Variants: in 'salt' or in 'ss...'?

mauro sacchetto
mauro sacchetto Posts: 353
edited May 2020 in Font Technology
Curiosity, albeit marginal, about the Greek, although it could be repeated for other alternative glyphs not necessarily Greek.
In the GaramondPremierePro some variants - such as the letter kappa (uni03BA) and the kappa symbol (uni03F0) reproduced as kappa.alt (always uni03BA) - are present both as Stylistic Alternate ('salt' lookup 26) and in a Style Set (ss02 lookup 31).
What is the use of having this double location? Thank you
Tagged:

Comments

  • Craig Eliason
    Craig Eliason Posts: 1,440
    https://typedrawers.com/discussion/1206/opentype-salt-feature
  • Georg Seifert
    Georg Seifert Posts: 674
    Adobe illustrator does not support stylistic set but salt and Indesign is the other way around. So to be able to access the alternate in both apps, you need to put them in both features. 
  • mauro sacchetto
    mauro sacchetto Posts: 353
    Ah, it's therefore a convenience more for developers than for the font user! Good to know. Thank you
  • Theunis de Jong
    Theunis de Jong Posts: 112
    Adobe seems curiously uninterested and/or incapable of fixing this across their "Suite".
    To me it really appears such a small change to make.
  • Peter Constable
    Peter Constable Posts: 210
    I would think that, in a stylistic set , all of the glyphs should have something in common stylistically, and that there be one alternate per character. In contrast, I think of stylistic alternates as arbitrary alternates, with multiple alternates per character. This is basically how salt was defined by Adobe, and ssXX by Tiro:

    salt: "The 'salt' table maps GIDs for default forms to one or more GIDs for corresponding stylistic alternatives. While many of these substitutions are one-to-one (GSUB lookup type 1), others require a selection from a set (GSUB lookup type 3)."

    ssXX: "Glyphs in stylistic sets may be designed to harmonise visually, interract in particular ways, or otherwise work together."

    It would certainly make sense for a font with ssXX features to also provide access to the same glyphs via the salt feature.

    What's less clear is how applications should handle successive feature selection by the user. E.g., the user applies ss01 across a paragraph. Then in the UI they activate a glyph palette to select a glyph from all alternates for a character (salt). Should the text formatting on that character include both features, ss01 + salt, or only salt? To some extent, it may not matter, depending on how fonts are designed: If both salt and ssXX are supported for glyphs of some character, and if the lookups for salt are ordered to precede the lookups for ssXX, then the scenario would work whether the app applies both features to the given character or turns off ss01 while turning on salt. Note this in the feature description for ssXX:

    "font developers are responsible for ordering substitution lookups to obtain desired user experience"
  • Mark Simonson
    Mark Simonson Posts: 1,739
    edited May 2020
    Adobe illustrator does not support stylistic set but salt and Indesign is the other way around. So to be able to access the alternate in both apps, you need to put them in both features. 

    This used to be true, but as of a couple of years ago, both Illustrator and InDesign have support for both Stylistic Alternates (salt) and Stylistic Sets.

    Illustrator's Stylistic Alternates button is as useless as ever, only allowing access to the first alternate character if there is more than one. In both apps, you can see all Stylistic Alternates in the Glyph palette using the filter popup menu. Illustrator added a popup menu on its OpenType palette that lets you choose Stylistic Sets.

    Photoshop can access Stylistic Sets through its Glyph palette, but not Stylistic Alternates.

    OpenType support in all three apps is much better than it used to be.
  • mauro sacchetto
    mauro sacchetto Posts: 353
    It seems very sensible to me that a stylistic set has a common denominator. However, I often saw in the same set a jumble of variables that united, for example, the open Greek theta and the Latin w with three vertices instead of four. And it is not clear why, if I simply want open theta, I must also find a different w in the text. Obviously there is a margin of discretion, as it seems to me also in the management of ligatures. For example, I have inserted the ligature f_j in liga and not in dlig, but here too the choices diverge
  • Thomas Phinney
    Thomas Phinney Posts: 2,899
    mauro sacchetto said:
    It seems very sensible to me that a stylistic set has a common denominator. However, I often saw in the same set a jumble of variables...
    That is just an error, or a hack workaround for lack of 'salt' support.

    With current apps and browsers, there is no longer much excuse for this sort of thing.
  • Peter Baker
    Peter Baker Posts: 190
    @Thomas Phinney : I don't suppose you're including MS Word among "current apps." With Word not supporting salt or smcp or much else besides ssNN and calt, and a vast number of users using Word and nothing else, it's a temptation to devote one ssNN to the provision of at least the first of the alternates in salt, which users would otherwise have no access to at all.

    To my mind, Word is the single greatest obstacle to the widespread use (and understanding) of the OT features of modern fonts.
  • Thomas Phinney
    Thomas Phinney Posts: 2,899
    Yes, Word isn’t really there yet. It doesn’t fully support ssNN even, as the user can’t activate more than one set.
  • mauro sacchetto
    mauro sacchetto Posts: 353
    edited May 2020
    I managed to produce the substitutions I wanted between monotonic and polytonic so that they work perfectly with Latex.
    In LibreOffice (I work on Linux) I have not found a way.
    LibreOffice laboriously supports some features, and more than one at the same time. For example I can switch from lining numbers to small cap numbers by putting the cursor in the font window and adding the string <:onum> to the end of the font name. Similarly for small caps. You can also activate multiple lookups with the <&>: <:onum&smcp&dlig>.
    In the case of the Greek, instead it is a 'locl' which, by this method, I was unable to activate. Adding <:locl> does not produce infact any results. I will do other experiments, because I don't know how to tell to LibreOffice that I'm using polytonic rather than monotonic Greek

    PS
    Consider this, even if rather old, article:
    http://www.scholarsfonts.net/Using_OT_in_LibreOffice_1-2.pdf
  • Khaled Hosny
    Khaled Hosny Posts: 289
    mauro sacchetto said:

    In the case of the Greek, instead it is a 'locl' which, by this method, I was unable to activate. Adding <:locl> does not produce infact any results. I will do other experiments, because I don't know how to tell to LibreOffice that I'm using polytonic rather than monotonic Greek
    For language-specific substitution to work, you need to pass the correct language to the layout engine. LibreOffice supports setting text language, but it does not seem to have entry for Polytonic Greek, but fortunately it can take BCP 47 language code directly and entering el-polyton seems to work. Alternatively, if you won’t want to change the check spelling language, you can use lang=el-polyton font feature which also works.



  • Peter Baker
    Peter Baker Posts: 190
    mauro sacchetto said:

    LibreOffice laboriously supports some features, and more than one at the same time. For example I can switch from lining numbers to small cap numbers by putting the cursor in the font window and adding the string <:onum> to the end of the font name. Similarly for small caps. You can also activate multiple lookups with the <&>: <:onum&smcp&dlig>.

    The current version of LibreOffice (for Mac, and I suppose for other OSes) has a "Features" button in the "Character" dialog that opens a nice GUI for selecting OT features, with a preview at the bottom. Some things are still missing (for example, it doesn't display the names associated with Stylistic Sets), but it's much more convenient than adding suffixes to the font name.

    LibreOffice writer (unlike a certain popular word processor I could name) has features on by default that should be on: ccmp, calt, liga, locl. You should never have to turn locl on.

  • mauro sacchetto
    mauro sacchetto Posts: 353
    edited May 2020
    True, so far I had never noticed! It is also possible, using styles, to "fix" these lookups so that, once the font is selected, they are adopted by default.
    LibreOffice in this is superior to those "certain popular word processors" to which @PeterBaker alludes :)
    I work on Linux, it's features are actually present in this version too. I attach a screenshot



    1.
    However, I have not been able to find 'locl' in this window. Which extended entry does it correspond to?

    2.
    Another strange thing is that if I select <Elzevirian numbers> (those that today, with a less obsolete expression, we call oldstyle) LibreOffice produces the lining figures, but in superscript. I thing there is no error in my lookup, for the same happens with other fonts as GaramondPremierePro


  • Peter Baker
    Peter Baker Posts: 190
    1. locl is on by default, and it appears to be impossible to turn off. At least, if I append ":locl=0" to the font name, it has no effect. So, no need to put it on the GUI.

    2. This doesn't happen to me in my (slightly obsolete) Mac version of LibreOffice. You should probably leave a bug report on the LibreOffice site. (I'm just assuming that there's a place to do it there.)

  • John Hudson
    John Hudson Posts: 3,229
    It seems very sensible to me that a stylistic set has a common denominator. However, I often saw in the same set a jumble of variables that united, for example, the open Greek theta and the Latin w with three vertices instead of four.

    It's a legitimate approach for stylistic set features to have different substitutions for different scripts.
  • mauro sacchetto
    mauro sacchetto Posts: 353
    edited May 2020
    ok, thanx! Yes, it's possible to leave a bug report on bugzilla. Just made!
    https://bugs.documentfoundation.org/show_bug.cgi?id=132927
  • mauro sacchetto
    mauro sacchetto Posts: 353
    @KhaledHosny
    Thanx for your suggestion.
    el-polyton doesn't work on my system, lang=el-polyton works fine
  • Peter Baker
    Peter Baker Posts: 190
    John Hudson said:

    It's a legitimate approach for stylistic set features to have different substitutions for different scripts.

    I don't immediately see a way to have different name table entries for different scripts. Is that possible?
  • Peter Constable
    Peter Constable Posts: 210
    Peter Baker said:

    I don't immediately see a way to have different name table entries for different scripts. Is that possible?
    For general use of the name table,* then it doesn't allow for different entries for different scripts. However, it does allow for different entries for different languages. 

    Having said that, the OT spec and implementations of it are about 15 years out of date in that regard: languages can be indicated in name entries only using platform-specific numeric IDs that are totally obsolete. The spec and its implementations could definitely use an update to replace obsolete numeric IDs with a mechanism that leverages BCP 47 tags.

    Clarification: A format 1 name table was added in OT 1.6 to incorporate use of BCP 47 tags. In retrospect, it wasn't the best possible design (I think a better design would also do something with OT Layout language systems), and AFAIK no tools or platforms have ever supported it. So, in practice, we're still left with 1990s-era numeric IDs.

    This is certainly one of those areas I'd like to see improved in the OT spec.

    ----
    Notes:
    * If we were talking about strings referenced in a feature parameters table for a feature like ssXX, then the answer is, Yes: OT Layout features are organized in the GSUB and GPOS tables in script/language-system/feature hierarchies. So, suppose a font has OTL data for (say) Latin and Greek; and suppose for both scripts it supports the ss01 feature. The ss01 feature table for Latin and the ss01 feature table for Greek could be one and the same table, but they also could be two different tables:

    script: grek / langsys: <dflt> / ss01 feature table @ offsetA
    script: latn / langsys: <dflt> /ss01 feature table @offsetB

    If those are different feature tables, then they could have independent feature param tables with different name IDs specified. In that way, then, there would be different ss01 name entries for the different scripts.  
  • John Hudson
    John Hudson Posts: 3,229
    Yes, that's what I would presume: lookups separated by script, and each with its own feature parameters entries.
  • mauro sacchetto
    mauro sacchetto Posts: 353
    edited May 2020
    KhaledHosny 
    Where did you find that  BCP 47 Language Codes?
    Is there a variant for ancient Greek too?
  • Peter Constable
    Peter Constable Posts: 210
    mauro sacchetto said:
    KhaledHosny 
    Where did you find that  BCP 47 Language Codes?
    Is there a variant for ancient Greek too?
    The registry for valid _subtags_ for use in BCP 47 is at
    https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry

    You should be familiar with the rules for how subtags are combined.

    For Ancient Greek, what's relevant is that there is a separate ISO 639 ID, which is reflected in the BCP 47 subtag registry:

    Type: language
Subtag: grc
Description: Ancient Greek (to 1453)
Added: 2005-10-16
  • John Hudson
    John Hudson Posts: 3,229
    edited May 2020 
    Description: Ancient Greek (to 1453)
    That’s an interesting definition of ‘Ancient Greek’, which is usually understood as limited to Archaic, Classical, and Hellenistic Greek. And while the fall of Constantinople in 1453 is a major event in the history of Romano-Greek civilisation, the immediate effect on the language was the spread of Greek texts and scholarship westward, and the explosion of Greek publishing spreading out from new centres in Italy.

    And, of course, Ancient Greek ≠ polytonic Greek.
  • mauro sacchetto
    mauro sacchetto Posts: 353
    edited May 2020
    I am aware of this difference.
    Among other things, if I load the polytonic option with Latex, the following appears in the log:
    /usr/local/texlive/2020/texmf-dist/tex/generic/hyph-utf8/loadhyph/loadhyph-el-polyton.tex

UTF-8 Hyphenation patterns for multi-accent (polytonic) Modern Greek<br>
    But then to activate an 'locl' lookup for ancient Greek is it the string <grek{PGR}> still valid? Or is there a more suitable way?

Categories