Diacritic Mark Suffix

Mithil Mogare

I observe in many fonts there are 2-3 different styles of diacritic mark sets like acute, acutecomb, acutecomb.case and acutecomb.narrow. This led to questions in my mind.

1. what is the purpose of acutecomb even though we have plain acute in the set?
2. what is the application of acutecomb.narrow?
3. what other suffixes are there to use and their application?
4. why we cant use acute.case instead of comb in it?
5. if the .case is for caps then is there any suffix for narrow caps., something like acutecombnarrow.case?
6. how suffix functions?

Denis Moyogo Jacquerye

> 1. what is the purpose of acutecomb even though we have plain acute in the set?

The plain acute is a spacing mark, it sits next to the letter and has its own advance width. The acutecomb is a non-spacing combining mark, it sits on top of the letter it combines with and has no effective advance width.

This is true for any spacing and non-spacing pair, like grave and gravecomb, etc.

> 2. what is the application of acutecomb.narrow?

The acutecomb.narrow can be used with narrow letters, like i or rather idotless.

> 3. what other suffixes are there to use and their application?

> 4. why we cant use acute.case instead of comb in it?

You can do whatever you want 😉 but does it make sense?

Some font editing tools have predefined suffixes they will use, their documentation should mention them.

> 5. if the .case is for caps then is there any suffix for narrow caps., something like acutecombnarrow.case?

> 6. how suffix functions?

It should be acutecomb.narrowcase or acutecomb.narrow.case not acutecombnarrow.case. The period separates the glyph name and the suffix(es).

Your font editing tool may use suffixes to write automatic OpenType features or when constructing glyphs you add to the fonts.

Some authoring tools still use spacing marks to construct glyphs, which they seriously should stop doing, even as a fallback, as this perpetuates pre-Unicode practices which are now bad practices.

John Hudson

I use .cap rather than .case (and .sc for smallcap marks). Using .case doesn’t make sense to me, because that suffix is associated with the ‘case’ OpenType Layout feature, that in turn is misnamed because that feature is specifically for all-caps variants, whereas .cap or other mark variants are contextual and composite forms determined by the base glyph, not the textual case.

Johannes Neumeier

6. how suffix functions?

However the software makes it function. Glyph names are entirely arbitrary, it is unicode values and opentype features that matter. You can name your glyph squiggleswoosh in your font editor as long as it is assigned unicode U+0301 and takes part in GPOS it will work as a combining acute. It will be easier, of course, to follow a convention and utilize the font naming supported by the editor to get some automagic.

Mithil Mogare

John Hudson said:

I use .cap rather than .case (and .sc for smallcap marks). Using .case doesn’t make sense to me, because that suffix is associated with the ‘case’ OpenType Layout feature, that in turn is misnamed because that feature is specifically for all-caps variants, whereas .cap or other mark variants are contextual and composite forms determined by the base glyph, not the textual case.

This is great way.
But, If three.osf for three then then what about three.ss01. Will it be three.ss01.osf?
can we use 2 suffixes after one after other like acutecomb.narrow.case or acutecomb.narrow.caps for narrow caps? 
If not then how can we use?

John Hudson

It may be helpful to understand the whole background of .suffix use in glyph names.

As stated elsewhere in this thread, glyph name can be arbitrary. Many of my fonts use glyph names that are specific to the way I work, are not recognised by tools without the custom name mapping files I use, and are not parseable by downstream software such as Adobe Acrobat. The latter is important in this discussion, because the convention of using names with dot-separated suffixes was defined by Adobe specifically to assist Acrobat parsing of glyph names. The context for this parsing is PDF documents that have been distilled from a print stream, i.e. from a source that does not include the original Unicode character codes. Adobe wants PDF content to be searchable and available to accessibility tools such as screen-readers. This means that they want Acrobat to be able to reconstruct the text content of print-distilled PDFs, and the mechanism they rely on to do this is parsing the names of the glyphs in the embedded fonts in the PDF. In order for this to work, they need fonts to use a set of conventions that map from glyph names to Unicode characters. The suffix convention is a way to name unencoded variants, in which the portion of the name to the left of the dot is parseable as mapping to a Unicode character, and the portion to the right of the dot is an arbitrary suffix that is ignored by Acrobat.

Font makers started using OpenType Layout tags as suffixes in some situations, to help them manage naming in font production and keep track of which feature(s) to assign glyph variants in OTL code. Font tool makers started leveraging such suffixes to automate writing of some of that OTL code, so now in many tools one can call a glyph something like /a.ss01/ and the substitution code will get written for the ss01 feature.

So there are two conventions to bear in mind regarding glyph name suffixes: Acrobat name parsing in which the suffix is completely ignored, and individual font tools in which the suffix may be used to automate some part of the OTL code, but doesn’t need to be.

So now we can consider the question:

But, If three.osf for three then then what about three.ss01. Will it be three.ss01.osf?
can we use 2 suffixes after one after other like acutecomb.narrow.case or acutecomb.narrow.caps for narrow caps? 

Yes, you can use more than one suffix, separated with more than one dot. Acrobat will ignore everything after the first dot, as it only cares about what is to the left of that dot. Font tools will probably not know what to do with multiple suffixes in terms of automating OTL code, but that’s okay because the substitution code for a glyph with more than one suffix is probably something that you want to write and control yourself, not automate.

When I am using multiple suffixes to help me manage variant glyphs, I order the suffixes in a way that reflects how I intend to order the substitution lookups. So, in the example of the variant oldstyle but also ss01 /three/ glyph variant in the question, I would ask myself whether I want the onum feature of ss01 lookup to be applied first. The answer to that will likely depend on what other variants are included in the ss01 variant set, and hence whether it makes sense to substitute the oldstyle numerals before or after the ss01 substitution. There isn’t a single correct answer, as either lookup order can be made to work.

Craig Eliason

John Hudson said:

 Font tools will probably not know what to do with multiple suffixes in terms of automating OTL code, but that’s okay because the substitution code for a glyph with more than one suffix is probably something that you want to write and control yourself, not automate.

Glyphs app can handle multiple suffixes pretty well. 

John Hudson

Glyphs app can handle multiple suffixes pretty well. 

In what sense? You mean it automates OTL feature mappings based on more than one suffix? Does the order of the suffixes determine the lookup order?

Craig Eliason

Yes