Bug 28061 - Evince prints some RTL documents scrambled
Summary: Evince prints some RTL documents scrambled
Alias: None
Product: cairo
Classification: Unclassified
Component: pdf backend (show other bugs)
Version: 1.9.7
Hardware: Other All
: medium normal
Assignee: Adrian Johnson
QA Contact: cairo-bugs mailing list
Depends on:
Reported: 2010-05-11 02:50 UTC by Carlos Garcia Campos
Modified: 2010-05-16 04:28 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

patch (4.08 KB, patch)
2010-05-12 07:30 UTC, Adrian Johnson
Details | Splinter Review

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):

But is printed Like this:

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]

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.