Description: In earlier versions (through 5.2?), when I typed multiple combining Cyrillic characters over regular Cyrillic characters in an Old East Slavic text that I am editing, the characters would be visible as a stack (the regular character below, the first combining character above it, and the second combining character above the first). Now when I type the same way the combining characters overlap with each other. (I initially switched to LibreOffice because in Microsoft Word combining characters overlapped each other as they now do in LibreOffice). Steps to Reproduce: 1. Enter any standard Cyrillic character (I use the font Bukyvede, which has many rare characters.) 2. Enter one combining Cyrillic character above the first one. (I typically use a small combining letter, e.g. ⷮ . (I use PopChar to enter letters with no keyboard equivalent.) 3. Enter a second combining Cyrillic character (typically ҇ )above the first one. Actual Results: Combining characters overlap each other above standard character Expected Results: First combining character appears above standard character; second combining character appears above first combining character. (I do not mind if the higher character interferes with the line of print above it; the solution is to make a greater space between lines.) Reproducible: Always User Profile Reset: No Additional Info: While this problem may affect only a small number of users, it is a major problem for anyone attempting to reproduce an Early Slavic text. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/603.2.4 (KHTML, like Gecko) Version/10.1.1 Safari/603.2.4
Created attachment 134779 [details] Sample of Cyrillic combining character overlap
Not sure how the script is supposed to handle them but with Segoe UI while they combine we do seem to have misalignment with multiple combining glyphs. Combining characters in these Unicode blocks: 0483-0489 2de0-2dff a66f-a67d рⷱ҇е прⷪ҇ркъ лⷮ҇ from attachment 134779 [details] U+0440U+2df1U+0487U+0435 -- рⷱ҇е U+043fU+0440U+2deaU+0487U+0440U+043aU+044a -- прⷪ҇ркъ U+043bU+2deeU+0487 -- лⷮ҇ U+a69bU+a67cU+a674 -- ꚛ꙼ꙴ
Using BabelPad, a Unicode 9 compliant editor, selecting multiple Cyrillic combining glyphs stack as OP requires. This Unicode.org technical note L2/15-002 seems germane, and has a few more examples: http://unicode.org/L2/L2015/15002-double-titli.pdf
Created attachment 135263 [details] Screenshot with Ponomar Unicode With PonomarUnicode.otf (NOT .ttf, availabe at http://sci.ponomar.net/fonts.html) I found all of then except лⷮ҇ have such problem, and I found the shape of ⷮ (U+2DEE) designed not suitable to combine with ҇ (U+0435). With BukyVede font I found all Combining Cyrillic letters overlapped with U+0435 even if U+2DEE looks just like small т, so I can conclusion this is font issue, and I suggest you can contect designers of BukyVede font for this.
Volga suggests that the problem is with the font Bukyvede. However, if I understand Volga correctly, ҇ does not combine with ⷮ above a third letter in the font Ponomar or presumably, in any other Slavic font the contains the combining characters. This would mean that the bug is shared by all such Slavic fonts. The problem with this response is that the characters combined perfectly well in OfficeLibre 5, and even in old versions of Microsoft Word. It appears that some "improvement" in OfficeLibre has, as a side effect, prevented the combination from working in any font. I would guess that the "improvement" was intended to prevent large stacks of letters from overlapping with the line above the stacks. Perhaps the "improvement" is even recommended in some technical UNIX document. This does not mean that the result is not a bug, since it ruins the functionality of a large group of fonts that have been functional (with updates) for decades.
I note that, as Volga remarks, the characters do combine properly in ponomar ttf but not ponomar otf . However, in light of my previous remarks, it still seems that the bug is in LibreOffice, and not in the many fonts that have suddenly become problematic.
Created attachment 135457 [details] Screenshot with BukyVede and BabelPad I tested on both BabelPad and LibreOffice, these fonts performanced the same to me, so I can sure this font is a bit buggy.
This is a font bug, LibreOffice does not interfere with mark positioning provided by the font, however this font does not provide any mark positioning at all and relies solely on heuristics applied by the text layout system. We use HarfBuzz which have such heuristics, but it applies them only when the font does not have GPOS table (glyph positioning table) but this font has one that does kerning only and no mark positioning. It is possible that the system text layout libraries that we used before applied these heuristics more liberally. But font designers should not be depending on such heuristics since they are neither standardized nor well documented.
Created attachment 137364 [details] How the text looks with GPOS table removed fom the font Here is how the text looks when I remove the GPOS using FontTools Python library: $ ttx -x GPOS BukyVede-Regular.ttf $ ttx BukyVede-Regular.ttx and then using the BukyVede-Regular#1.ttf instead of the old file.