Summary: | Evince prints some RTL documents scrambled | ||
---|---|---|---|
Product: | cairo | Reporter: | Carlos Garcia Campos <carlosgc> |
Component: | pdf backend | Assignee: | 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
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? I can reproduce the problem. I'm working on a fix. 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. 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.