469656 - add support for OpenType optical size feature

Status: RESOLVED WONTFIX

(Core :: Graphics: Text, enhancement)

Description

[Jonathan Kew [:jfkthame]]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20081213 Minefield/3.2a1pre
Build Identifier: 

Some OpenType font families provide an "optical size" feature that specifies the preferred subfamily to use for various sizes. For example, Garamond Premier Pro has subfamilies "Caption", "Subhead", and "Display" (with a range of weights in each subfamily), in addition to the default face.

When the style simply calls for the overall family Garamond Premier Pro, we should choose the appropriate face according to the font size. This means we would get the Caption face at very small sizes, which is slightly bolder and set wider for better legibility; at larger sizes we'd get the Subhead or Display faces, which are thinner, crisper, and tighter-spaced.

The attached test file and screenshot shows the expected result (simulated by explicit use of @font-face), with the current behavior (ignoring optical sizing) for comparison.


Reproducible: Always

Comment 1

[Jonathan Kew [:jfkthame]]

Attachment: screenshot showing the effect of using optical sizes

Comment 2

[Jonathan Kew [:jfkthame]]

Attachment: html source used to create the sample screenshot

Comment 3

[Jonathan Kew [:jfkthame]]

Attachment: patch to support optical font sizes (WIP, currently Mac only)

Comment 4

[Jonathan Kew [:jfkthame]]

It should have been easy to extend this to support Windows as well, but unfortunately it's not as straightforward as I hoped. It seems that the GDI font enumeration functions can't see all the faces of a typical OpenType pro family with optical sizes. I have 34 faces of Garamond Premier Pro installed, in 4 optical sizes, and 5 weights; however, when we use EnumFontFamiliesEx to build the list of available fonts, it only returns 13 out of the 34 faces.

So although MSDN claims that "EnumFontFamiliesEx enumerates all font styles", this doesn't appear to be true, and it's going to make it more painful to try and find them. (I tried a standalone test program to check that this wasn't due to something odd about the way we're using the APIs. Same result, only 13 of the 34 styles are found.)

I assume the "missing" fonts are being considered as bold and/or italic variants of some of the fonts that are being returned, and have to be accessed as such. Sigh.

Comment 5

[John Daggett (:jtd)]

There's already a bug for doing better style linking under Windows, bug 454514, sounds like this enhancement is somewhat dependent on that bug.  

The normal GDI api's only group families based on the family name, not the preferred family name.  And OpenType 1.5 adds a *third* family name, the WWS (width-weight-style) family name, so for "ideal" behavior families should be joined by:

  WWS family ==> preferred family ==> family

To do this we need to manually look this information up in the name tables, since there's no way that I know of for doing this via a GDI api.

Comment 6

[Karl Tomlinson (:karlt)]

Interesting.  So there would be a couple of sizes at which increasing the em height would result in shorter text.

Comment 7

[Jonathan Kew [:jfkthame]]

(In reply to comment #5)
> There's already a bug for doing better style linking under Windows, bug 454514,
> sounds like this enhancement is somewhat dependent on that bug.  

Thanks for the pointer; I'd seen that sometime previously, but forgotten about it... yes, these are related. Seems like we should be able to kill several birds with one cache.

(In reply to comment #6)
> Interesting.  So there would be a couple of sizes at which increasing the em
> height would result in shorter text.

True. Actually, if we ever use hinted metrics, this can happen anyway in certain odd cases, but optical sizing makes it more-or-less bound to happen. Does it seem like this would be a problem - do we make assumptions that would break?

Comment 8

[Karl Tomlinson (:karlt)]

(In reply to comment #7)
> Does it seem like this would be a problem - do we make assumptions that would
> break?

No.  I don't think Mozilla makes any such assumptions, and the chance of it causing a problem with html pages seems unlikely.

Comment 9

[John Daggett (:jtd)]

Related discussion of the optical size feature on Typophile:

http://typophile.com/node/60432

Comment 10

[Jonathan Kew [:jfkthame]]

Attachment: patch, support the OpenType optical size feature

This builds on the FindFontsForStyle patch in bug 677900; if multiple faces are found that match the requested style, then it will check for the presence of an 'opsz' feature, and if found, use this to select the appropriate face from the collection.

By looking for 'opsz' (in the GPOS table) _only_ after FindFontsForStyle has returned an array with >1 entries, we avoid the cost of looking for and parsing the GPOS table at all in the case of "simple" families without optical-size variants.

This patch should provide optical-size support for installed fonts on OS X and Windows, and for @font-face fonts on all platforms; it does _not_ implement it for the Linux/Pango/fontconfig backend, as it is not clear to me how to achieve this. I can't see any evidence that fontconfig supports the optical size feature at this time, and building our own separate support for it may be more trouble than it's worth.

Comment 11

[Jonathan Kew [:jfkthame]]

Attachment: reftest for optical size support

This uses a bunch of faces from the Latin Modern Roman family to test that optical size support (for @font-face fonts) is working.

(Automated testing for installed system fonts is trickier as I don't think any of the standard font families on OS X or Windows include optically-sized variants. We can of course test it manually by installing appropriate fonts locally.)

Comment 12

[John Daggett (:jtd)]

Comment on attachment 552076 [details] [diff] [review]
patch, support the OpenType optical size feature


There are a number of problems with this but I think the biggest one is that I just don't think this is worth implementing.  To begin with, very few fonts implement this feature.  More importantly, doing style selection using data contained in the font itself is *not* the way font selection is done families of downloadable fonts.  The font descriptors contain the data needed for style selection, so if you want to make size-specific selection possible with families of downloadable fonts, you need to extend that model to support this (e.g. add a  'font-size' descriptor and added logic to the font selection algorithm to determine how to select from a set of available sizes).

If you follow the link mentioned in comment 9, John Hudson states "the OT 'size' feature is a lousy hack that breaks the OT layout model, is unlikely ever to be implemented in much software".

He explains this more fully as:

"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."

In the same thread Karsten Lueke also makes an interesting distinction between size-based selection for aesthetic reasons (e.g. header fonts should have more articulated serifs) vs. for dealing with output resolution concerns.  The former would be interesting to address in CSS but the latter is probably too complex for CSS (i.e. too many variations based on rasterizer and the ppem specifics of individual devices).

So while the concept of this feature is intriguing, I don't think the feature as designed is worth supporting, it's not really thought out well and it's not widely supported.  Additionally, whatever we implement really has to work with the selection model for downloadable fonts.  Doing that will require changes to CSS.

Comment 13

[John Daggett (:jtd)]

(In reply to Jonathan Kew from comment #10)
> By looking for 'opsz' (in the GPOS table) _only_ after FindFontsForStyle has
> returned an array with >1 entries, we avoid the cost of looking for and
> parsing the GPOS table at all in the case of "simple" families without
> optical-size variants.

Just to prevent confusion, the patch here uses the 'size' feature, which is listed in the OT feature registry.  There's no reference to a 'opsz' feature in the patch, nor does a feature tag exist for this.

Comment 14

[Jonathan Kew [:jfkthame]]

I don't think we're likely to pursue this. The old OpenType 'size' feature never really caught on, and has basically been superseded by variable fonts with an 'opsz' axis.