webcgm vs svg applicability for technical graphics
Download
Skip this Video
Download Presentation
WebCGM vs SVG: Applicability for Technical Graphics

Loading in 2 Seconds...

play fullscreen
1 / 28

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


  • 764 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
ad