the OpenType features UI questionnaire /Q2

peter sikking
peter sikking Posts: 24
in Type Business
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:
  • 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.
If you can back up your contribution with an anecdote of how this has impacted your business negatively—e.g. a project fell through, customer support costs, strife with customers, extra work to split out discretionary OT features -> separate fonts—then that will really increases the impact by a factor of 10.

Looking forward to a long list here, —ps
Tagged:

Comments

  • Mark Simonson
    Mark Simonson Posts: 1,734
    Some foundries and/or vendors have tables listing what features are supported by popular apps (including versions).
  • peter sikking
    peter sikking Posts: 24
    edited March 2017
    @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.”
    I am looking for reports from the type-business trenches, pain and costs that are not in compatibility tables. like the following story that I heard first-hand:

    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.
    now one report generator for one customer is going to be shrugged away by those who make excuses for the current status quo. so we need overwhelming evidence of this.


    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.
    Please also tell us what doused this. for instance:
    • 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.
    Looking forward to a long list here, —ps
  • Nick Shinn
    Nick Shinn Posts: 2,207
    edited March 2017
    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. 
  • peter sikking
    peter sikking Posts: 24
    @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.
  • Ray Larabie
    Ray Larabie Posts: 1,431
    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.
  • peter sikking
    peter sikking Posts: 24
    @Ray Larabie: thanks for sharing that. gets the pain across for trying to work with a standard that is not a standard.
  • James Puckett
    James Puckett Posts: 1,993
    edited March 2017
    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.
  • Nick Shinn
    Nick Shinn Posts: 2,207
    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. 
  • John Hudson
    John Hudson Posts: 3,186
    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.
  • Nick Shinn
    Nick Shinn Posts: 2,207
    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!
  • peter sikking
    peter sikking Posts: 24
    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.
  • Mark Simonson
    Mark Simonson Posts: 1,734
    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.

  • Mark Simonson
    Mark Simonson Posts: 1,734
    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.
  • Michael Rafailyk
    Michael Rafailyk Posts: 146
    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.
    Just noticed it now after releasing a family entirely based on Contextual Alternates. Cannot express how unpleasantly surprised I am  :#
  • Michael Rafailyk
    Michael Rafailyk Posts: 146
    Nick Shinn said:
    I was really disappointed when MyFonts stopped showing the Contextual Alternates feature in its type tester.
    Some good news – they brought back the Contextual Alternates on the preview with the latest backend update.

Categories