WebCGM vs SVG: Applicability for Technical Graphics

1
WebCGM vs SVGApplicability for Technical
Graphics

• Lofton Henderson
• Dieter Weidenbrück

2
WebCGM focus target

• long evolution from CGM1987
• simple graphical functionality
• vectorraster, 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 vectorraster 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.cgmname(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 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

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

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 -
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 gtgt CGM1999 gtgt WebCGM
• WebCGM tosses adv. color controls, text-on-path,
  conics, NURBS, segments, bundles, clip/shield
• Selectively Tiny gt WebCGM Tiny lt 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