More and more applications seem to be capable of using the OpenType ›size‹ feature

Which ones?

FontLab, for example, will let me add and save it as part of the .vfb file, but loses it when generating the actual OT file.

How do you check that?

{To Follow}

> Which ones?

LuaTeX; XeTeX; FontForge (as I just found out); probably Adobe's products (haven't used them in a while). Lua and Xe, to be precise, aren't doing anything entirely new in the TeX world (as TeX has been selecting the correct optical size automatically for about 30 years now), but they now do the same with OpenType fonts out of the box -- provided the ›size‹ feature is present. Otherwise fonts have to be assigned to sizes manually. So for, say, Minion Pro Opticals, something like this...

\documentclass{scrartcl}
\usepackage{fontspec}
\setmainfont{Minion Pro}
\begin{document}
\tiny hat einer und gemacht
\normalsize zu werden um
\huge von Buch wollen
\end{document}


...would result in Minion's different size variants to be selected automatically for different sizes.

As for FontForge, I just learned it has a dedicated ›size‹ tab asking for the relevant information, and apparently stores it correctly, too -- which solved my problem for now.

> How do you check that?

using otfinfo, which reported »no valid 'size' feature data in the 'size' feature«. After the FontForge treatment, things seem to be okay, though.

The size feature doesn’t seem to be a good idea.

Surely it’s up to the typographer to decide which cut of a typeface is right for a particular setting, rather than have that decision made by the font.

For instance, if a typeface is being printed on coarse paper, reversed, or with low contrast between foreground and background colours, then a smaller “optical” size would be called for. But how is a font to know what stock it is being printed on, and in what colour?

A good typographer should be able to over-ride it, but:
- The font doing the job -or even coming close- on its own saves time.
- Sadly most typographers are not as good as the font could be.

hhp

Adobe apps don't support the 'size' feature, although AFDKO does and Adobe implement the feature in their fonts.

I've long argued -- with some traction at both Microsoft and Adobe, I believe -- that as a mechanism the OTL 'size' feature is a bad idea: it's really a hack of the GPOS data structure to affect font selection. A number of better ideas are kicking around, and I'm hopeful that one of them will be selected for the standards process.

"Surely it’s up to the typographer to decide which cut of a typeface is right for a particular setting,..."

Not nessesarily. What if "the typographer" is at lunch, or asleep, or there isn't one, or never was, at the very moment of scaling to the output. Fairly common, I think, 'specially on the web, ya know... the end user is quite often the typographer.

This has been obvious for near twenty years. The standards have failed and any foundry needing to operate their fonts without shipping, or offering the services of a live typograpler... has the font name.

And don't call me Surely.

What kind of standard are you in favour of David?
What benchmark can I use for determining the renderability ranges of the fonts I manufacture?

Nick, except when the fonts get "rounded down" to the current standards, I'm not in favor of standards outside of FB's until/unless we ever have to "round up", in which case FB'd move formats again to higher ground. I'm not at all hopeful of dramatic change in either the standards or compliance to them. Don't forget, a lot of work was needed to get to the lowest common denominator of font functionality we have today, and thems serious efforts you just can't undo.

As for benchmarks, the type designer making such fundamental decisions about the appearance of typography is tricky. When I class size for the Font Bureau library going to the web, I decide based on the unhinted appearance of the fonts on windows. Determining what we call 7 pt, or "bold", or the default figures, that was all fine while the world was stuck with books and print, but now that the world is struck with screens and CSS...