Re: SVG Fonts [...]

Am Donnerstag, den 03.06.2010, 19:34 +1200 schrieb Robert O'Callahan:
> On Thu, Jun 3, 2010 at 6:48 PM, Dirk Schulze <vbs85@gmx.de> wrote:
>         What do you mean with i18n issues? SVG Fonts support unicode,
>         you can
>         define glyphs dependent on the language:
>         http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObject/fonts-glyph-03-t.html
> 
> I mean support for processing text in complex scripts like Indic,
> where the rules for mapping Unicode to positioned glyphs are very
> complex. For example:
> http://www.microsoft.com/typography/otfntdev/indicot/default.htm
> 
> 
>         It looks like you just give explanatory statements why Firefox
>         won't support SVG Fonts.
> 
> No. I really wish there was a good reason to support SVG Fonts in
> Firefox (at least the easy-to-implement subset that Opera and Webkit
> have); then we could get 100/100 in Acid3, and we wouldn't have to
> feel guilty about adding a useless feature just to pass some tests.

I don't realy care about what ACID3 is doing. And I agree, that ACID3
shouldn't be the only reason to support any feature.
I would also agree not to use SVG Fonts as a default font for the
upcoming SVG1.1se test suite. We shouldn't test SVG Font support on
every test. I like the idea of using SVG Fonts to have a one by one
match of the actual rendering and the reference image, but a wrong
implementation of SVG Fonts will cause failing all tests.
But this two examples are just the famous once. There are content
creators with SVG Font support and the feature is also used in portions.
The current specification require SVG Fonts, so a viewer without SVG
Fonts support is not a SVG compliant viewer.

> 
> There are a few possible reasons to add a new Web platform feature:
> 1) it adds capabilities that aren't available using existing features
> 2) it adds capabilities in a way that makes them much easier to author
> than using existing features
> 3) it's widely used on the Web so it's needed for compatibility
> 
> Downloadable Opentype fonts with @font-face have reason (1). WOFF is a
> combination of (1) and (2).

Again, I don't have concerns against WOFF or any other new feature, if
it makes the work of a designer more easy, or improves the accessibility
or interoperability. Chromium already supports WOFF and I'm sure, that
the other WebKit ports follow this example.

> 
> 
>         The same for your annotation, that SVG Fonts 1.1 is not
>         implemented on
>         any viewer. That's not true. There is just no complete
>         implementation
>         out there.
> 
> The problem is, SVG Fonts 1.1 is easy to implement except for the part
> where you allow arbitrary SVG content in each glyph. As far as I can
> tell, that is actually really hard to implement in a performant way,
> in a typical Web browser engine where you expect to be able to use SVG
> fonts for HTML content, and when you want style inheritance into the
> glyphs to work the way the spec says it should.

Of course it's the hardest part and yes it's a challenge to make it fast
enough. But there are other parts that have the same problems (depending
on the viewer). For WebKit it's a challenge to have a fast enough
implementation of 'enable-background' (uesed on SVG Filters) with a few
memory consumption. But we'll work on it, when all concerns about
'enable-background' in the upcoming vector-effects are solved.

> Saying a browser's implementation is "not complete" when it entirely
> omits the really hard part would be an understatement.
Following this comment, Firefox never had SVG support.

Dirk

Received on Thursday, 3 June 2010 08:02:12 UTC