Modifier Letters and Combining Characters

mauro sacchetto · August 26

I'm somewhat confused about the use of Modifier Letters and Combining Characters.

Semantically, if I'm not wrong, the former are letters freestanding with a suitable width metric and must not contain anchors; the latter require a base glyph, have a null metric, and can contain anchors.

However (perhaps because FontForge's compound glyph production logic is unclear to me), should I use the former or the latter?

For example, if I want to produce (and set in PUA) .cap marks (a circumflex.cap that's wider and flatter than the "normal" circumflex...), should I create a modifier or a combining character)?

Thanks

LeMo aka PatternMan aka Frank E Blokland · August 26

Hi Mauro, to answer your question about spacing (modifying) and combining diacritics properly, I think we need to distinguish between three different aspects, which are, of course, ultimately intertwined:

        – The functionality of the font
        – The general technical aspects
        – The requirements of font tools

       1. Functionality
As far as the font’s functionality is concerned, modifier diacritics are normally used as spacing glyphs. They have their own advance width and can therefore occur independently. Combining marks, on the other hand, are non-spacing characters: they normally have zero advance width and are intended to be positioned relative to a base character.

For example, on a Mac, if one types an input sequence such as <Option> + /u, followed by /e, the result is an /ë. In this case, the input method uses the spacing/modifying diacritic for display, whereas the Unicode sequence 0065 + 0308 uses the combining character.

       2. Technical aspects
In the first case, the input method produces the precomposed character U+00EB LATIN SMALL LETTER E WITH DIAERESIS. The diaeresis is therefore part of the single encoded character, regardless of whether the glyph itself was constructed from separate components in the font.

In the second case, U+0065 LATIN SMALL LETTER E is followed by U+0308 COMBINING DIAERESIS. Here the diaeresis is a separate Unicode character, and the shaping system uses the font’s mark-positioning data to place it on the /e. The combining diaeresis consequently normally has no advance width and contains anchors.

Whether you use a spacing/modifier diacritic or a combining mark as the component when constructing a precomposed glyph is therefore largely a matter of your font-production workflow. Historically, with single-byte fonts, spacing diacritics were generally used because combining characters were not available in the same way.

       3. Requirements of font tools
This is where things can become slightly confusing. If your font editor or production workflow derives the mark-to-base positioning data from the components used to construct the precomposed characters, it may expect you to use the combining marks for those constructions. In that case, using the combining mark can be advantageous because the same glyph contains the anchors needed for the mark feature.

However, this is a requirement of the particular font-production workflow, not a requirement of Unicode itself. The Unicode distinction between a spacing modifier and a combining mark is independent of how you happen to construct the glyphs in, for example, FontForge.

As for your specific example of .cap circumflex, the answer is simply whether you want it as a modifier/spacing glyph, as a combining glyph, or as both. If you use circumflex for the modifier/spacing glyph and, for example, circumflex_comp for the combining glyph, you can have circumflex.cap and circumflex_comb.cap, serving different purposes. They do not need separate PUA code points, because they share the Unicode code point of their respective reference glyphs.

That all being said, there are certainly better experts on this subject here on TypeDrawers who can probably add to this.

Incidentally, our own tools work rather differently. The IKARUS-based file system cannot store composites to begin with. Therefore, the composites are built from the precomposed characters during the generation of TrueType fonts, based on the referenced-elements list in the so-called character layout file. For the creation of the mark-to-base features, I have built an automated workflow that calculates and builds these based on metrics and positions. Of course, the same values are used to build the corresponding precomposed glyphs. Finally, during font generation, a feature file is invoked for each font:

include (/Volumes/FontProduction/FontMaster/Support_Files/Feature files/AGL 1.5/features_2.1_New_OTM_Pro.fea);

include (/Volumes/FontProduction/FontMaster/Aanmaak/Estuary/Mac OS/OpenType/Pro/EP24X13T_1000.fea);

include (/Volumes/FontProduction/FontMaster/Databases/Estuary/GDEF_Mark/E_24_13T_Mark_Base_1000.fea);

include (/Volumes/FontProduction/FontMaster/Support_Files/Feature files/AGL 1.5/GDEF.fea);

include (/Volumes/FontProduction/FontMaster/Aanmaak/Estuary/Mac OS/OpenType/Pro/EP24X13T_CFF_name.fea);

Paul Hanslow · August 26

As with all aspects of type design, there are exceptions. Generally though, modifier letters have advanced width while combining characters have no advanced with (ie non spacing) and reside above, below, to the right, or to the left of the base letter.

For your circumflex.cap example, type designers typically create a 'case' or 'cap' variant of the mark, which is more vertically squat (compressed) and often has slightly more weight to balance better with the cap letters. The naming conventions of these marks vary greatly between type designers, while my typical practice is to add the suffix '.case' to any uppercase version of a comb mark. So /circumflexcomb's uppercase variant is titled /circumflexcomb.case. This helps to identify it as a non-spacing mark (due to the 'comb' part of the name). This is done to avoid any confusion with the legacy marks, which DO have advanced width. My approach is to design the comb marks, then add their outlines as components to the appropriate legacy mark, before adding advanced width and moving the component to reside comfortably in the advanced width. Typically, assigning 'case' versions of comb marks to the PUA isn't necessary, as all uppercase composites will inherit the case version of the mark (you can do this manually if required). Just leave them unencoded but include them in the file.

All 'case' mark versions can have a '_top.case' anchor rather than the typical lowercase '_top' anchor. I also suggest the UC version of marks be used on all ascending characters to allow tighter line-to-line fitting. But not all designers do this. Using a specific anchor for UC marks gives more control over constructing composite glyphs, separating the UC and LC comb-mark versions into designated buckets.

The combining marks containing 'topleft' or 'topright' come with problems as to how they are positioned on the base glyph. I'm speaking generally here, as most top right/left comb marks are catagorized as non spacing with zero advanced width, but this can result in clashes with the the proceeding letter depending on the design of the font. Some type designers create anchors specific for these marks, while others position the outline with a negative left sidebearing to sit closer to the previous base glyph that requires the mark. Still, this requires thoroughly checking in text runs.

When thinking about comb marks you have to consider a few things: anchoring, positioning of the mark's outlines even when the mark has a zero advanced width, and also how the mark functions. Some comb marks reside between two glyphs (like the combining double breve below), and would be input as base glyph + mark + base glyph.

John Hudson · August 26

[Modifier Letters] are letters freestanding with a suitable width metric and must not contain anchors...

To clarify: yes, these are spacing characters that are not anchored to preceding characters, but combining marks may technically be anchored to them (although in practice such sequences are rare).

The use of modifier letters is mostly in phonetic notation systems, and in some orthographies directly derived from such systems (e.g. those for Indigenous North American languages derived from the NAPA).

The only technical note I will add to what Frank and Paul have written is that something classed as a mark in Unicode is not necessarily treated as a combining mark in a font, and any glyph in a font can be classed as a combining mark. In an OpenType font, this is determined in the GDEF table, where glyphs are assigned categories. If a glyph is classed as a mark in GDEF, any advance width it might have will be ignored (collapsed to zero) by shaping engines.

Modifier Letters and Combining Characters

Comments

Categories