WebCGM vs SVG: Applicability for Technical Graphics Lofton Henderson Dieter Weidenbrück
Dec 10, 2015
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