.woff2 sometimes bigger than .woff

[paolobarbolini]

Describe the bug

It looks like version 5 made some .woff files smaller in some cases, while .woff2 stayed at the same filesize, making them sometimes bigger than the .woff equivalent

Steps to Reproduce

1. Look at the size of the v4 release fonts (lato, roboto)
2. Compare it to the size of the v5 release (lato, roboto)
3. Lato went from lato-latin-400-normal.woff: 28.6k, lato-latin-400-normal.woff2: 23.6k to lato-latin-400-normal.woff: 17.4k, lato-latin-400-normal.woff2: stayed the same
4. Roboto went from roboto-latin-400-normal.woff: 20.3k, roboto-latin-400-normal.woff2: 15.7k to roboto-latin-400-normal.woff: 14.4k, roboto-latin-400-normal.woff2: stayed the same

While these tests are on 5.0.0 the same applies for 5.0.4

Expected behavior

I'd expect .woff2 to be smaller than .woff

Version

5.0.4

OS

Linux

Browser

Firefox

Additional context

No response

[ayuhito]

I don't have the bandwidth at the moment to investigate this properly but this should be related to this PR. I'm curious exactly what the WOFF files don't have in comparison to WOFF2.

Since we're targeting a very niche user-agent on Google's API, it's also likely they had a regression in terms of feature parity or language subsetting.

[alban-ameti]

Hi, just notice the same issue with font 'PT sans'

Here is an example screenshot of the size difference:

I have also looked at how the font faces are declared and I am little confused.

In the 400.css it's imported as:

/* pt-sans-latin-400-normal */
@font-face {
  font-family: 'PT Sans';
  font-style: normal;
  font-display: swap;
  font-weight: 400;
  src: url(./files/pt-sans-latin-400-normal.woff2) format('woff2'), url(./files/pt-sans-latin-400-normal.woff) format('woff');
  unicode-range: U+0000-00FF,U+0131,U+0152-0153,U+02BB-02BC,U+02C6,U+02DA,U+02DC,U+0300-0301,U+0303-0304,U+0308-0309,U+0323,U+0329,U+2000-206F,U+2074,U+20AC,U+2122,U+2191,U+2193,U+2212,U+2215,U+FEFF,U+FFFD;
}

In latin-400.css it's imported as:

/* pt-sans-latin-400-normal */
@font-face {
  font-family: 'PT Sans';
  font-style: normal;
  font-display: swap;
  font-weight: 400;
  src: url(./files/pt-sans-latin-400-normal.woff2) format('woff2'), url(./files/pt-sans-latin-400-normal.woff) format('woff');
}

Why is there a unicode-range in one and not in the other when they should both be the latin set?
Does that have anything to do with the size difference?
For example in the .woff is there only the latin characters whereas in the .woff2 we get all characters and therefore its bigger?

[ayuhito]

Why is there a unicode-range in one and not in the other when they should both be the latin set?

The subset-specific CSS files are a legacy artefact from when we supported users migrating from the Typefaces Project. The CSS is the same as their sources. But, I actually agree that we should include unicode-range in these files too since you won't be able to import multiple individual subsets if you need to without them overwriting each other.

Does that have anything to do with the size difference?

This is just a difference in CSS, leading to the same binary files. A little more digging into this indicates this is likely due to hinting for Windows machines included in the woff2 file whilst the woff file doesn't include that metadata.

---

This is the source metadata we use to package the binary files straight from Google's CDNs.

"latin": {
            "url": {
              "woff2": "https://fonts.gstatic.com/s/lato/v24/S6u8w4BMUTPHh30AXC-q.woff2",
              "woff": "https://fonts.gstatic.com/s/lato/v24/S6u8w4BMUTPHh30AXC-sNiXg7Q.woff",
              "truetype": "https://fonts.gstatic.com/s/lato/v24/S6u8w4BMUTPHh30wWw.ttf"
            }
          }
}

Loading these files into Wakamai Fondue confirms that they support the same number of characters. However, a closer examination of the individual glyphs reveals differences in rendering.

The change introduced in the related PR switches the user-agent to a Safari agent for woff. This change inadvertently removes the extra hinting data used by Windows, as Safari doesn't require it and the Google API dynamically serves unhinted and hinted variants of the same font depending on the user-agent. Thus the woff files end up being smaller than the woff2 files.

---

As for fixing this. I'm not sure how we should approach this. The PR to subset woff files specifically targeted the Safari user-agent as it had a short window where it did support unicode-range but it didn't support woff2, allowing us to fetch these files. It may make sense to experiment with the user-agent and see if it may be possible to generate subsetted woff files that does include Windows hinting, but otherwise, we may need to consider reverting back to the all variant or manually converting existing woff2 files that include Windows hinting down to woff.

[alban-ameti]

Is the hinting required in browsers on windows? I would prefer to have smaller font in the browser if the hinting is not being used anyway. Not sure if that is a good solution tho I know nearly nothing about fonts :)

[ayuhito]

Is the hinting required in browsers on windows?

It very much is or else the fonts render really badly on Windows machines specifically.

[alban-ameti]

Thank you for the replies and looking into this I really appreciate it.

[caass]

After some googling I just found this issue -- to make sure I understand:

1. This bug is due to how google-font-metadata splits .woff and .woff2 files up by each subset.
2. Specifically, after subset-splitting was enabled for .woff files with this change, subsetted .woff files had smaller sizes than subsetted .woff2 files.
3. Because the user-agent used for fetching those .woff files was Safari, the font served by Google Fonts didn't have hinting data. This made the .woff files smaller, at the expense of font rendering on Windows. As in, windows won't render .woff fonts correctly.

So while one of the symptoms of this bug is that fonts in .woff2 are bigger than their .woff equivalents, the actual bug is that the .woff files don't include font hints that are used in Windows due to how they are fetched from Google.

And it sounds like the potential solutions are:

1. Modify the user-agent used to generate .woff files to download files with font-hinting.
2. Reverting to the all variant when downloading fonts, instead of subsetting.
3. Translating downloaded .woff2 files with hints into .woff files.

Does that seem accurate?

[ayuhito]

Does that seem accurate?

@caass, that's a spot on summary of this issue!

Ideally, I would want to find a suitable user-agent that allows Google Fonts into giving us the correct hinted subsets since that is the safest option from a licensing sense (see 2.2 from this OFL FAQ) and also fixes the bug for users of the upstream google-font-metadata library too.

In hindsight, I think the all subset variant was the best to keep in the spirit of compatibility and simplicity, but I'm also not keen on making another breaking change since that is a very chaotic process.

I'm a little undecided on decompressing the WOFF2 files since I think it complicates a lot of facets of this project. I'll hold off on commenting on that until we're sure the user-agent approached can't be used.

cc; @rsheeter (if you may have a better idea of what user-agent might be appropriate to get around this)