Bug 39067

Summary:	0 width lines are too wide when printing
Product:	poppler	Reporter:	Adrian Johnson <ajohnson>
Component:	cairo backend	Assignee:	poppler-bugs <poppler-bugs>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	medium
Version:	unspecified
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:
Attachments:	patch to fix the bug

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.