Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fonts need to be sorted #23

Closed
jyasskin opened this issue Apr 29, 2020 · 5 comments
Closed

Fonts need to be sorted #23

jyasskin opened this issue Apr 29, 2020 · 5 comments

Comments

@jyasskin
Copy link
Member

https://wicg.github.io/local-font-access/#fontiterator says "For each local font font on the system", but if that reflects the order fonts were installed, it reveals a lot of fingerprinting information. The spec should say that the fonts are sorted by some key.

@inexorabletash
Copy link
Member

inexorabletash commented Apr 29, 2020

Mostly agreed... the challenge is that if we have a permission scheme and/or UX allowing full access, and were on an operating system where enumeration was inherently async, and the enumeration order was not aligned, this would require the implementation to do a full enumeration and buffer the results, do a sort, then provide the enumeration to script.

@jyasskin
Copy link
Member Author

Yep, sorting might remove the benefit of having FontIterator be async iterable, unless getting the synchronous font names in FontMetadata requires parsing.

@dbaron
Copy link
Contributor

dbaron commented May 27, 2020

This is also mentioned in w3ctag/design-reviews#399 (comment) (4th paragraph).

@oyiptong
Copy link
Collaborator

oyiptong commented Oct 5, 2020

Would like to talk a bit about sorting. While it does remove some of the benefits of FontIterator being async iterable, it exists a future where fonts can be async iterable and sorted, e.g. if system font enumeration data lives in an out-of-process cache and sortable.

As for which key to sort it with, I propose postscriptName. It is used on the web as a unique identifier for @font-face src: local matching.

Annecdotally, Apple systems deduplicate using that name table entry.
https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6name.html

Platform-specific Information
It is no longer recommended that fonts for use on macOS have PostScript names with the Macintosh platform ID and MacRoman platform-specific ID.

If two fonts are installed with the same PostScript name, Apple platforms treat them as duplicates and only one will be available for use.

Another convenient property of postscriptName is that according to the OpenType name specs, it is encoded in a subset of ASCII.

PostScript name for the font; Name ID 6 specifies a string which is used to invoke a PostScript language font that corresponds to this OpenType font. When translated to ASCII, the name string must be no longer than 63 characters and restricted to the printable ASCII subset, codes 33 to 126, except for the 10 characters '[', ']', '(', ')', '{', '}', '<', '>', '/', '%'.

This makes using this field as the sorting key ideal, as it will be the same across all locales.

This property combined with the fact that postscriptName can be used as a unique identifier, makes it an ideal candidate.

@inexorabletash
Copy link
Member

This is made explicit in the https://wicg.github.io/local-font-access/#dom-fontmanager-query algorithm now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants