A (very) simple question about OpenType Stylistic Sets

piccic's picture

Although I have read about the issue occasionally in a few threads, I am unsure about this question:
Stylistic sets are ideally created to address a range of glyphs substitution, and I also think it works better to use them for full range substitutions (i.e. Swashed forms, Mediaeval forms, etc.)
Inversely, I may just wish to have a single alternate glyph, which may allow the user to have – let's say — a more traditional [t] than the one I have decided to be standard.

In these cases, how do you think it's better to place that simple alternate?
I know some designers (for example, Karsten), like the idea of using Stylistic Sets as well, even for a single glyph, but I'm not so attracted by this "multiplication of the sets"… :)
Would it be fine to use [salt], or maybe I could just include the glyph and not address the automatic handling of the substitution?
After all, in lead we just entered the single alternates manually… :=)

twardoch's picture


you don't have to grab anything. If you install FOG 5, the files will automatically become available in FLS 5. The files reside in the same shared folder. If you open any VFBs, the new .nam files will only have an effect if you choose Generate Unicode or Generate Names.


blokland's picture

André: [...] I assume you were involved in the conference [....]

All FM conferences so far were organized by DTL, so I was indeed involved in the conference at The Hague.

sub s' @Letters by s.hist; # s.hist = long s

To be honest, I have not seen the other discussion in question, but I can imagine the preservation of the Unicode value of the s for exchangebility reasons (there was also a discussion on the ‘hist’ feature and related ligature stuff on the ATypI list recently, but I did not find time to look at it yet). Glyph variants like s.hist should be left unencoded by definition, of course (otherwise the use of s.hist here instead of longs would not make sense either).

At the conference Jürgen (Dr. Willrodt) did not discuss this topic specifically. You can watch his talk at River Valley TV (around the 20th minute the PDF page in question shows up). I will forward your question to him, by the way.

As Adam pointed out, using ‘uniXXXX’ entries instead of ‘AGLFN’ names can prevent problems under older Mac OSes. My problem is that working on the features files, character layout files and kerning pairs is not easy with the non-descriptive ‘uniXXXX’ naming, so I made simple AppleScript files that translate (in BBEdit) the entries in forenamed files from ‘AGLFN’ to ‘uniXXXX’ naming and vice-versa.


dezcom's picture

Thanks, Adam!!!

@blokland: That is a great idea, Frank! I have been using an Excel file I made with columns for each class being substituted along with an extra column which has the descriptive name. I can check row by row for compatibility and use line count to ensure equal entries but your way is WAY better!

twardoch's picture

I've just come up with a workaround how to rename glyphs (e.g. through Generate Names) including making the changes inside of the OpenType features definitions, completely within FontLab Studio 5, without using any scripts. It's not a superbly polished solution, but it works well.

1. In Preferences / Opening OpenType & TrueType, enable "Store binary OpenType layout tables".
2. Generate the .vfb font as .otf or .ttf.
3. In the .vfb font file, choose Glyph / Glyph Names / Generate Names.
4. Open the newly-generated .otf, and there, choose Glyph / Glyph Names / Generate Names.
5. Generate the newly-opened .otf again as .otf, and in the dialog box that appears, choose "Binary".
6. Close this font and open it again: note that in the OpenType panel and in the Classes panel, the data now uses the new glyph names.
7. Save the features into a file from the OpenType panel, and save the classes into a file from the Classes panel.
8. Close this font and go back to the original .vfb file.
9. Open the newly saved classes and features using the Classes panel and the OpenType panel.

This way, you'll have the classes and the OpenType feature definitions that use the new glyph names.

It's not very elegant but it works.


dezcom's picture

Bless you, my son!

agisaak's picture

Thanks for your reply,

I was unable to locate the thread in question. It didn't specifically have to do with historical forms but something similar. IIRC it involved a use of the 'sups' feature which mapped one to onesuperior rather than mapping one to one.sups.

The discussion in the handout you posted, though, seemed to suggest it was appropriate to map s to (encoded) longs rather than (unencoded) s.hist (sorry if the naming error in my earlier post caused confusion).

It seems that having GSUB lookups which convert characters to other characters rather than simply mapping from glyphs to glyphs is frowned on by many. However, while while poking around on Adobe's site I found the following in the description of the 'mgrk' feature:

Example: The user applies this feature to U+03A3 (Sigma), and gets U+2211 (summation).

Which would seem to suggest that this isn't strictly forbidden.


dezcom's picture

"U+03A3 (Sigma), and gets U+2211 (summation)."

If you name the glyphs as you stated and the unicoode values properly for each, how could that happen? I assume you would put both glyphs in the font. I do this (include both) for some other Greek, Omega, and the math version as well

agisaak's picture

I've never used this feature, but the description suggests you'd simply have the following:

feature mgrk { # Math Greek

    sub Sigma by summation;
    sub Pi by product;
    # etc.

} mgrk;

The description suggests that Adobe is advocating the above rather than

feature mgrk { # Math Greek

    sub Sigma by Sigma.mgrk;
    sub Pi by Pi.mgrk;
    # etc.

} mgrk;

which would seem to contradict the view that GSUB rules should only perform glyph substitution and never character substitution.


twardoch's picture

"mgrk" is one of the OpenType features that are in the spec, but are discouraged from being used. They are not actually being used in any Adobe fonts made in the last yen years. I think the feature should be removed (similarly to what was done to "dpng" some years ago).


Thomas Phinney's picture

As Adam says, 'mgrk' is deprecated, much like 'crcy' and 'dpng', precisely because it does seem likely to be used to enact what ought to be done by a change in codepoint.



quadibloc's picture

From the documentation on the ss tags, ss03, for example, can remap characters in ss01 and ss02 as well as from the default set. So ss20 has the highest priority, then ss19, and so on.

So one could have lining figures as the default, regular oldstyle figures as ss01, and an alternate short 1 that looks like a lining 1 instead of a small-cap I in ss02.

The problem is now "solved" except for applications in which there is no way to enable or disable any of these features. I would recommend font designers to make all their glyphs available as just plain characters in the Private Use area in addition to having the fancy processing for normal characters.

twardoch's picture

> so ss20 has the highest priority, then ss19, and so on.


You're wrong. The priority between different user-controlled OpenType Layout features is determined by the order of the lookups in the font. In one font, you can have "liga" to have higher priority than "smcp", and "ss01" have a higher priority than "ss20", and in another font this can be exactly the other way around. If features use multiple lookups, then those can interweave: one lookup from the "ss01" feature is processed, then a lookup from "ss20", then again one from "ss01".

There is no "canonical order" for any of the user-controllable features in the OpenType spec. It is the font developer who decides on the priorities within a font. The rule is, that some features (ccmp, locl) are applied before the script shaping, then the script shaping features are applied (this is done differently for each script, and each script shaping engine automatically picks the appropriate features), and then finally, the user-controllable features enabled by the user are applied in the order of the lookups defined in the font.

Syndicate content Syndicate content