Re: New work on fonts at W3C

On Jun 23, 2009, at 12:02 PM, "Levantovsky, Vladimir" <Vladimir.Levantovsky@MonotypeImaging.com 
 > wrote:

> On Tuesday, June 23, 2009 2:12 AM Brad Kemper wrote:
>>
>> If the font requires some custom @font-face rules in the CSS file in
>> order to work well, then that block of CSS could also contain a
>> comment explaining the restriction further, along with a sentence  
>> that
>> says, "this text comment block must be included with the @font-face
>> rule, unedited, as part of the license requirement."
>>
>> Furthermore, the single font could be split into two fonts: one with
>> the vowels, odd numbers, and punctuation, and the other with the
>> consonants and even numbers, and then brought together via @font-face
>> unicode ranges and a font-family stack. This would make it pretty  
>> hard
>> to accidentally copy it to another site and have it work, without
>> first understanding that they are not supposed to. And it would make
>> it pretty difficult to use in other applications that do not have
>> @font-face rules.
>
> A font isn't just a collection of glyphs - it also contains additional
> information such as glyph substitution, positioning and layout tables,
> kerning, etc.

Couldn't such tables and alterate characters and such be kept in one  
of the fonts (or both) and just have the missing characters pulled  
from the other font? I thought that would be how Unicode ranges would  
need to work anyway.

> Ligatures, glyph variants and many advanced features that
> are necessary to support complex language scripts such as Arabic and
> Indic depend on the layout processing - I don't see how you can  
> split a
> font without breaking all this. Many language scripts are syllabic -  
> how
> do you plan to handle those fonts?

I was primarily thinking of Latin scripts, but I imagine in other  
scripts there would be some vital, oft used characters that you could  
still split between two fonts.

> I am also stunned that you seem to be suggesting that web authors  
> should
> go to such a great length and make extra efforts in handling fonts

I really wonder if you are being genuine when you say things like  
that. I see absolutely no reason whatsoever why the tool to split a  
font in two, rename it, and add a little license info should be any  
more difficult or less automated to use than a tool like WEFT for  
creating EOT. It might even be a little easier, since it would also  
generate the @font-face code block and maybe a sample font-family rule.


> when
> targeted font compression seem to present much simpler solution -
> compress a font that is hosted on a server, and let browser decompress
> it before it passes it on to the OS font engine. To me it seems as the
> most straightforward and effortless solution, isn't it?

Aside from the separate issue of compression, how is that easier than  
using a tool to "obfuscate a font that is hosted on a server, and let  
browser de-obfuscate it before it passes it on to the OS font engine"?

>
> Regards,
> Vladimir
>

Received on Tuesday, 23 June 2009 20:40:08 UTC