Are there any OpenType features that are required to be user-modifiable?

Florian Pircher

Spin-off of typedrawers.com/discussion/4334/applications-without-opentype-feature-support:

If I understand correctly, there are two types of features in OpenType:

• Some features are designed to be controlled by the software using the font (e.g. init/medi/fina, rlig, locl, mkmk, …).
• Some features are designed to be controlled by the font user. These features may be designed to be active by default (liga, calt, …) or only at the user’s discretion (dlig, ss01, onum, …).

Some features may apply to both categories (e.g. tnum both getting enabled automatically by an app inside a table context or getting enabled manually at the user’s discretion).

Are there features designed to be controlled by the user, but where the typesetting software is “broken” if it does not offer the user control over the feature? “Broken” in the sense that normal body copy cannot be typeset without having control over the feature. For example, an app is “broken” if it does not support init/medi/fina since some languages require those features to be readable. But those three are software-controlled features. Is there something similar for user-controlled features? Tabular figures or a slashed zero is nice sometimes, but if those features are not controllable by the user, I would not consider the app “broken”.

John Hudson

I categorise OTL features three ways (see Enabling Typography [PDF]):

1,0 = on by default and cannot be disabled by users (required features)

0,1 = off by default but can be turned on by users (discretionary or conditional features)

1,1 = on by default but can be turned off by users (standard or typical features)

The concept of ‘broken’ is hard to define. Your suggested meaning relies on a concept of ‘normal body copy’, which I think is also hard to define, and perhaps not really useful: all texts are specific, and while they may have many things in common any particular text might also rely on things that are important for that text but not for others. Also, since all texts are instantiated, the features can’t be isolated from design: there are typefaces in which being able to turn on or off ligatures might be important, and others that work fine without ligatures. Finally, there is the intersection of the features with language system settings so, for example, in an environment that fails to map document language setting to OTL langsys, being able to turn liga off might be very important indeed.

Florian Pircher

I agree with all of the above. My question about “broken” software regarding “normal body copy” arose from thinking about what the minimal set of controls would be that an app needs to expose to not only be Unicode savvy but also OpenType savvy.

John Hudson said:

Your suggested meaning relies on a concept of ‘normal body copy’, which I think is also hard to define, and perhaps not really useful: all texts are specific, and while they may have many things in common any particular text might also rely on things that are important for that text but not for others.

Yes, a difficult – if not impossible – definition. There will always be texts demanding all the capabilities of OpenType and beyond. I mostly thought about common contemporary texts. Business correspondence, text messages, posts on the web, etc. Is there a group that cannot express themselves in their native written language on TypeDrawers because the text editor does not offer feature selection?

Nick Shinn

When a font supports <all small caps> by mapping both capital and lower case to the same lower case glyph, then text set in Acrobat will be broken, losing its capitalization.

Thomas Phinney

> When a font supports <all small caps> by mapping both capital and lower case to the same lower case glyph

Unless I am confused and have forgotten, the font does not need to do that, to support this Adobe UI feature. Just doing normal smcp and c2sc is sufficient.

Adam Jagosz

What is <all small caps> meant to mean, other than smcp and c2sc? I think Nick means reusing smcp glyphs for c2sc, e.g. sub A by a.sc.

RichardW

One such group would be the those numerically inclined, who can't express arbitrary vulgar fractions - fraction slash doesn't act on neighbouring digits.

John Hudson

fraction slash doesn't act on neighbouring digits

Depends on environment: HarfBuzz implements numr and dnom features intelligently based on the presence of U+2044.

Thomas Phinney

@Adam Jagosz you are almost certainly right, Nick means using the same destination glyphs for both features. Apologies to Nick for me being dense about what he was trying to say.

Adobe’s workaround back in the day was to have TWO sets of small cap glyphs, one for each source (caps vs lower-case). This solves the problem, but at a cost.

BUT, note that “the problem” generally only occurs when the PDF is generated after-the-fact from a PostScript stream. That is, any app that directly generates PDF from a source document is perfectly capable of associating the right underlying text with the glyphs, using the PDF /actualtext (I think it is called) mechanism. This has been around for an awfully long time now. 

So, the problem is rarely seen.

Nick Shinn

<calt> is disabled by Adobe apps, when tracking exceeds certain values.

Because of its origin as a connected script feature.

This is really annoying for “pseudo random” effects, which one would think should be implemented with this feature, but the effect ceases to work when spaced out.

Therefore, I have put this effect in <rlig>, which is a required feature.
Not perfect, as it means that users can’t tweak their typography “manually”.

Ray Larabie

@Nick Shinn That's an clever idea. I've had customers complain about shuffle effects breaking with tracking in Adobe apps. Do you think it would be wise to double-up with a lookup? That way apps that support calt but not rlig would still work.

feature rlig {
lookup shuffle {
#shuffle code#
} shuffle;
} rlig;

feature calt {
lookup shuffle;
} calt;