- From: John Hudson <tiro@tiro.com>
- Date: Tue, 22 Oct 2013 10:22:26 -0700
- To: John Daggett <jdaggett@mozilla.com>
- CC: Chris Lilley <chris@w3.org>, public-webfonts-wg@w3.org
On 22-Oct-13 08:22, John Daggett wrote: > I'm somewhat skeptical that this sort of > feature is appropriate for webfonts, since rasterization will vary > across devices and zooming in and out would produce odd FOUT effects. > Might make more sense in EPUB contexts where the rasterization might > be more closely tied to the packaging and a document would embed the > fonts, making load times irrelevant. > I'm not sure 'font-size' is the right name for the descriptor, as you > want to pair a given face with a *device* size rather than the > computed value of 'font-size'. I should clarify that, at least so far, the MS size-specific design selection mechanism targets nominal point size and not ppem raster size. So zoom operations would not be expected to change the font selection. As I understand it, at present @font-face would require the size-specific font to be spec'd by the author for the given size of text element. This means that the author has to know for what sizes a given font is intended, and manually implement that information in the CSS. I am wondering if there is a way in which we can utilise this new font data downstream from the authoring? Or is it something that should be automated at the web authoring tool level? JH
Received on Tuesday, 22 October 2013 20:32:10 UTC