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

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

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, …

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

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

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

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

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

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

Out-of-line Links Objects dont 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

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

Animation WebCGM: –Not planned SVG: –The only choice for standards-based animation

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

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

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

Embedded raster images Example: FormatCompressionFile sizeSecond file WebCGMG4 compression65 KB- SVG with refJPEG1 KB1,282 KB SVG with refPNG1 KB150 KB SVGIncluded1,732 KB- SVGzIncluded990 KB-

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

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

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

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

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.

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

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

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.

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

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

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

Q and A g