Howdy, Stranger!

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

Peter Constable


Peter Constable
Last Active
  • 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."
  • [OTSpec] Erratum, new OpenType Layout language system tag

    A new erratum has been posted for OpenType 1.8.1: There was an error in describing numeric values for some operator codes for the CFF2 table. See the errata page for OT 1.8.1 for details.

    Also, a new language system tag has been registered for Chinantec languages. Chinantec is a family of languages spoken in South/Southwest Mexico. It's reported that there are some typographic distinctions needed for Chinantec languages, though not between them. So, a language system tag was needed for the group of languages. See the Language system tags page for details.

  • "If DirectWrite supports all color formats, how come not all browsers support them?"

    Somebody asked me this question and found my answer helpful, so I thought I'd share it here. As a reminder, the OpenType spec defines four formats for colour glyph, using the COLR table, the SVG table, the CBDT table, or the 'sbix' table.

    In traditional, non-colour text display, a layout engine resolves a string to an array of glyphs that then get rasterized (by a TrueType or CFF/CFF2 rasterizer), and then the resulting bitmap will get a single colour property assigned and passed to a graphics layer to present on some surface. (There may be some font-smoothing filtering somewhere along the way, but we an skip that for this discussion.) So, let's consider what changes when using a colour font: The different colour formats require different implementations with different interactions between text layout and graphics libraries.

    The COLR format is in one sense the simplest for an existing text layout / graphics interaction: instead of a single array of (TT or CFF) glyphs that get rasterized and presented in one colour (which could be any colour), there is an array of glyph arrays that each get drawn with different colours and layered on top of each other. So, it's very similar to drawing different single-colour strings.

    The CBDT and sbix formats are conceptually simple, but require a little more of a change in the implementation: from a glyph array, you divide this into two different glyph arrays (not unlike splitting into layers for COLR), but then also send these down two different paths: one set of glyphs will be handled normally, using the rasterizer pipeline, but the other will be handled in an entirely different manner -- not sent to the rasterizer but directly to a 2D graphics/imaging library. (Fortunately, because CBDT and sbix use commonly-used bitmap formats, the graphics/imaging library will undoubtedly support those bitmaps.)

    The SVG format is even more different: The glyph array is divided into two different arrays as for CBDT/sbix and sent through different pipelines. But now instead of commonly-supported bitmap formats, you need a graphics library capable of displaying SVG documents.

    DirectWrite does have support for all of the colour formats, but for CBDT, sbix and SVG, DirectWrite is actually doing very limited work: it can reports which glyphs are handled with normal rasterization versus the glyphs that use an alternate format, and it can provide the separate glyph arrays corresponding to each format, and it can return to the app the CBDT/sbix/SVG data from the font. But the app then needs to call into an appropriate graphics library to display those other data formats. Direct2D does provide support for those other formats, including SVG, but apps would need to be updated specifically to handle processing with those other formats -- it doesn't just happen unilaterally by the platform.

    So, if some browser supports one format but not others, that will be because it hasn't explicitly been updated to support those other formats.
  • Re: Oblique and Italic in same family

    For certain reasons, and after some discussion, we (MS, Adobe, Apple, Google and others) ended up deciding to make slant and italic separate sub-family-variant axes in the extended-family model that OpenType Font Variations forces. So, platforms that support the full richness of OT 1.8 shouldn't have a problem with a family that has both Italic and Oblique variants -- or even an Oblique Italic variant.

    That said, Tom's warning is probably appropriate: it would likely create problems in some existing software.