[Feature Request] Make Italic variant, not just Oblique

[dayfuaim]

Please, make the Italic style, not just Oblique (like now).

Oblique style is not much distinguishable from upright (Normal).

[eweracs]

I am happy to work on optically corrected obliques, as I am working on an algorithm to accomplish this.

Top: Pure slant
Bottom: Algorithmic optical correction

You can find my contact on my website.

[qinyiyao]

We’ve actually considered this before and ultimately decided against it for a few reasons:

• We tried and couldn’t make that much visual distinctions with a Grotesque sans-serif font, particularly with this font’s design direction and only at an -6 angle.
• The font's top priority is TikTok mobile app UI typesetting, which has very limited use for Italics and Obliques, so there’s little priority. As for making fine optical adjustments to the existing Oblique styles, that’s even less worth the trouble, but we can consider it in the future.
• The font takes drastic measures to reduce file size. (4 axes and still under 1MB! We don’t even have Text masters on the Width axis.) The Slant axis is sparsely defined and relies on corner-space interpolation for simple letters. Having a true italic style would require discrete masters in a separate file per Google Fonts’ specs, which would double the file size, prevent animation, and complicate installation.
  • The ideal way to use it is to actually create a subset font without the slant axis then skew it on the fly, but most typesetting environments have trouble with that, so we had to keep this axis in the font.
  • I’m hoping for OpenType 2 to allow flexible on-the-fly synthesis of outlines, maybe also even automatic grade adjustments (which we also dropped to save on file size), but that’s in the far future.

Although if we continue to see more reasons for it then we'll add them to our consideration!

[eweracs]

What file size optimisations are you talking about? Currently, there are more than 10k kerning pairs per master, which is extremely excessive and can already be remedied by fixing spacing problems like in /lslash and /ldot. That is the first place I would think of when optimising file size. Furthermore, there are lots of glyphs that could, or rather should, be composed from components, instead of as paths. That reduces file size considerably as well.

Why was an angle of 6 degrees picked? Indeed that is almost negligible, visually speaking. I would expect at least something around 10 degrees for it actually to be worthwhile.

762kB is not particularly small for a 4-axis VF, especially considering it only has 12 masters.

Overall, I don't see an argument against adding properly designed italic masters if it's about file size. There are much more important places file size can be optimised.

[qinyiyao]

@eweracs Haha oh yes, we tried to squeeze kerning as well, but it was ultimately more trouble than its worth:

• Most of those kerning pairs are generated with Kern On, which generates kerning data up to a fixed file size. Dropping everything below 8 units only yielded ~8KB. On the other hand, the Kern On workflow is so much more valuable to keep in place to allow faster iterations, so we made a trade-off to keep a convenient automatic workflow at the cost of perfect design abstraction.
• When we get to OT2, kerning should be handled through a font's own wasm code, so I'm also banking on an algorithmic typography future.

For components, you are absolutely right! We are not nearly using components as much as we can and it should get more attention in the next round.

As for the -6 slant angle, I'm going to assume that it was picked mostly because it looks pretty cool without causing too much optical distortion, so it's more effective as an aesthetic choice than semantic emphasis (which has limited usage). If we have an optically corrected design, it should probably get a larger range just for more design flexibility. This also comes down to workflow agility: the entire Slant axis is handled procedurally outside of Glyphs, allowing for much faster iteration cycles (which was important for us). If we design optically corrected obliques, it would require putting outline data in the Glyphs file while carefully maintaining procedural code in the build pipeline, adding complexity and fragility to the process.

The biggest file size squeeze we got is having fewer masters. It will easily go over 1MB if we have full design space coverage! Overall, I made many decisions to deliver more business value at the cost of the font's design coherence. usually one would not design a font this way, but boy did it work well for TikTok. :D

I do really like where you are going with algorithmically correcting oblique letterforms! Have you considered turning it into a library outside of Glyphs so it can be integrated into procedural generation processes like this one?

[eweracs]

First off, I admit I'm surprised by how well you know the inner workings of fonts and font production. Sorry, I initially read you were a product designer and it didn't register with me that you have extensive font production experience as well. So, apologies if I'm mis-gauging the level at which I should be discussing with you.

Concerning Kern On: yes, of course, having compatibility with using KO is vital, and I would never modify the kerning outside of KO. I didn't check exactly what kerning post-processing you do, but personally, I leave the kerning generated by KO as-is and post-process kerning only on export. That leaves everything intact and lets designers kern without having to worry about kerning pair optimisation in the final export.

You might be aware that KO has an autospace mechanism built in, which I would strongly suggest you use for glyphs /lslash, which has lots of positive kerning when it should have none. Overall, there are many glyph pairs that have kerning when they shouldn't, this comes down to spacing negligence and KO simply "correcting" this spacing via kerning. Quite some file size could be saved here.

My slant correction algorithm is intended as a Glyphs filter, ideally usable as a custom parameter on export. I am still working on the actual algorithm itself and I am far from solving all edge cases, but I'm getting there. I have a working filter plugin as well, which simply wraps the algorithm in a Glyphs filter, but before the algorithm handles all necessary cases, I can't publish it.

[qinyiyao]

@eweracs (No worries, and you'd be right: I have no relevant knowledge prior to this project. My real job is a professional cleaner of elaborate messes. :)

Post-processing sounds like an interesting approach. We can certainly shed some water weight here. I mean we can fancy with lossy compression through clustering and quantization, but I'll definitely leave that to Kern On and other research projects before it's mature enough for global-scale production use. Let me mark this for some investigation later.

Looking forward to the plugin!

[cssobral2013]

I join this issue with a request: why not make a separate source for Italic?