.screenfonts (was: Re: Merits and deficiencies of EOT Lite)

On Jul 29, 2009, at 7:55 AM, Thomas Phinney wrote:

> On Tue, Jul 28, 2009 at 10:35 PM, Gustavo
> Ferreira<gustavo.ferreira@hipertipo.net> wrote:
>> On Jul 29, 2009, at 12:45 AM, John Hudson wrote:
>>
>>> John Daggett wrote:
>>>
>>>> Maybe this is just me but implementing EOT-Lite in non-IE browsers
>>>> without revving IE effectively handicaps CFF fonts, TTF fonts would
>>>> be favored for market reasons rather than on technical merits. CFF
>>>> font vendors would be under market pressure to offer TTF versions  
>>>> of
>>>> their fonts and switch to using a TTF tool chain.  Clients would be
>>>> advised, "you should use TTF fonts because IE doesn't support CFF
>>>> fonts" and I'm guessing that stigma would outlive it's validity.
>>>
>>> There is already a TT bias for the web, just as there are the  
>>> remnants of
>>> a once strong PS bias for imagesetters. I think web designers will  
>>> be
>>> advising their clients 'You should use TTF fonts because CFF fonts  
>>> look like
>>> crap and are hard to read at text sizes' long before they get  
>>> around to
>>> saying 'And IE doesn't support CFF fonts'.
>>>
>>> Without significant improvement in CFF rasterisation, I think a  
>>> natural
>>> divide will emerge between CFF fonts for headlines and display  
>>> typography
>>> and TTF for text. (...)
>>
>>
>> Sorry, but I don't agree with your analysis.
>>
>> I believe the divide will be between "screen text fonts" and "other  
>> fonts",
>>  or "size specific fonts" and "scalable fonts" – not TTF vs CFF.
>
> On what basis do you believe this?

On the basis of my own experiments, and on the basis of ideas/protypes  
shown by David Berlow:

http://www.rogerblack.com/blog/screen_fonts_history
(http://typophile.com/node/60281)
http://www.fontbureau.com/test/franky/

> Currently, there essentially are no size specific fonts any more.

Yes, there are.

'Pixel fonts' remain extremely popular among designers who work with  
Flash.

Many digital devices (phones, handhelds, cameras, information panels  
etc.) still use true bitmap fonts.

Several high-quality typefaces for print are still developed following  
a size-specific approach.

And finally, this is how physical fonts were made for centuries.

> The
> main operating systems have ceased to support bitmap fonts.

Still, bitmap fonts survive as 'fake bitmap fonts' – outlines built on  
a grid and used at a specific PPEM.

> Given that
> even in browsers type is scalable (variable zoom levels set by the
> user) means that truly size-specific fonts that only work at one size
> are not going to be very useful.

The typographic infra-structure of html/browsers assumes that all  
_fonts_ are scalable.

I consider this to be a major BUG that affects the whole web and the  
future of our profession.

_Typefaces_ should be scalable, not fonts.

The typeface Verdana is implemented as one single super-smart delta- 
hinted TrueType font, but it could have been implemented as several  
size-specific dumb PS/CFF fonts.

> Fonts optimized for a general size range are a different matter. Is
> that what you meant? For example, a font optimized for use at very
> small sizes?

No, I mean outline fonts made to be displayed at one specific PPEM  
size, just like bitmap fonts.

> But in truth all outline fonts are (at least technically) scalable,
> and as a result of their spacing and other design characteristics, all
> fonts are by very nature optimized for a particular size range.

The core web fonts are optimized for low PPEMs by means of design,  
spacing and _TrueType hints_.

But TrueType hints are not 'interoperable' – they are interpreted  
differently (or simply discarded) depending on the rasterizer. Even  
different versions of Windows treat TT-instructions differently.

If I can't rely on TT hints, then I'm left with outlines and spacing  
only. This is enough for me to optimize a typeface design for a single  
PPEM, but not enough to optimize for a full 'size range'.

>> "Screen text fonts" are not necessarily TTF fonts.
>
> On Windows, for web fonts, I believe they are exactly that. Since 90%+
> of viewers are on Windows, this matters.

I am trying to argue that the only reason for this is a limitation or  
misconception in the current web font architecture that considers all  
outline fonts to be scalable.

Fake bitmap fonts and size-specific outline fonts are possible on  
Windows and are possible as CFF fonts. They can be made to have the  
same screen quality as manually hinted TT-fonts. With this approach,  
supporting a range of sizes means delivering several individual fonts  
instead of one heavily hinted TT one; the intelligence moves from the  
TrueType hinting code inside the font to the type-designer's skills  
and production tools.

Individual size-specific fonts will not scale gracefully, but they  
shouldn't have to – what needs to scale gracefully is a _typeface_,  
not a font.

The infra-structure for type on the web should make it possible and  
easy to use several fonts to make a typeface design scale gracefully.  
Quality of type on screens should not be limited by the  
particularities of the TrueType format.

> I'm not saying I like this fact (there are many things I prefer about
> OpenType CFF over OpenType TTF). Nor am I saying that the superiority
> is particularly inherent in the format. But right now, the situation
> is such that any foundry delivering Web fonts for use at text sizes
> would be crazy to deliver OpenType CFF.

I understand your point, but I think it is even crazier for foundries  
who care about text sizes on the screen to put time & money into  
making optimized TrueType fonts for the web. Such fonts will work  
differently under different rasterizers, and we can't predict how  
future rasterizers will interpret TT-instructions.

> Customers may not know *why*
> the rendering sucks, but they will know something is bad.
>
>> "Size specific fonts" are independent from font formats.
>
> Probably so. Can you elaborate on what you mean by this?

Size-specific fonts are rasterizer- and technology-independent because  
they use outlines which are grid-fitted by design. If used in the  
correct PPEM size they 'just work' – the proportions match the pixel  
grid and produce predictable bitmap letter shapes. Different  
rasterization settings influence the overall darkness or blurriness of  
text, but don't damage spacing and legibility.


Regards,
Gustavo.

Received on Wednesday, 29 July 2009 08:19:38 UTC