SVG Tiny Compliance

From Inkscape Wiki
Revision as of 23:48, 6 January 2005 by PeterMoulder (talk | contribs) (* Move some text to Animation-(Timeline) and refer to that page.)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

It'd be a nice feather in the cap to be able to declare full compliance to one of the SVG specs. SVG Tiny is a good thing to aim for. A number of developers have voiced support for trying to achieve this.

As a first glance without looking much at either the spec or inkscape source, I believe we need the following: don't rely on style attributes working (use fill=... attributes); switch; SVG fonts; animation.

In more detail:

Styling:

  • We must write `fill="..." etc. attributes instead of using style="fill:...". (I.e. when writing SVG Tiny documents, we must not use style attributes -- or at least use only "redundant" style attributes if that's easier to implement.)

<switch>:

  • Minimum requirement is that we render it correctly (e.g. as a viewer would, showing just one child). Interface for viewing other branches would be nice (perhaps a non-modal dialog box listing the children named by their requiredFeatures, requiredExtensions and systemLanguage attributes. The layers dialog box may be a good base.

SVG fonts: font, font-face, font-face-src, font-face-name, missing-glyph, glyph:

  • massifr has started work on this. He's still new to inkscape source code, so could use guidance.

Anchors (<a>):

  • Especially relevant to Inkview. Inkscape can create <a> elements with right-click on an existing item, and has a textual dialog box for filling in attribute values (object-attributes.cpp). We have a "follow link" item in the contextual menu, but it does nothing (object-ui.cpp:sp_anchor_link_follow).

Animation: animate, animateColor, animateMotion, animateTransform, mpath, set:

  • My reading is that we can't claim to support all of SVG Tiny without supporting animation.
  • See Animation-(Timeline) for implementation notes.

(<foreignObject>: I believe we don't need to do anything to support the foreignObject element. We already have the property of not discarding unrecognized elements like foreignObject and its children.)