Although the OT 'size' feature is implemented in an odd way in terms of where the data goes in the font, this does not bother me so much.

What *does* bother me is that the 'size' feature deals strictly with point size, and not pixel resolution. In a world where the most important use of optical size is on screen, this is problematic. If one wants something for use at text sizes on an unspecified "average" screen of today, a design optimized for perhaps 6-8 points in print is likely to be a better choice than one optimized for 10-12 points in print, even if the screen size nominally matches 10 or 12 points.

Ideally one would be able to express in the font family some sort of function using a combination of ppem size (number of pixels high the font is at the current sizing) and resolution of the user's screen to determine which distinct optical-size font to use.

For so-called pixel fonts, a type designer would want to be able to express things purely in terms of ppem size.

Failing all that, for a web browser to have an automatic function like "take the current ppem x2/3 and look for a font optimized for that point size" would be better than nothing.

Regards,

T

related threads here on Typophile and on the www-fonts list

Everything Thomas said, and then...

The OT size feature is nominally a GPOS layout feature, despite the fact that is does not perform any glyph positioning function. It also does not conform to any of the normal characteristics of a GPOS feature. It also requires implementing software to process this feature outside of the normal chain of OT Layout processing.

Given this, it is hard for me to see it as anything but a hack enshrined within the OTL feature descriptions. The fact that not even Adobe, who defined the feature and implement it in their optical master fonts, have implemented support for it in any of their applications suggests that it is not only a hack but even fails the typical justification of a hack: that it is useful.

The normal processing order for OTL is cmap then GSUB then GPOS: first you get the default glyphs for the characters, then you substitute other glyphs as appropriate to GSUB features, then you apply positioning to those glyphs. The 'size' feature needs to be processed completely outside this chain, despite being nominally a GPOS feature. The 'size' feature actually needs to be applied prior to any glyph layout processing, since it affects font selection.

I believe this is one of the reasons why the feature isn't supported in applications: many implementers struggle to get normal GSUB and GPOS layout right -- given the absence of a clear OTL implementation spec, as distinct from the font format spec --, and it is no wonder that they have simply ignored this eccentric 'size' feature.

Also, in order to build 'size' feature data into a font, one needs to use an Adobe FDK-based tool for OpenType Layout tables. A tool such as VOLT, used by pretty much everyone making fonts for complex scripts, which is based around the normal structures of GPOS lookups, has no way to build a 'size' feature. Since it is not currently possible to mix-and-match tools for GSUB and GPOS development, this contributes to poor support for the 'size' feature on the font side as well as the application side.
_____

A couple of ideas have been put forward for better methods of implementing size-specific font selection.

One idea is a new SIZE table in the font. At its simplest, this could present the same information as the 'size' feature but in a more appropriate location and with better implementation guidelines. David Berlow drafted a description of a more complex SIZE table during the OT 1.6 discussions; this sought to address more complication font family relationships including ppem-specific designs. I'm not sure how this relates to his new permissions and recommendations table idea, or whether some of the concepts in the SIZE table proposal have now found their way into the new table.

A second idea is to use the new composite font format (currently under development as an mpeg-OFF standard) to enable multiple size-specific fonts to be packaged as a single virtual font with the composite font XML wrapper including information to enable applications to select the appropriate component font for specific sizes or size ranges. In theory, this could be expressed in point size or ppem size, or some combination (allowing a single component font to be used for one size in print and wysiwyg situations but another for reading on screen).

This last idea brings me back to the web font format discussion. On the W3C list, I suggested that size-specific fonts were orthoganal to the web font format question, which is why I suggested that we continue the discussion over here. My thinking is that this is a font data matter, and hence something that would be within a potential web font wrapper.

The only situation in which I think it at all likely to be otherwise would be if indication of a ppem-specific font were to be included in the .webfont info.xml meta data. But presuming this information is also in the font data in some format, then one runs into the problems of duplication, redundancy and potentially differing data for the same font.

Finally, there is the point that Karsten alluded to on the W3C list: as real resolutions of screens increase, text at pixel-specific sizes gets smaller. In order to be able to serve ppem-specific designs that are also of appropriate size for reading, you need to know the resolution of the reader's device. Ideally, you also want to know how far away from the screen the reader is sitting.

Somewhere in here, heads start exploding. I'm still trying to figure out whether David Berlow is the only person who can hold all this stuff in his head, or if his head exploded a long time ago and he just hasn't noticed yet. :)

Somewhere in here, heads start exploding. I’m still trying to figure out whether David Berlow is the only person who can hold all this stuff in his head, or if his head exploded a long time ago and he just hasn’t noticed yet. :)

David's head has clearly exploded. :D

Carrying over something I wrote to the www-font list, with a little addition, this adds to Gustavo's comment rather than the original post:

On the www-font list, Gustavo raised the issue of "size-specific" outline screen fonts -- with a specially designed font per each ppem-size -- which brought up the question how to tell UAs for which ppem-size a font is designed.

I think that first of all one needs to make a fundamental distinction between two types of "specific-ness" that should not be mixed up:

1. size-specific design
The "one outline for all sizes" approach that outline fonts brought with them results in a compromise since one design needs to serve both very small and very large sizes.
Size-specific design refers to special versions of a typeface, each serving a specific range of type sizes -- which are measured in pt, mm, or other. Size-specific-ness belongs to the "higher-level" realm of esthetics/legibility and is agnostic of the "lower-level" realm of this or that rasterization technology, output device, resolution (if rasterized at all).

2. ppem-specific design
In brief, it means designing along the pixel grid. A font per ppem-size.
This approach addresses the "lower-level" realm of rasterization technology, output device, resolution.

Thomas Phinney: "What does bother me is that the 'size' feature deals strictly with point size, and not pixel resolution."

Size-specific design and ppem-specific design serve different purposes and hooking in at different level: esthetics/legibility vs technology. They do not even overlap.
Therefore I think that the information for which ppem-size a font was designed does not belong into the current 'size' feature.
This single ppem-size value per font is still more than just an on/off, so cannot be a single bit in 'head' table's 'flags'.
Perhaps an update OS/2 version with a ppem value appended at the end.
Or a 'ppem' table with a single value in it? Presence of the table signals to the UA that this is a ppem-specific design, and for which ppem-size. Then activate specific behavior. But if, as John suggests, even the current size-specific 'size' feature should be a table rather than a feature, then this may indeed inform if the font is either size-specific or ppem-specific -- in my current understanding, options are none/either/or.
Or of course David Berlow's 'perm' table which has a section "Scaling" with both point- and pixel(=ppem)-related min/optimum/max size entries.

I am sure I have missed something in my considerations.

@johnhudson
"as real resolutions of screens increase, text at pixel-specific sizes gets smaller. In order to be able to serve ppem-specific designs that are also of appropriate size for reading, you need to know the resolution of the reader’s device."

I had a brief discussion with kevlar about this at TypeCon. It goes beyond "resolution" - which is used to refer to both the virtual grid imposed by software AND the "native" resolution of, say, LCD screens which exists physically.
As a developer, I never understood that I could query for the screen resolution and yet be left totally in the dark as to the physical dimensions of the display. Without this knowledge, I fail to see how optical resolution can be set. I also have reservations about Thomas Phinney's "right for a majority of circumstances" approach.
I mean, what the hell good is/was the Plug'n'Play spec if it doesn't supply this info?
My understanding is that display manufacturers are now beginning to supply such info to the OS starting with Win7 and that interest in optical resolution is on the rise.
We shall see.
[Some info for the novice as to the fuzzy mess resulting when these two resolutions are in conflict on LCD screens:
1) Confusion Over Screen Resolution
2) Screen Resolution And Me]
Kevlar tells me the problem I describe fixing in Screen Resolution And Me, goes unfixed among appr. 60% of users.
An incredibly big problem being swept under the rug. Supposedly Win7 addresses the issue.

"Ideally, you also want to know how far away from the screen the reader is sitting."
I believe there's a product that uses a display mounted cam to determine this distance. But the problem of optical size has to be solved before we can refine it in this way and add the additional variable of user-distance.
I would like to be able to specify 1 inch and have it be 1 inch no matter what display is being used.

rich

TP>What *does* bother me is that the ’size’ feature deals strictly with point size, and not pixel resolution. In a world where the most important use of optical size is on screen, this is problematic.

What actually could bother you, if you were me, is that neither point or pixel is a true measure on screen, so that as things stand now, in a craft that was once concerned with the effects of one human breath on the type, type designers seeking remedy for readers must choose only what's closest to useful, point or pixel.

Also, I hear what you are saying, but I don't consider the design of fonts for screen to be optical sizing. I divide font variation into; for style, for size and for device. So, though the style and size heavily influence the decisions (e.g. in the Franky designs), if the coarseness and multiplicity of pixel colors doesn't overwhelm my per-size decisions, (remembering that I'm only talking about the bottom 18-24 sizes or so for Latin, 67 or so for Chinese), the user's preferred choices (of style or weight) might overwhelm my per-size decisions. So, if one must prepare a web font, then pixels, or the concerns of the device (and how I perceive this effect on the user), must lead the way, and the size and style issues should follow in a broad fan of choices suiting the size and style preferences, satisfying all possible css and end-user choices. That is, if you're making web fonts for the bottom end of resolution. (Franky would stylistically represent a feather in the fan, but not the way I done drawd and engineared that particular feather, I'd hope.)

JH>I’m not sure how this relates to his new permissions and recommendations table idea, or whether some of the concepts in the SIZE table proposal have now found their way into the new table.

The size table would be used to inform the recommendations after permissions define the possible uses. Remember that this is not just conceived for the web; permissions can query the size, or other tables to inform recommendations for print, sky-writing or film-making. It all depends on how cooperative composition agents and devices want to be, versus how cooperatively the incoming user market wants these same agents and devices to be. On the web, of course, it's harder because of the dynamic natures of the media and users, and made nearly impossible by the creeping and various description languages that live there. But it's not impossible if one considers all the things a type designer can do, and if doing those things impresses people enough, maybe they'll listen, and the web will move more considerately, and thus considerably on type and typography.

This reminds me, that some large number of people have told me that actual everyday web users do not want to do anything, not even change the font size, they just want the site to show up all nice so they they can read it, wherever, and whatever. If I was your average web designer, which means I have absolutely few typographic skills whatsoever, I'd be wondering where I am too. ;)

CS>David’s head has clearly exploded. :D

You obviously didn't start Chinese web type sensitivity training in 2004, did you? Start thinking about Chinese ClearType web fonts for 2 seconds a day, and square those seconds each month. Then, after a few years, Latin web fonts, according to any scaler, won't make your head explode, clearly or otherwise, which is more likely, surely. :E

JH>A second idea is to use the new composite font format (currently under development as an mpeg-OFF standard) to enable multiple size-specific fonts to be packaged as a single virtual font

And yet a first idea would be to use the existing var tables which are perfectly-suited for just exactly this problem, multiple size-specific fonts to be packaged as a single virtual font. Is the public asking for GX-like Variations yet or what, John? They never will, it's up to 'us' to figure it out and get it served so they never do.

KL>Size-specific design and ppem-specific design serve different purposes and hooking in at different level: esthetics/legibility vs technology. They do not even overlap.

I guess I'm going to have to remove overlap surgically then. I hope not to turn you all into Spinal Tap drummers by September 1st, but I told you so.

Cheers!

I think if systems (Oses) could more reliably convey what ppem they are really displaying with, we'd have a much more useful foundation to deal with optical size on screen... but I hear you David. One thing you might or might not have mentioned is the style of screen rendering. The well-known, opposing camps -- Windows crispness versus Mac smoothness -- would quite possibly prefer different designs for those two styles, all other technical aspects (ppem, etc.) being equal.

David: And yet a first idea would be to use the existing var tables which are perfectly-suited for just exactly this problem, multiple size-specific fonts to be packaged as a single virtual font. Is the public asking for GX-like Variations yet or what, John? They never will, it’s up to ’us’ to figure it out and get it served so they never do.

If size-specific glyph variants are all in the same font -- as I understand the case would be using GX-like variations --, then size could be handled as GSUB substitutions, which would the addded benefit that it would plug easily into existing OTL implementations and not require any parsing of any new table. Or is it the axes aspect of GX variations that you are thinking about?

But such an approach also means completely rebuilding all the size-specific fonts that various type designers have been making for the past twenty years, rather than just adding some size meta data that identifies at which sizes these existing fonts should be used. With the composite font approach, intelligent users could create their own virtual fonts of size-specific designs, opt to follow foundry recommendations or not, and even make separate composite fonts using the same design for different sizes depending on purpose.

DB -- [...] I don't consider the design of fonts for screen to be optical sizing. I divide font variation into; for style, for size and for device. [...] So, if one must prepare a web font, then pixels, or the concerns of the device [...], must lead the way, and the size and style issues should follow in a broad fan of choices suiting the size and style preferences [...] That is, if you’re making web fonts for the bottom end of resolution.

Despite "overlap" was the wrong term ... Do we disagree? Your "for size" is my "size-specific", your "for device" is my "ppem-specific". With fonts made "for the bottom end of resolution", the "for size" category evaporates -- it's hard to make serifs a bit fatter for smaller sizes if a pixel more would constitute another style, e.g. a bold. So effectively one ends up, "for style", with a bunch of fonts, some (or none) of them with "for size" flag and others (or none) with "for device" flag. If there is none for both categories, there is one "size"/"device"-independent "for style" font.

So based on
a) screen resolution given as 144ppem (not as 1024*768 pixel count) and
b) desired type size (like 12pt, i.e. resolution-independent)
the rasterizer could determine which font ppem-size is required and then
1) check if the according "for device" font variation "for [requested] style" is present and if yes, use it,
2) else check if the according "for size" font variant "for [requested] style" is present and if yes, use it,
3) else use the present "size"/"device"-agnostic "for style" variant.

(This is a summary of how I understand your description.)

Question is how to package the "for size" and "for device" fonts (which I consider to be sub-categories of "for style") -- I mean: in terms of font naming.

CS>The well-known, opposing camps — Windows crispness versus Mac smoothness — would quite possibly prefer different designs for those two styles...

Absolutely. The OS have expressed their 'preferences' for how dark a given shape should render. Adobe is the darkest, MS is the lightest and Apple is in between leaning towards Adobe. Establishing this in 2007 was job 1, job 1101, was making Franky with "all weights possible." This weight choice takes care of whatever preferences clash in this area between user and web site developer, user and font vendor, or user and OS rendering. Good?

I don't think users should have their text type color decided for them by anyone but themselves, especially when the 'opposing camps' are doing it for reasons divorced nearly entirely from user preferences.

KL>Question is how to package the “for size” and “for device” fonts (which I consider to be sub-categories of “for style”) — I mean: in terms of font naming.

I worship variations so I don't have to name every possible style. I worship the web because it's a place where users can make choices based on appearance alone, and because I don't have to 'deliver' anything.

JH>But such an approach also means completely rebuilding all the size-specific fonts that various type designers have been making for the past twenty years, rather than just adding some size meta data that identifies at which sizes these existing fonts should be used...

Why is it either or? If a font is made for one size, add a little data that indicates it. If a font is made for a lot of sizes, add a lot of data to indicate it. But everything beats the one-size-fits-all outline that can't do so in reality. We rebuilt all the per-size designs into outlines in the 70's and 80's, nobody seemed to mind then. ;)

Cheers!

understand arguments towards having ppem-specific fonts. Goal is to choose font optimal for readability by automatically choosing font based on calculated ppem size. However, there are scenarios where you will have same variation to be displayed at different ppem sizes, even ones it is not intended for.

For example, if you read PDF on various devices you have to display text using font chosen by document creator. Or you are just zooming in document in Word. For dynamic document scenario, many of you are using optical zoom in Safari on iPhone. All these scenarios do not change resolved font while ppem changes, which means choice is ppem-independent. For all these sizes font should be displayed as good as possible.

For me as layout applications developer, it means that this may be better to have different ppem sizes in one physical font, using same glyph index and changing glyph proportions as less as possible. Of course, it places restrictions over how font can achieve this and hinting is the way it is done now.

Of course, font variants can include ppem axis to choose from. But there should be a way to choose ppem-independent variant. This will be application’s choice to use ppem-independent variant if scenario is using fixed layout or optical zoom.

Thanks,
Sergey

>All these scenarios do not change resolved font while ppem changes, which means choice is ppem-independent.

All 'page scaling scenarios' mean choice is ppem-independent, all 'font sizing scenarios' are another thing. Zoom scales pages. Print scales pages. Graphic designers size fonts. Web users size fonts.

If one lumps them together as Serge does, and then says, "all sizes should be displayed as good as possible", well, that's where we've been.

What I did was make what would it look like if "each size would be displayed as well as possible?" Then, I made a list of how to get that to a user. Then, I made a list of who's stopping it. Now, I'm writing a blog on why I think this sad state exists.

Cheers!

I am not very enthusiastic about a GX or GSUB approach with all size/ppem-specific glyph variants inside the same font. I think it would make things more complicated and create problems, for example: How to handle vertical metrics? What about backwards-compatibility? File size? etc.

It might be useful to make a parallel with interpolation technology. I find the Superpolator approach more powerful than MultipleMaster because it gives me more control on the topography of the variation space. I wish size/ppem-specific variations could follow a similar pattern.

I like Karsten's ab123 procedure, but on b I would like to be able to specify a ppem-size instead of points. It should be possible to forget about points and paper altogether and deal only with serving ppem-specific designs for screen (step 1).

Ideally, the infra-structure to package variations should be more generic than just a ppem axis and host other kinds of variations (there are many possibilities, specially if we finally embrace movement and color). The ppem axis should not expect proportional scaling of the design: higher ppem means only that glyphs get taller, not necessarily wider. And however sophisticated this system becomes, it should work with the lowest resolutions and plain b&w rasterization – screen resolution is increasing, but access to the web is not restricted to desktop computers.

To put my ideas in context, here is an article about the Elementar bitmap font system, published in 2007 on TYPO magazine 27. Thanks to Pavel Zelenka for giving me permission to make it available on my website.

I agree that trying to stuff many different sizes in the same font seems crazy.

I wonder about the limitations of ppem specific sizes without also accounting for resolution. Do you think that the same pixel pattern is equally good for 24 ppem at 72 dpi and 144 dpi? I have suspected for a while that there ought to be some interplay with resolution.

And what about the monitor type? Wouldn't your ideal pixel pattern differ between, say, the same LCD monitor in portrait and landscape modes? (I'm typing this on a 24" monitor currently in portrait mode with ClearType turned off.)

Regards,

T

>I agree that trying to stuff many different sizes in the same font seems crazy.

I think 64 is the max. Any more than that, yah, just crazy.

>Do you think that the same pixel pattern is equally good for 24 ppem at 72 dpi and 144 dpi?

yes, but that problem is nothing when compared to the reading comfort of millions of my fellow humans in the real world of resolution.

>And what about the monitor type?

It's called the weight axis.

Cheers!