| Summary: | pxlcolor: differences in line width | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | Marcos H. Woehrmann <marcos.woehrmann> |
| Component: | PXL Driver | Assignee: | Hin-Tak Leung <htl10> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | Keywords: | bountiable |
| Priority: | P4 | ||
| Version: | master | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Customer: | Word Size: | --- | |
| Attachments: |
002-21.png
012-01.png doing rounding of co-ordinates and pen-width |
||
|
Description
Marcos H. Woehrmann
2009-10-30 11:48:31 UTC
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.
|