Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Peter Constable

About

Username
Peter Constable
Joined
Visits
517
Last Active
Roles
Member
Points
132
Posts
127
  • Re: [OTVar] Changing tracking/HVAR

    Clearly not things that we've already made it possible to be variable. It would be many of the things that at present aren't variable: cmap entries, name IDs, OS/2.fsType, unicodeRange and codepageRange bits... 

    I don't think this impinges on axis proposal authors since it doesn't affect anything that they currently could make variable.
  • OpenType 1.8.2 errata

    We've just posted two errata for OpenType 1.8.2—a couple of details in 'PCLT' and 'vhea' chapters that were wrong. https://www.microsoft.com/typography/otspec/errata.htm
  • Re: A List Apart considers user interfaces for variable fonts

    I'm not sure that this moves discussion of UI for variable fonts forward that much. It's fairly obvious to make the connection between an N-dimensional variable font with numeric inputs and a collection of up-to-N controls each of which can set up-to-N numeric values. I don't find discussion of multi-variant data visualization all that helpful because visualization of the N dimensions isn't a goal: seeing text formatted using the selected font instance is the only necessary and best visualization of the selected settings; and a radar chart that shows the settings on N axes for "Display Narrow" doesn't actually tell me as a user anything I need to know.

    What might move the discussion forward more would be (i) critical analysis of different kinds of controls in terms of what font-selection scenarios they would or wouldn't be useful for, or (ii) what scenarios might require what manipulation of what kinds of font variables.

    For instance, the discussion of pads points out the obvious, that two variables can be controlled at once. It assumes that for fonts with two or more axes a pad will be beneficial because it "avoid[s] an overload of UI elements and give[s] a designer better visibility." But this overlooks a question of whether or not it makes sense to manipulate the pair of axes together. For example, when would it be useful to manipulate, say, x-height and serifness at the same time, or contrast and optical size? Or would it ever be useful? If you think about cases of successful pad-like or 2D controls, you discover that they are successful because they combine variables that make sense to manipulate together.

    Probably the most widely-used and successful 2D controls are colour pickers that manipulate luminance and saturation at the same time, or hue and saturation. Usually the 2D control is combined with a slider for the 3rd dimension: hence luminance-saturation + hue, or hue-saturation + luminance, or hue-luminance + saturation. They are successful because the dimensions they manipulate are so closely related and pertain to a single concept in the user's mind: colour.

    Another 2D control that is fairly common is the level-curves control used in image editing apps. The concepts involved are more abstract, and therefore the level-curves actually have a fairly significant learning curve (pun intended). To the extent these controls are successful, it is because the problem to solve can only be controlled in two dimensions: the need is to set level adjustments for pixels of various luminance levels, spanning the complete range of possible luminance levels -- so a continuous range of input luminance levels needs to be associated with an adjustment value for each.

    The simpler counterpart to the level-curves control are the levels controls, comprised of a histogram visualization with level-adjustment sliders for brights, darks and midtones. The problem is simplified to three inputs and simpler controls -- three sliders -- are used. This is similar to audio equalizers, in which the continuous audio-frequency range is divided into (say) five sub-ranges, and a level-adjustment slider is provided for each range.

    With those comparisons in mind, rather than creating a 2D pad that can manipulate any arbitrary combination of two axes, as in TypeShift, I think it would be much more helpful to explore whether there are any combinations of possible font axes that would make sense to manipulate together because users intuitively think of them as being closely related, as in the case of colour pickers. Or whether there are situations in which it will make sense for a user to set font values in relationship to some continuous range of inputs values, as in the case of level-curves controls; or a simpler version of that with the input values grouped into a small number of ranges, as with levels and equalizer controls?

    Note with regard to the latter that optical size is like this: text size is a continuous ranges of inputs, and the designer chooses adjustment levels to contrast, x-height, etc. corresponding to each input. But this is being selected at design time, so that at usage time the selection can generally be automated and doesn't require any UI. This brings two questions to mind:

    - What font variables can be automated, based on what inputs and in what scenarios?

    Multiple axes present a risk of exposing the user to choice overload. How can we limit the choices we present to the things most valuable for the user to control. What are the opportunities to provide better typography automatically, without requiring users to understand more concepts and make more choices?

    And, going in the opposite direction from simplicity...

    - Are there any scenarios in which a levels or level-curves kind of UI would be useful?

    E.g., one could imagine a font that doesn't have an optical size axis, but does have contrast, x-height, etc. axes, and a UI is provided with a set of level-curves controls that allows the user to determine what contrast, etc. setting gets used at each text size -- i.e., designing their own customized optical-size meta-axis using primitive axes in the font?

    Summarizing, if we want to move discussion of UI for variable fonts forward, I think we need to move beyond simple surveys of control types and dive into the deeper waters of how typography works, and how good typographic results can best be achieved by a combination of users interacting with typographic options and software making good choices on their behalf.
  • Re: [OTVar] Axes Proposals: variationsguide.typenetwork.com

    This might be just slightly off topic...

    Last week week, Type Network published 3 long-form essays on Variable Fonts by David Berlow, which provide context to David’s vision of variable fonts...

    I'm reading the third one now. David says,
    The fifth registered axis is optical size. This is a treatment, because it does not change the script, class, family or style—just the appearance of a style at a particular size, or range of sizes.
    It seems to me that he considers optical-size variation to be a treatment rather than a style because a priori it is assumed that style cannot include optical-size variation. Is that a generally-held perspective?

    In the letterpress days, would a case of matrices had different drawers for different weights or widths and also different drawers for different sizes? If so, I suppose from that perspective optical-size variation was conflated with and not independent from text size. But in principle could flip things around by saying that optical-size variation was treated in a parallel manner to weight and width, and text-size was simply conflated with optical size. I guess the physical size is the more visible feature than the subtle changes in glyph design, though.

    But I still wonder: in what way is it useful to distinguish between style and treatment in the case of optical size? Earlier in the essay, he gave other examples of treatment, such as how a contour would be stroked or filled. Those involve changing the presentation with the contour staying constant. But with optical-size variation, the contour is changing.
  • Re: [OTVar] Axes Proposals: variationsguide.typenetwork.com

    I'm digesting David's proposed axes. Here's the first one:
    Tag: xtra
    Name: x transparent
    Description: assigns a “white” per mille value to each instance of the design space
    Valid numeric range: -1000 to 2000
    Scale interpretation: values can be interpreted as per-mille-of-em
    I can understand (at one level) what 0 "white" might mean. But it's not clear to me what negative values are supposed to mean.

    In the demo he provides, he points to the distance between stems of "H" as the xtra value. But it's not clear how that would relate to any other characters, such as "i" or "w" or "ই". Is the idea that the value would be based on glyphs for certain representative character or characters? If so, does it matter if this is done differently in different fonts?

    What's the interoperability need for such an axis?