Webcgm vs svg applicability for technical graphics
Download
1 / 28

WebCGM vs SVG: Applicability for Technical Graphics - PowerPoint PPT Presentation


  • 757 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'WebCGM vs SVG: Applicability for Technical Graphics' - liam


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Webcgm vs svg applicability for technical graphics

WebCGM vs SVG:Applicability for Technical Graphics

Lofton Henderson

Dieter Weidenbrück


Webcgm focus target
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
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 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
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
Important differences

  • Object linking

  • DOM, Event model

  • Animation

  • Styling

  • Encoding and File sizes

  • Embedded raster images


Object linking
Object linking

  • Required: navigation from text to an object and highlighting

  • Example


Object linking in webcgm
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
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
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
DOM and Event Model

  • WebCGM:

    • Under construction, nothing available right now

  • SVG:

    • Fully developed, very powerful


Animation
Animation

  • WebCGM:

    • Not planned

  • SVG:

    • The only choice for standards-based animation


Styling
Styling

  • WebCGM:

    • Under construction (CSS) for dynamic changes at runtime

  • SVG:

    • Fully developed, part of requirement list


Encoding and file sizes
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
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



Interoperability a fable
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
Interoperability framework

  • Extensions

  • Resource limits

  • Language flavors and profiles

  • Predictability of text model

  • Completeness of implementations

  • Test suites

  • Maturity and stability


Extensibility
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?!)


Resource constraints
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
    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
    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
    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
    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
    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
    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


    Conclusions1
    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

    Q and Ahttp://www.w3.org/graphics/svghttp://www.cgmopen.org


    ad