Talk:Colour pinstripe/Printer: Difference between revisions

From Rosetta Code
Content added Content deleted
(Thoughts, musings, and resolving an edit conflict with another comment.)
(The task is really to demonstrate the coding.)
Line 8: Line 8:
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. --[[User:Rdm|Rdm]] 15:20, 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. --[[User:Rdm|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 --[[User:Short Circuit|Michael Mol]] 15:55, 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 --[[User:Short Circuit|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.

[[User:Markhobley|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 [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)

Revision as of 15:57, 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)