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

[com.google.fonts/check/meta/script_lang_tags] Change to rationale #4408

Open
simoncozens opened this issue Jan 9, 2024 · 3 comments
Open
Labels
Check improvement proposal Five minute fix No discussion needed and practically a one-liner

Comments

@simoncozens
Copy link
Collaborator

simoncozens commented Jan 9, 2024

According to @verdy-p in notofonts/toto#4 (comment):

Note that Windows 11 now DOES uses and supports 'dlng' and 'slng' metata in its Settings>Fonts panel. Though there's a bug when it parses them: see MicrosoftDocs/typography-issues#1112

This is worth adding to the rationale, as it's potentially more important that fonts have a correct meta table if MS is going to start using them in the fonts panel.

(However, please also note that last we heard, there was also a bug in OS X's handling of fonts with a meta table which may make it better not to include the table until this is fixed...)

@simoncozens simoncozens added the Five minute fix No discussion needed and practically a one-liner label Jan 19, 2024
@verdy-p
Copy link

verdy-p commented Feb 24, 2024

Doesn't Google font provide different built packages for various platforms? Could there be a building profile added for some OSX versions, tracking its limitations (such as the bug on fonts with a metatable that they still don't handle correctly), or for Windows 10+ that will use the metatable as part of their UI, and probably soon as well in other Microsoft tools (including MS Edge for its font selection and fallback mechanism, that should require updates probably in Google Chromium and Google Chrome as well)?

Note also that now the Microsoft Typography documents each of its fonts with their "dlng/slng" metadata explicitly listed. So visibly this is already a good indicator that Microsoft chose that way, and legacy OS/2 tables and OpenType specific language/script codes will be progressively phased out (even if Microsoft is still adding some limited patches to them in the OpenType specifications for very few languages, much less than those discussed with "dlng/slng" metadata which have now a more extensive coverage).

This could announce a new way to make language/script-specific feature tables, using these BCP47 based dlng/slng codes rather than just the legacy OpenType language/script codes (and possibly an extension to Opentype specifications for the format of feature tables.

@simoncozens
Copy link
Collaborator Author

Doesn't Google font provide different built packages for various platforms?

... No, I don't think so. And I think we want to produce "good" fonts and put pressure on operating system vendors to get their bugs fixed.

@verdy-p
Copy link

verdy-p commented Feb 24, 2024

So you think about putting pressure on Apple, given that Google and Microsoft will work with these tables, and both will want to support users of Apple OS for their apps (e.g. office applications by Google and Microsoft) and their "tuned" web browsers (based on the Safari core, engine rather than Chromium core).

I had the feeling that there were separate "packages" for Google fonts (e.g. for different formats, with different OT outlines, or with/without hinting, or with different coloring options for Emoji-like fonts, or with smaller coverage for limited platforms).

Was the bug reported to Apple, is it being worked on?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Check improvement proposal Five minute fix No discussion needed and practically a one-liner
Projects
None yet
Development

No branches or pull requests

2 participants