simoncozens / fonts-and-layout Goto Github PK

Hello Simon,

Thank you immensely for crafting such comprehensive documents on OpenType, script shaping, and text layout. Your book has been an invaluable asset in my exploration of this field.

Given the limited resources on this subject, especially in my native language, I am curious if I could have your permission to translate this online book into Chinese? I will keep it open source and allow for community edits.

Additionally, do you have any upcoming plans to complete the unfinished sections? I am particularly interested in the parts about rasterization and hinting, and I am truly looking forward to your insights on these topics.

Great job describing the basic variation tables of fvar and gvar. It would be great if you also included other important OpenType variable font tables like the STAT, MVAR, and HVAR tables, too.

There's a little aside in the doc:

Italic isn’t a design axis; it’s handled separately, for two reasons: first, you don’t really want people to be producing semi-italic fonts, and second, often the italic shapes of characters are quite different to the upright shapes, so it’s not possible or sensible to interpolate between them.

From a design perspective, this all makes sense. From a tech perspective, the spec does provide the 'ital' axis for those who want to go there. More importantly, the italic axis must appear in the STAT table for a font (even if the given font is a Roman) in order to tell software how the given font fits into the overall family. Essentially, the STAT table entry for a Roman tells the OS that there exists elsewhere an italic version of this font, which allows applications to nicely organize all the fonts in a family.

Was reading through the initial chapters and I found a typo. Unsure if you'd like this stuff to be tracked here; If not, let me know.

The second Bézier Curve paragraph has the following sentence:

Bézier’s contribution - as well as popularising the de Casteljau algorithm - was to made it suitable (…)

It should read:

Bézier’s contribution - as well as popularising the de Casteljau algorithm - was to make it suitable (…)

Re this:
"Another, more flexible way of putting multiple family members in the same file is provided by OpenType Variable Fonts."
The title case suggests this is an official name. The official name for the technology is "OpenType Font Variations". We use "variable font" to describe a font that uses the technology, but not title-cased. So, I'd change to either "OpenType Font Variations" or to "OpenType variable fonts".

Wrt this:
"Where you start and end your axis and put your default is up to you; these values don’t necessarily represent points or percentages or anything else. They’re dimensionless quantities that are only interpreted in relation to each other. In this case, it looks like the width axis represents percentage width. But if you wanted to set up your design space with compressed = 1, regular = 2 and expanded = 3, it’s completely your choice."

That's incorrect. Please see the way that registered axes are defined in OT 1.8 -- it's in the 'fvar' table chapter.

For instance, your example discusses the wdth axis. The scale is defined as follows:

"Values can be interpreted as a percentage of whatever the font designer considers “normal” for that font design. Values must be strictly greater than zero."

There's also this additional note:

"Note: The OS/2.usWidthClass field (and also the CSS font-stretch property) use a scale that is different from the 'wdth' axis scale, but for which there is a defined correspondence using mappings provided with the description of usWidthClass in the OS/2 table documentation. For non-default instances of a variable font, the 'wdth' axis value can be used to derive the OS/2.usWidthClass value for that instance."

So, a wdth value of 200 should represent 2x the width of 100. Of course, applied to overall length of some arbitrary content, this will be a first order approximation. But the scale is essential for interoperability with e.g. CSS or with responsive layout algorithms that would use the value as a first approximation for how to select a wdth value to obtain some line-fitting result.

If people create fonts that don't conform to the scale definitions in OT 1.8, they should anticipate that their fonts will behave in unpredictable ways in different software or, at worst, not be supported at all.