Talk:Colour pinstripe/Printer: Difference between revisions

From Rosetta Code
Content added Content deleted
(The task is really to demonstrate the coding.)
(I don't think we necessarily need to bypass the driver.)
Line 15: Line 15:


I know how to do most of this in C (or C++) on Windows (via [[GDI]] and a syscall) for ''raster'' printers, with the exception of [http://msdn.microsoft.com/en-us/library/dd144877%28VS.85%29.aspx querying the printer driver] to get awareness of the ink colors available. (For example, to my knowledge, most home HP inkjet printers support a five-color model, if the right cartridges are used. I'm not aware of these capabilities being made available to userland applications, though; I'm fairly sure they're used as a dither basis in either the printer driver or the printer's internal processor.). Also, this task is specifically plausible only for raster printer devices. I would suggest that the task be renamed to [[Colour pinstripe/Raster]]. Since the task as-written only supports devices which allow bypassing of driver and internal processing, it may also be sensible to specify an explicit color order (such as CMYK(CM|B)(MY|R)(YC|G), or else each example would have to be specific to a particular printer control language. That said, comparison of PostScript vs PCL is a good thing, but it'd be preferable for it to not be the ''only'' thing. --[[User:Short Circuit|Michael Mol]] 15:55, 23 May 2011 (UTC)
I know how to do most of this in C (or C++) on Windows (via [[GDI]] and a syscall) for ''raster'' printers, with the exception of [http://msdn.microsoft.com/en-us/library/dd144877%28VS.85%29.aspx querying the printer driver] to get awareness of the ink colors available. (For example, to my knowledge, most home HP inkjet printers support a five-color model, if the right cartridges are used. I'm not aware of these capabilities being made available to userland applications, though; I'm fairly sure they're used as a dither basis in either the printer driver or the printer's internal processor.). Also, this task is specifically plausible only for raster printer devices. I would suggest that the task be renamed to [[Colour pinstripe/Raster]]. Since the task as-written only supports devices which allow bypassing of driver and internal processing, it may also be sensible to specify an explicit color order (such as CMYK(CM|B)(MY|R)(YC|G), or else each example would have to be specific to a particular printer control language. That said, comparison of PostScript vs PCL is a good thing, but it'd be preferable for it to not be the ''only'' thing. --[[User:Short Circuit|Michael Mol]] 15:55, 23 May 2011 (UTC)

I don't think we necessarily need to bypass the driver. It may be possible for the application to tell the driver to print the pinstripe, and the driver does the printing. Likewise, the code could tell the driver what colour it wants, and the driver can do the necessary adjustments
using the inks available in the device. (It would be reasonable to expect black, red, blue, green, magenta, cyan and yellow, and white).

[[User:Markhobley|Markhobley]] 16:04, 23 May 2011 (UTC)

Revision as of 16:04, 23 May 2011

We've got a 2400 dpi color printer; no way am I going to do 1 pixel wide color stripes on it, as it'll just look like mush. Perhaps the task needs some rewording to take into account a greater diversity of hardware? –Donal Fellows 14:39, 23 May 2011 (UTC)

The purpose is demonstrate pixe by pixel control of the printer by the production of a test pattern. The 1 pixel wide stripes may mush on some printers. However, as you go down the page, the stripes get wider. This would be considered normal, and can be used as a reference point for comparing printers.

Markhobley 15:01, 23 May 2011 (UTC)

Yes, after an inch the pinstripe is 2 pixels wide, after a foot, it's 12 pixels wide, after 10 feet, it's 120 pixels wide. But I am not quite sure what this means for an HP Designjet with a full roll of paper. --Rdm 15:20, 23 May 2011 (UTC)

Perhaps a reasonable limitation would be "no fewer than three color cycles, and then no greater than one square"? (where square would be the largest equal-logical-width, equal-logical-height space--a 1ftx250ft roll would produce a 1ft square.) Go three cycles, and then continue up to 1-square. Also...I wonder what Windows' GetDeviceCaps reports for that printer for HORZSIZE, VERTSIZE, HORZRES and VERTRES --Michael Mol 15:55, 23 May 2011 (UTC)

The task is really to demonstrate the coding. You could always adjust the run length and step distances for a specific implementation in live code (Maybe set variables at the top of the code). I don't think we need to worry about that for the purpose of this task. As long as the task demonstrates the fine control of the printer, a reader would be able to wield the techniques demonstrated to achieve their specific goals.

Markhobley 15:57, 23 May 2011 (UTC)

I know how to do most of this in C (or C++) on Windows (via GDI and a syscall) for raster printers, with the exception of querying the printer driver to get awareness of the ink colors available. (For example, to my knowledge, most home HP inkjet printers support a five-color model, if the right cartridges are used. I'm not aware of these capabilities being made available to userland applications, though; I'm fairly sure they're used as a dither basis in either the printer driver or the printer's internal processor.). Also, this task is specifically plausible only for raster printer devices. I would suggest that the task be renamed to Colour pinstripe/Raster. Since the task as-written only supports devices which allow bypassing of driver and internal processing, it may also be sensible to specify an explicit color order (such as CMYK(CM|B)(MY|R)(YC|G), or else each example would have to be specific to a particular printer control language. That said, comparison of PostScript vs PCL is a good thing, but it'd be preferable for it to not be the only thing. --Michael Mol 15:55, 23 May 2011 (UTC)

I don't think we necessarily need to bypass the driver. It may be possible for the application to tell the driver to print the pinstripe, and the driver does the printing. Likewise, the code could tell the driver what colour it wants, and the driver can do the necessary adjustments using the inks available in the device. (It would be reasonable to expect black, red, blue, green, magenta, cyan and yellow, and white).

Markhobley 16:04, 23 May 2011 (UTC)