New Microsoft size-specific design selection mechanism

John Hudson's picture

[Originally posted earlier today on Typedrawers. This information seems significant enough to warrant cross-posting. Comment in the forum of your choice.]

Matthew Carter's new Sitka* typeface family ships as 24 fonts with Windows 8.1. The standard Windows 4-style family is implemented in six different size-specific designs (Small, Text, Subhead, Heading, Display, Banner). After Ross and I got involved in the project, we spent a lot of time at Microsoft discussing options for software selection of size-specific designs. I think we probably hit all the possibilities in one way or another -- everything from new GSUB features to Composite Font Representation wrapper --, and some of the funkier options were quite attractive. In the end, Microsoft opted for a very simple mechanism: two new data values in the OS/2 table, one indicating the lower size range limit for the individual font and one the upper size range limit. The relationship of the fonts is established via existing name table entries.

A formal spec for the new OS/2 table version should be forthcoming from Microsoft in the next few weeks, and will be submitted for inclusion in the ISO MPEG Open Font Format. Here are the basics:

The OS/2 table is updated to version 5.

The two new data fields are
usLowerPointSize
usUpperPointSize

The unit used in defining these values is a twip, i.e. a twentieth of a point. This enables size use ranges to break at fractional point sizes without getting unreasonably fiddly.

The usLowerPointSize value is inclusive; the usUpperPointSize value is exclusive. In other words, the lower value indicates the size at which the font starts to be used, and the upper value indicates the size at which it is no longer used.

EXAMPLE: The Sitka Text font is intended to be used from 9.7 point up to any size below 13.5 point. Therefore, the usLowerPointSize value is set to 194 twips (9.7×20) and the usUpperPointSize value is set to 270 twips (13.5×20).

NOTES:

1. The size selection mechanism is based on the computer point (1/72 inch). This means that selection is made relative to nominal point size, and is not device dependent. This may be controversial (hello, David), and while I think it is reasonable in the long-term -- given device resolution increases, pinch-zoom behaviour, etc. -- there are current situations in which one might well want device dependent size selection that calls for different outlines for the same nominal point size at different resolutions. Folks who want to join in making a case for such should engage with the ISO MPEG specification process once MS submit the draft spec.

2. It should go without saying that this new mechanism is intended to replace the existing GPOS {size} feature mechanism, which has mostly languished unimplemented since it was first specified about 15 years ago. Hacking the GPOS data structure to put font selection information in a table normally accessed only at the end of glyph processing was always counter-intuitive, and I'm not surprised it turned out to be pretty much dead-on-arrival.

3. In order to implement the new data in the Sitka fonts, we wanted to be able to integrate the new OS/2 table version support in our existing workflow. Thanks to Frank Blokland at DTL and the OTMaster developers at URW for quickly adding this functionality for us, which I believe will be available in the next version of OTMaster, which Frank anounced at ATypI.

_____

* At ATypI Amsterdam, Matthew gave a presentation with Kevin Larson on the Sitka design process, which used iterative legibility testing to refine letter shapes.

hrant's picture

{To Follow}

William Berkson's picture

Can we see a sample of the different sizes?

John Hudson's picture

http://www.tiro.com/John/Sitka_Size_Specimen2.pdf

See also the 'MS Sitka' thread in the General Discussion area. I think it would be more useful to maintain discussion of this particular typeface family there, and use this thread to talk about the size-specific selection data model.

Theunis de Jong's picture

InDesign has a checkbox for "Automatically use correct Optical Sizes" in its General Preferences, but I don't think it ever did anything :-)

While awaiting applications to support this new feature:
Is changing the optical size an application operation? Can you manually override to another size? And if so, does the text need recomposing?

John Hudson's picture

InDesign's preference for Optical Sizes is, I believe, a legacy Multiple Master function, i.e. it doesn't work with OpenType. Adobe is one of the few font foundries that actually include GPOS {size} feature data in their OT 'Optical' fonts -- terrible term, by the way --, but have not implemented support for it in any apps, to my knowledge.

Is changing the optical size an application operation? Can you manually override to another size? And if so, does the text need recomposing?

Good questions all. I'm not sure anyone has fully worked out how this should work at the level of interaction between automated selection and user discretion. Given Microsoft's tendency to specify data formats but not implementation, I expect it will be up to the wider type and design community to think about this and determine what we'd expect from different kinds of applications (as was the case with, e.g. determining whether Stylistic Set features should be treated as additive or exclusive).

blokland's picture

John: ‘[…] this functionality […] will be available in the next version of OTMaster […]

Yes, and OTM 3 will become available around the end of this week.

FEB

Nick Shinn's picture

Ideally, the foundry would set the default values for optical size ranges, but the layout application would have a slider so that typographers could adjust the ranges*. The foundry would certainly consider target device or demographics in deciding where to put the boundaries.

Typographer manual over-ride is necessary because size (degree of arc) is not the only thing that effects readability, because apart from device and demographics, there are also color (of text/background) and brightness of the document design to be considered.

In some cases, the adjustment may be better as grading/weight change, rather than size-specific.

*Quark has something like that for editing tracking tables.

blokland's picture

Prior to the new OTM-release end of this week, a must-read manual by Karsten Lücke, which contains a lot of info on the production and editing of OpenType fonts, is available for download now.

FEB

abattis's picture

When will the specs be released? FontForge is ready to go on this :)

blokland's picture

John: ‘[…] which I believe will be available in the next version of OTMaster, which Frank anounced at ATypI.’

OTM 3.7 is available directly from DTL (see also the Latest DTL News section) now, and will be very shortly from FontLab Ltd.

New in version 3.7.0:
— Import/export of Ideographic Variation Sequences (IVS)
— Extensively enhanced Glyph Editor
— Switch for Subroutinization in CFF
— Support OS/2 Table V5
— Side-by-side viewer (for multiple fonts)
— Change table view with ( + )
— Editing of Feature Parameters
— Enhanced Consistency Checker
— Export of IK/II/BE/IB formats (plus export of all formats, i.e., plus UFM, CHA, FEA)
— Support for COLR+CPAL tables
— Autohinter for edited or newly added glyphs

Karsten Lücke’s manual on OT-format production/editing is available as PDF, or can be ordered as printed edition directly against production costs.

billtroop's picture

I could hardly believe that the Indy pref for optical size works only with old MMs and not with (as John points out) the ill-denominated 'opticals' (which always sounds to me like a nominally health-giving breakfast dish composed of stale rusk, eggy stuff, and brewer's yeast, preferably served on a recycled floptical). But he is completely correct that the feature has no effect on the 'opticals'. You must wonder what Adobe's point in publishing the fonts is, if no software, not even their own, supports the hapless fonts.

For the record, Microsoft was the first software publisher to support correct optical size automatically. There was a Windows-only version of MSW in the mid-1990s that automatically selected the right optical instance of an MM font that contained an optical instance.

So it is great that MS software will be supporting the sizes. Since Sitka is the best thing to happen to type since Sumner Stone's Cycles family, I believe, thanks to MS support, that it will eventually be compulsory for other software publishers to support the font family fully, whether they like it or not. It is so heartening to see a font project like this - - for once, everything has been done right. It is just extraordinary to think that there will in future years be a lot of really good typesetting being produced automatically by people who don't know and don't care that they are doing it. That's the way to do it!

mike_duggan's picture

Thanks for the comments Bill

Syndicate content Syndicate content