Bug 1672842 Comment 6 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

I suspect we'll want to create a new subclass of gfxFontEntry (and family) records for the macOS system font(s), and handle them separately from the main font list where we rely on names as the primary identifiers of families & faces. We can no longer get away with looking up what (hidden) font name `-apple-system` needs to resolve to, and then treating it the same as a normal (user-visible) font.

An alternative form of font identification will need to be plumbed through to everywhere that fonts are handled/instantiated; e.g. we presumably won't be able to use the postscript name as the thing we serialize and send to webrender, as it will fail to resolve to the required font on the WR side.
I suspect we'll want to create a new subclass of gfxFontEntry (and family) records for the macOS system font(s), and handle them separately from the main font list where we rely on names as the primary identifiers of families & faces. We can no longer get away with looking up what (hidden) font name `-apple-system` needs to resolve to, and then treating it the same as a normal (user-visible) font. Likewise for font styles returned by the widget code for "native" look-and-feel: we can't use name-based font entries to track these any more.

An alternative form of font identification will need to be plumbed through to everywhere that fonts are handled/instantiated; e.g. we presumably won't be able to use the postscript name as the thing we serialize and send to webrender, as it will fail to resolve to the required font on the WR side.

Back to Bug 1672842 Comment 6