Open floppyhammer opened 1 year ago
It is probably because Unifont doesn't have OpenType shaping rules for Arabic, and HarfBuzz synthesizes those, implementing fallback Arabic shaping, which rustybuzz currently doesn't. This is documented behavior.
From README:
@behdad Thanks for the answer! I didn't realize that.
Yes, this particular feature is not implemented. I wasn't expecting it to be that common. I guess I would have to figure it out after all.
Could you further explain why implementing this requires subsetting? I don't understand how a shaping feature would require implementing subsetting?
It doesn't "require" subsetting per se, but it requires part of it. At least this is how it is implemented in HB.
I do not remember details, it was nearly 5 years ago, but I assume this is hb-ot-shaper-arabic-fallback.hh
. And as you can see HB creates temporary tables using subsetting code and them passes them to the shaper.
Meaning we have to implement this part of subsetting as well.
It needs the code to serialize SingleSubst and LigatureSubst tables. Alternatively you can implement the logic in code...
Good to know, thanks! I guess it should be doable...
Test text: ح ب ا حبا It consists of two parts (separated with a space): حبا ح ب ا The second part is basically the first part with every character delimited with space (in order to cancel ligatures).
Related buffer config:
Test case 1 (unifont-15.0.01.ttf) Shaped glyph id: harfbuzz
56721 56725 56237 35 56720 35 56722 35 56740
rustybuzz1578 1579 1584 35 1578 35 1579 35 1584
So firstly, I had tested with unifont, and rustybuzz failed to handle the ligatures. I thought I must had got something wrong, but then I tested with another font.
Test case 2 (HONORSansArabicUI-B.ttf) Shaped glyph id: harfbuzz
7 33 97 1 5 1 30 1 93
rustybuzz7 33 97 1 5 1 30 1 93
And the result is correct and conforms to that of harfbuzz.
There might be something off with rustybuzz.