Bug 4536

gpdf and xpdf display these calendars fine.

I don't see any problems with these PDFs.  Could you please attach the specific
PDF you see a problem with and a screenshot.  Alternatively, if the problem is
gone, please close the bug.  Thanks.

Sorry, I forgot that. I use the lastest stable version and I don't get the
images right. In the attachment you have what Acrobat displays and what evince
displays.

Created attachment 5264 [details]
acrobat display

Created attachment 5265 [details]
folding lines acrobat display

Created attachment 5266 [details]
folding lines evince display

Created attachment 5268 [details]
another evince display

Comment on attachment 5266 [details]
folding lines evince display

In the attachments described as “folding lines”, acrobat displays the
folding lines, but evince doesn't.

The other two attachments show no difference in rendering (but I don't know how
to remove them).

Bugzilla Upgrade Mass Bug Change

NEEDSINFO state was removed in Bugzilla 3.x, reopening any bugs previously listed as NEEDSINFO.

  - benjsc
    fd.o Wrangler

Can you check with a new poppler?

Folding lines are not different than the ones displayed in the attachment three years ago using poppler-0.11.1 and evince-2.26.2.

I hope it helps.

Thanks,


Pablo

I realize that I haven't explained the issue accurately.

Attachments 1 and 4 might be right (and poppler fixed), since folding lines are displayed fine.

But attachments 2 and 3 are those with folding lines not properly displayed.

I update the summary accordingly.

I hope it is clear now.


Pablo

Cairo only problem

I've just generated one of those pdfs and I can see all the lines. 

(In reply to comment #14)
> I've just generated one of those pdfs and I can see all the lines.

Regular dodecahedron is displayed fine, but rhombic dodecahedron isn't. The folding lines are missing there. (Compare https://bugs.freedesktop.org/attachment.cgi?id=5266 with https://bugs.freedesktop.org/attachment.cgi?id=5265.)

I hope it helps,


Pablo

confirmed, it seems there's a problem when line_width < 1.0. 

*** Bug 11288 has been marked as a duplicate of this bug. ***

*** Bug 21729 has been marked as a duplicate of this bug. ***

*** Bug 14315 has been marked as a duplicate of this bug. ***

*** Bug 24228 has been marked as a duplicate of this bug. ***

Seems not to have been fixed in poppler-0.14.0 (tested with gtk-splash-test).

Again, for some strange reason gtk-cairo-test seems not to be able to load it.

*** Bug 29043 has been marked as a duplicate of this bug. ***

Created attachment 50481 [details] [review]
set minimum line width to 1

PDF has a Stroke Adjust parameter than when true requires that lines be at least 1 pixel wide. This patch adds a stroke_adjust parameter to CairoOutputDev that when true adjusts lines with a device width of < 0.5 pixels to be 0.5 pixels wide.

Like the splash backend, the Stroke Adjust parameter is initialized from the globalParam setting (with default value true) and overrides the setting in the PDF file. This emulates Adobe Reader where the Stroke Adjust is controlled by the "Enhance Thin Lines" setting in Preferences (defaults to true) that overrides the SA in the PDF file.

I found a minimum line of of 0.5 to produce better results than using 1.0 because unaligned horizontal and vertical 1.0 width lines in cairo are rendered 2 pixels wide. The test case in bug 14315 is a good example.

Created attachment 50482 [details] [review]
align 1 pixel wide lines

This patch extends to the previous fix to align 1 pixel wide lines so that cairo renders them 1 pixel wide as described at http://www.cairographics.org/FAQ/#sharp_lines

The minimum line width has been increased to 1 pixel wide now that the rendered width is 1 pixel wide.

The test case in bug 14315 now renders almost exactly like Adobe Reader.

Hey, it's great you tackle this kind of rendering glitches!

Yes!, thank you very much Adrian, both patches have been pushed to git master.

*** Bug 14133 has been marked as a duplicate of this bug. ***