W3C home > Mailing lists > Public > www-svg@w3.org > June 2011

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

From: Robert O'Callahan <robert@ocallahan.org>
Date: Tue, 28 Jun 2011 14:57:54 +1200
Message-ID: <BANLkTin3uW_kW_TGDJQdaXThW=5FXmdc2g@mail.gmail.com>
To: "Levantovsky, Vladimir" <Vladimir.Levantovsky@monotypeimaging.com>
Cc: "list.adam@twardoch.com" <list.adam@twardoch.com>, "www-font@w3.org" <www-font@w3.org>, "www-svg@w3.org" <www-svg@w3.org>, "www-style@w3.org" <www-style@w3.org>, "public-webfonts-wg@w3.org" <public-webfonts-wg@w3.org>, OpenType List <opentype-migration-list@indx.co.uk>
I'm quite enthusiastic about Adam's proposal!

On Tue, Jun 28, 2011 at 5:40 AM, Levantovsky, Vladimir <
Vladimir.Levantovsky@monotypeimaging.com> wrote:

> Once the referencing mechanism is resolved, the OT glyph indices can be
> used to render corresponding SVG glyphs, if present, or the traditional
> glyphs as a fallback. The question is then whether it is truly necessary to
> embed the SVG data inside SFNT structure, or whether it would be sufficient
> to just reference an external SVG file containing glyph descriptions.
>

Embedding the SVG data inside the SFNT is better for everyone involved, I
think. It's certainly much simpler to implement, and it is probably more
convenient for authors managing fonts. Even for tools, packing an SVG blob
into an SFNT should be very easy.

One thing that needs to be resolved is what restrictions (if any) should be
imposed on SVG in the SVG table. I would want to impose the same
restrictions that we impose for SVG images: no external resource loads
(other than data: URIs), and no scripting. Declarative SMIL would be allowed
however.

Another issue is how styles such as "fill" and "color" set on text elements
are applied to arbitrary-SVG glyphs. SVG Fonts tries to achieve this by
hacking CSS inheritance, but I don't like that solution at all. Instead I
recommend defining a new "textFill" paint server keyword which resolves to
the "fill" for SVG text (with patterns being rescaled automatically from
user space to glyph space), or the CSS "color" for non-SVG text. For
stroking, we'd need a "textStroke" paint server and a "textStrokeWidth"
length value (textStrokeWidth would also need to automatically rescale from
user space to glyph space --- one of the reasons why CSS inheritance alone
as in SVG Fonts doesn't work).

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 Tuesday, 28 June 2011 02:58:38 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:48 GMT