Are there any OpenType features that are required to be user-modifiable?
Florian Pircher
Posts: 176
Spin-off of typedrawers.com/discussion/4334/applications-without-opentype-feature-support:
If I understand correctly, there are two types of features in OpenType:
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”.
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, …).
Tagged:
0
Comments
-
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.
1 -
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.0
-
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.
0 -
> 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.0 -
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.
2 -
One such group would be the those numerically inclined, who can't express arbitrary vulgar fractions - fraction slash doesn't act on neighbouring digits.
0 -
fraction slash doesn't act on neighbouring digitsDepends on environment: HarfBuzz implements numr and dnom features intelligently based on the presence of U+2044.
1 -
@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.0 -
<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”.1 -
@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;1
Categories
- All Categories
- 40 Introductions
- 3.7K Typeface Design
- 795 Font Technology
- 1K Technique and Theory
- 614 Type Business
- 444 Type Design Critiques
- 539 Type Design Software
- 30 Punchcutting
- 136 Lettering and Calligraphy
- 83 Technique and Theory
- 53 Lettering Critiques
- 482 Typography
- 301 History of Typography
- 114 Education
- 67 Resources
- 495 Announcements
- 79 Events
- 105 Job Postings
- 148 Type Releases
- 162 Miscellaneous News
- 269 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports