Thomas Phinney

The desire to limit the number of kern pairs has not usually been about file size, but about app bugs (see below).

Nowadays with class kerning, it is also more likely that there is no direct relationship between some theoretical "# of pairs" and file size, as classes work... differently. Generally if you are worried about "too many pairs" and file size, you should be using class kerning judiciously to reduce the impact of the kerning on file size.

15+ years ago, it was common for applications to misbehave when presented with more kerning data than they knew what to do with. The critical number would be as low as 3K kern pairs, but more commonly ~ 4K to 8K. There were a variety of different bad behaviors after the critical # was reached, depending on the app:

- ignore pairs after the first X pairs
- ignore pairs before the last X pairs
- read X pairs and start writing over them with additional pairs, starting at the beginning

I remember limiting fonts to 4K or 5K kern pairs because of this.

Apps have gotten better since then, of course.

Hrant H. Papazian said:

Unless you have a good reason to not use 1000, use 1000, since some software still assumes it.

The assumption is that fonts with PostScript outlines (Type 1 or OpenType CFF/.otf) will have a 1000-unit em, and fonts with TrueType outlines, a 2048-unit em. What is considered “standard” is dependent on the outline format.

Much about these swashes feel very tentative and restrained. It's like you are worrying about how they will fit in the middle of a line of text. Which may be a legitimate concern, but I will note that most of the expert type designers whose swashes I have studied go at least a bit farther, often a LOT farther.

The bottom stroke of the swash L could be at least twice as long, and a bit heavier at its thickest. Ditto Q and Z.

Lowercase g could do something when swashes are on. It already felt restrained.

The bottom left swash of AMN could descend more and be more prominent. Descending bits of R and especially S could do more and go further.

I'll be the first to admit that my own swash caps to date have been less than thrilling. But they were in a pretty weird typeface that had weird swashes already, and I was just adding on.

Given the design of Cantarell, you can go as light as you like, and a step or two bolder, before you start to need to do anything special for optical compensations with an extra master. At first it would just be for a few glyphs such as a and e. If you go a lot bolder, you'd need to do a whole master.

You should try starting with keeping the Regular as a master, and doing the lightest and boldest weights. Then see how different it looks (and whether it's a problem) if you drop the Regular master.

That said, in general I would just use two masters, and do corrections at the heaviest end as needed (per Georg's comments). The reason being that for further development, changes and extension, it's just a lot less work if you have two masters instead of three.

And as a bonus, the final file size would be smaller. I know you say that's not a priority, but it can't be a *bad* thing, right?  

1) Well, first I will note that for me, if I am doing axis-based design, also targeting variable fonts doesn't make much difference. Variable Fonts have all sorts of capabilities for additional masters or even glyph-specific tweaks to the design space that allow all the same kinds of compensations that one might have made when using axis-based fonts as an upstream source for a large family of fonts.

I'm confused by the fact that you talk about designing a new family in your point #1, but you've also said you are porting Cantarell. This seems contradictory. But it's late at night, so I may be missing something.  

But in any case, there is not in general anything inherently massively different about doing axis-based design than just doing design. Mind you, I may have trouble seeing what you might see as differences, because it wouldn't occur to me to NOT do axis-based design if I have at least two weights. Seriously, if I am doing more than one weight of a typeface, I would do a weight axis. If I need a slightly bolder and slightly wider variant of a font, I build a variant with weight and width axes and twiddle the values until they work best. Axis-based fonts are just a basic part of 90% of my type design, and have been for 20 years.

2) In your case, two considerations regarding making the regular weight a master, and having lighter and bolder masters as well:

• you are mostly focused on web fonts and size matters. Consider that more masters means a bigger final font file.
• I do not know how much you care about compatibility with the existing non-variable version of Cantarell. If it is important that the new variable version be pretty close, you might need an intermediate master.

3) Yes, you can add a width axis later on. BUT, first we need to know: Will you need the later version with the added width axis to be highly compatible in design with the version you create now, without the width axis? Do you need that final version to still be hightly compatible with the original Cantarell?

If you need compatibility between the width-axis font and the later two-axis version, and you aren't constrained by compatibility with the existing Cantarell, then shipping the one-axis version first will put some constraints on the later two-axis version that you would not otherwise have. That would seem like a less than ideal situation, to me.