Making Cloud.typography Faster | Hacker News Reader

Making Cloud.typography Faster

csswizardry.com

79 pointscsswizardry21 comments

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?

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.

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.

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.

That trick of marking a stylesheet for print media use only, and setting it for use with all media only after it is fully loaded, is very clever. Worth the read for that little gem alone.

Neat, huh? :D

Great write-up on this topic. in the demo video near the bottom can you make the links to those each available. I tried to go to https://csswizardry.dev/typography.com/fixed.html and am getting a page that says "sneaky" I was hoping to run these demos locally to really see the magic firsthand.

~~Hey! OP here. I’m currently sat on a flight so I’ll try my best to push it back live. N.B. At some point, my client will de-whitelist my csswizardry.dev domain from their Cloud.typography account and these demos will stop working.~~

UPDATE: I’ve had to go the opposite way and pull the whole lot. It outs my client and I really don’t want their name against anything. Email me and I’ll fire you a private demo.

john @ curtisdigital.com , thanks and have a good flight!

I love harrys posts, you can tell he really knows this stuff inside and out (plus we share an uncommon name). That font pop-in does such suck and I can see some execs agreeing that the extra time is worth the cost. I agree that the initial rendering being faster would be much nicer.

Thanks, Harry!

Side note: This was really hard to read for me. The font was way too thin. Any vertical lines get smeared across three horizontal pixels (I assume because of subpixel AA) making everything thin and hard to parse. This is the second or third site I've seen this happen on, I wish I knew why.

You’re not the first person to mention this—I’m sorry. Does font-weight: 400; on the body copy help? (Sorry to make you do the legwork but for me the type is perfectly legible as it is, so I need someone else to verify.)

It does, a lot - https://imgur.com/o4cE1id

For reference, I'm on Chrome, Win 10. The above image is at 125% zoom in Chrome, magnified 16x to see the pixels. I don't mind testing though, this helps me a lot - now I know what property to change or suggest if I see another site that does this to me.

font-weight:400 made this readable for me as well.

The best thing monitor manufacturers even did was see 4k monitors to designers.

I only run 1440p, though on a very nice monitor. In a couple of GPU revs I'll pick up a nice 4k.

Ohh wow. That’s night and day. Thanks for the feedback. I’m on it.

Removing the font-weight:300 and color:#333333 rules both improved the readability for me. OS X, Chrome.

And hey, as someone with aging eyes? Thanks for looking into this.

Not showing anything for 1.5 seconds is considered acceptable?

s/acceptable/an enormous improvement

From the article, wihch presumably you read:

> Yes, we do have a FOFT, but we are getting text in front of the reader much, much sooner—this is an enormous improvement.

Emphasis mine.

Reply on news.ycombinator.com