back to

Opentype and Optical Size: will it blend?

February 21st, 2009 by Noam Berg

One of my goals for the Cristoffel typeface is to have it be able to adjust its optical size automatically. Lately I’ve been trying to figure out how to make this work.The basic idea is as follows:

When fonts were boxes full of metal type, each size was designed individually, and the designer would make subtle changes to the relative weight of the characters where needed. Larger display sizes would be thinned out a bit, and small text sizes would be thickened up. That’s the basic idea behind optical size. When Photocomposition machines came along, different sizes were derived from the same film negative. One outline, scaled up and down. All the subtlety of optical size went right out the window.

Digital fonts follow the same mechanic: one outline scales up and down to achieve different point sizes. the plus side is that you can have any damn point size you please. The downside, again, is that there is no optical compensation. nowadays many foundries are releasing their workhorse text faces in several optical variations, each one covering a range of point sizes. This is certainly a step in the right direction, but it requires a designer to knowingly specify the right font in the family for the text they’re using.

Optical Size Illustration

I would like for Christoffel to have a series of optical alternates for each character in the set, and for them to be substituted automatically depending on the current point size being used. There are two main challenges here, the first being how to encode this information into the OpenType code. the second is how to ensure this code can be used by applications. OpenType features depend on applications that can recognize and execute their features.

The good news is that the OpenType specs include a “size” tag. From the spec:

Function: This feature stores two kinds of information about the optical size of the font: design size (the point size for which the font is optimized) and size range (the range of point sizes which the font can serve well), as well as other information which helps applications use the size range. The design size is useful for determining proper tracking behavior. The size range is useful in families which have fonts covering several ranges. Additional values serve to identify the set of fonts which share related size ranges, and to identify their shared name. Note that sizes refer to nominal final output size, and are independent of viewing magnification or resolution.

Example: The size information in Bell Centennial is [60 0 0 0 0]. This tells an application that the fontâs design size is six points, so larger sizes may need proportionate reduction in default inter-glyph spacing. The size information in Minion Pro Semibold Condensed Subhead is [180 3 257 139 240]. These values tell an application that:

  • The font’s design size is 18 points;
  • This font is part of a subfamily of fonts that differ only by the size range which each covers, and which share the arbitrary identifier number 3;
  • ID 257 in the name table is the suggested menu name for this subfamily. In this case, the string at name ID 257 is Semibold Condensed;
  • This font is the recommended choice from sizes greater than 13.9-point up through 24-points.

Application interface: When the user specifies a size, the application checks for a size feature in the active font. If none is found, the application follows its default behavior. If one is found, the application follows the specified offset to retrieve the five values.

the bad news is that it’s a very obscure tag that isn’t really in use.A thread on Typophile mentions XeTeX as the only app that’s ever implemented the size tag. Here’s what Yannis Haralambous has to say about the size tag in O’Reilly’s Fonts and Encodings:

this feature is a notorious hack to enter information on optical size into a font. Adobe asks us to include this feature in a GPOS table, but without associating it with any lookup. This table contains the optical size and perhaps also the ranges of optical sizes at which the font may be used. (p.818)

The size aims to make up for an enormous shortcoming in PostScript (other than MultipleMaster, with their “optical size” axis) and TrueType fonts, which is that they completely disregard the optical size: there are, infact, fonts named Times New Roman Seven, Times Ten, and ITC Bodoni Seventy-Two, but the fact that their optical sizes are, respectively, 7, 10, and 72 appears only in their respective names,5 nowhere in the fonts themselves. The syntax for size is as follows:We use the keyword parameters followed by four numbers. The first is the font’s optical size, expressed in tenths of a point. The second is for fonts issued in multiple optical sizes; we can say that they belong to a family and that the members of this family are numbered sequentially, starting at 0. Finally, the two remaining numbers express the range of optical sizes at which the font can also be used. Let us take, for example, the excellent font ITC Bodoni. It is issued in three optical sizes: 6, 12, 72. We could thus include the following feature in the font for optical size 12:

feature size {
parameters 120 1 90 299 ;

which means that it has an optical size of 12, which is the second member of the family. (p 565)

This means that even if I use it in my fonts, a program like InDesign won’t know how to use them. How then to make this feature functional?

One Idea I had was to try creating a plug-in for Creative Suite that would make text size-sensitive. I know people write plug-ins for Photoshop and Illustrator, but I’ve never tried before and i don’t know what’s involved. I am by no means the world’s best coder, and there isn’t much time for development, especially if I have to learn a new language and API.

The other idea I had along these lines was to create a Firefox extension. Instead of addressing the optical size issue from the designer’s starting point, this takes it directly to the people. On-the-fly interpretation! Or perhaps it can be built right into the next build. Firefox 3 supports automatic kerning and ligatures, so obviously there’s somebody in the Mozilla community who cares about type. Again, this is getting heavily into the coding arena, not my strong suit. Firefox extensions require JavaScript, which scares me a bit.

Oh, and the kicker: what about zooming? As the OpenType spec points out, “Note that sizes refer to nominal final output size, and are independent of viewing magnification or resolution.” What is final output size in a web browser? How to account for individual users’ screen resolutions? What happens when people start zooming in and out? Ultimately, such is the blessing and the curse of mutable type. The designer no longer has complete control over the design. The user can screw up your pristine layout with a single keystroke (ok, maybe holding down shift or something too). Sometimes, you just need to accept that you have no control and get on with life. In the meantime, you do the best you can to ensure your type looks as sharp as you can make it.

Posted in technology, Thesis, Typography

One Response

  1. Zashkaser

    Good to see you’re doing some research to fill in the ???

Leave a Comment

Please note: Comment moderation is enabled and may delay your comment. There is no need to resubmit your comment.

About the Mad Scientist Running this Show

Noam Berg is a graduate Student in the Design and Technology MFA program at Parsons School for Design in New York City. He is also the (debatably) creative force behind Exfish Studio. Noam is obsessed with old vacuum tubes, type design, computers, guitars and comic books. Noam likes Thai sweet chili sauce, hats, suits & ties, Wacom tablets, Japanese green tea (with the toasted rice), nerdy science girls, many varieties of music, SLR cameras, AnarchoJudaism, lithography and pocket watches. Noam's not a big fan of cell phones, the cool kids, ugly and over-used fonts (you know who you are!) and talking about himself in the third person. Seriously, this is really weird. I'm gonna stop doing it now.