Seriously what the hell is #Safari or #WebKit doing, everything about this font says the advance width, lsb, rsb, and xmax are all zero. Why the hell does Safari insist on going "oh, 300 zero width characters? That's 88.9 pixels of whitespace."
Does anyone I know work on the font size of Safari/Webkit? Because this is *bad* and someone should fix it.
@karlcow load up https://pomax.github.io/Minimal-font-generator/small and enjoy an incredibly wrong title (Chrome and Firefox do the expectedly correct thing)
If you open the console and run TinyFontGenerator.generateFont(`A`) that'll give you the font in bas64 form.
Or you can even read through https://github.com/Pomax/Minimal-font-generator/blob/master/fontgenerator.js for the exact byte layout to verify it's spec compliant (at least in the "no really, this should be zero width" sense).
Happy to answer any questions.
@TheRealPomax I filed https://bugs.webkit.org/show_bug.cgi?id=316951
Thanks a lot for the extensive demo.
@karlcow thank you so much!
It sounds like there's synthetic styles getting added into the font though, though which... hopefully not?
weight/style/etc are all things that people should enable either by using variable fonts with axis control, or declaring multiple @font-face rules with the same family name but different "font-*" values. No @font-face-loaded font should get anything automatically added into it during parsing or as "CSS says X, we try to fake X" =S
@TheRealPomax synthetic bold. When a font doesn't have a bold version, the browser rendering engines create a fake bold of the font and it's where the issue is happening in WebKit. Hopefully this will be fixed soon, thanks to your discovery.
@ahmad is attempting a PR.
@karlcow @ahmad aye, but for font-face it shouldn't? If the font does not support bold, bolding the font should simply do nothing, rather than trying to load a synthetic bold version? There shouldn't be a need for synthetic bold/italic/etc when @font-face gets used.
I saw the PR, super exciting to see this getting fixed, I remember some folks ran into this all the way back in 2012, but I was a poor student with only a windows laptop at the time and barely any open source experience =D
@TheRealPomax @ahmad You may want to use https://drafts.csswg.org/css-fonts-4/#font-synthesis-intro
font-synthesis: none
@karlcow That should be the default, thought =)
If a font-face resource doesn't have bold/italic, any weight and style instructions that someone sets via CSS should simply "do nothing": as there is no font resource for that configuration, the resource that matches the most specific still-applicable set of values should end up getting used.
(No "just coming up with a typeface that designer never intended for" until and unless requested =D)
@TheRealPomax yes that would respect the author intent probably, but in the priority of constituencies users > web dev > implementers > spec. I guess with my webcompat hat, if browsers were reversing course on this, it would break a lot of pages and make many people… angry :)
I definitely understand your point, but I guess we are stuck with it. It's usually very hard to change a behavior which is deployed everywhere. And not many people even among web devs fully understand fonts (myself included, I will ask someone who knows better than me in the team).
@karlcow That's the thing though... Safari's kinda unique here. Most websites wouldn't be impacted unless they were Safari-only.
So really: would they be impacted at all? At least based on the last 15 years of font stuff I've been working on... probably not? If it's websites that worked in Chrome and FF and Safari, not using synthesized bold etc would make no difference at all.
(certainly not for any site using google webfonts, typekit, etc.)
Pomax
Karl Dubost