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.
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.
I forgot to mention that the glyph positioning adjustments may be kerning. Try using a monospace font.
It may be inkspace not properly turning hinting off.
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
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.
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.