RE: SVG 2 Features and Approach

Well, those browsers happen to be wrong. It is not for the tail to wag the dog. The spec really should follow wisdom rather than caprice. There will be sound reasons to complain if SVG agrees to take a backward step in functionality and cogency of design. Because some individual at Mozilla decides he or she doesn't like SVG fonts is not exactly a groundswell of rationale for exclusion from a standard. Certain browsers are just not standards-compliant. It has always been this way with SVG. Should we remove SMIL animation because Microsoft says they don't like it. Should we remove text support because Firefox has a poor implementation of the 1.1 standard? Just allow some browsers to fail certain tests as they always have. Unless you want to be like HTML5 and remove things from the test suite so that all browsers are 100 percent compliant? Why not just roll back SVG to a least common denominator (that which all browsers support) and scrap initiatives to improve it. 

Accessibility is being gutted here, I think.

Emoji in full color with animation will be rolled out in SVG format soon, and Apple learned that one can't sell i-phones in Japan without emoji. 

Enough rant! I had to get it out of my system since the rationale for SVG fonts is so much better than the rationale against them.

regards
David

-----Original Message-----
From: Tab Atkins Jr. [mailto:jackalmage@gmail.com] 
Sent: Monday, January 07, 2013 3:27 PM
To: Jelle
Cc: www-svg
Subject: Re: SVG 2 Features and Approach

On Mon, Jan 7, 2013 at 3:18 AM, Jelle <pjmulder@xs4all.nl> wrote:
> I would be severely disappointed if SVG fonts are taken out of the 
> standard to protect the vested interests of the type foundries, pdf and ps.

The removal of SVG fonts from the SVG2 spec has absolutely nothing to do with foundries.  (I didn't even realize there *was* an angle there until I read your message.)  It's entirely because browsers haven't implemented them beyond a smattering of basic support, and have stated that they don't plan to in the future.  Ultimately a spec is only useful if it documents reality, and the reality is that the SVG Fonts spec isn't usable in browsers.

> This is
> the only text based font type and would be a blessing for anyone 
> needing to handle subsets of fonts. A whole traditional Chinese font 
> is huge in any format except for SVG, it would allow for handwritten 
> font types or dynamically created ones as well and the whole 
> diacritics issue is something I think should be handled by the authoring software rather than the fonts.
> Those have rules of where to place things surely that could be solved 
> with "fft" rules etc. in Unicodes and the according glyphs. It may 
> become an unholy mess for some uses, but I guess software would find a 
> solution to handling that as well. A simple keyGlyph that would tell 
> any renderer what code the first letter in the alphabet is in the 
> whole string should help out for wide ranged fonts as well.

Note that, while SVG Fonts is getting dropped from SVG2 (or put into a module, or whatever), we're separately pursuing the ability to put SVG into a Truetype font for the outlines.  It already works in some
(private?) version of Firefox, and I think has mild support from the other browsers.

> The whole concept of SVG fonts is way too cool and useful to disregard 
> for some ugly binary format like Woff that only type specialist can or 
> want to use. Font hinting?,.. well maybe some better rendering 
> algorythm?

Note that WOFF1 is just the TTF format with an extra header and optional compression.  WOFF2 is a more advanced version of the format with much stronger compression, and is very suitable for CJK fonts because of this.

~TJ

Received on Monday, 7 January 2013 21:30:38 UTC