InDesign does support the 'ruby' feature as an option on ruby in the Japanese version. But I agree with your post in general.

Very interesting, thanks for the screenshot. Looking at it, isn't it time for Adobe/MS to publish some guidelines as regards the relation of OpenType UI options and features? Maybe just sum up what InDesign or WPF do -- since fonts produced so far have been made to work with these.

A few examples: The screenshot shows that there are separate options for "Standard Swashes" and "Contextual Swashes" (both features called by "Swashes" in ID), or "Standard Ligatures" and "Contextual Ligatures" (both called by "Ligatures" in ID), or "Capital Spacing" is a special option (bundled with uppercase'ing in the "All Caps" option in InDesign).
AFAIK, the distinction between contextual and non-contextual versions of a feature is a mere technical, not a semantic one -- and I remember that earlier recommendations said, put ligatures in "Ligatures" and contextual ligatures in "Contextual Ligatures", plainly based on whether they involve context or not. Now this would have the effect that if a user activates "Ligatures" but not "Contextual Ligatures" he only gets half of what the designer intended to happen when clicking e.g. the "Ligatures" button.
And why is kerning made a separate option?

It is great to see that more applications support OT features -- but as of now, with (more or less) different interface approaches take alone from Adobe and Apple (and are there any WPF-based apps already?), I fear that OpenType options will confuse designers rather than encourage them to actually use them. And maybe even apply features "wrongly" by activating them only partially ...

Karsten

I fear that OpenType options will confuse designers rather than encourage them to actually use them.

That's the reality right now! But I don't expect that the interfaces will ever get unified across applications. The needs of users of a word processor, layout or image procession software are much too different.
I would be glad if at least the menu names for the OpenType features would be unified. In the German Creative Suite there are up to 3 names for one feature and some translations are completely wrong. And the names are new in every version! I'm not surprised that many CS users have never opened the OpenType menu/panel.

The problem of how to present OpenType features to users consists of a few separate problems that InDesign has had to deal with:
1) Features that are mutually exclusive. For example, pcap and smcp probably shouldn't be applied to the same text. And dnom, sups, sinf, subs, and numr would be problematic when combined.
2) Features that make sense applied together. For example, it seems unlikely that anyone would need to apply case and cpsp independently.
3) Features that don't really need to be called out. For example, ccmp, locl, or rlig.

To address (1), InDesign applies certain features based on mutually exclusive settings. For example, the numbering styles in InDesign become variations of pnum, onum, tnum and lnum.

To address (2) InDesign groups some features together in "bundles" underneath some user applied attributes. Here are some examples.
Discretionary ligatures - dlig + hlig
Contextual alternates - calt + clig
Swashes - swsh + cswh
All caps - case + cpsp (if the font's kerning is used)
Note: clig is applied with calt, not liga.
Question: should cswh be considered contextual or swash in nature?

We have a couple examples of (3) where OpenType features are on and there isn't any way for the user to turn them off (outside of scripting): locl, mark, mkmk, ccmp, and rlig.

eric

The problem of how to present OpenType features to users

What problem?
Why don't you just list the features in a font?
Then users can decide which they want to apply.

As it is, different layout applications, whether Quark vs Adobe or InDesign vs Photoshop, have their own *interpretations*.
This is not doing users or font developers any favours.

Hello Mr Menninga, thank you -- also for correcting my clig error, and for pointing out the dependency of cpsp on kern of which I was not aware. This is very helpful, and I like the categories.
(1) is a very sensitive one. For font developers it were nice to know that all application developers stick to this for sure, then ordering features/lookups at least for certain features were much less of an issue.

Ralf Herrmann -- That's the reality right now!

Yes, but currently it's only very few applications which offer OT support, so it's still possible to guide the many others who plan adding OT support.  :)

But I don't expect that the interfaces will ever get unified across applications. The needs of users of a word processor, layout or image procession software are much too different.

I do not expect identical user interfaces everywhere. Whether there are four checkboxes for the four numeral styles (InDesign) or 2x2 checkboxes (Apple, Sony Vegas Pro) -- both approaches are intelligible. And of course different kinds of applications may support different kinds of features. What bothers me are aspects (1) and (2) as mentioned by Mr Menninga.

What problem?

Hello Nick, offering a checkbox for every single feature may be too much, even a modest font may easily have 20 features minimum. So reducing the choices UI-wise makes sense. And some features need not even be exposed because they should just be on (kern, calt): they are essential part of the design, not options.

Karsten

I only have Indesign CS, so I don't know whether this has been changed in later versions.

I don't understand why there is a separate fly-out for open type features, separate from other character formatting. What does the user care how the features are accessed? Doesn't it make more sense to have all character formatting in one window? Is there something I'm missing here?

Filip: Very cool!

Karsten: Adobe has published this information for some years now, in the table at the end of our OpenType User Guide.

Regards,

T

So reducing the choices UI-wise makes sense.

No, because the UI is suggesting a list of features which is, in relation to any given font, arbitrary.

Here is how the features should be shown, as they appear in FontLab's Preview panel: only the features that are in the font, no more, no less. (This is, I suspect, the way that the next generation of Type Testers at online retailers will work.)

Followed by the way the same font appears in InDesign, with redundancy of [not available] features, and redundancy of faux and OT features.

Doesn't it make more sense to let type founders decide how to "reduce the choices" (if they consider it necessary), rather than have the application present the user with a generic list of features, many of which are redundant?

Only a small class of serif faces are likely to have most of the features shown in the menu: Script fonts, for instance, might have swash and contextual alts, but not tabular figures, small caps, and subscript. Sans serifs are the other way round.

K.L. So reducing the choices UI-wise makes sense.
N.S. No, because the UI is suggesting a list of features which is, in relation to any given font, arbitrary.

Therefore my request to OT spec authors, please add some (formal) information or recommendations about bundling features into UI options -- to remove this arbitrariness.  :)

I know the table in the OT Guide and appreciate it. So, some links:
•  OT features in Adobe applications (p.14), bundled
•  OT features in WPF, bundling up to app developer
(Will there be a similar table for MacOS 10.5?)

Thanks for the links Karsten.

These documents are useful, especially for highlighting inconsistencies.

One thing that struck me about the WPF document is the way that some of the typographic features are renamed in the code.
For instance, fractions are designated either "slashed" or "stacked", which makes perfect sense -- but does not correspond to the Feature Tags "frac" and "afrc" -- which is described elsewhere in the MS Feature Tag web page as "nut", with no mention of stacking.

Similarly, the WPF document is correct in describing three of the four figure attributes -- "proportional", "oldstyle", and "tabular", in accordance with feature tag and application practice, but opts for "normal" instead of "lining" in the code, and refers to this as "standard" in the accompanying text.

This kind of inconsistent naming is intended to be helpful, but in fact drives users up the wall as they attempt to understand concepts and principles in a wider context, by comparing their knowledge and experience in one area with that in another.

It seems to me that the immutable part of all this is the feature tags. Perhaps these features are not all perfectly conceived and named, but rightly or wrongly we have to live with them, and turn their hard-and-fast nature to our advantage. These feature tags have a four-letter code name, and a "friendly name" -- clearly spelled out at the OpenType Layout tag registry.

Why don't application developers follow the lead and use the code names in code, and the friendly names in their explanatory text and menus?

I strongly disagree with Nick's statement that features not present in the currently selected font should be made completely unavailable. We certainly considered that in the Adobe UI, and rejected it due to numerous problems:

- what would the app display for OpenType features when the current text selection has multiple fonts?

- as a user, I want to be able to select a block of text, turn on a bunch of features (which may not all be supported by a given typeface), and then cycle through a bunch of fonts. Nick's approach makes this difficult, and perhaps impossible.

- in creating character and paragraph styles, I need to be able to select features regardless of what is supported by any given font.

Cheers,

T

For instance, fractions are designated either “slashed” or “stacked”, which makes perfect sense — but does not correspond to the Feature Tags “frac” and “afrc” — which is described elsewhere in the MS Feature Tag web page as “nut”, with no mention of stacking.

When choosing names for WPF typography properties we asked people around how many of them know what "nut" fraction is. You can guess the result. Even if description in OT spec uses different word than WPF feature, interpretation is the same and not confusing. They should not be exactly the same.

Similarly, the WPF document is correct in describing three of the four figure attributes — “proportional”, “oldstyle”, and “tabular”, in accordance with feature tag and application practice, but opts for “normal” instead of “lining” in the code, and refers to this as “standard” in the accompanying text.

I agree in this case, "Default" looks better for me too. This value indicates that glyph forms will be default for this font. I do not remember exactly, but I think word "Normal" had been choosen to keep it consistent between different properties. They may have different names best describing default state, but developers should be able to quickly understand how to set property to "undefined" state.

Why don’t application developers follow the lead and use the code names in code, and the friendly names in their explanatory text and menus?

If you design a platform API, you still need to have descriptive names, because you have a user -- developer. Simple feature tags are not descriptive enough. WPF also tried to define some structured set of properties, grouping and naming features so application developer can't make errors like applying features proportional and tabular digits together.

Out of three things Eric called out, WPF definitely addresses (1) and (3), because this would protect developer from making logical error. Representing typographic features in UI is completely different topic. We leave (2) to application, because assumption may or may not be true. For example, InDesign applies historical and discretionary ligatures together under one name, but other app may do it differently. App may use only first stylistic alternate or allow picking from the set. App designer may deside to organize, group or enable/disable them differently, based on his own understanding and target audience.

Thanks,
Sergey

P.S. Looking at Sony Vegas 8.0 system requirements (they include WPF) makes me wonder if it is actually using WPF to support OpenType features. Unfortunately, I can't find any information to confirm that.

I strongly disagree with Nick’s statement that features not present in the currently selected font should be made completely unavailable.

To make a feature available, one applies it to a font which supports that feature.
Do people apply features to fonts that don't have them?
What is the point of applying "all small caps" or "proportional oldstyle" to a "Standard" font?

what would the app display for OpenType features when the current text selection has multiple fonts?

No different than now.
All features applied only to some fonts in some part of the text would be shown, but with a "dash" indicating that they are not globally applied.

- as a user, I want to be able to..."

Is that statement the result of surveys that Adobe has made of how people work with OpenType in InDesign etc.?

Nick’s approach makes this difficult, and perhaps impossible.

My proposal wouldn't stop anyone cycling through fonts.
You're assuming that a typographer would start with text in, say, Times Roman, and apply features to that text that are not supported by TR, then try out some fonts to see which look good and support the features.
Surely, if a typographer wants to apply a feature, and the font selected does not support that feature, they change the font -- they want to see what the feature looks like applied.

I'm suggesting that the display of features should be font- and document-driven, not application-driven:

- If a feature is applied in selected text, it should show up in the feature menu.
- If a feature is available in a font that is selected, it should show up in the feature menu.
- If a feature is applied in selected text, but not available in the font selected, it should be indicated by brackets (as it is now) or by being greyed out.
- If it is applied only in some of the selected text, it should be indicated by a dash (as it is now).

in creating character and paragraph styles, I need to be able to select features regardless of what is supported by any given font.

Again, I'm not going to select a font that does not support the feature I want. If I want superior figures and I have a Standard font selected, I will change the font, not apply the feature in "bracket" mode.

I want to see immediately, clearly, and not on a buried menu, what OpenType features are present in the font of my selection, not be presented with a bewildering mixture of real and faux options, repeated options, and options in brackets.

And, on the other hand, if the text I'm working with already has features applied, and I'm considering changing the font, I again don't want to have the GUI cluttered up with options that aren't applied in the text, and aren't available in the font selected.

This is not so simple. If you are expert typographer working in InDesign and control everything around your text, you may be right.

If you are kind of MS Word user and type text in several languages, your font will change automatically with the language.

If you are in the browser, you may not even know whehter font you want is present on client system. Or you just say font is "script", not speciying particular one. Still, you expect browser to display smallcaps.

Everything depends on particular use and so UI may be designed and behave differently.

Sergey

Interesting, Nick. So once you've switched to a font that no longer supports a feature, that also means you can't turn it off on that text, right?

Cheers,

T

Wrong.

I said:
"- If a feature is applied in selected text, but not available in the font selected, it should be indicated by brackets (as it is now) or by being greyed out."

It could still be turned off, which is how things work now for features not supported by the selected font.

Rather than have an arbitrary list of features in the application menu, the OpenType menu items that appear should be the result of text- and font-specific prompts:
(a) features that have been applied in selected text
(b) features that are available in the active font

Surely this is a better method for an OpenType GUI, avoiding a list of options that is otherwise full of redundancies, and yet can never accomodate every feature.

It would also put the onus on foundries to configure their features in such a manner to work efficiently (ie reasonably succinctly) in the menus, and this would encourage us to cut down on bloated lists of features that users may find offputting. For instance, there is little point in including "denominator" and "numerator" if you have a fraction feature.

Here's a proposal for how a Feature Menu could work:

1. This is the Feature Menu that would appear for a font with no OpenType features:

2. This is the Feature Menu that would appear when an OpenType font with many features is selected:

3. This is the Feature Menu that would appear for an OpenType font with just one feature, for instance a "handwriting" script:

4. This is the Feature Menu that would appear when text with applied features is selected, and the "handwriting" script is applied. Proportional oldstyle figures are applied throughout, and all small caps in parts:

Does this make any sense at all, or should I just mind my own business and stick to type design? :-)

should I just mind my own business?

The silence is deafening.

Nick, I like your table much better than the existing two in InDesign. I don't know about the technical problems.

I suspect that the current way of having the open type stuff as a fly out window impedes acceptance and use of open type.

The silence is deafening.

Still thinking about it. (Currently I prefer greying out -- or bracketing -- non-available features rather than not showing them, for the reason Thomas gave: you may want to select a feature even though the currently selected font does not support it. Also, if you'd really de-bundle features, the list would get a bit longer.) You remind me of a feature request I did two years ago.  :)

if you’d really de-bundle features,

That's not really necessary--note that I show "all small caps" (smcp + c2sc)--and there's no reason to show features such as "local".

you may want to select a feature even though the currently selected font does not support it.

I don't believe people generally work that way, but a sub-menu would cover the possibility.
And with the Feature Menu always on display--as it should be--such a sub menu would still be at a higher level than the present OpenType menu.

The thing is, there are so many OpenType features, it's a bit much to have them all on display in the OT menu all the time.
To the 17 in the "loaded font" menu I showed above may be added 13 more: Petite caps, Alternative fractions, Historical forms, Historical ligatures, Slashed zero, Contextual Swash, Unicase, Ornaments, Stylistic Sets, Stylistic Alternates, Random (and perhaps Numerator and Denominator, although with "Fraction" these are redundant)--for a total of 30 items.

With further bits over here:
http://typophile.com/node/37122
(additions of 2.Nov.2007)

In light of this
http://ilovetypography.com/2014/10/25/why-a-better-opentype-user-interfa...
it seems time to revive this thread...

hhp