WebCGM vs SVG:Applicability for Technical

GraphicsLofton 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 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

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:

Format Compression File size Second file

WebCGM G4 compression 65 KB -

SVG with ref JPEG 1 KB 1,282 KB

SVG with ref PNG 1 KB 150 KB

SVG Included 1,732 KB -

SVGz Included 990 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, 38000-

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

http://www.w3.org/graphics/svg

http://www.cgmopen.org