Comment 43 for bug 1425387

It looks like Inkscape was originally just for Latin languages and makes an assumption that the "next" glyph will have a width so that it is OK to calculate advance values by just adding glyph widths sequentially. Hebrew has diacritical marks (essentially vowels) which are in a cluster with the primary glyph. The problem was that these would come out in the wrong order, diacriticals first (probably because it is a R->L language), so the advance calculation, based on width, would fail when it looked at the diacritical marks. I believe the fix used was to sort within the cluster by width, because the primary was always wider and the diacriticals had zero width. However, other languages do completely different things with glyph clusters and this is what is probably breaking Thai and other languages.

If anybody has time to fix this (I do not) the correct solution would be to revert the sort "fix" and instead implement a smarter width calculation. My memory is fuzzy but I don't recall that the Inkscape code was carrying along the cluster information at the point the "advance" calculation is performed. Probably somewhere in the underlying libraries there is a "width of this cluster" function which may be employed. (Best person to ask would be Behdad Esfahbod, author of harfbuzz, http://behdad.org/.)

In other words, go from the current (as I recall, from the last time I looked at it):

glyph array (0->N-1, each with width information)

to

glyph array (0->N-1, each with width information, now ignored for "advance")
glyph cluster array (start,end, cluster width; 0->M-1, M<=N, now used for "advance")

For languages like English or French, where clusters are all 1 glyph, all this does is
move the width into a parallel array. However for more complex languages like Hebrew, Thai, or Hindi it would retain the proper width for glyph clusters all the way to the point where they are rendered.