- From: r12a via GitHub <sysbot+gh@w3.org>
- Date: Tue, 09 Feb 2021 17:01:47 +0000
- To: public-css-archive@w3.org
> As an aside, I'm not really convinced it's worthwhile to try and refine this stuff to such a degree. Fallbacks are just that: fallbacks. They may or may not even be available on a given user's system; you might end up with some other default/generic anyway. They aren't expected to render identically to the target webfont, no matter how many knobs we provide to tweak them. What follows may be a slightly philosophical point. I'm glad to see how the ideas here can also be applied to fallbacks related to web fonts, etc. I just didn't want to lose sight of my original problem, which was: There are very few Mongolian fonts, but pages on Windows will have guaranteed access to Mongolian Baiti, and pages on OS X will not have access to Baiti but will have access to Noto Sans Mongolian. The problem being that the metrics of these fonts on display are very different. So i just wanted a simple way to be able to say: If the browser is using Baiti, use these additional settings for font size, density, etc; if the browser is using Noto, use these other settings. So it's a use case that doesn't attempt to make the font look alike, but does attempt to produce something that takes up the same amount of space and works well for readability. In this sense, this is a slightly different kind of 'fallback' behaviour in that you actually pretty much know which font is likely to be used in which case. Solving that issue will be very useful for working with non-Latin fonts. -- GitHub Notification of comment by r12a Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/126#issuecomment-776088581 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 9 February 2021 17:01:49 UTC