Incorrect positioning of a glyph when put on path (rev >= 12488)

[Shrinivas]

To reproduce this bug, paste this string in devanagari script: वर्ष in Inkscape. Note the placement of the curve above the character ष. Now draw a horizontal straight line and put the same string (वर्ष) on path. Observe the change of the placement of the glyph above ष.
The aberrant behavior is evident when the straight line is rotated when the text is still on path. All the glyphs when put on path should have fixed position relative to each other, whereas in this case the curve above the line changes its position with respect to the other characters. (Please refer to the attachment.)

[su_v (suv-lp)]

Please always include information about OS/platform and Inkscape version when filing a report, thank you.

Based on tests with stable current releases (on OS X 10.7.5):
- not reproduced with Inkscape 0.47, 0.48.5
- reproduced with Inkscape 0.91 r13725

Based on tests with archived trunk builds (same OS):
- not reproduced with lp:inkscape rev <= 12487,
- reproduced with lp:inkscape rev >= 12488;
the reported issue was likely exposed with the changes merged in r12488:
Revision 12488: Merge emf/wmf work (bug #988601)
https://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/12488

[su_v (suv-lp)]

Also reproduced with lp:inkscape/0.92.x r15087 (stable release branch for upcoming 0.92).

[jazzynico (jazzynico)]

Reproduced on Windows 7 with 0.91 and lp:inkscape/0.92.x rev. 15090.
Not reproduced with 0.48.5.

[Martin Owens (doctormo)]

Fixed in r15139, tangents were being reset if it wasn't a normal charicter. But this reset wasn't needed. Removed two lines of code, above svg opens fine. Rotation works perfectly.

I'm going to push this patch to 0.92 branch.

[su_v (suv-lp)]

AFAICT not fully fixed, see attached example - the rendering of the composited glyph put-on-path differs from how it rendered in earlier Inkscape releases and lp:inkscape rev <= 12487 (and e.g. in web browsers). Needs investigation into what is the correct behavior based on the SVG specification?

[Martin Owens (doctormo)]

Agreed that there is still an issue. But the specific bug that caused the glyph to be on a completely different matrix when on a path is now fixed. I'm not sure if we should make a new report for the fixed bug or for this more subtle character index/position bug, but they should probably be separate since the solution for the subtle bug could be very hard to solve.

[David Mathog (mathog)]

I wish I had time to work on this, but I don't.

If somebody else wants to go for it here is my fading recollection of the root of many of these problems. Somewhere or other in the Pango pipeline, at around pango_shape(), there is a step that breaks a unicode string down into not just a series of glyphs, but a series of glyph logical clusters. The latter is stored in a second array (like 1,2,3,3,3,4,5..., where the 3,3,3 indicates that the 3,4, and 5th glyphs are in the same logical cluster):

https://developer.gnome.org/pango/stable/pango-Glyph-Storage.html

For European languages glyphs are pretty much 1:1 with the logical clusters but that is very much not so for other languages. Further along Inkscape somewhere or other makes an implicit assumption that the series of glyphs all play by the same rules, that is that the logical clustering can be ignored. Problems follow. I'm pretty sure I broke some of the Indic languages in an attempt to make the vowels and diacriticals in Hebrew go where they should, by rearranging them within a cluster. That is bug #1282968. The correct fix would have been to retain the cluster information longer so that at a later point code wasn't trying to place glyphs by sequentially offsetting by the width of the previous glyph. That is true lots of places: kerning, character selection, character formatting, all of these things should be done on the logical cluster, not the glyph. Any place you find that works with a line of text converted to just a series of glyphs it isn't quite right for these other languages.

I believe pango has functions for finding the appropriate offsets of clusters, but Inkscape may not be using these in all locations.

A possibly related/confounding issue concerns inconsistent use of unicode's "Mark, Nonspacing". See the discussion in bug #500343 at post 5.

[Shrinivas (vierzig)]

From my side I confirm the fix of this bug.

Tested on version: inkscape-trunk (1:0.91.0+devel+15147+77~ubuntu16.04.1)
OS: Linux Mint 18, Mate
Processor: Intel

Was amazed by the swift turnaround.
A heartfelt thank you to the Inkscape team!!