After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 641255 - Evince ruins barcodes when they are composed of lines
Evince ruins barcodes when they are composed of lines
Status: RESOLVED NOTGNOME
Product: evince
Classification: Core
Component: printing
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Evince Maintainers
Evince Maintainers
: 653913 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-02-02 15:55 UTC by Margarita Manterola
Modified: 2012-07-06 20:01 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
A PDF file to test the problem. (5.95 KB, application/pdf)
2011-02-02 15:55 UTC, Margarita Manterola
Details
Print preview problem (on the left) (45.14 KB, image/png)
2011-04-02 10:54 UTC, Olivier Samyn
Details

Description Margarita Manterola 2011-02-02 15:55:24 UTC
Created attachment 179892 [details]
A PDF file to test the problem.

Hi!

I had been using evince to print bills with barcodes with Debian Etch's version (0.4.0) and it used to work perfectly fine.

Using modern versions (2.22 - Lenny, or 2.30 - Squeeze), the barcode is totally screwed by evince.

The barcode looks fine when zoomed in at 300% zoom or more, but when printed, it's like a big black block.  Even when printed to the PDF printer, the resulting PDF is then screwed.

The same file prints well in xpdf, acroread, using lp directly, and with the older evince version. It even prints fine with epdfview, so it's definitely an evince problem, and not a poppler problem.

When the barcode is an image, it's no problem for evince to print that right, but when it's a set of closely located lines, then it's not able to separate them correctly, and then end up being a big black block, with only a few small white lines in the middle.

I'm attaching the original pdf.  I can also attach the pdfs as they are generated when printing from evince and from epdfviewer, or whichever you want, all the others are the same, evince is the only one that screws the barcode.

--
Love,
Marga
Comment 1 Fabio Durán Verdugo 2011-02-02 18:38:38 UTC
Yes I can confirm this with 2.32 and git master.

change the status to NEW
Comment 2 Olivier Samyn 2011-04-02 10:54:27 UTC
Created attachment 184936 [details]
Print preview problem (on the left)
Comment 3 Olivier Samyn 2011-04-02 10:55:08 UTC
I get a similar problem when printing lilypond generated scores from evince.

The print preview already displays the problem. I attached a screenshot that shown the difference between the print preview(on the left) and the original.

Evince version 2.32.0 (Ubuntu 10.10).
Comment 4 Felix Möller 2011-07-21 20:02:22 UTC
I can confirm this with 

$ rpm -q evince poppler
evince-3.0.2-1.fc15.i686
poppler-0.16.7-1.fc15.i686
Comment 5 Adrian Johnson 2011-08-17 08:33:18 UTC
It is the same bug as bug 653913. The bar code is a series of rectangle paths drawn with the fill-stroke (B*) operator. The line width has been set to 0 (indicating the thinnest line that can be drawn). The cairo backend of poppler draws 0 width lines with 1 unit width. On the display 1 unit of width is 1 pixel which is correct. When printing 1 unit is 1/72 inch which is too wide. So the rectangles are stroked with a "fat" 1/72" line resulting in the bars being too wide when printed.

The poppler bug is https://bugs.freedesktop.org/show_bug.cgi?id=39067
Comment 6 José Aliste 2011-08-17 09:17:10 UTC
*** Bug 653913 has been marked as a duplicate of this bug. ***
Comment 7 Christian Persch 2012-07-06 20:01:10 UTC
The poppler bug is fixed, closing.