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”.
Comments
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.
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?
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.
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.
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”.
feature rlig {
lookup shuffle {
#shuffle code#
} shuffle;
} rlig;
feature calt {
lookup shuffle;
} calt;