Web CGM vs SVG Applicability for Technical Graphics

Web. CGM vs SVG: Applicability for Technical Graphics Lofton Henderson Dieter Weidenbrück

Web. CGM 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, highquality, dynamic Web pages, …

W 3 C Positioning • “W 3 C scalable graphics requirements” – Web. CGM: partial; SVG: full • “W 3 C Graphics Activity Statement” – Two different markets for vector graphics • Presentations by Lilley-Weidenbrück – SVG: high end creative graphics, general Web use – Web. CGM: 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 Web. CGM • 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(my. Obj 1, 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 • Web. CGM: – 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 • Web. CGM: – Under construction, nothing available right now • SVG: – Fully developed, very powerful

Animation • Web. CGM: – Not planned • SVG: – The only choice for standards-based animation

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

Encoding and File Sizes • Web. CGM – 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 • Web. CGM – Embedding with run-length, G 3, G 4, 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 base 64 encoded form

Embedded raster images • Example: Format Compression Web. CGM G 4 compression SVG with ref File size Second file 65 KB - 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 • Web. CGM – GDP, ESCAPE; private fonts; linetype, markers, … – Web. CGM: prohibited! Incl. comments (AD) !!! • SVG – Foreign namespace extensions, fonts, optionality, … – No constraints on usage, no mitigation requirements • (What is the “X” in XML? !)

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

Text predictability • Web. CGM: – 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” • Web. CGM: “good” (… data coming) • The difference: size and complexity (& maturity) • SVG >> CGM: 1999 >> Web. CGM • Web. CGM tosses: adv. color controls, text-on-path, conics, NURBS, segments, bundles, clip/shield • Selectively: Tiny > Web. CGM & Tiny < Web. CGM • 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 • Web. CGM 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/Web. CGM • Nothing for first 8 years. • Excellent basic TS now.

Maturity and stability • CGM • base CGM: 15+ years; Web. CGM 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 Web. CGM for its – Specificity – Stability & Maturity – Reliability

Q and A http: //www. w 3. org/graphics/sv g http: //www. cgmopen. org