Casual-Users and the Font Market: An Interview with Type Designer Laura Worthington

ThomasJockin
ThomasJockin Posts: 26
in Type Business
Hey everyone!

TypeThursday just published an interview with script typeface designer Laura Worthington.
We discussed how she became a typeface designer, the rise of the casual user market and design considerations for this market.

It was a great talk. Well worth your time.
Read it on Medium
Tagged:

Comments

  • Dave Crossland
    Dave Crossland Posts: 1,430
    I'm particularly interested in opinions for and against Laura's use of PUA-encoded alternate glyphs. I think this is a good idea as it provides a simple solution for users of software that doesn't support OpenType adequately (after 15 years...)
  • Nick Shinn
    Nick Shinn Posts: 2,210
    script typeface designer Laura Worthington

    She is well known for her scripts, but her body of work is more diverse than most.
  • Thomas Phinney
    Thomas Phinney Posts: 2,889
    Very few users of those non-savvy apps actually hunt for stuff by Unicode.

    At Adobe, we initially used PUA for all non-standard glyphs (in addition to proper OT features), and then stopped. Pretty much nobody cared.

    Maybe Laura's audience is different? Could be.
  • Mark Simonson
    Mark Simonson Posts: 1,736
    It sounds like she's saying that there is a non-professional font user market consisting of people who can't afford professional graphics apps, and that OT features tend to only be supported in pro apps. Using PUA for alternate glyphs provides a workaround for these people.

    I used to use the  in my early OT fonts, but stopped because Adobe recommended against it. I can see the argument for not doing it (basically, it's a hack, plus unpredictable results when switching fonts). On the other hand, when I stopped doing it, it was because I bought the argument that OT support would improve and there would be no need for such a hack in the future. Except that OT support hasn't improved all that much. (Latest version of Mac OS is an exception, but unfortunately rather hidden away.)

    Aside from the potential issues with switching fonts, it doesn't seem to be such a terrible idea and has some real immediate benefits for users until OT feature support becomes more common beyond pro apps, if ever.

    Anyway, reading Laura's interview makes me wonder if following Adobe's recommendation was really worth it.
  • Jameson R Spires
    Jameson R Spires Posts: 20
    As much of a headache it is, if it's something that is going to improve your ability to meet your customer's needs (one definition of quality), I see very little downside.

    I would suspect MyFonts and other vendors would have some data available to see how many users are using the fonts they purchase for use in MS Office (still very OT-unfriendly as of v2016)?
  • James Puckett
    James Puckett Posts: 1,995
    edited February 2016
    …I see very little downside. 

    The downside is that as long as type designers use hacks to make up for the failings of software developers then said developers have an excuse to keep failing. This opens us to a slippery slope problem. We might end up with the kind of situation Microsoft put web developers into for years, having to use hacks to develop web pages that were standards-compliant and that also worked with Internet Explorer. We might have to start releasing two sets of fonts in every release—one with PUA encodings for the people who use cheap software, and another for people running Adobe software, and the support headaches that entails.
  • John Hudson
    John Hudson Posts: 3,204
    edited February 2016
    I'm particularly interested in opinions for and against Laura's use of PUA-encoded alternate glyphs. I think this is a good idea as it provides a simple solution for users of software that doesn't support OpenType adequately (after 15 years...)

    Using PUA encodings intelligently involves a degree of knowledge on the part of the user that I wouldn't presume for general retail fonts. We use PUA only exceptionally, when our clients are very aware of the issues and have determined that there is no other mechanism that will meet their use needs. Typically such clients are also the sort of people who will be creating their own OTL->PUA and PUA-OTL scripting and workflows; again, not the typical purchaser of a retail font license.

    My view, which I've held for about the same 15 years to which you allude, is that PUA should properly be reserved to purely non-semantic elements such as ornaments, border parts, etc., or to test case and documentation fonts for unencoded scripts.

    Using PUA to access variants of encoded characters, such as swash forms, contextual variants, or ligatures, means that you are corrupting the text even as you are typesetting it. The result may look pretty, but it can't be searched, sorted, indexed, or any of the other things that we should be able to do with digital text. If one is producing only print media, then I suppose the old adage that whatever it takes to get the ink on the page stands, but how often these days are we producing only print media copy? Digital text is text that can be copied, pasted, and exchanged, and tends to find its way into multiple formats. If the text has been corrupted at some stage in order to make it look a particular way, that isn't going to be immediately obvious to the person who cuts and pastes it into an rich text email and sends it off, not realising that it is going to be gibberish to the recipient.

    _____


    Microsoft began supporting OTL stylistic set features, initially in Publisher, because Geraldine Banes and I sat down with people in the Office team and showed them the Gabriola font and the sort of things it could do. To their credit, they devoted resources to add new feature support to a product that was supposed to be in pre-release lockdown, just because they thought the font was so cool. If we'd said '...alternatively the user can use PUA encodings to access all these glyphs', I doubt very much if they would have gone for the OTL option. If one continues to support bad legacy solutions, there's little impetus for software developers to support better new solutions.
  • Jameson R Spires
    Jameson R Spires Posts: 20
    James Puckett said:
    …I see very little downside. 

    The downside is that as long as type designers use hacks to make up for the failings of software developers then said developers have an excuse to keep failing. 
    That is not the fault of this subset of customers.

    I do not think anyone is suggesting that Microsoft should continue their poor OT support.
  • Mark Simonson
    Mark Simonson Posts: 1,736
    I can see how PUA hacks don't help in getting better OT support, but avoiding them hasn't been much more effective. I don't think any of this will improve until developers take the lead, focus groups be damned. Until that happens, it's all just pushing a rope up a hill.

    Ugh.
  • James Puckett
    James Puckett Posts: 1,995
    That is not the fault of this subset of customers.

    No, it isn’t. But if the type industry as a whole embraces PUA then we making it easier for software developers of all sorts to not bother with OpenType support. And that’s bad for all of our customers.

  • Jameson R Spires
    Jameson R Spires Posts: 20
    FWIW OT support in Office 2016 for Windows remains unchanged from 2013, any OpenType font needs to be either TTF or a CFF with a dummy or real DSIG table for use of alternates, ligatures, etc.
  • Dave Crossland
    Dave Crossland Posts: 1,430
    edited February 2016
    I can see how a non-professional retail customer will be upset that the put down their $50 on a fully featured script type and then can't recreate the kind of samples they saw that persuaded them to purchase a license without dropping another $500 on Adobe, Corel or Quark plus all the learning time. I expect they are using some equivalent to https://en.wikipedia.org/wiki/Creative_Writer and are perfectly happy with it ;)

    @Adam Twardoch has made an interesting proposal: To use the TTC ("TrueType Collection") format as a fallback method of accessing swash glyphs (etc) when OpenType fails us.

    AIUI, this was invented for CJK fonts a long time ago, and is supported everywhere since MacOS and Windows have shipped TTCs for a long time. Basically it allows you to put a whole font family (say, what would be 4 font files, Regular, Italic, Bold, BoldItalic) into a single file, and where those fonts have duplicate TTF tables, to de-duplicate them. 

    Adam has a script pyfeafreeze ("python OT-feature freeze") that will take a fully-featured OpenType font and split it out into a set of 'pre-OpenType' fonts where the regular ABCabc glyphs are replaced with their OT-feature substitutes (ss01, smcp, etc.) 

    Adam has thus pointed out that instead of using OT to access your swashes with PUA as a fallback access method for non-OT software, we could have OT to access the swashes along with TTC to present each feature as a separate family. 

    For the end user, this is similar to the way that in larger families where you have say Roboto-Black.ttf that in OT-aware apps appears in the UI as part of the "Roboto" family and "Black" style, and in pre-OT apps (like Word.....) it appears the "Family Black" family and "Regular" style. 

    So with a TTC version of "Beloved" they have a single file, and they install it, and in their font menu they get (say) 4 families, "Beloved", "Beloved Swash 1", "Beloved Swash 2", "Beloved Superswash". And then their text stays encoded as normal "Hello", and they select the "H" and set it to "Beloved Superswash" and the "o" and set it to "Beloved Swash 1".

    The benefit of this approach is that the text stays normally encoded and intact (so Google Translate, copy-and-paste-to-email, etc etc, continues to work) which is what the PUA-haters worry about. 

    For end-users it might also be better in that, if they change their mind and want to swap to Samantha (or, assuming you try to keep your PUA encoding scheme consistent, then a font from another vendor who doesn't PUA-encode) then when they switch, their text will not turn into weird boxes, and they 'just' have to reapply specific families to specific letters. 

    I think that this is a fantastic idea, because fiddling about with the Character Map or FontBook to access PUA encoded glyphs is a bit tricky, requiring step-by-step guides and videos, whereas "install the font file" and then "see fonts listed in the family menu" is immediately discoverable and quite obvious for naive users. 

    One caveat is that while Adobe and Apple support "OTC" fonts (OpenType-CFF style collections) they are not supported on Windows. 



    Do people think that would be a better OT-fallback than PUA characters?
  • Mark Simonson
    Mark Simonson Posts: 1,736
    edited February 2016
    That's kind of what I've been doing with some of my fonts (except separate fonts, not TTC) and I really have mixed feelings about it just because of the extra work and possible user confusion it makes. It does avoid the font-switching-surprise issue, but, like the PUA hack, doesn't help get better OT support.

    I do think things have improved on the Mac. The recent versions of 10.11 have much improved OT support at the system level. And pretty much everything is supported and works, including things like named stylistic sets. Any app that uses the system font APIs can support OT features relatively easily. (This doesn't affect apps that roll their own OT support, such as Adobe apps.) The downside is that OT features are practically hidden in a tiny pop-up menu on the systemwide Font browser. On the other hand, it's the same UI for any app that uses it. So, there's not much reason that cheap or free software on the Mac to not have decent OT support.

    Even so, I sometimes wonder if users will ever get it. Even among pro users of pro apps, it seems unusual for them to know about how to access OT features. I get the impression that most people just use the Glyph palette. I hope it's just because the UI for accessing OT features is so bad. Speaking of which, I wonder what's happening with the Adobe OT UI improvement effort?
  • Chris Lozos
    Chris Lozos Posts: 1,458
     I hope it's just because the UI for accessing OT features is so bad. Speaking of which, I wonder what's happening with the Adobe OT UI improvement effort?

    That is also my concern.  True, software support has not progressed enough but people's habit are hard to break, both users and developers.  Perhaps if the software supported it better, students in design schools would learn about it and use it more.
  • Dave Crossland
    Dave Crossland Posts: 1,430
    like the PUA hack, doesn't help get better OT support.
    The whole XHTML vs HTML5 saga demonstrated to me that worse is better, and I think well after 15 years, we're not going to see much OT support where it has not already arrived.

    Meanwhile its a fact that there are a lot of casual users of fonts who do not use OT-aware software and need a way to access hitherto typically unencoded glyphs.

    So, there's not much reason that cheap or free software on the Mac to not have decent OT support.

    Windows continues to be the most popular desktop operating system, though, so the recent improvements in Mac OS X (and in libre desktops) are sadly mostly irrelevant.  


  • James Puckett
    James Puckett Posts: 1,995
    How do we go about doing that? Petitions, public outcry, typographic mobs?

    A display type shops and small software makers could work together to develop a BSD/MIT licensed OpenType API that can be easily integrated into commercial Windows software. DirectWrite does the hard work, all people need is a couple panels to turn stuff on and off.
  • John Hudson
    John Hudson Posts: 3,204
    Dave, from a text processing perspective, Adam's TTC solution is definitely superior to PUA, because the background text remains clean Unicode. There are issues, though. One is the absence of cross-font kerning. Although the TTC may contain a single glyf table and could conceivably contain a single GPOS table with kerning (or even a single old format kern table), from an OS and applications perspective the contents of the TTC are being enumerated as separate fonts. So my understanding is that kerning — or other layout features — would not be applied across boundaries between glyphs from different nominal fonts.

    Note also that there is very little support for CFF flavour TTCs, especially on Windows, so they would need to be built from TTFs, with the usual manufacturing quality issues that this entails. If you've got a solid TTF production workflow, that's fine, but if you're relying on automated conversions from PS sources, you might find making good TTCs a challenge.
  • Kent Lew
    Kent Lew Posts: 944
    Other than a fancier technical wrapper, Adam’s TTC solution sounds not terribly different, at the user level, from what we were doing decades ago with things like Sloop One, Two, and Three.

    And users just going to the glyph palette to insert swashes and alternates seems an awful lot like Linotype typesetters just inserting the uncommon sorts manually from a pi case.

    Ah, Progress . . . !
  • Dave Crossland
    Dave Crossland Posts: 1,430
    edited February 2016
    James Puckett said:
    How do we go about doing that? Petitions, public outcry, typographic mobs?
    A display type shops and small software makers could work together to develop a BSD/MIT licensed OpenType API that can be easily integrated into commercial Windows software. DirectWrite does the hard work, all people need is a couple panels to turn stuff on and off.
    I'm confused; how could DirectWrite be easier for Windows developers to integrate? 

    Indeed, https://github.com/behdad/harfbuzz/blob/master/COPYING has been around for ages, licensed as you suggest, and it isn't used much. 
    Kent Lew said: Ah, Progress . . . !
    I think these low-sophistication methods are entirely appropriate for unsophisticated casual users.

    John, both excellent points. It sounds like Laura's PUA scheme is the best fallback option, then.
  • Kent Lew
    Kent Lew Posts: 944
    I think these low-sophistication methods are entirely appropriate for unsophisticated casual users.
    Fair enough.

    It is reliance upon such things by presumably more sophisticated, professional users that strikes me as particularly ironic. Perhaps worse is indeed better.
  • Nick Shinn
    Nick Shinn Posts: 2,210
    edited February 2016
    Sloop 1, 2, 3 is actually a very practical method.

    For instance, the typographer may set the same text in three successive lines, in the three fonts as reference, and in a fourth working line in which the preferred combination is worked out. And perhaps a fifth line as “next best”.

    At least, that’s how I’ve done it in the past, pre OT.

    If the typographer is not relying on the type designer’s off-the-shelf mixology, but prefers to concoct their own, it’s actually better than OT in InDesign etc., because they don’t have to repeatedly dig down through several layers of GUI to get to the options (stylistic sets), which is hugely annoying.
  • Nick Shinn
    Nick Shinn Posts: 2,210
    edited February 2016
    Yes, I guess the tranche of users we are discussing doesn’t have Optical Kerning!
  • Dave Crossland
    Dave Crossland Posts: 1,430
    Mark Simonson said:
    The thing I don't like about separate fonts is that it means lack of kerning between characters that were designed to work together. I really like the way that works when everything is in one font.
    This may be true of Adobe Illustrator and InDesign text environments, but as @Adam Twardoch pointed out in https://github.com/googlefonts/fontbakery/issues/388 the way that the web works, applying a swash glyph alternative via OpenType requires wrapping that character in a <span> element, which breaks kerning in the same way.
  • Mark Simonson
    Mark Simonson Posts: 1,736
    That sounds like an implementation bug. Applying OpenType features is not supposed to work that way.
  • Dave Crossland
    Dave Crossland Posts: 1,430
    edited February 2016
    @"Laura Worthington" said:

    for me and my audience, [PUA] is better than doing nothing. The way this all began is by interacting with customers who, upon purchasing my typefaces, found they couldn't access the very elements that encouraged them to buy the typeface in the first place. ... copy and paste glyphs out of Character Map or Font Book and into another program, but at least it works. ... "Sure Cuts A Lot," [app] now has a native glyphs panel 
    Laura, I'm curious if you know of any software that has responded to these users by adding an OpenType UI for users to set/unset non-default features (like ss01)?

    It seems that any Windows application that uses the standard text stack gets OpenType shaping (such that automatic ligatures, OpenType (GPOS) kerning, etc, works) - but no UI! @Adam Twardoch described this in the github thread on this:
    Start with Notepad. :) I supports calt (contextual alternates) but gives no way to override its results. Zapfino Extra LT Pro that I made in 2003 shows how this works -- you see substitutions happening as you type but if you finished typing, there is no way to pick another variant. And then virtually every Windows app that uses the standard GDI Windows text controls, any Photoshop clone, older versions of Word or Corel Draw, and tons of simple "add text to image" apps, or apps for vinyl sign cutting or CAD apps or motion graphics/video editing apps or apps that add subtitles or captions etc.
  • John Hudson
    John Hudson Posts: 3,204
    This may be true of Adobe Illustrator and InDesign text environments, but as @Adam Twardochpointed out in https://github.com/googlefonts/fontbakery/issues/388 the way that the web works, applying a swash glyph alternative via OpenType requires wrapping that character in a <span> element, which breaks kerning in the same way.

    That's not 'the way the Web works'; that's the way bad run integration works. The idea that a CSS span applied to characters automatically creates a distinct run for glyph processing is really stupid.

    Then again, as I discussed in my Unicode presentation last year, there are numerous poor decisions around run identification and integration, most of which may only be fixed by downstream processing in which all runs in a line are integrated post-shaping.

Categories