Re: SVG fonts: [ was RE: minutes, SVG WG TPAC F2F 2014, day 2]

It's a shame that we are giving up on SVG fonts, it's a great feature.

I don't use them because two major platforms have decreed that they won't
implement them for various reasons that I have never understood.

Lately I've been thinking that I'll narrow my development target to the
platforms that support the spec.  It would be a shame to narrow the spec
because platforms refuse to implement.

SVG fonts rock, they have so many uses beyond the description of text, and
implemented properly they would do that in ways that regular fonts cannot.

I, for one, will be sorry to see them go.


On Fri, Nov 15, 2013 at 6:39 AM, David Dailey <ddailey@zoominternet.net>wrote:

> ChrisL
>  ... I propose that we get rid of SVG Fonts completely from SVG
>     2
>
>     cyril: what is problematic with removing this is making them on
>     the fly
>
>     ChrisL: have you seen roc's font workshop page?
>
>     cyril: no...
>
> Am not sure if the font workshop page resolves Cyril's question or not.
> Does it?
>
> Losing the ability to define new fonts on the fly, client-side would
> present a major crippling of current functionality.
>
> See part 5 of the instructions concerning
> http://cs.sru.edu/~ddailey/Parisien.html
>
> If svg-in-opentype gives some mechanism for providing for client-side
> generation of fonts that include color, gradients, animation, patterns,
> (namely the whole ball of wax that SVG fonts provides) then I'm cool, but I
> think the resolution to drop them may have been premature given that one
> person voiced a question and another asked for a link, implying that the
> above question of loss of functionality may not have been clearly answered
> prior to the call for a vote. Some folks will be very unhappy with a
> withdrawal of major functionality from SVG1.1 to SVG2 . Of course the oral
> discussion that ensued may have resolved the issue satisfactorily.
>
> Btw -- It was me who mentioned to Doug about superpath maybe not offering
> the solution to drawing efficiency, since some hardware vendors (I think
> like NVidia) are implementing (and presumably caching) SVG paths in the GPU.
>
> I will check into that further to see if I heard right, but at the same
> time there are other savings offered from superpath: 1. Conservation of
> overall document size for complex shared edges (as in maps) 2. Ability to
> animate shared borders (as in the partition of Poland 1772-1939) or 3.
> Ability to animate unshared parts of paths -- making Mickey Mouse's arm
> move without having to redraw (and stipulate) the entire d attribute. Just
> the d attribute of the arm subpath of the superpath could be animated,
> saving lots of compute cycles.  Nonetheless I will see if I got my facts
> straight on the above.
>
> Cheers
> David
>
>
> -----Original Message-----
> From: Cameron McCormack [mailto:cam@mcc.id.au]
> [snip]
>
>
>
>


-- 

*If this were a movie, the country with the flying death robots would not
be the hero. *