Variable fonts, axes values

13

Comments

  • Florian Pircher
    Florian Pircher Posts: 176
    KP Mawhood said:
    Radical question. Apart from their utility as a transitional tool and backwards compatibility for non-OT Var outputs, what is the advantage of "named" instances over "unnamed" instances? 
    Fonts only contain named instances. An unnamed instance would be any axes configuration that was not given any name. Or do you mean a different concept of unnamed instance?
    KP Mawhood said:
    Besides instances, is there a way to encourage the inexperienced type user towards (1) harmonious type scales that (2) work well together within a single type system?
    The best thing you can do in this regard is to conform to the axis ranges as outlined in the OpenType spec. For example, set your regular weight at 400 and bold weight at 700, not some other scale like 1–100 or something else. This allows users to get familiar with axes across different fonts and allows apps to offer higher-level abstractions over font variation, such as automatic optical size selection.
    KP Mawhood said:
    … how would a reader of Latin script adjust axes for Arabic and vice versa?
    This reminds me of a recent Twitter thread:

  • John Hudson
    John Hudson Posts: 3,227
    @Florian Pircher
    An unnamed instance would be any axes configuration that was not given any name. 
    Exactly. Any specific location in the design space is an instance or, if you like, a potential instance waiting to be instantiated by being selected and displayed. Named instances are locations that have labels attached to them, typically because they correspond to named locations on an external scale—e.g. CSS weight—, or provide signposts within the design space that the font maker thinks will be helpful to the user. And yes, as Katy suggests, there are probably users who interact with variable fonts solely via named instances, and others who may wish to ignore the named instances altogether and define their own set of instances and relationships, which is where type style definition within software becomes important.
  • María Ramos
    María Ramos Posts: 100
    Florian Pircher said:
    I feel like this discussion is too fixated on the slider interface. A font only offering 300 and 350 axis values but restricting anything in between by specifying a step size for that axis might make some sense for sliders (although I disagree with that), but for different interfaces like number fields, it makes even less sense. A user inputting a value of 325 into a number field would probably expect that value to be set as is, not rounded up or down to the nearest step.

    I can actually think of a possible solution for that. What if for the user interface we use the number of variants in the font (using the step-variant idea)?

    If we have, for example, a font with 30 unit variants, the user can type numbers from 1 to 30, while we can keep the standard values as underlying data. It may add a layer of work for font developers but would make it simpler for the user and software support.  
    I am thinking of desktop users, having a slider or a text field where they can use any number form 1 to 30. In the underlying data, 15 could correspond with 400 (Regular) for example.

    I am often thinking of corporate typefaces in a big company with more than 100 employees working with the same variable font, the brand guidelines have specific values for different uses of the fonts. Variables fonts with a huge number of values add a layer of complication for them, it is hard to understand what the values actually mean and there are many possibilities of making a mistake.
  • Florian Pircher
    Florian Pircher Posts: 176
    edited May 2022
    But now font users have to memorize 12 is Regular and 6 is Thin in one font, but in a different font that uses a different step size, 3 is Regular and 1 is Thin. And if you use multiple apps, some supporting the step size parameter and some don’t, users have to learn multiple design space interpretations (“If I want bold, then I have to use 23 in this app and 700 in this other app for the same font.”)

    As @John Hudson pointed out, this use case would be best served by type style definitions in apps. The workflow would then be: Use named instances if they cover all styles that are needed and define additional styles as user-named instances (e.g. a class in CSS or a Paragraph Style in InDesign).
  • Peter Constable
    Peter Constable Posts: 210
    María Ramos said:
    ...
    If we have, for example, a font with 30 unit variants, the user can type numbers from 1 to 30, while we can keep the standard values as underlying data...

    I think that would be a bad idea for a few reasons. First, it hinders the advanced user who doesn't want to be constrained to those 30 variants. But more importantly, it obscures what is actually selected in the font and thereby hinders interop in various contexts. For example, the user wouldn't know what to specify in CSS to get the same result. And it removes any commonality across fonts—Bold is 700 in many fonts, but 27 in font A, 14 in font B, 13 in font C...

    I am often thinking of corporate typefaces in a big company with more than 100 employees working with the same variable font, the brand guidelines have specific values for different uses of the fonts. Variables fonts with a huge number of values add a layer of complication for them, it is hard to understand what the values actually mean and there are many possibilities of making a mistake.

    That's a fair concern. One solution would be to spec the corporate branding font to have named instances for exactly those instances that are needed. Another is for the branding team to create templates and stylesheets (i.e., CSS) that control which instances are used.

    It might not hurt to have data in the font recommending a step size and then have app UI use those steps but without limiting users to those steps. E.g., with a slider or with a numeric control, have arrow keys jump to the next step on an axis, while allowing values in between to be selected by other means. 
  • María Ramos
    María Ramos Posts: 100
    Florian Pircher said:
    But now font users have to memorize 12 is Regular and 6 is Thin in one font, but in a different font that uses a different step size, 3 is Regular and 1 is Thin. And if you use multiple apps, some supporting the step size parameter and some don’t, users have to learn multiple design space interpretations (“If I want bold, then I have to use 23 in this app and 700 in this other app for the same font.”)

    Names of predefined instances would still be accessible through the dropdown menu, so no need to memorize those values. Of course, the idea is for all apps to use the same step system, we are imagining an ideal situation if the concept works. Apps that do not support the step value—if it offers clear benefits—will be followed by others.

    Peter Constable said:
    María Ramos said:
    ...
    If we have, for example, a font with 30 unit variants, the user can type numbers from 1 to 30, while we can keep the standard values as underlying data...

    I think that would be a bad idea for a few reasons. First, it hinders the advanced user who doesn't want to be constrained to those 30 variants. But more importantly, it obscures what is actually selected in the font and thereby hinders interop in various contexts. For example, the user wouldn't know what to specify in CSS to get the same result. And it removes any commonality across fonts—Bold is 700 in many fonts, but 27 in font A, 14 in font B, 13 in font C...
    We could show the hidden CSS values in desktop apps for a selected step, same as we can show color codes for the web.

    I think creating customised named instances for corporate branding fonts, as Peter mentions, could help in the implementation of different variations for big companies. Of course, stylesheets are a must for variable fonts and all kinds of corporate fonts.

    Peter Constable said:

    It might not hurt to have data in the font recommending a step size and then have app UI use those steps but without limiting users to those steps. E.g., with a slider or with a numeric control, have arrow keys jump to the next step on an axis, while allowing values in between to be selected by other means. 
    That’s true, but my concern is not only with the user interface or the use of the font. I am also thinking about the quality of the font. And I think you will agree with me it is much easier to find errors (outlines not working properly, inconsistencies...) in a variable font with 800 unit values than one that is limited to a meaningful range—not limiting the user style options, as described by some—but defining what are the options that are actually useful and meaningful for a good typographic palette, without losing fluidity in the design space.

    Disagreement doesn’t bother me, I may be wrong, maybe the step idea is not the way to go or maybe it is. What I know for sure is that something needs to be improved, both in user interfaces and in how font developers control the output of their variable fonts.  
  • John Hudson
    John Hudson Posts: 3,227
    edited May 2022
    useful and meaningful for a good typographic palette
    Useful and meaningful to whom? In what situations?

    A useful and meaningful selection of instances for a signage project is likely to be different from that for a product design project, which is different in turn from that for an annual report.

    In the past, working with static font families, users working on different kinds of projects were limited to what the font maker had decided was useful and meaningful in terms of discrete font weights, widths, and other styles. A key benefit of variable fonts—while still allowing the font maker to define named instances—is to remove that limitation, so that typographers can make decisions about what is useful and meaningful.

  • Florian Pircher
    Florian Pircher Posts: 176
    María Ramos said:
    And I think you will agree with me it is much easier to find errors (outlines not working properly, inconsistencies...) in a variable font with 800 unit values than one that is limited to a meaningful range […]
    Say you have a font with two axes, both offering 10 steps. That’s already 10 × 10 = 100 instances. 100 instances are probably more than anyone would regularly check for quality issues, so I don’t think introducing steps would change the quality assurance process much. Three axes at 10 steps each yield 1000 instances, etc.
  • María Ramos
    María Ramos Posts: 100
    edited May 2022
    What I mean by “meaningful and useful” is that there is a noticiable difference between continuous steps (see initial posts). Meaningful and useful within the design space. A noticiable difference to human perception, screen rendering or printed results. And this difference can be subtle, but enough to add value to the previous one.
  • John Hudson
    John Hudson Posts: 3,227
    What I mean by “meaningful and useful” is that there is a noticiable difference between continuous steps.

    Yes, but the steps are only meaningful and useful in that sense relative to where you start from, which is not going to be the same for every project or every user. So if the primary text weight for a signage application is e.g. wght 370 then the steps relative to that for bolder or lighter weights are going to be different than the steps relative to the nominal Regular 400 wght that might be used in an annual report, or the 440 wght that is used in a packaging design. Just as a single ‘Regular’ static font isn’t appropriate for all purposes, a single step model defined at the font level isn’t appropriate for all purposes.

    So we come back to higher level interactions with the variable font flexibility, better UI and the importance of style sheets.
  • María Ramos
    María Ramos Posts: 100
    @John Hudson what makes you think the 370 and 440 weight values will not be present in the step variable font? The designer could propose a step variant of 10 units if it makes sense. Maybe the value is not 370 if the designer has defined a step of 20 units and you use 360 or 380 instead. I am not proposing to limit the step to a small number if the design space needs let’s say 100 variants for example. 

    @Florian Pircher of course, controlling every single step and combination of steps is a kind of utopia but the more you clean the design space the more control you can have and the more inconsistencies you can correct. 
  • John Hudson
    John Hudson Posts: 3,227
    edited May 2022
    I am not proposing to limit the step to a small number if the design space needs let’s say 100 variants for example. 
    I am questioning what determines that ‘need’ and who is qualified to make that determination. I think need is determined by use, so it seems to me that the qualified person is the user, not the font maker.

  • KP Mawhood
    KP Mawhood Posts: 296
    edited May 2022
    John Hudson said:
    An unnamed instance would be any axes configuration that was not given any name. 
    Exactly. Any specific location in the design space is an instance or, if you like, a potential instance waiting to be instantiated by being selected and displayed. Named instances are locations that have labels attached to them
    Yes, exactly this @Florian Pircher. I'm interested by how the location of an instance could be used as a data point in user interfaces.

    In terms of UI, it's much easier to select a multi-axes instance from reference points across sliders than a dropdown of 16–40+ fonts that might have overly long and cumbersome naming structure. Plus, all the advantages for translation mapping in each software, since there would be no need to translate phrases like "ultra condensed", "extra wide" etc… replacing this with "width" or even an icon.

    Aside, "wide thin" at a glance sounds like an oxymoron.
    Florian Pircher said:
    This reminds me of a recent Twitter thread:

    Yes. There is a distinction between aesthetics and function, and that we should be careful of mixing the two. When we speak of VF's axes in this context, I'm reminded of Sahar Afshar's insightful reflections on justifying text for Arabic (ATypI 2017). 

    As a means to justify Arabic, the width axis would seem inappropriate… since this would conflict with an existing stylistic range. But, then how does this fit into existing justification settings? This is an example where variable fonts could fundamentally alter our interaction with typographic software.
  • Florian Pircher
    Florian Pircher Posts: 176
    KP Mawhood said:
    In terms of UI, it's much easier to select a multi-axes instance from reference points across sliders than a dropdown of 16–40+ fonts that might have overly long and cumbersome naming structure.
    Yes, the UI is still lacking in this regard. One problem is that most apps try to use a one-size-fits-all solution to selecting fonts. Most often, this solution is optimized for basic use cases (select family, then select Regular/Bold/Italic/BI). That can be done with a pop-up menu for the family and B and I buttons. Maybe the app offers a second pop-up menu for all styles of a font instead of—or in complement to—the B and I buttons.

    That is the way I see in most cases. Two pop-up menus: family and style. Currently, all named instances of a variable font are forced into the style menu. That is what Adobe did with the 32 styles of Minion Pro.



    Not particularly user-friendly. For the newer Minion 3, Adobe split the family by optical size. Now there are multiple options in the family menu:



    And only a few options in the style menu:



    The data provided by the STAT table is sufficient for apps to split the named instances into multiple families, offering a reduced style menu. However, I am not aware of any app doing this.
  • John Hudson
    John Hudson Posts: 3,227
    edited May 2022
    There is a distinction between aesthetics and function, and that we should be careful of mixing the two.
    Indeed. The wght axis is explicitly weight, not emphasis or other typographic articulation. I must remember to go give Simon a hard time about this on Twitter. :#
  • Thomas Phinney
    Thomas Phinney Posts: 2,896
    I so hate that Adobe split Minion 3 into four families by optical size. Grrr.
    Meant that upgrading existing docs to Minion 3 was substantially more work.
  • Dave Crossland
    Dave Crossland Posts: 1,431
    edited May 2022
    Florian Pircher said:

    The data provided by the STAT table is sufficient for apps to split the named instances into multiple families, offering a reduced style menu. However, I am not aware of any app doing this.
    In fact the STAT table is meant to provide metadata for apps to provide per axis drop downs, which is what https://axis-praxis.org/samsa and the Google Fonts 'type tester' do. 



    Arguably this dropdown should be primary, and the slider a secondary affordance that appears on a pop-up... ;)

  • KP Mawhood
    KP Mawhood Posts: 296
    Florian Pircher said:
    The data provided by the STAT table is sufficient for apps to split the named instances into multiple families, offering a reduced style menu.
    Analogy 1 (ref: Ditch the drop down)

    "You Know What? Fuck Dropdowns." (SXSW, 2016)
    https://www.youtube.com/watch?v=hcYAHix-riY
  • KP Mawhood
    KP Mawhood Posts: 296
    A useful and meaningful selection of instances for a signage project is likely to be different from that for a product design project, which is different in turn from that for an annual report.
    There is no overlap between the stylistic needs of different genres?
    In the past, working with static font families, users working on different kinds of projects were limited to what the font maker had decided was useful and meaningful in terms of discrete font weights, widths, and other styles. A key benefit of variable fonts—while still allowing the font maker to define named instances—is to remove that limitation, so that typographers can make decisions about what is useful and meaningful.
    Yes, and also that font makers should pay attention to UI developments.

  • John Hudson
    John Hudson Posts: 3,227
    There is no overlap between the stylistic needs of different genres?
    Not sure what you mean by ‘stylistic needs’. Yes, there is overlap in that different projects may involve multiple weights or widths and some of those weight and width ranges overlap, but if defining a typographic palette for a project in terms of steps then a) the steps for different projects may start from different places, and b) the step interval for a project may be non-linear. So that strongly suggests to me that steps do not belong in the font, but rather in the style sheets of the user who is planning the typographic palette for the project.

    Yes, and also that font makers should pay attention to UI developments.
    UI developments are just that: developments, things evolving, sometimes gradually and sometimes radically, over time. Fonts are built to format specications. They contain a lot of information that UIs can make use of—and make use of innovative ways—but font format specifications don’t chase UI design, and there’s not a lot that font makers can do differently in terms of tailoring the way they make fonts to particular UIs or trends in UIs.

    My impression is that UI designers have barely begun to tackle variable fonts. Yesterday, Figma announced support for variable fonts, and I have heard good things about their UI but have not tried it myself yet. The fact that it is apparently different from what other apps have done so far indicates that this is still an area in which there is plenty of room for innovation and improvement, and I don’t think font makers should be trying to second guess what users with tomorrow’s interfaces will find helpful in fonts.

  • Thomas Phinney
    Thomas Phinney Posts: 2,896
    edited May 2022
    For the most part, I agree with @John Hudson.

    That said, it is also true that the data structures in fonts are built with some interface ideas in mind, and the data structures sometimes drive what is even possible in interfaces. As @Dave Crossland points out, the 'STAT' table offering stops on a per-axis basis, in addition to specific named instances, has obvious interface implications.
  • María Ramos
    María Ramos Posts: 100
    It just feels sometimes we are too scared of trying or proposing things that makes us go through a transition and change the way we work and think. We should not only adapt to new technology and what software developers propose but also offer our input as font developers and font users. We should always go one step further, that’s the way we improve things. 

    Having said that, I would like to know what font users think of variable fonts. Why not collecting opinions and see what are the issues they find when using variable fonts? All my thoughts are coming from me as a user of variable fonts, knowing as a font developer that things could be done differently.
  • Thomas Phinney
    Thomas Phinney Posts: 2,896
    edited May 2022
    María Ramos said:
    It just feels sometimes we are too scared of trying or proposing things that makes us go through a transition and change the way we work and think.
    Nope: several of us are rejecting your idea for myriad carefully-described reasons, nothing to do with being scared of change.

    John Hudson literally wrote the book—well, the big introductory article for the world—on variable fonts, as requested by the big four companies that introduced the format. His article launched the same morning as the announcement at ATypI in Warsaw, in 2016. https://medium.com/variable-fonts/https-medium-com-tiro-introducing-opentype-variable-fonts-12ba6cd2369

    For my part, I have embraced variable fonts, OpenType as a file format, OpenType layout features, and numerous other new font technologies. I did entire presentations on why I thought OpenType would be a success in the marketplace, in ways GX and AAT were not, and why. I evangelized this big new thing to type foundries, taught foundries and designers how to make OpenType layout features, etc.

    So, no: my rejection of your proposal is because I think it places limitations on end users that as an end user I would hate, creates new problems, and because the problem you are trying to solve doesn’t seem to me to be a problem in the first place.

    This is NOT to say that variable font tech cannot be improved, at the level of the format and the OpenType specification. I am going to be very happy to see the next version of the AVAR table, because it will allow us to bend and restrict designspace in useful ways that would otherwise require masters in every corner. With three, four, or more axes, that is problematic.

    Currently I am working around that as a designer (for Google’s Material Symbols) by creating something I call “synthetic masters” for some of the corners that would otherwise be handled by pure vector addition from the other masters. Instead, I pluck instances from chosen spots elsewhere in the designspace, and then add them to the corners to become new masters. But this is a hack. If an AVAR update to handle this sort of thing wasn’t already on the table for the next version of OpenType, I would have been asking for something like it. So, yes, I am in favor of incremental improvements as well as big new things. No, I am not scared of innovation and change, large or small.

    That said, even though I don’t like your current proposal, I admire the creativity and thought that went into it. Your enthusiasm and willingness to get out and evangelize it is great! Maybe next time it will be something I can get behind.
  • John Hudson
    John Hudson Posts: 3,227
    edited May 2022
    In case I have not been adequately clear: I don’t reject the idea of breaking down variable font interaction into ‘meaningful and useful’ steps. I just don’t think there is any benefit—and several downsides—to trying to do that at the font data level rather than where interaction actually happens, where users have a better idea what meaningful and useful steps are for their needs.
  • Thomas Phinney
    Thomas Phinney Posts: 2,896
    Agree: if this were a system-level or app-level option available to the user, I would be all for making such an option available.

    In fact, I would just generally be in favor of a system that allows users to select specific instances—whether predetermined or not—and share those definitions easily with each other. Like styles for a document, but at a higher/broader level.
  • María Ramos
    María Ramos Posts: 100
    Right! My previous comment was probably not totally fair to the people who engage in the conversation here. 

    Are there more benefits or drawbacks in the step proposal? It seems I am one of the few envisioning the benefits here. If you offer users the two options, showing variable fonts with the steps model and the current model, which one would they use the most?

    The color selection picker, mentioned in this thread before, is a good comparison model in terms of implementation for the user interface. You have different ways of selecting a color:
    1. Dragging the mouse in a gradient area where you have all the values but is hard to be precise in your selection.
    2. Typing the values or using de sliders for the color model of your choice, where you are precise in your selection and have many more options than your perception scope.
    3. You use a color palette with all the colors and grades of colors you need.

    Maybe all of them should be options for variable fonts as well. We could think the instances are what the palette is for colors but instances are usually too limited and do not include grades, let’s say a want something a bit heavier than Regular. Being able to build your own variable font typographic palette would be useful, if not at a font developer level at least at a font user level as you suggest above. I still think including a recommendation at a font developer level could be helpful, same as some apps recommend grades of color.
  • Simon Cozens
    Simon Cozens Posts: 752
    edited May 2022
    I still think we're engaging at cross purposes. Improving the UI that applications expose  for using variable fonts is an absolutely fine idea. I don't think anyone disagrees.

    Altering the underlying variable font technology to force this change on all uses of VFs is a terrible idea.

    (Edit: Actually, re-reading the past few posts, perhaps we've got past that stage now...)
  • KP Mawhood
    KP Mawhood Posts: 296

    A few reflections…

    1. Is it better/kinder to be disagreed with directly, or be welcomed into a club that back-pats freely? Action often rests on the individual, and it can takes years (decades) to help others see your point of view – and how to implement that – if you continue to believe that it's the right way forward. 

    Thomas Phinney said:
    I think it places limitations on end users that as an end user I would hate, creates new problems, and because the problem you are trying to solve doesn’t seem to me to be a problem in the first place.

    2. As kindly, gently and politely as I can… Thomas, John you are cutting-edge, leading experts in this field. You can articulate incredibly fine details around these technologies with skill, precision and confidence. Your roles cannot be overstated.

    At the same time, you are not the target audience for this product. Variable font technology was not designed for you… because you are experts; you are not the everyday font user. You know too much about the product, the technical constraints, political decisions, business implementation, marketplace projections etc. 

    https://en.wikipedia.org/wiki/False_consensus_effect
    https://www.nngroup.com/articles/false-consensus/

    What does the everyday font user look like?

    It's easy to be lead astray by group think, and so it's important to test our assumptions and apply user research techniques. How much insight did the community gain from Mary Catherine Pflug's "Font Purchasing Habits Survey"? 

  • KP Mawhood
    KP Mawhood Posts: 296
    edited May 2022
    Simon Cozens said:
    Altering the underlying variable font technology to force this change on all uses of VFs is a terrible idea.
    To force change, yes. To improve conversion, why rule it out? Isn't helping typographers one of the major goals of variable font technology.

    General example questions (pulled from UX Design):
    • What users are trying to do (goals)
    • What users do (behaviours)
    • The context of user (the environment)
    • How our product helps them achieve their goals
    • How our product facilitates common behaviours
    • What pain points and roadblocks can be removed
    • How our product compares to competitors (or similar products)
    • Is our product desirable. Does it solve a problem
  • Simon Cozens
    Simon Cozens Posts: 752
    OK, so we are still talking at cross purposes. :smile:

    Let me try to come up with an analogy. All analogies have limitations, but let's try.

    I have a crate of LEGO bricks. The bricks in the crate are well-made, well-designed, and brightly coloured. You can put them together in nearly any configuration. There's a lot of  expressiveness there.

    But there's some disadvantages to that. My son sometimes doesn't know what to build. Sometimes the configurations don't really work.

    There are two ways we can solve this problem. We could change the technology itself: produce a smaller number of bricks, where each individual brick is larger and more complex: for example, make a "castle door" brick and a "castle wall" brick, and now you have much more likelihood that a combination of bricks will turn into a nice castle.

    Or we could change the user experience, which is what LEGO has done: package up particular selections of bricks which work well, and provide a guide for the user which helps them to put the bricks together. If you want to build a castle, you buy a castle set. It's exactly the same bricks as we have in the crate, but curated.

    Curating the technology itself will solve the problem, but it will also reduce the overall expressiveness, and once it's lost at the technology level, it can't be brought back. Curating the user experience will also solve the problem, but at the same time allows for the underlying technology to still be used in interesting and unexpected ways by advanced users.

Categories