-
-
Notifications
You must be signed in to change notification settings - Fork 25
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
Parse font faces and consider font weight #53
Comments
Encountered this myself, funnily enough. Using Inter with weights 400/700, but Fontaine doesn't have a weight specifier so whilst it works for the body content, there are still significant layout shifts for headers. |
I've actually played with it and made it work locally, so can make a PR. @danielroe what do you think about this? |
@kilobyte2007 Would love that! |
+1 |
@sermagnus there is an open PR #264 and it works but it seems like it won't work like we expected it to work because capsize doesn't provide the metrics needed here. |
@kilobyte2007, what do you think of tweaking a PR in a way which would allow adding missing metrics on our own? I would love to be able to do that. It's certainly an extra effort without capsize providing these for us, but it has to be done only once :) |
Capsize is about to land support for character subsets other than basic Latin, e.g. Thai. The previous This overhaul is enabling us to expose metrics for different character sets, e.g.: import lobster from '@capsizecss/metrics/lobster'; // Same as today, latin regular
import { latin as lobsterLatin } from '@capsizecss/metrics/lobster'; // Same as today, latin regular
import { thai as lobsterThai } from '@capsizecss/metrics/lobster'; // New, thai regular Once this is done, we planned to look at modelling variants, following Google Fonts export const latin = {
familyName: 'ABeeZee',
category: 'sans-serif',
capHeight: 700,
ascent: 920,
descent: -262,
lineGap: 0,
unitsPerEm: 1000,
xHeight: 520,
xWidthAvg: 517, // latin regular (backwards compat)
xWidthAvgByVariant: {
"regular": 517,
"700": 537,
"italic": 527,
"700italic": 547,
}
} Still not settled on the naming ( The intention is that the lookup would be opaque, so when passing additional declaration properties, Capsize would use the correct metric when generating the fallback: const { fontFamily, fontFaces } = createFontStack(
[ lobster, arial ],
{
fontFaceProperties: {
fontWeight: 700,
fontStyle: 'italic'
}
}
); Hope that adds some clarity to our direction. |
@michaeltaranto We would prefer to have access to the underlying metrics rather than using the |
@danielroe Yeah they would be available on the metrics to lookup, as mentioned there's bike shedding to happening. I have been wanting to come back to Capsize 🤝 Fontaine, as I think you may be able to use the |
That would be amazing! |
🆒 Your use case
Sometimes we have this setup:
When fontaine is parsing the font-face it creates the override/fallback font-face without accounting for the weight.
🆕 The solution you'd like
We should probably add weight parsing, we should just probably parse it with regexp and add it on the created weight/override.
Expected result would be:
🔍 Alternatives you've considered
No response
ℹ️ Additional info
No response
The text was updated successfully, but these errors were encountered: