the OpenType features UI questionnaire /Q1

peter sikking

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

Mark Simonson

I have included discretionary OpenType features in most of my recent type families. It has never been a matter of whether I was willing to spend the time and effort to add them, rather it was part of the original design concept in cases where I've included them. As a result, it's difficult to say how much project time it added, although it obviously would have taken somewhat less time without them.

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.

Nick Shinn

Of the 10 typeface families I’ve published in the previous five years, three have had small caps, seven have had alternate figures, three have had superior and inferior figures, and two have had stylistic sets.

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!

Vassil Kateliev

Last four I've worked on had all the bells and wishes (+ Cyrillic) - Small caps, five figure styles + sups/subs (+ slashed zeroes on all), extended ligatures, case sensitive forms; one of them was a huge 2000+ glyphs per weight family with swashes, contextual alternates, three stylistic sets and more... I would say that these cost me up to 30% of my production time, but it feels like 90% (some feel especially tedious) 

John Hudson

Smallcaps, super- and subscript, and numeral style/spacing variants are the bulk of discretionary OTL glyph creation work in our European script fonts. Obviously these then also need to be kerned, to each other and to relevant upper– and lowercase glyphs.

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.

Chris Lozos

Peter, are you saying "bottom line" for type producers or for application software developers [Microsoft, Apple, Adobe, etc..] that supports that type? 

Thomas Phinney

I hate to say this, but I do not see at all why the effort of type designers will have any impact on support from apps. Software product managers are much more interested in what their users want, and also in this case what proportion of the fonts their users have support these things. But the effort the type designers put in is really not a business-centered or end-user-centered argument.

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.

peter sikking

@Chris Lozos: sorry, your question is ambiguous. if you quote the snippet from my post you are referring to, I can answer you.

peter sikking

@Thomas Phinney: thanks for asking the tough questions.

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

Ray Larabie

In the mid 2000's I probably didn't put more than 10% of a project into discretionary ligatures. Now it's 0% and I've gone back to most of my older typefaces and stripped those features out. The features are too hard for users to find/notice and app support is spotty. That doesn't include ordinals and fractions...I always include those.

Thomas Phinney

Peter:

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?

peter sikking

well, the whole reason to do this survey is that I was told in discussions that in the places where decisions can be taken to go ahead and do this, there is no good picture of how much is already invested in this and how much value is not reaching the users of those fonts.

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.

Chris Lozos

"...questions for you that are sort of make or break in getting OpenType features UI available everywhere ..."

peter sikking

@Chris Lozos: it is both the type publishing industry and the type rendering industry. between them, they intended OpenType features to work, also those 90 out of 150 that are discretionary and need UI.

Chris Lozos

When type designers make Opentype features that are not supported by the software that uses their type, they get discouraged.  When type users are not aware of how to access a feature, they ignore it and don't demand it.  When the developers of page-makeup and word processing software get no demand by their users to support OT features, they don't bother supporting them--the circle.

Thomas Phinney

peter sikking said:

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.

I agree that there isn't actually that much synergy in the work to be done with Variable Fonts. But VF is something that has attention and mind share and might easily get funded. Dealing with both under a single umbrella would be a strategic move to try to get the general feature UI funded and paid attention to. (Probably not something I should say publicly, oh well.)

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

Nick Shinn

On further reflection, I don’t think the relevant question for foundries is how much time or money they put into producing fonts with discretionary OT features, but how many they have published.

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. 

peter sikking

@Thomas Phinney: today I thought there is at least one synergy between the vari-fonts and OT features: I’ll be dealing a lot with John Hudson. we’ll only have to discuss good coffee once. ;^}

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.

peter sikking

@Nick Shinn: I do not think anybody thinks there is a chicken-and-egg situation here.

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?

Yªssin Bªggªr

I also don't get why the hours are so interesting/relevant… how that would make the case any better than the thousands of fonts with hard to reach features…
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.

peter sikking

@ybaggar: that is the spirit of this question!

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.

Nick Shinn

Peter, sorry, I don’t keep track of the hours, let alone break them down by feature. 

Mark Simonson

Same here.

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.

peter sikking

@Mark Simonson: thank you for that insight.

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…

Thomas Phinney

Sure. Although... that was glyph count in an entire library. The numbers are probably distorted by a few fonts with massive numbers of discretionary goodies. The average % of discretionary glyphs per font will be considerably higher than the median %.

peter sikking

well, the ‘macro-economic’ point for the proprietor of that library is the same: ~50% of the R&D investment is very hard to translate into user value.

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.

peter sikking

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.

Rodrigo Saiani

I have recently designed a custom font family with all features to a major Brazilian brand. Because the support is limited for OT Features in some softwares, it is possible that most applications I'll see from the project will bear just the basic set. If one wants to make sure it's easily accessible, we need to make an alternate font just for the features, and sometimes this requires more work on either end of producers and or users.
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.