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.
Comments
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.
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?
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.
"'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.
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.
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.
usLowerPointSize
andusUpperPointSize
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?
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.
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).
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.
"...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.
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.
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?
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.
_________
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
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."
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.