A rationale for this replacement of /gamma?

Theunis de JongTheunis de Jong Posts: 112
edited November 2018 in Font Technology
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.

Comments

  • 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'.
  • 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.
  • Perhaps they did it because the font was conceived primarily as a typeface for user interfaces rather than running text or scientific work.
  • 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.
  • 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 JongTheunis de Jong Posts: 112
    edited November 2018
    .. It's an open source font so I didn't actually have to browse the binary :pensive:

    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.

  • 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 FreibergerIgor Freiberger Posts: 250
    edited November 2018
    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. IsaakAndré G. Isaak Posts: 626
    edited November 2018
    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 JagoszAdam Jagosz Posts: 689
    edited November 2018
    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 FreibergerIgor Freiberger Posts: 250
    edited November 2018
    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.

  • 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.
  • 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.


Sign In or Register to comment.