Thu 02 Apr 2015 08:09:11 AM UTC, original submission:
Although libotf correctly works out which mark a mark is attached to, this information is not passed to the caller of any member of the OTF_drive_gpos*() family of interface functions.
Normally this is not a problem - interacting marks tend to be sorted out into runs of the same kind. In these cases, the mark attached to is the preceding mark, and the Emacs code in function ftfont_drive_otf() in ftfont.c makes this assumption.
However, this does not work in some unusual but natural strings, such as Northern Thai ᨻᩦ᩠᩵ᩋᩬ᩶ᨦ 'relatives', where the sequence of marks is SIGN II (above), TONE-1 (above), <SAKOT, NA> (below), OA BELOW (below), TONE-2 (above). TONE-2 attaches to TONE-1, but the client assumes it is attached to OA BELOW and mispositions it.
An upwards compatible solution would be for the client to signal that it will accept complete information and receive it through a supplementary fake glyph, just as multiple lookup type 1 and type 2 positionings are combined using the 'accumulate' option. I note that the Emacs client currently fails to implement this part of the interface. The glyph code of the glyph attached to would be sufficient information - OpenType offers no mechanism to choose between preceding glyphs with the same glyph code.
Making the font reorder the combining marks is not a solution. Moroever, it is the font that decides whether <SAKOT, X> is a combining mark or a non-spacing mark for several characters X, so m17n cannot perform the desirable reordering.
|