- From: Dominik Röttsches via GitHub <sysbot+gh@w3.org>
- Date: Thu, 05 Mar 2020 12:24:47 +0000
- To: public-css-archive@w3.org
If we allow custom overrides, values, percentages, etc. I'd prefer to not have those placed as descriptors in `@font-face` but rather as new properties. I'd also be very supportive of a from-font value. I'd be even more supportive of not allowing custom value overrides, but only some form of keyword to indicate: "use sTypo* only" - in which case I'd be okay with having that as a descriptor in the `@font-face` header. Background for not placing overrides in `@font-face` are issues https://github.com/w3c/csswg-drafts/issues/2531 as well as my proposal in https://github.com/w3c/csswg-drafts/issues/4358. Placing overrides in @font-face is not supported in Chrome currently and architecturally difficult. We removed `font-variant` in the spec as an override, and I would be happy if we could remove other overrides there as well. @litherum if I am not mistaken in skimming through the code, WebKit [already has code for parsing several OpenType fields manually](https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/platform/graphics/opentype) (for `math` table, vertical layout metrics), as well as even for [sTypoMetrics](https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/platform/graphics/opentype/OpenTypeCG.cpp#L57) (but this may not be used when running on Mac OS). I do understand your preference to have CoreText handle metrics parsing, but wouldn't this be an acceptable case of accessing this data to enable a `from-font` keyword? Or alternatively, since you work closely with your CoreText colleagues, couldn't they expose the `sTypo*` metrics for you? -- GitHub Notification of comment by drott Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4792#issuecomment-595203087 using your GitHub account
Received on Thursday, 5 March 2020 12:24:49 UTC