hey y’all,
some of you here know me, from being involved with OpenType features UI for a while now. I have some questions for you that are sort of make or break in getting OpenType features UI available everywhere where rich text is being edited. This questionnaire is meant to build the case why really time and budget should be allocated towards this goal.
I am simply going to take this one question at the time, each in their own thread.
Question 1, for font publishers (no matter whether you designed/engineered these all by yourself, employ a team doing that and/or commission them):
Can you give me an estimate of how much you have invested in discretionary OpenType features? (say, in absolute time/money, or in % of project time/budget—and don’t forget support time/budget.)
Yes, we are only interested in discretionary Opentype features, i.e. the ones that do not work ‘automatically’ and need user intervention to be turned on.
Note that this discussion is in the ‘Type Business’ category. That is no coincidence; the only arguments that will convince to (finally) introduce universal OpenType features UI are business arguments. That’s just how the world turns. Please answer here within that context.
Font publishers, I encourage you to answer here, so that we can build some momentum here.
thanks, —ps
3
Comments
Because the UI support has been so spotty, I have been reluctantly leaning toward using discretionary features less now than I used to. If UIs supported discretionary features better, it would be more worthwhile to take the time to do them.
In total, I would say the extra work accounts for 10% of production time.
But it certainly feels like more, scaling and spacing bold italic figures for arbitrary fractions!
A full set of smallcaps — corresponding to the uppercase character coverage — has been included in all our text families for major European scripts (Latin, Greek, Cyrillic) since the 1990s. Superscript set is sometimes limited to a–z and 0–9, but often also include A–Z. Subscript is often limited to 0–9. Font families for specialist publishers, such as the Brill types, may include much larger super– and subscript glyph coverage, including full upper– and lowercase Greek alphabetics, some accented letters, and mathematical operators and punctuation. [If you're wanting to make a business case for OTL UI support, you should definitely get input from publishers, especially academic publishers, who tend to deal with challenging texts and rely heavily on typography to aid navigation, establish hierarchy, etc..]
In recent years, we've also begun to provide more discretionary feature glyph variants for non-European script fonts, again in response to requests from publishers: notably superscript numerals and alternate stylistic forms of conjuncts and punctuation signs for Indic scripts. We've also made discretionary swash forms of Arabic letters.
That's mostly in the context of typefaces for running text. I've made exactly one display typeface in the past twenty years, and of its 4,516 glyphs I reckon 3,043 (approx. 67%) are dependent on discretionary layout features. That's the Gabriola font, and it's the primary reason why MS Office supports Stylistic Set features — however imperfectly — in Publisher and Word.
And therein lies an irony. The companies that you are presumably hoping will step up to invest in OTL UI are the companies that, for twenty years, have been on the one hand paying me to include discretionary feature support in the fonts I make for them and, on the other hand, failing in various ways to support those same features.
Certainly, the number of fonts already supporting the features matters, especially when further considered by the popularity of those fonts. Knowing that there are many widely-used fonts that have features that are inaccessible in the apps, that is an argument for putting the features in the apps. “Empower your users with functionality they are missing!”
Better still, survey a bunch of users, then educate them, then survey the same users again: that could show how many ask for the features before they are prompted, and then see how many want them once they know what they are missing.
this is not a question of convincing apps. on any computing platform (desktop, mobile, tablet × vendors) there will be 1000 (or 1000s of) apps where rich text can be edited/generated. of these apps, maybe one/two dozen (per platform) can be convinced that top-notch typography is their mission and they can be bothered to spend person-months analysing/designing/implementing OpenType features UI. the rest: no chance.
All apps can be convinced in a jiffy when the OpenType features UI is offered as a standard component by the UI libraries of the OS they are running on (just like the Print dialog is, or the font selection UI). two days of work to integrate it? OK. zero days (appears automagically on the next version of the OS): super.
(if some of the top-notch-typography apps have their own ideas about super-duper OpenType features UI: fine. but when all the other apps have complete and usable OpenType features UI as standard, then there is no more room for incomplete and unusable solutions.)
through business eyes, the OpenType standard is a pact between font publishers and font renderers. for discretionary OpenType features, that pact is failing because of the last ‘local loop’ in the delivery: the UI for it is missing in 99% of rich-text apps, and where it has been included it is incomplete and—signals the user community—unusable.
if the font publisher and font renderer companies can be convinced that they have substantial investment in discretionary OpenType features that is all for nought, then they may be convinced to chip in to make a reference implementation a reality on all computing platforms.
I have to thank Si Daniels for coining exactly what is needed here:
“an open, standardized reference UI for font features”
that is the right thinking in this case.
so font publishers, small and large, keep the stories coming about how much you have invested in discretionary OpenType features; we want to gather overwhelming evidence here in this thread.
thanks! —ps
Ah. It was not clear to me from your initial post (and discussion in the thread) that this is what you were up to. So, you want to convince the same people who make the fonts to contribute, separately, to a reference UI implementation?
I think that is a fine thing, of course, and commented a fair bit in the previous thread.
But I think that we all already know that there are plenty of fonts, and so do the OS vendors. Further, the people who make those fonts are aware of how much time and energy they put in, and they don't need massive convincing.
I think most people in the biz already agree that "this (vague thing) should happen"; what is missing is process/structure and people driving it, for making that thing happen. Spell out the steps and get that ball rolling.
If you include variable font UI in the same push you might get considerably more positive attention. After all, virtually all the big players and many small and mid-size ones are currently involved in that effort and are spending considerable resources on it. If this was an incremental part of that, you would probably find it easier to get help and people involved.
All that said, I suspect you underestimate the time to implement it.
In the other thread, there were some suggestions for how to get this going, organizationally, and how to promote it. Typo Labs, anyone?
so I thought the best thing was to collect some overwhelming evidence—here.
I was encouraged by my visit to the Berlin typostammtisch last thursday. I talked to a few font designers and engineers, and all of them have horror stories of how it is not working. would be good to get them out in the open here.
last year at TYPO labs I came there with the ‘process/structure and people driving it, for making that thing happen’ pitch to the right people. it is clear that they were not ready to listen to process & structure. in typical infrastructure fashion, everyone sees a hairy, mind-blowing problem and is waiting for someone else to fix this.
Since I am experienced in infrastructure UI design, I am not underestimating how long this process takes. the design process is the hard part, because there the complex system has to be made simple and predictable. once the UI is specified the implementation of it is a lot more straightforward—which is exactly the key to getting it done.
I would be very happy to also design vari-font reference UI. I do not see so much overlap/synergy with the discretionary OpenType features so it makes the design project simply longer. not twice as long, because vari-fonts is not as complex as OT features.
Perhaps the Variable Fonts work will not be as complex from a “design the user interface” perspective. From either an infrastructure or app-implementation perspective, I suspect it will be more work, not less.
T
Because, apart from demand-side factors, your argument appears to turn on whether, if OT support were provided, there would be sufficient supply of fonts to justify it.
Hell yeah!
My foundry has ten families on the market with at least both “small caps and alternate figures”.
IMO, you can’t really publish a serif design for body text without those features.
In certain genres, discretionary features are de rigueur, and whether or not typographers end up using them, we put that stuff in there, like minority language characters and math symbols, because it’s part of doing the job right.
And again, even if a licence purchaser doesn’t end up using all the weights in a family, or all the languages, or all the features, this latency (observed in marketing and specimens) may well provide an important perception of value.
Have you checked the best-seller lists at MyFonts and FontSpring to see which of the typefaces listed there have Discretionary features? I believe that information is provided on those distributors’ sites.
today I looked at the programme of TYPO labs (I’ll be there) and yeah, vari-fonts is BIG. if that work can get easily funded, let’s start there. another synergy is that the route to get vari-fonts UI out there is the same as for OT features: through the font-related OS UI libraries. one works with the same people the whole way through.
there is simply a ton of fonts out there with discretionary OT features.
where it gets interesting is how much time//money was sunk in the discretionary OTf part of those fonts.
so in the case of your 20 families, how many people-hours is that?
But I would just say, for every family with discretionary OT features (thousands of them), assume it took at the very least 20 hours and often +100. All our fonts have them. I've already spent weeks on stylistic sets.
paraphrasing: “man, I/we spent already so much on discretionary OT features!”
backed up with some ballpark numbers—because the people who will take decisions on this are used to doing that while looking at a spreadsheet.
now, we simply need more postings here. it basically has to become a petition, of many type publishers saying the same thing again and again—and backed up by their reputation in type design/publishing.
meanwhile, I will pose a second question in a new thread.
For what it's worth, I would say that most of the time on discretionary features is designing, drawing, and spacing the glyphs needed to support the feature, not in writing the feature code (which can often be trivial or even automatic to build).
So, if you look at a font and 10% of the glyphs in the font are related to discretionary features, then roughly 10% of the time designing and building the font went into discretionary features. If it was 66% of the glyphs (and I have a font family like this), then it was probably close to 66% of the time and effort.
This sort of rough calculation I'm sure depends a lot on the design, but it seems like a reasonable way to estimate it.
here is a corker: a font engineer who used to work on a really large font library, ran a script over that library and found out that ~50% of the glyphs were tied to discretionary OT features.
now that equals ~50% of the time and effort…
rephrasing that: there is an untapped user value potential for ~50% of the library, that could be unleashed (and charged for) by making discretionary OT features a working standard—instead of a not-dead-but-resting one.
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.
I have been on both sides, specifying rich featured type for basic user stuff such as Powerpoint presentations only to be limited by the lack of these features in those softwares.
This has easily been a source of frustration in branding and typeface projects alike.