Best practices for creating smoothly working webfonts

Jasper de Waard

Hi there,

I'm working on a webfont at the moment, and rather than simply hand the otf's over to a simple webfont generator, I want to take this seriously. What's the best way to go about creating smoothly functioning webfonts? So far I've found:
- Turn on in FL settings: "export oldstyle non-opentype kern table" and "expand class kerning while building [kern] table"
- Expand kerning(?)
- Keep opentype features. Apparantly there's support for that
- Include separate fontfiles for smallcaps and numerals(?)

Thanks in advance

Dave Crossland

- Turn on in FL settings: "export oldstyle non-opentype kern table"

No, I wouldn't do that today - it might have made sense in the past, but today, all browsers that support kerning support GPOS kerning which, being class based, has much less filesize impact.

- Expand kerning(?)

With no KERN table that isn't needed

- Keep opentype features. Apparantly there's support for that

Yep, increasingly there is support for this, although users have to turn on the features beyond LIGA with their CSS, so you might want to do 2 versions with and without.

- Include separate fontfiles for smallcaps and numerals(?)

This is what I mean by 2 versions with and without OTL; the version without might be split into separate families to provide all the available glyphs. I have tended to do this for fonts in Google Fonts API.

Rainer Erich Scheichelbauer

I do my subsetting for things like Small Caps with Instance custom parameters in Glyphs. That way I can take care of everything at export time. If you really want to do subsetting after compilation… well good luck with fiddling with the compiled GPOS table.

Jasper de Waard

@Dave: Thanks for your help. I have to admit I'm working with fairly old software (firefox 26.0 on Mac 10.6.8), but the kerning only shows when I include a non-opentype kern table. So, I'm assuming this only goes for the latest version of all browsers?

@Rainer: I don't see the problem. Cut the font up in fontlab, then generate the ttf's, then convert to webfonts. Am I missing something?

Ermin Međedović

@Jasper de Waard: (Rainer is The Glyphs guy!;)

Rainer Erich Scheichelbauer

No complaints. If you enjoy manually cutting fonts up in FLS, that is just the perfect workflow.

In the OS X engine, kerning only shows if there is at least another feature in the GPOS table. Like Dave, I recommend it should not be 'kern' (lowercase letters, please). Try cpsp. Doesn’t hurt anyone.

Jasper de Waard

@Rainer: I'll make the switch to Glyphs sooner or later. For the time being, though, I'll stick with what I know.

Sorry if this is a stupid question, but the GPOS table contains opentype features, right? So with, say, a 'liga' feature I should be fine, no?

I just googled cpsp, never heard of it, but it makes a lot of sense When I asked people before about how to space caps I was always told to either forget about it, or do a shitload of kerning between caps. Thanks for the tip!

John Hudson

Sorry if this is a stupid question, but the GPOS table contains opentype features, right? So with, say, a 'liga' feature I should be fine, no?

You can't compile a GSUB lookup to a GPOS table, since the tables have entirely different architectures. So any feature you put into the GPOS table has to be made up of GPOS lookups.

[The whole notion of putting features into tables is a bit wrong-headed. What you put into the tables are lookups, and the lookups are associated with features. In theory a feature could include both GSUB and GPOS lookups.]

kupfers

The cap spacing feature can cause problems in webfonts in the way that browsers have difficulties calculating the right line length (calculated vs. displayed = text overflowing the div). Might have been solved in the latest versions but it was still an issue in Safari at least fairly recently.

Thomas Phinney

If browsers currently have problems with cap spacing, then users will need to not turn it on. But they will presumably fix such problems over time. If the webfonts are to be provided to end users as final fonts, then better to make them right and advise to avoid the feature until browsers are fixed.

(I'm assuming that the reason kerning and ligatures don't cause this problem is that they more commonly reduce space usage rather than increase it. Yes?)

John Hudson

What Tom said. Don't disable fonts because browsers are broken. If there is one thing I've learned in 20 years at this game, it is that software makers are more likely to fix bugs if you refuse to work around them. And browsers are updated and pushed to users much more frequently than any other major software.

kupfers

Sure, go head. I only describe what I experienced. The cap spacing feature was not specifically turned on in the CSS, or I would not know how. Optimize-legibility was on. Do you suggest, people should/shouldn’t include it via font-feature-setting cpsp? Maybe some browsers follow Adobe’s wish for the feature to be on by default, some don’t. Or perhaps some do it with text-transform uppercase. But yeah, I’m all for more OT feature support in browsers. I’m just saying, until then, your webfonts might not work smoothly across browsers and OSes.

Robin Mientjes

Regarding these line length calculations, this sort of problem is much more broken in the CSS and general rendering than in the font support. Chrome would, for the longest time, break a string with positive kerning in it if you set it in an inline-block element. Turn off the kerning and it works. Use a system font and it works. We could take that as a font problem, but the truth is that Chrome simply calculated the bounding box too early, or rather, refused to redraw.

Now, the problem was quite egregious, so as a responsible web designer I had to fix it temporarily. This happened to Alright Sans out of the box — we could ask Webtype to never ship with positive kerning, we could ask them to ask designers to be careful with inline-block, or we push through with qualities we require from fonts and force Chrome to fix a sloppy issue that does not occur in other browsers. It seems obvious to me.

Chris Lozos

"...or we push through with qualities we require from fonts and force Chrome to fix a sloppy issue that does not occur in other browsers."

Yup, obvious to me too.