RE: New work on fonts at W3C

On Tuesday, June 23, 2009 4:32 PM Brad Kemper wrote:
> 
> On Jun 23, 2009, at 12:02 PM, "Levantovsky, Vladimir"
> 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.
> 

Applying Unicode-range that encompasses a complete character set for a
certain language is one thing, but using a selective, non-consecutive
set of Unicode code-points is something completely different. I wonder
if anyone actually tried doing this. I might work for languages where
each character has a unique one-to-one mapping to a single glyph, but
even then things like kerning will get broken.

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

Brad, I am brutally honest with you here. 
I said what I said because I know how difficult this can be. For
example, in Arabic each character can be represented by four different
glyphs (not considering ligatures) - it depends on the character
position in a word and on adjacent characters. The substitution rules
are encoded in a font and use glyph indices as a reference - how are you
going to process them if you split characters and glyphs in two separate
fonts? It gets a lot more complex for South Asian languages, and even
Latin-based languages may use fonts that support these advanced
features.

Back to my original point - why would you even want to make web authors
jump through all these hoops when a very simple conversion step (such as
compression) can be applied to make font file not directly installable
as a system font.

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

I didn't say "obfuscate", I said "compress". 
If you are referring to lightweight obfuscation proposed by Ascender -
implementing this would be a piece of cake - you just look up a table
directory in a font and substitute one specific tag by another specific
tag of the same length. The browser would then do the same (only in
opposite direction). You do not need to analyze the content of the font
and do all other complex things you suggested in your previous post.

> >
> > Regards,
> > Vladimir
> >

Received on Tuesday, 23 June 2009 22:26:10 UTC