From: Peter Constable (petercon@microsoft.com)
Date: Thu Mar 04 2004 - 00:37:26 EST
> From: unicode-bounce@unicode.org [mailto:unicode-bounce@unicode.org]
On
> Behalf Of Mete Kural
> Are you sure about this? As far as I understand SVG can be used to
embed
> font definitions in a platform-independent manner.
Embed in *what*? Sure, SVG is platform independent insofar as it is a
spec that is not dependent on any platform. (For that matter, OpenType
also exists independent of any platform.) But that doesn't mean that it
*is* supported in any kind of container protocol that allows embedding,
except the SVG spec -- hence products that can use SVG as a document
format.
> Once the font
> definitions are embedded in SVG, then an operating system should be
able
> to map these definitions to its native format, correct?
>
> For example there is a TrueType to SVG Font conversion utility on
Apache:
> http://xml.apache.org/batik/ttf2svg.html
> I would think that similarly it should be possible to build an SVG
Font to
> TrueType conversion utility.
Well, *lots* of things are *possible*, but that doesn't mean that they
are used. What are you suggesting? That an SVG font could be "installed"
on some platform e.g. Windows and that during the installation process
the platform will converting the SVG resource into a TTF? Or that it
will leave it as an SVG resource and add a native SVG rasterizer? I
don't know of any platform on which either of these is happening.
> Do you think that SVG Fonts can be the font standard of the future? Do
you
> think platforms such as Windows and Macintosh will support SVG fonts
as
> system fonts? I appreciate your insight.
*The* standard? Not very likely any time soon. I can think of a few
different issues. To provide some context, let's look at what the font
section of the SVG spec has to say:
<quote>
The purpose of SVG fonts is to allow for delivery of glyph outlines in
display-only environments. SVG fonts that accompany Web pages must be
supported only in browsing and viewing situations. Graphics editing
applications or file translation tools must not attempt to convert SVG
fonts into system fonts...
</quote>
So, evidently the authors of the SVG font spec didn't have in mind what
you are suggesting.
<quote>
The intent is that SVG files be interchangeable between two content
creators, but not the SVG fonts that might accompany these SVG files.
Instead, each content creator will need to license the given font before
being able to successfully edit the SVG file.
</quote>
Have you considered the IP issues for SVG fonts? Currently, there is
absolutely nothing in the SVG font spec related to IP and security
issues. How many type designers are going to be excited about selling
SVG fonts when all it takes is a simple style sheet for someone to
extract that vendor's IP that happens to have gotten embedded in some
onine SVG content and convert it into a new font that they market as
their own?
<quote>
SVG fonts contain unhinted font outlines. Because of this, on many
implementations there will be limitations regarding the quality and
legibility of text in small font sizes.
</quote>
There goes absolutely any hope of this being *the* standard font format.
<quote>
For increased quality and legibility in small font sizes, content
creators may want to use an alternate font technology, such as fonts
that ship with operating systems or an alternate WebFont format.
</quote>
So once again, the authors of the SVG font spec don't envisage it as
ever replacing font formats used on OS platforms.
<quote>
Because SVG fonts are expressed using SVG elements and attributes, in
some cases the SVG font will take up more space than if the font were
expressed in a different WebFont format which was especially designed
for compact expression of font data. For the fastest delivery of Web
pages, content creators may want to use an alternate font technology.
</quote>
Here's a good one. Can you imagine trying to sell a mobile-device vendor
on using a Chinese font in SVG format?
It's interesting to note what the SVGMobile spec has to say about SVG
fonts:
<quote>
SVGB and SVGT support a subset of SVG fonts where only the 'd' attribute
on the 'glyph' and 'missing-glyph' elements is available. Arbitrary SVG
within a 'glyph' is not supported.
As with Full SVG 1.1, SVGB supports downloadable fonts using WebFonts
facility defined in the "Cascading Style Sheets (CSS) level 2"
specification. In SVGT, an SVG font can be only embedded within the same
document that uses the font.
</quote>
So, it sounds like you can include outline data (using the d attribute),
but nothing else -- not even the Unicode attribute (how can the thing be
useful?)!! There's no attempt to make the outline data more compact, and
they still envision SVG fonts only being embedded in SVG documents, not
as a standalone font format.
(The *one* thing SVG fonts would have going for them in a Far East
context is that it would be easier to deal with the kaiji (private-use
character) issue for SVG documents using SVG fonts than it is for
systems based on plain text and other font formats.)
Add to all these points that there is not adequate for advanced
typography and complex scripts, though of course, that obstacle could
potentially be fixed.
Then there's the fact that no platform currently has native support for
SVG fonts but do have a huge amount of infrastructure built on other
font formats.
So, in view of such issues, I think you'd agree that there are a lot of
reasons why *not* to plan on replacing formats like Type 1, TTF and OTF
any time soon.
Perhaps you could start by trying to ignite a movement within the TeX
community to replace Metafont with SVG. Even if you succeeded there (I'd
be surprised), that won't have much impact on platforms. (How many OS
platforms do you know that have built-in support for Metafont fonts?)
Peter Constable
This archive was generated by hypermail 2.1.5 : Thu Mar 04 2004 - 01:21:31 EST