One other thing: I don't think we should be too eager to define a new SVG
subset for fonts, mainly because the problem we'd be trying to solve with
that is purely theoretical at this point. We don't know of any platforms
that have non-Web-capable SVG renderers that need fonts with SVG glyphs.
I'm not eager to spend time and energy specifying and implementing
restrictions on SVG glyphs for a problem that may never exist. It's similar
to how, not all that long ago, we spent time and effort (and messed up SVG
somewhat) to make SVG not dependent on CSS --- a requirement that is no
longer relevant and really never was. Let's not tackle another such
non-problem.
A precedent: we've already deployed SVG images widely with no particular
SVG subset defined for SVG image content and things seem to be going OK ---
we haven't heard about platforms with limited SVG renderers trying to use
SVG images and failing. The fact that unsupported SVG features often
degrade gracefully helps.
Rob
--
Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur
Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
— whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28]