Stylistic Alternatives - Indesign ?

Primary tabs

93 posts / 0 new
Last post
Rachel Roberts's picture
Offline
Joined: 21 Feb 2007 - 12:23pm
Stylistic Alternatives - Indesign ?
0

The font I'm working on, I wanted to have an alternative "i", so I used the salt feature. I have two classes, "i" and "salt", containg the glyphs to change.


feature salt {
sub @i by @salt ;
} salt;

First of all, is this the correct way to go ?

Everything works great within Fontlab in the opentype window, but how do I get it to work in Adobe Indesign or other applications. The opentype menu doesn't seem to have any options to use the alternative glyphs.

Village's picture
Offline
Joined: 25 Jun 2006 - 8:52pm
0

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.

Rachel Roberts's picture
Offline
Joined: 21 Feb 2007 - 12:23pm
0

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.

James Mark Hatley's picture
Joined: 13 Jul 2004 - 11:00am
0

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".

Village's picture
Offline
Joined: 25 Jun 2006 - 8:52pm
0

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.

Village's picture
Offline
Joined: 25 Jun 2006 - 8:52pm
0

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

Nick Shinn's picture
Offline
Joined: 8 Jul 2003 - 11:00am
0

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.

James Mark Hatley's picture
Joined: 13 Jul 2004 - 11:00am
0

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.

Rachel Roberts's picture
Offline
Joined: 21 Feb 2007 - 12:23pm
0

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.

David Yoon's picture
Offline
Joined: 17 Apr 2006 - 7:58pm
0

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.

Rachel Roberts's picture
Offline
Joined: 21 Feb 2007 - 12:23pm
0

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 ?

David Yoon's picture
Offline
Joined: 17 Apr 2006 - 7:58pm
0

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.

Village's picture
Offline
Joined: 25 Jun 2006 - 8:52pm
0

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.)

Christopher Slye's picture
Joined: 5 Oct 2006 - 11:03am
0

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.

Mark Simonson's picture
Offline
Joined: 3 Dec 2001 - 11:00am
0

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.

Christopher Slye's picture
Joined: 5 Oct 2006 - 11:03am
0

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.

James Mark Hatley's picture
Joined: 13 Jul 2004 - 11:00am
0

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.

Rachel Roberts's picture
Offline
Joined: 21 Feb 2007 - 12:23pm
0

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 ?

Göran Söderström's picture
Joined: 15 Feb 2006 - 2:53am
0

/track/

Charles Ellertson's picture
Joined: 3 Nov 2004 - 11:00am
0

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?

Rachel Roberts's picture
Offline
Joined: 21 Feb 2007 - 12:23pm
0

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.

Charles Ellertson's picture
Joined: 3 Nov 2004 - 11:00am
0

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.

Nick Shinn's picture
Offline
Joined: 8 Jul 2003 - 11:00am
0

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.

Chris Lozos's picture
Offline
Joined: 25 Feb 2004 - 11:00am
0

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

ChrisL

Thomas Phinney's picture
Offline
Joined: 3 Sep 2002 - 11:00am
0

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

Christopher Slye's picture
Joined: 5 Oct 2006 - 11:03am
0

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'.

Thomas Phinney's picture
Offline
Joined: 3 Sep 2002 - 11:00am
0

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

Village's picture
Offline
Joined: 25 Jun 2006 - 8:52pm
0

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?

Josh Scruggs's picture
Offline
Joined: 7 Jun 2005 - 10:47am
0

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

Nick Shinn's picture
Offline
Joined: 8 Jul 2003 - 11:00am
0

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.

Charles Ellertson's picture
Joined: 3 Nov 2004 - 11:00am
0

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.

Nick Shinn's picture
Offline
Joined: 8 Jul 2003 - 11:00am
0

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

Mark Simonson's picture
Offline
Joined: 3 Dec 2001 - 11:00am
0

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?

Chris Lozos's picture
Offline
Joined: 25 Feb 2004 - 11:00am
0

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

Christopher Slye's picture
Joined: 5 Oct 2006 - 11:03am
0

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.

Rachel Roberts's picture
Offline
Joined: 21 Feb 2007 - 12:23pm
0

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.

Charles Ellertson's picture
Joined: 3 Nov 2004 - 11:00am
0

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.

Adam Twardoch's picture
Offline
Joined: 3 Dec 2002 - 7:36pm
0

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. ss01ss20, 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 ss01ss20, 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.

Thomas Phinney's picture
Offline
Joined: 3 Sep 2002 - 11:00am
0

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

Adam Twardoch's picture
Offline
Joined: 3 Dec 2002 - 7:36pm
0

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.

Charles Ellertson's picture
Joined: 3 Nov 2004 - 11:00am
0

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

Thomas Phinney's picture
Offline
Joined: 3 Sep 2002 - 11:00am
0

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

paul d hunt's picture
Offline
Joined: 5 May 2005 - 8:44pm
0

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.

Thomas Phinney's picture
Offline
Joined: 3 Sep 2002 - 11:00am
0

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

:)

T

John Hudson's picture
Offline
Joined: 21 Dec 2002 - 11:00am
0

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... :)

Nick Shinn's picture
Offline
Joined: 8 Jul 2003 - 11:00am
0

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!

Adam Twardoch's picture
Offline
Joined: 3 Dec 2002 - 7:36pm
0

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 Shinn's picture
Offline
Joined: 8 Jul 2003 - 11:00am
0

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.

Chris Lozos's picture
Offline
Joined: 25 Feb 2004 - 11:00am
0

"...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

Karsten Luecke's picture
Offline
Joined: 6 Aug 2005 - 8:41am
0

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

Nick Shinn's picture
Offline
Joined: 8 Jul 2003 - 11:00am
0

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.