Difference between revisions of "SVG Tiny Compliance"

From Inkscape Wiki
Jump to navigation Jump to search
 
m (Reverted edits by UcqN9w (Talk); changed back to last version by Jonas Adolfsson)
 
(28 intermediate revisions by 9 users not shown)
Line 1: Line 1:
> What do you think if we set a goal for 0.42 or 0.43 to fully support
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.
> 100% of SVG Tiny?  That'd be a nice feather in the cap to be able to
> declare full compliance to one of the SVG specs.


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


  Styling
In more detail:
    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
Styling:
    viewer would, showing just one child).  Interface for viewing other
* 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.)
    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,
<switch>:
  missing-glyph, glyph
* 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 attributesThe layers dialog box may be a good base.
    massifr has started work on thisHe's still new to inkscape
    source code, so could use guidance.


  a  Especially relevant to Inkview.  For Inkscape (editor), ability
SVG fonts: font, font-face, font-face-src, font-face-name, missing-glyph, glyph:
    to launch URLs from the context menu might be nice but not
* massifr has started work on thisHe's still new to inkscape source code, so could use guidance.
    essentialAn ability to create <a> elements other than using the
    XML editor would also be nice.


  Animation: animate, animateColor, animateMotion, animateTransform,
Anchors (&lt;a&gt;):
  mpath, set
* 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).
    My reading is that we can't claim to support all of SVG Tiny
    without supporting animation.


    Easier in a viewer than in an editor... For editing interface,
Animation: animate, animateColor, animateMotion, animateTransform, mpath, set:
    Brisgeek says that Macromedia Flash is a good example.  He couldn't
* My reading is that we can't claim to support all of SVG Tiny without supporting animation.
    off hand think of free software examples, but mentioned Moho as a
* See [[Animation-(Timeline)]] for implementation notes.
    gratis-but-non-free example.  (Written in Java.)
    F4L is a non-functional free-software mock-up of the Flash 4 interface.
    Of course we should search for existing relevant free software.


    For advanced stuff (research territory), we may be able to work
(&lt;foreignObject&gt;: I believe we don't need to do anything to support the foreignObject elementWe already have the property of not discarding unrecognized elements like foreignObject and its children.)
    with the project Opera people at INRIA, possibly working with the
    Madeus editor(I mention this example only because our group at
    Monash has worked with them before.)


(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.)
Looking back at the full SVG (1.1) spec, is Inkscape already able to claim to be a "[http://www.w3.org/TR/SVG11/conform.html#ConformingSVGGenerators Conforming SVG Generator]", for which I think lack of animation/filtering features would not be a problem (it seems to me that it doesn't matter what features you support, as long the generated file is valid SVG) but compliance with the Priority 1 accessibility guidelines from the "[http://www.w3.org/TR/ATAG10/ Authoring Tool Accessibility Guidelines 1.0]" would be necessary. http://www.w3.org/TR/SVG11/access.html outlines how accessibility applies to SVGSome low-hanging fruit would be better support for [http://www.w3.org/TR/SVG11/struct.html#TitleElement <tt>title</tt>] and [http://www.w3.org/TR/SVG11/struct.html#DescElement <tt>desc</tt>] elements (e.g. from the Object Properties dialog box) and the [http://www.w3.org/TR/REC-xml/#sec-lang-tag <tt>xml:lang</tt>] attribute for text spans (whose initial implementation could be as simple as a textbox in the Text&amp;Font dialog box).
 
We would not, however, be able to claim to be a "[http://www.w3.org/TR/SVG11/conform.html#ConformingSVGInterpreters Conforming Static SVG Interpreter]" or "[http://www.w3.org/TR/SVG11/conform.html#ConformingSVGViewers Conforming Static SVG Viewer]" until [http://www.w3.org/TR/SVG11/feature.html#SVG-static more features] were supported, e.g. filters and SVG fonts.
 
 
=== Research ===
 
* Check out all these [http://svg.org/special/svg_phones phones] that use svg now!!!
* Check out [http://www.ikivo.com/animator/index.html Ikivo Animator]
* Check out [[Beatware Mobile Designer]]
 
[[Category:Developer Discussion]]

Latest revision as of 15:36, 20 April 2007

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


Looking back at the full SVG (1.1) spec, is Inkscape already able to claim to be a "Conforming SVG Generator", for which I think lack of animation/filtering features would not be a problem (it seems to me that it doesn't matter what features you support, as long the generated file is valid SVG) but compliance with the Priority 1 accessibility guidelines from the "Authoring Tool Accessibility Guidelines 1.0" would be necessary. http://www.w3.org/TR/SVG11/access.html outlines how accessibility applies to SVG. Some low-hanging fruit would be better support for title and desc elements (e.g. from the Object Properties dialog box) and the xml:lang attribute for text spans (whose initial implementation could be as simple as a textbox in the Text&Font dialog box).

We would not, however, be able to claim to be a "Conforming Static SVG Interpreter" or "Conforming Static SVG Viewer" until more features were supported, e.g. filters and SVG fonts.


Research