Difference between revisions of "SVG Tiny Compliance"
PeterMoulder (talk | contribs) (* Move some text to Animation-(Timeline) and refer to that page.) |
|||
(2 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
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.) | |||
Revision as of 23:48, 6 January 2005
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.)