Bug 28061

Summary: Evince prints some RTL documents scrambled
Product: cairo Reporter: Carlos Garcia Campos <carlosgc>
Component: pdf backendAssignee: Adrian Johnson <ajohnson>
Status: RESOLVED FIXED QA Contact: cairo-bugs mailing list <cairo-bugs>
Severity: normal    
Priority: medium CC: freedesktop
Version: 1.9.7   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: patch

Description Carlos Garcia Campos 2010-05-11 02:50:50 UTC
Bug forwarded from Evince: https://bugzilla.gnome.org/show_bug.cgi?id=618261

"Certain PDFs in RTL languages in evince are printed scrabbled. I should note
the document prints fine in acroread on linux.

Attached PDF example renders like this (correctly):
http://gnet.homelinux.com/pics/evince_should_print.png

But is printed Like this:
http://gnet.homelinux.com/pics/evince_what_is_printed.png

Using evince 2.28.2 on Debian Sid"

Test case is attached to the original bug report.
Comment 1 Behdad Esfahbod 2010-05-11 13:17:28 UTC
Both the original pdf and the Print-to-PDF output from evince render fine in evince and gv.  Should be something with the particular printer in question.  What printer is it, do you know?
Comment 2 Adrian Johnson 2010-05-11 14:54:21 UTC
I can reproduce the problem. I'm working on a fix.
Comment 3 Adrian Johnson 2010-05-12 07:30:24 UTC
Created attachment 35594 [details] [review]
patch

The problem is incorrect values in the widths array of the PDF font dictionary. This only affects PDF output, not PS output. Depending on your distro your version of evince may have the patch for printing in PDF format.

The cause of the incorrect widths is that currently cairo is using the glyph advances in font units in the PDF output. This works for the majority of Type 1 fonts that use a 1/1000 glyph scale as this is also the scale used for the widths array by PDF. The PDF in comment 0 contains a Type 1 font with 1/1200 scale. As a result spacing in strings of glyphs is increased. Each time a new string of glyphs starts at a fixed position it partially overlaps the previous string.

Behdad, could you check that the use of linearHoriAdvance in the attached fix is correct.

CFF fonts also have the same problem and require the scaling fix already used for TrueType fonts.
Comment 4 Behdad Esfahbod 2010-05-15 11:19:43 UTC
Looks right to me.

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.