4 ms·

Awesome post. I worked with cloud.typography for a client once too, and was surprised to discover that they shipped two base64-encoded data strings for each fon

Awesome post. I worked with cloud.typography for a client once too, and was surprised to discover that they shipped two base64-encoded data strings for each font, each one containing only one half of the font's glyphs – that is to say, their CSS had two @font-face rules for each font: one that had the data for e.g. A-M, and the other that had data for N-Z. The `font-family` rules of the body text specified both FontA and FontB, leaving the browser to piece the font together. Of course, this made extra bloat in the base64 string, because it's essentially two encoded font files instead of one. I assumed this was for anti-DRM / licensing purposes, so that if someone tried to download the font shipped to the client, they wouldn't get the whole alphabet (even though it's fairly trivial to stitch fonts together – you can use FontForge to copy/paste glyphs from one font to another). Do you know if they still ship fonts with a split alphabet?

jfk13 7y ago
This is a terrible idea, and I wish sites/foundries would abandon it. For fonts with features like ligatures or kerning, it'll break these when the adjacent glyphs that should interact happen to come from separate sub-fonts. But even for simple fonts that don't have any such features, it can result in terrible rendering because it's possible the font rasteriser (e.g. freetype), which sees the two parts of the font as completely independent entities, will end up applying hinting in quite different ways based on separate analysis of the disjoint glyph subsets. I've seen real-world examples where the end result is that half the glyphs "snap" to one x-height value, and the other half (from the other sub-font) snap to a value that's a pixel taller or shorter. The font rasteriser has no way of knowing that it should have auto-hinted "globally" across the two separate resources.
- crazygringo 7y ago
  Son of a gun. I've actually seen that before (the different x-heights) and, debugging it, couldn't figure out what the heck was going on. And it was with one of those split-into-two-fonts thing. So that definitely is real. Thanks for finally solving the mystery for me years later.
csswizardry 7y ago
It’s all paranoia all the way down, I’m sure. There can be no other explanation for such convoluted implementations. That said, I do sympathise. If your entire business/career/life is fonts, and all of a sudden they’re one ‘right click » Save as…’ away, I’d be panicking, too.

jfk13 7y ago

This is a terrible idea, and I wish sites/foundries would abandon it. For fonts with features like ligatures or kerning, it'll break these when the adjacent glyphs that should interact happen to come from separate sub-fonts. But even for simple fonts that don't have any such features, it can result in terrible rendering because it's possible the font rasteriser (e.g. freetype), which sees the two parts of the font as completely independent entities, will end up applying hinting in quite different ways based on separate analysis of the disjoint glyph subsets. I've seen real-world examples where the end result is that half the glyphs "snap" to one x-height value, and the other half (from the other sub-font) snap to a value that's a pixel taller or shorter. The font rasteriser has no way of knowing that it should have auto-hinted "globally" across the two separate resources.

crazygringo 7y ago
Son of a gun. I've actually seen that before (the different x-heights) and, debugging it, couldn't figure out what the heck was going on. And it was with one of those split-into-two-fonts thing. So that definitely is real. Thanks for finally solving the mystery for me years later.

csswizardry 7y ago

It’s all paranoia all the way down, I’m sure. There can be no other explanation for such convoluted implementations. That said, I do sympathise. If your entire business/career/life is fonts, and all of a sudden they’re one ‘right click » Save as…’ away, I’d be panicking, too.