Optical sizes in OT

sondre m's picture

So, this might have been discussed before, or it might be really far out there, but I thought about it and thought I'd get some input.

In the era of metal type different sizes had different qualities. Especially didot-faces were adjusted between sizes, something that poses some difficulties using digital didot amongst sizes. When Monokrom launched their foundry, their catalogue had both Satyr and Faunus, which is the same face made for different uses. Text size and medium size. Would this be possible to implement in a font technology? Or would it just be a huge pain in the ass for type designers, not worth it, technically impossible etc? I'm talking about an automated process where the form of the font would adjust to the size set in the software. So, if I chose satyr in 10/12pt it would display as satyr and if I increased the size to 18/20 it would switch to what Monokrom calls faunus?

Just a thought ;)

https://monokrom.no/catalogue

John Nolan's picture

Absolutely; it was done in some multiple master fonts, and optical sizes are still supported in InDesign as far as I know (I'm sure I'll be corrected if I'm wrong!), see here.

Or Google "Multiple Master optical size axis."

hrant's picture

Also, some people (like the Kingsley boys before they called it quits*, and Vincent Connare) have actually used hinting to that effect!

* See end of: http://www.myfonts.com/foundry/Kingsley_ATF/

hhp

ralf h.'s picture

Would this be possible to implement in a font technology?

It already is. There is an OpenType feature called SIZE that is supposed to select a font from a family based on the type size.

So, if I chose satyr in 10/12pt it would display as satyr and if I increased the size to 18/20 it would switch to what Monokrom calls faunus?

This describes, why the SIZE feature never caught on. There is little advantage for word processing and layout apps, where people make many conscious decisions about the typeface and their appearance anyway. Why not let them make that choice? It saves one click. So what? It might even lead to results the user doesn't want or doesn't expect.

Such features might make more use when text is displayed on electronic devices in various formats and sizes. But there it is also already possible. On my blog I use a display typeface for headlines, but when the size of the screen is small (like on mobile phones) I use CSS media queries to replace the display font with a more robust typeface. Same idea. But doesn't need the SIZE feature or any other new technology.

John Hudson's picture

The existing OpenType 'size' feature is a hack, and its no surprise that after fifteen years there is still almost no software that supports it. It involves co-opting the data structure of the GPOS table to store non-GPOS data about intended size range of a font. It requires a layout engine to access this odd GPOS feature prior to font selection; whereas normally GPOS features are the last things applied in layout. Everyone I've spoken to at Microsoft and Adobe agrees that this feature is a non-starter; what I've yet to get them to agree on is what should replace it.

Jack B. Nimblest Jr.'s picture

Hrant: " ...some people (like the Kingsley boys before they called it quits*, and Vincent Connare) have actually used hinting to that effect!"

Not likely. TT has no provision for using points in calculations, as in, "this is 9 point so do something special." We, and others make assumptions based on pixels per em, but 18 of them could be 6 pt, 12 pt or 18 and the hints would never know.

hrant's picture

Why not let them make that choice?

Ralf, I'm not sure if you're for or against the idea, but: to me you don't want a reader determining too many things for the same reason you don't want a driver determining things like cylinder firing order - they're not trained to know what would go wrong. And they don't really want to know. There's very much such a thing as freedom from choice!

David: Maybe that's why it didn't catch on... But I do remember having discussions about that (with Vincent participating) on Typophile. Let me try to track it down.

hhp

ralf h.'s picture

I'm not sure if you're for or against the idea

Depends. When a family has display and body styles, the user can just select them. I don't see much benefit in automating this step. In the same way as I don't expect my app to automatically switch to old-style figures in copy text and tabular figures when I type in a table. These kind of automatic changes would probably be more confusing than helpful.
On the other hand: When I think of the Adobe type families where different weights & widths are multiplied with up to 4 optical sizes, then this can create simply too much choice for the regular font user. Here an automatic style change or maybe simply a different style menu could help. But then again, such type families are so rare, I don't think it’s worth to push such possibilities just for a few font families.

hrant's picture

Indeed it depends. For example to me it actually makes sense to automate the selection of a display versus a text cut of a typeface, for most people; but for "power users" (usually graphic designers well versed in typography) let them deviate from the default method (or even change the default behavior). Also, I would say there are changes that are subtle enough (such as an increase in stroke contrast for a display cut) to be worth quietly automating, versus more structural changes (like OS versus lining numerals) that are indeed risky to automate.

hhp

oldnick's picture

to me it actually makes sense to automate the selection of a display versus text cuts of a typeface

The problem with idiot-proofing any process is that American culture seems to have a uncanny ability to build bigger and better idiots…

Jack B. Nimblest Jr.'s picture

Clearly.

As for automating the selection of size masters within a family, I think it should also be made clear that most font families released with discrete size masters, are a compromise subset of a font that contains, or contained, indiscreet outlines, gx variations, plain matching masters, multiple masters, whatever was used to capture a range of sizes, widths, weights or contrasts.

Font publishers like myself would rather not publish a font for each and every point size, weight, width or PX size to satisfy the needs of e.g. print or responsive media. and, i think apps and font formats won't make way. Understanding all the intelligence in and around the use of a size range of typecases is simply too much for modern engineering.

sondre m's picture

On the subject of choice and automating, I was thinking to implement the design of the type designer as intended, like the variation of metal type between sizes. I guess it could be implemented as a manual alternative set in OT. But, the question, would it be "worth the hours"? Would it be viable?

George Thomas's picture

But I do remember having discussions about that (with Vincent participating) on Typophile. Let me try to track it down.

Hrant, please don't forget to try and find that discussion. It is something I'm very interested in.

Thanks.

jasonc's picture

@bbg: certainly any hinting decisions are based on ppm, not pt, but I don't see that as an issue, it's probably a better determiner than pt size.
Obviously thing like shrinking serifs to nil below certain sizes is easily done.
But beyond that, it's technically possible to include 2 sets of outlines in each glyph and let the hints choose which one to use based on ppm size. However it's a lot of work, writing the functions to do that. And more to the point, it's not valuable nowadays as many OS's would throw away your hints.

hrant's picture

Ah, I think I remember now what the problem was with using hinting to emulate optical scaling: when you zoom in/out, the text reflows! :-/

George, I'm not sure this is it - I don't have time to re-read the whole thing right now.
http://typophile.com/node/18814
But there might be more anyway.

hhp

Jack B. Nimblest Jr.'s picture

Vinny said: "MPPEM[] returns the PPEM
the instruction for PointSize doesn't work and is useless since size is dependant on resolution."

Scaling, sizing and zooming, three different things historically, are merged today.

Nick Shinn's picture

This idea makes sense where the typographer would like to maintain an even thickness of stem (for monoline or sans faces) or serif, at different sizes.

I could have built it into Scotch Modern, where I designed the 18 pt, 10 pt and 7 pt of Display, Regular, and Micro to relate to one another that way, but I didn’t know how to implement it and I don’t think it’s a style of setting type that very many people are interested in.

Theunis de Jong's picture

TeX uses "optical sizes", and it attempts to make it resolution-independent by asking the user to input a scale factor. Something complicated, such as "give me 10pt size characters, for an intended output of 125%".
That can never work with fonts alone -- the rasterizer needs not only know the pixel size but also the intended "output" size -- the Zoom factor. And on top of that an optional output scale as well.

Nick, your equalized stem widths for different font sizes sounds really great, but indeed there is (at current) no way to have software decide what size to use.

Jack B. Nimblest Jr.'s picture

"...typographer would like to maintain an even thickness of stem"

..constant thickness of serif, I think. Whether there is contrast or evenness in the color resulting from stems, I think it's the contrasting serifs and hairlines of each size one is tempting the reader into believing in.

Nick Shinn's picture

Yes, I didn’t say what I meant.
I meant even thickness of serifs.

Syndicate content Syndicate content