Cursive attachment font problem

I have made a font that works in Chrome and Firefox, but not in LibreOffice Writer, even though all three of those use HarfBuzz. Specifically, it looks like cursive attachment is broken. There is clearly a bug somewhere, but is it in my font or in LibreOffice?

To reproduce, install the font at and create a new document containing “𛰅𛰆𛱂‌𛰀𛱚‌𛱊𛱁𛰙 𛰙𛰜𛱁𛱆‌𛰅𛱁!” (that is, <U+1BC05, U+1BC06, U+1BC42, U+200C, U+1BC00, U+1BC5A, U+200C, U+1BC4A, U+1BC41, U+1BC19, U+0020, U+1BC19, U+1BC1C, U+1BC41, U+1BC46, U+200C, U+1BC05, U+1BC41, U+0021>) in that font. The letters aren’t cursively joined properly. Paste the same string at Duployan font test to see the intended rendering.

My best guess is that LibreOffice configures HarfBuzz with a lower HB_BUFFER_MAX_OPS_FACTOR than the default. Could that be it? Does LibreOffice have its own maximums that this very complex font might be overshooting?

Here is the string rendered in Firefox on the left and LibreOffice on the right.

I had a look to the font with FontForge app because I had the same kind of issue some time back with a cursive Sütterlin font.

I wanted it to work even in justified alignment. Unfortunately, glyphs may be spaced apart from each other as a result of justification.

But even without justification, it is rather tricky to join glyphs: the entry and exit points must be positioned the same in every glyph bounding box. Also the angles of entry and exit lines must be equal.

Angles appear OK but I am not sure that your exit points are correctly positioned. They seem a bit too far from the right edge of the bounding box, thus leaving some white space with the next glyph (or else your entry points are not far enough from the left edge of the bounding box.

If I understand right your font purpose, you’re trying to computer print stenography. IMHO, the difficulty lies in stroke direction which can be left-bound in LTR context… Thus to join one glyph to the next, the bounding box width should probably be negative. I don’t know if font renderers (anf FontForge) can handle that.

Anyway Firefox seems to render your example without “glitch”, but to be sure, add a screenshot (edit your question for that, don’t use a comment) so that I can compare my rendering with what you complain about (and maybe add also one for correct rendering).

This font implements cursive using cursive attachment lookups in GPOS. This is like what some Arabic fonts do. The entries and exits don’t need to be at the same height and the left and right margins don’t matter.

I have looked more and I think the problem is that the font is too complex for LibreOffice to handle so many characters in a run. If you put each syllable on its own line, each syllable is shaped properly.

So my question becomes: What imposes this limit on complexity?