Svg can not be used as an interchange format
2003-07-20 22:08:00 Paul Prescod
[Reply]
> Paul > Of course any interchange format is going to lose some details of the native formats.
> Robin > It will lose whatever the spec allows it to lose, which is often zero, but at least not an arbitrary amount like 'what is supported by a third format'.
I'm having trouble understanding you. Whenever you have Model A and Model C and interchange through Model B you lose anything that A and C support that is not supported by B. But the alternative is to build A-Z * A-Z translators which is to say 676 translators. This never happens. Just to keep some sanity in the system you must necessarily choose some hub formats. The only question is whether the hub formats are open standards or not, and whether they are well-designed for the purpose or not.
As an example, I did a Google search for "graphing software". I found OriginPro. What does it output GIF? Until recently that was patent encumbered and certainly not scalable. Now look at this long list of output formats supported by GraphViz:
http://www.research.att.com/~erg/graphviz/info/output.html
Which scalable vector format should I use for import into Keynote for the Mac? I'd like to believe that by 2005 there would be an obvious answer to that question but right now I don't think that there is. (amazingly, I had trouble with bitmaps and PowerPoint just last week!)
Now look at OpenOffice Draw. What does it output? A bunch of bitmap formats and WMF. Oops. Most Mac programs (like Keynote) do not support WMF.
Now I want to put the corporate logo into my presentation (or Visio file). What is the marketing department going to email me? Likely either a bitmap or an Illustrator file that is useless on my computer.
> Cutting unicode text as ascii would result in loss
> that would never be acceptable.
That's just not true. Some tools only claim to support ASCII and if their user base is happy with that they get what they pay for. The application needs to indicate that it is losing characters and let the user choose another strategy if that is a problem. But more to the point, there are applications where Unicode is a lossy interchange format. That doesn't mean that Unicode is a LOUSY interchange format just that it is not in and of itself sufficient for all purposes. Where it is not good enough you augment it or use something else altogether.
> All modern OS's can handle this, and most older ones will > too. If your container only supports ascii, then it will have > to be converted down, but you would never store it on
> the clipboard as ascii alone. That is why the clipboard
> can store data in multiple formats, and auto convert as
> well.
Great. So if you are cutting from Illustrator to Word would it not make sense that the clipboard formats would be Illustrator (for perfect fidelity), SVG (to at least get scalability) and PNG (to at least get graphics)?
> Svg is generic like ascii, not all encompassing like
> unicode.
I don't see how "generic" and "all encompassing" are opposites. Furthermore, I don't see ASCII and Unicode as being opposites but rather living on different points on a spectrum. Some hate Unicode because it is too lossy. Others feel that in trying not to lose much it became too complicated (i.e. not lossy enough). Most people just figure they should use it when it fits and use something else when it doesn't.
> That is a good analogy of why it can't be used as an
> interchange format for anything but simple cases where
> you don't mind loss.
I don't see how "simple cases" have anything to do with it. You either can afford to lose what you lose by going through the interchange format (whether it is SVG, Unicode, PNG or ASCII) or you cannot. If you can, you use it and benefit from the fact that you have a way to get your data from point A to point C. If you do not, you had better hope that your point A and point C speak the same language.
> That would be fine, except it is a runtime format. So your
> data is stored across tags, entities, css, javascript, it
> might have to be transformed by xslt or script before
> being viewable, you might have to load bitmaps
> externally, your data might change half way through,
> and now rcc etc etc.
You've conflated a bunch of issues. "Storing data across tags" is never a problem. The other features could be a problem if your exporting program uses them when they are not appropriate. For a simple graphic, Illustrator is not likely to put in a bunch of script. IIRC, the Visio guys said that they worked hard not to use script and used only a tiny bit for doing multi-ended links. So you would lose multi-ended links if you import Visio SVG into something that doesn't suport script. This is a concrete deficiency that can be solved by appropriate standardization (i.e. XLink). By the way, SVG that depends upon XSLT is not SVG.
This makes simple conversions like unicode>ascii pretty much impossible, because your data isn't stored in a consistent manner. That is the big reason it makes a lousy interchange format.
If you think that Unicode doesn't have similar issues you should look into "combining characters". Even XML itself has similar issues. The usual solution is to define normalization forms (as both Unicode and XML have). This is likely to happen in the SVG world when interoperability problems arise. After all, SVG-Tiny, SVG-Basic and SVG-Print are all profiles defined for certain kinds of interoperability.
At this point it is probably more productive for us to wait and see. The Visio group has committed to using SVG for interoperability. The OpenOffice group has also. I think we will see that "in the small" we will see greater interchange capabilities between these programs thanks to this agreement. I also think that in the large we will see this effect multiplied across most applications, especially if Microsoft can be convinced to come on board. I guess you disagree and I'm going to have to agree to disagree.
> Ok, fair enough. Could you define the problem domain of > SVG for me though, or point me somewhere that can?
SVG is destined to be a Web format for vector graphics and a platform for Web-based graphical applications. But deploying standards on the Web takes a long time. In the meantime, subsets or variants of it will be used in a variety of domains like interchange between graphical apps, MMS messaging on cell phones, Intranet-applications, page layout and smart graphics applications. These variants were not the focus of the specification and are thus not all as clearly defined as the full specification (though some of them are).
SVG would have been defined differently if interchange was the only goal but there is a vacuum to be filled there and industry leaders like Microsoft (through Visio), Adobe (through various SVG exports) and Sun (through OpenOffice) are going to try to fill it through SVG. I think that they will find SVG is not a perfectly suited standard (what standard is perfect!) but that it will still be substantially better than the vacuum (very similar to the situations with IP and XML, too other "better than the vacuum" standards). I expect that one or more "interchange" subsets will be defined either implicitly (as they are today) or explicitly (as has been happening more recently) over the next couple of years.
Previous Message
Up
