This would happen for a small random assortmentĭisabling setting of the `r2l` flag within `fontforgeexe/combinations.c` tests/fonts/Caliban.sfd file, whereįor example 'sometimes' "Lv" would be displayed right-justified as "vL", Very much as though FF thought right-to-left display The character pair would be displayed in reversed order and View / Combinations / Kern Pairs UI dialog, in addition to the otherĭialogs that can display kern pairs. Issue fontforge#1811 mentioned trying to understand kern pairs by consulting the It is hard to follow the logic, understand the input or output,Īnd the broken TTF from Google doesn't help. However there may be other issues with character-based kerning informationĮxport. Information is now correctly exported to the SVG file. This change addresses and should close issue fontforge#1811, as class-based kerning Information, with that being the only change to the SVG output. Of being a little more careful, checking for non-NULL before using theĪfter this change the generated SVG file contained the desired additional
If it is 'significant' containing information. This change has `svg_dumpkerns()` dump the initial entry in `sf->firsts` The "" list entry seen in the kerning dialog display.īut the initial entry in the `sf->firsts` list *( ) ( )* be a dummy This was reasonable for `sf->seconds` as this is a placeholder entry for The first entries in the font `sf->firsts` and `sf->seconds` lists. `fontforge/svg.c` routine `svg_dumpkerns()` first outputs char kern pairsĪnd then outputs font-based GPOS lookup kern information. Kerning classes could be found represented in SVG `` lines. The Element / Font Info / Lookups / GPOS / 'kern' lookup class 2ĭialog was not seen in the generated SVG file, while all other shown Issue fontforge#1811 reported that kerning information was lost when generatingĪn SVG file from a TTF from Google. If you export the GPOS table into a feature file and then remove the kerning pairs and merge the feature file back into the font, the font exports correctly.īut there is no format using the g1="." and g2="." specifiers. complex shinanigans we do in parsing feature files, but it's a lot easier / that either of our two "classes" will ever show again. In looking through the SVG output file, a comment sounds a little suspicious. In Font Info > Lookups > GPOS, both values have 45. If you look at View>Combinations>Kern Pairs for AV it has the value 0, but VA has the value 45. Once exported, the SVG contains kerning for VA with the correct value, but AV does not have any kerning. The 'kern' table will only be read if there is no 'kern' feature in 'GPOS'. This font contains both a 'kern' table and a 'GPOS' table. When you open the file in font forge, you get the warning:
When exporting a PT Sans to SVG, some hkern values are not generated.
0 kommentar(er)
