Intent to Implement: Local Font Access API

[dhn...@chromium.org]

Contact emails

dhn...@chromium.com, owe...@chromium.com

Spec

https://github.com/DHNishi/LocalFontAccess

Summary

A Local Font Access API would give access to local fonts installed on a user's device. This enables the development of web apps for designers that need to access and manipulate the glyphs inside of fonts.

Motivation

In order to create apps for designers, developers need access to the raw font information to render fonts properly across all platforms and to manipulate the glyphs and their spacings inside. Most designers have fonts on their system which are not web fonts and are unlikely to become web fonts any time soon, due to licensing issues. As a result, these designers can only use native applications for their work, and the web is an unsuitable platform. By granting access to the font information directly, we resolve this issue while also avoiding situations like the faux bold controversy workarounds that the browsers use today.

Compatibility Risk

None of the other vendors have public signals for this new API. Some web developers have given positive feedback. Due to the small footprint of this API, risk should be low.

Ongoing technical constraints

Currently, this feature will be supported on Windows/Mac/Linux. Chrome OS is designed to make it very difficult to install custom fonts and requires that the user place their Chrome OS device into Developer mode to do so. The Android platform is currently not a target for these apps for designers with regards to typefaces, so we are not including it in the initial pass.

If a breaking changes between OS versions fundamentally changes how font access works, the implementation could need to change correspondingly. We expect the risk of this constraint to be low.

OWP launch tracking bug

https://code.google.com/p/chromium/issues/detail?id=535764

Link to entry on the feature dashboard

https://www.chromestatus.com/features/6173242628767744

[PhistucK]

Are you really from http://chromium.com/? :) You probably meant @chromium.org in the contact section.

If I remember correctly, Internet Explorer (or Flash, or both of them) used to ship an API (or an ActiveX add on) that exposed the list of fonts (without any permission). Perhaps just standardize this, if you wish to expose this.

Looks like the whole purpose of this API is to eliminate the work for the user to go to their font folder and drag the font into an <input type=file> (I just tested that with Windows 7, it works. Windows 7 just does not let you go to that folder in the file browsing dialog). This seems excessive to me, especially due to the relatively low usage this niche API will probably be getting.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Domenic Denicola]

Where is the spec? The link only goes to an explainer.

[Ilya Grigorik]

Any privacy implications to be discussed here? Seems like having an exact mechanism to traverse local fonts might leak some data.

[Owen]

The current plan is for this to require the user to grant the site explicit permission, significantly limiting the risk of fingerprinting.

And there isn't yet a spec for this, we wanted to explore the problem and see how a solution could look before going too deep into specifying it.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Owen]

I've done a bit of digging but can't find any reference to the IE API, do you by any chance have a link or reference?

 

Requiring users to manually browse to a fonts directory and upload all their fonts is not a solution as users wouldn't know how to find that folder and the UX would be terrible (even as a technical user I'm not sure how to do that). In terms of alternate solutions, I've been speaking with some developers building a design app on the web, who are currently planning to require their users download and run a local server which opens the fonts folder to the web, which is obviously not ideal. 

We think a low surface area API with an appropriate permission request is the real solution to this problem that will enable richer visual editing software on the web.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[PhistucK]

See -

http://stackoverflow.com/questions/3597682/how-to-iterate-the-installed-fonts-using-javascript

http://www.sitepoint.com/system-fonts-javascript/

There is a Flash method and there is an ActiveX method. Both of them do not require permissions, I believe.

☆PhistucK

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Alex Russell]

Glad to see this moving forward! +1

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Elliott Sprehn]

Can we get an API draft first? It seems hard to figure out if this should be implemented from the explainer, it doesn't really say how big.small this API is or how it works.

[Joe Medley]

Could you extend the font loading API? http://www.w3.org/TR/css-font-loading/

Joe Medley | Technical Writer, DevPlat | jme...@google.com | 816-678-7195

[Daniel Nishi]

Joe: The font loading API does specify that it is expected that it would extend to be able to query local fonts in the future. That API is mostly based around specifying fonts in CSS for layout purposes AFAIK, though. The use cases served by giving access to the font blob itself include being able to directly access the glyphs, allowing for layout consistent across all platforms.

Because the other API is mostly dealing with CSS font loading, I think it is okay to look at this as a new API, rather than an extension.

[Dominik Röttsches]

Hi Daniel, Owen,

On Fri, Sep 25, 2015 at 2:23 AM, <dhn...@chromium.org> wrote:

Motivation

In order to create apps for designers, developers need access to the raw font information to render fonts properly across all platforms and to manipulate the glyphs and their spacings inside. Most designers have fonts on their system which are not web fonts and are unlikely to become web fonts any time soon, due to licensing issues. As a result, these designers can only use native applications for their work, and the web is an unsuitable platform. By granting access to the font information directly, we resolve this issue while also avoiding situations like the faux bold controversy workarounds that the browsers use today.

Can you elaborate on the motivation and the problems you're trying to solve a bit more? What do you mean by "apps for designers", something like a desktop publishing app? And what do you mean by "This enables the development of web apps for designers that need to access and manipulate the glyphs inside of fonts."?

Working on fonts in Blink myself, I'd like to help but I'd like to discuss the approach. There seem to be two main problems you're trying to address.

1) Getting a list of locally available fonts

This is probably useful, with the fingerprinting risk discussed before. With site specific permissions, this might be okay. However, I agree with Joe who suggests to extend CSS Font Loading. I would suggest to design an API that's consistent with FontFaceSet of that specification.

2) Solving support for advanced typography by accessing font blobs and reimplementing font rendering in JS

"By granting access to the font information directly, we resolve this issue while also avoiding situations like the faux bold controversy workarounds that the browsers use today."

And, quoting from the explainer:

"Several solutions for handling the font blob exist today for web. We can use a JS library like FontKit or OpenType.js or C libraries (such as FreeType2) through Emscripten to inspect and rasterize the glyphs contained in the font."

I do not think reimplementing the full text, layout and font stack in JavaScript will be the solution here. Unfortunately it's not as simple as a character table and a linear sequence of rendered glyphs. In order to support complex text shaping, you need ICU for unicode character properties, HarfBuzz, Freetype, font table parsing just to name a few. Making things fast through word caching, font and glyph caching, rendering quality aspects like antialiasing, hinting etc. will be quite a headache to implement again in JS, especially since the font rendering user experience depends on matching the platform's look and feel. That's why achieving the same pixel-perfect rendering across platforms is actually not what the users expect.

In the layout team, we do realize that support for advanced typographic features needs improvement and we're working on that. I believe "Faux bold", as one example that you mention, will be addressed by implementing the font-synthesis CSS property. Also, I recently improved matching font-style and font-weight, which addresses additional font selection issues that we had. font-feature-settings probably already does some of the things you're interested in, and our support for that needs more testing and improvements, but in principle gives control over all OpenType typographic features.

The bottom line is, I do not believe that access to the binary font blob will "resolve this issue" as mentioned in your motivation. Instead, I am curious to hear which use-cases in detail are most important to you. Perhaps we can discuss how we prioritize and improve blink's font rendering towards those. I think we have a common goal in making web typography as good as what a designer finds in a native desktop publishing environment.

Dominik

[Matt Falkenhagen]

Just for reference, Chrome also has an extensions API for getting a list of fonts from the system:

https://developer.chrome.com/extensions/fontSettings#method-getFontList

[Daniel Nishi]

Hypothetically, if we were trying to make a page layout web app, we would need access to the complex font rendering aspects, such as text shaping, ligatures, kerning tables, etc, etc. Furthermore, these would need to be consistent across platforms for purposes of both sharing work and presenting work on different devices. We'd also need the ability to manipulate the rasterized glyphs in order to shape them to however we need.

One approach would be to support all of these advanced typographical features. Due to the complexity of fonts, a spec for supporting everything needed would be huge. Even if there was a spec, inconsistencies between the implementations between different platforms would be unacceptable for certain layout apps.

In practice, companies like Prezi have ported the parts they've needed to make their product consistent using Emscripten to fill the gaps (this also has the side effect of making their web product consistent with the native offerings which use the same libraries). Others have begun porting OpenType to JS. In order for these solutions to work, they need access to the binary font blob.

As far as I can see, having access to the binary font blob is the only solution which would provide the required consistency to avoid situations like this and to support existing users.

[Owen]

And just to close the loop on use cases:

We are specifically anticipating enabling web applications more like desktop apps like Adobe Illustrator and Sketch that have extremely high requirements for typography and as a core function within the app they are willing to invest in making it work.

[Elliott Sprehn]

Seems like this falls into the Houdini umbrella of primitives. This also seems like it should be owned by them and part of the CSS font loading API, not a new FontAccess object.

I don't think this is really ready to give a positive or negative signal to without more details on what kind of API this will implement. The explainer is vague, and it seems this should be socialized with other browser vendors too.

The broader goal of exposing more font data is great though. :)

[Dominik Röttsches]

Hi Daniel,

it'd be great if we could work on concrete issues instead of vague claims of "web rendering is inconsistent across platforms". Similar to Elliot who mentioned the Houdini initiative and exposing more font data, I'd suggest to identify a minimal set of primitives/APIs that are missing to achieve bringing layout applications with a high typography fidelity to the web.

In terms of breakages: So far, we've talked about the issue of synthetic bold, and - from the video, an issue with unsharp font selection, leading to differences in line breaking. These can be addressed without rewriting and porting the whole font and layout stack to JavaScript.

Such a migration to JS is highly inefficient: Loading and decompressing fonts into each renderer, redudant caches for layout, rendered glyphs, etc., potentially slow and memory-intense text processing in JS, etc. - a very heavy CPU and memory load for a mobile device.

Manipulating glyph shapes, one of the requirements you brought up, could probably be achieved by an API that returns an SVG path for a glyph for example.

One approach would be to support all of these advanced typographical features. Due to the complexity of fonts, a spec for supporting everything needed would be huge. Even if there was a spec, inconsistencies between the implementations between different platforms would be unacceptable for certain layout apps.

Which features, concretely, do you see missing in the CSS3 Fonts Module?

In practice, companies like Prezi have ported the parts they've needed to make their product consistent using Emscripten to fill the gaps (this also has the side effect of making their web product consistent with the native offerings which use the same libraries). Others have begun porting OpenType to JS. In order for these solutions to work, they need access to the binary font blob.

As far as I can see, having access to the binary font blob is the only solution which would provide the required consistency to avoid situations like this and to support existing users.

I still don't think this will reliably and efficiently address the requirements presented.

Dominik

[Daniel Nishi]

Concretely, here are a subset of the features that are required to bring the layout applications to the web:

A list of all fonts with their family name, style, and postscript name.

This should come with their standard metrics (i.e. height, ascender, descender, etc), as well as their underline location and thickness values

The actual glyph paths, rather than just an SVG. Also, the glyph advance widths, kerning values, and a way of getting the supported glyph ranges for any local font.

Lastly, we'd need to provide access to the advanced font features such as the hinting in the fonts (if provided), the ligatures, small caps (http://designforhackers.com/blog/small-caps-fake-vs-real/), colored glyphs (http://typography.guru/journal/windows-color-fonts/), and contextual alternatives (http://ilovetypography.com/2011/04/01/engaging-contextuality/).

Due to the large surface of required features and the depth of the font file types, I feel giving access to the font file blob is the path of least resistance.

Why do you feel that this solution will not allow web devs to "resolve the issue"?

[PhistucK]

On Thu, Oct 1, 2015 at 7:52 PM, 'Daniel Nishi' via blink-dev <blin...@chromium.org> wrote:

Why do you feel that this solution will not allow web devs to "resolve the issue"?

It will, but not in a "webby" way (opinions diverge here, of course). Some school of thoughts says that Web APIs should be granular (yet generic) enough so that a developer does not have to resort to "parsing" on their own.

The thing is that since you can already do that (drag the font to a file input), this API is taking a step forward that is too small to be justified, in my opinion.

By the way, even simpler - I just checked and using <input type=file webkitdirectory> (prefixed, baa), I can select c:\Windows\Fonts and it seems to give me all of the files. If the API only goes so far, it does not save a lot of user time or complexity.

(It even gives you the file name and the size of the file, which could be useful before loading the entire thing and parsing it)

☆PhistucK

[Alex Russell]

On Thu, Oct 1, 2015 at 9:52 AM, 'Daniel Nishi' via blink-dev <blin...@chromium.org> wrote:

Concretely, here are a subset of the features that are required to bring the layout applications to the web:

A list of all fonts with their family name, style, and postscript name.

This, or a rough subset of it, is the first half of the proposed API.

 

This should come with their standard metrics (i.e. height, ascender, descender, etc), as well as their underline location and thickness values

This isn't being proposed right now.

 

The actual glyph paths, rather than just an SVG. Also, the glyph advance widths, kerning values, and a way of getting the supported glyph ranges for any local font.

The goal here is to support 2 early classes of apps:

• Those that want to be able to reference local fonts in CSS (via the font list)
• Those that want to get access to the blob data for those fonts to do their own rendering

There are a lot of positions in the middle: custom rendering, the ability to get much finer-grained information about any particular font, etc. But for the folks who really need this in the short run those are both meaningful improvements on the status quo and they leave the other enhancements on the table for us to add in an incremental way (which is how we should work).

 

Lastly, we'd need to provide access to the advanced font features such as the hinting in the fonts (if provided), the ligatures, small caps (http://designforhackers.com/blog/small-caps-fake-vs-real/), colored glyphs (http://typography.guru/journal/windows-color-fonts/), and contextual alternatives (http://ilovetypography.com/2011/04/01/engaging-contextuality/).

Due to the large surface of required features and the depth of the font file types, I feel giving access to the font file blob is the path of least resistance.

Right, and that's what's being proposed right now.

 

Why do you feel that this solution will not allow web devs to "resolve the issue"?

On Thu, Oct 1, 2015 at 12:40 AM, Dominik Röttsches <dr...@google.com> wrote:

Hi Daniel,

it'd be great if we could work on concrete issues instead of vague claims of "web rendering is inconsistent across platforms". Similar to Elliot who mentioned the Houdini initiative and exposing more font data, I'd suggest to identify a minimal set of primitives/APIs that are missing to achieve bringing layout applications with a high typography fidelity to the web.

In terms of breakages: So far, we've talked about the issue of synthetic bold, and - from the video, an issue with unsharp font selection, leading to differences in line breaking. These can be addressed without rewriting and porting the whole font and layout stack to JavaScript.

Such a migration to JS is highly inefficient: Loading and decompressing fonts into each renderer, redudant caches for layout, rendered glyphs, etc., potentially slow and memory-intense text processing in JS, etc. - a very heavy CPU and memory load for a mobile device.

Manipulating glyph shapes, one of the requirements you brought up, could probably be achieved by an API that returns an SVG path for a glyph for example.

One approach would be to support all of these advanced typographical features. Due to the complexity of fonts, a spec for supporting everything needed would be huge. Even if there was a spec, inconsistencies between the implementations between different platforms would be unacceptable for certain layout apps.

Which features, concretely, do you see missing in the CSS3 Fonts Module?

In practice, companies like Prezi have ported the parts they've needed to make their product consistent using Emscripten to fill the gaps (this also has the side effect of making their web product consistent with the native offerings which use the same libraries). Others have begun porting OpenType to JS. In order for these solutions to work, they need access to the binary font blob.

As far as I can see, having access to the binary font blob is the only solution which would provide the required consistency to avoid situations like this and to support existing users.

I still don't think this will reliably and efficiently address the requirements presented.

Dominik

[Behdad Esfahbod]

I'm late to this thread, but wanted to add my few cents:

  - The explainer shows a very simplistic and unrealistic model for fonts.  In reality, specifying "Arial", "Regular" does not resolve in One Font Blob.  Font selection and fallback is a complex topic that no one has been successful putting into abstract APIs yet,

  - While there are efforts to port text shaping (ie. what HarfBuzz does) to the web (fontkit, opentype.js), they will *forever* be incomplete and inconsistent.  This is simply because HarfBuzz is used by Firefox, Chrome, and Android, and Jonathan Kew and I, plus many other knowledgeable people, have devoted the better part of the past ten years improving HarfBuzz.  It will be unrealistic to believe that a couple wiz JS developers can implement / port it all to JS / Coffee / whatever in their spare time in a few months / even years,

  - Adobe Illustrator was given as an example, I just want to point out that even Adobe is not big enough these days, to be able to afford to keep their text shaping engine up to date.  As a result, it's badly broken and have not seen significant updates for many years (over five for sure).  We are currently talking to them about just adopting HarfBuzz and fixing the problem once for all,

  - The two claims that 1) need access to local fonts, and 2) must layout exactly the same on all machines are in conflict.  Even "Arial Regular" is different from version to version of the same OS, or across operating systems.

  - It would be premature to run to add API for exposing font blobs, without having a clear roadmap of how this API is to be used.  That said, API to provide what CSS font families are available, can indeed be used in "feels-desktop" web applications.  Or better yet, a native font chooser widget accessible to web apps.

  - Here's a more "webby" proposal Ian Roth and I wrote a few years ago, you might want to check out (specially Mozilla's response):

  https://docs.google.com/document/d/151ZZAJVo2nysvBVAAjW_9cK02T5vWHy2sClNl2eXnsA/edit

Cheers,

behdad

[Owen Campbell-Moore]

Thanks for the thoughts!

I unfortunately don't know enough to chime in on the alternate proposal, but wanted to comment on "It will be unrealistic to believe that a couple wiz JS developers can implement / port it all to JS / Coffee / whatever in their spare time in a few months / even years".

Implementing or porting does indeed sound totally unrealistic, but I understand it could be realistic to compile to something like Web Assembly, at which point a JS-accessible version of HarfBuzz shares all of your work and fixes etc?

I'm also curious what you were thinking of by "a native font chooser widget accessible to web apps", once the user chooses a font would that expose a blob or something else?

Thanks

[Behdad Esfahbod]

On Mon, Jan 4, 2016 at 2:35 PM, Owen Campbell-Moore <owe...@google.com> wrote:

Thanks for the thoughts!

I unfortunately don't know enough to chime in on the alternate proposal, but wanted to comment on "It will be unrealistic to believe that a couple wiz JS developers can implement / port it all to JS / Coffee / whatever in their spare time in a few months / even years".

Implementing or porting does indeed sound totally unrealistic, but I understand it could be realistic to compile to something like Web Assembly, at which point a JS-accessible version of HarfBuzz shares all of your work and fixes etc?

Correct.

 

I'm also curious what you were thinking of by "a native font chooser widget accessible to web apps", once the user chooses a font would that expose a blob or something else?

No.  Wouldn't expose the blob, but app can use it in CSS.

b

[Dimitri Glazkov]

Just to emphasize the points raised in the discussion: it seems that there are pretty serious concerns raised here and they need to be resolved before proceeding. Please listen to Behdad and Emil -- they are the experts in this field.

:DG<