Fully support weight and unicode-range in @font-face declaration
#11248
Conversation
🎉 Snyk checks have passed. No issues have been found so far.✅ security/snyk check is complete. No issues have been found. (View Details) ✅ license/snyk check is complete. No issues have been found. (View Details) |
✅ PR preview is ready!
|
weight and unicode-range in @font-face declarationweight and unicode-range in @font-face declaration
frontend/app/src/components/FontFaceDeclaration/FontFaceDeclaration.tsx
Outdated
Show resolved
Hide resolved
|
In the font tests, firefox and webkit don't show the collapse icon for the sidebar. 🤔 |
frontend/app/src/components/FontFaceDeclaration/FontFaceDeclaration.tsx
Outdated
Show resolved
Hide resolved
frontend/app/src/components/FontFaceDeclaration/FontFaceDeclaration.tsx
Outdated
Show resolved
Hide resolved
| { | ||
| "family": "Chimera", | ||
| "url": "./app/static/NotoSans-only-letters_and_numbers.woff2", | ||
| "unicode_range": "U+0000-0040", | ||
| }, | ||
| { | ||
| "family": "Chimera", | ||
| "url": "./app/static/SourGummy-Normal-Variable.ttf", | ||
| "unicode_range": "U+0041-10FFFF", | ||
| }, |
There was a problem hiding this comment.
question: Is it expected that we are trying to load in 2 more fonts with family names that do not match the underlying font file? Also curious since I see that expect_font(app, "Chimera") is failing in CI
There was a problem hiding this comment.
Yes. This particular test case is building a font that cherry-picks different characters from different files. In this case, it uses numerals from NotoSans and alphabetic characters from SourGummy. This just happens to be an example where I can visually see that it correctly limited itself to the indicated unicode range and might not be indicative of the typical use case.
|
@sfc-gh-dmatthews Just to double-check, the usage here would look like this, correct? [[theme.fontFaces]]
...
weight = "100 900"
unicodeRange = "U+0025-00FF" |
|
@jrieke Yes. The following entries would all be valid: For unicode range: Separately, in another PR down the road, we could also update the default font declarations to accept a string or list of strings in the same way as we allowed the dual type for weight. (When setting the default font, you can specify a list of fonts to use as fallbacks. Currently, this must be one long string, but I thought people might naturally try to enter it as an actual list in TOML, so we could offer that as a convenience. |
weight and unicode-range in @font-face declarationweight and unicode-range in @font-face declaration
This reverts commit 5e40f40.
| const { family, weight, url, style = "normal" } = font | ||
|
|
||
| const { family, weight, stringWeight, url, style, unicodeRange } = font | ||
| const resolvedWeight = weight || stringWeight |
There was a problem hiding this comment.
nit: I think we might want to give stringWeight priority since its the newer option and weight is only the fallback for compatibility reasons: stringWeight || weight
There was a problem hiding this comment.
Maybe also add a comment here that the integer based weight is used as fallback here for compatibility reasons.
There was a problem hiding this comment.
LGTM 👍 I added a couple more comments. In general, I don't really like that we likely need to support two properties for weight long term. But there might not be a good alternative. We could maybe break with our compatibility guideline and change to string. This might work, but would need a bit more testing to see if it would break something in SiS.
Co-authored-by: graphite-app[bot] <96075541+graphite-app[bot]@users.noreply.github.com>
Describe your changes
Currently, when declaring a font in
[[theme.fontFaces]]inconfig.toml, theweightfield is interpreted as an integer andunicode-rangeis not supported at all.This PR supports declaring weight by keyword ("normal", "bold") as well as declaring weight ranges for variable font files ("100 900"). Additionally, this adds support for unicode range. This may be beneficial if a font is broken out into different files (e.g. basic and extended latin characters) and can be helpful for localization. Even if an app developer doesn't explicitly localize their app, they can define character sets for other languages that will only conditionally load if someone uses a browser extension to translate the page, for example.
GitHub Issue Link (if applicable)
closes #11163
closes #11247
Testing Plan
Contribution License Agreement
By submitting this pull request you agree that all contributions to this project are made under the Apache 2.0 license.