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

Kiva fonttool weight constants don't match OpenType and CSS specs #908

Closed
corranwebster opened this issue Mar 11, 2022 · 2 comments · Fixed by #918
Closed

Kiva fonttool weight constants don't match OpenType and CSS specs #908

corranwebster opened this issue Mar 11, 2022 · 2 comments · Fixed by #918
Milestone

Comments

@corranwebster
Copy link
Contributor

The names of the weights are defined here: https://docs.microsoft.com/en-us/typography/opentype/spec/os2#usweightclass

But these don't match the names defined here in all cases:

weight_dict = {
"ultralight": 100,
"light": 200,
"normal": 400,
"regular": 400,
"book": 400,
"medium": 500,
"roman": 500,
"semibold": 600,
"demibold": 600,
"demi": 600,
"bold": 700,
"heavy": 800,
"extra bold": 800,
"black": 900,
}

For example "light" is 300 in both specs, but 200 in the constants file.

This is likely to result in mis-matches in font queries because FontEntry objects have the wrong value.

Fixing this may require bumping the font database version and re-generating the font database.

There is a potential tension here because the constants are used for scoring closeness of match, but are also used for interpreting the contents of font files.

@corranwebster
Copy link
Contributor Author

There is one fortunate feature that the font weights are not being used heavily by the higher-level code right now - the only values that the querying code sees are likely "normal" and "bold" which are mapped correctly.

@corranwebster corranwebster added this to the 5.3.0 Release milestone Mar 11, 2022
@corranwebster
Copy link
Contributor Author

Also, this is entirely backend code - these names are used for matching font names to font queries, but font queries are not really end-user exposed, so I think that updating this list to be more inclusive and correct is fine. It should silently make font matches better where it matters, and won't break end-user code.

The only possible end-user breakage is if there is something that was matching before and now doesn't, but because only "bold" and "normal" are really exposed, we should be fine on that.

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

Successfully merging a pull request may close this issue.

1 participant