Questions and Answers

Source Sans Pro
Source Sans Pro
Technique and Theory
Multi-lingual / multi-script typefaces
Scott-Martin Kosofsky

As someone who works daily with books that involve as many as four or five scripts (and their weights and italics and small caps, where applicable), I can tell you that using fonts in which multiple scripts have been loaded can create more problems than they solve, and take more time than when the fonts are individual. This is especially true when one of the scripts is right-to-left and another is left-to-right.

A very long glyph palette can be clumsy and tiring to use, and switching text direction and keyboard layout is more time consuming than switching fonts. This is especially true when the scripts are combined within single paragraphs.
If the work at hand is typesetting, say, food contents labels, working with a clumsy overloaded font is a chore you can live with, but with more extensive work, such as a book, it can be a curse. Having a Latin set along with another script is often a necessity, but you needn't use it as your primary Latin. In a structured document, in which good use is made of paragraph and character style sheets, switching fonts is no problem at all, and keeping the fonts separate makes editing much easier and faster.

Moreover, I find that most makers of multi-script fonts make decisions regarding relative character height based on ignorance or convenience (e.g., hinting zones), not on what more knowledgeable people might consider best typographic practices, and so the purported advantage of equal weights by size (which is not always desirable) becomes a false one in the end.


x-height + descender = cap height
John Hudson

For traditional text faces, I use a simple rule: x-height + descender = cap height. Ascender height is basically stylistic, i.e. it can vary pretty freely depending on the style of type and the effect one wants to achieve in text. But the relationship of x-height and descender height to cap height is foundational. Interestingly, I didn't start from this idea, but realised it after noting that my inverted exclamation mark always fit perfectly into the x-height and ascender: I was doing it intuitively.


FontLab Error: invalid first character in name (text was ".null")
Karsten Luecke

If you generate OTF fonts (with PostScript outlines): only '.notdef' must be present, but not '.null' and 'CR'.
If you generate TTF fonts (or OTF with TT outlines): '.notdef', '.null' (unicode '0000'), 'CR' ('000D') and 'space' ('0020') should be the first four glyphs in your font, in this order. To reorder them, set the Font Window to Index Mode, then pull the glyphs the the correct place.
What I meant was, make sure '.null' is not mentioned in any feature.

Source: TPHL

Glyph Naming Conventions

In order to have a glyph included in a feature, make sure you name the glyph with an appropriate suffix or ending. For example, to have your small capital glyphs used as replacements for lowercase letters in the smcp feature, name your glyphs a.smcp, b.smcp, c.smcp, etc. Suffixes containing multiple feature tags are supported and processed as best as possible. For example, a glyph named R_A.dlig.swsh would generate a rule under the swsh feature to substitute it for R_A.dlig as well as a rule under the dlig feature to substitute it for R.swash A. The table below shows what suffixes and endings are recognized by the system and used in generating OpenType features.

Source: Typedrawers: Collecting (glyph name) suffixes
Source: Font Development Best Practices: Glyph Naming

If you like this site and find it useful, help us to make it better by giving feedback, suggesting improvements or by donation.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.