[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [cgmopen-members] CGM-SVG draft for meeting
CGM Open members, Attached is an input document for the Sunday meeting. It is still a rough draft/outline, but is a reasonable start on the requested analysis: CGM versus SVG for technical graphics. (Another input document is coming in next mail.) See you Sunday, -Lofton.Title: Applicability of CGM versus SVG for technical graphics
2nd Draft: 18 September 2002
By: Lofton Henderson
Contribution to Dieter Weidenbrueck, who is managing the assembly of a document about the current use of CGM and potential use of SVG for technical illustrations in (especially) Web-based documents.
This paper is an objective and dispassionate look at the requirements of technical illustration in our application community, and how the two formats measure up, from both technical and interoperability perspectives.
This draft is a rough proposed outline. In many cases, there are only placeholders for known issues.
(LH note: This draft is a little short on WebCGM/ATA "downside", which probably lies mostly within the interoperability chapter, and doesn't take a careful look at "implementation completeness" aspects of interoperability. Also maybe there needs to be something said about private flavors like ActiveCGM.)
[...tbd...easier to write after we're done]
Paper should cover these topics:
1.) CGM historical development, requirements, use and graphical legacy in technical environment...
2.) the W3C "party line" about SVG (graphic arts) and WebCGM (technical);
3.) a look at and analysis of specific technical aspects
4.) a look at inteoperability considerations
We could get a lot of stuff here from our slide talks at XML200x, tutorials, etc.
The key point is: the functionality of CGM:1999 (esp V3/V4) is aimed exactly at the requirements from technical documents. ATA profile is aimed at these requirements in air transport industry. WebCGM is aimed at these requirements for general technical graphics on the Web.
...fill in scope, goals, requirements -- graphic arts quality, dynamic, interactive Web pages...
Do we want to summarize it here? It is the party line not by virtue of anything that is posted on the W3C web site, but by virtue of the agreed statements of Lilley/Weidenbrueck in several public presentations (XML200x). [Hmm... if we do a good, neutral job on this, maybe W3C will also be interested to post CGM-SVG clarification? Maybe, maybe not. Esp if any assertions are contentious in the interoperability part -- that's religion. The technical parts are easier -- science.]
CGM pretty rich static graphics. WebCGM narrowly targeted at web tech graphics. SVG is very rich, SVG is a graphic arts drawing model. No support for scaling and specification modes applicable to stuff like line width, etc. ...finish this...
(In CGM:1999, and in ATA now. Projected for WebCGM 2.0. Not defined in SVG 1.0).
Placeholder for Dieter's contribution, per his email message of 19th August. I have skimmed it once, and most seems right, and it overlaps some other topics that I listed above -- pic behaviors, obj behaviors, etc.
See also my contribution/analysis (SVG #2) on the SVG 1.0 definitions for some limited behaviors, and SVG product support of same.
Explicit in WebCGM; merely a suggested use of 'title' in SVG.
WebCGM everything is spelled out -- specific required resource limits on every aspect; SVG nothing is limited. E.g., raster size limits? E.g., SVG requires PNG and JPEG, but also allows any other that anyone wants to use. E.g., 4096 limit on WebCGM polybezier, no limit on SVG.
Prohibited in WebCGM. Completely unrestricted in SVG, including: private elements and attributes, inclusion of non-SVG foreign objects, inclusion of arbitrary content from other namespaces, etc.
See for example the private Adobe CSS styles on their public current support matrix (available at http://www.adobe.com/svg/indepth/pdfs/CurrentSupport.pdf)
The only way in SVG that you can get an exact text result is to embed the font definition in the picture file. This applies not only to font style and selection, but to text sizes and other visual text attributes. WebCGM has minimum set of required fonts of all conforming viewers, plus stringent fidelity and accuracy requirements. (Plus it has a capability for extended font support, Font Properties, but I doubt it's implemented).
There are several WebCGM plug-ins that support inter-content-type object linking. There are several that have resolved the "fragment bug".
There is not one SVG plug-in that even executes the SVG-to-SVG linking (lrh todo: verify this on SVG TS for most recent Adobe plug-in. Done -- so support for xlink:show, no support for svgView "target", etc.). No fragment bug fixes.
WebCGM: "adequate" number of implementations, incl several plug-ins; substantially complete (for WebCGM), though some features like unicode are not universally supported (not needed for ATA); commercially supported, some freely available for some use, others licensed with purchaseable support.
SVG: huge number of implementations, but apparently only one plug-in; the Adobe plug-in is fairly complete, but even so its feature support matrix shows limitations; batik (standalone viewer) is probably next in completeness, and the many others are far less complete. See the viewers product listing on the SVG web site, and look for example at IONIC (follow link to implementations).
Question. Do newer batik releases support any plug-in capability? Not according to Batik site.
There is an interesting view of the completeness of several implementations at the SVG Conformance Suite Implementation Status, however note that the matrix is almost a year old, and at least the two dominant implementations are more complete now (see individual product status in the viewers product listing for updates)
Similar product data to this is scheduled to be posted to the CGM Open web site by October, 2002. Completeness and conformance assessment pro-formas will be provided.
SVG 1.0: 125 BE tests spanning entire standard (static graphics, dynamic/DOM, animation, etc).
ATA: ~250 BE plus DT tests spanning the static graphics.
WebCGM: ~230 BE+DT tests for static graphics, ~25 BE tests for Dynamic.
Overall, a policy of strict conformance is needed in this community (ATA, WebCGM, etc). Strict conformance is expressed in a strict profile.
CGM:1999 did not have strict conformance. The ATA and WebCGM profiles are strict. Several vendors have bought into it. There is a test suite, including DT tests as well as BE.
SVG 1.0 definitely does not have strict conformance. There is no strict profile. Fact (supported by extensive experience w/ CGM and other standards): no one should go near SVG, or any graphical format, for technical graphics applications without a strict profile. Suppose someone took the time to write and publish one (probably a 1-2 year process, by the time all consensus is reached)? Question: would the one-and-only plug-in maker pay attention? Past experience suggests "no".
There have been a number of little SVG 1.0 interop incidents, as you could probably deduce from the SVG public comments list, or the SVG working group list (member-only). But of course, we can all quote CGM ones as well. Still, a couple of simple examples might be informative. It would be useful to look at some of the SVG public comment and discussion lists, where you might find stuff like complaints about Adobe AI10 use of private attributes (compositing methods). The point here is not necessarily that SVG is worse than WebCGM regarding interoperability incidents. The point is that it, like all open interchange formats, suffers from the same difficulties -- it is not a panacea, and the same problems would have to be worked out.
blah...blah...blah
(SVG is cool but: technically deficient in a number of ways; some people think the scope of its interoperability issues is yet to be appreciated, because it hasn't yet been applied seriously in a rigorous, mission-critical technical environment.
(WebCGM is tailored at exactly reproducible results across implementations, in all graphical and intelligent aspects. SVG will be problematical to get identical results across implementations."
(To make SVG work, you'd have to add some technical stuff -- including fundamental drawing model enhancements -- and limit it as strictly interop-wise as WebCGM. So ... why bother? Why do all of that when WebCGM already exists?)
(this must be revised).
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC