Enumerate through all glyphs in font about fontkit HOT 6 OPEN

hb_input does that (for GSUB): https://github.com/googlei18n/nototools/blob/master/nototools/hb_input.py

from fontkit.

This is a very hard problem. It would essentially involve doing glyph substitution in reverse, from glyphs to characters instead of characters to glyphs. GSUB coverage tables may make this possible for opentype, but it would certainly not be easy especially when you consider the chaining substitution tables that are available. AAT uses state tables, so it would also be difficult if not impossible to go backward from matching states to the character sequences that might produce them. There may be an infinite number of combinations of characters that yield a single glyph.

from fontkit.

See http://github.com/devongovett/apple-color-emoji

from fontkit.

Played around with this a bit this weekend. See #60. It works for AAT-based fonts like Apple Color Emoji for now. You can try it out on that branch like this (I'll add a public API at some point). It returns an array of possible strings that would produce the given glyph.

font._layoutEngine.getStringsForGlyph(1039);
// => ['\u{1F468}\u200D\u{1F469}\u200D\u{1F467}\u200D\u{1F466}']

font._layoutEngine.getStringsForGlyph(730);
// => ['\u{1F3C3}', '\u{1F3C3}\u200D\u2642', '\u{1F3C3}\u200D\u2642\uFE0F']

Will probably update my apple-color-emoji package to use this at some point. Much easier to maintain.

from fontkit.

Thank you for this illuminating answer. Main reason why I wanted this feature was to extract all SBIX glyph PNGs and assign them their appropriate unicode name. I guess there should be other better ways of parsing the font in order to get those resources.

from fontkit.

You could mine the CMAP table data for that particular use case, since Unicode characters are unrelated to the visual changes that GSUB can effect. Find the coverage ranges, and run through the supported glyphs, resolving their glyph outline(s) one entry at a time?

from fontkit.