Many files are rendered with different line widths when converted to ppmraw directly by Ghostscript or via pxlcolor. In some cases this results in gaps and in other cases missing lines. The attached 002-21.png file shows the difference in the file 002-21.ps (found in the private repository in tests_private/ps/ps3fts). The directly converted ppmraw file is on the left. The attached 012-01.png file shows the difference in the file 012-01.ps (found in the private repository in tests_private/ps/ps3fts). The directly converted ppmraw file is on the top. Command lines used for testing: gshead -sDEVICE=pxlcolor -r600 -o test1.pxl ./$1 pclhead -sDEVICE=ppmraw -r600 -sOutputFile=viapxl.ppm -dNOPAUSE ./test1.pxl gshead -sDEVICE=ppmraw -r600 -o direct.ppm ./$1 I'm testing with r10243 for both GhostPCL and Ghostscript.
Created attachment 5590 [details] 002-21.png
Created attachment 5591 [details] 012-01.png
I have a general idea why that happens - PXL co-ordinates are 16-bit signed integers (in units declared up-front, which is usually 600 per inch but can be 300/1200/2400). In many places co-ordinates out of the graphic library are simply cast'ed to (int), which is just throwing the fraction bits away. So there are one pixel differences everywhere; presumably ppmraw and elsewhere in ghostscript, one does (int)(x + 0.5) (round to nearest integer) rather than (int)(x) , (clip the fractional bits), To fix this, adding a fair number of +0.5 to various casts will help. I can give this a go, after fixing the other more "interesting" bugs.
Created attachment 5601 [details] doing rounding of co-ordinates and pen-width This do rounding of the co-ordinates and penwidth - it is proper to do so, but does not help the issue reported. The issue reported is that penwidth below 0.5pixels are simply lost. It appears that gs ppm direct imposes a minimum pen width to make sure very thin lines are drawn for at least one pixel.
I tried setting a minimum penwidth, but apparently the pxlcolor/pxlmono driver never receive any instructions for setting line width to very small values.
It appears that ppmraw can draw very thin lines at 1-pixel, but base/gdevpx.c has a line which says: NULL /****** WRONG ******/, /* draw_thin_line */\ This line was in gs 6.0.
The two differences in line widths are two different issues - the effect showed in attachment 5590 [details] is due to inaccuracy in co-ordinate calculation, which be fixed by a combination of *both* the attached patch 5601 *and* setting -r1200 during the pxlcolor/pxlmono stage. The latter causes the co-ordinate calculation (which are rounded to integers due to PXL's limitation) to calculate to a higher resolution of 1/1200 per inch. The latter is apparently due to pcl6's interpretation of very thin lines - all the raster devices such as ppmraw in ghostscript draws very thin lines at 1-pixel; pcl6 outputting to ppmraw treats them as thin lines and not draw them. This can be demonstrated by using pcl6 to output to pdf then use gs to generate the ppm instead: gs -sDEVICE=pclcolor -o pxlout.pxl 012-01.PS pcl6 -sDEVICE=pdfwrite -sOutputFile=pxlout.pdf pxlout.pxl gs -sDEVICE=ppmraw -o pxlout.ppm pxlout.pdf pcl6 -sDEVICE=ppmraw -sOutputFile=pxlout.ppm pxlout.pxl So I would recommend apply the patch, possibly modify the testing procedure slightly to include a -r1200 switch in the pxlcolor/pxlmono stage, and try to fix the inconsistency of what to do with very thin lines.
The patch in comment 4 was committed as r10266 'Do rounding of co-ordinates rather than clipping'.