Bug 39067 - 0 width lines are too wide when printing
Summary: 0 width lines are too wide when printing
Status: RESOLVED FIXED
Alias: None
Product: poppler
Classification: Unclassified
Component: cairo backend (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: poppler-bugs
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-08 04:56 UTC by Adrian Johnson
Modified: 2011-08-19 07:23 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
patch to fix the bug (992 bytes, patch)
2011-07-08 04:58 UTC, Adrian Johnson
Details | Splinter Review

Description Adrian Johnson 2011-07-08 04:56:47 UTC
https://bugzilla.gnome.org/show_bug.cgi?id=653913 contains a PDF file that prints incorrectly with evince.

The PDF is drawing a number of closely spaced boxes using the fill-stroke operator. The line width is set to 0. The cairo backend renders the PDF correctly to the display but when printing the boxes merge together into a black blob. The problem is the cairo backend is using a too large stroke width when printing.

When the line width is 0 the cairo backend sets the line width to 1. This is correct for the display where 1 unit = 1 pixel. But when printing 1 unit = 1/72 inch which is too large.
Comment 1 Adrian Johnson 2011-07-08 04:58:31 UTC
Created attachment 48891 [details] [review]
patch to fix the bug

Patch to fix this bug. It sets 0 width lines to be 1/600 inch wide when printing.
Comment 2 Brad Hards 2011-07-08 16:30:45 UTC
Review of attachment 48891 [details] [review]:

Do you have to assume the DPI? Is there any API for querying it?
Comment 3 Adrian Johnson 2011-07-08 16:54:03 UTC
(In reply to comment #2)
> Do you have to assume the DPI? Is there any API for querying it?

CUPS provides API for getting the printer DPI. But using this would require adding API to the glib frontend to set the DPI and the application would need to obtain the DPI from CUPS and call the glib API to set the DPI.

But this is over complicating a simple bug fix and we would still need to provide a sensible default for the cases when the application did not provide a DPI or when printing to a generic PDF/PS file or printing without CUPS.
Comment 4 Brad Hards 2011-07-08 17:41:07 UTC
Is cairo_surface_get_fallback_resolution() a possible option here?

I'm not very familiar with cairo, but I'm assuming that cairo knows the resolution of whatever its drawing to.
Comment 5 Adrian Johnson 2011-07-09 19:45:27 UTC
(In reply to comment #4)
> Is cairo_surface_get_fallback_resolution() a possible option here?
> 
> I'm not very familiar with cairo, but I'm assuming that cairo knows the
> resolution of whatever its drawing to.

Cairo does not know the resolution of the printers because it does not interact directly with printers. It simply outputs a device independent PS or PDF file.

The problem with using the cairo fallback resolution to obtain the width of zero width lines is the fallback resolution is intended for use with images. Gtk+ sets the fallback resolution using the halftone screen frequency obtained from the PPD file via CUPS. For example on my printer in 600dpi mode the number of half tone cells per inch is 106. Not much different to the 72dpi currently assumed by CairoOutputDev for zero width lines and still too thick to correctly print the test case.
Comment 6 Carlos Garcia Campos 2011-08-19 07:23:17 UTC
Pushed to git master, thank you very much.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.