> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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
