Roel Nieskens

Nina Stössinger said:

What I’d find more interesting (does this exist?) is a color font format that would have the colors assigned via variables

The two color vector formats, COLR and SVG, will have this. You can put predefined palettes in the font and let the users choose from that. I'd imagine this working similar to choosing a weight or style: "Shiny gold", "Old silver", "Purple and pink", "Toxic green".

These palettes are stored in the CPAL table. On top of that, individual colors can be overwritten. If the "Toxic green" palette has four green fills a black outline, you could change the outline to pink and leave the greens intact. Or overwrite them all.

In COLR you'll have control over all colors like that, but in SVG the type designer can choose to hardcode colors and not allow them to be overwritten.

A big downside of the CPAL table is that everything is numbered, not named. So instead of being able to say "Pick the 'Toxic green' palette and overwrite 'outline-color'", you must say "Pick palette 17 and overwrite color 3". See Gluk's comment, who has read the spec more closely than I!

At least in CSS you can map (custom) palettes to human readable names.

Support for overwriting the CPAL table is not here yet, and current tools export all colors hardcoded for the SVG format.

Oh, and for the people who seem to be pretty mad about color fonts being an option: don't be. It's an optional thing that takes nothing away that you already have. It just add news tools to your toolbox, feel free to ignore the crap out of them.

(If you want to know more there's this guy talking about color fonts and the caveats mentioned above at TYPO Berlin.)

Regarding file size, I suppose that once you crossed the line where most point are more than 256 units apart, it doesn't really matter if you use a UPM of 2048, 4096, 8192, etc. The savings come from being able to use a single byte to store the point's coordinates, as opposed to a signed short, which is two bytes. A font with a 1024 UPM might have 50% of its coordinates stored as a short — say 25.000 points, which equals 50.000 bytes — but when "scaled" to 256 UPM they might all fit in a byte. That saved you 25Kb.

There's a silly experiment I did with a famous icon font that reduces file size in exactly that manner.

Oh, and get your rotten tomatoes ready: I think most webfonts would work perfectly well for screen with a low UPM like 256. The least that could be done is scaling the UPM as far down as possible by using the greatest common divisor for all coordinates.

I don't know, but there will definitely be videos inside glyphs during the event.

Serving your webfonts only in the WOFF and WOFF2 formats is maybe your best bet. As with all other options, people who know their stuff will be able to pirate them anyway, but the Average Joe won't be able to simply download and install them.

Thanks for the thorough answer, Thomas. Turns out the font was unhinted indeed. I didn't know how to determine that for CFF fonts, but your answer turned me in the right direction. Next on my todo: pull this font through a CFF autohinter to see the difference.

To clarify, I was looking at fonts used as webfonts in Internet Explorer, not in other apps.