Diacritics

mauro sacchetto

Technical problem in creating compound glyphs. Assuming I have all the Combinig Glyphs, both FontForge and Glyphs build them easily. For the uppercase ones, I create the corresponding glyphs, in the two programs with slightly different names (same name with capital letter for FontForge, same name with .case suffix for Glyphs). Let's assume, however, that I intend to create a diacritic without Unicode encoding, for example the breve sign for Cyrillic, with a design other than the Latin breve (sure, it is not that in Cyrillic there are many letters with the breve and it is possible without too much effort to do everything by hand ...) I can call this glyph .breve.CYR, or any other name. At this point, it seems to me that neither program recognizes the name and is able to construct automatically the compound glyph. Am I wrong or is there an effective technique? Thank you

Christian Thalmann

Glyphs recognizes brevecomb-cy.

mauro sacchetto

A little good new! Thank you

jeremy tribby

more generally, check out page 97 (section 7.6.3) of the Glyphs 3 handbook, which covers script-specific naming, as well as page 234 in the appendix (section 17.4), which covers naming conventions for automatic feature generation. I frequently forget these details so I keep screenshots of those pages handy

mauro sacchetto

Thanks for the tip. But the system by which glyphs with hyphen suffix (such as -cy or -thai etc.) belong to certain languages is a conventional or specific system of Glyphs?

mauro sacchetto

Update: I have found that several of the uppercase glyphs for diacritics are actually already encoded in PUA (eg Acute to uniF6C9, Grave to uniF6CE). There are also cyrBreve (uniF6D1) and cyrbreve (uniF6D4), so it is not strictly necessary to create others. But these matters are poorly documented, so I ask:

1. why create unencoded Unicode glyphs where the appropriate slots already exist (this also applies eg to many .sc glyphs)?

2. why in agl are other glyphs missing - for example there is Macron (uniF6D0), but there is no Breve, Caron or Circumflex?

3. always in agl I find Brevesmall (uniF6F4), Caronsmall (uniF6F5), Circumflexsmall (uniF6F6) etc .: why the suffix <small>? Are they specific "small" glyphs, or can they replace the missing "normal" ones?

4. if I insert in one of this slot a glyph that I need and that I use for the creation of accented glyphs, I have to consider them "Combining" and give them width 0 (even if in Glyphs Handoook I read that it is no longer a dogma and that this convention can also be broken

Thank you

Florian Pircher

mauro sacchetto said:

even if in Glyphs Handoook I read that it is no longer a dogma and that this convention can also be broken

Glyphs will reduce the width of combining marks to zero at export, that is why they can have a non-zero width inside on Glyphs.

mauro sacchetto

I don'k know if the glyphs in PUA I mentioned above are seen as Combining Marks. In any case...

Florian Pircher

You can always check by selecting a glyph and choosing Edit → Info for Selection… (⌥⌘I). If the Subcategory is Nonspacing, its width is reduced to zero at export. In general, if the glyph name ends in ‘comb’ (e.g. acutecomb) it is Nonspacing.

mauro sacchetto said:

Update: I have found that several of the uppercase glyphs for diacritics are actually already encoded in PUA (eg Acute to uniF6C9, Grave to uniF6CE). There are also cyrBreve (uniF6D1) and cyrbreve (uniF6D4), so it is not strictly necessary to create others.

I don’t think there is much value in encoding capital marks with PUA codes.

mauro sacchetto said:

1. why create unencoded Unicode glyphs where the appropriate slots already exist (this also applies eg to many .sc glyphs)?

Most of the Latin small caps in Unicode are designated for IPA use, so unless the font also supports the rest of IPA, I see little reason to encode the few small cap glyphs that have IPA small caps codepoints.

mauro sacchetto

I understand. The thing that puzzles me is that, for example, Garamond Premiere Pro and several other Adobe fonts place the a.sc-z.sc glyphs just and only in the predefined Corporate Use slots (uniF761-uniF77A). Others instead create them outside of the slots in possession of Unicode encoding. What is the best strategy?

John Hudson

Older Adobe fonts are more likely to include the PUA mappings for smallcaps. In the early days of OpenType, Adobe thought it important to provide a workaround for accessing smallcaps in non-OTL environments. Later, they sensibly abandoned this, since using PUA for smallcaps diminishes document text interchange and searchability.

Thomas Phinney

The fonts Adobe made earlier in the history of OpenType encode those things in PUA. Later Adobe fonts leave them unencoded because Adobe decided the negatives outweighed any theoretical advantages. But a font that has shipped with such codepoints, well, they do not want to drop them in a later update to the font.  

I was the one who pushed the original decision for PUA encoding in early Adobe OpenType fonts, for various things. I was concerned about OpenType adoption and wanted to make sure that legacy apps had SOME way to get at this stuff. It did not get used all that much as far as I could ever tell. If I had it to do over again, I wouldn’t have ever done any PUA encoding of those glyphs, with a limited exception for ornaments only.

mauro sacchetto

Thank you for your clear and definite answers