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
  • Re: Private use of name table entry

    @John Hudson Thanks for that reminder. I recall now Rob mentioning you had brought this up, though I'm not sure I ever got around to reading that email. (I may have been relying on Rob to inform me of what mattered.)

    Great to have made history together, and now to _do_ history -- as opposed to making up history. ;-) 
  • 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."
  • Color fonts in Windows 10


    As was mentioned here a year or so ago now, Windows 10 supports all of the colour font formats defined in OpenType 1.8.x. My co-worker, Rick Manning, has just published a post in the Windows Developer Blog about using colour fonts in the Windows 10 Creators Update (released in April). This is a fairly brief overview, not too in-depth either on the font formats or on APIs. 
  • [OTVar] Variable fonts in Windows 10 Creators Update and Insider previews

    If people are using the Windows 10 Creators Update or the more recent Windows Insider Preview builds, we have a bug bash in progress, with "Quests" which are scenarios we invite people to try out. One of the "quests" is for trying out variable fonts. So, if you're using the Creators Update or WIP builds, we invite you to help us out by going through the quest and providing feedback.

    To do so, launch the Feedback Hub app (hit the Start button or the Windows key and just start typing "Feedback Hub"). If you haven't signed in for providing feedback, do so. Then try opening either of these links in Edge (might not work in other browsers):

    (For the second one, you'll have to copy and paste into Edge's address bar.) You can select "Quests" in the navigation pane in the Feedback Hub app and scroll through the list to find the "Variable Fonts" quest.


    As you may know, Microsoft held the Build 2017 developer conference last week in Seattle. In addition to the live sessions, there were lots of pre-recorded sessions posted online. One of our DirectWrite developers, Shrinath, and I gave a talk on variable fonts:

    OpenType variable fonts: How to use fewer fonts and get a lot more typographic richness

    Follow the link to find the video and slides. The session is geared primarily toward app developers. Some of the topics covered:

    - We touched on reasons why to use multiple fonts from a family in presenting app UI or content, and presented benefits of variable fonts.
    - We provided a bit of explanation of how variable fonts work.
    - Demos showing named instances variable fonts working in existing apps (no changes) on the Windows 10 Creators Update. This goes into more depth in relation to XAML than my talk at Typo Labs.
  • Re: OpenType 1.8.1 errata

    We just posted two new errata:

    1. The gvar chapter had an incomplete specification of how to calculated inferred deltas when a contour point doesn't have explicit deltas.

    2. The CFF2 chapter inadvertently had a maxstack operator introduced, but it's not necessary and will be removed to simplify implementations.

    Both are noted in the errata page, but complete spec corrections will be reflected in the next version of the spec.

    See the errata page for details.