- From: Tobi Reif via GitHub <sysbot+gh@w3.org>
- Date: Thu, 12 Apr 2018 11:09:16 +0000
- To: public-css-archive@w3.org
> I think we could solve this ![yay](https://user-images.githubusercontent.com/80411/38673263-1cad880c-3e51-11e8-8ad4-37353a320b56.png) > I think we could solve this with a new descriptor inside @font-face that takes a raw number that represents the font ascent (and another one for descent). The raw number would be a multiplier on the used font-size. If present, the browser would use this number instead of whatever is in the font file. If that would completely solve the issue shown above using the various test-pages and in the various screenshots (eg https://tobireif.com/non_site_stuff/test_case_for_font_position_report_yet_another_font/ incl. the screenshots linked from that page) then I'd be happy, and I (and everyone else who's affected by the issue) could stop applying hacks. I think I'd prefer a simpler solution where no calculation or measurements are necessary on the part of the CSS user, eg `position-of-glyphs: consistent-across-platforms`, but to be frank I'll take *any* solution that's a complete and reliable cross-OS and cross-browser solution - and which will get implemented by all browsers 😀 A detail: With the solution you describe there's a risk that authors choose eg an ascent value that fits an "A" - but wouldn't fit an "Ä". With a simple property such as `position-of-glyphs: consistent-across-platforms` there'd be no such risk - the browser would ensure consistent glyph positioning across OSs and would be knowledgeable enough to not clip any glyphs. -- GitHub Notification of comment by tobireif Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2228#issuecomment-380767711 using your GitHub account
Received on Thursday, 12 April 2018 11:09:23 UTC