Can you be more specific? What version of InDesign are you using? What kind of computer and OS? Is there a particular glyph or glyphs with which you are seeing this? Is it in Roman fonts, Italic fonts, or both?

I want an | a | glyph alternate and yes it exists. When I turn it on in opentype options in indesign it won't work.
In the end what action does turn on stylistic alternates?

I got it via pressing alternate a glpyh ( stylistic)
Windows XP; indesign cs2.

This is in illustrator

In InDesign, stylistic alternates are acessed through the glyph palette. You can, for example, find the regular 'a' in the palette and select its available alternates from the "flyout" menu of the letter itself. Unlike Illustrator, there is no way to "apply" the feature with a button or menu item.

Does that answer your question? I might be misunderstanding...

Christopher,

is there a reason why in Garamond Premier Pro, Adobe chose to include substituions of lowercase letters with their "final" forms in the "salt" (stylistic alternates) feature but did not include the same substitutions in one of the "ssXX" (stylistic set) features, e.g. ss04? Also, these glyphs are not substituted in the "fina" (final forms) feature.

Since the glyphs in question are even named "a.end", "d.end" etc., associating them with the "fina" feature would be an intuitive choice.

Please also see my contribution in the other thread devoted to stylistic alternates.

Best,
Adam

> why in Garamond Premier Pro, Adobe chose to include substituions of lowercase letters with their “final” forms in the “salt” (stylistic alternates) feature but did not include the same substitutions in one of the “ssXX” (stylistic set) features, e.g. ss04?

Am I right to believe that you think it would be a good idea if you could replace ALL the letters in a paragraph with their final forms, by simply applying one (or more) stylistic set(s)? Does the image below make any sense to you?

> Also, these glyphs are not substituted in the “fina” (final forms) feature.
Since the glyphs in question are even named “a.end”, “d.end” etc., associating them with the “fina” feature would be an intuitive choice.

Really? What happens if the apps decide to follow the spec for 'fina' and make it active by default? Would you be happy to have to turn it off every time, because your text simply looks like this?:

> Does the image below make any sense to you?

Ah! This is the image I get if I apply "stylistic alternate" in Illustrator to a run of text set in Garamond Premier Pro. Of course it does not make sense, typographically, to apply "salt" to an entire paragraph as you did. Similarly, it would not make sense to apply "ordn" or "subs" to an entire paragraph. The user applies these features on his or her discretion, to the glyphs he or she needs.

There are numerous fonts out there which have stylistic sets that don’t work well when applied to entire words.

Take Robert Slimbach’s wonderful creation, Poetica Std:

Am I suggesting that one should apply ss07 to an entire word or paragraph?

Or ss11?

Not really. One needs to apply the sets selectively, letter by letter.

Still, you have not explained why something that is doable in Illustrator (apply salt to one, two or three letters at a time) should not be doable in InDesign (apply an ssXX to the same glyphs to produce an analogous effect).

Poetica includes both a "sub A from [A.1 A.2 A.3 ...]"-style salt feature and eleven "sub A by A.1"-style ssXX sets. Garamond Premier Pro does it otherwise. Why?

Regards,
Adam

> Of course it does not make sense, typographically, to apply “salt” to an entire paragraph as you did.

No, what I did was to simulate the effect of including the same substitutions (present in 'salt') in one Stylistic Set, as you suggested.

> Similarly, it would not make sense to apply “ordn” or “subs” to an entire paragraph. The user applies these features on his or her discretion, to the glyphs he or she needs.

From this I infer that you understand the differences between 'salt' and 'ssXX', and how they're NOT the same thing. The 'salt' feature is designed to be applied at the user's discretion — in the sense that he/she has the freedom to decide what should be done in a particular situation — whereas 'ssXX' is designed to be applied throughout and make changes to a wide range of elements without requiring the user's decision about every single one of them.

> There are numerous fonts out there which have stylistic sets that don’t work well when applied to entire words.

I consider that a bad implementation/usage of stylistic sets.

> Not really. One needs to apply the sets selectively, letter by letter.

The appropriate feature to achieve such behavior is 'salt', not 'ssXX'.

> Still, you have not explained why something that is doable in Illustrator (apply salt to one, two or three letters at a time) should not be doable in InDesign (apply an ssXX to the same glyphs to produce an analogous effect).

You've already answer that yourself: "[...] it does not make sense, typographically [...]".

> Poetica includes both a “sub A from [A.1 A.2 A.3 …]”-style salt feature and eleven “sub A by A.1”-style ssXX sets. Garamond Premier Pro does it otherwise. Why?

I was not involved in the development of neither Poetica or Garamond Premier, so I can't say what thoughts went into them. But my view is, when Poetica was developed the ideas behind OpenType features and their implementations in the applications were not as mature as they were by the time when Garamond Premier was developed. Technically wise, Garamond Premier might embody more best practices than Poetica does. That's the price of being a pioneer; nothing is certain, so there's a good chance of not getting it right at the first time.

Miguel,

the feature description for ss01–ss20 cites Poetica as an example. Are you saying that when ssXX was conceived, with Poetica being used as an example, Poetica actually was a bad implementation of the ssXX idea, because actually the idea was something else which however could not be exemplified at the time of the writing of the ssXX feature description by anything better than Poetica, which was a bad implementation of the idea but nonetheless is the one cited as an example?

> The appropriate feature to achieve such behavior
> [as in Poetica] is ‘salt’, not ‘ssXX’.

But what you’re saying contradicts the OpenType specification, because the OpenType specification (read my lips:) uses Poetica as an example for ssXX!!!

Am I to assume that Adobe now recommends to contradict the OpenType specification and disregard its recommendations for the ssXX feature because people who wrote up the ss01–ss20 feature description didn’t know what they were doing?

Or what exactly is it that you’re saying, please? Thank you.

A.

OK, unlike you, I didn’t "simulate" anything here. I just typeset the paragraph in Illustrator CS2 using Adobe Garamond Pro, clicked on the frame and then simply clicked on the "Stylistic Alternate" button on the OpenType palette:

An Illustrator CS2 user is able to enable or disable stylistic alternates on a per-glyph basis, but also on entire words, sentences, paragraphs or text frames. It is up to the user’s discretion to do or not to do this.

Similarly, an InDesign CS2 user is able to enable or disable stylistic sets on a per-glyph basis, but also on entire words, sentences, paragraphs or text frames. It is up to the user’s discretion to do or not to do this. The difference between Illustrator and InDesign is that the first gives you just one alternate and the second gives you up to twenty. Right?

A.

If we could redo Poetica's features today, we'd probably do a different combination of 'salt' and 'ssXX'. One possible solution comes to mind:

feature salt {
sub A from [A.1 A.2 A.3];
sub B from [B.1 B.2 B.3];
sub C from [C.1 C.2 C.3];
...
sub Z from [Z.1 Z.2 Z.3];
} salt;

feature ss01 { # 1 -> 2
sub [A.1 B.1 C.1 ... Z.1] by [A.2 B.2 C.2 ... Z.2];
} ss01;

feature ss02 { # 1 -> 3
sub [A.1 B.1 C.1 ... Z.1] by [A.3 B.3 C.3 ... Z.3];
} ss02;

feature ss03 { # 2 -> 1
sub [A.2 B.2 C.2 ... Z.2] by [A.1 B.1 C.1 ... Z.1];
} ss03;

feature ss04 { # 2 -> 3
sub [A.2 B.2 C.2 ... Z.2] by [A.3 B.3 C.3 ... Z.3];
} ss04;

feature ss05 { # 3 -> 1
sub [A.3 B.3 C.3 ... Z.3] by [A.1 B.1 C.1 ... Z.1];
} ss05;

feature ss06 { # 3 -> 2
sub [A.3 B.3 C.3 ... Z.3] by [A.2 B.2 C.2 ... Z.2];
} ss06;

In other words, the user would be able to switch between the different "flavors" of Poetica via 'ssXX', but first he/she would need to specify where he/she would like to see an alternate form, via 'salt'.

Miguel,

Poetica includes up to 9 alternate variants for each uppercase letter. You'd quickly run out of the 20 ssXX sets if you do it your way.

Each of these variants forms a *set* across the alphabet, i.e. the D.swash5 glyph is of the same stylistic flavor as R.swash5 but of different flavor than R.swash8. So the way Poetica is implemented now actually makes perfect sense in the ssXX world, and makes sense in the salt world.

Also, while InDesign implements ssXX on an additive basis, Mac OS X’s Cocoa implementation is mutually exclusive. Poetica works well in the mutually exclusive world as well as in the additive world.

> If we could redo Poetica’s features today, we’d probably
> do a different combination of ‘salt’ and ‘ssXX’. One
> possible solution comes to mind:

Try another, something along the lines of:

feature salt {
sub A from [A.1 A.2 A.3 ... A.9];
sub B from [B.1 B.2 B.3 ... B.9];
sub C from [C.1 C.2 C.3 ... C.9];
...
sub Z from [Z.1 Z.2 Z.3 ... Z.9];
} salt;

feature ss01 {
sub [A B C ... Z] by [A.1 B.1 C.1 ... Z.1];
sub [A.1 B.1 C.1 ... Z.1] by [A.2 B.2 C.2 ... Z.2];
sub [A.2 B.2 C.2 ... Z.2] by [A.3 B.3 C.3 ... Z.3];
sub [A.3 B.3 C.3 ... Z.3] by [A.4 B.4 C.4 ... Z.4];
...
sub [A.9 B.9 C.9 ... Z.9] by [A B C ... Z];
} ss01;

feature ss02 {
sub [A B C ... Z] by [A.2 B.2 C.2 ... Z.2];
sub [A.1 B.1 C.1 ... Z.1] by [A.3 B.3 C.3 ... Z.3];
sub [A.2 B.2 C.2 ... Z.2] by [A.4 B.4 C.4 ... Z.4];
sub [A.3 B.3 C.3 ... Z.3] by [A.5 B.5 C.5 ... Z.5];
...
sub [A.9 B.9 C.9 ... Z.9] by [A.1 B.1 C.1 ... Z.1];
} ss02;

feature ss03 {
sub [A B C ... Z] by [A.3 B.3 C.3 ... Z.3];
sub [A.1 B.1 C.1 ... Z.1] by [A.4 B.4 C.4 ... Z.4];
sub [A.2 B.2 C.2 ... Z.2] by [A.5 B.5 C.5 ... Z.5];
sub [A.3 B.3 C.3 ... Z.3] by [A.6 B.6 C.6 ... Z.6];
...
sub [A.9 B.9 C.9 ... Z.9] by [A.2 B.2 C.2 ... Z.2];
} ss09;

...

feature ss09 {
sub [A B C ... Z] by [A.9 B.9 C.9 ... Z.9];
sub [A.1 B.1 C.1 ... Z.1] by [A B C ... Z];
sub [A.2 B.2 C.2 ... Z.2] by [A.1 B.1 C.1 ... Z.1];
sub [A.3 B.3 C.3 ... Z.3] by [A.2 B.2 C.2 ... Z.2];
...
sub [A.9 B.9 C.9 ... Z.9] by [A.8 B.8 C.8 ... Z.8];
} ss09;

The idea is that without any manually-applied salt, the user would switch everything to 1st set by applying ss01, to 2nd set by applying ss02, to 3rd set by applying ss03 etc. If the user had manually applied some stylistic alternates to some glyphs in his font, applying any of the ssXX features would still "upgrade" or "spice up" his entire text "by one set up". And additive combination of the sets would have a yet more "accelerating" effect.

A.

> Are you saying that when ssXX was conceived, with Poetica being used as an example, Poetica actually was a bad implementation of the ssXX idea

That's possible. My view is that the implementation in Poetica doesn't seem consistent with the result we expect, nowadays, when applying a Stylistic Set.

> But what you’re saying contradicts the OpenType specification, because the OpenType specification (read my lips:) uses Poetica as an example for ssXX!!!

Dear Adam, you know, better than me, that some aspects of OpenType spec would benefit from a revision, to bring it up to date with our (as a community) current understanding and usage of the technology.

> Am I to assume that Adobe now recommends to contradict the OpenType specification and disregard its recommendations for the ssXX feature because people who wrote up the ss01–ss20 feature description didn’t know what they were doing?

No. The people that initially wrote it had *very* good and well intentioned ideas, and knew perfectly well what they were doing. Nonetheless, with time ideas get more mature, and I'm of the opinion that some definitions in the OT spec would benefit from being polished and clarified.

Take the 'rand' (Randomize) feature as an example; it is an excellent idea! Will it ever be implemented? Probably not. Why? Because after all these years we (and I mean font developers and app developers) realized that we can achieve the same result with 'calt'.

If anyone wants to try this as a proof-of-concept (including you Miguel), below is a more complete code snippet for a Poetica Std "2.0". If you own PoeticaStd.otf, open it in FontLab Studio 5, remove the existing feature code and replace it with the code below. Compile the features. FontLab Studio will ask you to create a bunch of "O" glyphs (because there are less O swashes than other glyphs, but let's disregard it for now) -- approve it.

Once the features are generated, in the OpenType Features preview panel check the test word:

/W.swash2/A/N/A.swash5/W/A/N.swash3/D/A.swash1

(This simulates a text string with manually inserted salt alternates). Make sure you apply the kern feature.

Then apply ssXX features mutually-exclusively, or additively. You will see that the entire text moves "up and down" within the respective sets, but maintaining the "set distances" between the manually-inserted altnerates:

Adam

@ss00 = [A B C D E F G H I J K L M N O P Q R S T U V W X Y Z];
@ss01 = [A.swash1 B.swash1 C.swash1 D.swash1 E.swash1 F.swash1 G.swash1 H.swash1 I.swash1 J.swash1 K.swash1 L.swash1 M.swash1 N.swash1 O.swash1 P.swash1 Q.swash1 R.swash1 S.swash1 T.swash1 U.swash1 V.swash1 W.swash1 X.swash1 Y.swash1 Z.swash1];
@ss02 = [A.swash2 B.swash2 C.swash2 D.swash2 E.swash2 F.swash2 G.swash2 H.swash2 I.swash2 J.swash2 K.swash2 L.swash2 M.swash2 N.swash2 O.swash2 P.swash2 Q.swash2 R.swash2 S.swash2 T.swash2 U.swash2 V.swash2 W.swash2 X.swash2 Y.swash2 Z.swash2];
@ss03 = [A.swash3 B.swash3 C.swash3 D.swash3 E.swash3 F.swash3 G.swash3 H.swash3 I.swash3 J.swash3 K.swash3 L.swash3 M.swash3 N.swash3 O.swash3 P.swash3 Q.swash3 R.swash3 S.swash3 T.swash3 U.swash3 V.swash3 W.swash3 X.swash3 Y.swash3 Z.swash3];
@ss04 = [A.swash4 B.swash4 C.swash4 D.swash4 E.swash4 F.swash4 G.swash4 H.swash4 I.swash4 J.swash4 K.swash4 L.swash4 M.swash4 N.swash4 O.swash4 P.swash4 Q.swash4 R.swash4 S.swash4 T.swash4 U.swash4 V.swash4 W.swash4 X.swash4 Y.swash4 Z.swash4];
@ss05 = [A.swash5 B.swash5 C.swash5 D.swash5 E.swash5 F.swash5 G.swash5 H.swash5 I.swash5 J.swash5 K.swash5 L.swash5 M.swash5 N.swash5 O.swash5 P.swash5 Q.swash5 R.swash5 S.swash5 T.swash5 U.swash5 V.swash5 W.swash5 X.swash5 Y.swash5 Z.swash5];
@ss06 = [A.swash6 B.swash6 C.swash6 D.swash6 E.swash6 F.swash6 G.swash6 H.swash6 I.swash6 J.swash6 K.swash6 L.swash6 M.swash6 N.swash6 O.swash6 P.swash6 Q.swash6 R.swash6 S.swash6 T.swash6 U.swash6 V.swash6 W.swash6 X.swash6 Y.swash6 Z.swash6];
@ss07 = [A.swash7 B.swash7 C.swash7 D.swash7 E.swash7 F.swash7 G.swash7 H.swash7 I.swash7 J.swash7 K.swash7 L.swash7 M.swash7 N.swash7 O.swash7 P.swash7 Q.swash7 R.swash7 S.swash7 T.swash7 U.swash7 V.swash7 W.swash7 X.swash7 Y.swash7 Z.swash7];
@ss08 = [A.swash8 B.swash8 C.swash8 D.swash8 E.swash8 F.swash8 G.swash8 H.swash8 I.swash8 J.swash8 K.swash8 L.swash8 M.swash8 N.swash8 O.swash8 P.swash8 Q.swash8 R.swash8 S.swash8 T.swash8 U.swash8 V.swash8 W.swash8 X.swash8 Y.swash8 Z.swash8];
@ss09 = [A.swash9 B.swash9 C.swash9 D.swash9 E.swash9 F.swash9 G.swash9 H.swash9 I.swash9 J.swash9 K.swash9 L.swash9 M.swash9 N.swash9 O.swash9 P.swash9 Q.swash9 R.swash9 S.swash9 T.swash9 U.swash9 V.swash9 W.swash9 X.swash9 Y.swash9 Z.swash9];

feature salt {
sub A from [A.swash1 A.swash2 A.swash3 A.swash4 A.swash5 A.swash6 A.swash7 A.swash8 A.swash9];
sub B from [B.swash1 B.swash2 B.swash3 B.swash4 B.swash5 B.swash6 B.swash7 B.swash8 B.swash9];
sub C from [C.swash1 C.swash2 C.swash3 C.swash4 C.swash5 C.swash6 C.swash7 C.swash8 C.swash9];
sub D from [D.swash1 D.swash2 D.swash3 D.swash4 D.swash5 D.swash6 D.swash7 D.swash8 D.swash9];
sub E from [E.swash1 E.swash2 E.swash3 E.swash4 E.swash5 E.swash6 E.swash7 E.swash8 E.swash9];
sub F from [F.swash1 F.swash2 F.swash3 F.swash4 F.swash5 F.swash6 F.swash7 F.swash8 F.swash9];
sub G from [G.swash1 G.swash2 G.swash3 G.swash4 G.swash5 G.swash6 G.swash7 G.swash8 G.swash9];
sub H from [H.swash1 H.swash2 H.swash3 H.swash4 H.swash5 H.swash6 H.swash7 H.swash8 H.swash9];
sub I from [I.swash1 I.swash2 I.swash3 I.swash4 I.swash5 I.swash6 I.swash7 I.swash8 I.swash9];
sub J from [J.swash1 J.swash2 J.swash3 J.swash4 J.swash5 J.swash6 J.swash7 J.swash8 J.swash9];
sub K from [K.swash1 K.swash2 K.swash3 K.swash4 K.swash5 K.swash6 K.swash7 K.swash8 K.swash9];
sub L from [L.swash1 L.swash2 L.swash3 L.swash4 L.swash5 L.swash6 L.swash7 L.swash8 L.swash9];
sub M from [M.swash1 M.swash2 M.swash3 M.swash4 M.swash5 M.swash6 M.swash7 M.swash8 M.swash9];
sub N from [N.swash1 N.swash2 N.swash3 N.swash4 N.swash5 N.swash6 N.swash7 N.swash8 N.swash9];
sub O from [O.swash1 O.swash2 O.swash3 O.swash4 O.swash5 O.swash6 O.swash7 O.swash8 O.swash9];
sub P from [P.swash1 P.swash2 P.swash3 P.swash4 P.swash5 P.swash6 P.swash7 P.swash8 P.swash9];
sub Q from [Q.swash1 Q.swash2 Q.swash3 Q.swash4 Q.swash5 Q.swash6 Q.swash7 Q.swash8 Q.swash9];
sub R from [R.swash1 R.swash2 R.swash3 R.swash4 R.swash5 R.swash6 R.swash7 R.swash8 R.swash9];
sub S from [S.swash1 S.swash2 S.swash3 S.swash4 S.swash5 S.swash6 S.swash7 S.swash8 S.swash9];
sub T from [T.swash1 T.swash2 T.swash3 T.swash4 T.swash5 T.swash6 T.swash7 T.swash8 T.swash9];
sub U from [U.swash1 U.swash2 U.swash3 U.swash4 U.swash5 U.swash6 U.swash7 U.swash8 U.swash9];
sub V from [V.swash1 V.swash2 V.swash3 V.swash4 V.swash5 V.swash6 V.swash7 V.swash8 V.swash9];
sub W from [W.swash1 W.swash2 W.swash3 W.swash4 W.swash5 W.swash6 W.swash7 W.swash8 W.swash9];
sub X from [X.swash1 X.swash2 X.swash3 X.swash4 X.swash5 X.swash6 X.swash7 X.swash8 X.swash9];
sub Y from [Y.swash1 Y.swash2 Y.swash3 Y.swash4 Y.swash5 Y.swash6 Y.swash7 Y.swash8 Y.swash9];
sub Z from [Z.swash1 Z.swash2 Z.swash3 Z.swash4 Z.swash5 Z.swash6 Z.swash7 Z.swash8 Z.swash9];
} salt;

feature ss01 {
sub @ss00 by @ss01;
sub @ss01 by @ss02;
sub @ss02 by @ss03;
sub @ss03 by @ss04;
sub @ss04 by @ss05;
sub @ss05 by @ss06;
sub @ss06 by @ss07;
sub @ss07 by @ss08;
sub @ss08 by @ss09;
sub @ss09 by @ss00;
} ss01;

feature ss02 {
sub @ss00 by @ss02;
sub @ss01 by @ss03;
sub @ss02 by @ss04;
sub @ss03 by @ss05;
sub @ss04 by @ss06;
sub @ss05 by @ss07;
sub @ss06 by @ss08;
sub @ss07 by @ss09;
sub @ss08 by @ss00;
sub @ss09 by @ss01;
} ss02;

feature ss03 {
sub @ss00 by @ss03;
sub @ss01 by @ss04;
sub @ss02 by @ss05;
sub @ss03 by @ss06;
sub @ss04 by @ss07;
sub @ss05 by @ss08;
sub @ss06 by @ss09;
sub @ss07 by @ss00;
sub @ss08 by @ss01;
sub @ss09 by @ss02;
} ss03;

feature ss04 {
sub @ss00 by @ss04;
sub @ss01 by @ss05;
sub @ss02 by @ss06;
sub @ss03 by @ss07;
sub @ss04 by @ss08;
sub @ss05 by @ss09;
sub @ss06 by @ss00;
sub @ss07 by @ss01;
sub @ss08 by @ss02;
sub @ss09 by @ss03;
} ss04;

feature ss05 {
sub @ss00 by @ss05;
sub @ss01 by @ss06;
sub @ss02 by @ss07;
sub @ss03 by @ss08;
sub @ss04 by @ss09;
sub @ss05 by @ss00;
sub @ss06 by @ss01;
sub @ss07 by @ss02;
sub @ss08 by @ss03;
sub @ss09 by @ss04;
} ss05;

feature ss06 {
sub @ss00 by @ss06;
sub @ss01 by @ss07;
sub @ss02 by @ss08;
sub @ss03 by @ss09;
sub @ss04 by @ss00;
sub @ss05 by @ss01;
sub @ss06 by @ss02;
sub @ss07 by @ss03;
sub @ss08 by @ss04;
sub @ss09 by @ss05;
} ss06;

feature ss07 {
sub @ss00 by @ss07;
sub @ss01 by @ss08;
sub @ss02 by @ss09;
sub @ss03 by @ss00;
sub @ss04 by @ss01;
sub @ss05 by @ss02;
sub @ss06 by @ss03;
sub @ss07 by @ss04;
sub @ss08 by @ss05;
sub @ss09 by @ss06;
} ss07;

feature ss08 {
sub @ss00 by @ss08;
sub @ss01 by @ss09;
sub @ss02 by @ss00;
sub @ss03 by @ss01;
sub @ss04 by @ss02;
sub @ss05 by @ss03;
sub @ss06 by @ss04;
sub @ss07 by @ss05;
sub @ss08 by @ss06;
sub @ss09 by @ss07;
} ss08;

feature ss09 {
sub @ss00 by @ss09;
sub @ss01 by @ss00;
sub @ss02 by @ss01;
sub @ss03 by @ss02;
sub @ss04 by @ss03;
sub @ss05 by @ss04;
sub @ss06 by @ss05;
sub @ss07 by @ss06;
sub @ss08 by @ss07;
sub @ss09 by @ss08;
} ss09;

Ps. The implementation shown above has interesting side-effects. E.g. applying ss01, ss04 and ss05 at the same time gives you the exactly original string back. This could be made slightly more interesting if each ssXX feature for each entry glyph moved at a different pace, e.g. ss01 could replace A with A.1, B with B.1, A.1 with A.2 and A.1 with B.2, but ss05 could replace A with A.5, B with B.5, A.1 with B.7 and B.1 with B.3, or something like that. Then additively combining various sets would give you very different combinations :)

A.

> Similarly, an InDesign CS2 user is able to enable or disable stylistic sets on a per-glyph basis, but also on entire words, sentences, paragraphs or text frames. It is up to the user’s discretion to do or not to do this. The difference between Illustrator and InDesign is that the first gives you just one alternate and the second gives you up to twenty. Right?

It's true that one 'ssXX' can be seen as a subset 'salt'. In other words, 'salt' could be viewed as a 'ss00' (hypothetical Stylistic Set 0). BUT 'salt' is much more than a simple stylistic set, because it was designed to consider one-from-many (GSUB lookup type 3) substitutions as well as one-to-one (GSUB lookup type 1) substitutions, whereas 'ssXX' was only intended to be used with the latter type of substitutions.

Having said that, Illustrator's implementation of Stylistic Alternates is incomplete since it trims down 'salt' to only provide one-to-one substitutions (therefore you can only get access to the first alternate when pressing the button on the UI). And this implementation is flawed because it makes 'salt' behave like a simple 'ssXX', which subverts the initial intent of the feature. This also has the side effect of leading users to believe that the two features ('salt' & 'ss01') are the same, when in fact they were created with clear different intents of interaction in mind.

Miguel,

to me, there no apparent reason why the first set of alternates provided by salt should NOT be compatible with what ss01 offers. Of course, *in addition* salt should give the user access to *all other* alternates offered by ss01–ss20. My principle is simple: whatever is in ss01–ss20 should *always* be in salt, because salt is a superset of ss01–ss20, organized differently. salt may contain additional glyphs that are not accessible through ss01–ss20 but anything that is accessible through ssXX should also be accessible through salt.

I don’t see why salt (being "stylistic alternates") should NOT include any glyphs that are mapped to "sets of stylistic alternates", i.e. ss01–ss20.

Obviously, you know that there are two ways to access salt in Illustrator: "wide" and "deep". The "wide" access through the "Stylistic Alternate" switch in the OpenType palette only gives access to the first alternate but can be applied to an arbitrarily long text. The "deep" access through the Glyph palette gives access to any alternates for a single glyph but can only be applied on a per-glyph basis.

I think this is actually pretty good, and does its job well. I cannot really think of a reasonable user interface that would combine the "wide" and the "deep" access at the same time.

To me, simply speaking, salt and ssXX are one and the same matrix but rotated by 90 degrees -- see table:

+———+—————————+—————————+—————————+
| — | salt(1) | salt(2) | salt(3) |
| — | —— ss01 | —— ss02 | —— ss03 |
+———+—————————+—————————+—————————+
| A | ——— A.1 | ——— A.2 | ——— A.3 |
| B | ——— B.1 | ——— B.2 | ——— B.3 |
| C | ——— C.1 | ——— C.2 | ——— C.3 |
+———+—————————+—————————+—————————+

or viewed from a different angle:

+—————————+—————————+—————+—————+—————+
| ——————— | ——————— | — A | — B | — C |
+—————————+—————————+—————+—————+—————+
| salt(1) | —— ss01 | A.1 | B.1 | C.1 |
| salt(2) | —— ss02 | A.2 | B.2 | C.3 |
| salt(3) | —— ss03 | A.3 | B.3 | C.3 |
+—————————+—————————+—————+—————+—————+

Of course, there may not be a 100% compatibility both ways if there are, say, more "B" alternates than "C" alternates because it is not possible to "skip" positions in the salt indexes. So a realistic scenario might look like:

+———+—————————+—————————+—————————+
| — | —— ss01 | —— ss02 | —— ss03 |
+———+—————————+—————————+—————————+
| A | ——— A.1 | ——— A.2 | ——— A.3 |
| B | ——— B.1 | ——————— | ——— B.3 |
| C | ——————— | ——— C.2 | ——————— |
+———+—————————+—————————+—————————+

+———+—————————+—————————+—————————+
| — | salt(1) | salt(2) | salt(3) |
+———+—————————+—————————+—————————+
| A | ——— A.1 | ——— A.2 | ——— A.3 |
| B | ——— B.1 | ——— B.3 | ——————— |
| C | ——— C.2 | ——————— | ——————— |
+———+—————————+—————————+—————————+

or viewed from a different angle:

+—————————+—————+—————+—————+
| ——————— | — A | — B | — C |
+—————————+—————+—————+—————+
| —— ss01 | A.1 | B.1 | ——— |
| —— ss02 | A.2 | ——— | C.2 |
| —— ss03 | A.3 | B.3 | ——— |
+—————————+—————+—————+—————+

+—————————+—————+—————+—————+
| ——————— | — A | — B | — C |
+—————————+—————+—————+—————+
| salt(1) | A.1 | B.1 | C.2 |
| salt(2) | A.2 | B.3 | ——— |
| salt(3) | A.3 | ——— | ——— |
+—————————+—————+—————+—————+

Of course, the corresponding feature code for that would be:

feature salt {
sub A from [A.1 A.2 A.3];
sub B from [B.1 B.3];
sub C from [C.2];
} salt;

feature ss01 {
sub [A B] by [A.1 B.1];
} ss01;

feature ss02 {
sub [A C] by [A.2 C.2];
} ss02;

feature ss03 {
sub [A B] by [A.3 B.3];
} ss03;

But I still need to hear a good reason why any ssXX alternates would not be included in salt.

A.

Your ideas for Poetica are quite interesting. But being able to change the default set of glyphs (@ss00) directly by any of the other sets still makes me uncomfortable.

In fact, I was just looking at the specimen book* and it's clear that the different sets of capitals were not designed to be interchangeable, at least not all of them. Most of the alternate capital forms are swash versions, therefore changing from plain capitals to swash capitals is a job for 'swsh', not a stylistic sets. Of course, once the basic swash form of the capitals is applied, the stylistic sets can come into play, allowing different flavors of "swashness".

Another thing I noticed is that the specimen doesn't contain any example of a word set in all caps that is as "swashed" as the examples you made. This is understandable since an all-swash-caps does not only look silly, but it's also difficult to read. The image below reproduces one example found in the booklet.

*Gorgeous! Unfortunately it's not available in PDF

> to me, there no apparent reason why the first set of alternates provided by salt should NOT be compatible with what ss01 offers.

Me neither (but to be correct I should say that an example that contradicts it doesn't occur to me right now), but what I meant was 'salt' might have much more to give than what the user gets when he/she presses the 'Stylistic Alternates' button in Illustrator's UI. And the UI doesn't make it clear to the user that he/she is only getting a subset (the first "layer") of that feature.

> Of course, *in addition* salt should give the user access to *all other* alternates offered by ss01–ss20. My principle is simple: whatever is in ss01–ss20 should *always* be in salt, because salt is a superset of ss01–ss20, organized differently. salt may contain additional glyphs that are not accessible through ss01–ss20 but anything that is accessible through ssXX should also be accessible through salt.
I don’t see why salt (being “stylistic alternates”) should NOT include any glyphs that are mapped to “sets of stylistic alternates”, i.e. ss01–ss20.

We agree on that.

Based on your tables, this is how I see it:
+—————————+—————+—————+—————+
| ——————— | ———— salt ————— |
+—————————+—————+—————+—————+
| ——————— | — A | — B | — C |
+—————————+—————+—————+—————+
| —— ss01 | A.1 | B.1 | C.1 |
| —— ss02 | A.2 | B.2 | C.3 |
| —— ss03 | A.3 | B.3 | C.3 |
+—————————+—————+—————+—————+


Using your terminology, the table shows that 'salt' has "wide" (covers A, B and C) and "deep" (can get to all alternates of A, B and C) access, whereas stylistic sets only have "wide" access, as each one is restricted to its own "layer".

> But I still need to hear a good reason why any ssXX alternates would not be included in salt.

I can't think of one. And it should be said that the opposite isn't true. This is due to the architecture/intentions of both features. 'salt' can contain the same kind of substitutions present in ssXX, but ssXX shouldn't (can't?) contain all types of substitutions that can be implemented in 'salt' (such as one-from-many).

> And it should be said that the opposite isn’t true.

I agree that not all substitutions present in salt should be present in ssXX. In many fonts they will be, but some fonts will have extra stuff in salt. This is why I suggested to develop ssXX first and then salt. This seems to be the logical sequence to me.

Adam wrote:
I don’t see why salt (being “stylistic alternates”) should NOT include any glyphs that are mapped to “sets of stylistic alternates”, i.e. ss01–ss20.

Miguel wrote:
Having said that, Illustrator’s implementation of Stylistic Alternates is incomplete since it trims down ‘salt’ to only provide one-to-one substitutions (therefore you can only get access to the first alternate when pressing the button on the UI).

Reading this thread, one question bugs me: What would an ideal implementation and UI of 'salt' in applications look like?

As to the one-by-one part:
User selects a glyph and applies 'salt' to receive an (the first) alternate for this glyph. Same for strings, maybe (if 'salt' mirrors 'ss01').
This however is like applying 'ss01' -- which makes 'salt' superfluous.

As to the one-from-many part:
User selects a glyph, and upon right-click/ctrl-click or some shortcut, a popup appears which only presents alternates for this glyph. Consider as a more 'interactive' version of the Glyph Palette method. (The way Chinese or Japanese is typed comes to mind!)
But then, doesn't 'aalt' do the job already? Maybe not: 'salt' is more 'focused', i.e. limits the choice to real design alternates -- as against small cap, uppercase, superior &c alternates.

It seems that this discussion is about: Does it make sense to use the one-by-one part of 'salt' as a 'ss01' mirror for less advanced applications which don't yet support Stylistic Set features?
To tweak my question a bit, I would ask: If not for the one-from-many part, for presenting a more focused selection of alternates, what is 'salt' good for at all?

Wow. I went away for a few days and this thread went crazy. I haven't read everything thoroughly, but I have some comments based on what I have read so far (so sorry if I missed something):

AFAIK, stylistic sets were proposed by John Hudson back in summer 2002 (so maybe he has some further insight). The idea is to express a single design variation that spans multiple glyphs. A "stylistic set" is meant only to be a set of glyphs (i.e. more than one, as I see it) which are collectively a single design variation -- so it can be a set of capitals in Poetica, or the long ascenders in Kigali, or the plain capitals in Bulmer. It's a way of saying, "These alternates belong together."

It is probably true that we haven't been too consistent about how 'ss**' features are implemented in fonts, but I think it's fair to say that Poetica is well-suited to it.

Adam, you're example/complaint about applying a set to Poetica "all at once" is valid, but in fairness to whomever authored those features in Poetica (I don't think it was me!), I think it was imagined that the features would be applied to upper/lowercase text, not all-caps. Still, the stylistic sets serve the purpose that 'ss**' was created for, which is to express a shared design trait among glyph alternates.

As I said in another thread, I don't agree with this idea that alternates should be in both 'salt' and 'ss**' as a general practice (just like you wouldn't put all ligatures from 'liga' in 'clig'). I think the two features are complementary, in that 'salt' handles single alternates, and 'ss**' handles sets of alternates. Like a lot of feature choices, it's harmless, but I wouldn't call it "best practices".

I am not so sure that there is anything in the 'ss**' description which prescribes that it be applied "all at once". This certainly seems to be the way to go for many stylistic sets, but I don't know that this should be assumed. As we've seen in Poetica, some discretion is sometimes needed. (By the way, we should clarify some of the language Miguel used unintentionally, because in the OpenType vernacular, both 'salt' and 'ss**' are "discretionary", because they're not on by default.) With not too much trouble, an 'ss**' feature can be applied to a character style in InDesign, for example, and applied to the first letter of every paragraph with nested styles. In a case like this, 'ss**' can be very useful and appropriate, without being an "all at once" kind of thing.