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
511
Last Active
Roles
Member
Points
132
Posts
126
  • Re: Inclusion of 'meta' table Design Languages in fonts

    @Georg Seifert

    I noticed the discrepancy while preparing the draft text for OT 1.8 and followed up with Apple. They did update the description for the dataOffset field in the data map record, that the offsets are from the start of the 'meta' table, and that makes clear where the data corresponding to a given record is located. It also makes clear that the dataOffset field in the header isn't required. Their spec also indicates that the data map records follow the header.

    They probably should update the header description in their spec.

    As confirmation of what I'm saying, here's an excerpt from discussion I had with John Jenkins -- this is John writing:

    "Yes, the offsets are really from the start of the 'meta' table and not the start of the data. (We recently updated our spec to reflect this.) I think the best thing to do—since there are already implementations out there—is to change the 'offsetToData' field in the header to 'unused; set to 0'..."

    And later in the discussion,

    "I think it would still be a good idea to have zeroing it out be the norm."


    Wrt "supported", that is still ambiguous, but let me make some observations: 

    First, "supported" is the less interesting of the two concepts. It's mainly useful for font fallback or font binding scenarios as a heuristic to decide, "Is it worth even trying to display this string using this font?" Ultimately, the question of whether a font can display a string is determined from the 'cmap', and data such as the "supported" field or OS/2 fields is just a first-level heuristic for this.

    Secondly, the OS/2 Unicode range fields were initially based on Unicode blocks, and blocks don't really correspond to anything that has practical use. For example, consider the currency symbols block: there aren't very many usage scenarios that involve all or even a large number of those characters at once. Nobody writes messages in currency symbols, for instance. Or, consider Romanian or Turkish text, say: there are multiple Unicode blocks you would need to check to determine if a font can display it. But a font certainly doesn't need to have complete coverage of all those blocks to support Romanian or Turkish. Should a font designed to support Romanian and Turkish but not, say, Lithuanian set Unicode range bits for those blocks? If it does, that may result in misleading an app used for Lithuanian.

    "Supports" allows one to be specific, if desired; e.g., to say that the font can support Romanian and Turkish, but not list Lithuanian. For widely-used scripts like Latin, though, I wouldn't want to be the font developer struggling over what languages to specifically mention and how to verify that. (Btw, see the thread on testing for language coverage.) 

    It's much easier to simply make a declaration about a script: "This font supports Latin script". Of course, particularly for Latin and Cyrillic, or even Arabic, there are so many characters used for certain languages but not others, this can be very ambiguous. My guidance would be to declare support for the script if there are any major languages that could be displayed using the font. Keeping in mind that this is no more than a heuristic for font fallback, I think that's good enough.
  • 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: Are OTF fonts from Glyphs broken on Windows?

    People actually use WordPad? Sorry.

    I'm not sure how many people use WordPad, but regardless it might still be useful for testing since WordPad is a wrapper around the RichEdit control, which is quite widely used in Windows and Office, including Office on other OS platforms.

    I should make a qualification: I don't know enough details to know if code paths used in WordPad are distinct. RichEdit was originally built using GDI, but later revised to enable use of other text code that Office uses across platforms. I'm not sure to what extent WordPad is using GDI-only code paths.
  • OpenType 1.8.2 released

    We've just published another minor-version update of the OpenType spec: OpenType 1.8.2.

    This update was primarily aimed at refinements related to OpenType Font Variations, but there were other non-variations-related changes as well.

    Significant improvements:

    - Axes of design variation (weight, width, etc.), previously described in the 'fvar' chapter, are now described in a dedicated set of pages, the OpenType Design-Variation Axis Tag Registry. This was done because these are relevant for non-variable as well as variable fonts, and to facilitate registration of new axis tags in the future.

    - 'fvar': A new axis flag has been defined, HIDDEN_AXIS. This was defined to allow new font-picker user interfaces in applications to anticipate this or other future flags that may provide recommendations on how to present font options in the UI.

    - 'gvar': The "IUP" algorithm (for inferring deltas for in-referenced points) has been revised to cover specific cases that were undefined, leading to inconsistent behaviours across platforms.

    - 'STAT' (now version 1.2): Added a new axis value table format, format 4, which will allow named instances of some variable fonts to be supported better in older applications that were not designed to support families with an open-ended set of axis possibilities.

    - CFF2: The FontMatrix operator has been constrained, and restricted to use in a Top DICT only.

    - OT Layout scripts/language systems: A constraint on use of language system tags with 'DFLT' script has been relaxed.

    There were also several errors corrected and details clarified, as well as many editorial changes, including changes to structure or field names for better consistency across the spec.

    For more complete details on changes, see the change log.

    A note to font tool developers: all but a few chapters were revised to include anchors for all sections, table/record/enumeration descriptions, and individual fields, allowing you to offer users links to very specific parts of the spec.


  • Re: Private use of name table entry

    @John Hudson : Interestingly, I don't think I ever saw your proposal. I wasn't working in the text/font space at the time, though.

    For a bit more history...

    In the spring of 2014, we had finished Windows 8.1 and were starting Windows 10 planning, and I had just joined the Windows Graphics team to work on DirectWrite. Greg & Rob's team, working with you, had recently completed the Sitka fonts and added them into Windows. Their desire for Sitka all along was to have automatic selection of optical size variants. So, Rob came to me to ask if we'd consider supporting that in DirectWrite.

    My immediate reaction was, I really like the idea, but:

    - DirectWrite (like WPF and XAML) assumes a weight/width/slope family model. In that family model, different optical size variants entail different families.
    - If there is automatic optical-size switching, then a family must encompass different optical sizes -- i.e., an app selects "Sitka", not "Sitka Text" or "Sitka Display", etc.
    - Therefore, this ask entails that DirectWrite needs to support a family model that includes optical size as well as weight/width/slope.
    - I don't want to support a WWSO family with one more name pair; if we support this, then we need a way to support an open-ended, extensible family model.

    It didn't take much for me to convince Rob we should solve that general family problem if we want to support auto-optical-size selection. So, their team and ours, along with Sergey Malkin, had a few meetings in which we grappled with the problem. We considered an extension of the algorithm in WPF/DWrite that parses name strings looking for recognizable tokens, and concluded we really didn't want to parse, but instead wanted some way to have recognized name tokens that we can compose together in different ways. We ended that set of meetings with Rob taking an action item to flesh out that model, thinking through different scenarios, including font families getting extended over time, older browsers working with newer fonts or pages, etc.

    Then it was time to start Windows 10 coding, and all this went onto a back burner.

    Move forward to late 2015. We had released Windows 10 and the subsequent November update, and were evaluating what our next big investments for DirectWrite should be. It was then we decided to extend OpenType with variable fonts. As you know, we established the partnership with Adobe, Apple and Google early in 2016, and had our first face-to-face meeting in March. Over the next few months, in a series of meetings, we worked through a series of technical design decisions needed for the format. By summer, we had made most of the design decisions.

    In the two years since the spring 2014, we had never gotten back to auto-optical-size selection or how to support extensible family models in DWrite. But as we were closing on many of the font-format decisions, I had a chance to start thinking ahead to DWrite implementation. I think it was probably sometime in June that it dawned on me: We're going to _have_ to support extensible family models in DWrite.

    I don't recall exact timing -- it may have been in the previous partner meeting or the following one, that someone from Adobe (I think, Sairus) brought up a "DIAL" table proposal that Eric Muller had written several years earlier. I think the context was a discussion about user interfaces. At any rate, I asked Sairus if he could make Eric's document available, which he did.

    So, with this somewhat late realization we needed to have data we could use to compose (not parse) font names for different family models, I drafted the STAT proposal. I had my two-year-old recollection of our internal meetings and some of Rob's follow-up work, and had recently read Eric's document: these were my main influences in drafting a proposal for the table. It was distributed for discussion at our next meeting (must have been in July). It got pulled together pretty quickly -- under two weeks, IIRC. I didn't accommodate all of the capabilities Eric's "DIAL" table proposal had, but allowed for the possibility of future extension to include them.

    It was during the discussion at that next meeting that the format 3 axis value table was added (to allow for explicit style-linking information -- I think it may have been Read's idea), and we also decided to have a registered 'ital' (italic) axis, so that all relevant attributes of a font can be captured in a uniform manner.


    OK, that's the (long) additional history on STAT. As for your question regarding the OS/2 size fields: it was at that same partner meeting when STAT was discussed that we agreed that STAT would supersede both the OS/2 fields and the 'size' feature tag. So, in OpenType 1.8, the following was added to the descriptions of the OS/2 size fields:

    "Note: Use of this field has been superseded by the 'STAT' table. See Recommendations Section for more information."

    Similarly, the following was added to the description of the 'size' feature:

    "Note: Use of this feature has been superseded by the 'STAT' table. See “Families with Optical Size Variants” in the Recommendations section for more information."

    And, at the end of the Recommendations page, a section "Families with Optical Size Variants" was added:

    "In families that have fonts for different optical sizes or in variable fonts that support the optical size ('opsz') design axis, a 'STAT' table with format 2 axis value tables should be used to indicate text size ranges for which the different optical-size variants or variable-font named instances are recommended. This supersedes the use of the usLowerOpticalPointSize and usUpperOpticalPointSize fields in the 'OS/2' table, and the OpenType Layout 'size' feature."