Re: Revisiting SVG Fonts

TL;DR: Polyfill method.

PDF.js and jsfont ( http://hertzen.com/experiments/jsfont/ ) demonstrate 
that SVG Tiny embeddings can be re-serialized into TTF files with a 
functioning onload handler. It requires quite a bit of code, but it's 
doable.

I encourage developers to explore font authoring techniques inside the 
browser as most font editing activities require desktop software.

As an aside, Ancient Lives is a great example of transcription software 
running in the browser:
http://www.ancientlives.org/

...

Mozilla is requiring font-shaping be available.

For authors who are targeting SVG Fonts, I suggest exploring ligature 
hacks and altGlyph.
I'm experimenting with those techniques in my attempts to support 
handwritten content and rasterized content.

The rest of my reply follows in-thread.

Robert, I've only asked, in the first section (in-thread), for some 
clarification.

The rest of my response is a low priority.

-Charles

note: My reference to "Robert's comment" on 11/3/11 (en-US) is to Robert 
O'Callahan,
subsequent replies are from Robert Longson.

On 11/4/11 1:59 AM, Robert Longson wrote:
>> On 11/3/11 3:04 PM, Charles Pritchard wrote:
>> What I took away from Robert's comment was that SVG 1.2 Tiny is not
>> sufficient for inclusion in Mozilla. I believe that a more complete
>> implementation of the specification in SVG 1.1 may be acceptable,
>> inclusive of animation and multi-colored glyphs.
> No, an SVG 1.1 Full font implementation is even less likely to be
> accepted into the
> codebase than SVG 1.1 Tiny font support. We're not really interested
> in supporting
> animation or multi-coloured glyphs[1].

When you say "we're not really interested" does that mean:
a) We will not do this. If it is in a specification we will not 
implement it.
or
b) We're not motivated by this, we have no particular concerns about 
this matter at this time.
c) Something else.

> We think the web should be for everyone, not just those who can read
> and write English
> so we're not going to implement something that can't be used by a
> large part of the
> world's population. [2-5]

SVG Fonts may be used with arbitrary content through various altGlyph 
and ligature-related hacks.
The important thing is that the document doesn't devolve into <path> 
instead of <text>.

Without SVG Font support of any kind, the font data is likely to be 
exported as <path> data sans-accessible content.

SVG2 seems to be a reboot; SVG1 files are quite likely to be exported in 
that manner.
There's room to avoid that with SVG2.

I appreciate your (and Mozilla's) position on linguistic sensitivity and 
your attendance on this thread.

I agree that SVG Fonts are a toy (script) in comparison to the goals of 
Graphite:
http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=RenderingGraphite
https://wiki.mozilla.org/Features/Platform/Graphite_font_shaping


Personal handwriting is an unsupported script. That's one I'm focused 
on, and it won't be solved by Graphite; it's an area where I'm hoping 
altGlyph usage can be trimmed down.

I'm 100% behind the motivation Mozilla has here in defending linguistic 
diversity.

I'm saddened that it comes at the expense of speakers.

Few speakers of the "world's population" have the technical knowledge to 
work with a font editing program, and the time and resources to populate 
the font with all of the requisite details needed for Graphite font 
shaping to shine.

Many speakers are able to take a pen to paper and transcribe on keyboard 
what they've written or what they see.

We could certainly deconstruct the graphite and opentype specs and 
XML-ize them into SVG Fonts... but the majority of users, of all 
scripts, would be thoroughly overwhelmed.... just as they would be 
thoroughly overwhelmed in attempting to develop with Graphite.
https://wiki.mozilla.org/SVGOpenTypeFonts

It sounds to me like that's the only way forward, in terms of supporting 
inline XML for font-face.
Otherwise, we're stuck manipulating data uris.


> Putting SVG into OpenType font tables is one solution that would allow
> this as we could
> take advantage of our existing complex shaping capability.
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=119490#c70
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=119490#c49
> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=119490#c95
> [4] https://bugzilla.mozilla.org/show_bug.cgi?id=119490#c99
> [5] https://bugzilla.mozilla.org/show_bug.cgi?id=119490#c104
>

This thread was easier for me to follow, from Batik:
http://batik.2283329.n4.nabble.com/Extracting-all-glyphs-from-a-font-td2975166.html

"SVG fonts do not support the complexity needed for most Indic 
languages, particularly those written in Devanagari"

Received on Friday, 4 November 2011 10:20:59 UTC