A rationale for this replacement of /gamma?

Theunis de Jong

When using Adobe's Source Sans Pro, I noticed its default /gamma (U+03B3) automatically gets translated to the phonetic symbol "Latin letter gamma" (U+0263) when not in text marked as "Greek":



Checking the OpenType features appears to confirm this is deliberate, as the substitution is found in the Default section of "latn" under "Localized":



and you can even see some more substitutions of perfectly normal Greek characters into phonetic characters: /alpha to U+0251, /iota to U+0269, /upsilon to U+028A, and /phi to U+0278.

Is this expected behavior and correct usage of the language sections, the 'locl' feature, and the appearance of Greek and IPA phonetic characters? Or, am I right in stating that when entering the Greek letter 'γ' I really should get that, even if it is inside an English text (or any other language really), and I should get the Greek character instead of a variant design, for use with phonetics?

If it weren't done by Adobe (co-developers of the OpenType font format), I would loudly cry foul, as changing Unicode codepoints behind an end user's back should be done very carefully – if at all.

André G. Isaak

To me, this definitely seems wrong. If these substitutions were registered under 'latn IPPH' or 'latn APPH' that would probably be fine, but not under 'latn dflt'.

Andreas Stötzner

Really odd, and surely a wrong implementation. The ordinary Greek gamma and the IPA-gamma are clearly two different characters, with different meaning and roles. You wouldn’t want in, let’s assume, a Math formula context or similar scenario get a mutation every time you type ‘gamma’, expecting to just get a gamma. Good heavens No, what did they have in mind doing this?

The creators of that font seem to interprete those special IPA characters in the sense of the locl feature. There lies the mistake.

George Thomas

Perhaps they did it because the font was conceived primarily as a typeface for user interfaces rather than running text or scientific work.

André G. Isaak

To me, this definitely seems wrong. If these substitutions were registered under 'latn IPPH' or 'latn APPH' that would probably be fine, but not under 'latn dflt'.

Actually, on reflection I think I’m going to retract my claim above. It might make some sense to register substitutions under 'latn IPPH' or 'latn APPH' for those phonetic characters which have only recently been added to unicode like latin small letter chi or latin small letter beta — much as one frequently substitutes scedilla and tcedilla with scommaaccent and tcommaaccent in Romanian — but it shouldn't perform such substitutions on characters like alpha and gamma which have been part of the IPA block since the early Cambrian.

When I write papers on linguistics, I very frequently include greek letters as variables rather than as phonetic symbols, and I don't want those to turn into IPA characters.

Adam Jagosz

I would hesitate if it was just the gamma — the glyph for the phonetic character has a loop and is more easily recognized as a gamma in Latin context. But since there are also substitutions for other letters, this is clearly wrong (especially alpha and upsilon!). The “rationale” behind this was probably in the lines of “oh, it says Latin small letter alpha. Let's use it for Latin”.

Theunis de Jong

.. It's an open source font so I didn't actually have to browse the binary

Judging from https://github.com/adobe-fonts/source-sans-pro/blob/ef7ab8e7338079e2ddfa5b3012640f5d79e6284c/Roman/familyGSUB.fea

<div>feature locl { # Localized Forms </div><div></div><div>&nbsp;script latn; </div><div>&nbsp;&nbsp;lookup GREEK_TO_IPA { # substitutes Greek characters by Latin characters </div><div>&nbsp;&nbsp;&nbsp;sub alpha by alphalatin; </div><div>&nbsp;&nbsp;&nbsp;sub beta by betalatin; </div><div>&nbsp;&nbsp;&nbsp;sub gamma by gammalatin; </div><div>#&nbsp;&nbsp;&nbsp;sub theta by theta.alt1; #from Myriad features </div><div>&nbsp;&nbsp;&nbsp;sub iota by iotalatin; </div><div>&nbsp;&nbsp;&nbsp;sub upsilon by upsilonlatin; </div><div>&nbsp;&nbsp;&nbsp;sub phi by philatin; </div><div>&nbsp;&nbsp;&nbsp;sub chi by chilatin; </div><div>&nbsp;&nbsp;} GREEK_TO_IPA;</div> it appears this was a deliberate choice, and not an error.

Jens Kutilek

Theunis de Jong said:

When using Adobe's Source Sans Pro, I noticed its default /gamma (U+03B3) automatically gets translated to the phonetic symbol "Latin letter gamma" (U+0263) when not in text marked as "Greek":

[...]

If it weren't done by Adobe (co-developers of the OpenType font format), I would loudly cry foul, as changing Unicode codepoints behind an end user's back should be done very carefully – if at all.

The Greek letters you enter stay Greek letters. The OpenType layout features just replace one glyph by a different glyph, but the underlying encoded text does not change.

Regarding a rationale, I guess that the type designers wanted to replace proper Greek forms, which are suited for Greek text, by more commonly known forms in non-Greek context, to make them look more like symbols in Latin text, and to avoid ambiguity with Latin glyphs.

Igor Freiberger

The Unicode 0263 gamma is not only a phonetic symbol. It is paired to Unicode 0194 Gamma and both are used in the African Reference Alphabet. So, in the realm of Latin script, the gamma to be used is the Latin one as it is part of alphabets based on this script.

This is the rationale.

The Greek gamma can still be used without problems, you just need to set its language to Greek. With InDesign it is easy to use GREP to do this automatically.
 

André G. Isaak

However, 0x0194 Latin Uppercase Gamma is *not* paired with 0x03B3 Greek lowercase gamma. Or do you think the font should also change 0x0393 Greek uppercase gamma to 0x0194?

Even if someone did want such substitutions to be performed, it should be restricted to the appropriate languages, not placed in 'latn dflt'.

Adam Jagosz

It is not the font software's responsibility to correct typing errors of the end user. Maybe substituting /Scedilla /Tcedilla for their counterparts with comma makes a little sense, since there might be existing documents from before introducing the appropriate codepoints... But still I would suggest using find and replace to just switch the source text to the correct codepoints. I suppose there is even less reason to use the codepoint of Greek letter alpha to represent a Latin letter alpha. No? This is just dumb because you see what appears to be a single storey a, but you change the font or copy it to another program and boom! alpha.

Igor Freiberger

André and everybody else: I just explained the rationale behind this substitution.
I am not advocating it is better or worse. Actually, in my opinion it is quite debatable.

Adam Jagosz

Jens Kutilek said:

Regarding a rationale, I guess that the type designers wanted to replace proper Greek forms, which are suited for Greek text, by more commonly known forms in non-Greek context, to make them look more like symbols in Latin text, and to avoid ambiguity with Latin glyphs.

I agree with the last statement in the case of gamma and maybe upsilon (though this is tricky, because Latin upsilon is nothing like Greek); as for alpha, quite the opposite.

Denis Moyogo Jacquerye

This would be a nice stylistic set or in the IPPH and APPH locl features but shouldn’t be in Latin default’s locl feature.