1 / 28

WebCGM vs SVG: Applicability for Technical Graphics

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

liam
Télécharger la présentation

WebCGM vs SVG: Applicability for Technical Graphics

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

  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.cgm#name(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 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

  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:

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

  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

More Related