Re: Revisiting SVG Fonts

> On Monday, October 31, 2011, 8:30:33 PM, Charles wrote:
>
> CP>  And I understand that SVG fonts do not support various items that would
> CP>  make them a worthwhile alternative -- such as supporting semantics to
> CP>  render full color emoji.
>
> You have that exactly backwards. SVG fonts *are* able to support colour, animated, emoji while TrueType and OpenType do not.
Sorry, my wording was ambiguous.

That's what I meant by "worthwhile".

I should have said something like "supplement" instead of alternative.

> However, current work to allow SVG glyphs inside OpenType fonts would give the colour and animated capability of SVG fonts with the greatly superior internationalization and feature flexibility of OpenType; and such an OpenType could be transported as woff.
>
> That seems to me by far the best way forward.
Extending OpenType fonts with SVG is a reasonable destination.
Implementing SVG glyphs seems like the way forward.

They're an early requirement anyway on the technical side. WebKit is far 
closer to supporting opentype + svg because of their support of SVG glyphs.

There are many cases where inline XML is more desirable than WOFF with a 
data:uri.

> CP>  That said: there is a high barrier to entry when working with binary
> CP>  formats. I can't -quite- be helped with PNG, but SVG does do something
> CP>  about that -- it allows hand coding of images in ASCII format, and it
> CP>  still permits raster images to be included.
>
> Yes (assuming by ASCII you mean Unicode)

I meant ASCII. Unicode is a better example.

It's certainly easier to hand-code Unicode.

> CP>  There is a high barrier to entry for designing and generating WOFF.
>
> Not really.
>
> Its certainly possible to design an SVG font and then convert it to OpenType and produce a woff. (FontForge, and FontSquirrel, are two ways to do this).

HTML, SVG documents and Raster images can be edited within the web 
browser using JS and contenteditable.

The same can happen with WOFF but it requires a lot of client-side code.
WOFF was introduced without any API to generate or alter the content.

There has been a recent, reasonable proposal for exposing glyph paths 
prior to rendering.

I realize that there are authoring tools, open source ones, for 
developing fonts. I consider that a high barrier to entry relative to 
manipulating an SVG file by hand.

>
> CP>  Meanwhile: creating an SVG font is as easy as creating an SVG. It can
> CP>  even be debugged right there, in real time, in the browser. One could
> CP>  easily write a program to allow drawing in SVG, and exporting those
> CP>  glyphs as an SVG font. All of this is ASCII/DOMString compatible. WOFF
> CP>  is not. It's not easily interchanged, not easily supported on the
> CP>  server-side.
>
> CP>  With all due respect to WOFF, it's far too formal for many basic use
> CP>  cases.
>
> I have no idea what you mean by 'too formal' here. Is it a synonym for 'binary format'?

It's a very advanced format with a lot of features and a strict binary 
format.

SVG Tiny glyphs are a very basic format with very few features.

Opening up notepad and hitting reload in IE is informal.
Requiring only a browser for authoring is informal.

I am able to write a client-side JS script to convert an SVG font into 
WOFF and to serialize it into a data:uri and load that script 
asynchronously. I can also cross-compile open source authoring tools.

Those are activities I consider "too formal" for basic hacking at an SVG 
file.
Vendors have just barely approached editing techniques for WOFF in the UA

My concern is that excluding SVG Fonts raises the barrier to entry for 
authors.

There is an active proposal to expose path data for text strings to the 
scripting environment. That path data can then be edited, and added into 
inline SVG glyph definitions supplementing the original font. Currently, 
authors have to supply information twice or include a WOFF decoder.

I don't understand the push-back. If SVG fonts are added to WOFF, the 
browser vendors would still have to do the same work.


-Charles

Received on Tuesday, 1 November 2011 02:10:02 UTC