Typophile

Fonts with variable metrics

blank

Has anyone ever created or proposed a font format that allows metrics to vary with size? For example, a face might need more interletter spacing at small sizes and less at large sizes. So why not create a font that automatically increases or decreases interletter spacing by a set percentage as it changes from the default? Specific kerns could even be set to only activate above or below certain sizes.

Thoughts?

You could include this when using the OpenType feature “size”:
http://www.microsoft.com/typography/otspec/features_pt.htm#size

But I don’t think it would be a good idea. The spacing isn’t just based on the size alone. It may also be based on the reading distance, text color, background color/material and so on. So it is really something the user has to choose. I guess people might even be annoyed if the font would apply such changes automatically.

James, you must be pretty new to digital type!

Precisely what you describe has already been available, and been implemented, and been abandoned.

Basically, from 1990 to 2000, Adobe had a lot of Multiple Master fonts with optical axes that did just that. This development was spearheaded by Sumner Stone. Each font with an optical axis had size variation from 6 to 72 points. Spacing changed according to type size. In the mid-90s, one of the PC versions of Microsoft Word automatically selected the right optical size to use when it detected a multiple master font. If I recall, much later, one of the early editions of InDesign could accomplish the same trick, though clumsily. Microsoft’s implementation was invisible — I think I must have been almost the only person outside Microsoft who knew this was happening, and I publicized it wherever I could, but it wasn’t considered of overwhelming interest by anyone.

Quark was on the verge of doing some great things with MM when Adobe pulled the plug around 2000. Nobody really knows why Adobe pulled the plug. We used to blame it on Microsoft, but I now accept Microsoft’s verdict that it was Adobe, in particular Dan Mills, who made the decision. Dan Mills was later fired — whether for this typographical treachery or for something else, I have no idea.

Apple had a superior version of the technology called Variations but if I recall correctly, none of the released Variations fonts (of which Matthew Carter’s Skia was the most famous) had an optical axis.

MM survives as a vital part of Acrobat and all its derivative products. (You will find two multiple master versions of Times and Helvetica — with invisible attributes — in every copy of Mac OS X - - they are supposed to work with Preview.)

MM also survives as a vital part of the design process, thanks to the fabulous work done by Yuri Yarmola with Fontlab.

MM optical axes had design change from 6 to 72 points. But there was never any reason why you couldn’t leave the design the same at each end, and simply use the axis to change spacing, just as you suggest.

Oh, the dreadful, painful history you have missed! How I truly envy you!

By the way, PageMaker had a great feature that would automatically apply tracking according to size - - this is not an ideal situation at all, but it often worked better than nothing - - much, much better — and it isn’t at all analogous to what was happening with MM.

By the way, MM still works perfectly well with all versions of Windows including Vista - - simply install ATM Deluxe for NT and disable UAC. Try it - - you’ll like it!

One problem with MM is the crazy nomenclature and lack of interactive control in programs. Only one program ever supplied up-front interactive slider bars without the confusing gobbledygook - - LightningDraw GX on the Mac. Had that feature been implemented in all layout and WP programs, everyone in the world would happily be using MM fonts today.

It’s an unfair world out there!

Be that as it may, many, including some at Adobe, predict that MM in some form will be with us again - - sometime within the next 5, 10 or 20 years, depending on whom you’re talking to.

PS. MM also did light to bold, compressed to wide, serif to flare to sans serif, etc. etc. - - and Lucas de Groot had a special MM font that did something vaguely pornographic - - I’m not making this up! I’ve never seen that font. Lucas offered me his entire library as a present when I got him a special beta copy of FontStudio that would work with PPC Macs - - and foolishly, I declined. I also gave that version of FontStudio to Carol Twombly, who really wanted it. She didn’t offer me anything in return.

PPS. Ralf is absolutely right - - the totality spacing can’t be based on size alone. But spacing carefully optimized to size is a very good starting point. And you do need a starting point. If you didn’t have one, you wouldn’t be able to space a font at all.

I don’t think it was uncommon for a hinted TrueType font to use hinted widths at small sizes. I believe Microsoft Sans Serif is wider at 8pt (96dpi) than it is at 9pt due to 8pt have hinted widths.

Quark’s tracking table Xtension has been doing this since 1989 (version 2.1).
Typically, if using a face throughout a publication, one would set the table to decrease tracking the larger the type size became.
I don’t recall ever adding tracking for small sizes.

As Ralf notes, probably best to have it in the application, rather than the font.
Also, the user can kern display and text versions of a type differently with the XPress Kern Table Editor.

”...a font format that allows metrics to vary with size”
Hot metal did this. The Merganthaler VIP typesetter did this. MM could do this. TrueType GX Variations too. All the current font formats allow any single outline to do it, so a collection of outlines can too.

PageMaker and QuarkExpress allowed the user to define a table of a track-per-size, per outline. These work on a single outline with a value for each size. As long as the single outline master is still applicable to the range of size/track pairs used, somewhat fine!

”...a hinted TrueType font to use hinted widths at small sizes...”
As this depends on the presence of a course grid, at which point the technique is most often being used for readability survival rather than as a refinement to spacing, it is really not a point to make.

”...the OpenType feature “size”...”
is static, i.e. one label per font, it’s not related to anything of the dynamic issue being discussed.

It would be great to have a truely dynamic version like GX Variations offered, but waaaaaay too many “type people” (lol) appear scared of this. It would bring out the cream of the crop in type design and use, and leave the janitorial type type people, (who must keep things understandable for themselves, or else!), in the dark at the back of the pack. Thus, since the janitorial type type people seem favored and rising for their lack of interest in granting type type intelligence, their lack of vision, and even of hearing, it’s unlikely to happen in any of the “big” typesetting systems, much less in a standard. . . ever, or until the next generation of typographic janitors arrives. ;)

Cheers!

David,

Is it possible to ammend or extend the OpenType specification (and MS Volt) to support a different character width per point size, or at least to substitute a different character width when a typeface’s point size is greater than a certain number?

Or must we we wait for yet another typeface specification, like OpenType II, to have this?

===

I know that in Latin languages, this is useful for the M and N in the very least, and in Hebrew for the Shin in the very least; I’m certain that in other character sets this is needed as well.

At Lintotype of Hauppauge’s Type Department, I was shown print samples of metal type typeface designs that had different character widths and slightly different designs at different point sizes. When I created a set of Linotype-like Hebrew type designs for the standard FrankReuhl typeface design, I inspected print samples of that typeface design at different point sizes. I found that each letter form had interesting design differences, created to be used at different point sizes.

Hence, it is clear then this is an essential feature of a typeface design, and something that should not be lost for convenience sake. Variable character widths and designs that are point specific should be incorporated into this or the next typeface standard like OpenType.

R.H.”...the OpenType feature “size”...”
D.B.: is static, i.e. one label per font, ...

And so it could be used to automatically switch between fonts with different designs and/or metrics depending on the used size.

D.B.: ... it’s not related to anything of the dynamic issue being discussed.

And I must ask you a second time: Why do you think you can define the scope of a discussion you haven’t started? My answer might be useful to James or any other reader. Let them decide and please stop always trying to prove my or other other peoples statements wrong. It’s not helpful.

There are three issues here:

1. The increase or decrease of spacing between the letters, known as tracking;

2. The widths of a character’s design;

3. The actual design of the letter.

The first factor, a typeface’s tracking, affects all the letters of a typeface across the board equally.

The second factor only affects the widths of those letters which the designer intends to be different at different point sizes.

The third factor only affects the design shapes of those letters which the designer intends to be different at different point sizes.

For example, if I was typesetting the phrase “time in a bottle”, and I created a typeface with these variable widths, then at very small type sizes, the shape of the “m” (and perhaps “n”) would have the horizontal strokes spaced further apart to increase its legibility and prevents ink spread on certain paper kinds, and the kerning between the two “t”s and the “l” of “bottle” (in kerning, there is no end, so I will not cite the other combinations where this would be helpful) needs also to be increased.

At large type sizes, I might seek the opposite to occur: the strokes of the “m” should be closer together to minimize the unnecessary while space. Similarly, the extra space between the letters “t” and “t”, and “t” and “l”, would be decreased. Perhaps, I would make a three letter ligature with equal distances between the horizontal strokes of the t, t, and l, and join the first two letters, but not the “t” and “l”.

Ralf Herrmann,

> You could include this when using the OpenType feature “size”:
http://www.microsoft.com/typography/otspec/features_pt.htm#size

Does this mean that the character’s width(s) are changed in a different point size range (like from 13.9 until 24 as in the Microsoft example), or only the design shapes?

Has Microsoft implemented this feature in its MS Volt software?

>it is really not a point to make.

Please accept my humble apologies for mentioning it.

Does this mean that the character’s width(s) are changed in a different point size range (like from 13.9 until 24 as in the Microsoft example), or only the design shapes?

The “size” feature basically tells an application which font file to use for any specified point size range, so the changes are not limited to any characteristic.

The only application that can take advantage of this feature that I know of is XeTeX.

I asked my OpenType/Volt expert who confirmed that “size” is not a [direct] way to handle variable widths in a font.

Perhaps, Simon Daniels of Microsoft can confirm that OpenType is flexible font format that allows new features to be added to it, such as variable character widths.

It would seem logical that if “size” can determine a point size range for tracking, then seemingly it can then input information to another unyet created or named operative that could change a character’s width based upon its point size.

Maybe, in the next main release of OpenType by Adobe/Microsoft the feature of variable character widths will be implemented.

Certainly, implementation of this feature is vital to OpenType, because digital type would then include an important feature of metal type.

What do you think, Thomas Pinney? At RIT, wasn’t that an area of your study?

> Nobody really knows why Adobe pulled the plug [on MM fonts]

I talked about it at great length in a presentation at ATypI. I’ve written about it in public as well. You may choose to not believe the explanations I’ve given, but to simply say “nobody really knows” is a bit odd. Certainly those of us who were here at Adobe when the decision was made to not support MM in OpenType are pretty familiar with the issue.

I was not thrilled at the time with the decision not to support MM functionality in OpenType, but I understood the many pragmatic factors that went into it. These days a decision like that today would be made by me and David Lemon, but if somehow we could wind back the clock, I couldn’t tell you which way we’d go on that one.

> Dan Mills was later fired

Not at all true. He retired to spend more time with his family.

Cheers,

T

Thomas,

> I was not thrilled at the time with the decision not to support MM functionality in OpenType, but I understood the many pragmatic factors that went into it.

Can you elaborate upon the “many pragmatic factors”?

Perhaps, if convincing counter-arguments can be suggested, the clock can in deed be turned back, and David Lemon and you might conclude differently.

With a religious note, we are in the final Hebrew month, called “Elul”, the traditional time of ’teshuva’ (lit. return, or popularly known in English as ’repentance’), when we turn back the clocks and resolve that next year will be different. “Teshuva” is so powerful that it not only affects ones future, it can even change the past.

Cheers!

BTroop: Dan Mills was later fired
TPhinney: Not at all true. He retired to spend more time with his family.
Me: That’s what I heard from him too. I’m curious though, as to whether he finished it and if Adobe is planning to publish it any time soon? ;)

RHerrmann: And I must ask you a second time: Why do you think you can define the scope of a discussion you haven’t started?
Me: Defining the scope of discussion here, in general, is quite impossible, and topic “ownership” is fleeting. Stop asking and perhaps you will stop being disappointed.
RHerrmann: You could (use the “size” feature)... But I don’t think it would be a good idea.
Me: What makes you think you can give an answer, then say it’s not a good idea, and then complain when I fully agree?

ISeldowitz: ...must we [] wait for yet another typeface specification, like OpenType II, to have this?
Me: Good question! I can only hope. Like most standard standard developments, the current one is the translation of 10-20 years of technology into “education.” Unlike most standard standard topics, the education in this topic is well ahead of the technology.

Cheers!

One of the misapprehensions here is that tracking can ever be a substitute for variable metrics. It can’t. As you go up and down the size scale, different letters will be spaced proportionately differently. At 6 points you might need proportionately more spacing around l shapes and less around o shapes — or vice versa. It depends on numerous factors. Tracking is only the crudest possible solution.

I love it that there is someone here who genuinely believes that fired people really just left to spend more time with ... their families. Who am I to be cynical?

Meantime, MM still works.

It’s painful to hear David break taboo about the janitorial class in type. I would like to say that I don’t have anything against janitors, and never have had. Love ’em.

So here’s the thing...

You have text at a specific size and you want it to be as non-poo-like as possible. The ’possible’ part may be constrained by non-typographic considerations — resources and time, technological limitations — compromising typographic quality. If there are no constraints, then the obvious way to make non-poo size-x text is to have a dedicated size-x font with appropriately designed outlines, spacing, kerning etc. Let’s be clear that this is the proper solution and anything else is a compromise. Interpolation is a compromise. Tracking is a compromise. Variant metrics is a compromise. The compromises are on a continuum between poo and non-poo. As Bill points out, variant metrics would be better than tracking: it would be further from poo, closer to non-poo.

But the compromises are subject to the same non-typographic considerations and constraints as the ideal: resources and time and technological limitations. The closer the compromises get to non-poo — i.e. the fewer typographic compromises they entail — the more resources and time they are likely to require, and eventually they become essentially indistinguishable, in terms of cost, from the ideal, non-poo solution. At that point, such compromises simply are not worth spending time on: better to spend one’s time making those size-x specific fonts. On the other end of the scale, there are compromises that are so close to poo that they, too, are not worth spending time on. We don’t want to be in the business of making almost-poo.

The question then, is whether there are in fact compromises somewhere in the middle of the continuum that are sufficiently non-poo-like to be worth doing and sufficiently cheap, in terms of resources and time to be viable. And I’m not convinced that the answer is yes, although if I had to pick a technology that came close it would be TT variations.

Basically, I’ve come to the conclusion that the compromises are all a waste of resources and time because, ultimately, the results are not satisfying, and in order to become more satisfying they need to become more complex, and will eventually become technically more complex than making size-x specific fonts would be. We’ll know we’ve reached this point when designers are making size-x specific fonts and then processing them to fit them into the compromise technology. We may already have reached this point.

The answer is not new font formats or extensions of font formats. The answer is font development tools that make it viable for designers to produce size-x specific fonts, i.e. that reduce the cost in resources and time of doing it properly. Letterror’s Superpolator and Tim Ahren’s RMX tools strike me as the most significant advances.

Captured from web.archive.org on 1 Dec 2008. view this capture