Bug 49902

Summary: Splitting up long word in eps-export, results in psfrag-incompatible output
Product: cairo Reporter: azzzt
Component: postscript backendAssignee: Adrian Johnson <ajohnson>
Status: RESOLVED NOTOURBUG QA Contact: cairo-bugs mailing list <cairo-bugs>
Severity: normal    
Priority: medium CC: freedesktop
Version: 1.12.2   
Hardware: x86-64 (AMD64)   
OS: Windows (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: Example eps file

Description azzzt 2012-05-14 05:04:33 UTC
Created attachment 61609 [details]
Example eps file

If one uses inkscape to generate a graphic und exports it to an eps file, a long word gets split up in several substrings, for example

original word in Inkscape "AAAAAAAAAAAAA" 
output in the eps-file "(AAA)-3(AAA)-3(AAA)-3(AAA)-3(A)"

When psfrag, which is tool to write LaTeX code into an epsfile, looks for the word "AAAAAAAAAAAAA" and tries to replace it, it now fails since it cannot find the string "AAAAAAAAAAAAA". With Adobe Illustrator the word is exported correct and psfrag is able to replace long words with LaTeX code. psfrag is actually used quite a lot in science, so it would be great if cairo would be compatible with psfrag.
Comment 1 Adrian Johnson 2012-05-14 05:17:03 UTC
The "-3" is an adjustment to the glyph position because the glyph positions requested by Inkscape are not at the natural glyph advances. The problems is Inkscape is introducing errors in the glyph positions when laying out text.


Testing with

pango-view -o test.ps -t AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

outputs the glyphs in a contiguous string.
Comment 2 Adrian Johnson 2012-05-14 05:28:11 UTC
I forgot to mention that the glyph positioning adjustments may be kerning. Try using a monospace font.
Comment 3 Behdad Esfahbod 2012-05-14 05:50:10 UTC
It may be inkspace not properly turning hinting off.
Comment 4 azzzt 2012-05-14 05:56:21 UTC
I tried it with CourierNew and FreeMono but still had the same effect. I assumed that it hasn't to do with the kerning, since it happens always seem to happen after a certain number of glyphs, here after every 6th character:

[(abcdef)3(ghijkl)3(mn)]TJ
[(AA abc)3(de)]TJ
Comment 5 Adrian Johnson 2012-05-14 06:09:41 UTC
The reason you see the adjustment every few glyphs is cairo allows a small error (3/1000 of the font size) before it emits the adjustment. However even if the error is less then 3/1000 font size, if Inkscape is consistently adding an small offset to difference between each glyph the error accumulates and eventually cairo is forced to adjust the position of the next glyph.
Comment 6 James Cloos 2012-05-14 07:34:34 UTC
b> The reason you see the adjustment every few glyphs is cairo allows a
b> small error (3/1000 of the font size) before it emits the adjustment.

Perhaps cairo could check whether setting a negative Tc value would
avoid breaking the strings and use that in such cases?

Checking whether all of the adjustments in a TJ array are the same and
come after the same strlen would seem to be a reasonable starting point.

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.