Any takers?

ChrisL

Mathematics and Punctuation sets I'm not entirely sure that this is an Opentype issue, but it's something that I think matters. In big fonts its important that I can access punctuation and mathematical characters from the glyphs menu of whatever software I'm using. Right now its faster to get out a book of keyboard commands and find the right chord to get to this stuff than it is to find it in the glyphs menu of a massive font.

I'm wrestling with this myself as I fumble to build my first OpenType font: I have a variety of replacement glyphs (liga, dlig, calt, salt, etc.) and, as you say, there are already "switches" for liga, dlig, calt, but when it comes to salt glyphs things get more complicated.

For instance, I have K & R with long tails, an extra tall T, an o_f, an I_O_U & O_U, a C_E, etc. Yet each of these would be complete overkill if they were "turned on," thus setting any/each/all of them into a sset doesn't make a lot of sense. I'm not quite up on the coding to randomly insert these things, but if such randomization is possible (say, every 3rd IOU would get I_O_U), that's what I'd like to build into a sset.

Not sure at all if this counts as a response to your query, but these are the things I'm considering as I continue to fumble along.

Which kind of math glyphs do you mean? Complex stuff for calculus or simple stuff like fractions and inferior/superior figures?

ChrisL

Jason,
That is not quite what I was after but it would be nice to know. My guess is that you could do what you want with contextual alternates and make a set called "K and R tails".

I am looking from a users perspective more than from a type designers point of view. Do you put anything into the stylistic sets now or just make the features and not put them in sets?

ChrisL

Jpad, are you thinking of alternate glyphs for certain math characters that could be specified under certain conditions? For instance, applying a stylistic set for math could give you slightly oversized parentheses and brackets instead of the standard ones, or letters that default to italic while the numerals remain roman. Or are you just wishing for an easier way to get to the math characters included in a font?

I am looking from a users perspective more than from a type designers point of view. Do you put anything into the stylistic sets now or just make the features and not put them in sets?

I am not understanding, don't the type designers place things in the sets when building the OT tables, not the end users?

Anyway, I can't wait to get the place to add "Noisy", "Longtail", "Crooked Caps", "Faux Cyrillic" and more to some particular fonts, and have the OT menus reflect that. The default language fields should be related to the -dflt- tag, maybe?

Thomas, is there a way I can already build compliance to this proposed feature, documented on the web? So that if/when there is support,everything will be ready? And could you get Chris more info on how to forward this cause?

Choz
!Exclamachine
.~

I suppose I posted my current dilemma in order to supply an example of what I'm working with on the development side; that is, I'm curious how users might prefer I arrange alternates such as those I mentioned. I'm certainly no type designer (this is my first attempt at building rather than using), so, hopefully without hijacking your thread, my intention was to provide others with a point of reference to discuss these sorts of replacements, & thereby address your query (while also getting some input on my own situation).

ps. Already part-jacked so I may as well ask: can anyone point me in the direction of how to code randomized replacements?

If I understand correctly, you would detail a glyph substitution set for each character you wanted to randomize, using the <rand> feature. If you are using VOLT, and you have the alternates in the same sequence as the primaries, you can do this more easily with glyph groups. However, last I heard, there are no OpenType applications that support this yet. That was from some website, some time ago, so it may not be the case now. If it is still the case, perhaps you might use any other OpenType feature that defaults to 'on', and just make explicit substitutions that compliment your general design. Like, make K+N always use K#3 and N#1, and K+n always use K#2 and n#2?

Choz Cunningham
!Exclamachine Type Foundry
The Snark

I don't think the rand feature actually works. From what I know, most fonts made with "randomization" actually use the trick discussed in this typophile thread, which, as I understand, was first posted by Thomas Phinney. See also here.

I've always thought of stylistic sets as a way to select variant glyphs, such as alternative designs for the @-sign. One other thing I can imagine using it for is to select between a dotted zero and one without dot. The numbers in Inconsolata are quite narrow to distinguish 0 from O, but perhaps if I had a stylistic set for dotted zero, I could widen them up with no risk of confusion.

Raph,

it's a good idea to include the dotted zero in a stylistic set but if your font does include such a zero, please *also* specify a "zero" feature, which is the semantically correct place to do such a substitution. Of course, by all means, this substitution can be in both "zero" and "ssXX" (e.g. ss01).

A.

As I understand it, it's not really appropriate to put a single alternate in 'ss**'. A stylistic set should be a set of stylistically-related alternates to be activated all at once (as the name implies).

The problem, I think, is that if one wants to apply a single alternate to appear throughout all their text, one cannot just select everything and apply 'salt' (without getting alternates of a bunch of other letters at the same time). There've been some abstract hallway discussions about how applications should offer a user a way to make such a setting – saying essentially, "Apply 'salt' to just the letter 'a' everywhere." This is part of the difficult problem of deciding what is rightly handled inside the font, and what's rightly handled by the application UI. (And then maybe we have to wait around for an app which does it!)

I assumed the most leeway was given for stylistic sets, as that was where you could do "whatever". My preference is to only include a slash zero in the -zero- feature, saving the SS's for things not codified elsewhere.

Choz Cunningham
!Exclamachine Type Foundry
The Snark

I’m currently designing a font where the Stylistic Set 01 has capitals with a discrete little “swash” on the upper left side (Like in the letters B D E F R P etc). This makes the whole font look a little bit different, it’s like another cut of the typeface, so therefor it feels just like a Stylistic set.

On stylistic set 02 I have put Unicase letters.

On another font I decided to make some of the stems thinner in the Stylistic Set 01.

So for me, the Stylistic Sets are a very nice place to include something that effects the whole font in a way or another.

Another thing that could be included is bold and italic. I mean, why not? Of course it gives a hell of big document, but maybe it would be nice for the user? Just an idea.

Based on what I've dug up on Typophile & what this thread has discussed I've just used a simple calt replacement that Thomas suggested in another thread (which of course I can't find now). This is giving me some control over the replacements without getting into a bunch of code that, at the moment, makes me nervous.

For instance, I've set up my "o_f" glyph as a calt that is only triggered if preceded and followed by "space", so that the combined glyph only kicks in for the word "of". Same sort of thing for long "R" and "K"; I've selected specific letters to follow, and if those letters are entered the long alternates are trigged. Of course, the user can always go into the glyph palette and insert any of the glyphs anywhere they want, but this is providing a certain amount of functionality without having to go into the glyph palette constantly.

As for stylistic sets (which is, of course, the topic of this thread), I'm still not quite sure if/how I'll implement them. As above, the problem is that turning them on and off for key strings of text (rather than to a huge selection and thus "over-doing" the alternates) doesn't seem much better than simply adding alternates manually.

My next task is to find out if there's a simple way to work with GPOS in FontLab so that I can move some of my alternates around in the replacement process.

In an effort to try and get this thread back on topic, I think I should try to clarify my reason for starting it a bit more.

(1) I am trying to establish a set of "user" wishes for what "they" might want in a stylistic set so that type designers might respond with some things that fit "users" needs.
(2) I would take these established "wishes" or "needs" and create a common table of repeated words which could then be translated into many languages. Here is a sample:

"Substitute" "glyphs" [a, g] with "alternates" "single story".

All the words in quotes would be words that need translation into other languages. Items in brackets would be common to the languages that might use them like glyph names.
With this system, a language translation table could be constructed that would change the Stylistic set named in English, "Substitute glyphs a and g with single story alternates" into French, German, or whatever language is needed on the users system.

I would then propose to the "Proper Authorities" of the Opentype consortium and developers like FontLab and Adobe, that the stylistic set numbers be replaced with names that fit what they do and are easily constructable from a given set of translation variable terms.

ChrisL

There are already terms in feature code like "sub" for example that could be used as part of the translation table and create "on the fly" stylistic sets from feature code.

ChrisL

Chris, if you are looking for codification of the major stylistic sets sought/in use, I don't think that is what the stylistic sets are intended for. Or, to be precise, I don't think those things should be considered stylistic sets at that point.

The OpenType feature tags themselves are not a finite set. According to MS Typography, "Microsoft expects the list of registered tags and features to expand over time. The most recent version of the registry will be available on Microsoft's ftp and World Wide Web sites." (I can't find a record of version changes, proposed features, a system for proposal submission, or the like, but then MS has never been the world leader in open-collaboration tech. I think they mostly consider open to be the companies they are in established relationships with.)

From this perspective, the question arises, "What do users/designers keep putting in the stylistic sets so repeatedly that that might be better promoted to static, official OpenType feature tags?"

Doing that would keep the stylistic sets open as a testbed for new ideas and one-offs, which I think there should be. Of course, I'm still not sure how the feature tag registry is supposed to be expanded, but somewhere, someone knows. And I bet they read Typophile. :)

Choz Cunningham
!Exclamachine Type Foundry
The Snark

I really like a font to have a set of pre-made superiors and inferiors, or nut/em fractions. Maybe I am just lazy, but every font is different, and there is no real formula for making fractions if you need to. Projects that involve lots of fractions are a nightmare sometimes, simply for this reason. I hate having to sit and optically adjust the size of each number, the kerning between it and the solidus, and typically, the size of the solidus itself.

Feminine and Masculine ordinals are nice to have, even though I have myself never had to make use of any. These seem to be becoming more popular today.

Off the top of my head, I like to think of Whitney by H&FJ as one of the most complete fonts, in terms of it's plethora of typographic elements. Certainly, it was designed with specific parameters in mind, and absolute necessities for the Whitney Museum, but can none of these more obscure features become more standard in OT fonts?

"Track": All the things that you mentioned explicitly already have OpenType layout features defined and supported - no need for stylistic sets for them.

Choz: Although the OpenType layout features may continue to expand, I expect that the remaining expansion of typographic (as opposed to linguistic) features will be minimal. For a lot of things that are relatively uncommon, stylistic sets take away the impetus to cover them with their own separate features.

The OpenType feature tag registry can be expanded by Microsoft and Adobe. All you need to do is write up a formal proposal in the same format as the other feature tags, and maybe some backing explanation for why you think this feature is important. Post it to the OpenType list.

Alternatively, you can go through the Open Font Format, which is under ISO. It's under the MPEG spec, and you'd go through your national body, either working with somebody who's a member of the MPEG working group, or joining the group yourself. This all gets a bit more complicated, and I must admit that I don't know all the ins and outs.

Chris: You may indeed have misunderstood what I was suggesting. I was suggesting that you put together a proposal for *how* in any given font the stylistic sets would relate to user-friendly UI name strings. I wasn't particularly suggesting that there be a central registry of UI strings. Heck, the spec doesn't even do that for the *existing* layout features!

Cheers,

T

My own practice of codifying "salt" vs. "ssXX" is that I completely duplicate those two. However, I put one-to-one-from-many substitutions into "salt" and "one-to-one" substitutions into "ss01"-"ss20". For example, if a font has two variant "a"s, one variant "b" and three variant "c"s, I'd define the features as follows:

feature salt {
sub a from [a.1 a.2];
sub b from [b.1];
sub c from [c.1 c.2 c.3];
} salt;

feature ss01 {
sub a by a.1;
sub b by b.1;
sub c by c.1;
} ss01;

feature ss02 {
sub a by a.2;
sub c by c.2;
} ss02;

feature ss03 {
sub c by c.3;
} ss03;

I also don't think there is nothing conceptually wrong in associating the same substitutions with different features -- if a substitution can serve both a semantic and a stylistic purpose, or if a certain feature is not really widely supported.

For example, if I have a swash "R" glyph with a really long tail that is mostly suitable to be put at the end of words, I'd associate it with both the "fina" and the "swsh" feature. Similarly, if I have two set of small caps in my font, I'd associate the first one with "smcp", while I'd put the second one into "pcap" but also as "ss01" of the normal small caps:

feature smcp {
sub a by A.smcp;
...
} smcp;

feature pcap {
sub a by A.pcap;
...
} pcap;

feature ss01 {
sub A.smcp by A.pcap;
...
} ss01;

(And of course if there is a "ss01" feature, I'd also place this into "salt" because ssXX and salt are to me really just different ways of organizing the same information.)

A.

Christopher writes: "As I understand it, it’s not really appropriate to put a single alternate in ‘ss**’. A stylistic set should be a set of stylistically-related alternates to be activated all at once (as the name implies)."

How many does a "set" constitute? Is two enough? :>

A.

Also, Christopher, please note that the Adobe InDesign UI for selecting stylistic sets is additive, not mutually exclusive (checkboxes rather than radio buttons). This suggests that each ssXX feature may very well operate on a very small set of glyphs (even single ones) rather than always referring to an entire alphabet.

In Zapfino Extra Pro, ss01-ss04 indeed exchange entire alphabets, switching between the four basic sets of Zapfino, but ss05-ss10 give access to alternates for those glyphs that have more than four alternate forms, which are, of course, less and less for the latter sets. For example "ss09" only gives access to three glyph alternates ("d", "e" and "t") as these are the glyphs with the highest number of variants in the font.

I don't see anything inherently wrong with that approach especially that there is no really plausible way for the OpenType spec to specify what the minimal size of a "set" should be for ssXX.

Adam

Tom Phinney writes: "I was suggesting that you put together a proposal for *how* in any given font the stylistic sets would relate to user-friendly UI name strings."

I myself don't really think that this is a particularly good idea, especially for the reasons I have written here before: the localization of those names will only be incidental. One font vendor may supply set names for English only, some other vendor may supply set names for English, German and French, and yet another for 12 different languages. Obviously, the larger for vendors will be in favor here, but still, what should a user of, say, the Polish language version of InDesign see in the menu if the name of the "Feminine" set in a given font was not localized into Polish? Should he see "Feminine" or "zestaw stylistyczny 3"? I don't think the English set name (or Greek, or Chinese, or whatever the default set name will be in the font) will say much to a non-English speaker, so sticking with the localized stub names ("zestaw stylistyczny 3" etc.) will probably be a better idea. But this again introduces complications for documentation writers (they cannot rely that "Feminine" or a translation thereof will always be available to users in the UI).

However, *if* people feel having human-readable names for stylistic sets in OpenType fonts would be a good idea, I'd recommend using a simple scheme: the human-readable names for the ss01-ss20 features should be stored in the "name" table, using name ids 101-120. For example, name ids 102.3.1.1033 and 102.1.0.0 would hold the U.S. English names for ss02, and the name ids 102.3.1.1045 and 102.1.29.25 (or 102.1.0.25?) would hold the Polish names for that feature.

Adam

Descriptive names for ssXX features:

A (whose?) suggestion in an earlier post was good -- the applications' menu should show Set number followed by the descriptive name:

"Stylistic Sets" --> "Set 1: Swash R and K"

where "Swash R and K" is the name defined in the font.
It is important that Set 1 is shown too, because it makes it clear to the typographer that if he applies "Set 1: Swash R and K" in one font, he may get "Set 1: Swash Z" in another font which covers swash R and K in "Set 3: Swash R and K".

Localization of descriptive names:

I know that you are not fond of English-only descriptive names. It is true that to a German or Polish user, the English term may not be of much use for he doesn't know what it means.
But it does have advantages: Though of no descriptive use for some, it identifies a feature uniquely. A Spanish typographer can tell his German collegue to use this particular feature. With localized versions (of which they see only their own), they would have some trouble translating the term such that both will refer to the same thing!
Example: I wanted to make a little manual showing graphically which buttons to press to access a certain style. Thanks to localization of applications I ended up with a column of button pairs for 'B' and 'I' (English), 'G' and 'I' (French), 'F' and 'K' (German), &c.
Another example, more OpenType related: I tend to speak of InDesign's "Stylistic Set" features. But some German typographer collegues didn't understand what I was talking about. Finally I recognized that in the localized German InDesign "Stylistic Sets" are translated as "Formatsätze". Without access to a German ID version, I would have been lost in finding a translation letting me point to them.

So, for me, identification is much more important than meaning. The average user doesn't know what a (German) typograpic term "Kursiv" means either, but knows what happens if he clicks the 'K' button ('I' for Americans).  :)
In applications that support them to date, Stylistic Set features are offered in their own submenu. So users might understand a language switch, and that it's due to the font, not the application.

Karsten

> A Spanish typographer can tell his German collegue
> to use this particular feature

But using this argument, the only logical consequence would be to use English-only names for ALL OpenType features, including Swash, Old-Style Figures etc. My point is that you should localize all or none -- having half-translated and half-foreign menus is something from the 20th century.

But bad translations should be fixed there where they are broken: by fixing the translations, not by introducing some additional complication to the system.

I know that some translations for the OpenType Layout features in Adobe applications are nonsense. I've consulted with Winsoft (who did the localization of Adobe Creative Suite applications into Polish) on the translation of the typographic terminology in these apps. They used some, though not all, of my suggestions.

The question that you need to ask yourself is: what is the purpose for these human-readable names to be included in OpenType fonts. If this is to just provide "some labels" for the features, fine, but let's be clear about it. Then they can be completely arbitrary, not necessarily localized. The sets can be then called "Blue", "Green", "Orange" or "Chicago", "New York" and "Paris". It's fancy, but I don't think it's significantly better than "Set 1", "Set 2", "Set 3" -- though some mnemotechnic can help users differentiate them.

However, if the names are, indeed, to tell to the user what the set actually contains, then, logically speaking, they should be localized. But here all my doubts creep in -- will these localizations really do any good?

A.

Ok, I'll be clear about it. The stylistic sets' names will always vary from foundry to foundry, and often from font to font. If things were regularized, it would hinder the use of the Sets. Since what they look like, what they do, and all that is up to the designer, it makes sense that the names are, too. I specifically included oddball set names as an example to show why it might be good not to translate them, but use them only as mnemonic devices. Perhaps funkier names would have been a better example; "Baldwin Bros." "Supadupa" and "Sqoooshed™".

If a designer wants them to have a valid meaning in one language, or encode translations of them for several, fine. To be clear, the few applications that support sets show them now as numbers. This should remain, regardless of name. The names should be mere additions, not replacements. Since Thomas is reading this, and (I think) has a profound impact on those developing the only cutting-edge applicans using OT, I suspect that it is a non-issue, anyway.

Of course, if the creator doesn't see a benefit to the us of the names, they could always leave them blank. So this is a win-win situation.

If a stylistic set simply alters a few specific characters, it might be a best practice to comma delineate them in the set's name field, since that is inherently international. But that would be a designer's choice, or custom, like using the set-names in the first place.

Choz Cunningham
!Exclamachine Type Foundry
The Snark

For a lot of things that are relatively uncommon, stylistic sets take away the impetus to cover them with their own separate features.

Then they are doing what I think they were intended to do very well. If some feature, particularly typographic, becomes so common that users/creators expect it in the font, it seems that would be the time to "graduate" that feature to its own tag. The first thing I've heard of is this small-caps-lining-figures, and while that may be worthy, I leave it to someone else to care more for now.

It is suggested at wikipedia that AAT, and here that Metafont offer more typographic flexibility than OpenType does. Since OT can be expanded, are there a few specific simple things that could be added as permanent features that would change this perception? I don't think it could or should develop to the complexity of metafont, but perhaps a standardized space should be made for a few more "goodies"?

Choz Cunningham
!Exclamachine Type Foundry
The Snark

> The first thing I’ve heard of is this small-caps-lining-figures,
> and while that may be worthy, I leave it to someone else
> to care more for now.

Is there a reason why you would not simply associate the small-caps-lining figures with "smcp"?

> It is suggested at wikipedia that AAT, and here that Metafont
> offer more typographic flexibility than OpenType does.

Yes, and this is exactly the reason why AAT and Metafont only have one implementation and are therefore proprietary insular solutions, while OpenType has many implementations and is widespread. It is much easier for engineers to implement simple things than to implement "flexible" things.

A.

Hi Adam. Yes, I think two in a set is enough. The point is to communicate a shared style among more than one glyph.

And I did indeed choose the word "appropriate" deliberately, because I don't think anyone wants to characterize a one-substitution set as "illegal" -- it's just that it seems to violate the spirit of the feature. If one has just one subsitution, then I think one should put it in 'salt'.

well, i apologize, i think that this question has more to do with the coding behind the fonts then the characters themselves. I know very little about this, so don't mind me. However, I was thinking that we might be approaching this problem the wrong way around. Instead of asking people to rattle off what they "want", why not make a list of what we "have" (typically available in any well designed/programmed font), and then go from there?

Adam Twardoch wrote: But using this argument, the only logical consequence would be to use English-only names for ALL OpenType features, including Swash, Old-Style Figures etc. My point is that you should localize all or none [...]
But here all my doubts creep in — will these localizations really do any good?

Fully agreed.

The question that you need to ask yourself is: what is the purpose for these human-readable names to be included in OpenType fonts. [...] The sets can be then called “Blue”, “Green”, “Orange” or “Chicago”, “New York” and “Paris”. It’s fancy, but I don’t think it’s significantly better than “Set 1”, “Set 2”, “Set 3” — though some mnemotechnic can help users differentiate them.

I did ask myself the question.
The last point you make is not to be underestimated. For those who can read English names, great; those who cannot may still guess at the meaning because of similarity of terms in both languages; and the rest may remember the sound or look of the words.
In a syntax like "Set 1: Human-readable name", the colon should make clear that what follows is an attempt at describing the content, nothing more.
So I'd say, add English names, but no further localization. I'd be happy to do this. With 1-2-3 I am lost even in my own fonts.

Karsten

Is there a reason why you would not simply associate the small-caps-lining figures with “smcp”?

Because this thread spawned from a thread about how the Small Caps commonly come with SC-sized Text Figures, and the other Lining Figures don't match. While it might make sense to turn on Small Caps and Lining Numerals, that doesn't always mean that you will get small-caps-lining-numerals; in fact you will probably get something very different.

---

Stylistic Sets are highly discretionary things. While I think best practice would to be to place a single alt in <salt>, and matching alts :gt;1 in a s. set, I would hardly begrudge anyone for doing otherwise, that's their free-space to play a bit. (And OpenType is young.)

Perhaps we should choose to think of the whole issue differently. The name of stylistic set no. 1 is <ss01> . The personal appellation describing it is something else; a label, subtitle, whatever you please. So if one is compelled to wonder what an application developer will do with the name, that's about their implementation of OpenType, not the type designer's choice of label. Let's use label.

On another note, where are <21> through <99>? :)

Choz Cunningham
!Exclamachine Type Foundry
The Snark

Here's one:
I just bought LTC Metropolitan and the README says:

Metropolitan Italic Pro (Opentype) combines two of Frederic Wardes versions of Arrighi. Accessible in the contextual alternates feature, the alternate ascenders, g, y, and ampersand were found in the original version of Arrighi from 1925.
The only difference is that the upright caps that were originally paired with the type have not been included. There is also a swash 'e' added in the swash feature, as well as all standard ligatures.

What would prevent them from adding the upright caps as a stylistic set? I myself think that it is a pretty cool idea. One of my favorite italics is Celestia Antiqua Italic, and it DOES have the Roman caps.

Choz,

if the user wants small-cap-sized lining numerals, the most likely way he'd want to access them would be through the smcp feature, I think. Consider that you have six sets of figures in your font:
one -- uppercase lining proportional
one.lnum_tnum -- uppercase lining tabular
one.onum_pnum -- text oldstyle proportional
one.onum_tnum -- text oldstyle tabular
one.pnum_smcp -- small-caps lining proportional
one.smcp_tnum -- small-caps lining tabular

In this case, a thorough approach for implementing the OpenType Layout features could be as follows (of course, instead of "one", the real implementation would take care of entire classes):

feature smcp {
sub one by one.pnum_smcp;
sub one.onum_pnum by one.pnum_smcp;
sub one.onum_tnum by one.smcp_tnum;
sub one.lnum_tnum by one.smcp_tnum;
} smcp;
feature lnum {
sub one.onum_pnum by one;
sub one.onum_tnum by one.lnum_tnum;
} lnum;
feature onum {
sub one by one.onum_pnum;
sub one.lnum_tnum by one.onum_tnum;
sub one.pnum_smcp by one.onum_pnum;
sub one.smcp_tnum by one.onum_tnum;
} onum;
feature pnum {
sub one.lnum_tnum by one;
sub one.onum_tnum by one.onum_pnum;
sub one.smcp_tnum by one.pnum_smcp;
} pnum;
feature tnum {
sub one by one.lnum_tnum;
sub one.onum_pnum by one.onum_tnum;
sub one.pnum_smcp by one.smcp_tnum;
} tnum;

Using this approach, in InDesign, the user would get the small cap lining proportional figures by selecting "Small Caps" combined with "Default Figure Style" or with "Proportional Lining", while he'd get the small cap lining tabular figures by selecting "Small Caps" combined with "Tabular Lining". Selecting "Small Caps" in combination with "Proportional Oldstyle" or with "Tabular Oldstyle" would give the user small cap letters mixed with the text oldstyle figures (proportional or tabular, respectively).

I don't quite see the reason why anyone would need a new feature for small-cap figures only.

(Edit: This post is really more appropriate for this thread: http://typophile.com/node/29580 so I apologize for cross-posting.)

A.

Choz > On another note, where are <21> through <99>? :)

OpenType Layout feature tags "ss21" to "ss99" are not registered by Microsoft. However, font developers are free to include unregistered OpenType Layout feature tags in their fonts. Most applications will not support these but those applications that give the user direct access to all OpenType Layout feature tags included in the font will (e.g. XeTeX, GlyphGate, the Glyph Palette in InDesign CS2 or Illustrator CS2).

Karsten > add English names, but no further localization

Why only English and not only Japanese or only Arabic?

A.

Christopher,

of course, the practical problem is that InDesign gives the user access to "ssXX" but not "salt", while Illustrator gives the user access to "salt" but not "ssXX".

In Zapfino Extra Pro, I chose a following method (given that a a.2 a.3 a.4 are the four basic styles):

# For Illustrator
feature salt {
sub a from [a.2 a.3 a.4];
} salt;
feature swsh {
sub a from [a.3 a.4];
sub a.2 from [a.4];
} swsh;
# For InDesign
feature ss01 {
sub [a.2 a.3 a.4] by [a a a];
} ss01;
feature ss02 {
sub [a a.3 a.4] by [a.2 a.2 a.2];
} ss02;
feature ss03 {
sub [a a.2 a.4] by [a.3 a.3 a.3];
} ss03;
feature ss04 {
sub [a a.2 a.3] by [a.4 a.4 a.4];
} ss04;

In InDesign, the access to the basic four sets is through ss01-ss04 (while the first set is also visible when no Stylistic Set is chosen). In Illustrator, the access to the first basic set is with no formatting applied and to the three further sets is through salt, swsh and salt+swsh (which can be conveniently toggled in the OpenType palette).

A.

Using this approach, in InDesign, the user would get the small cap lining p...

For the non-coding designers thats a beefy bit of text. Now that you've explained, its clear why you were saying that a new feature tag would be unneeded. Just makes we wish there was friendlier dev tools already out there.

Karsten > add English names, but no further localization
Why only English and not only Japanese or only Arabic?
Call them labels, and allow them in whatever languages the designer pleases! Leave the names as SSxx.

However, font developers are free to include unregistered OpenType Layout feature tags in their fonts.

Should I ever find 20 sets not enough, I'll just move attempt to register them, makes more sense than not doing so when it is extensible. Or, if I have more than 20 S. Sets, I'll just shoot myself.

Choz Cunningham
!Exclamachine Type Foundry
The Snark

Choz,

if you ever find yourself in a need of more than 20 stylistic sets, it may make just as much sense to split them into separate fonts :)

> Just makes we wish there was friendlier dev tools
> already out there.

You have a choice of two: Microsoft VOLT (which is WYSIWYG and pretty friendly for the simple stuff, although it has some rough edges for the more complicated tasks) and AFDKO/FontLab Studio which uses the text-based notation developed by Adobe. It is not entirely WYSIWYG but allows pretty rapid development and easy re-use of the code.

In general, if you feel that design is your strength but not development, it's often easier to hire a font developer to do the technical mastering of your fonts. Font production is not just all about design, there are some technical aspects involved which require slightly different skills than those of a designer.

Regards,
A.

I use VOLT. It's utilitarian and stable, but what I would love to see is virtually the same thing, with a fully drag and drop, select from menus type thing. However, it is far beyond my resources to pursue that at this time.

I am a bit geeky for a designer, and the same I suspect is true of most people interested in type today. Even if I were to out-source the code side of a font, I like to know how things work enough to not ask for something impossible. Knowing the rules also creates new ideas. Besides, how would one know what the going rate was for such things?

Choz Cunningham
!Exclamachine Type Foundry
The Snark

It depends on the project but you can find people who'll charge $200-$300 for a fairly straightforward font family up to $2000-$3000 if the font involves complex contextual substitutions. If you want additional consulting on things like character sets, glyph naming, font naming etc., the amount will likely double. If extra work needs to be done on the font (merging of character sets, copying of kerning information, hinting etc.), this of course adds up, too.

These amounts are usually per a unique set of fonts. If your regular, your light and your bold have the same character set, you'll be able to split the price between them, arriving at a price of $50-$100 (for as simple font), and that's a price that is compensated after 2-3 sales of the font. If your italics have the same character set, that's also included -- if they're different (e.g. extra ligatures), some 50% more would apply.

There may be some colleagues out there who are slightly cheaper.

Adam

Would it be appropriate to put Optical Sizes into the Stylistic Sets, like

ss01: Body Text
ss02: Caption
ss03: Subhead
ss04: Display
ss05: Poster

and so on? Adobe uses different fonts for those, properly style-linked so that they appear in the font panel's dropdown menu. Apart from a cluttered menu, the big issue with this approach is that switching between optical sizes (styles), disorders the weight, width and style (!) formatting within the text. When, for example, a certain string was marked as italic and the overall formatting of the text bloc that holds the string has Caption applied, one is forced to do the italic formatting over at every single instance, if suddenly the text bloc needed to be set in Subhead. (That is, if no character and/or paragraph styles are used.)

Stylistic Sets might offer a solution to this problem, although it would imply that the actual font would hold twice, thrice or too many more glyph sets. Is there a better solution to handle optical sizes? (Suppose, in addition, that one might want to create a family with optical sizes for every single point size…)

Stylistic Sets could perhaps more effectively be used for width and style (!) styles proper, e.g.

ss01: Book
ss02: Bold
ss03: Light
ss04: SemiBold
ss05: Black
ss06: ExtraBlack

or similarly:

ss07: RegularWidth
ss08: Condensed
ss09: Extended

and, taking advance of the fact that Stylist Sets are additive:

[×] ss04: SemiBold
[×] ss08: Condensed

Ludwig,

1. Optical sizes, different weights or different widths usually imply different ascender, descender or x-height lines in fonts. However, you can only have one such information per font so that for the additional "stylistic sets", the font would contain false information.

2. Fonts have classification information in them, e.g. the PANOSE classification numbers, information about width, weight etc. This information, combined with the information about ascenders, descenders or the x-height, allows font matching systems to substitute a close matching font when the original is unavailable. If you stuff all the glyphs into one font, this systems will no longer work.

4. Many applications that are not intended for professional page layout (e.g. Excel) do not and never will support OpenType Layout features such as stylistic sets.

5. OpenType fonts have a physical glyph limit of 65,536 glyphs per font. Having 5x as many glyphs as you currently do for European fonts is typically not a problem (currently, you have around 1000-2000 glyphs, so you'd have 5000-10,000) but for large multilingual fonts, especially Asian fonts, it would be a problem.

6. There is no cross-platform or even cross-application standard for OpenType Layout feature tagging when exchanging formatted text (through the clipboard or through text files e.g. RTF files). If you apply a combination of stylistic sets in InDesign and copy-paste the text into Word, it will come in as plain text -- all the formatting will be lost. If you use different fonts to denote different weights or styles, the information is typically preserved.

7. It is easier to charge users per font. You can sell single fonts for $20 each and entire families for $200 or $400. Users will be less likely to pay $200 for just one font even if it contained an unlimited number of styles -- this is the experience that Adobe made with Multiple Master fonts. Also, with such monster all-in-one fonts, it's less possible to differentiate the offerings: currently, you can sell a complete family for $400 to more professional users while you only sell one or two styles, $20 each, for less demanding users who are on a smaller budget. The monster fonts would only allow you to do "all or nothing", or you'd have to produce different subsets of fonts, but then you run into family naming conflicts etc.

Therefore, I don't think your idea will ever work. The only situation where I think it might make sense would be with italic glyphs. Italics are often mixed with roman styles and currently, there is no way to devise spacing/kerning in character pairs when the font is switched. If upright and italic glyphs were placed in one font, this would be easier to implement. Actually, there is an "ital" feature but it is only used in Asian fonts.

The problem however is again that there is only one set of metric information per font. Italic fonts usually contain information about the slope angle, which is used by text editing applications to draw a sloped text cursor on the screen. If the italic glyphs were stored as variants in an upright font, this information would not be available.

In short: I think the system does make sense the way it is now. I don't think you can expect revolutionary changes anytime soon.

Is there a better solution to handle optical sizes?

It should be handled by the application, in a similar manner to Quark's "Tracking Utility", which enables the user to set different tracking values for a font, according to the size it is used.

The Optical Scale utility would say:

Font Family: Harmony
72+ pt: Harmony Poster
36-72pt; Harmony Display
18-36pt: Harmony Subhead
12-18pt: Harmony Caption
9-12pt; Harmony Text
less than 9pt: Harmony Small

This is an example for a family with six optical sizes, if such a thing exists.
The user would determine which sizes are appropriate for the different optical sizes.

Nick,

the Adobe OpenType fonts include the information about optical sizes. Adobe InDesign has a mechanism for automatically selecting optical sizes depending on the point size but... this mechanism in the current version of Adobe InDesign only works with old Multiple Master fonts that have an optical size axis (that Adobe announced obsolete 7 years ago), while the mechanism does not work with new OpenType fonts (that Adobe have been promoting for the last 7 years).

I hope that this will change.

A.

BTW, I recommend everyone interested in the topic (Adobe support for automatic selection of optical sizes in OpenType fonts) to file a product feature request at:

http://www.adobe.com/support/feature.html

The more different people submit this, the more likely a feature will be actually implemented.

Regards,
Adam

Who all would I lobby for support for logically named feature sets instead of meaningless numbers?

ChrisL

I have submitted the following message to the OpenType list. All interested parties who are not subscribed to the OpenType list are invited to join at: opentype-migration-sub@indx.co.uk

==

A set of twenty new name IDs is reserved in the "name" table to represent user-friendly labels for OpenType stylistic sets.

The new name IDs range from 31 to 50, corresponding to the OpenType Layout feature tags ss01-ss20 (name ID 31 represents a label for the "ss01" feature, name ID 45 represents a label for the "ss15" feature etc.)

When an OpenType-savvy application examines an OpenType font and finds a user-friendly label for a stylistic set included in a font, that label should be displayed instead of a generic label such as "Stylistic Set 4".

The new name IDs need only to be specified for platform "3" and encoding "1". Typically, a font developer specifies the user-friendly label in the 1033 (U.S. English) language, but any valid Microsoft Language ID can be used. If the font does not contain a label in the language of the application user interface but contains a U.S. English label, the application may choose to display that name; alternatively, it may choose to display a localized generic label (e.g. "Zestaw stylistyczny 4" for Polish).

For a given Microsoft Language ID, a particular name ID represents the user-friendly label for the corresponding ssXX feature across all writing systems and language systems defined in the font. If a stylistic set feature is implemented differently across scripts and language systems (e.g. one substitution is done in the ss01 feature for the Arabic script, and another, visually unrelated substitution is done in the ss01 feature for the Latin script), the font developer should pick a user-friendly label that adequately describes all these behaviors collectively, or should not specify user-friendly labels for such font.

==

Adam

Thanks Adam!

ChrisL

Adam,
Is it possible for me to second the motion on your posted request? I assume the more people who agree with it will make it have greater weight.

My whole point for starting this thread was to try to get user-friendly labels for OpenType SS.

ChrisL