Re: SVG Fonts inside of OpenType fonts? [Cross-post from www-font@w3.org]

Rob,

--Original Message--:
>On Thu, Jun 30, 2011 at 2:16 AM, Erik Dahlstrom <ed@opera.com> wrote:
<snip/>
>It's always more cumbersome to use libraries than to build functionality directly into the browser, but I want to resist the temptation to build everything into the browser.

What? You're going against Google's master plan - one code base that rules the entire
universe, shame on you:-)

Tab asked: " For example, you theoretically have the ability
to add an <html:video> to a <glyph> (loading the data from a data:
url, if necessary).  How does this work?"

Well in October 2006 my CDF implementation was shown at a W3C workshop
with HTML text pulling in an SVG font which contained video in the glyphs. That
was before the HTML video element was even introduced. It's been done, and
IMO SVG Fonts are different enough from normal OpenType to leave them be,
If we need a new format then lets go that way and leave the status quo as is.

Also, Vladimir wrote: ""This is exactly where the weakness of the SVG is - the glyphs inside
SVG fonts are identified by the <unicode> strings and while this can be made to work for
one-to-one and many-to-one mappings - it doesn't work for one-to-many mappings in a generic way."

This is incorrect. If an implementation does SVG Full fonts, then the content can contain <use>
elements.

So, the glyph geometries themselves can just sit in a <defs> or wherever, and you could
even use their 'id' as your glyph index. Then the <glyph> elements in the SVG font can
reference an arbitrary number of them. i.e. one-to-m, n-to-m and n-to-one mappings
are all possible with the SVG font spec. as is, no changes required.

It is a fact that an authoring tool is capable of outputting SVG font outlines for glyphs
etc. as a single self contained file with no rendering ambiguity. Furthermore, language
dependent rendering can be achieved with <switch> if you wish.

ASV had animating SVG Fonts ages ago as do I.

I don't see that shoving SVG Fonts into an OpenType container does anything  more
than force us to restrict them in arbitrary ways and so seems a bit silly.

If the existing SVG Font mechanism isn't sufficient for PDF->SVG workflow (which
it isn't) then that's orthogonal. The glyph indice thing is a red herring since the mappings
are all possible now and if the SVG Font is in the SVG file then the rendering is
predictable, more so than PDF...

XML compressed or not in a font file makes me queasy.

Alex

>
>
>
>...
>
>
>Out of
>curiosity I'd be interested in hearing if there are any other use-cases that
>would be helped by having script support in the font itself.
>
>
>Having script run in the font itself has all the same issues that having
>script run in SVG images would have --- and more. Just a taste: what would
>you do if your font does "document.location = 'http://google.com';" (i.e.,
>replaces the font document with some HTML document)? Get script turned on in
>SVG images in Opera, then we can talk again :-).
>
>So (intentionally or not) you just misrepresented what I wrote. I asked about possible use-cases. That is all.
>I apologize. It was unintentional, I thought you were advocating enabling script inside fonts.
>
>
>Rob
>-- 
>"If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us." [1 John 1:8-10]
>
>
>

Received on Thursday, 30 June 2011 01:34:33 UTC