New Microsoft size-specific design selection mechanism

John Hudson

I've confirmed that I am allowed to talk publicly about this now, so here goes...

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.

Dave Crossland

Nice. How will this work its way into the web?

John Hudson

Via text APIs, I imagine. As far as I know, this aspect of the infrastructure didn't make it into Win8.1 -- DWrite would be the obvious home for it; I wouldn't expect backwards implementation for GDI+, although that would be nice --, but that was due to timing.

There are some interesting questions to consider with regard to size-selection in dynamic text environments. The distinction between zooming and enlarging text is important, and I'd say that zooming shouldn't trigger new font selection -- otherwise there will be reflow --, whereas enlarging might. I tend to think of enlarging as the dynamic text equivalent of a large-print edition, which can be either a straight enlargement of the original setting or a resetting in a larger type size.

[Deleted User]

I very much hope that Microsoft will specify the size-selection mechanism, and the interaction of new OS/2 values with the name table records in particular, soon. This to make sure that noone produces incompatible fonts and that noone creates incompatible mechanisms. Both would render the functionality useless.

Deleted Account

"There are some interesting questions to consider with regard to size-selection in dynamic text environments"

That's simple, isn't it?

The non-dynamic user is screwed to names for sizes.
"usLowerPointSize" and "usUpperPointSize" are not screwed to names, so,
Developers are all either screwed to the founding unregistered size range names too,
and/or we're free to screw it up any other way we wish.

And, then bunches of bunches of names for numbers show up and another fundamental type thingy is shot in the foot, feet, each toe, twice, while it was standing on the hand that didn't shoot it, which also got shot, 12 times.

To say "I've got a better idea," would be an insult to most of my better ideas;)

I don't think you get far in any direction with:

MSSitka-Small, 6-9.7, 400, 500
MSSitka-Text, 9.8-17.34, 400, 500
MSSitka-Subhead,17.35-23.8, 400, 500
MSSitka-Heading, 23.9-24, 400, 500
MSSitka-Display, 24.1-50, 400, 500
MSSitka-Banner, 50.1-7,000, 400, 500

vs.

MSSitka, 6, 411, 513
MSSitka, 9, 402, 501
MSSitka, 12, 398, 456
MSSitka, 18, 365, 411
MSSitka, 24, 314, 398
MSSitka, 42, 308, 367.

or

family\style\size_name\size_range_MSpts\GDI_OS/2wt\GDI_OS/width

vs

family\style\size(in pts)\wt (in 1/1000em\width (in 1/1000em)


Do you?

John Hudson

I'd love to reliably and confidently include numbers in font names. For whatever reason, software companies still seem to be wary of it, although the last recorded issue I saw with it was with Mac Type 1 printer fonts.

When we were working on the Sitka fonts in-house they were Sitka 6, Sitka 13, Sitka 21, Sitka 27, Sitka 32 and Sitka 36 (these working numbers don't correspond necessarily to the eventual target sizes; they record interpolation points between Matthew's nominal masters). Then Microsoft said we had to come up with names instead. Naming size-specific designs with descriptive terms such as 'Caption' and 'Subhead' has always seemed to me problematic: these typographic rôles are not linked to fixed sizes, they create problems for localised language UIs, and they're vague (how 'Small'?).

But I don't see that your proposed name/number system actually captures the information that a user would need to know at what sizes to use specific fonts (if relying on name to determine this manually, rather than using software that references the OS/2 table data and applies the selection automatically). 'size(in pts) = 12' means what exactly?

And what is the point of providing differing weight and width data -- rather than weight and width class data -- for size-specific variants of the same nominal typeface style and weight. A 6pt-specific Bold Condensed Roman and a 36pt-specific Bold Condensed Roman are both still bold condensed romans. The fact that they have different actual weight and width values relative to the em is something it isn't useful to record. The fact that they are in fact the same nominal type weight, width and style -- just targeting different sizes -- is useful to record.

John Hudson

BTW, when I referred to ‘existing name table entries’ in the original post, I wasn’t talking about 4-style family names, and hence not to 'Small', 'Text', etc.. The specific name fields to be used to establish that the Sitka Small Italic font is a size-specific variant of the same family as Sitka Text Italic, Sitka Subhead Italic, etc. will be documented in the technical spec from MS, and I'm not going to muddy waters by speculating on which data will be involved. Software makers have a long history of picking the wrong set of names for a function, without me confusing anyone.

Deleted Account

John:
"'size(in pts) = 12' means what exactly?"

Size in points means exactly what it says.

John:
"And what is the point of providing differing weight and width data -- rather than weight and width class data -- for size-specific variants of the same nominal typeface style and weight."

The fonts in question are not size-specific variants.

John Hudson

Glad to have that sorted. Now I understand that you're talking about something entirely other than the subject of this thread, I'll go back to packing for IUC37.

Deleted Account

John" "Now I understand that you're talking about something entirely other than the subject of this thread"

Well... actually I'll be the one to determine what's entirely the subject, if that's okay here. Elsewhere, be careful.

Optical sizing, is at least a large subset of traditional typography, and so, has all the usual issues in legacy and cutting edge operating systems as they try to emulate really really old solutions. Names are an issue that type and software developers have striven with great effort to create parallel systems for, or eliminate names from use, if they can be recorded numerically. The two systems are for people and for programs, and combinations that occur among them. You all know this right?

Today, one can see, from Panose, to pixels, ("pixels or px), an attempt to quantify the entire mantra from family to glyph, for software. People and developers, split on names, depending on their typographic context. We all like families as names, some programs need them converted to a list of numberish things like H1, big deal. People like numbers for sizes, so do programs. Sitka has names for each range, the master is in the middle.

Range-based type compromises by leaving something between the user and content to decide what to use. In this case, the compromise to a single file, scaleable to multiple sizes and resolutions, is both late in the history of digital outline fonts, and fraught with UI issues. So, I had to ask why.

In addition, if this compromise is repeatedly near-emulated by others to form a "standard", more people will want to ask why.

This will be a good place to start.

Also:
"6pt-specific Bold Condensed Roman" and
"36pt-specific Bold Condensed Roman =
"bold condensed romans."

So we need be limited to a 1 digit system dedicated to width and weight "classes", to say what the names tell everyone and everything, all over again? I think not. The beats grow apart, we know who wants that recorded in the fonts.

Laurence Penney

Thanks for the useful post, John.

Is there any defined behaviour when fonts in a family have overlapping optical size ranges? For example, FontShop might think it reasonable to specify FF Clifford Six to extend from 2pt to 11pt, and FF Clifford Nine from 8.5pt to 14pt. Personally I often prefer to use the smaller design sizes at sizes larger than apparently intended.

Georg Seifert

One question I have about the optical sizes is if you design a poster or something that is read from a distance, you would like to use the same range of style but in a different scale. There should be a way to define this.

PabloImpallari

If the only 2 new fields are:
usLowerPointSize and usUpperPointSize

How are the "names" of the related font files defined?
They are hard-coded into the sequence: Small, Text, Subhead, Heading, Display, Banner?
or each designer can create their own sequence?

For example:
If you only want to relate only 2 size-specific designs (Text and Display), is that possible?
Or you always need to have all 6 variations?

Nick Shinn

Ideally size should be identified by degree of arc of vision, which would address Georg’s concern.

There is no harm in having a size-specific standard, but it is only a benchmark.

For instance, brightness has an effect—consider turning off (or on) the illumination of a Kobo Glo e-reader. With the light off, a smaller optical size is called for, with no change in absolute size of text.

Deleted Account

Really guys.

Most all the issues raised since I raised the granularity issue, are granularity issues.

How many "ranges" per style we we receive of the gods of type.

Berlow's "ranges" per style rating system v.1/23.09_2
256 ranges = Homerun.
128 ranges = Triple.
64 ranges = Double.
32 ranges = a Single.
16 ranges = Strike out.
8 ranges = foul the ball off foot
4 ranges = foul ball off face
<4 ranges = foul ball, no further details.
none = (you are here).

John Hudson

Pablo, definitely no requirement to implement the same six size variants as Sitka, or any other number. The definition of the two new date fields means you could even include this data for a single font variant, although there wouldn't be any point in doing so.

Laurence, I believe the spec will be that size ranges be exclusive. The whole point is to make it easy for software to select a size-specific variant for a given piece of text, and if the font family contains two fonts with overlapping ranges, how is the software supposed to decide which to use?

Georg and Nick, I think it will be essential that any software implementing size-specific design selection should accept manual overrides. The idea that different scales could be applied is an interesting one, and that would presumably be possible at a higher level.

Sorry not to have responded sooner: I just got home from my extended Unicode trip.

Deleted Account

John,
"...the whole point is to make it easy for software to select a size-specific variant for a given piece of text"?

Assuming this means: the point is to make it easy, once people or composition software select a size, for font software to get the right variant for that size selection, and forgiving the fact that the implementation you introduce yields the "wrong" variant 64/72ths of the whole number point size requests, via arbitrarily selected range names, on fonts with otherwise identical meta data, I'm not sure how one gets to a "higher level", this way.

How the software decides which variant to use from a series of font variants, each set for a single size, is a silly question — with scaling, software picks the closest variant to the size request, with interpolation it picks the right one for that size request. Using a point size number for a master adds the benefit of not having to be exclusive, and more frighteningly, not inclusive.

Wonder how that works... There's also a problem with the family being chained together like this, as if they all respond to size alike? everywhere? which we already know they don't. But... I can't wait to hope to try to consider a mixture of TTFs and CFFs to serve large size variants for Windows.

John Hudson

There's also a problem with the family being chained together like this, as if they all respond to size alike?

I think it's possible for e.g. a set of Bold family members to have different OS/2 size range data from e.g. the Regular members of the same family. It's something I'll check when we have the spec to examine.

...with scaling, software picks the closest variant to the size request, with interpolation it picks the right one for that size request.

Right. Interpolation -- or extrapolation à la TT variants -- provides much finer targeting than scaling a single font to a range of sizes. So would some possible hint-to-size mechanisms we looked at, if we'd been able to reliably query point sizes (remember, we're looking for design-specific size selection, not ppem-specific, so we'd want to affect outlines even for high-res printing).

For various reasons, on-the fly interpolation and extrapolation were taken off the table a decade ago. There are good reasons -- something you and I agree on -- to put them back on the table. In the meantime, font developers have been making -- and will continue to make -- families of fonts with size-specific 'instances', intended for use at ranges of sizes. The new OS/2 data enables such fonts to carry easily accessible information about what those size ranges are.

Deleted Account

John, having commercially pioneered 'instances', of web fonts intended for use in ranges of sizes, I completely agree that font developers have been making families of fonts like this... there being good reason for ranges on the web, where ranges are everything, as instances can't be finer.

For print, where ranges are old, I think the definition of progress is, as you imply, much finer.

But leaving that, and a question I still harbor about how properly bold a bold can be independent of resolution, the MS Win 8.1 support says, "They [the Sitka family] are intended for use for print or on-screen content, but not for UI."

Can you talk a little about the discussion of how the distinction is best made between fonts for, or not for, UI?

LeMo aka PatternMan aka Frank E Blokland

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

OTM 3.7 is now available directly from DTL (see also the Latest DTL News section) 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 (+ export of all formats, i.e., + 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.

John Hudson

Can you talk a little about the discussion of how the distinction is best made between fonts for, or not for, UI?

You'd probably have to ask Microsoft. That seems to me primarily a design issue, and perhaps the comment was intended to forestall any enthusiastic developer trying to use Sitka in a Windows UI environment instead of the authorised fonts. Beyond that, there'd be character set issues, given how heavily localised UIs are. But these are all guesses.

John Hudson

From Greg Hitchcock to the OpenType discussion list:

Here is the update to the OS/2 table adding support for optical size ranges. The new Sitka font that has shipped with Windows 8.1 uses these new fields. I'm providing here the fields in the table that have changed, if anyone desires a Word document for the whole OS/2 table with the additional fields, I can provide that as well. Contact me off list and I'll send that to you.

The decision to add additional metrics to the OS/2 table went through several evolutions. Our early plans were to implement the changes through TrueType instructions. We also considered using the OpenType Layout SIZE feature, but decided against these for a myriad of reasons. Ultimately we settled on the new fields in the OS/2 table. The new version will be 5, thus this is the sixth version of the table. The only changes, besides the version number, are two new fields added to end of the existing OS/2 table data.

The choice of using TWIPs for measurement is embedded somewhat in Windows history. For the OS/2 table we preferred not using a fixed point notation. Although the SIZE feature used tenths of a point, TWIPs had been used in Windows GDI and OS/2 as a scaling option since the mid-80's.

As always, feel free to provide feedback.

version
Format: 2-byte unsigned short
Units: n/a
Title: OS/2 table version number.
Description: The version number for this OS/2 table.
Comments: The version number allows for identification of the precise contents and layout for the OS/2 table. The version number for this layout is five (5). Versions zero (0, TrueType rev 1.5), one (1, TrueType rev 1.66), two (2, OpenType rev 1.2), three (3, OpenType rev 1.4) and four (4, OpenType rev 1.6) have been used previously.

usLowerOpticalPointSize
Format: two-byte USHORT
Units: TWIPs
Description: This field is used for fonts with multiple optical styles.
This value is the lower value of the size range for which this font has been designed. The units for this field are TWIPs (one-twentieth of a point, or 1440 per inch). The value is inclusive—meaning that that font was designed to work best at this point size through, but not including, the point size indicated by usUpperOpticalPointSize. When used with other optical fonts that set usLowerOpticalPointSize and usUpperOpticalPointSize, it would be expected that another font has this same value as this entry in the usUpperOpticalPointSize field, unless this font is designed for the lowest size range. The smallest font in an optical size set should set this value to 0. When working across multiple optical fonts, there should be no intentional gaps or overlaps in the ranges. usLowerOpticalPointSize must be less than
usUpperOpticalPointSize. The maximum legal value is 0xFFFE. For fonts that were not designed for multiple optical styles, this field should be set to 0 (zero) and the corresponding usUpperOpticalPointSize set to 0xFFFF.

usUpperOpticalPointSize
Format: two-byte USHORT
Units: TWIPs
Description: This field is used for fonts with multiple optical styles.
This value is the upper value of the size range for which this font has been designed. The units for this field are TWIPs (one-twentieth of a point, or 1440 per inch). The value is exclusive—meaning that that font was designed to work best below this point size down to the usLowerOpticalPointSize threshold. When used with other optical fonts that set usLowerOpticalPointSize and usUpperOpticalPointSize, it would be expected that another font has this same value as this entry in the usLowerOpticalPointSize field, unless this font is designed for the highest size range. The largest font in an optical size set should set this value to 0xFFFF, which is interpreted as infinity. When working across multiple optical fonts, there should be no intentional or overlaps left in the ranges. usUpperOpticalPointSize must be greater than usLowerOpticalPointSize. The minimum legal value for this field is 2 (two). The largest possible inclusive point size represented by this field is 3276.65 points, any higher values would be represented as infinity. For fonts that were not designed for multiple optical styles, this field should be set to 0xFFFF and the corresponding usLowerOpticalPointSize set to 0 (zero).

Scott-Martin Kosofsky

I posted this on the OpenType list, in a discussion about how to implement automated size-specific designs. I thought it might be of interest here:
_________
Wouldn't it be nice of you could legislate or engineer your way around ignorance? All you can do is offer a better, more flexible product and hope for the best. Will automatically engaged type size masters stop people from setting lines that are too long or too short for their type size and leading? Of course not. And, as Frank Blokland wrote, what about those of us who make a conscious typographic decision to use the "wrong" size to suit a specific purpose?

Adobe's Multiple Master offered a very powerful toolbox to typographers but it failed in the marketplace. People said it was too complicated, though it's more likely that they didn't know enough to use it. Later optical-size strategies have had their problems, too, as a six-point "caption" master might be improperly weighted for someone who uses it to set 8.5pt footnotes along with a 12pt main text that's a bit light, though it might work perfectly well for a list of food ingredients on a label. It all depends on the design and the common denominator the manufacturer is trying to achieve. But these are sophisticated issues for experienced typographers to consider, not the province of the hoi polloi, for whom all the choices are nothing more than a source of confusion. It's little wonder why so many never purchase the full set of fonts. Someone smart once said, "Do not . . . cast pearls before swine, lest they trample them under their feet, and turn and tear you in pieces." Ok, maybe not tear you into pieces, but they will trample.

I can't tell you how many experienced designers I know who cannot navigate their way through OpenType features, or have any idea of what they are, how they work, and how they're accessed. Is the system flawed, or has there been a failure to educate people about a technology that's been around for nearly twenty years? Or is typography--good typography--just too complicated for mass access?

Automation of type-size masters has the same chance of making things worse as it does of making them better. Hey, but if keeps some people employed, who am I to say?

Scott

George Thomas

1. The system is not that flawed.
2. There has not been a failure to attempt to educate, but to learn.
3. Good typography is indeed complicated and the masses don't want to deal with it. The famous Refusal Order Blank, reason number one truly applies to them: "You wouldn't know what the hell to do with type if you had it."

Georg Seifert

Is there any software (other then win8.1) that supports any of the size selection? Does Indesign support the Adobe size feature?

John Hudson

No, InDesign doesn't. There's a setting preference for size selection, but it's a legacy MM thing.

I recall hearing something about LaTeX and size selection many years ago, but don't know the details.

As discussed on the OFF standards list recently, the MS mechanism currently lacks a reliable mechanism to identify size-specific fonts within larger, more complex family arrangements. This was also discussed during the OTL developer meeting at Seattle in April, and the assumption is that some kind of name identifier will need to be added to work with the new OS/2 size data.

Georg Seifert

Thanks for the clarification. I add support for the size Feature to Glyphs, anyway. To avoid one part of the hen and egg problem.

Sandy Cerovich

This should probably be a different topic, but it does tie into the Microsoft specs discussion. Weight - at one time the MS specs only allowed weights above 250. Has that changed? Do they allow 100 or 200 now, for instance?

PabloImpallari

As discussed on the OFF standards list recently, the MS mechanism currently lacks a reliable mechanism to identify size-specific fonts within larger, more complex family arrangements. This was also discussed during the OTL developer meeting at Seattle in April, and the assumption is that some kind of name identifier will need to be added to work with the new OS/2 size data.

That's what I asked here: http://typedrawers.com/discussion/comment/6252/#Comment_6252

Nick Shinn

Consider me wilfully ignorant, this is all a bit too technical for me at the moment.

Georg Seifert

This should probably be a different topic, but it does tie into the Microsoft specs discussion. Weight - at one time the MS specs only allowed weights above 250. Has that changed? Do they allow 100 or 200 now, for instance?

I think they always allowed values below 250 but would force bold it a bit to "keep thin strokes legible"...