search

backdrop / backdrop-issues

Issue tracker for Backdrop core.
144 stars 40 forks source link

Cleanup OpenSans webfonts and get them up to date #6728

Open indigoxela opened 2 weeks ago

indigoxela commented 2 weeks ago

Description of the task

I'm not actually sure, how to label this issue... :wink: Recently I realized, that FireFox console nags about our OpenSans webfont:

downloadable font: Glyph bbox was incorrect (glyph ids 459) (font-family: "Open Sans" style:normal weight:400 stretch:100 src index:1) source: .../core/misc/opensans/OpenSans-Regular-webfont.woff
downloadable font: Glyph bbox was incorrect (glyph ids 441 459 695) (font-family: "Open Sans" style:normal weight:700 stretch:100 src index:1) source: .../core/misc/opensans/OpenSans-Bold-webfont.woff

Not a dramatic problem, but I had a closer look at the webfont core ships with (since 2015). Initially OpenSans was part of Seven, then moved to a generic library, but the fonts never got updated.

Additionally I discovered, that there are two empty files, OpenSans-ExtraBoldItalic-webfont.svg and OpenSans-Semibold-webfont.ttf.

We might want to start thinking over the types we provide:

Suggested change

Get fresh fonts, provide only .woff2 and .woff as fallback. Eventually .ttf as additional fallback, but that may not be necessary. Clean up opensans.css.

And this time take care that we don't ship empty (zero size) files again. :wink:

Additional information

quicksketch commented 2 days ago

This sounds like a great proposal. I'd love to fix that nag in the console, I've seen it from time-to-time as well.

indigoxela commented 2 days ago

I'd love to fix that nag in the console

Does anyone know, which glyphs 441, 459 or 695 are?

Anyway, here's a PR

We still ship with .ttf variants, but might also drop those. Or keep. I don't think, any browser will ever use them. Semibold is still there and still unused in core (not part of opensans.css). But it's no zero-byte-size file anymore.

quicksketch commented 2 days ago

Yeah, from the looks of things, we should be able to drop ttf as well. The 0.01% can use the fallback typeface.

I learned that woff2 is basically just a better compressed version of woff, so there's no problem using a converter. https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_fonts/WOFF

On Mon, Oct 28, 2024, 8:06 AM indigoxela @.***> wrote:

I'd love to fix that nag in the console

Does anyone know, which glyphs 441, 459 or 695 are?

Anyway, here's a PR https://github.com/backdrop/backdrop/pull/4892

  • Got latest version of OpenSans from Github
  • Converted woff and woff2 locally with a FontForge script
  • Removed outdated font types (ofl, svg) and updated opensans.css
  • Updated license and fontlog file according to new version

We still ship with .ttf variants, but might also drop those. Or keep. I don't think, any browser will ever use them. Semibold is still there and still unused in core (not part of opensans.css).

— Reply to this email directly, view it on GitHub https://github.com/backdrop/backdrop-issues/issues/6728#issuecomment-2441852822, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAYO3TGV54P2PD24I2K5STZ5ZAGZAVCNFSM6AAAAABPYZCBNCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBRHA2TEOBSGI . You are receiving this because you commented.Message ID: @.***>

indigoxela commented 1 day ago

from the looks of things, we should be able to drop ttf as well.

Done, removed ttf from opensans.css - but still kept the files. Or should I remove them, too?

woff2 is basically just a better compressed version of woff

Yes, more efficient, woff2 files for our webfont are usually ~20kb smaller than woff.

there's no problem using a converter.

The conversion happened from ttf to woff and to woff2 - FontForge can generate (compress) both variants. The download only contains ttf. I'm always using that tool for ttf-to-woff(2) conversion and never had any problems with it.

quicksketch commented 1 day ago

The conversion happened from ttf to woff and to woff2 - FontForge can generate (compress) both variants. The download only contains ttf.

That's a good reason to keep the TTF. That basically leaves a reference to the original files in the event that we need to reconvert them and allows the files to be checksum'd to see if there have been any changes in future updates. I think leaving the file in place but not including it in the CSS seems like a good combination.

quicksketch commented 1 day ago

I was curious what the CSS code looked like if you used Google Fonts these days, here's the CSS file used when clicking "Get Embed Code" from Google now:

https://fonts.googleapis.com/css2?family=Open+Sans:ital,wght@0,300..800;1,300..800&display=swap

The individual definitions look like this:

/* latin */
@font-face {
  font-family: 'Open Sans';
  font-style: normal;
  font-weight: 300 800;
  font-stretch: 100%;
  font-display: swap;
  src: url(https://fonts.gstatic.com/s/opensans/v40/memvYaGs126MiZpBA-UvWbX2vVnXBbObj2OVTS-muw.woff2) format('woff2');
  unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304, U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}

So that's interesting that it is exclusively use woff2. I think our woff/woff2 solution is perfectly fine.

I am not sure why Google is adding font-stretch: 100%, as that CSS property seems like it wouldn't do anything (it's the default).

I do think we should add font-display: swap; by default, that would make it so that Google Lighthouse would be happy when run against a Backdrop site and prevent a flash of invisible text. See https://developer.chrome.com/docs/lighthouse/performance/font-display/

indigoxela commented 21 hours ago

I do think we should add font-display: swap; by default...

Good idea, done.

quicksketch commented 21 hours ago

Looks good to me! GitHub Actions seem to be having a little slowness right now, but as previous PRs were all passing, this should too. I slated this for the 1.30.0 release.

I did see that there is a noticeable difference when using font-display: swap when the browser cache is disabled. It's pretty quick for me, but I could see using the swap as being both beneficial for people with slow connections and slightly annoying to designers. But it looks like our fallback font (Helvetica) is nearly identical in line-height, so the loading of the font causes minimal redrawing of the layout. Using "swap" is considered best-practice (by Google) though so I think we should stick with it.

quicksketch commented 20 hours ago

Here's a screencast showing the fallback from Open Sans to Helvetica:

Screencast from 2024-10-29 23-41-55.webm

This is only manually modifying the font-face. The initial page load is too fast for me to capture on video.

herbdool commented 12 hours ago

I tested it out and the FOUT is fairly minimal.

I've only just learned about font-display from this issue, but now I'm overwhelmed by choices. I was wondering if swap is the ideal option for slow connections.

https://css-tricks.com/almanac/properties/f/font-display/ describes the optional value, which will avoid downloading the custom font on slow connections:

optional: Like fallback, this value tells the browser to initially hide the text, then transition to a fallback font until the custom font is available to use. However, this value also allows the browser to determine whether the custom font is even used at all, using the user’s connection speed as a determining factor where slower connections are less likely to receive the custom font.

or the fallback value, as a compromise:

fallback: Acts as a compromise between the auto and swap values. The browser will hide the text for about 100ms and, if the font has not yet been downloaded, will use the fallback text. It will swap to the new font after it is downloaded, but only during a short swap period (probably 3 seconds).