1280163 - Allow to find glyphs within a font face

Status: NEW

(DevTools :: Inspector, enhancement, P3)

Description

[Sebastian Zartner [:sebo]]

As of bug 1247723 comment 0 the Font Inspector should have some UI for finding specific glyphs within a font file.

Sebastian

Comment 1

[Helen V. Holmes (:helenvholmes) (:✨)]

I did a bit of research yesterday about how it might be possible to complete this and thought it would be useful to complete it here:

I assume it's programmatically possible to pull out glyphs as InDesign is able to do it, as seen here: http://cl.ly/1I0x1b3i181B organizing them this way is great for discoverability, as the current implementation on Mac and Windows to see glyphs otherwise is to look through a character map of all the characters in the font instead of being able to just see the glyphs (either through character map or Font Book). http://www.myfonts.com/Article8099.html (The implementation for Mac in this article still assumes you're using software with a Font menu, which seems to be a menu that exists in proprietary software such as Photoshop and Illustrator but not universally across Mac programs.)

Assuming that the type designer has set up their font file in a way that's clean you should be able to pull out the `CFF` or `post` tables, as explained here: https://github.com/behdad/fonttools#the-ttx-file-format

Some other designers suggested that the snippets here might prove useful, although like the repo above, the examples are all in Python: https://github.com/behdad/fonttools/tree/master/Snippets

Comment 2

[Patrick Brosset <:pbro>]

Inspector bug triage (filter on CLIMBING SHOES).

Comment 3

[Jonathan Kew [:jfkthame]]

Actually, I think there are two somewhat separate things you might want to expose, as both are useful (in different ways):

(a) the repertoire of Unicode *characters* supported by a font

(b) the repertoire of *glyphs* in a font

And for (b), it would also be nice to show how a given glyph is accessed -- but be aware that this isn't always simple (contextual forms, ligatures, optional features, etc.), and may not be possible at all; or may have many answers (a single glyph that is mapped from multiple characters and/or features).

Comment 4

[Patrick Brosset <:pbro>]

Jut stumbled upon this JS font parsing library that looks totally awesome: https://opentype.js.org/glyph-inspector.html

Gabriel (:gl) and I recently discussed about this and said we might want to start looking into this soon.
Jonathan, what would an API doing a and b look like?

Comment 5

[Jonathan Kew [:jfkthame]]

What kind of thing would you want from an API? For (a), I can imagine an API on nsIDOMFontFace that returns a list of all the Unicode codepoints supported by the font -- either as a list of integers that you'd have to iterate over, or as a single string that lists them in some form such as "U+0020..007E,U+00A0..00FF,U+0123,U+0456" or something (similar to the unicode-range descriptor in @font-face). It would then be up to you to parse that into numbers or whatever you need.

(b) is harder, because it's not clear how to most usefully enumerate glyphs, nor what you can do with them once you have them. At the simplest level, we can tell you "this font has 1234 glyphs", in which case they have glyph IDs from 0..1233. But arbitrary glyph IDs aren't much use; there's no (current) API, AFAIK, that would enable you to render a glyph identified by its ID, though I think there was talk at some point of possibly adding that to canvas2d.

It might be more useful to have glyph names than just IDs -- but not all fonts provide glyph names, and if they do, they're not always user-friendly: while "dotlessi" might be useful, "afii54321" is probably less so to most users.

You'd probably also want to know "how do I put this glyph into a document", which will often be answered by "it's Unicode character X", but not always.... it might be "Unicode character sequence XYZ, if the Byzantine language system is in effect and features foo and bar but not xyz are applied, in a context where it's preceded by PQRS and followed by ABC". I'm not sure how feasible it is, in the truly general case, to figure this out and express it in a usable way.

So to do something about (b), I think we need some further discussion of exactly what the API is going to provide, and how that will be useful -- possibly including an extension to the canvas text API as well.

Another point of view, I guess, is instead of trying to start from the repertoire of glyphs, and work "backwards" to connect them to characters (and features) that could be used in a document, start with the repertoire of characters, and then for each character, provide a way to view all the alternate glyphs that could be used to display it (and what feature accesses each of them). This could work well for simple alternates (small caps, oldstyle figures, etc), but it's harder to visualize how it would deal with things like contextual alternates or many-to-many mappings.