WebCGM vs SVG: Applicability for Technical Graphics

1. WebCGM vs SVG:Applicability for Technical Graphics Lofton Henderson Dieter Weidenbrück

2. WebCGM focus & target • long evolution from CGM:1987 • simple graphical functionality • vector+raster, binary, standalone • specific intelligent content for • hyperlinking, search, query • structuring and HTML/XML integration • stringent interoperability framework • Target: Web-based technical graphics

3. SVG focus & target • Since September 2001 • Very rich vector+raster graphical model • comparable to best proprietary graphic arts • XML language, XML-family integrated • DOM, CSS, SMIL, Xlink, Xpointer, RDF, … • Highly extensible and customizable • Focus: creative graphics & design, high- quality, dynamic Web pages, …

4. W3C Positioning • “W3C scalable graphics requirements” • WebCGM: partial; SVG: full • “W3C Graphics Activity Statement” • Two different markets for vector graphics • Presentations by Lilley-Weidenbrück • SVG: high end creative graphics, general Web use • WebCGM: technical graphics & Web techdoc • Each to its own purpose • Coexist and complement

5. Technical Graphics Requirements • Complex geometry with modest graphical requirements • Precision • Text • low typographical requirements • precision • Metadata requirements – modest but very specific • Reliability • Reusability and longevity • Interoperability

6. Important differences • Object linking • DOM, Event model • Animation • Styling • Encoding and File sizes • Embedded raster images

7. Object linking • Required: navigation from text to an object and highlighting • Example

8. Object linking in WebCGM • possible using URI fragment • addressing by unique ID or non-unique name • addressing of all objects with same name • object behaviors: view_context and highlight • …/abc.cgm#name(myObj1,view_context) • implemented by all viewers

9. Object linking in SVG • linking to object using its ID • not possible to address objects using a common name except for groups • results in establishing the view of the parent svg element unless a view element has been specified • highlighting using the view target • no implementations of this seen so far

10. Out-of-line Links • Objects don’t carry a link on them, all linking is handled outside of the graphics file • WebCGM: • one event handler for all objects (not fully standardized yet) • straightforward implementation • SVG: • Objects are clickable only if there is a link attached to them • Alternative: assign an event handler to each object on the illustration – impractical for large scale projects with thousands of objects • Alternative 2: lots of scripting on the outside

11. DOM and Event Model • WebCGM: • Under construction, nothing available right now • SVG: • Fully developed, very powerful

12. Animation • WebCGM: • Not planned • SVG: • The only choice for standards-based animation

13. Styling • WebCGM: • Under construction (CSS) for dynamic changes at runtime • SVG: • Fully developed, part of requirement list

14. Encoding and File Sizes • WebCGM • binary format • Text encoding available • XML encoding under discussion • SVG • XML encoding, human readable but large (8-10 times bigger than a binary file) • Alternative: SVGZ, gzipped version of the file that is small but no longer human readable

15. Embedded raster images • Major requirement in Technical Illustration • WebCGM • Embedding with run-length, G3, G4, JPEG, PNG compression • No separate file necessary • SVG • Embedding possible using the image element • Raster content resides in second file (external reference) or is included in base64 encoded form

16. Embedded raster images • Example:

17. Interoperability – a fable • Once upon a time … a brilliant star called CGM • Enthusiastically acclaimed, 250 products, buzz • Virtuous and technically excellent • But a dark shadow came over the land… • Incomplete implementations • Incorrect implementations • Private functional extensions • No one understood each other anymore • Many years of hard discipline to struggle back to the light

18. Interoperability framework • Extensions • Resource limits • Language flavors and profiles • Predictability of text model • Completeness of implementations • Test suites • Maturity and stability

19. Extensibility • #1 on the axis of interoperability evils • Private functions • Optionality & discretionary features • Implementation dependent behaviors • WebCGM • GDP, ESCAPE; private fonts; linetype, markers,… • WebCGM: prohibited! Incl. comments (AD) !!! • SVG • Foreign namespace extensions, fonts, optionality,… • No constraints on usage, no mitigation requirements • (What is the “X” in XML?!)

20. Resource constraints • WebCGM: everything has limits • Raster size & formats, polygon vertexes, fonts,.. • SVG: nothing limited • 9.7GB raster valid, any raster format, 38000-segment filled polybezier, … • Specify maxima for generators • Which are sufficient minima for viewers

21. Text predictability • WebCGM: • limited fonts plus boxed text model, • low typographic sophistication, • high fidelity & predictability. • SVG: • typographically rich, • CSS font matching, • potential low fidelity & predictability, • … unless you embed font/glyph definitions.

22. Implementation completeness • A look at the situation • SVG: a look at “Impl Status Matrix” • WebCGM: “good” (… data coming) • The difference: size and complexity (& maturity) • SVG >> CGM:1999 >> WebCGM • WebCGM tosses: adv. color controls, text-on-path, conics, NURBS, segments, bundles, clip/shield • Selectively: Tiny > WebCGM & Tiny < WebCGM • Is this a problem? • Yes, unless your sector can sole-source – 1 vendor • 98% complete is not good enough (for tech. gfx.)

23. Language flavors and profiles • Implementation fragmentation into flavors: • Subset implementations, resource limits • Extensions, discretion & optionality • WebCGM profile • Unambiguous uniform requirements • No-loopholes strict conformance policy • SVG ‘basic’ and ‘tiny’ profiles • Nested functional subsets (levels) • No constraints on extensions, optionality, resources... • “Loose” conformance framework

24. Test suites • The value of test suites (TS): • Measure implementation correctness • Assess implementation completeness • Feedback to standard! • SVG • Excellent basic TS from early (Candidate Rec) • “Any new function proposal must have test(s)” • CGM/WebCGM • Nothing for first 8 years. • Excellent basic TS now.

25. Maturity and stability • CGM • base CGM: 15+ years; WebCGM profile: 4+ • Virtually zero errata • Small but committed vendor group • SVG • “Youthful” (2+ yrs): errata, interpretations, ... • Interoperability framework too loose to stop flavors fragmentation. • Effective use of TS for ad-hoc interop fix-ups • Energy & effort from several large implementers

26. Conclusions • Technical issues • e.g. embedding of raster files • Linking and navigation issues • e.g. link between callout and parts list entry • Re-usability • Archive and Revisions • Interoperability issues • Identical results across implementations

27. Conclusions • SVG has a great potential and great functionality • It should be used what it has been written for – creative graphics • For technical graphics, we prefer WebCGM for its • Specificity • Stability & Maturity • Reliability

28. Q and Ahttp://www.w3.org/graphics/svghttp://www.cgmopen.org