Rachel, you should avoid the salt feature, which is not a plain 1:1 GSUB lookup. As salt is explained on the Adobe OT Resources page:

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). The manufacturer may choose to build two tables (one for each lookup type) or only one which uses lookup type 3 for all substitutions.

What you're working with is a GSUB lookup type 1, but of a non-standard kind. In other words, it's not a calt, hist, titl, or swsh. In order for your feature to work in less-OpenType-knowledgeable apps, such as InDesign CS1 you are using, you should use one of the available features, such as titl, and duplicate your feature as a Stylistic Set: SS01. SSes are accessible by InDesign CS2 and Apple's TextEdit, but not Illustrator CS2 for example.

So, watch out for salt. Until the implementation of the lookup type 3 is sorted out, stay away from it.

Village,

Thanks for the advise, so is it possible to do what I'm trying to do - have alternative glyphs. If it is whats, the best way to go about it.

I'm new to opentype, so if someone could explain this process that would be great.

I don't know if this is apples to apples but I recently finished a job with Apex New and used the search and replace to sub in the alternate "a" "g" and "y".

Rachel, what you're doing is fine, but you should choose a different feature; one which is supported by all of the applications you want to use the font in.

I screengrabbed all of the OT interfaces from the CS2 apps. You can view them here:
http://vllg.com/files/cs2/

I would nominate Titling Alternates in your case.

feature titl { # Titling Alternates
# Latin
sub i by i.alt;
} titl;

And use a stylistic set too:

feature ss01 { # Alternate lowercase i
# Latin
sub i by i.alt;
} ss01;

I believe that you need to have a GPOS feature - kern, for example - in the compiled OT file in order for the GSUBs to work.

Good luck.

Jupiterboy, you could have used the Stylistic Set 01 for schoolbook forms of a g and y.

I second chester's advice.
I put the alternate set in all three of salt, titl, and ss01, that way it is accessible in as many past and present versions of different software.

I'm stuck in the digital mud of CS1. I'd have to get a new wide format printer if I jumped forward at this point. Believe me I searched for a way to pick up the alternates automatically.

Anyway, the internal museum design staff didn't feel it was worth keeping this stylistic convention that was set in the catalogue, so only my wall texts had the alternates. Chester?—I think those three alt characters really change the feel of the face—nice work.

Once again Typophile comes through with the answers, thanks everyone.

Nick when you say you put the alternate set in all three of salt, titl, and ss01. Do you mean choose one of salt, titl or ssO1, or use them all.

Thanks again everyone.

Based on http://www.typotheque.com/fonts/opentype_feature_support/ I'd guess all three. InDesign CS2 does ss01 but not salt, Illustrator and Quark 7 do salt but not ss01, older InDesign versions do titl but neither ss01 nor salt, and Photoshop does salt and ss01 but not titl. So if you do all three, it can be accessed in all these programs.

So I would do :

feature titl {
# Latin
sub i by i.alt;
} titl;

feature salt {
# Latin
sub i by i.alt;
} salt;

feature ss01 {
# Latin
sub i by i.alt;
} ss01;

will different features doing the same thing cause any problems ?

I haven't tried it with all three, but in this thread Adam Twardoch gives an example with three features doing the same thing, so I would expect that it works.

And I made a mistake earlier: Photoshop does salt but not ss01.

The font will work with all three features. (If you wanted to, you could make your i -> i.alt substitution the smcp or onum feature.)

I know this conversation is as old as the (OpenType) hills, but what everyone is advocating is not ideal, from my perspective.

Many OpenType features are really the same -- they substitute one glyph for another, in the case of 'titl' or 'smcp' or 'sups'. The reason there are different features is that the feature itself conveys information about the substitutions it comprises. If you put an alternate in 'titl' that is not a titling alternate, then you are telling an application "this font has one or more titling alternates" when it actually doesn't.

It's tempting to look at the features that are supported in popular applications and comandeer them in order to make alternates more easily acccessible, but I personally believe it's bad practice. I understand the arguments in favor of it, but I don't necessarily agree with them.

My opinion is that your alternate i belongs in 'salt'. If it truly is a titling alternate, then of course it's appropriate to put it in 'titl'. Whether it correctly belongs in a stylistic set ('ss**' feature) is even murkier; I personally think that stylistic sets should be reserved for multiple glyphs which are intended to be substituted together, not single alternates.

Of course in InDesign, alternates from 'salt' are available through the glyph palette.

In the long run, I think it's better to keep glyphs in appropriate features, because we all hope that one day soon that OpenType feature UI will improve, and when that day comes, font users will find that their fonts behave consistently and predictably.

The fact that InDesign allows stylistic sets to be specified in a style sheet and that it allows more than one stylistic set to be applied on the same text makes for a powerful combination and implies that they were meant for more than the limited way you describe (presumably the way in which they were intended to be used).

salt severely limits the usefulness of alternate since they can't be specified in style sheets. Using the Glyph palette to select alternate characters is probably okay for display fonts, but impractical for text.

Imagine using the Glyph palette to substitute every lowercase "a" with an alternate form in a 300-page book. If it's included as a single character stylistic set instance, you can change the style sheet and every "a" in the book will use the alternate form. And who is to say that a single alternate character could not be considered a valid stylistic set? Why must it be "multiple glyphs"? Especially since we have up to twenty sets to utilize?

I realize that what I'm describing could be considered a hack. But this is such an incredibly useful and powerful thing that I very much hope that InDesign's implementation of stylistic sets becomes the norm.

Mark, we're really talking about two different things. First, what is an OpenType layout feature intended to do? And second, how successfully is a feature supported in an application?

I can't argue with your observations about feature UI. It is very helpful to be able to specify features in a style sheet, and the fact that one cannot do that with 'salt' is a problem. The real solution, though, is for applications to improve their feature support and UI. 'salt' is a valid and useful feature, and we need applications to handle it better.

(By the way, in case anyone doubts it: Application users have the most influence over its features. I urge all users to write to application developers and describe UI problems and make suggestions. The more they hear about something, the more likely it is to be addressed. The fact that one cannot easily apply a single 'salt' substitution across an entire document, for example, is something to complain about.)

Stylistic sets are a tricky business. My recollection is that the feature was conceived as an adjunct to 'salt', as a way to say, "These glyphs are, collectively, a single stylistic alternate and should be used together, not individually." Given that, a stylistic set with one glyph should simply be in 'salt'. I don't know that it's some horrible sin to put a single glyph in a stylistic set, but I'd describe it as inappropriate -- something akin to putting a regular, non-contextual ligature in 'clig' instead of 'liga'. The best argument I can make against single-glyph stylistic sets is that they are not "stylistic sets", they are "stylistic alternates".

Really though, I understand the real-world situation is less than ideal, and I am sympathetic. I just didn't want the opposing view to go unmentioned, as I think it's worth keeping in mind.

It would be nice if the OT app. could read from the font data and use the terminology of the type designer for the alternate sets and only show the font specific options in the OT palette. And also, if all the hungry children could be fed, and the neo-cons would burst into flames, that would be good.

Through my inexperience with opentype I believed that the Stylistic Alternatives could be used in the same way as Lining and Old style figures, with a simple click changing all glyphs to the alternative - but thats obviously not the case at the moment.

If I was to implement the Stylistic Alternatives using the features stated, how would I use them in Indesign. Style sheets have been mentioned, but how would I use them ?

/track/

It’s tempting to look at the features that are supported in popular applications and comandeer them in order to make alternates more easily acccessible, but I personally believe it’s bad practice. I understand the arguments in favor of it, but I don’t necessarily agree with them.

I understand the sentiment, but don't agree at all. You only have to go back to the Type 1 days & the Windows & Mac operating systems to see the problems with this kind of thinking. To use double-f ligatures, you had to lie about the name, whether you put them in a separate font, like Monotype, or the same font, like some FontFont fonts. So, better not to use them?

Of course, if you weren't stuck with those kludge programs Quark and PageMaker, or with Windows or Mac OS, you could do as you chose. We ran TeX out of a DOS box, so could write a legitimate encoding vector to include whatever glyphs we wanted. Features for fonts aren't new -- a little thing most people don't know was that you could put ligaturing instructions in an AFM file, and if your typesetting program made use of it (the AFM), you would get automatic ligaturing -- fj gg, zy, ggy, no problem.

The point is that end users, so often ignored, turn the tables when it is time to get work done -- we have to ignore your whims, while thanking you for the basic tools.

And by the way, how did anyone ever get the idea that "set" implied more than one member?

charles_e,

I'm slightly confused, are you saying not to include alternative glyphs.

I've actually got it all working now using .titl and sso1 features, which works across platforms on all Abode applications. The alternative "i" I wanted to include isn't vital to the font, but more of an extra I wanted to add.

No, what I'm saying is that as long as there are different applications programs which support different features, the helpful type designer will make their *font features* available so those varying programs can use them. Fonts usually aren't an end in themselves; someone must be able to use them to do work. To the extent possible, don't go flat-out against the intended purpose of a feature, but there is ample history for even this, with good reason, looking back no further than the Type 1 format.

I'm looking more & more with favor on the people like Nick Shinn (& others), who said

I second chester’s advice.
I put the alternate set in all three of salt, titl, and ss01, that way it is accessible in as many past and present versions of different software.

Chris, what of those who have not upgraded from CS1? As an employee of Adobe, you must know how many there are. I don't, but I'm assuming there are a significant number.

Those are the people who must rely on "Titling" to access the alternates features in InDesign etc.

In principle, I think it's better to maximize accessibility now and facilitate the longevity of existing products, rather than optimize for programmed obscelescence and a hypothetical future.

Perhaps Christopher might hint about CS3's opentype features? Might he say they are at least better than they are in CS2?

ChrisL

Maybe I'm just grouchy today or something, I dunno.

Predictably enough, I'm with Christopher on this one. I'll also go so far as to add that if you hijack features for your own purposes, you are making a font that can reasonably be called a hack, or even buggy.

On the other hand, perhaps I should be more appreciative; if other folks make sub-standard OpenType fonts, more people will want to buy ours instead. I just hope it doesn't damage OpenType's reputation.

This discussion reminds me of a popular OpenType script font that uses the 'calt' feature for non-contextual substitutions of ending forms. Since 'calt' is on by default, this means that typing with this font in common applications such as InDesign yields ending forms in the middle of words... sigh.

Charles: the reason that some people think stylistic sets should affect more than one glyph is not because they don't know the definition of "set" but because the OpenType feature registry says so.

Function: In addition to, or instead of, stylistic alternatives of individual glyphs (see 'salt' feature), some fonts may contain sets of stylistic variant glyphs corresponding to portions of the character set, e.g. multiple variants for lowercase letters in a Latin font. Glyphs in stylistic sets may be designed to harmonise visually, interract in particular ways, or otherwise work together.

Cheers,

T

To use double-f ligatures, you had to lie about the name, whether you put them in a separate font, like Monotype, or the same font, like some FontFont fonts. So, better not to use them?

Well, I wouldn't say that it's "better not to use them". The glyphs are in the font and are usable. We agree that the current UI is not very good for stylistic alternates, and using them is a hassle in some cases. (On the other hand, if one is only using an occasional alternate, the current UI in InDesign is quite adequate.)

But the old Type 1 method which you are describing reinforces my belief that it's better to resist nonintuitive workarounds (which is how I would describe typing cap-Y to get 'ffi'). The appeal of keeping glyphs in appropriate OpenType layout features is an idealistic one for me. If I enter characters + 'titl' into my document, I've just specified a description which is independent of font and application.

I want to see all applications implement a wide range of layout features, which I am optimistic about -- but when that happens, it will not be so pleasant if all the fonts out there have been built with inconsistent layout features. Imagine how crazy things would be if applying 'bold' to a font produced italics or titling alternates. I don't think layout features are so different from these more entrenched styling choices, and in a world where styling and content are becoming more distinct all the time (HTML, CSS, etc.), it is only becoming more important to ensure that style tags produce the expected visual result.

And by the way, how did anyone ever get the idea that “set” implied more than one member?

The same way I learned what lots of other words mean, I guess. (Reading? School?) My Webster's dictionary says:

a number of things of the same kind that belong or are used together

My real point with that was that, the way I see it, 'ss**' was meant to be the multiple-glyph version of 'salt'.

My real point with that was that, the way I see it, ‘ss**’ was meant to be the multiple-glyph version of ‘salt’.

That's certainly how I read the spec. Now, it's still reasonable to put for example an alternate "i" in ss01, in part because you probably also have that same alternate on all the various accented forms of the "i" as well.

Cheers,

T

It's always good to hear from folks at Adobe on these issues. Naturally, I agree whith Christopher and Thomas on these issues, and one of my mantras is "Design 10 years into the future", which is what Adobe's David Lemon once told me, concerning OT development.

In order for OpenType to be accepted and embraced, and for people to know how "drive" OT fonts, developers need to adhere to the spec. Just as all users of the road need to adhere to the same set of traffic laws.

I assumed that Rachel's work is personal, and not intended for publication, in which case she can make her GSUB work under any feature. (Closed Course. Professional Driver.) If Rachel intends to publish the typeface in question, she should think very carefully about how her alternate i feature functions: Is it a titling variant? Or a stylistic set? What espectations will users have about the font, based upon which OT features are programmed into it?

Maybe I’m grouchy too but…

I realize opentype feature implementation and UI design is still in it’s early childhood stage of development but in my opinion it needs an overhaul. With casual, handmade design the current and increasing trend, fonts capable of simulating the hand of the artist should be possible in Opentype font development and modern design applications. This means having the ability pull from a set of many alternate designs for a single glyph to randomly insert slightly different designs when a letter is repeated in a string of text.

I love the idea of stylistic sets but it needs to be implemented in a consistent manner throughout the whole suite. It almost seems like the individual teams (Illustrator, InDesign, Photoshop…) don’t talk to each other when it comes to UI design. I hope I can stick my foot in my mouth by the end of this month with the release of CS3 and we will see some improvements.

Josh

if you hijack features for your own purposes

It depends on one's perspective. It would seem that Thomas expects font developers to abide by the way Adobe interprets features.

For instance, by combining figure features, the InDesign implementation of OT figure styles is somewhat of a hack/buggy. Suppose I produce a font with two figure features, pnum and tnum. Now, if an InDesign user clicks on "Proportional Oldstyle", what happens? I just hope that doesn't "damage OpenType's reputation" :-)

To use Thomas' colourful language, the OT features have been hijacked so that Adobe's OT fonts, all of which have either one or four figure styles, serve the purposes of Adobe's layout applications, or vice versa. Either way, a perfectly legitimate font with two figure features appears buggy, when in fact it is the layout application which is at fault.

Actually, I have found it quite stimulating to *have* to produce four sets of figure styles, and I have great admiration for Adobe apps--and I always design with them in mind. And like chester, I follow their lead and advice on many things. I only draw attention to this figures issue to demonstrate that it's not an absolute situation, no design is perfect, and as there may be some interpretation involved in implementing OpenType features, there should also be room for flexibility.

Design 10 years into the future

But what if someone who chooses not to upgrade CS1 wants to access a stylistic set with InDesign today, without doing it glyph by glyph from the glyph palette? What possible negative future ramifications will occur if I put the alternates of a font like Softmachine in "Titling"? In fact, that's what I've done, and explained it in the "read me" pdf.

I think RachelR has her answer, so I hope we’re not really hijacking the thread. OK, I understand that someone may specify “set” is to be used only when there is more than one member, though that borders on Wittgenstein’s grumble about “private language” -– as best I remember my math logic, a set could have no members, one member, or more than one member . . . whatever.

Here is a true story. We had a book to set where the designer wanted to use text (old style) numbers, and small capitals for acronyms. Pretty normal stuff. As it turned out, there were some acronyms with an “I”, and one that occurred more than once where there was both an “I” and a “1” in the acronym. On seeing sample pages, the editor hit the roof; down came the mandate that either the os figures or the small cap acronyms had to go.

Putting on my Solomon cap (an unfamiliar role), I made up a os fig “1” that looked like a regular “1” (or like a Minion os “1”). Problem solved. This was back in the Type 1 days, so the glyph was named oneoldstylealt, and since, as I mentioned, we could write our own encoding vector, everything was pretty clear downstream to boot.

Now how are we going to handle this with OT? The need is there; designers and editors still fuss about their overlapping turf. As I understand it, if we were to put the alternate “1” in the salt feature, then it is on when any of the other features we might want as stylistic alternates are on. Not a happy situation. Moreover, if the “1” variant is to be used throughout the book, it needs to be picked up in ID’s “Paragraph Style Options - Open Type Features” which includes stylistic sets, but not salt, unless I’m wrong yet one more time.

My point, I hoped, was that the designers of type too frequently don’t pay enough attention to the users of type and their needs. Comps have that problem too, I know. All throughout the 19th century, the lead comp was the designer. But the compositors developed their own aesthetic, and it turned out not to be an aesthetic shared by most people, including the customers who paid the printing bill. Enter the layout man; the comps lost the privilege of designing.

Surely it was mechanization that sundered design and production in the 19th C.,, not the pecadilloes of compositors.

the reason that some people think stylistic sets should affect more than one glyph is not because they don’t know the definition of “set” but because the OpenType feature registry says so.

So, if you design a font with only one alternate glyph (I have seen fonts like this), the spec would bar you from putting the single alternate glyph into a stylistic set?

Or, let's say you have only two alternate characters and let's say they don't harmonize, you shouldn't put them into separate stylistic sets simply because there would only be one glyph in each set?

This insistence that a stylistic set must have two or more characters seems a little unreasonable and bureaucratic. In spite of the spec, is there any reason (practical or otherwise) that having a stylistic set that affects only one glyph would cause problems now or in the future?

I think we all have to look at it from the users perspective. If the user can't use it reasonably easily to achieve the desired result, then either the spec, the applications, or the font design need some adjustment (or all three). I know it is hard reigning in a comittee which goes accross corporate borders but if opentype is to gain ground, the process must begin.

ChrisL

We come up with feature functionality before giving it a name, so to argue that one can interpret the name of a feature one way or another is beside the point. The thing to consider is its specification and (lacking clarity there) its intended function. The stylistic sets features were conceived (IIRC) to gather more than one alternate and activate them together. Anyone is welcome to interpret a feature's function differently, but in the end, font developers will benefit from knowing what the intended, agreed-upon function of a feature is, to ensure that what they implement in their font will be consistent with those from other developers.

That said, the discussion about the difference between 'salt' and 'ss**' is more difficult than is typical, because the general concept of stylistic alternates is quite fuzzy compared to other features. For example, if one applies 'smcp' to a letter, it's pretty obvious what one should get. OTOH, if one applies 'salt' to a letter, all one knows is they should get "some stylistic alternate." Such an expectation is pretty vague, and certainly can't be expected to be consistent between different font families. Also, applications will probably always have different UIs for 'salt' and 'ss**', because the former is often "one from many", and the latter is always "one to one". (The reason there are multiple 'ss**' features is kind of a way of implementing "many to many from many".)

I don't think all this is a matter of "insistence" or "bureaucracy". I only think that a specification exists to create a standard on which people can depend to ensure consistent and successful results is a world where many things (fonts, applications, OSes) interact. I think the best way to ensure successful, pleasing layout features is to follow a specification, so I recommend that. Everybody else is quite welcome to do differently, with the inherent advantages, disadvantages, and risks. As we know, taking liberties with a layout feature's specified function has some appeal, but I just want everyone to be aware of the downside, too.

Great thread everyone, thanks for the input.

It seems from people in the know here that to ensure consistent and successful results stylistic alternatives aren't possible at the moment. I have the alternatives I wanted working using a ss01 feature, but at the risk of producing a buggy font, I'll side with caution and leave out the stylistic alternatives, better safe than sorry.

Surely it was mechanization that sundered design and production in the 19th C.,, not the pecadilloes of compositors.

Well, maybe. Take a look at Vincent Steer's Printing Design and Layout (London: Virtue & Co, 1934).

At the beginning of the present century, however, the need for an intervening stage between the written word and the printed word became acute. The printing industry had been split up into sections and where one man formerly performed all the operations necessary in the production of a piece of printing, now many specialists were required. Printers had lost the art of designing their own work and were soon to lose the proud privilege of doing so. The master printer, having now become a modern business man, was no longer to be regarded as an artist craftsman.

My take is that it was the time of Victorian excess in the comp world. The comps resisted the intervention of a "layout man," but the print shop owners noticed they got more billable hours out of the comps if they didn't do design as well, do that was that. It pretty much came about because the comps tried to outdo each other with different typefaces & complicated layouts -- not what the customers wanted -- sound familiar?

BTW, there is one used copy of the Steer at Amazon, cheap (I paid about $50 for my copy). Lots of good out-of-date ornaments if that's your thing.

My own understanding is that OpenType Layout features can perform several different functions. In my own terminology, OpenType Layout features can perform five different kinds of tasks:

a) linguistic: there is a very strong inherent meaning to the feature; the feature performs a task that is crucial in the process of producing linguistically (orthographically) correct text. Usually, there is an established orthographic tradition when such features are applied, and they are usually applied automatically by the typesetting software. Such features are init, medi, fina or isol for Arabic, haln or nukt for Indic scripts, rlig, locl or ccmp for all writing systems, and many others.
b) semantic: the feature has some clearly defined purpose, and affects the semantic aspect of the text — as well as the visual side. Typically, its use is discretionary but there is an established typographic tradition of when such features are applied, i.e. whenever a feature is applied, the general reader knows what this accentuation means. Such features include sups, subs and sinf commonly used in scientific purposes, frac, numr, dnom and afrc to denote fractions, hist to indicate a shift in the historical context of the text, ornm, ordn and others.
c) casing: the feature assists the typesetter in case conversions. It is a border-case between semantic and articulatory function, and deserves a class of its own. Use of different case may affect the semantic aspect of the text (e.g. proper names) or just the visual side (emphasis, headlines). The features include smcp, c2sc, case, pcap, c2pc, unic, cpsp.
d) articulatory: the feature has a defined purpose but there is not commonly-accepted convention, or code, that allows the reader to decipher the function; the convention needs to be established on a per-publication basis, e.g. zero, swsh, cswh, titl, dlig, onum, lnum. Such features may also be used to solve purely visual tasks, e.g. jalt, kern, pnum, tnum, curs. For non-cursive writing systems, this also includes init, medi, fina.
e) stylistic: the feature has no defined purpose and is used solely to diversify the visual aspect of the text or assists in solving of typographic problems, e.g. ss01–ss20, salt, liga, calt, aalt.

Each feature typically is tied to one of these functions, but some features can perform different functions. For example, features such as curs, init, medi, fina can perform linguistic, articulatory or stylistic functions, depending on the particular writing system, language, font and the purposes for which the user is employing the font.

My own view: Substitutions defined in features classified as performing semantic or articulatory functions, as well as some liguistic features (ccmp, locl) may also be duplicated in the stylistic features. "Hi-jacking" of the linguistic, semantic or casing features (i.e. implementing functionality in them that contradicts their defined function) should be avoided at all cost. The stylistic features can be "hi-jacked" practically without limitations: it really is up to the designer what kind of functionality gets implemented in ss01–ss20, salt, liga, calt. "Hi-jacking" of articulatory features should be avoided, but in some very specific cases exceptions can be made. For example, the zero feature might perhaps substitute some other glyphs except "zero" if the designer deems it necessary, or instead of a slashed zero, a different form of the zero glyph (clearly distinct from "O" but not necessarily using a slash) might get inserted.

For ssXX and salt, I personally always consider them to have a similar, "pivotal" relation to each other. In the fonts I develop I typically first develop the semantic and articulatory features.

feature fina {
lookup fina1 {
sub a by a.fina;
sub e by e.fina;
} fina1;
} fina;

feature swsh {
lookup swsh1 {
sub b by b.swsh;
sub g by g.swsh;
} swsh1;
} swsh;

feature hist {
lookup hist1 {
sub r by r.hist;
sub M by M.hist;
} hist1;
} hist;

Then, I develop the stylistic features. I start off with stylistic sets. In addition to substitutions that only happen within the stylistic sets, I also make sets that duplicate the functionality of some of the previously defined semantic and articulatory features. Pretty much any semantic or articulatory substitution can also in addition be viewed as a stylistic substitution -- users may want to use a different glyph not because they want to express a different function but also simple because they like it visually. I wouldn't go so far and duplicate the basic casing features (smcp, c2sc, case etc.) onto stylistic sets, but would do so for their alternates, e.g. if a font has several sets of small caps, I'd include pcap/c2pc but also make the petite caps a stylistic set ss01 and stylistic alternate salt for the small caps. Similar, alternate fractions (afrc) should be IMO also stylistic sets of regular fractions (frac) -- at least for precomposed fractions.

So, my ssXX features might look like:

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

feature ss02 {
sub a by a.ss02;
sub d by d.ss02;
} ss02;

feature ss03 {
lookup fina1; # Same as "fina"
} ss03;

feature ss04 {
lookup swsh1; # Same as "swsh"
} ss04;

feature ss05 {
lookup hist1; # Same as "hist"
} ss05;

Finally, I create the stylistic alternates feature (salt) which implements the same substitutions as the ssXX features but using one-to-one out of many lookups. Since Illustrator only supports the first alternate, stylistic alternates in Illustrator works exactly the same as stylistic set 1 in InDesign:

feature salt {
sub a from [a.ss01 a.ss02 a.fina];
sub b from [b.ss01 b.swsh];
sub c from [c.ss01];
sub d from [d.ss02];
sub e from [e.fina];
sub g from [g.swsh];
sub r from [r.hist];
sub M from [M.hist];
} salt;

I found this approach rather logical, consistent and also predictable for end-users.

I wonder what your thoughts on this might be.

Best,
Adam

Ps. Edited: by John Hudson's suggestion, I replaced "strong stylistic" with "articulatory" and "weak stylistic" with "stylistic". Also added a paragraph explaining that while most features are tied to one function, some features can be tied to different functions depending on the script, language or font.

As you know, most or all of us at Adobe disagree with you on the acceptability of "hijacking"; we think it should either never be done, or certainly not for mere convenience in a regular retail font.

That being said, some features are flexible enough that few uses of them are likely to constitute hijacking. I think this is true of 'salt' and 'ssXX'.

The type of hijacking that I find most objectionable is when there is a feature that is clearly defined for one purpose, and that is the purpose in question, but the font developer chooses to assign another feature as well or instead because of what happens to be supported in current versions of applications, and that other feature has a clearly defined and contrary meaning to the glyphs being put in it.

As an example, putting ending forms into 'calt' (connecting/contextual alternates) in a way that causes them to show up even in the middle of a word when 'calt' is on, is bad practice. Especially so given that 'calt' is supposed to be on by default. Also undesriable would be putting an arbitrary stylistic alternate into 'titl' (titling alternates).

Many of these sorts of things will be reasonable candidates for a stylistic set and perhaps a stylistic alternate.
I will continue to label such fonts as broken and buggy. I think that making fonts in this way is bad for everybody in the long run, even if it seems convenient in the near term. Yes, you can get much better performance out of your 16-cylinder font, but the gas consumption and emissions are long-term problems.

As a side note, your code example of 'salt' does not function identically to 'ss01' the way you say it does, unless your 'ss01' happens to also invoke some ".ss02" glyphs and some ".hist" glyphs, etcetera.

Regards,

T

Thomas,

I agree that my wording was overly optimistic. My "salt" and "ss01" do not work identically. I guess I should have said that using my implementation, it is possible to achieve largely similar results using "salt" in Illustrator and one or more "ssXX" features in InDesign. Since the "ssXX" features in InDesign are implemented in an additive way, one could say that InDesign offers a finer control than Illustrator but altogether gives access to the same glyphs.

As you noted, I'm also opposed to "hi-jacking" features that have a clearly defined purpose. This is most true for linguistic and semantic features. Strong stylistic features are a border case -- if there are really good reasons, some hi-jacking would be permissible, within reason. For example, the description of titl in the OpenType spec says "Function: This feature replaces the default glyphs with corresponding forms designed specifically for titling. These may be all-capital and/or larger on the body, and adjusted for viewing at larger sizes. (...) Recommended implementation: The titl table maps default forms to corresponding titling forms (GSUB lookup type 1).". However, as the English word titling is ambiguous (it may stand for "to provide a title for" or "to designate or call by a title"), I could imagine a designer putting fancy abbreviations such as "Mr.", "Ms.", "Mme." into that feature. It would not necessarily go with the exact wording of the specification, but would still make sense by general logic.

A.

Adam, a very nice & thorough job of thought & explanation.

Having said that, there are always matters that do not fall nicely into categories. I stayed out of the "small cap numbers" thread, but consider that there is a style Harvard Blue where titles are set cap-small cap. It is a fairly common legal style. Now any numbers occurring withing the book titles in this style should NOT be set with small cap lining figures, but with either full lining or old style, depending on the figure style of the journal.

But the feature one would turn on to set the titles would be "small caps," so as to make setting the Cap-small caps easier, and to avoid blocking kerning between the full & small caps. And for this reason, I wouldn't want the small cap feature to include small cap lining features.

From my perspective then, small cap figures belong in a stylistic set. I agree it is debatable.

Best,

Charles

Adam: Yes, the English word "titling" is ambiguous, which is why instead of an English word we use a feature tag and we define what that feature tag means. So the example you give is a great example of a designer doing something they shouldn't. In any case, even that kind of logic would not support putting a sylistic variant of a lowercase "i" into 'titl'.

Mark et al: Personally, I would not consider it egregious to have a stylistic set that only affected one glyph. I do think it would be a really bad idea to put completely unrelated things in a single stylistic set, as the whole point of a stylistic set is to get a consistent look, and it's meant to be applied globally.

Also of note is the idea that 'salt' is meant to be applied on a single character at a time, and implies a UI that allows the user to pick which alternate they want for the character being affected.

Josh: The functionality you're asking for is already possible and has been implemented in some fonts that work with shipping applications today. The 'rand' feature is not directly supported, but can be imitated by contextual substitutions. Given that context can go across words, the same word can be made to appear differently when typed repeatedly in different contexts, as one can see with "the" in Bickham Script Pro.

Nick: It would seem that Thomas expects font developers to abide by the way Adobe interprets features.

No, I simply expect developers to abide by the published specs.

You bring up a quite different (though certainly important) question of application support and UI. I have certainly never argued that InDesign's UI for OpenType features is wonderful. I agree that it could stand improvement in a variety of ways, and have repeatedly suggested that if other people are unhappy about it, they should put in a feature request so that the InDesign team will know that people are unhappy (http://www.adobe.com/cfusion/mmform/index.cfm?name=wishform). But as of a few weeks ago, going through the entire InDesign feature request database for the previous year, NOT ONE PERSON made such a request, and hardly anyone has asked for support for more OpenType layout features. This despite thousands of feature requests.

So, Nick, if that bothers you enough to write about it here, you should make a feature request. Otherwise you're like people who complain about the actions of elected leaders but can't be bothered to vote. It's not like I haven't pointed out the link before:
http://www.adobe.com/cfusion/mmform/index.cfm?name=wishform

Cheers,

T

i agree, charles. i feel that Adam's stance an explanation provides a comfortable middle ground between the fundamentalist OT spec hardline and the willy-nilly asignment of functions and features.

I still say you're going to hell, and taking me with you!

:)

T

My mistrust of classification systems is well documented, but teleological classification is a respectable Thomistic tradition, so I'll play along with Adam's suggestions. I'm not very happy with the titles 'Strong Stylistic' and 'Weak Stylistic', because these qualifiers seem to undermine the functional focus of the classification. I would probably use, respectively, 'Articulatory' and 'Stylistic'.

Of course, now we can have a good argument about whether e.g. the 'curs' feature is linguistic, articulatory or stylistic. And the answer is that it might be any of these, or straddle categories, depending on the particular script, language, font and the purposes for which the user is employing the font. And there goes another classification system... :)

Charles, the emergence of the layout man, later to be termed art director or graphic designer, was due to more widespread phenomena than just changes in typography. Mechanization happened in all areas of publishing. "The Origins of Graphic Design in America 1870-1920" by Ellen Mazur Thomson is the best work I've come across on the phenomenon.

Also undesriable would be putting an arbitrary stylistic alternate into ‘titl’ (titling alternates)

Thomas, "titling" is the least logical of the "discretionary alternates", because really it's just a lazy way of not making another font. After all, what is the difference between titling and a display/size-specific ("optical scaling") font? Surely typographers should have access to (almost) all characters in a font at display size? It seems to me that "titling" was instituted to accomodate Adobe Garamond's titling caps -- meanwhile types such as Kepler, Freight, Filosofia, Requiem etc. offer the whole shebang. Therefore it deserves to be repurposed!

Thomas,

> Yes, the English word “titling” is ambiguous, which
> is why instead of an English word we use a feature
> tag and we define what that feature tag means. So
> the example you give is a great example of a designer
> doing something they shouldn’t.

Let’s analyze the feature description: "This feature replaces the default glyphs with corresponding forms designed specifically for titling. These may be all-capital and/or larger on the body, and adjusted for viewing at larger sizes."

A fancy "Mr." ligature is a "corresponding form designed specifically for titling". Not "titling" as in "to provide a title for" but "titling" as in "to call by a title".

The feature description then goes on to speak what the corresponding forms may be. Just by reading the feature description, it does not say that a fancy "Mr." ligature with a raised and underscored "r" is not what this feature is for. As I said, the word "titling" is ambiguous, and the titl feature description does not clarify whether it is only one of the meanings that it is intended for. The example cited in the feature description ("The user applies this feature in Adobe Garamond to get the titling caps") shows one possible solution, but it is not exhaustive.

It was not me who wrote the feature descriptions in the OpenType specification. An average font developer may or may not know what the developers of the specification had in mind when writing the wording.

If you must, please accept this contribution of mine as a call for clarification of the feature description of titl to minimize possible implementations that you consider non-conformant.

A.

Ps. Please keep in mind that non-native speakers such as myself tend to read texts more literally if they do not necessarily know the cultural background. Perhaps for you, it is obvious what exactly the word "titling" means in this context. For me, it is not.

Nick, if that bothers you enough to write about it here, you should make a feature request.

It doesn't bother me, as I said I have been challenged and stimulated by it -- to create old style figures for a scotch modern face, and it surprised me that they turned out OK (at least I thought so). What bothers me is the hard line on standards. I like to see clearly defined standards, but at the same time I don't mind digression. In fact, clearly defined standards encourage meaningful digression.

I don't see myself making feature requests to Adobe, or getting involved with industry groups. I've done my share of that and I often end up being a lone dissenting voice, which wearies. I'd rather discuss things on Typophile, this is where the action and ideas are -- and your blog is cool too.

"...the entire InDesign feature request database for the previous year, NOT ONE PERSON made such a request, and hardly anyone has asked for support for more OpenType layout features."

There is at least one now.

ChrisL

Ok, maybe the right place for my comment was on this thread.  ;-)

Further to my comment on the uselessness of the "Titling" feature:

http://typophile.com/node/32478

**

So I will carry on putting alternates in "titl" so that users of older apps can access the feature.
However, I have decided to in future use Stylistic Sets and Stylistic Alternates "properly", based on arguments above.

Oops. I just thought of a good use for Titling -- for a set of Inline, "Tooled", or Decorative Capitals, such as those in Scala (although there are four sets). Perhaps those would be better as stylistic sets. But if there was just one set of fancy caps, something like Castellar, inserted in a tradition serifed font, for example.

Nick,

since Titling Alternates is an "articulatory" feature and Stylistic Sets is a "stylistic" feature, I think it is quite fine to place the Inline, “Tooled”, or Decorative Capitals into the "titl" feature and *also* have them as one of the "ssXX" features. I think everybody agrees that there is no problem with having the same glyphs being invoked through different features, as long as each and every of these paths does not conflict with the registered description or the intended meaning of each of these features. A set of decorative capitals is both "titling" and "stylistic", and you don't have to make an "either or" choice.

A.

To the assembled, does the following constitute a "true" titling application?

Versions of A, O, and U with "embedded" umlauts, which are contained within the cap-height. These forms are not appropriate within running text, but they can be used for all-caps headline setting. These forms should not be linked to case, because not all languages would benefit from these variants.

If this is a true titl, should it also be tagged to only occur in German texts?

Looking forward to hearing both opinions and answers.

Versions of A, O, and U with “embedded” umlauts, which are contained within the cap-height. These forms are not appropriate within running text, but they can be used for all-caps headline setting.

Sounds good.

I would not restrict it to one language. What about adding some more fancy versions for combinations with acute, grave, circumflex?

Karsten

> Versions of A, O, and U with “embedded” umlauts,
> which are contained within the cap-height.

It is very appropriate for both Titling Alternates and Stylistic Sets. Language tagging typically makes sense to enforce certain behaviors by default if the text is known to be in a particular language (e.g. the Serbian Cyrillic alternates in "locl", the localized forms feature, specific substitutions for non-Arabic languages that use the Arabic script), or to prevent some behaviors to happen in a particular language that would otherwise occur, but would "spoil" the setting in that language (e.g. the formation of f+i ligatures in Turkish and related languages).

I think for completely discretionary features where it is not known with certainty that a particular behavior is suitable only for German or not at all for German, restricting a substitution to one language only is not a good idea.

Best,
Adam

Adobists-

I would expects a spec-positive approach from anyone developing fonts inside Adobe. Not only have they co-authored the specification, but are large and need a consistent toolbox for everyone internally.

Nevertheless, what makes a font OpenType, is the file format (talbes) and a digital signature. This is accessible to anyone. The structuring of the specification is not. The value of OpenType to Adobe is increased by Metcalfe's law, so your OT fonts increase in value with the aggregate output of outside developers--but without being part of the spec design, they (we) are a lawless horde, which tends to complicate things.

Likewise, I do not think it is unfair for others to expect that Adobe will implement all the features they sponsored for inclusion prior to dictation of best practices. I take most earnestly the recommendations that are implemented by them, not just stated. They are the only (of all two) specification designers that has a strong position in actual dtp software and font development. After all, why else should they determine the final wording of the specification? (Example: 'RAND')

Adam-

I find your breakdown very useful for a project I am working on. I was trying to formulate something similar, with little success. Do you mind if I borrow those categories for the collaborative taxonomy of OT components I am working on in my "spare" time?

These forms are not appropriate within running text...

Not necessarily.
Wherever leading is tight or solid, cap accents get in the way.
And it's the art director's prerogative to do that, negative leading even.

If this is a true titl, should it also be tagged to only occur in German texts?

Dude. Blue Öyster Cult.

Wherever leading is tight or solid, cap accents get in the way.
And it’s the art director’s prerogative to do that, negative leading even.

And the comp's prerogative to tell such an art director to look for a short pier to take a long walk off -- or should that be "off which to take a long walk"?

A designer who doesn't take into account the language used in running text, for whatever reason, is a stylist -- who cares nothing for authors or readers.

Charles, art directors working in many languages set text solid--many of them with a complete lack of style.
Often lack of space, or excess of text, is the culprit.
Perhaps "embedded" cap accents will help.

Nick, you're right of course. Under those conditions (never happens in my line of work), it would make sense, if the community of readers understood & accepted it. There is even a precedent in mathematics -- the limits for summation & integration are place on top in displayed equations, but along side when the equation is run into text, expressions having numerators/denominators indicate them with a solidus when run in, and so on.

Edit

I hope it goes without saying that these glyphs should be in addition to the caps with regular accents. This could even be a plus -- I've always felt that the accents on Quadraat capitals compromise the design a bit. Mr. Smeijers may feel otherwise, of course.

So, are people saying that embedded/tucked accented caps should be a it's own, new, separate feature tag?

Yes, it should be a stylistic set feature, because typographers will want to apply it to a mass of text.

Yes, it should be in stylistic alternates as well, typographers might not think to look in the sets for it.

No, it shouldn't be language-specific, because it is not a linguistic attribute.

Perhaps a font targeted specifically for German (and English heavy metal) use could include it as "calt" - so that it is on by default, but could be turned off if perchance a Scandinavian uses the font.

Nick,

In contemporary German typographic practice, such treatment of accents as shown above in Futura is considered dated, antiquated, or at least, it is left for very discretionary purposes. Most certainly it should not be on by default.

Choz,

feel free to use my categorization in your work. You are welcome to mention the source -- to ensure the readers that it is not any "official" classification but the result of my subjective view of the topic.

Best,
Adam

dated, antiquated

That's what I had in mind, a retro or historical revival typeface that played up such tight-fitting qualities. But you're probably right, it shouldn't be on by default.

What about adding some more fancy versions for combinations with acute, grave, circumflex?

A comparable treatment for French etc. would be a didone face where acute, grave and circumflex cap accents are all just a thin horizontal hairline.

**

Adam, your thoughts please on the occasional Polish practice of running the cap acute right through the top horizontal stem of C, S and O?

> Perhaps a font targeted specifically for German (and English heavy metal) use could include it as “calt” - so that it is on by default, but could be turned off if perchance a Scandinavian uses the font.

Don't implement such behavior in 'calt', because turning the feature off may disable other functionalities present in 'calt'.

(and English heavy metal) use

They are generally niche-purposed swashes, with no affect on pronunciation or meaning. Shouldn't they should normally go in a stylistic set? Or, perhaps, even in swash (assuming the face didn't have a broader-use swash). Don't forget that it isn't just English-speaking/targeting bands that use the umlaut gratuitously, and that it is not restricted to topping a o and u. !Panzermensch, that "heavy metal" face I was showing last October, features an umlautted n, as an homage to Spinal Tap.

@ our next board meeting I will propose that !Exclamachine work to sponsor the -hmum- tag.~

. You are welcome to mention the source — to ensure the readers that it is not any “official” classification

I'll call it the Twardoch Method™. :) There does seem to be enough thought and acceptance by those that understand OT in this thread that if you haven't nailed it down, you are on a very interesting track. I am not going to say that it is officially anything, but I think that it might be a great tool for those trying to get their brain around OpenType concepts. I like the way you break it into more manageable bites, which is the overall goal of my project. Since it is a wiki, there is no harm in having several ways of categorizing. So far I had just begun building a database using the inherent hierarchal tags, and grouping by lookup types. This will become another searchable, groupable vector.

an umlautted n, as an homage to Spinal Tap.

Sounds like a candidate for Unicode.

"It's like a pair of eyes. You're looking at the umlaut, and it's looking at you."
-- David St. Hubbins

I think they want it (the 'n̈') to only be assembled out of some sequence of tedious demiglyphs. The futureproof standard with enough space for "forever" used up all the best code points for the 720° rotated extreme 'e', the deformed-P with dot below ('‽') and other typographic gems. They are running scared now and very picky about what they will add. The Snark's only chance at officaldom, for example, is if it evolves into a form that looks similar to, but not exactly like a tilde-on-a-dot. I think.

I should have gone to bed already, and not peeked back in on this thread! At least we're not debating this: http://en.wikipedia.org/wiki/Talk:Heavy_metal_umlaut#n-umlaut

>> an umlautted n, as an homage to Spinal Tap.
> Sounds like a candidate for Unicode.

It is in Unicode. The Unicode Standard encodes it as U+006E U+0308. The character does not have a precomposed form, but it does not necessarily need one. In an OpenType font, you’d define a mark attachment feature mark so that "n" followed by "dieresiscomb" snap into place, and optionally, you could also supply a precomposed glyph named "uni006E0308" that you’d access through the ccmp feature.

A.

It is in Unicode.

Not much use if the font (such as helvetica.dfont, which many a web site calls for--and nothing this user can do to deny them) has combining accents which don't have a negative left sidebearing. I'm looking at Spin¨al Tap.

Surely negative left sidebearing on (most) combining accents is a best practice?

Or are there applications that position combining accents by backspacing them?

Kerning pair perhaps?

ChrisL

Not much use if the font (such as helvetica.dfont, which many a web site calls for

But adding the n w/ umlaut to a new font would also not solve that problem.

and nothing this user can do to deny them)

Switch to Opera? They offer a lot of style sheet control for the user. Or install the Firefox developer's toolbar add-on, then write up your own style sheet override that uses any face. No one is still really using IE are they?

Surely negative left sidebearing on (most) combining accents is a best practice?

I'd really like to know the current consensus on that.

Nick,

I believe a negative sidebearing for combining accents is a fine design solution which works well in "primitive" applications. Ideally, such font should also contain mark positioning.

A.

Besides its use in the name of a certain mock-rock group, Ndieresis and ndieresis are used in the Malagasy language, but the glyphs do not have "standalone" Unicode indices (yet). They can be made using ccmp, as Adam notes.

Ideally, such font should also contain mark positioning.

What's the code for that?

> What’s the code for that?

You'll have to use VOLT if you want to do mark positioning. The AFDKO (v2.0) can't do it yet.

"Predictably enough, I’m with Christopher on this one. I’ll also go so far as to add that if you hijack features for your own purposes, you are making a font that can reasonably be called a hack, or even buggy."

A HACK ? You want to talk about a HACK look no further that CS3.

Three programs made by one company and all handle Open Type fonts differently.

That would be Photoshop, Indesign and Illustrator.. Turn on Ornaments in Indesign.. Nope can't do it that can only be accomplished in Photoshop. Turn on Stylistic Alternates in InDesign.. Nope can't do that also you can only do that in Photoshop.

Turn on Stylistic set 01 in Photoshop or Illustrator. Nope can't do that also. You only can do that in Indesign.. See a pattern here of nobody is keeping track of what the other programmers are doing ?

Do you think they could have hid the open type features panel much further down the list. It's only three menus deep.

Font lab has the right idea, give you a list of options and let you turn them on in any order you want. Don't have to go searching for it or turning one option only at a time before the three menus close again..

The whole glyph pallet is a hack. You don't need that, Font designers can actually program it if aalt list was being used like it is suppose to be used, to build a list of option buttons into the application.

It's no wonder people keep building fonts with everything in the wrong place.

There trying to get there hard work to work with stupid open type implemented programs above.

I'm astonished at how poorly the open type features are written into the above three applications now that I'm testing my font on them.

Just read the aalt list and give them buttons for every option listed. Don't bury them on auto closing menus three layers down.

Pete, I'm afraid this is not news.
The folks at Adobe, in the different departments of type and the several applications involved, have been aware of the problems with OpenType application support since they first introduced it, and their attention has been drawn to the problems by others (such as myself), since at least 2002.
For many reasons--the most telling of which is that expert typography is an insignificant part of the graphic design industry --fixing the problems is simply not a priority, although some progress has been made, in Illustrator for instance, where the OT features palette can be brought to the top level.

I for one am grateful that OpenType exists (and we do have Adobe to thank for that), despite any flaws, inherent or in application support.
And I'm really excited about the OpenType support in the upcoming MyFonts.com redesign.

I'm actually glad also that it exists because the fonts I make and want to make would be impossible with out Open Type but still the implementations of it are totally inconsistent. I know that this is not a new problem but really has this feature not been around for 8 years already? You know how I found this thread, Googling how to turn on Stylistic Alternatives on in Indesign. Three programs with the same suite code all handling Open Type fonts and not one doing it the same. Different menus, different options. It may be a hack alright and I write in all my fonts I'll fix it as soon as Open Type programs get fixed up and work the way they are suppose to work. I have two options, break the rules and give them more content or leave them out and give them nothing. Actually later I found this list and it shows the sorry state open type support is in programs.

Here I'll have to shorten the link, warning it's a one page pdf document.

http://tinyurl.com/4cavo4

I'm moving options around to get them working somehow because the feature support is inconsistent. If people have a problem with that then don't use those options.

It's not a big problem if everyone owns all three of those programs but that is a pipe dream. If they only own one they are at a serious disadvantage.

That glyph pallet gets you around the problem of older fonts not being able to get a hold of glyphs because they were not programed into a feature but now days it has the effect of breaking features if they are now programed in. Where is the ornaments feature ? If you programed it in CORRECTLY it is now broken in Indesign.

Works the Photoshop and you have to hack one a time in Indesign to do the same thing. Actually what you are doing is forcing the user to try to figure out how to program your font that they never made don't have a clue where the glyphs are, what there names are and how many into programming it onto a little substitution list..

Now that is consistent.

On a font that has 10,000 glyphs that the menu consistently insists to show the entire font every time you try to type something in.

Oh that's a better idea alright.

Very interesting, this thread shows how much we look differently at type functionality…
I have a pair of questions:

- I am trying a functionality, which substitutes groups of letters with politypes. I placed the most important, basic substitutions as discretionary ligatures, and then I added other substitutions into separate Stylistic Sets, so the user will be able to avoid an excessively decorated text.
If the additional ligatures are – say – in stylistic sets ss03 to ss05, would it be better to duplicate all the substitution features in subsequent sets? i.e. Would it be better to have ss05 contain all the possible substitutions or just the more decorative additions?

I wonder about this, since some additions concern letters of different height, which the user should be able to turn off while mantaining politypes resting within the regular height…

- Since I would like to avoid duplications, may I just duplicate (according to the advice given before) the ones I consider "stylistic alternates" in both [salt] and a stylistic set? I find this goofy, since I prefer to use [ssXX] for substitutions that involve a set of more letterforms…

I just realized this is an older topic brought back to life. Thought i was having a Dejá Vu.

I've been working on an OT version of a recent hand lettering font for my day job. I had 3 cap I's for it: one standard, one swash, and one just as a chosen alternate. In the aalt feature I just added a straight sub for that letter for the alternate and it became available in the glyph menu of both Illustrator and InDesign. If I were to add it to the salt feature it would be presumably be accessible through Photoshop as well. Is using the aalt feature like this considered OK or is that in a sense a hijack as well?

I hope someone replies, maybe I should have started a new thread, but I thought this was appropriate. :=)

Can you define what you mean by politypes. That one wasn't in my dictionary and so it might make things clearer to understand the nature of substitution that you want to do.

If you are talking about multiple glyphs to be substituted by a single combined glyph, then you have to label it as a ligature. Not all ligatures must be substituted automatically. Besides the discretionary ligatures you could also employ the feature clig. That lets you define the context of a ligature, however, both calt and liga features must be active for it to work as far as I've seen.

You could consider a new post as this won't be on the front page and its kinda long.
ps.
Sorry about responding to you're original question with another question.

Stephen

Thanks Stephen, maybe I'll start a new thread.
I used "politypes" to make a distinction from normal ligatures, since the name ligatures to me is more related to lowercase, as it came about in current writing, when the need for writing faster arose.
My politypes (politipi) are multiple glyphs and mostly formed by two uppercase.
None of those is contextual (so no [calt], for now), and I have divided them between [liga] and [dlig], leaving on [liga] only the one really needed (for example [T_T]).
Hope my question is a little clearer now… :=)

Your question is strictly about [aalt], I'm sorry I am unable to answer, as I was wondering myself if [aalt] could be used just to make all alternatives grouped in the glyph palette of InDesign, or if its use needs to be justified by more important issues… :=)

I apologize in advance for resurrecting such an old thread, but just like Mighty Pete, I got here exactly the same way - trying to google how to turn on stylistic alternates in InDesign for a font I'm creating.

I also agree with Thomas Phinney in that "hijacking" OpenType features is a bad idea.

So, Adobe, quit making us "hijack" OpenType features. "Hijacking" OpenType is a lot better than not doing the work to create a flexible typography option. I find the tone of Phinney's post rather galling, as it's the company he works for which has forced my hand. What are the other options? Offering different fonts and going back to the bad old days before OpenType? Not even remotely imaginable.

The best solution would be for Adobe products to actually support OpenType features consistently and fully. What I'm doing with my typeface is, in some circumstances, not really covered in OpenType, so my original plan was to create ten different stylistic sets, not including the default. I can't do this, so then I was forced to "hijack" features to get them to work at all, only to find out how woefully Illustrator is behind the times, and then to discover that the common feature tag support between programs WITHIN CS5 isn't even consistent.

I'm very irritated that I'm being forced to hijack features due to inconsistent and incomplete support in CS5 for issues that involve OpenType feature tags that have been documented for at least 11 years. The tag may be older, but I see references to it in the spec change logs that go back to at least 2000.

Delusion, remember that you're not addressing "Adobe" here, because "Adobe" does not read Typophile. Adobe's type team does (or at least some members of it), but they want mostly the same things you do. It doesn't matter because the product teams do not perceive there being popular demand for these features, and/or think very few of their users will care.

If you want to have an effect on the features in Photoshop, Illustrator and InDesign, besides complaining here, log a feature request for each affected product.

https://www.adobe.com/cfusion/mmform/index.cfm?name=wishform

I'm curious about what you were trying to do and why stylistic sets were not a viable workaround.

Best of luck. I do know it's frustrating. (Also note that I haven't worked for Adobe for over two years.)

Cheers,

T

I apologize for delivering the brunt of my irritation to your doorstep.

I find it so strange that Adobe, or the product teams of the individual products, or whoever, doesn't make complying with OpenType as robustly as possible a priority. When I think of typography, Adobe is one of the first few companies I think of, and it's a standard they helped create.

The reason Stylistic Sets aren't a solution for what I'm doing is that Indesign is the only of the four CS5 programs I use that supports it. Premiere probably isn't that big of a deal for me personally, as on the rare occasions I use it it's usually just for personal projects. Indesign supports it, but Illustrator and Photoshop scratch their collective heads at it.

The typeface I'm creating is historically related to Win Crouwel's New Alphabet, so the options I'm creating are more appropriate for Stylistic Sets than the "traditional" OpenType features. An example of this is that I'm providing a set for an overline to represent a doubled character, a monospace set, a monocase set, etc. OpenType has a unicase tag, but none of CS5 supports it, and a monocase tag isn't in OpenType. The overlining for doubled characters - effectively a set of double-letter ligatures - is too idiosyncratic to even consider as an OpenType feature tag. Stylistic Sets would be ideal, but most of this is per-pixel based work and best suited to Photoshop. To be a bit more practical, it would help if re-naming the Stylistic Sets were supported, so that someone wouldn't have to guess or consult a cheat sheet.

The company that Adobe used to be in the Warnock era would have done the right thing and supported the entire collection of Adobe apps with all opentype features and perhaps even made them work the same way on all of the apps. Today's Adobe regime is a different beast. They have become large enough and powerful enough in the marketplace to feel free to ignore their fine heritage. They have achieved the Peter principle size of bureaucracy where pure organizational divisions led by pure organizational managers with pure organizational egos rarely perceive each-other's common goals and customer needs in favor of the cost-benefit analysis seen with only a bean-counter's mentality. There have been repeated and consorted attempts by users to at least include a basic glyph palette in Photoshop let alone stylistic sets. Adobe has ignored them. Before I hear the mantra of "submit it as a feature request via their website" yet again, I will mention that I have and we have and no-one gave a damn except the folks there who are too low on the totem pole to have a voice.
The catch 22 of user requests is that they can't request what they don't understand and they can't understand what does not exist in a sensible enough way to reveal its true worth. Stylistic sets buried 3 levels deep with no way of knowing how they function because catchy names like ss01, ss02, ss03, don't mean diddley sßit to the average user.

I wonder how many feature requests came through the Adobe web site in the early 1980's for a thing called PostScript? Probably was no such link then--probably no web site then either;-P Guess what, Warnock went ahead and did it anyway even though most potential users of the time did not have a clue what it meant. Warnock and Company then "Splained it to them Lutsy" and next thing you know, we had the DTP revolution. Of course, Warnock was a visionary and these guys now are just Harvard MBAs whose idea of vision does not venture past their divisions current quarterly profit report.

> Stylistic sets buried 3 levels deep with no way of knowing how they function because catchy names like ss01, ss02, ss03, don't mean diddley sßit to the average user.

Wouldn't that be "diddley ʃit"?

yup

I just have trouble understanding the presumed conversations between the Office/AdobeApps groups, and the respective Type Groups:

TG:"if you do it that way, you'll break the fonts."
O/AA G: "okay"

Don't sound much like a standard to me.

Hope this all works on the web. :o

I hear and share your frustration.

Getting a glyph palette in Photoshop would be fabulous. The best current work around is to get what you want in Illustrator and copy/paste it into Photoshop. (Illustrator and Photoshop share a text engine, while InDesign has a different one.)

To be fair, Adobe was big and silo'd even before Warnock and Geschke left day-to-day running of the company. It's gotten worse, but that is as much a function of pure size as anything else.

Much as I wish I had stylistic sets in Illustrator and Photoshop, and that InDesign and the others all supported showing "friendly names" for Stylistic Sets, I understand the motivations of the product managers for these products. As basic as typography is to me, and to most of the people reading posts on a site called "Typophile," the product managers are looking at what gets user demand and what solves the problems that users complain about. The PMs can do the stuff that they are really sure will sell, or they can take a chance that if more/better typography is dangled in front of the users that those users will turn out to appreciate it in the end. As long as the list of sure winners is sufficient, the stuff you and I really want is not making the cut. :(

Chris: The golden age might not have been as golden as you think. Some time ask me in person and in private exactly how we got the big burst of OpenType features in InDesign 2.0.....

Cheers,

T