search

mozilla / standards-positions

https://mozilla.github.io/standards-positions/
Mozilla Public License 2.0
639 stars 69 forks source link

Local Font Access API #401

Open janileppanen opened 4 years ago

janileppanen commented 4 years ago

Request for Mozilla Position on an Emerging Web Specification

Other information

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

annevk commented 4 years ago

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 commented 2 years ago

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 commented 2 years ago

Thanks for letting us know about the update!

Some thoughts:

Hope that helps.

inexorabletash commented 2 years ago

Quick responses, in bullet order:

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.

annevk commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

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

danielhjacobs commented 4 months ago

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

Anne left Mozilla in July 2022 and is now working for Apple.

That said, while this is not a Mozilla-related topic, I'm also wondering Anne's opinion on this from WebKit's perspective: https://lists.webkit.org/pipermail/webkit-dev/2022-April/032176.html