the OpenType features UI questionnaire /Q2
peter sikking
Posts: 24
OK, following up on question 1, here is the next one.
The purpose is to make a (long and winding) list of the lack of support for discretionary OT features in software. Some examples of what your contributions can be:
Looking forward to a long list here, —ps
The purpose is to make a (long and winding) list of the lack of support for discretionary OT features in software. Some examples of what your contributions can be:
- software XYZ does not support discretionary OT features at all.
- discretionary OT feature ‘ABCD’ is not supported by software XYZ.
- software XYZ supports some discretionary OT features, but my customers cannot find it/keep forgetting it/refuse to use it—all the time.
Looking forward to a long list here, —ps
Tagged:
0
Comments
-
Not meaning to discourage your drive here, Peter, just as a note on research methodology; does this list need to start from scratch, and are you sure a thread on a forum is the best form? Asking people to type up anew all the issues they’ve ever encountered with OT feature support in any app seems like a big ask, and it also seems to me that a lot of this information is already out there — searching these forums alone for “OpenType support” already seems to turn up a bunch of pointers, which might at least serve as a starting point. Thinking it might be worth digging around in the archives and collating what was found [with date references, since these things change] in an external doc that people could then add to (which could also afford to be more structured than a post here, eg. as a Googledoc/spreadsheet)?7
-
Some foundries and/or vendors have tables listing what features are supported by popular apps (including versions).0
-
@Nina Stössinger: thanks for asking the tough questions. makes me think and further understand the dynamics of the issue.
just to be sure: the aim is not to arrive at some sort of ramp-down list of what needs to be addressed. what needs to be done is very clear, and a tidy work package:
design how all the discretionary OT features are going to work desktop, tablet and mobile; then work with the 3 main OS vendors (apple, ms, google) to realise them on their OSs. then discretionary OT features will be a standard that works in all rich-text applications—say, 1000 apps per platform, makes ~9000 apps.
this question here is to burst the bubble of a couple of excuses that I hear being made, in order to not have to think about rolling out discretionary OT features UI:- “it is just about one–two dozen popular apps, just sort them out.”
- “with a bit of knowledge what works in which app, font designers can work around the holes.”
a very large type publisher in berlin makes a custom font family for a customer. customer wishes are packed in discretionary OT features. customer complains after delivery, saying ‘this is not working’; in their business they use a report generator and it has zero discretionary OT features UI. so the type publisher had to unpack all the discretionary OT features and roll them into separate fonts.
this report from the type-business trench is an eye-opener for me:- the problem is not the popular apps, it’s ~9000 apps;
- it is not only about editing rich text, it is also about generating rich text;
- that must have cost the type publisher both extra project effort and customer goodwill;
- discretionary OT features failed as a standard, there and then.
thus, let me rephrase this second question of the survey:
Has the current state of discretionary OT features impacted your business negatively? for instance:- a project fell through;
- customer support costs;
- strife with customers;
- extra design/engineering work.
- software XYZ does not support discretionary OT features at all;
- software XYZ supports some discretionary OT features, but my customers cannot find it/keep forgetting it/refuse to use it—all the time;
- discretionary OT feature ‘ABCD’ is not supported by software XYZ.
1 -
This hasn’t been a problem for me.
Rather, the economic issue here is stifled potential, concerning all OpenType features.
Relating to the poor quality of OT support, not merely the lack of it.
I’ve put in the work of loading fonts with features, and yet these are several clicks away from the main interface, and inconsistently accessible across different apps, even within the Adobe Creative Suite. So they are simply not part of a user-friendly experience.
As my fonts are necessarily priced according to their features, I feel like I am pricing my whiz-bang fonts out of the market, charging for things which won’t be used; the alternative is to give the features away at no extra charge, as most people are just not familiar with using them, and thus don’t appreciate the value.1 -
@Nick Shinn: thank you for contributing.
I would summarise that as: cannot charge for the full user value of discretionary OT features, because a good portion of them won’t get used.
(a very familiar and uncontroversial theme in interaction design; if its UI is not good, then the feature does not exist for most users.)
now, we need both more examples of different negative impact on your business and we need some weight behind the one Nick contributed. the latter is fast and easy: just write something like ‘ditto, cannot charge for the full user value’ and you’re done.
0 -
I have some fonts that are geared to elementary school educators. Over the years I've incorporated requests for alternate characters: I and J with and without a serif, q with a curl etc. I originally put these alternates in the positions of uncommonly used (in elementary school) maths characters. I included a lookup chart and all was well. In subsequent updates of these fonts, I moved the characters out of their improper locations and turned them into unencoded discretionary ligatures. I must have had almost as many support requests as font sales. Even if a customer understood that only certain applications supported discretionary ligatures, they often needed to use Word to collaborate with other teachers. I ended up making custom fonts for several customers.
A common customer support issue is when Adobe applications of the same version didn't support the same features. Like Photoshop CS6 and Illustrator CS6. So I'd often end up making a custom font for the customer just to make it work between apps. I never charged anyone for that type of modification because the customer just wants the font they purchased (or got for free) to work. I got a lot of those requests over the years and some of them ended up getting pretty time consuming...like backtracking an older version of a font to do modifications. Digging through a box of hard drives. Bleah. That's one of the reasons I've been gradually killing off discretionary ligatures in my older fonts. It's a financial burden...not worth the couple of extra sales I might have made.4 -
@Ray Larabie: thanks for sharing that. gets the pain across for trying to work with a standard that is not a standard.0
-
This reminds me of developing my Black Monday font. Black Monday was one of the first fonts to cycle through multiple versions of each glyph using contextual alternates. When Silas Dilworth was doing production he realized that many apps either didn’t support contextual alternates or didn’t make it east to enable the feature. He ended up writing a script to generate a 1,538 line LIGA feature to do the glyph swaps because LIGA is widely supported and is usually on by default. It worked, but was an ugly hack; writing code to generate 1538 lines of code to do what should have worked with 8 lines of code.
And I never use stylistic sets for anything because I’ve never met a type user who who understands them. I can’t prove it, but I think this is probably because of the horrible early decision made to represent them with numbers instead of just displaying names. I know that stylistic sets can hypothetically have names now, but few apps will display the names, so it still seems pointless.2 -
I was really disappointed when MyFonts stopped showing the Contextual Alternates feature in its type tester.
MyFonts is my main distributor, and I had invested a lot of time in developing typefaces which exploited that feature.
Not a Discretionary feature, but a similar issue.3 -
Not a Discretionary feature, but a similar issue.
<calt> is discretionary in the sense that matters to Peter, in that it should have UI access in order to turn off the contextual alternates. This is how the feature was registered (what I classify as a 1/1 feature: on by default, but can be turned off).
Now, it's worth noting that a lot of fonts use <calt> for substitutions that really should never be turned off, because for a long time it was the only feature available that was explicitly for contextual substitutions. The <rclt> Required Contextual Alternates is relatively new, and I'm not sure where it is supported in terms of Latin and other 'simple' scripts.
_____
BTW, I've thought for a while now that the OpenType Layout model of distinguishing required (1/0), standard (1/1), and discretionary (0/1) substitutions at the feature level isn't ideal. I wonder if it might have been better to have this as a flag at the lookup level, such that we would only need, for example, a single ligature feature, and the individual lookups within the feature would determine which ligatures are always active, which are on by default but can be turned off, and which are off by default but can be turned on. This would have provided a flexible model in which any GSUB feature could have lookups in any or all of the three states.
Of course, it shouldn't need saying that such a model would have changed the nature of the choices facing user interface designers; indeed, it would have changed what we mean by supporting OTL features.
3 -
Good point John, about <calt> being discretionary.
I will revise my response to Peter’s Q1.
Since I recently discovered <rlig>, I have been using this instead of <calt> for pseudo-randomization and similar effects, because it does not “fail” when tracking is applied.
And it really is non-discretionary!
0 -
ding dong; your input is needed.
only an emphatic flood of contributions in this thread can convey the urgency of this topic—which is eluding the type rendering world at the moment.0 -
When I started adding OT features in the mid-2000s, there were some popular apps, like MS Office and Flash, with poor or nonexistent OT support. So I made "supplemental" fonts where certain discretionary features, like small caps and alternate characters, were the defaults. For example, if your app didn't support the small caps feature, you could choose the supplemental font from the font menu instead.
I made the decision to include these supplemental fonts at no extra cost with the standard version. But it resulted in some confusion both for the customers (who, for example, often don't realize they can get alternate characters with the normal fonts), and for my distributors (who sometimes try to sell the supplemental fonts separately or are not set up to include them). It also meant extra work for me to create the extra fonts, especially at first when I was making them mostly manually. I have scripts now that create the fonts automatically, but it takes time to write and configure the scripts, and to manage distribution of them alongside the standard fonts.
Because support for OT has improved, I've somewhat reluctantly stopped doing this on my more recent releases. I say reluctantly because I know that many users will never discover the discretionary features I've included. At least the supplemental fonts made it obvious that these things existed in the typeface. I would love to drop the supplementary fonts from my older fonts, but my sense is that many users are used to having them. If support for discretionary features were more visible and standardized, I would be a lot happier about dropping this "hack" for good.
2 -
On the subject of supplemental fonts containing OTL discretionary variants as default forms — something that I've resisted making, on the grounds that I shouldn't have to bend over backwards to provide workarounds to poor support of technologies by the people who invented the technologies, harrumph —, I have found online unauthorised derivative fonts made in this way. So lack of good and consistent support for OTL discretionary features also leads to the proliferation of unauthorised derivative fonts and the breaking of license agreements.7
-
I also regularly get requests for custom versions of my fonts with discretionary features enabled (as with the supplementary fonts). Because of the scripts I use, it's not a lot of work to make them, but it shouldn't be necessary in the first place. Plus it amounts to busy work and a distraction from working on more worthwhile stuff.0
-
Nick Shinn said:I was really disappointed when MyFonts stopped showing the Contextual Alternates feature in its type tester.
MyFonts is my main distributor, and I had invested a lot of time in developing typefaces which exploited that feature.1 -
Nick Shinn said:I was really disappointed when MyFonts stopped showing the Contextual Alternates feature in its type tester.2
Categories
- All Categories
- 40 Introductions
- 3.7K Typeface Design
- 793 Font Technology
- 1K Technique and Theory
- 609 Type Business
- 443 Type Design Critiques
- 535 Type Design Software
- 30 Punchcutting
- 135 Lettering and Calligraphy
- 82 Technique and Theory
- 53 Lettering Critiques
- 478 Typography
- 300 History of Typography
- 113 Education
- 65 Resources
- 492 Announcements
- 78 Events
- 105 Job Postings
- 148 Type Releases
- 160 Miscellaneous News
- 269 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports