But don't let the process become the point! And it shouldn't be so linear. In practice it's very iterative: you make some glyphs, you see how they behave in groups (where spacing already comes in), you can even allow the [eventual] kerning to affect the letterforms! Even hinting can have such a "backwards" effect - just look at the Bolds in the MS core fonts - they wouldn't have been so bold without the necessity to eventually not have to hint every single stem, etc.

Practically speaking, the greatest amount of iteration will be between the letterforms and the sidebearings: because the relationship between the Black and the White is what matters most, the "internal" counters of glyphs are tied to the "external" sidebearings. So you make some key glyphs (different for each designer, but also dependent on the intended use of the font - for example a display face will rely more on the memorability of individual glyphs, while a text face will rely more on the integration of the whole), then see how they fit together, modify them, add some more glyphs, try those in combo, modify, etc. Yeah, it's a pain. :-)

hhp

I agree with Hrant that it's very iterative.

That being said, the most important thing is to try to finalize the spacing before getting into kerning. If you mess with the spacing much after you get into kerning, you will likely need to throw out all your kerning and start over again.

If you're working in PostScript style outlines, there's no reason not to hint your glyphs as you're working on them. If you're working with TrueType outlines, you pretty much have to leave hinting to absolute dead last.

Other than that, it's a matter of taste and preference.

Personally, working with PS outlines, I complete a handful of glyphs, and while I'm working on them I space and hint them. I then test them together and fix the spacing some more. Then I continue to expand the glyph complement (hinting all the while), periodically stopping and refining the spacing.

The typeface I'm working on right now I have tweaked the spacing too much, so I will be tossing out the moderate amount of kerning I already did and starting over. I didn't invest a lot of time in the kerning because I knew I wasn't 100% done with the spacing.

Hope that's of some help.

Cheers,

T

Thanks, guys -- I'm not too far off then. I've already had to throw out the kerning once, and now I'm paranoid that the sidebearings will never be good enought for me to start kerning again. Blah! It's frustrating, but I guess that's part of learning.

More thoughts are welcome...

Thanks,
Addison

> finalize the spacing before getting into kerning.

On the other hand, the intended use of the font can affect the relationship between spacing and kerning (especially for some non-Latin scripts where building kerning on top of "perfect" base spacing can become prohibitive). If you can safely assume that kerning will be available virtually all the time*, you can make different (more efficient) spacing decisions, and sometimes even different letterform decisions (like in the beak of the "r" or the size of the serifs on the "v").

* And when it fails because of amateurism on the user's end, such users won't notice anyway!

hhp

especially for some non-Latin scripts where building kerning on top of "perfect" base spacing can become prohibitive

I don't understand this statement, Hrant; can you explain what you mean by prohibitive? I do agree, if this is what you are getting at, that some scripts require extensive kerning to achieve acceptable basic spacing, i.e. that kerning is not always 'exceptions' to basic spacing as it usually is in Latin fonts. In that case, application of kerning should be part of the language shaping engine, not something turned on by the user.

It comes down to the near-requirement of avoiding touching: you want the words to set tightly, but scripts that have letters with a lot of lateral "protrusions" will collide a lot (with kerning off). You can either set everything loose and use a ton of negative pairs to correct, or you can set everything with "natural" tightness and use some positive pairs to remove collisions. Which way you go depends on a number of things, like the degree of collision in the script, the intended user base of the font, but also the amount of time/effort you want/can_afford_to put into the design. And this last consideration isn't limited to lazy/cheap people like me. :-) The MS core fonts have too-dark Bolds basically because it would have been ridiculous* to hint every single stem to snap wider to two pixels.

* Both in effort and resultant file size - note that about 50% of the file of an MS core font is the hinting!!

Let me give a real example: Armenian has a fair amount of "collision potential" (mostly in the descenders). You can tame the protrusions, but that's culturally and functionally (think boumas) bad - although you still do it a little bit (in the same way that a "g" in a [good] Latin text face needs to look slightly cramped). To save myself having to set everything loose and then tighten with a ton of pairs, I went the other way. With 546 pairs* I got really good texture. My estimate of how many pairs would have been required with the other (non-kern-reliant) method is 3-4000, so a lot more work. With kerning off, this kern-reliant method will produce some collisions when set without kerning, but: it will also produce better "x-band" spacing; people with kerning off aren't likely to mind some touching anyway.

* Tellingly (although not surprisingly) about half of the pairs were positive - very unlike the typical Latin font. BTW, Mana uses some reliance on positive pairs too - this allows it to be tight (unlike Verdana for example). Over 1/3-rd of Mana's pairs are positive.

> application of kerning should be part of the language
> shaping engine, not something turned on by the user.

But in practice the user -and the app- end up sharing the responsability. Most notably, MS Word does support kerning, but the user has to turn it on (and every time) - never gonna happen. :-(

hhp

Hrant wrote:

"The MS core fonts have too-dark Bolds basically because it would have been ridiculous* to hint every single stem to snap wider to two pixels."

"* Both in effort and resultant file size - note that about 50% of the file of an MS core font is the hinting!!"

That is simply untrue. You're presenting incorrect speculation as fact (again). Given a well-hinted TrueType font in the first place, it is literally a single line of code that accomplishes this.

In any superhinted TT font, one is controlling when the stems change from one thickness to the next, at least for most of the lower levels (one, two, three pixels thick). This is especially necessary when there's a matching italic, since one needs to make sure they break at the same ppem sizes for those lower levels.

In other words, the "additonal" work involved and font size added, rounded to the nearest whole number as a percentage, is zero. (Though of course if one had already done the detailed hinting and then changed the stem widths, that would entail more work. But like spacing vs. kerning, that's not the order one does these tasks in.)

If I were to speculate, I'd *guess* that the reason the bolds are so heavy for those fonts is to keep them more WYSIWYG between what they look like at typical screen sizes and what they look like in print. But that would be just speculation, though with a little more basis.

This is somehow comforting. I think I had agreed with the last half dozen posts of Hrant's that I had read. I was wondering if it was a sign of the apocalypse or something.

That aside, I do understand and agree with Hrant's comments about different scripts needing a different spacing vs. kerning strategy. I believe my original comments apply reasonably well to Latin, Greek and Cyrillic.

Regards,

T

I've done some "superhinting", but not tons - so maybe I don't realize how easy it is to pop all the stems wider. On the other hand, your explanation for the exteme weight of the MS core Bolds doesn't seem very probable to me. There's so little WYSIWYG between different sizes of the Geogia bitmaps (which is actually good news though), much less between the bitmaps and print - so WYSIWYG of the color relationship between screen and print seems pretty far-fetched. Not least because it would have to be based on a specific PPEM! Kind of destroys the point.

Maybe it was a filesize issue?

hhp

Hey, I forgot - I kinda have proof of my "theory":
Check out the 3rd sentence in the 3rd paragraph here:
http://www.microsoft.com/typography/web/fonts/trebuche/default.htm

hhp

That has more to do with issues around shapes where changing the shape requires delta hints, which do add (substantially) to file size. A global stem width adjustment does not affect file size significantly, given that individual stems already have their own CVTs, and on top of that they have inheritance set up so that all the vertical stems can be controlled at one go.

Another way of realizing that this is not such a big deal is to remember that plenty of superhinted fonts that do not have such a strong weight difference in the outlines (between regular and bold) have been superhinted so that the bold is consistently heavier than the regular even at low ppem sizes. Times New Roman, Arial, Palatino Linotype, and a bunch of others....

Regards,

T

Connare writes: "Then when the outlines are made they have to be similar to the bitmaps and the hinting is easier since you know what the specific low sizes should look like."

The key thing to me here is that "easier". And delta hints apply huge distortions to the outlines. How can you -and why would you- design around that for the arches (assumedly) for example but not the stems?

> .... have been superhinted so that the bold is consistently heavier than the regular even at low ppem sizes.

For the screen - of course. My concern here is the (unhinted) outlines. Why are the Bolds too dark?

hhp

Hrant,

please look at http://www.twardoch.com/tmp/verdanahints.htm

I created a "Verdana Semibold" by just interpolating Verdana Regular and Verdana Bold at 50% (you can see it at the glyph sample). Then, original hinting of Verdana Regular and Verdana Bold is shown.

Below, two variants of FontLab-autohinted "Verdana Semibold" are shown. It is pure FontLab autohinting, with no manually set instructions.

As you can see, with just a small modification of PPM parameters, it is possible to enforce very bold appearance of the Semibold -- actually, even bolder than of the actual Bold (esp. at the PPMs 14 to 16 which IMO are hinted too light in Verdana Bold).

Adam

But in practice the user -and the app- end up sharing the responsability. Most notably, MS Word does support kerning, but the user has to turn it on (and every time) - never gonna happen.

Ah, but this is not true for all scripts. The Uniscribe shaping engines for some scripts (e.g. Thai) apply the OTL <kern> feature automatically, because it is understood to be essential to correct language shaping. I believe this may eventually happen for the Latin script also.

Thanks for the further explication: I thought that was what you were getting at, and agree.

Verdana, like Georgia, was designed by making bitmaps and then drawing outlines that wrapped to those bitmaps without very much hinting. That approach likely explains why the bolds are so bold, regardless of whether they actually needed to be so bold in order to achieve the same result.

Right. Which has the effect of making the screen font more WYSIWYG relative to the outline font.

In the broader sense, Hrant is right, and that's what Vinnie was saying: the closer the outlines are to the desired bitmap pattern, the easier it is to achieve that look with hinting. It's just that the *particular* issue of weight is one that is trivially easy to adjust with hinting. Well, in TrueType, anyway.

(Note: Type 1 and PostScript flavored OpenType have a concept called "force bold" which accomplishes some of the same goals, in a cruder but even easier way.)

Regards,

T

Adam, naughty boy - thou shalt not modify MS fonts! ;-)

> That approach likely explains why the bolds are so bold

I still can't see that. The fact that the onscreen stem difference between the Regular and Bold has to be 100% (below 17 PPEM) only translates to the outlines needing to have the same relationship if hinting effort is an issue.

> Which has the effect of making the screen
> font more WYSIWYG relative to the outline font.

Only below 17 PPEM. Above that it's only 50% (upto ~25). And consider that the higher the PPEM the more WYSIWYG a screen font becomes... So what were they really shooting for?

BTW, in this old interview
http://www.will-harris.com/verdana-georgia.htm
Carter says "The bitmaps dictated the weight."
Could he really have meant they "dictated" via WYSIWYG? Or isn't it probable it was via hinting?

Returning to the "easy" bit: exactly what becomes easier by making the Bold too dark? WYSIWYG becomes easier?! That doesn't seem to make sense.

hhp

A follow-up question:
I can believe that making a Bold's outlines snap [wider] to two pixels is simply a matter of setting a threshold (as opposed to tediously hinting every glyph), but: if this applies only to stems (and not arches for example) is it possible that this would create an imbalance in a glyph's rendering, like in fact sometimes introducing stroke contrast? Especially in a monoweight* font like Verdana.

* As a side question: is that a good term, or is "monoline" better?

hhp

Hrant,

in hinting terms, "stems" are both horizontal and vertical "corridors" of node alignment. You can control the thresholds when PPMs switch to 2, 3, 4 etc. pixels for both horizontal and vertical stems, separately. So you can control the stroke contrast, and keep it linear. As for arches, you cannot hint them explicitly -- all Type 1 hints and most TrueType instructions work in either horizontal or vertical direction only (there is some diagonal control in TTH).

You say "setting a threshold (as opposed to tediously hinting every glyph)". Stem control does not occur OPPOSED to hinting, it IS hinting. In fact, it is the fundament of any hinting -- you always start with the font-wide parameters (that go into the control value table "cvt" and the font preprogram "prep").

Only after you've reasonably set the font-wide hinting parameters such as stems and alignment zones, you start with per-glyph hinting, since instructing individual glyphs is basically fixing and fine-tuning what the font-wide hinting has achieved.

Adam