Performance fixes for GSUB/GPOS dumps#5547
Conversation
FontForge has limited support for class based kerning, it supports only certain value record formats, and for the rest it explodes the class kerning into kern pairs: fontforge/fontforge/parsettfatt.c Lines 556 to 562 in 072208f fontforge/fontforge/parsettfatt.c Lines 662 to 675 in 072208f |
|
This is because fontforge/fontforge/splinefont.h Lines 593 to 609 in 072208f But too fully represent GPOS PairPosFormat2 subtable, it would probably need two That is one of the severe limitations of FontForge when working with RTL fonts, as it means it basically can’t handle RTL class-based pair positioning as it requires adjusting both the offset and advance width of the glyph. It might be possible to detect RTL kerning and store and store only one value and special flag that it is RTL so that when writing GPOS back, the value is used for both offset and advance. This might not be perfect, but it will at least handle the common RTL kerning case while not needing too much changes to existing code. |
|
Run bulk test |
frank-trampe
left a comment
There was a problem hiding this comment.
@iorsh is going to run a few more tests, but the code conceptually looks good.
|
Bulk tests passed with the following environment: |
This PR improves the performance of saving large OpenType GPOS/GSUB tables.
@khaledhosny, on my machine the performance of saving Amiri font improved roughly from 68s to 10s, with comparable HarfBuzz metrics view (#5522) improvement. This is still suboptimal, but some Amiri kerning features are loaded as subtable with 6.8M (yes, six million) kerning pairs. I don't know what causes it, as the original font doesn't have anything like that.
Type of change