RE: SVG Fonts - Is it the Font Standard of the future?

From: Peter Constable (
Date: Thu Mar 04 2004 - 00:37:26 EST

  • Next message: Ernest Cline: "RE: SVG Fonts - Is it the Font Standard of the future?"

    > From: []
    > Behalf Of Mete Kural

    > Are you sure about this? As far as I understand SVG can be used to
    > 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

    > Once the font
    > definitions are embedded in SVG, then an operating system should be
    > to map these definitions to its native format, correct?
    > For example there is a TrueType to SVG Font conversion utility on
    > 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
    > think platforms such as Windows and Macintosh will support SVG fonts
    > 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:

    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...

    So, evidently the authors of the SVG font spec didn't have in mind what
    you are suggesting.

    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.

    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?

    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.

    There goes absolutely any hope of this being *the* standard font format.

    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.

    So once again, the authors of the SVG font spec don't envisage it as
    ever replacing font formats used on OS platforms.

    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.

    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

    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.

    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