Local Font Access API

[janileppanen]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Local Font Access API
• Specification or proposal URL: https://wicg.github.io/local-font-access/
• Caniuse.com URL (optional): n/a
• Bugzilla URL (optional): n/a
• Mozillians who can provide input (optional): @heycam, @jfkthame
• W3C Tag Design Review issue: n/a

Other information

Adobe is interested in using local font access in web-based authoring workflows.

[annevk]

I have a couple of design concerns, but overall it seems like this is something that can be made to work. I filed them at https://github.com/WICG/local-font-access/issues which also lists other valuable input.

[inexorabletash]

We'd appreciate another look, if @annevk or anyone has cycles. The proposal has changed a bunch since 2020, including simplifying to eliminate assumptions about the structure of font data.

[annevk]

Thanks for letting us know about the update!

Some thoughts:

• The Permissions integration seems flawed: Permissions query() should not spawn UI WICG/local-font-access#84.
• The Goals section lists Workers, but is alone in doing so. (Perhaps FontData or the result of the query should be serializable?)
• Font serialization variations WICG/local-font-access#81 seems quite concerning. Ideally web developers would get the same data regardless of OS or UA. I could see it differing per OS perhaps (also because the font types might differ), but UA does not seem acceptable. (Given that issue I'm not sure what exactly got simplified since last time, since I recall there was a similar problem then.)
• Having said that, essentially websites will have to reinvent font parsers and more across all the various font types, just like browsers will have to continue to do. In the abstract this seems like a lot of wasted effort and the draft doesn't really detail the trade off made here.
• Even with the rather limited API it doesn't clearly define across a range of font types what each of the fields has to return. E.g., as detailed in Clarify and extend behavior around names in the FontMetadata object WICG/local-font-access#69 to some extent.
• https://wicg.github.io/local-font-access/#privacy doesn't indicate that the locale is also potentially exposed through the font name (although it seems there are also several unresolved issues regarding that).

Hope that helps.

[inexorabletash]

Quick responses, in bullet order:

• Re: Permission integration - should be fixed.
• Re: Workers - Worker support is definitely desired by partners, but adding it to the spec is pending figuring out the permissions story. And maybe that's actually easy to spec/implement, I just need guidance. I added an additional issue capturing FontData being serializable, which is a great short term idea, pending solving the permission-in-a-worker problem. (The Blob could be sent of course.)
• Re: Serialization - In the the notes in that issue I was probably being too general; we're not expecting that UAs perform any normalization. Here's what I wrote on a blink-dev thread:

The spec text is currently agnostic about what happens. It could be made more forceful, e.g. that UAs are not required to normalize data, and that consumers of the API should code defensively.
Folks that chimed in on the issues represented the spread of thoughts, from not wanting to assume anything about fonts (which would preclude future innovation) to considering a lack of normalization a flaw, even for image uploads. I haven't had a chance to respond in detail. "Normalization" could imply many things, from rearranging elements within general container formats (e.g. JFIF marker segments for images, SNFT tables for fonts, MP4 data streams and captioning for audio/video) to dropping elements (e.g. EXIF metadata in images, COLRv1 or Variable support in fonts, text captions from video) attempting to transcode (e.g. lossily converting an SVG image to a PNG, or SVG font to OTF). The consumers of the API, on behalf of users, expressly do not want to lose fidelity of the fonts, so that designers creating content have access to tools as powerful as native.

@slightlyoff followed up with:

Normalisation isn't usually a goal for users that want the actual bytes of the local font in order to do the rendering themselves and can be an active non-goal given the ways that folks want to do custom grouping, enumeration, and rendering. Partners have consistently asked us not to remove information and I've never heard of a request for normalisation from a partner.
This is in line with not adding OTS sanitisation for these files (we don't need to when the OS rendering pipeline isn't at potential risk), and highlights the way that the current design is isomorphic with local file access.

... and I have a PR to add a non-normative note to help clarify. Again, UAs should be permitted to do normalization, but I don't expect most would.

• Re: reinventing font parsers - the web developers requesting these features are typically using off-the-shelf parsers (often HarfBuzz/FreeType). It's true that this is duplicating the functionality in browsers, but just as we have Canvas for places where declarative content is insufficient for all use cases, for advanced creativity apps this is key to the functionality they offer to users. Many are already doing this, and the limiting factor is access to the fonts. I'll single out Figma here, which has an Electron-based application as well as a browser-based version; for the browser-based version they offer a local web server users are encouraged to install to give access to local font data. These applications are typically large, and the size of the text shaping engine is a small fraction. It might be ideal if the web offered the full set of typographic primitives these applications need, but that wouldn't mitigate the need for this functionality. Would it help to include more text like this in the spec to outline the use case?
• Re: fields across range of font types - advice welcome! Currently our implementation in Chromium defers this to the OS's font enumeration API (DirectWrite, CoreText, FontConfig), so for the spec I was attempting to describe the behavior more abstractly. Guidance on bridging that is welcome. It may be that I should have less normative text?
• Re: locale - I added a note about this, agreed there's work to do. The spec text is also somewhat aspirational; since I expect most implementations to defer enumeration to the OS, and OSes vary in what is returned. I need to add a note about that to the spec.

[annevk]

Again, UAs should be permitted to do normalization, but I don't expect most would.

Why should they be permitted to do so? How do you avoid a race-to-the-bottom?

---

For font parsers, if browsers exposed their font parser somehow, couldn't FontData be much more specific than a Blob? (And at the same time potentially less leaky of extraneous data.)

---

As for font fields, leaning even more into the abstraction might be okay yeah. E.g., making the OpenType thing an example if that is something that is expected to be provided by the OS (a browser that is also the OS might still have to implement it I suppose, but that seems reasonably out-of-scope).

[inexorabletash]

Re: Normalization - I guess I'm just thinking of specs differently - providing room for UAs to innovate if needed. But it also makes sense to have the spec as strict as possible, and the spec can be revisited. Anyway, non-normative text was added to clarify that UAs are not expected to normalize. If you think that should be stronger, e.g. a normative statement that UAs must not normalize, please let me know. Help is welcome!

---

Re: Parsers - this is where we started our exploration. In Chrome's normal text stack implementation, we treat fonts as untrusted data (e.g. web fonts), decompose fonts into tables and perform validation before feeding them into OS APIs or browser-bundled libraries, and thought about exposing these tables via the API. As noted above, though, existing libraries want to consume whole font files. There's been some exploration of exposing text shaping primitives - e.g. could the HarfBuzz/FreeType APIs just be exposed to the web? (Our experience with WebSQL tells us this would be a bad idea.) Exploration here eventually converged with the Canvas Formatted Text proposal as a higher-level API that solves needs for some web apps that would still rely on browser-based shaping. But this is not sufficient for all design tools.

---

Re: Font Fields - I took your advice and made the OpenType mapping a non-normative example. Thanks!

[annevk]

Yeah, lack of normalization makes sense. I don't necessarily object to normalization, but if it's going to be done it has to be specified and implemented across implementations as otherwise developers will run into subtle issues.

I suspect this will still benefit from review by font experts, such as @jfkthame.

[pranayaggarwal]

Hi @annevk , any updates / status on this request?