RE: A way forward

For the sake of keeping this discussion to the point and as someone who is also involved in mpeg-OFF work  - I see .webfont and Composite Fonts being completely separate and orthogonal activities, and suggest that we should keep it that way:

 

-          .webfont is a wrapper around a font, and can be used for any font. It is web-specific and I do not see a use case where OFF Composite Font wrapper would be applied around .webfont wrapper (if needed, CSS already has its own way of doing this).

-          Composite Font should be considered as a new potential future font format that at some point may be supported by underlying platforms in similar ways TTF/OTF fonts are supported today. If .webfont wrapper is ever applied around Composite Font (it may not be necessary because of CSS) – it would be expected that Composite Font should be unwrapped (and decompressed, if necessary) by a browser and passed to underlying OS for processing the same way we would do it today for TTF/OTF font.

 

Regards,

Vladimir

 

 

From: www-font-request@w3.org [mailto:www-font-request@w3.org] On Behalf Of Robert O'Callahan
Sent: Sunday, July 26, 2009 7:30 PM
To: John Hudson
Cc: www-font@w3.org
Subject: Re: A way forward

 

On Sun, Jul 26, 2009 at 1:37 PM, John Hudson <tiro@tiro.com> wrote:

 Tal wrote:

 I wish this was true, but it isn't. The OpenType format has very real limitations that cannot be fixed. From what I understand, there is already work going on to develop a new format for component fonts.

  

 POI:
 
 There is an mpeg-OFF working group developing a composite font standard. A composite font consists of two or more fonts in an XML wrapper that function as a virtual font. One of the goals of this work is to overcome the 64k glyph limit in sfnt fonts, another is to enable multi-script virtual fonts from single-script component fonts, and another is to provide for size-specific type designs within a single virtual font. As with .webfont, the format of the fonts within the composite font is not restricted; I believe it is even possible to have component fonts of different format within a single composite font.


Sounds nightmarish, but it also sounds like this is going to be an XML wrapper around SFNT fonts, at least as first deployed. In that case, if we have a spec for embedding metadata in SFNT fonts, it will work with this new format.

Actually this other XML wrapper raises some question for .webfont. Should an mpeg-OFF wrapper around a .webfont work? What about a .webfont wrapper around an mpeg-OFF wrapper? What about a .webfont wrapper around an mpeg-OFF wrapper around a .webfont wrapper? Which metadata takes precedence in the latter case? Wrappers can be trouble...

Rob

-- 
"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]