Inkscape Wiki - User contributions [en]

Swatch Book

2008-05-15T07:05:02Z

PeterMoulder: /* Software Support */ partially fill in inkscape row

= Overview =

This page is for discussing the concepts around swatch books, for Inkscape and any other programs, and what things users might want.

Feel free to contribute here, on the mailing lists, or in our Jabber/IRC chat rooms.

== What is a Swatch Book? ==

Basically a "Swatch Book" is a collection of swatches that an artist or designer might put together for reference during a project.

Although a large number of people are familiar with various commercial spot color books, a swatch book is not limited to just colors. Decorators, designers and others often have books with more than simple color chips. That leads into the question of just what is a 'swatch' - [[JonCruz]]

== What is a "Swatch"? ==

In general artistic design work, I normally hit a different
definition of "swatch". It's not just a color, it's a "sample" or
"material". It could be a simple solid ink color, or it could be a
heavy plaid cloth. Moving into software, "Gold" is another good
example. "Gold" is a texture, not a color (just ask the Blender
artists out there). From an artist/designer's viewpoint, they tend to
think in terms of a swatch book as "a collection of things I've
pulled together to use for this project". I *think* some of the
problem comes from saying "Pantone swatch book" and such but not
keeping in mind that it is just a subset of general "swatch books".
That is, it is a "swatch book but with only solid paint swatches".
Then again... I have used foil Pantone books, so those definitely
fall into the "material, not just color" category. - [[JonCruz]]

Some examples I've seen in swatch books are
* Fabric
* Ribbon
* Paint
* Spot color samples (Pantone, Trumatch, Focoltone, Toyo, etc)
* Paper
* Wood
* Flooring
* Tile
* Counter material

The key here might be to think "material" instead of just "color". Although one might work with just colors, others might want to extend to a bit more.

= Use Cases =

And think of the use case. Say a comic artist is working on a
project. He would probably want a "swatch book" for each of his
characters, and perhaps one combining them. Then he might also want
to add a book per character per lighting condition ("daytime",
"nighttime", etc). When he went to use it, he might like to just
select "Fred's skin" and apply it to an area. Then "Fred's shirt" for
another. Those might just be simple RGB colors, or the skin might be
a simple gradient and the shirt might be a checked pattern.

However... the artist most definitely would benefit from being able
to define those books once and then just reference them from each of
the programs he uses to create things. - [[JonCruz]]

I think it would also be good if we could educate the comic artists on SVG Blend modes work, this way there would be no need to have separate color swatches for time of day. You could easily overlay a colored/gradiated rectangle within a frame and use multiply or another blend mode. Then again, that's also a preference of workflow.- [[ScislaC]]

= Swatches in SVG/Inkscape =

For SVG work, we'd probably like to be able to include gradients and
patterns also. "Brushes" might also be nice... but I think those are
something a bit different. For the apps I've seen that differentiate
brushes from patterns, brushes get to be more of blobs of complex
procedural code. - [[JonCruz]]

This involves more than just the swatches, but I found the brush weight profiles in Xara X[1|treme] quite intuitive. Basically it's now doable in 0.46 with LPE and an auxiliary shape that defines the variable brush weight, but Xara's simple dropdown of pre-defined profiles worked quite well. Just a thought. - [[jegHegy]]

I think all mentioned uses of swatches are applicable. As for brushes, yes, I think those would be great as well. If we can have a standard cross-application compatible way to include those and then leave it up to the applications to implement how they want to utilize them, that would be optimal. In addition to brushes, having a symbols library implemented in a swatch book would also be greatly helpful. - [[ScislaC]]

= Mockups =

TBD

= Software Support =

The purpose of this table is first of all to find what apps support each feature, so that we can then look into each of those to make sure that we support everything that each app needs to be sharable in a swatchbook.

{| class="wikitable" border="1"
|-
! App
! Color
! Gradient
! Pattern
! Filter
! Brush
! Shape
|-
| [http://www.inkscape.org/ Inkscape]
| yes, rich
| linear and radial only
| yes, vector
| ?
| not really
| ?
|-
| [http://www.blender.org/ Blender]
| ?
| ?
| ?
| ?
| ?
| ?
|-
| [http://www.cinepaint.org/ CinePaint]
| ?
| ?
| ?
| ?
| ?
| ?
|-
| [http://www.gimp.org/ GIMP]
| ?
| ?
| ?
| ?
| ?
| ?
|-
| [http://kolourpaint.org/ KolourPaint]
| ?
| ?
| ?
| ?
| ?
| ?
|-
| [http://www.koffice.org/krita/ Krita]
| ?
| ?
| ?
| ?
| ?
| ?
|-
| [http://www.scribus.net/ Scribus]
| ?
| ?
| ?
| ?
| ?
| ?
|}

= References =

* [http://lists.freedesktop.org/archives/create/2007-September/000994.html My post] to the CREATE list on Sep 27, 2007.

Swatch Book

2008-05-15T06:44:05Z

PeterMoulder: /* Software Support */ explain purpose of table

= Overview =

This page is for discussing the concepts around swatch books, for Inkscape and any other programs, and what things users might want.

Feel free to contribute here, on the mailing lists, or in our Jabber/IRC chat rooms.

== What is a Swatch Book? ==

Basically a "Swatch Book" is a collection of swatches that an artist or designer might put together for reference during a project.

Although a large number of people are familiar with various commercial spot color books, a swatch book is not limited to just colors. Decorators, designers and others often have books with more than simple color chips. That leads into the question of just what is a 'swatch' - [[JonCruz]]

== What is a "Swatch"? ==

In general artistic design work, I normally hit a different
definition of "swatch". It's not just a color, it's a "sample" or
"material". It could be a simple solid ink color, or it could be a
heavy plaid cloth. Moving into software, "Gold" is another good
example. "Gold" is a texture, not a color (just ask the Blender
artists out there). From an artist/designer's viewpoint, they tend to
think in terms of a swatch book as "a collection of things I've
pulled together to use for this project". I *think* some of the
problem comes from saying "Pantone swatch book" and such but not
keeping in mind that it is just a subset of general "swatch books".
That is, it is a "swatch book but with only solid paint swatches".
Then again... I have used foil Pantone books, so those definitely
fall into the "material, not just color" category. - [[JonCruz]]

Some examples I've seen in swatch books are
* Fabric
* Ribbon
* Paint
* Spot color samples (Pantone, Trumatch, Focoltone, Toyo, etc)
* Paper
* Wood
* Flooring
* Tile
* Counter material

The key here might be to think "material" instead of just "color". Although one might work with just colors, others might want to extend to a bit more.

= Use Cases =

And think of the use case. Say a comic artist is working on a
project. He would probably want a "swatch book" for each of his
characters, and perhaps one combining them. Then he might also want
to add a book per character per lighting condition ("daytime",
"nighttime", etc). When he went to use it, he might like to just
select "Fred's skin" and apply it to an area. Then "Fred's shirt" for
another. Those might just be simple RGB colors, or the skin might be
a simple gradient and the shirt might be a checked pattern.

However... the artist most definitely would benefit from being able
to define those books once and then just reference them from each of
the programs he uses to create things. - [[JonCruz]]

I think it would also be good if we could educate the comic artists on SVG Blend modes work, this way there would be no need to have separate color swatches for time of day. You could easily overlay a colored/gradiated rectangle within a frame and use multiply or another blend mode. Then again, that's also a preference of workflow.- [[ScislaC]]

= Swatches in SVG/Inkscape =

For SVG work, we'd probably like to be able to include gradients and
patterns also. "Brushes" might also be nice... but I think those are
something a bit different. For the apps I've seen that differentiate
brushes from patterns, brushes get to be more of blobs of complex
procedural code. - [[JonCruz]]

This involves more than just the swatches, but I found the brush weight profiles in Xara X[1|treme] quite intuitive. Basically it's now doable in 0.46 with LPE and an auxiliary shape that defines the variable brush weight, but Xara's simple dropdown of pre-defined profiles worked quite well. Just a thought. - [[jegHegy]]

I think all mentioned uses of swatches are applicable. As for brushes, yes, I think those would be great as well. If we can have a standard cross-application compatible way to include those and then leave it up to the applications to implement how they want to utilize them, that would be optimal. In addition to brushes, having a symbols library implemented in a swatch book would also be greatly helpful. - [[ScislaC]]

= Mockups =

TBD

= Software Support =

The purpose of this table is first of all to find what apps support each feature, so that we can then look into each of those to make sure that we support everything that each app needs to be sharable in a swatchbook.

{| class="wikitable" border="1"
|-
! App
! Color
! Gradient
! Pattern
! Filter
! Brush
! Shape
|-
| [http://www.inkscape.org/ Inkscape]
| ?
| ?
| ?
| ?
| ?
| ?
|-
| [http://www.blender.org/ Blender]
| ?
| ?
| ?
| ?
| ?
| ?
|-
| [http://www.cinepaint.org/ CinePaint]
| ?
| ?
| ?
| ?
| ?
| ?
|-
| [http://www.gimp.org/ GIMP]
| ?
| ?
| ?
| ?
| ?
| ?
|-
| [http://kolourpaint.org/ KolourPaint]
| ?
| ?
| ?
| ?
| ?
| ?
|-
| [http://www.koffice.org/krita/ Krita]
| ?
| ?
| ?
| ?
| ?
| ?
|-
| [http://www.scribus.net/ Scribus]
| ?
| ?
| ?
| ?
| ?
| ?
|}

= References =

* [http://lists.freedesktop.org/archives/create/2007-September/000994.html My post] to the CREATE list on Sep 27, 2007.

CSS Support

2008-01-25T05:31:28Z

PeterMoulder: Add information about external stylesheets

=== Current State ===

An initial implementation is now in SVN. Limitations:

* Allows a single <style> element in the document. Doesn't allow external stylesheets, doesn't allow more than one <style> element.
: (Or rather it ignores all but one of the <style> elements, possibly changing which one it respects based on which was most recently re-read.)

* No editing interface other than the XML editor.

: There are a number of aspects of editing:

** The most basic level: allow editing using the XML editor. (See Update section below.)
** Editing a stylesheet.
** Specifying what classes each object belongs to.

* Doesn't respect media restrictions (e.g. ignores "this rule applies only to non-visual media" directives, and doesn't allow having one style for print and another style for on-screen).

* <tt>@font-face</tt> hints are ignored.

* Doesn't handle any other at-rules (<tt>@media</tt>, <tt>@import</tt>, @page, ...).

==== An incomplete list of work needed: ====

* Ensure that this single stylesheet is updated whenever any of the <tt><style></tt> elements change (or are deleted or created etc.).

* Similarly, ensure that the picture is refreshed when the stylesheet is changed.

* Convert the simple user agent style sheet given at http://www.w3.org/TR/SVG11/styling.html#UAStyleSheet to libcroco structures (perhaps by passing strings to libcroco parsing functions) and store in <tt>desktop->style_cascade</tt>.

* Modify style.cpp to query the stylesheet. (Done but not checked in.)

* There may be some work needed for "shorthand properties", e.g. `<tt>marker</tt>' is shorthand for modifying <tt>marker-start</tt>, <tt>marker-mid</tt> and <tt>marker-end</tt> properties (http://www.w3.org/TR/SVG11/painting.html#MarkerProperty). A non-SVG CSS example is `<tt>margin</tt>'.

==== Updating for changes to <style> content ====

State so far: Every keystroke in the xml editor in the content of the <style> element gets sp_style_elem_read_content to be re-read.
One can force an object to get the revised stylesheet info by e.g. <Up> <Down> (forcing an update) then deleting its style attribute.
So one change is that we shouldn't be so keen to put things in the <tt>style</tt> attribute.
Currently, the stylesheet info gets merged into <tt>SPStyle</tt>, and set the <tt>style</tt> attribute to contain everything in <tt>SPStyle</tt> (and clear any styling attributes like <tt>fill=...</tt>).
One existing problem with this behaviour (other than how it interacts with stylesheets) is that we discard any <tt>style</tt> properties we don't know about. Whereas we ought to remember the content of the style attribute and only replace the properties we've changed, and add to if necessary.

One implementation would be to keep <tt>SPStyle</tt> but indicate which properties came from where, and hence which ones need to be written to the style attribute and which ones don't.
Apart from not writing if src==stylesheet, we can also avoid writing if src==attribute: i.e. don't gratuitously break SVG Tiny conformance of a document (or more generally break compatibility with implementations that don't honour CSS <tt>style</tt> attributes).
Not to say that we can't choose to use the <tt>style</tt> attribute for properties that the user changes during an inkscape session, but currently we change from attributes to <tt>style=</tt>... even for shapes that the user just changes the position of without changing any styling stuff.

=== Why can't we use libcroco-0.6's existing libxml interface to cr-sel-eng.c ? ===

Some CSS selectors (http://www.w3.org/TR/REC-CSS2/selector.html) can express "is preceded by X" or "is a descendent of X" (where X can itself be similarly constrained recursively), so we'd pretty much need to maintain the entire document in libxml form if we want to use libcroco for CSS selectors.

Suppose we want to find the style of node N. We pass libcroco a stylesheet and ask it what rules apply to N.
If the stylesheet says "nodes that are preceded by a node that is preceded by a node that's a descendent of (... etc. ...) have red stroking" then libcroco needs to be able to navigate through the tree.
So we can't pass libcroco just a libxml version of node N, we need to fill in its parent and sibling links, providing a libxml node for a significant proportion of all nodes in the tree.
(Short of using hardware watchpoints to check access to the sibling/parent links and supply them lazily.)

=== Notes on how to implement external stylesheets ===

External stylesheets are arguably easier to implement than internal ones: the reference to the stylesheet comes right at the beginning of the xml file before even the top-level <svg> element, so we already know all the styling stuff for <svg> as soon as we reach it. Editing may also be a bit easier, in that external stylesheets usually exist for sharing the same style among many documents, so there's less expectation of being able to edit the stylesheet itself.

The work of actually parsing the stylesheet once it's in memory is already done: see src/sp-style-elem.cpp:sp_style_elem_read_content.

So for read-only support of a single external stylesheet, it may well be just a matter of looking at how we can get XML processing instructions from libxml2 (please add a reference to the relevant documentation or code here once you've looked it up, anyone), and parse the pseudo-xml-attributes (see http://www.w3.org/TR/xml-stylesheet/; note that these aren't real xml attributes that libxml2 handles, so we do the parsing ourselves — or pass the string to a separate libxml2 instance/session/parser).

Then get the CSS from the specified URI (presumably using the same gnome vfs stuff that we currently use for accepting URIs on the commandline, though we could use libcurl instead: man curl, and see the --libcurl option for producing example code!).

Then proceed as sp-style-elem.cpp:sp_style_elem_read_content does (presumably splitting off most of that function into a new function that takes the string as argument).

==== Multiple stylesheets ====

Initially, we would support only a single stylesheet, as libcroco currently doesn't support multiple stylesheets.

If you don't want to change libcroco, then it suffices to concatenate all the stylesheets together; the only thing you lose with that approach is that any parsing errors won't have the right line number, but I believe it gives completely correct results in absence of errors in any of the stylesheets.

The xml-stylesheet spec says that multiple external stylesheets interact the same way as in HTML; the relevant part of the HTML spec is http://www.w3.org/TR/html4/present/styles.html#h-14.3.

[[Category:Developer Discussion]]

Animation-(Timeline)

2005-08-10T00:18:33Z

PeterMoulder: * Add link to Ambulant SMIL 2 viewer

=== User interface for timeline-based animation ===

==== Existing animation programs (Free & non-Free) ====

* MacromediaFlash is a good non-Free example.
* Macromedia Director prior to version MX had a different interface (http://www.rice.edu/fondren/erc/howto/director.html) which I prefer(ed) over Flash
* QFlash is a FUNCTIONAL free-software mock-up of the Flash 4 interface, which can import SVG files but not edit them. (http://qflash.sourceforge.net)
* F4l is a non-functional free-software mock-up of the Flash 4 interface.(http://f4l.sf.net/)
* [[Moho]] as a gratis-but-non-free example. (Written in Java.)
* LimSee2 (http://wam.inrialpes.fr/software/limsee2/) is an excellent almost-free basis. (The web site incorrectly claims open source, but it means only that the source code is visible: the actual license says in capital letters no commercial use or distribution.)
* Spalah Flash (http://spalah.sourceforge.net/?p=10) (not to be confused with Spalah CMS) "is a GTK2/GNOME2 based application for generating Macromedia SWF and W3C SVG animations." The GUI is today minimalist but the author is trying to integrate it with inkscape. See http://spalah.sourceforge.net/?p=19
* SMIL 2.1 player (GPL): http://www.cwi.nl/projects/Ambulant/distPlayer.html
==== Other thoughts ====

Suggestion from someone else: working like CinePaint (compaired with Gimp), with each frame independently from each svg document (working like this or providing this feature) - providing vectorial edition quality we can't get on apps like MacromediaFlash or any other (maybe ToonBoom or Moho) - allowing us to make our work fast publish without further lack of quality.
(One more suggestion about it: being able to convert .swf to .svg sequence (or animated .sgv) and vice versa.)

It is suggested that there be basically two modes: Local (Object) mode and Global mode. Below is a picture showing a very rough design of the local mode:
http://www.inkscape.org/wiki_uploads/anim_gui1.png

In local modes, all properties of the object editing will be shown on a timeline, and one can create and edit frame within the timeline. Then one may assign different value of that properties on different timeline, or make it change linearly, or inlinearly :)

==== Fantavision example ====
Back in the '80's there was a program on Apple IIE (Amiga and MS-DOS too) called "Fantavision". It allowed one to create vector artwork (although I didn't understand at the time that that was what it was called) and animations. It allowed one to create frames of animation where you manually repositioned, recolored, scaled, rotated etc. the objects from one frame to the next. However, it then automatically interpolated frames between the 2 frames (the number of interpolated frames was configurable) such that it create a smooth transition of the object moving from one frame to the other. The effect was very similiar to the "Morphing" effect for raster graphics (popularized in a Michael Jackson video, I believe). That is, the system calculated the trajectory of "Key Points" of the objects from one frame to the next. This process is often called "Tweening" (a term used by Macromedia Flash). [[Sketch|Skencil]] (formerly known as [[Sketch]]) supports this functionality and describes it as "Blending".

I guess what I'm saying is that I think a nice interface to create animations would be similiar. So to animate you would do the following:

* Draw the initial SVG Image

* Increment Frame (from say 1 to 20)

* Reposition the elements in frame 20 (including scaling, color changes, adding removing objects, etc, etc, etc)

* System would then calculate a trajectory for each key point from frame 1 to frame 20. Trajectories would be calculated for things like:
** Each "node" of an object
** Color
** Transformation Matrix
** etc

* You could display/manipulate the trajectories (using the trajectory editor shown above by the original creator of this topic)

* The system would then store the animations using SVG trajectories and the "Key Points" would be the frames you manually created

:So, to create say a 100 frame animation, one might only need to manually create/modify 10 frames and the system would interpolate the additional frames as necessary.

* Also, once the system interpolated frames it would allow you to manually modify the interpolated frames creating further "Key Points" and allow further refinement and interpolation.

NOTE: 3D apps such as blender also use a technique like this, which I think is most widely known as "keyframe animation" or simply "keyframing". However, many such systems tie the keys too closely to actual animation frames, and this creates problems when the frames-per-second rate changes. Particularly in the case of vector apps which are not so low-level as bitmaps and animation frames, I would suggest that frames should be as abstract as possible.

Having key positions in simple percentages of the total animation time might be a better solution. This would also need to be a global/local system, of course: animated objects would have their own animation time specified when inserted into a larger document. A character's walkcycle would end at 100%, but in the larger animation, it would perhaps only be 5% of the total time, yet repeating as the object moves across the screen.

One issue with this abstraction of frames might be that important animation effects do not occur exactly within frames: small things could be mistimed, or simply missed altogether. If you set the frame rate too low, this would be an obvious side effect, so it's not necessarily a problem
that Inkscape should try to fix. On the other hand, a few things could be done to ease this. For instance, "snapping" animation events to frames when exporting (thereby slightly altering the timing), or perhaps just warning that certain animation events are not visible at such a low frame rate.

Of course, on the web, with SVG and DHTML, where most Inkscape animations will hopefully be used one day, frames are not an issue at all, and we just worry about keys in time :)

SVG Test Suite Compliance

2005-07-25T06:48:53Z

PeterMoulder: * Retract the "still crashes" claim, as that test appears to be from an old version of inkscape

This table summarises the results of testing Inkscape against the [http://www.w3.org/Graphics/SVG/Test/ W3C SVG Test Suite].

Last complete test was performed on Windows with pre-release version Inkscape-0.41+0.42pre2-1.win32.exe. See also
* [[SVG Test Suite Compliance V0.41]]

== Key ==
; '''pass''' : the test passed fully (69 occurences)
; '''partial''' : the test partially failed but it may be easy to make it pass (25 occurences)
; '''fail''' : the test failed (86 occurences)
; '''crash''' : the test failed and Inkscape crashed (1 occurence)

----
== Results ==
=== Animation (not yet supported) ===
; animate-elem-02-t.svg : '''fail'''
; animate-elem-03-t.svg : '''fail'''
; animate-elem-04-t.svg : '''fail'''
; animate-elem-05-t.svg : '''fail'''
; animate-elem-06-t.svg : '''fail'''
; animate-elem-07-t.svg : '''fail'''
; animate-elem-08-t.svg : '''fail'''
; animate-elem-09-t.svg : '''fail'''
; animate-elem-10-t.svg : '''fail'''
; animate-elem-11-t.svg : '''fail'''
; animate-elem-12-t.svg : '''fail'''
; animate-elem-13-t.svg : '''fail'''
; animate-elem-14-t.svg : '''fail'''
; animate-elem-15-t.svg : '''fail'''
; animate-elem-16-t.svg : '''fail'''
; animate-elem-17-t.svg : '''fail'''
; animate-elem-18-t.svg : '''fail'''
; animate-elem-19-t.svg : '''fail'''
; animate-elem-20-t.svg : '''fail'''
; animate-elem-21-t.svg : '''fail'''
; animate-elem-22-b.svg : '''fail'''
; animate-elem-23-t.svg : '''fail'''
; animate-elem-24-t.svg : '''fail'''
; animate-elem-25-t.svg : '''fail'''
; animate-elem-26-t.svg : '''fail'''
; animate-elem-27-t.svg : '''fail'''
; animate-elem-28-t.svg : '''fail'''
; animate-elem-29-b.svg : '''fail'''

=== Colors ===
; color-prof-01-f.svg : '''fail'''
: <i>Tests color profile support. Hopefully the Little CMS work should address this: see InkscapeColor.</i>
; color-prop-01-b.svg : '''fail'''
: <i>there are bugs for variations of this test: see comment in sp_object_get_style_property.</i>
; color-prop-02-f.svg : '''pass'''
; color-prop-03-t.svg : '''pass'''

=== Coordinates ===
; coords-trans-01-b.svg : '''pass'''
; coords-trans-02-t.svg : '''pass'''
; coords-trans-03-t.svg : '''pass'''
; coords-trans-04-t.svg : '''pass'''
; coords-trans-05-t.svg : '''pass'''
; coords-trans-06-t.svg : '''pass'''
; coords-units-01-b.svg : '''partial''' - incorrect clipping
; coords-units-02-b.svg : '''partial'''
; coords-units-03-b.svg : '''partial''' - the red background is not clipped correctly
; coords-viewattr-01-b.svg : '''fail'''
; coords-viewattr-02-b.svg : '''partial''' - viewport boxes not styled correctly
; extend-namespace-01-f.svg : '''fail'''

=== Filters (not yet supported) ===
; filters-blend-01-b.svg : '''fail'''
; filters-color-01-b.svg : '''fail'''
; filters-composite-02-b.svg : '''fail'''
; filters-comptran-01-b.svg : '''fail'''
; filters-conv-01-f.svg : '''fail'''
; filters-diffuse-01-f.svg : '''fail'''
; filters-displace-01-f.svg : '''fail'''
; filters-example-01-b.svg : '''fail'''
; filters-gauss-01-b.svg : '''fail'''
; filters-image-01-b.svg : '''fail'''
; filters-light-01-f.svg : '''fail'''
; filters-morph-01-f.svg : '''fail'''
; filters-offset-01-b.svg : '''fail'''
; filters-specular-01-f.svg : '''fail'''
; filters-tile-01-b.svg : '''fail'''
; filters-turb-01-f.svg : '''fail'''

=== Fonts ===
; fonts-elem-01-t.svg : '''fail'''
; fonts-elem-02-t.svg : '''fail'''
; fonts-elem-03-b.svg : '''fail'''
; fonts-elem-04-b.svg : '''fail'''

=== Interaction (not supported) ===
; interact-cursor-01-f.svg : '''crash''' (on Windows when attempting the interaction)
: <i>Crash now fixed in CVS. (Windows user please confirm, and update counts accordingly.) Thanks to ACSpike for backtrace.</i>
:::does not crash on linux, pre2 - bb
; interact-dom-01-b.svg : '''fail'''
; interact-events-01-b.svg : '''fail'''
; interact-order-01-b.svg : '''fail'''
; interact-order-02-b.svg : '''fail'''
; interact-order-03-b.svg : '''fail'''
; interact-zoom-01-t.svg : '''fail'''

=== Linking ===
; linking-a-01-b.svg : '''fail'''
; linking-a-02-b.svg : '''fail'''
; linking-a-03-b.svg : '''fail'''
; linking-a-04-t.svg : '''fail'''
; linking-uri-01-b.svg : '''fail'''
; linking-uri-02-b.svg : '''fail'''
; linking-uri-03-t.svg : '''fail'''

=== Masking ===
; masking-mask-01-b.svg : '''partial''' - the string is incorrectly rendered (see Fonts above)
; masking-opacity-01-b.svg : '''pass'''
; masking-path-01-b.svg : '''pass'''
; masking-path-02-b.svg : '''partial'''
; masking-path-03-b.svg : '''fail'''
; masking-path-04-b.svg : '''pass'''
; masking-path-05-f.svg : '''partial''' - clip-rule=evenodd not functioning

=== Metadata ===
; metadata-example-01-b.svg : '''pass''' (I think)

=== Painting ===
; painting-fill-01-t.svg : '''pass'''
; painting-fill-02-t.svg : '''pass'''
; painting-fill-03-t.svg : '''pass'''
; painting-fill-04-t.svg : '''pass'''
; painting-marker-01-f.svg : '''pass'''
; painting-marker-02-f.svg : '''partial''' - mishandling of marker strokes
; painting-render-01-b.svg : '''pass'''
; painting-stroke-01-t.svg : '''pass'''
; painting-stroke-02-t.svg : '''pass'''
; painting-stroke-03-t.svg : '''pass'''
; painting-stroke-04-t.svg : '''pass'''

=== Paths ===
; paths-data-01-t.svg : '''pass'''
; paths-data-02-t.svg : '''pass'''
; paths-data-03-f.svg : '''pass'''
; paths-data-04-t.svg : '''pass'''
; paths-data-05-t.svg : '''pass'''
; paths-data-06-t.svg : '''pass'''
; paths-data-07-t.svg : '''pass'''

=== Color Gradients ===
; pservers-grad-01-b.svg : '''pass'''
; pservers-grad-02-b.svg : '''pass'''
; pservers-grad-03-b.svg : '''pass'''
; pservers-grad-04-b.svg : '''pass'''
; pservers-grad-05-b.svg : '''pass'''
; pservers-grad-06-b.svg : '''pass'''
; pservers-grad-07-b.svg : '''pass'''
; pservers-grad-08-b.svg : '''partial''' - gradient is ok; font is incorrect (see Fonts above)
; pservers-grad-09-b.svg : '''pass'''
; pservers-grad-10-b.svg : '''pass'''
; pservers-grad-11-b.svg : '''pass'''
; pservers-grad-12-b.svg : '''pass'''
; pservers-pattern-01-b.svg : '''pass'''

=== Rendering ===
; render-elems-01-t.svg : '''pass'''
; render-elems-02-t.svg : '''pass'''
; render-elems-03-t.svg : '''fail''' - not rendered
; render-elems-06-t.svg : '''partial''' - rendering is ok; font is incorrect (see Fonts above)
; render-elems-07-t.svg : '''partial''' - rendering is ok; font is incorrect
; render-elems-08-t.svg : '''partial''' - rendering is ok; font is incorrect
; render-groups-01-b.svg : '''partial''' - rendering is ok; font is incorrect
; render-groups-03-t.svg : '''partial''' - rendering is ok; font is incorrect

=== Scripting (not supported) ===
; script-handle-01-b.svg : '''fail'''
; script-handle-02-b.svg : '''fail'''
; script-handle-03-b.svg : '''fail'''
; script-handle-04-b.svg : '''fail'''

=== Shapes ===
; shapes-circle-01-t.svg : '''pass'''
; shapes-ellipse-01-t.svg : '''pass'''
; shapes-line-01-t.svg : '''pass'''
; shapes-polygon-01-t.svg : '''pass'''
; shapes-polyline-01-t.svg : '''partial''' - the pentagon ends are incorrect
; shapes-rect-01-t.svg : '''pass'''

=== Structure ===
; struct-cond-01-t.svg : '''fail'''
; struct-cond-02-t.svg : '''fail'''
; struct-defs-01-t.svg : '''pass'''
; struct-dom-01-b.svg : '''fail'''
; struct-dom-02-b.svg : '''fail'''
; struct-dom-03-b.svg : '''fail'''
; struct-dom-04-b.svg : '''fail'''
; struct-dom-05-b.svg : '''fail'''
; struct-dom-06-b.svg : '''fail'''
; struct-frag-01-t.svg : '''pass'''
; struct-group-01-t.svg : '''pass'''
; struct-group-02-b.svg : '''pass'''
; struct-image-01-t.svg : '''pass'''
; struct-image-02-b.svg : '''partial''' - problem with use element
; struct-image-03-t.svg : '''fail'''
; struct-image-04-t.svg : '''pass'''
; struct-image-05-b.svg : '''fail''' - Prints the message: error loading pixbuf at close
; struct-symbol-01-b.svg : '''partial''' - the topleft image is not resized correctly

=== CSS ===
; styling-css-01-b.svg : '''pass'''
; styling-css-02-b.svg : '''pass'''
; styling-css-03-b.svg : '''pass'''
; styling-inherit-01-b.svg : '''pass'''
; styling-pres-01-t.svg : '''pass'''

=== Text ===
; text-align-01-b.svg : '''pass'''
; text-align-02-b.svg : '''fail''' - baseline-shift not functioning
; text-align-03-b.svg : '''pass'''
; text-align-04-b.svg : '''partial''' - tref/t.o.a.p. not supported
; text-align-05-b.svg : '''pass'''
; text-align-06-b.svg : '''fail'''
; text-altglyph-01-b.svg : '''fail'''
; text-deco-01-b.svg : '''partial''' - underline and strikethrough not functioning; whitespace problem
; text-fonts-01-t.svg : '''partial''' - monospaced font is incorrect
; text-fonts-02-t.svg : '''partial''' - font-weight="lighter" not functioning
; text-intro-01-t.svg : '''pass'''
; text-intro-02-b.svg : '''partial''' - right-to-left text not functioning
; text-intro-03-b.svg : '''partial''' - text is vertical but oriented incorrectly
; text-intro-04-t.svg : '''pass'''
; text-path-01-b.svg : '''pass'''
; text-spacing-01-b.svg : '''pass'''
; text-text-01-b.svg : '''fail''' - 'textLength' and 'lengthAdjust' not functioning
; text-text-03-b.svg : '''partial''' - underline and strikethrough not functioning
; text-tref-01-b.svg : '''fail''' - tref not functioning
; text-tselect-01-b.svg : '''pass'''
; text-tspan-01-b.svg : '''partial''' - the red "are" positioned incorrecly
; text-ws-01-t.svg : '''pass'''
; text-ws-02-t.svg : '''pass'''
----

Creating Inkscape distributions

2005-07-16T00:26:49Z

PeterMoulder: *Merge the two mentions of doc/keys.html. Typographical: curly quotes for command disambiguation.

== Creating Dists of Inkscape ==

Those who wish to produce packaged releases of inkscape are welcome to do so.
If it is packages changes that you've made to the official release, please select a
version name that distinguishes it from the official version, to avoid confusion. For
example, “inkscape-0.35-johndoe.tar.gz”. Please consider distributing your changes
as a patch rather than as a full distribution, as patches tend to be easier to
maintain.

Inkscape's release process works like this:

# Start of release process - Finish up work on features.
# Feature Freeze Mode - Shift focus from feature implementation to bug fixing
# Hard Freeze - Two freeze wardens are named. All development must be done as patches submitted to the freeze wardens for review and integration.
# Branch - The codebase is tagged and branched. Final release tarball is posted. The codebase is returned to regular open development.
# Packaging - Three days are allowed for creating release dists (rpm's, deb's, exe's, and autopackages).
# Release Announcement - A Release Announcement and a Press Release are written and circulated to relevant online news sites. Our Freshmeat record is updated.

=== Feature Freeze Mode ===

In the run-up to CreatingDists, for a short time preceding the tagging of the release it's a good idea to hold off on adding new features or doing other major changes like architectural changes to the code that might decrease its stability. Whether a change is minor enough to be “ok” is left to the developer's judgement, and they're trusted to be conservative and careful.

The most useful activity to do during a feature freeze is to locate and/or fix bugs that produce crashes, and to do so with the smallest amount of change to the codebase possible. If a “proper” fix requires architectural changes or redesign of the code, consider writing that up as a post-release task.

-----

It might be useful to branch off a release branch a week before making the release. Hopefully most people using CVS would switch to this branch at this time. Then only bug fixes can go into that branch. --[[Ted]]

=== Branching the release candidate ===

Before release, a branch should have been be created for that release in the form RELEASE_<major>_<minor>_BRANCH. For example, 0.38 should have a branch called RELEASE_0_38_BRANCH.

Minor fixes and code review can then be performed on that branch before the final release; it also permits making future point releases easily (if necessary).

To check out the release branch into a fresh working copy, you can use:

<pre>cvs co -r RELEASE_0_38_BRANCH -d inkscape-0.38-branch inkscape</pre>

or, if you have a checked out tree handy, it is quicker to use:

<pre>
cp -a inkscape inkscape-0.38-branch
cd inkscape-0.38-branch
cvs up -PAd -r RELEASE_0_38_BRANCH
</pre>

Once the release is deemed ready a distribution tarball should be created as below.

=== Creating a distribution source tarball package ===

On the release branch (NOT ON HEAD):

* Set the version name via the file configure.ac in the AC_INIT() macro, Makefile.mingw.common, inkscape.nsi, and in debian/changelog
* Add the release notes into the NEWS file in the release branch
* Run ./autogen.sh && ./configure (with any flags, e.g. CXXFLAGS=).
* Run “cd src && make helper/sp-marshal.h helper/sp-marshal.cpp inkscape_version.h && perl mkfiles.pl && perl mkdep.pl”, then do “cvs -q diff -du make.*|less” to check for anything strange (e.g. source files accidentally added or removed), and finally “cvs commit -m '' make.*”.
* Make sure the code passes a “make distcheck”
* This should produce inkscape-VERSION.tar.gz
* Commit the changed configure.ac and other files to the branch
* Tag the release in CVS

Release tags should be in the form RELEASE_<major>_<minor>_<point>. A non-point-release like 0.38 would get the tag RELEASE_0_38_0, 0.38.1 would get the tag RELEASE_0_38_1, and so on.

On HEAD:

* Add the release notes into the NEWS file in the release branch
* Change configure.ac and inkscape_version.h.mingw to reflect the new future version

=== GPG signing Tarballs ===

Downstream packagers are asking for and may soon demand gpg signed tarballs. For Fedora, this is not a requirement, but does ease acceptance of packages. It also shows we are doing “The Right Thing”. md5sums are not foolproof.

* To create a gpg signed tarball:

<pre>$gpg -u packager@foo.net --armor --output tarball.sig --detach-sig tarball.tar.gz</pre>

* To verify :

<pre>$gpg --verify ./tarball.asc ./tarball.tar.gz</pre>

Of course, this step doesn't mean much in practice unless people have a trust path to your key. Packagers are encouraged to attend key signing parties and take other measures to establish important trust paths to their keys (particularly with downstream packagers).

:Where are the public keys matching these sig's posted?

=== Creating a Windows Distro ===
Inkscape/sodipodi has always been
buildable on Win32. The problem with the sodipodi and original inkscape build, though,
was that the Win32 builder had to download and configure
a lot of things to make it to work. Mingw, MSYS, automake,
autoconf, pkg-config, the codepages, etc. He would spend more
time on THAT than the actual code.

What a pain for the average developer/user who merely wants
to make Inkscape do what he wants it to do. Why waste
days and days getting it to compile, when the developer
would rather be working on the program itself?

So we spent several weeks collecting libraries, building others,
installing the codepages into the source (which we can delete soon
because of Pango) and creating a set of clean makefiles
that work on Win9x, NT, XP, and the cross-compiler.
It is a bit more work for people like me, but hopefully it
attains its goal of saving a lot of work for other people.

Also, remember that on Unix/Linux, $PREFIX is commonly
/usr/local or /usr or something like that. On M$, all of
a program's files are typically located in their own directory. So all
of the files are located relative to “.”. Actually, relative to
the .exe that is currently running.

.....anyway, just wanted to explain that there is a reason
for the Win32 build to be constructed in such a manner,
and that we haven't just been arbitrary.

Once the tree is built (“make -f Makefile.mingw” and “make -f Makefile.mingw dist”) into the “inkscape” directory, the [http://nsis.sourceforge.net/ NSIS] installer script “inkscape.nsi” can be run to create the self-extracting installer.

The Windows download package should be named according to the following scheme:

inkscape-$RELEASE-$PKG.$WINVER.exe

Where $WINVER is the required Windows version, e.g. “win32”. For example:

inkscape-0.37-1.win32.exe

=== Creating a Debian .deb ===

The article [[CompilingDebian]] provides a makefile to download a tarball and build a debian package therefrom.

=== Creating a distribution RPM ===

Method A:
# do as above for tarball, or download the release tarball
# login as root
# rpmbuild -tb inkscape-x.x.tar.gz
# Your RPMs will be in /usr/src/rpm/RPMS (/usr/src/redhat on RH systems)
# RPMs should be GPG signed

Method B:
# do as above for tarball, or download the release tarball
# mkdir ~/rpm
# Copy the tarball to ~/rpm/SOURCES/
# Copy the inkscape.spec from the tarball to ~/rpm/SPECS/inkscape.spec
# rpmbuild -ba ~/rpm/SPECS/inkscape.spec
# Your RPMs will be in ~/rpm/RPMS and ~/rpm/SRPMS
# RPMs should be GPG signed

The rpm should be named according to the following pattern:

inkscape-$RELEASE-$PKG.$DISTRO.$ARCH.rpm

Where:

$RELEASE: the Inkscape release number, such as “0.37”, “0.36.2”, etc.
The third number should be omitted if it is 0. (I.e., 0.37 instead of 0.37.0)

$PKG: A version number for your package. Use a value of 1 for your package, and increment it if you
need to update the released package for some reason.

$DISTRO: The name and an indicator of the version number for the distro. E.g.,
rh71, rh90, mdk91, suse90, fc1, etc. No need to be too exhaustive with the distro versions;
for a given brand of distro it's probably enough to have a reasonably “modern” release
and an older one for legacy support. For instance, rh71 and rh90.

$ARCH: The architecture that the package was built on. E.g., i686, i386, athlon, ppc, etc.
Don't bother with i586 - either i386 or i686 is preferred. The i386 packages will run on Cyrix
and K-6.

Examples:

inkscape-0.37-1.mdk80.i386.rpm
inkscape-0.37-1.mdk80.i686.rpm
inkscape-0.37-1.mdk91.i386.rpm
inkscape-0.37-1.mdk91.i686.rpm

inkscape-0.37-1.fc1.i386.rpm
inkscape-0.37-1.fc1.i686.rpm
inkscape-0.37-1.fc1.athlon.rpm
inkscape-0.37-1.fc1.ppc.rpm

For creating spec files, feel free to list yourself as the packager, but please use
inkscape-devel@lists.sourceforge.net as the contact email address, to ensure that
questions/complaints about the RPM go to the official support channel.

==== Patching RPMs ====

Occasionally, the RPM will not build without some modifications. If the problem is serious enough that it affects every packaging format, this could signal a need to do a point release, but usually you can just add a patch specifically for the RPM. This is what RPM is for, after all. :-)

Here's how to do it:

1. Create a copy of the source tree, with the modifications needed to correct the issue.
2. Generate a patch like this:

$ diff -uNr package-1.0/ package-1.0p/ > ../SOURCES/package-1.0-my.patch

3. Next add the patch to the RPM. In the specfile at %_topdir/SPECS/package.spec, add a line like this at the top of the file:

Patch0: package-1.0-my.patch

Then further down add a line after the %setup section, like this:

%prep
%setup ...
%patch0 -p1

It's a very good idea to split up changes into discrete patches, giving each a different number (they don't have to be consecutively numbered). Also, be sure to upload the patch(es) to the patch tracker so they'll get into the codebase for the next release.

Then rebuild the package like this:

rpmbuild -ba SPECS/package.spec

=== Signing your package ===

First, you need to have a public/private keypair. This can be generated with gpg using 'gpg --gen-key'.

To add a signature to an extisting package, use the command rpm --addsign /path/to/package.rpm To sign in the process of building a package, use rpmbuild -bb --sign

To check the signature on a package, use rpm --checksig.

=== Releasing Dists on the SourceForge File Release Tool ===

To release a file: (You need Release Tech permission for your Inkscape account)

* ftp upload.sf.net (anonymous/anonymous)
* cd incoming
* mput filename
* go to Admin -> File Releases
* scroll to the bottom and click [Add Release] to the inkscape item
* Enter 0.35 in the box & click “Create this Release”
* Fill in the form, checkbox the file you uploaded in (c)
* It won't give you a clear “success” message, but you can check it got in right by going to the Files list. You can then edit any of the info you entered, to make it more correct.

Also see CVSNamingConventions if you are making a release.

=== Announcing Releases ===

When you cut a release, send a copy of the release notes as an announcement to inkscape-announce@lists.sourceforge.net.
If you find other mailing lists or websites that should receive the announcements, add their email address to the inkscape-announce list. This is done by a list admin such as Bryce Harrington.

'''[AnnouncingReleases Places to Submit Release Announcements]''' - Keep an eye out for other places we could announce such as distros or graphics-related sites (not only Linux-centric!).

=== Updating Website Collateral ===

When a new release is cut, there are several pieces of info that need to be added to the website:

* Add a news item on front page
* Review/revise FAQ
* Review/revise Roadmap
* Add or revise Screenshots (if appropriate)
* doc directory: Add the manpage for the release, update doc/keys.html file, and change the corresponding version number(s) in doc/index.php.
** From shell.sf.net, cd to the inkscape_web directory and run the command “(cd ../inkscape; cvs update;chmod g+w -R * 2>/dev/null); pod2html --cachedir=/tmp --infile=../inkscape/inkscape.pod --outfile=doc/inkscape-man.html”.

Creating Inkscape distributions

2005-07-16T00:16:22Z

PeterMoulder: * Mention that keys.html needs to be updated to the new version

== Creating Dists of Inkscape ==

Those who wish to produce packaged releases of inkscape are welcome to do so.
If it is packages changes that you've made to the official release, please select a
version name that distinguishes it from the official version, to avoid confusion. For
example, "inkscape-0.35-johndoe.tar.gz". Please consider distributing your changes
as a patch rather than as a full distribution, as patches tend to be easier to
maintain.

Inkscape's release process works like this:

# Start of release process - Finish up work on features.
# Feature Freeze Mode - Shift focus from feature implementation to bug fixing
# Hard Freeze - Two freeze wardens are named. All development must be done as patches submitted to the freeze wardens for review and integration.
# Branch - The codebase is tagged and branched. Final release tarball is posted. The codebase is returned to regular open development.
# Packaging - Three days are allowed for creating release dists (rpm's, deb's, exe's, and autopackages).
# Release Announcement - A Release Announcement and a Press Release are written and circulated to relevant online news sites. Our Freshmeat record is updated.

=== Feature Freeze Mode ===

In the run-up to CreatingDists, for a short time preceding the tagging of the release it's a good idea to hold off on adding new features or doing other major changes like architectural changes to the code that might decrease its stability. Whether a change is minor enough to be "ok" is left to the developer's judgement, and they're trusted to be conservative and careful.

The most useful activity to do during a feature freeze is to locate and/or fix bugs that produce crashes, and to do so with the smallest amount of change to the codebase possible. If a "proper" fix requires architectural changes or redesign of the code, consider writing that up as a post-release task.

-----

It might be useful to branch off a release branch a week before making the release. Hopefully most people using CVS would switch to this branch at this time. Then only bug fixes can go into that branch. --[[Ted]]

=== Branching the release candidate ===

Before release, a branch should have been be created for that release in the form RELEASE_<major>_<minor>_BRANCH. For example, 0.38 should have a branch called RELEASE_0_38_BRANCH.

Minor fixes and code review can then be performed on that branch before the final release; it also permits making future point releases easily (if necessary).

To check out the release branch into a fresh working copy, you can use:

<pre>cvs co -r RELEASE_0_38_BRANCH -d inkscape-0.38-branch inkscape</pre>

or, if you have a checked out tree handy, it is quicker to use:

<pre>
cp -a inkscape inkscape-0.38-branch
cd inkscape-0.38-branch
cvs up -PAd -r RELEASE_0_38_BRANCH
</pre>

Once the release is deemed ready a distribution tarball should be created as below.

=== Creating a distribution source tarball package ===

On the release branch (NOT ON HEAD):

* Set the version name via the file configure.ac in the AC_INIT() macro, Makefile.mingw.common, inkscape.nsi, and in debian/changelog
* Add the release notes into the NEWS file in the release branch
* Run ./autogen.sh && ./configure (with any flags, e.g. CXXFLAGS=).
* Run "cd src && make helper/sp-marshal.h helper/sp-marshal.cpp inkscape_version.h && perl mkfiles.pl && perl mkdep.pl", then do "cvs -q diff -du make.*|less" to check for anything strange (e.g. source files accidentally added or removed), and finally "cvs commit -m '' make.*"
* Make sure the code passes a "make distcheck"
* This should produce inkscape-VERSION.tar.gz
* Commit the changed configure.ac and other files to the branch
* Tag the release in CVS

Release tags should be in the form RELEASE_<major>_<minor>_<point>. A non-point-release like 0.38 would get the tag RELEASE_0_38_0, 0.38.1 would get the tag RELEASE_0_38_1, and so on.

On HEAD:

* Add the release notes into the NEWS file in the release branch
* Change configure.ac and inkscape_version.h.mingw to reflect the new future version

=== GPG signing Tarballs ===

Downstream packagers are asking for and may soon demand gpg signed tarballs. For Fedora, this is not a requirement, but does ease acceptance of packages. It also shows we are doing "The Right Thing". md5sums are not foolproof.

* To create a gpg signed tarball:

<pre>$gpg -u packager@foo.net --armor --output tarball.sig --detach-sig tarball.tar.gz</pre>

* To verify :

<pre>$gpg --verify ./tarball.asc ./tarball.tar.gz</pre>

Of course, this step doesn't mean much in practice unless people have a trust path to your key. Packagers are encouraged to attend key signing parties and take other measures to establish important trust paths to their keys (particularly with downstream packagers).

:Where are the public keys matching these sig's posted?

=== Creating a Windows Distro ===
Inkscape/sodipodi has always been
buildable on Win32. The problem with the sodipodi and original inkscape build, though,
was that the Win32 builder had to download and configure
a lot of things to make it to work. Mingw, MSYS, automake,
autoconf, pkg-config, the codepages, etc. He would spend more
time on THAT than the actual code.

What a pain for the average developer/user who merely wants
to make Inkscape do what he wants it to do. Why waste
days and days getting it to compile, when the developer
would rather be working on the program itself?

So we spent several weeks collecting libraries, building others,
installing the codepages into the source (which we can delete soon
because of Pango) and creating a set of clean makefiles
that work on Win9x, NT, XP, and the cross-compiler.
It is a bit more work for people like me, but hopefully it
attains its goal of saving a lot of work for other people.

Also, remember that on Unix/Linux, $PREFIX is commonly
/usr/local or /usr or something like that. On M$, all of
a program's files are typically located in their own directory. So all
of the files are located relative to ".". Actually, relative to
the .exe that is currently running.

.....anyway, just wanted to explain that there is a reason
for the Win32 build to be constructed in such a manner,
and that we haven't just been arbitrary.

Once the tree is built ("make -f Makefile.mingw" and "make -f Makefile.mingw dist") into the "inkscape" directory, the [http://nsis.sourceforge.net/ NSIS] installer script "inkscape.nsi" can be run to create the self-extracting installer.

The Windows download package should be named according to the following scheme:

inkscape-$RELEASE-$PKG.$WINVER.exe

Where $WINVER is the required Windows version, e.g. "win32". For example:

inkscape-0.37-1.win32.exe

=== Creating a Debian .deb ===

The article [[CompilingDebian]] provides a makefile to download a tarball and build a debian package therefrom.

=== Creating a distribution RPM ===

Method A:
# do as above for tarball, or download the release tarball
# login as root
# rpmbuild -tb inkscape-x.x.tar.gz
# Your RPMs will be in /usr/src/rpm/RPMS (/usr/src/redhat on RH systems)
# RPMs should be GPG signed

Method B:
# do as above for tarball, or download the release tarball
# mkdir ~/rpm
# Copy the tarball to ~/rpm/SOURCES/
# Copy the inkscape.spec from the tarball to ~/rpm/SPECS/inkscape.spec
# rpmbuild -ba ~/rpm/SPECS/inkscape.spec
# Your RPMs will be in ~/rpm/RPMS and ~/rpm/SRPMS
# RPMs should be GPG signed

The rpm should be named according to the following pattern:

inkscape-$RELEASE-$PKG.$DISTRO.$ARCH.rpm

Where:

$RELEASE: the Inkscape release number, such as "0.37", "0.36.2", etc.
The third number should be omitted if it is 0. (I.e., 0.37 instead of 0.37.0)

$PKG: A version number for your package. Use a value of 1 for your package, and increment it if you
need to update the released package for some reason.

$DISTRO: The name and an indicator of the version number for the distro. E.g.,
rh71, rh90, mdk91, suse90, fc1, etc. No need to be too exhaustive with the distro versions;
for a given brand of distro it's probably enough to have a reasonably "modern" release
and an older one for legacy support. For instance, rh71 and rh90.

$ARCH: The architecture that the package was built on. E.g., i686, i386, athlon, ppc, etc.
Don't bother with i586 - either i386 or i686 is preferred. The i386 packages will run on Cyrix
and K-6.

Examples:

inkscape-0.37-1.mdk80.i386.rpm
inkscape-0.37-1.mdk80.i686.rpm
inkscape-0.37-1.mdk91.i386.rpm
inkscape-0.37-1.mdk91.i686.rpm

inkscape-0.37-1.fc1.i386.rpm
inkscape-0.37-1.fc1.i686.rpm
inkscape-0.37-1.fc1.athlon.rpm
inkscape-0.37-1.fc1.ppc.rpm

For creating spec files, feel free to list yourself as the packager, but please use
inkscape-devel@lists.sourceforge.net as the contact email address, to ensure that
questions/complaints about the RPM go to the official support channel.

==== Patching RPMs ====

Occasionally, the RPM will not build without some modifications. If the problem is serious enough that it affects every packaging format, this could signal a need to do a point release, but usually you can just add a patch specifically for the RPM. This is what RPM is for, after all. :-)

Here's how to do it:

1. Create a copy of the source tree, with the modifications needed to correct the issue.
2. Generate a patch like this:

$ diff -uNr package-1.0/ package-1.0p/ > ../SOURCES/package-1.0-my.patch

3. Next add the patch to the RPM. In the specfile at %_topdir/SPECS/package.spec, add a line like this at the top of the file:

Patch0: package-1.0-my.patch

Then further down add a line after the %setup section, like this:

%prep
%setup ...
%patch0 -p1

It's a very good idea to split up changes into discrete patches, giving each a different number (they don't have to be consecutively numbered). Also, be sure to upload the patch(es) to the patch tracker so they'll get into the codebase for the next release.

Then rebuild the package like this:

rpmbuild -ba SPECS/package.spec

=== Signing your package ===

First, you need to have a public/private keypair. This can be generated with gpg using 'gpg --gen-key'.

To add a signature to an extisting package, use the command rpm --addsign /path/to/package.rpm To sign in the process of building a package, use rpmbuild -bb --sign

To check the signature on a package, use rpm --checksig.

=== Releasing Dists on the SourceForge File Release Tool ===

To release a file: (You need Release Tech permission for your Inkscape account)

* ftp upload.sf.net (anonymous/anonymous)
* cd incoming
* mput filename
* go to Admin -> File Releases
* scroll to the bottom and click [Add Release] to the inkscape item
* Enter 0.35 in the box & click "Create this Release"
* Fill in the form, checkbox the file you uploaded in (c)
* It won't give you a clear "success" message, but you can check it got in right by going to the Files list. You can then edit any of the info you entered, to make it more correct.

Also see CVSNamingConventions if you are making a release.

=== Announcing Releases ===

When you cut a release, send a copy of the release notes as an announcement to inkscape-announce@lists.sourceforge.net.
If you find other mailing lists or websites that should receive the announcements, add their email address to the inkscape-announce list. This is done by a list admin such as Bryce Harrington.

'''[AnnouncingReleases Places to Submit Release Announcements]''' - Keep an eye out for other places we could announce such as distros or graphics-related sites (not only Linux-centric!).

=== Updating Website Collateral ===

When a new release is cut, there are several pieces of info that need to be added to the website:

* Add a news item on front page
* Review/revise FAQ
* Review/revise Roadmap
* Add or revise Screenshots (if appropriate)
* doc directory: Add the manpage for the release, update keys.html file, and update doc/index.php descriptions.
** From shell.sf.net, cd to the inkscape_web directory and run the command "(cd ../inkscape; cvs update;chmod g+w -R * 2>/dev/null); pod2html --cachedir=/tmp --infile=../inkscape/inkscape.pod --outfile=doc/inkscape-man.html".
* Update doc/keys.html on the website, change the corresponding version number in doc/index.php

SVG Test Suite Compliance

2005-07-04T15:30:42Z

PeterMoulder: * styling-pres-01-t now passes

This table summarises the results of testing Inkscape against the [http://www.w3.org/Graphics/SVG/Test/ W3C SVG Test Suite].

Last complete test was performed on Windows with development version CVS-0507040247. See also
* [[SVG Test Suite Compliance V0.41]]

== Key ==
; '''pass''' : the test passed fully (73 occurences)
; '''partial''' : the test partially failed but it may be easy to make it pass (24 occurences)
; '''fail''' : the test failed (85 occurences)
; '''crash''' : the test failed and Inkscape crashed (1 occurence)

----
== Results ==
=== Animation (not yet supported) ===
; animate-elem-02-t.svg : '''fail'''
; animate-elem-03-t.svg : '''fail'''
; animate-elem-04-t.svg : '''fail'''
; animate-elem-05-t.svg : '''fail''' (animation not supported)
; animate-elem-06-t.svg : '''fail'''
; animate-elem-07-t.svg : '''fail'''
; animate-elem-08-t.svg : '''fail'''
; animate-elem-09-t.svg : '''fail'''
; animate-elem-10-t.svg : '''fail'''
; animate-elem-11-t.svg : '''fail'''
; animate-elem-12-t.svg : '''fail'''
; animate-elem-13-t.svg : '''fail'''
; animate-elem-14-t.svg : '''fail'''
; animate-elem-15-t.svg : '''fail'''
; animate-elem-16-t.svg : '''fail'''
; animate-elem-17-t.svg : '''fail'''
; animate-elem-18-t.svg : '''fail'''
; animate-elem-19-t.svg : '''fail'''
; animate-elem-20-t.svg : '''fail'''
; animate-elem-21-t.svg : '''fail'''
; animate-elem-22-b.svg : '''fail'''
; animate-elem-23-t.svg : '''fail'''
; animate-elem-24-t.svg : '''fail'''
; animate-elem-25-t.svg : '''fail'''
; animate-elem-26-t.svg : '''fail'''
; animate-elem-27-t.svg : '''fail'''
; animate-elem-28-t.svg : '''fail'''
; animate-elem-29-b.svg : '''fail'''

=== Colors ===
; color-prof-01-f.svg : '''fail'''
: <i>Tests color profile support. Hopefully the Little CMS work should address this: see InkscapeColor.</i>
; color-prop-01-b.svg : '''pass'''
: <i>there are bugs for variations of this test: see comment in sp_object_get_style_property.</i>
; color-prop-02-f.svg : '''pass'''
; color-prop-03-t.svg : '''pass'''

=== Coordinates ===
; coords-trans-01-b.svg : '''pass'''
; coords-trans-02-t.svg : '''pass'''
; coords-trans-03-t.svg : '''pass'''
; coords-trans-04-t.svg : '''pass'''
; coords-trans-05-t.svg : '''pass'''
; coords-trans-06-t.svg : '''pass'''
; coords-units-01-b.svg : '''partial''' - incorrect clipping
; coords-units-02-b.svg : '''partial'''
; coords-units-03-b.svg : '''partial''' - the red background is not clipped correctly
; coords-viewattr-01-b.svg : '''fail'''
; coords-viewattr-02-b.svg : '''partial''' - viewport boxes not styled correctly
; extend-namespace-01-f.svg : '''fail'''

=== Filters (not yet supported) ===
; filters-blend-01-b.svg : '''fail'''
; filters-color-01-b.svg : '''fail'''
; filters-composite-02-b.svg : '''fail'''
; filters-comptran-01-b.svg : '''fail'''
; filters-conv-01-f.svg : '''fail'''
; filters-diffuse-01-f.svg : '''fail'''
; filters-displace-01-f.svg : '''fail'''
; filters-example-01-b.svg : '''fail'''
; filters-gauss-01-b.svg : '''fail'''
; filters-image-01-b.svg : '''fail'''
; filters-light-01-f.svg : '''fail'''
; filters-morph-01-f.svg : '''fail'''
; filters-offset-01-b.svg : '''fail'''
; filters-specular-01-f.svg : '''fail'''
; filters-tile-01-b.svg : '''fail'''
; filters-turb-01-f.svg : '''fail'''

=== Fonts ===
; fonts-elem-01-t.svg : '''pass'''
; fonts-elem-02-t.svg : '''fail''' (but close to what's requried)
; fonts-elem-03-b.svg : '''fail'''
; fonts-elem-04-b.svg : '''fail'''

=== Interaction (not supported) ===
; interact-cursor-01-f.svg : '''crash''' (on Windows when attempting the interaction)
: <i>Crash now fixed in CVS. (Windows user please confirm, and update counts accordingly.) Thanks to ACSpike for backtrace.</i>
; interact-dom-01-b.svg : '''fail'''
; interact-events-01-b.svg : '''fail'''
; interact-order-01-b.svg : '''fail'''
; interact-order-02-b.svg : '''fail'''
; interact-order-03-b.svg : '''fail'''
; interact-zoom-01-t.svg : '''fail'''

=== Linking ===
; linking-a-01-b.svg : '''fail'''
; linking-a-02-b.svg : '''fail'''
; linking-a-03-b.svg : '''fail'''
; linking-a-04-t.svg : '''fail'''
; linking-uri-01-b.svg : '''fail'''
; linking-uri-02-b.svg : '''fail'''
; linking-uri-03-t.svg : '''fail'''

=== Masking ===
; masking-mask-01-b.svg : '''partial''' - the string is incorrectly rendered
; masking-opacity-01-b.svg : '''pass'''
; masking-path-01-b.svg : '''pass'''
; masking-path-02-b.svg : '''partial'''
; masking-path-03-b.svg : '''fail'''
; masking-path-04-b.svg : '''pass'''
; masking-path-05-f.svg : '''partial''' - clip-rule=evenodd not functioning

=== Metadata ===
; metadata-example-01-b.svg : '''pass''' (I think)

=== Painting ===
; painting-fill-01-t.svg : '''pass'''
; painting-fill-02-t.svg : '''pass'''
; painting-fill-03-t.svg : '''pass'''
; painting-fill-04-t.svg : '''pass'''
; painting-marker-01-f.svg : '''pass'''
; painting-marker-02-f.svg : '''partial''' - mishandling of marker strokes
; painting-render-01-b.svg : '''pass'''
; painting-stroke-01-t.svg : '''pass'''
; painting-stroke-02-t.svg : '''pass'''
; painting-stroke-03-t.svg : '''pass'''
; painting-stroke-04-t.svg : '''pass'''

=== Paths ===
; paths-data-01-t.svg : '''pass'''
; paths-data-02-t.svg : '''pass'''
; paths-data-03-f.svg : '''pass'''
; paths-data-04-t.svg : '''pass'''
; paths-data-05-t.svg : '''pass'''
; paths-data-06-t.svg : '''pass'''
; paths-data-07-t.svg : '''pass'''

=== Color Gradients ===
; pservers-grad-01-b.svg : '''pass'''
; pservers-grad-02-b.svg : '''pass'''
; pservers-grad-03-b.svg : '''pass'''
; pservers-grad-04-b.svg : '''pass'''
; pservers-grad-05-b.svg : '''pass'''
; pservers-grad-06-b.svg : '''pass'''
; pservers-grad-07-b.svg : '''pass'''
; pservers-grad-08-b.svg : '''partial''' - gradient is ok; font is incorrect
; pservers-grad-09-b.svg : '''pass'''
; pservers-grad-10-b.svg : '''pass'''
; pservers-grad-11-b.svg : '''pass'''
; pservers-grad-12-b.svg : '''pass'''
; pservers-pattern-01-b.svg : '''pass'''

=== Rendering ===
; render-elems-01-t.svg : '''pass'''
; render-elems-02-t.svg : '''pass'''
; render-elems-03-t.svg : '''fail'''
; render-elems-06-t.svg : '''partial''' - rendering is ok; font is incorrect
; render-elems-07-t.svg : '''partial''' - rendering is ok; font is incorrect
; render-elems-08-t.svg : '''partial''' - rendering is ok; font is incorrect
; render-groups-01-b.svg : '''partial''' - rendering is ok; font is incorrect
; render-groups-03-t.svg : '''partial''' - rendering is ok; font is incorrect

=== Scripting (not supported) ===
; script-handle-01-b.svg : '''fail'''
; script-handle-02-b.svg : '''fail'''
; script-handle-03-b.svg : '''fail'''
; script-handle-04-b.svg : '''fail'''

=== Shapes ===
; shapes-circle-01-t.svg : '''pass'''
; shapes-ellipse-01-t.svg : '''pass'''
; shapes-line-01-t.svg : '''pass'''
; shapes-polygon-01-t.svg : '''pass'''
; shapes-polyline-01-t.svg : '''partial''' - the pentagon ends are incorrect
; shapes-rect-01-t.svg : '''pass'''

=== Structure ===
; struct-cond-01-t.svg : '''fail'''
; struct-cond-02-t.svg : '''fail'''
; struct-defs-01-t.svg : '''pass'''
; struct-dom-01-b.svg : '''fail'''
; struct-dom-02-b.svg : '''fail'''
; struct-dom-03-b.svg : '''fail'''
; struct-dom-04-b.svg : '''fail'''
; struct-dom-05-b.svg : '''fail'''
; struct-dom-06-b.svg : '''fail'''
; struct-frag-01-t.svg : '''pass'''
; struct-group-01-t.svg : '''pass'''
; struct-group-02-b.svg : '''pass'''
; struct-image-01-t.svg : '''pass'''
; struct-image-02-b.svg : '''partial''' - problem with use element
; struct-image-03-t.svg : '''fail'''
; struct-image-04-t.svg : '''pass'''
; struct-image-05-b.svg : '''fail''' - Message: error loading pixbuf at close
; struct-symbol-01-b.svg : '''partial''' - the topleft image is not resized correctly

=== CSS ===
<i>Inkscape has limited support for CSS stylesheets.</i>
; styling-css-01-b.svg : '''pass'''
; styling-css-02-b.svg : '''pass'''
; styling-css-03-b.svg : '''pass'''
; styling-inherit-01-b.svg : '''pass'''
; styling-pres-01-t.svg : '''pass'''

=== Text ===
; text-align-01-b.svg : '''pass'''
; text-align-02-b.svg : '''fail''' - baseline-shift not functioning
; text-align-03-b.svg : '''fail'''
; text-align-04-b.svg : '''partial''' - tref not supported
; text-align-05-b.svg : '''pass'''
; text-align-06-b.svg : '''fail'''
; text-altglyph-01-b.svg : '''fail'''
; text-deco-01-b.svg : '''partial''' - underline and strikethrough not functioning; whitespace problem
; text-fonts-01-t.svg : '''pass'''
; text-fonts-02-t.svg : '''partial''' - font-weight="lighter" not functioning
; text-intro-01-t.svg : '''pass'''
; text-intro-02-b.svg : '''partial''' - right-to-left text not functioning
; text-intro-03-b.svg : '''partial''' - text is vertical but oriented incorrectly
; text-intro-04-t.svg : '''pass'''
; text-path-01-b.svg : '''pass'''
; text-spacing-01-b.svg : '''pass'''
; text-text-01-b.svg : '''fail''' - 'textLength' and 'lengthAdjust' not functioning
; text-text-03-b.svg : '''partial''' - underline and strikethrough not functioning
; text-tref-01-b.svg : '''fail''' - tref not functioning
; text-tselect-01-b.svg : '''pass'''
; text-tspan-01-b.svg : '''partial''' - improved but still not quite correct
; text-ws-01-t.svg : '''pass'''
; text-ws-02-t.svg : '''pass'''
----
Further discussion is on the [http://sourceforge.net/tracker/index.php?func=detail&aid=1224751&group_id=93438&atid=604306 Bug Tracker].

SVG Test Suite Compliance

2005-07-04T13:56:49Z

PeterMoulder: * styling-inherit-01-b now passes

This table summarises the results of testing Inkscape against the [http://www.w3.org/Graphics/SVG/Test/ W3C SVG Test Suite].

This test was performed on Windows with development version CVS-0507040247. See also
* [[SVG Test Suite Compliance V0.41]]

== Key ==
; '''pass''' : the test passed fully (70 occurences)
; '''partial''' : the test partially failed but it may be easy to make it pass (25 occurences)
; '''fail''' : the test failed (87 occurences)
; '''crash''' : the test failed and Inkscape crashed (1 occurence)

----
== Results ==
=== Animation (not yet supported) ===
; animate-elem-02-t.svg : '''fail'''
; animate-elem-03-t.svg : '''fail'''
; animate-elem-04-t.svg : '''fail'''
; animate-elem-05-t.svg : '''fail''' (animation not supported)
; animate-elem-06-t.svg : '''fail'''
; animate-elem-07-t.svg : '''fail'''
; animate-elem-08-t.svg : '''fail'''
; animate-elem-09-t.svg : '''fail'''
; animate-elem-10-t.svg : '''fail'''
; animate-elem-11-t.svg : '''fail'''
; animate-elem-12-t.svg : '''fail'''
; animate-elem-13-t.svg : '''fail'''
; animate-elem-14-t.svg : '''fail'''
; animate-elem-15-t.svg : '''fail'''
; animate-elem-16-t.svg : '''fail'''
; animate-elem-17-t.svg : '''fail'''
; animate-elem-18-t.svg : '''fail'''
; animate-elem-19-t.svg : '''fail'''
; animate-elem-20-t.svg : '''fail'''
; animate-elem-21-t.svg : '''fail'''
; animate-elem-22-b.svg : '''fail'''
; animate-elem-23-t.svg : '''fail'''
; animate-elem-24-t.svg : '''fail'''
; animate-elem-25-t.svg : '''fail'''
; animate-elem-26-t.svg : '''fail'''
; animate-elem-27-t.svg : '''fail'''
; animate-elem-28-t.svg : '''fail'''
; animate-elem-29-b.svg : '''fail'''

=== Colors ===
; color-prof-01-f.svg : '''fail'''
: <i>Tests color profile support. Hopefully the Little CMS work should address this: see InkscapeColor.</i>
; color-prop-01-b.svg : '''pass'''
: <i>there are bugs for variations of this test: see comment in sp_object_get_style_property.</i>
; color-prop-02-f.svg : '''pass'''
; color-prop-03-t.svg : '''pass'''

=== Coordinates ===
; coords-trans-01-b.svg : '''pass'''
; coords-trans-02-t.svg : '''pass'''
; coords-trans-03-t.svg : '''pass'''
; coords-trans-04-t.svg : '''pass'''
; coords-trans-05-t.svg : '''pass'''
; coords-trans-06-t.svg : '''pass'''
; coords-units-01-b.svg : '''partial''' - incorrect clipping
; coords-units-02-b.svg : '''partial'''
; coords-units-03-b.svg : '''partial''' - the red background is not clipped correctly
; coords-viewattr-01-b.svg : '''fail'''
; coords-viewattr-02-b.svg : '''partial''' - viewport boxes not styled correctly
; extend-namespace-01-f.svg : '''fail'''

=== Filters (not yet supported) ===
; filters-blend-01-b.svg : '''fail'''
; filters-color-01-b.svg : '''fail'''
; filters-composite-02-b.svg : '''fail'''
; filters-comptran-01-b.svg : '''fail'''
; filters-conv-01-f.svg : '''fail'''
; filters-diffuse-01-f.svg : '''fail'''
; filters-displace-01-f.svg : '''fail'''
; filters-example-01-b.svg : '''fail'''
; filters-gauss-01-b.svg : '''fail'''
; filters-image-01-b.svg : '''fail'''
; filters-light-01-f.svg : '''fail'''
; filters-morph-01-f.svg : '''fail'''
; filters-offset-01-b.svg : '''fail'''
; filters-specular-01-f.svg : '''fail'''
; filters-tile-01-b.svg : '''fail'''
; filters-turb-01-f.svg : '''fail'''

=== Fonts ===
; fonts-elem-01-t.svg : '''pass'''
; fonts-elem-02-t.svg : '''fail''' (but close to what's requried)
; fonts-elem-03-b.svg : '''fail'''
; fonts-elem-04-b.svg : '''fail'''

=== Interaction (not supported) ===
; interact-cursor-01-f.svg : '''crash''' (on Windows when attempting the interaction)
: <i>Crash now fixed in CVS. (Windows user please confirm, and update counts accordingly.) Thanks to ACSpike for backtrace.</i>
; interact-dom-01-b.svg : '''fail'''
; interact-events-01-b.svg : '''fail'''
; interact-order-01-b.svg : '''fail'''
; interact-order-02-b.svg : '''fail'''
; interact-order-03-b.svg : '''fail'''
; interact-zoom-01-t.svg : '''fail'''

=== Linking ===
; linking-a-01-b.svg : '''fail'''
; linking-a-02-b.svg : '''fail'''
; linking-a-03-b.svg : '''fail'''
; linking-a-04-t.svg : '''fail'''
; linking-uri-01-b.svg : '''fail'''
; linking-uri-02-b.svg : '''fail'''
; linking-uri-03-t.svg : '''fail'''

=== Masking ===
; masking-mask-01-b.svg : '''partial''' - the string is incorrectly rendered
; masking-opacity-01-b.svg : '''pass'''
; masking-path-01-b.svg : '''pass'''
; masking-path-02-b.svg : '''partial'''
; masking-path-03-b.svg : '''fail'''
; masking-path-04-b.svg : '''pass'''
; masking-path-05-f.svg : '''partial''' - clip-rule=evenodd not functioning

=== Metadata ===
; metadata-example-01-b.svg : '''pass''' (I think)

=== Painting ===
; painting-fill-01-t.svg : '''pass'''
; painting-fill-02-t.svg : '''pass'''
; painting-fill-03-t.svg : '''pass'''
; painting-fill-04-t.svg : '''pass'''
; painting-marker-01-f.svg : '''pass'''
; painting-marker-02-f.svg : '''partial''' - mishandling of marker strokes
; painting-render-01-b.svg : '''pass'''
; painting-stroke-01-t.svg : '''pass'''
; painting-stroke-02-t.svg : '''pass'''
; painting-stroke-03-t.svg : '''pass'''
; painting-stroke-04-t.svg : '''pass'''

=== Paths ===
; paths-data-01-t.svg : '''pass'''
; paths-data-02-t.svg : '''pass'''
; paths-data-03-f.svg : '''pass'''
; paths-data-04-t.svg : '''pass'''
; paths-data-05-t.svg : '''pass'''
; paths-data-06-t.svg : '''pass'''
; paths-data-07-t.svg : '''pass'''

=== Color Gradients ===
; pservers-grad-01-b.svg : '''pass'''
; pservers-grad-02-b.svg : '''pass'''
; pservers-grad-03-b.svg : '''pass'''
; pservers-grad-04-b.svg : '''pass'''
; pservers-grad-05-b.svg : '''pass'''
; pservers-grad-06-b.svg : '''pass'''
; pservers-grad-07-b.svg : '''pass'''
; pservers-grad-08-b.svg : '''partial''' - gradient is ok; font is incorrect
; pservers-grad-09-b.svg : '''pass'''
; pservers-grad-10-b.svg : '''pass'''
; pservers-grad-11-b.svg : '''pass'''
; pservers-grad-12-b.svg : '''pass'''
; pservers-pattern-01-b.svg : '''pass'''

=== Rendering ===
; render-elems-01-t.svg : '''pass'''
; render-elems-02-t.svg : '''pass'''
; render-elems-03-t.svg : '''fail'''
; render-elems-06-t.svg : '''partial''' - rendering is ok; font is incorrect
; render-elems-07-t.svg : '''partial''' - rendering is ok; font is incorrect
; render-elems-08-t.svg : '''partial''' - rendering is ok; font is incorrect
; render-groups-01-b.svg : '''partial''' - rendering is ok; font is incorrect
; render-groups-03-t.svg : '''partial''' - rendering is ok; font is incorrect

=== Scripting (not supported) ===
; script-handle-01-b.svg : '''fail'''
; script-handle-02-b.svg : '''fail'''
; script-handle-03-b.svg : '''fail'''
; script-handle-04-b.svg : '''fail'''

=== Shapes ===
; shapes-circle-01-t.svg : '''pass'''
; shapes-ellipse-01-t.svg : '''pass'''
; shapes-line-01-t.svg : '''pass'''
; shapes-polygon-01-t.svg : '''pass'''
; shapes-polyline-01-t.svg : '''partial''' - the pentagon ends are incorrect
; shapes-rect-01-t.svg : '''pass'''

=== Structure ===
; struct-cond-01-t.svg : '''fail'''
; struct-cond-02-t.svg : '''fail'''
; struct-defs-01-t.svg : '''pass'''
; struct-dom-01-b.svg : '''fail'''
; struct-dom-02-b.svg : '''fail'''
; struct-dom-03-b.svg : '''fail'''
; struct-dom-04-b.svg : '''fail'''
; struct-dom-05-b.svg : '''fail'''
; struct-dom-06-b.svg : '''fail'''
; struct-frag-01-t.svg : '''pass'''
; struct-group-01-t.svg : '''pass'''
; struct-group-02-b.svg : '''pass'''
; struct-image-01-t.svg : '''pass'''
; struct-image-02-b.svg : '''partial''' - problem with use element
; struct-image-03-t.svg : '''fail'''
; struct-image-04-t.svg : '''pass'''
; struct-image-05-b.svg : '''fail''' - Message: error loading pixbuf at close
; struct-symbol-01-b.svg : '''partial''' - the topleft image is not resized correctly

=== CSS ===
<i>Inkscape has limited support for CSS stylesheets.</i>
; styling-css-01-b.svg : '''pass'''
; styling-css-02-b.svg : '''pass'''
; styling-css-03-b.svg : '''pass'''
; styling-inherit-01-b.svg : '''pass'''
; styling-pres-01-t.svg : '''fail'''

=== Text ===
; text-align-01-b.svg : '''pass'''
; text-align-02-b.svg : '''fail''' - baseline-shift not functioning
; text-align-03-b.svg : '''fail'''
; text-align-04-b.svg : '''partial''' - tref not supported
; text-align-05-b.svg : '''pass'''
; text-align-06-b.svg : '''fail'''
; text-altglyph-01-b.svg : '''fail'''
; text-deco-01-b.svg : '''partial''' - underline and strikethrough not functioning; whitespace problem
; text-fonts-01-t.svg : '''pass'''
; text-fonts-02-t.svg : '''partial''' - font-weight="lighter" not functioning
; text-intro-01-t.svg : '''pass'''
; text-intro-02-b.svg : '''partial''' - right-to-left text not functioning
; text-intro-03-b.svg : '''partial''' - text is vertical but oriented incorrectly
; text-intro-04-t.svg : '''pass'''
; text-path-01-b.svg : '''pass'''
; text-spacing-01-b.svg : '''pass'''
; text-text-01-b.svg : '''fail''' - 'textLength' and 'lengthAdjust' not functioning
; text-text-03-b.svg : '''partial''' - underline and strikethrough not functioning
; text-tref-01-b.svg : '''fail''' - tref not functioning
; text-tselect-01-b.svg : '''partial''' - Inkscape's text selection mechanism is quite similar to the standard, but using a dialog (this could therefore be considered a '''pass''')
; text-tspan-01-b.svg : '''partial''' - improved but still not quite correct
; text-ws-01-t.svg : '''pass'''
; text-ws-02-t.svg : '''fail''' - xml:space="preserve" not functioning; non-printing glyphs now displayed
----
Further discussion is on the [http://sourceforge.net/tracker/index.php?func=detail&aid=1224751&group_id=93438&atid=604306 Bug Tracker].

SVG Test Suite Compliance

2005-07-04T13:25:03Z

PeterMoulder: * Update for interact-cursor-01-f: crash now believed fixed in CVS.

This table summarises the results of testing Inkscape against the [http://www.w3.org/Graphics/SVG/Test/ W3C SVG Test Suite].

This test was performed on Windows with development version CVS-0507040247. See also
* [[SVG Test Suite Compliance V0.41]]

== Key ==
; '''pass''' : the test passed fully (69 occurences)
; '''partial''' : the test partially failed but it may be easy to make it pass (25 occurences)
; '''fail''' : the test failed (88 occurences)
; '''crash''' : the test failed and Inkscape crashed (1 occurence)

----
== Results ==
=== Animation (not yet supported) ===
; animate-elem-02-t.svg : '''fail'''
; animate-elem-03-t.svg : '''fail'''
; animate-elem-04-t.svg : '''fail'''
; animate-elem-05-t.svg : '''fail''' (animation not supported)
; animate-elem-06-t.svg : '''fail'''
; animate-elem-07-t.svg : '''fail'''
; animate-elem-08-t.svg : '''fail'''
; animate-elem-09-t.svg : '''fail'''
; animate-elem-10-t.svg : '''fail'''
; animate-elem-11-t.svg : '''fail'''
; animate-elem-12-t.svg : '''fail'''
; animate-elem-13-t.svg : '''fail'''
; animate-elem-14-t.svg : '''fail'''
; animate-elem-15-t.svg : '''fail'''
; animate-elem-16-t.svg : '''fail'''
; animate-elem-17-t.svg : '''fail'''
; animate-elem-18-t.svg : '''fail'''
; animate-elem-19-t.svg : '''fail'''
; animate-elem-20-t.svg : '''fail'''
; animate-elem-21-t.svg : '''fail'''
; animate-elem-22-b.svg : '''fail'''
; animate-elem-23-t.svg : '''fail'''
; animate-elem-24-t.svg : '''fail'''
; animate-elem-25-t.svg : '''fail'''
; animate-elem-26-t.svg : '''fail'''
; animate-elem-27-t.svg : '''fail'''
; animate-elem-28-t.svg : '''fail'''
; animate-elem-29-b.svg : '''fail'''

=== Colors ===
; color-prof-01-f.svg : '''fail'''
: <i>Tests color profile support. Hopefully the Little CMS work should address this: see InkscapeColor.</i>
; color-prop-01-b.svg : '''pass'''
: <i>there are bugs for variations of this test: see comment in sp_object_get_style_property.</i>
; color-prop-02-f.svg : '''pass'''
; color-prop-03-t.svg : '''pass'''

=== Coordinates ===
; coords-trans-01-b.svg : '''pass'''
; coords-trans-02-t.svg : '''pass'''
; coords-trans-03-t.svg : '''pass'''
; coords-trans-04-t.svg : '''pass'''
; coords-trans-05-t.svg : '''pass'''
; coords-trans-06-t.svg : '''pass'''
; coords-units-01-b.svg : '''partial''' - incorrect clipping
; coords-units-02-b.svg : '''partial'''
; coords-units-03-b.svg : '''partial''' - the red background is not clipped correctly
; coords-viewattr-01-b.svg : '''fail'''
; coords-viewattr-02-b.svg : '''partial''' - viewport boxes not styled correctly
; extend-namespace-01-f.svg : '''fail'''

=== Filters (not yet supported) ===
; filters-blend-01-b.svg : '''fail'''
; filters-color-01-b.svg : '''fail'''
; filters-composite-02-b.svg : '''fail'''
; filters-comptran-01-b.svg : '''fail'''
; filters-conv-01-f.svg : '''fail'''
; filters-diffuse-01-f.svg : '''fail'''
; filters-displace-01-f.svg : '''fail'''
; filters-example-01-b.svg : '''fail'''
; filters-gauss-01-b.svg : '''fail'''
; filters-image-01-b.svg : '''fail'''
; filters-light-01-f.svg : '''fail'''
; filters-morph-01-f.svg : '''fail'''
; filters-offset-01-b.svg : '''fail'''
; filters-specular-01-f.svg : '''fail'''
; filters-tile-01-b.svg : '''fail'''
; filters-turb-01-f.svg : '''fail'''

=== Fonts ===
; fonts-elem-01-t.svg : '''pass'''
; fonts-elem-02-t.svg : '''fail''' (but close to what's requried)
; fonts-elem-03-b.svg : '''fail'''
; fonts-elem-04-b.svg : '''fail'''

=== Interaction (not supported) ===
; interact-cursor-01-f.svg : '''crash''' (on Windows when attempting the interaction)
: <i>Crash now fixed in CVS. (Windows user please confirm.) Thanks to ACSpike for backtrace.</i>
; interact-dom-01-b.svg : '''fail'''
; interact-events-01-b.svg : '''fail'''
; interact-order-01-b.svg : '''fail'''
; interact-order-02-b.svg : '''fail'''
; interact-order-03-b.svg : '''fail'''
; interact-zoom-01-t.svg : '''fail'''

=== Linking ===
; linking-a-01-b.svg : '''fail'''
; linking-a-02-b.svg : '''fail'''
; linking-a-03-b.svg : '''fail'''
; linking-a-04-t.svg : '''fail'''
; linking-uri-01-b.svg : '''fail'''
; linking-uri-02-b.svg : '''fail'''
; linking-uri-03-t.svg : '''fail'''

=== Masking ===
; masking-mask-01-b.svg : '''partial''' - the string is incorrectly rendered
; masking-opacity-01-b.svg : '''pass'''
; masking-path-01-b.svg : '''pass'''
; masking-path-02-b.svg : '''partial'''
; masking-path-03-b.svg : '''fail'''
; masking-path-04-b.svg : '''pass'''
; masking-path-05-f.svg : '''partial''' - clip-rule=evenodd not functioning

=== Metadata ===
; metadata-example-01-b.svg : '''pass''' (I think)

=== Painting ===
; painting-fill-01-t.svg : '''pass'''
; painting-fill-02-t.svg : '''pass'''
; painting-fill-03-t.svg : '''pass'''
; painting-fill-04-t.svg : '''pass'''
; painting-marker-01-f.svg : '''pass'''
; painting-marker-02-f.svg : '''partial''' - mishandling of marker strokes
; painting-render-01-b.svg : '''pass'''
; painting-stroke-01-t.svg : '''pass'''
; painting-stroke-02-t.svg : '''pass'''
; painting-stroke-03-t.svg : '''pass'''
; painting-stroke-04-t.svg : '''pass'''

=== Paths ===
; paths-data-01-t.svg : '''pass'''
; paths-data-02-t.svg : '''pass'''
; paths-data-03-f.svg : '''pass'''
; paths-data-04-t.svg : '''pass'''
; paths-data-05-t.svg : '''pass'''
; paths-data-06-t.svg : '''pass'''
; paths-data-07-t.svg : '''pass'''

=== Color Gradients ===
; pservers-grad-01-b.svg : '''pass'''
; pservers-grad-02-b.svg : '''pass'''
; pservers-grad-03-b.svg : '''pass'''
; pservers-grad-04-b.svg : '''pass'''
; pservers-grad-05-b.svg : '''pass'''
; pservers-grad-06-b.svg : '''pass'''
; pservers-grad-07-b.svg : '''pass'''
; pservers-grad-08-b.svg : '''partial''' - gradient is ok; font is incorrect
; pservers-grad-09-b.svg : '''pass'''
; pservers-grad-10-b.svg : '''pass'''
; pservers-grad-11-b.svg : '''pass'''
; pservers-grad-12-b.svg : '''pass'''
; pservers-pattern-01-b.svg : '''pass'''

=== Rendering ===
; render-elems-01-t.svg : '''pass'''
; render-elems-02-t.svg : '''pass'''
; render-elems-03-t.svg : '''fail'''
; render-elems-06-t.svg : '''partial''' - rendering is ok; font is incorrect
; render-elems-07-t.svg : '''partial''' - rendering is ok; font is incorrect
; render-elems-08-t.svg : '''partial''' - rendering is ok; font is incorrect
; render-groups-01-b.svg : '''partial''' - rendering is ok; font is incorrect
; render-groups-03-t.svg : '''partial''' - rendering is ok; font is incorrect

=== Scripting (not supported) ===
; script-handle-01-b.svg : '''fail'''
; script-handle-02-b.svg : '''fail'''
; script-handle-03-b.svg : '''fail'''
; script-handle-04-b.svg : '''fail'''

=== Shapes ===
; shapes-circle-01-t.svg : '''pass'''
; shapes-ellipse-01-t.svg : '''pass'''
; shapes-line-01-t.svg : '''pass'''
; shapes-polygon-01-t.svg : '''pass'''
; shapes-polyline-01-t.svg : '''partial''' - the pentagon ends are incorrect
; shapes-rect-01-t.svg : '''pass'''

=== Structure ===
; struct-cond-01-t.svg : '''fail'''
; struct-cond-02-t.svg : '''fail'''
; struct-defs-01-t.svg : '''pass'''
; struct-dom-01-b.svg : '''fail'''
; struct-dom-02-b.svg : '''fail'''
; struct-dom-03-b.svg : '''fail'''
; struct-dom-04-b.svg : '''fail'''
; struct-dom-05-b.svg : '''fail'''
; struct-dom-06-b.svg : '''fail'''
; struct-frag-01-t.svg : '''pass'''
; struct-group-01-t.svg : '''pass'''
; struct-group-02-b.svg : '''pass'''
; struct-image-01-t.svg : '''pass'''
; struct-image-02-b.svg : '''partial''' - problem with use element
; struct-image-03-t.svg : '''fail'''
; struct-image-04-t.svg : '''pass'''
; struct-image-05-b.svg : '''fail''' - Message: error loading pixbuf at close
; struct-symbol-01-b.svg : '''partial''' - the topleft image is not resized correctly

=== CSS ===
<i>Inkscape has limited support for CSS stylesheets.</i>
; styling-css-01-b.svg : '''pass'''
; styling-css-02-b.svg : '''pass'''
; styling-css-03-b.svg : '''pass'''
; styling-inherit-01-b.svg : '''fail'''
; styling-pres-01-t.svg : '''fail'''

=== Text ===
; text-align-01-b.svg : '''pass'''
; text-align-02-b.svg : '''fail''' - baseline-shift not functioning
; text-align-03-b.svg : '''fail'''
; text-align-04-b.svg : '''partial''' - tref not supported
; text-align-05-b.svg : '''pass'''
; text-align-06-b.svg : '''fail'''
; text-altglyph-01-b.svg : '''fail'''
; text-deco-01-b.svg : '''partial''' - underline and strikethrough not functioning; whitespace problem
; text-fonts-01-t.svg : '''pass'''
; text-fonts-02-t.svg : '''partial''' - font-weight="lighter" not functioning
; text-intro-01-t.svg : '''pass'''
; text-intro-02-b.svg : '''partial''' - right-to-left text not functioning
; text-intro-03-b.svg : '''partial''' - text is vertical but oriented incorrectly
; text-intro-04-t.svg : '''pass'''
; text-path-01-b.svg : '''pass'''
; text-spacing-01-b.svg : '''pass'''
; text-text-01-b.svg : '''fail''' - 'textLength' and 'lengthAdjust' not functioning
; text-text-03-b.svg : '''partial''' - underline and strikethrough not functioning
; text-tref-01-b.svg : '''fail''' - tref not functioning
; text-tselect-01-b.svg : '''partial''' - Inkscape's text selection mechanism is quite similar to the standard, but using a dialog (this could therefore be considered a '''pass''')
; text-tspan-01-b.svg : '''partial''' - improved but still not quite correct
; text-ws-01-t.svg : '''pass'''
; text-ws-02-t.svg : '''fail''' - xml:space="preserve" not functioning; non-printing glyphs now displayed
----
Further discussion is on the [http://sourceforge.net/tracker/index.php?func=detail&aid=1224751&group_id=93438&atid=604306 Bug Tracker].

SVG Test Suite Compliance

2005-07-04T10:45:05Z

PeterMoulder: * Update information in Color, Interation and CSS sections

This table summarises the results of testing Inkscape against the [http://www.w3.org/Graphics/SVG/Test/ W3C SVG Test Suite].

This test was performed on Windows with v0.41.

== Key ==
; '''pass''' : the test passed fully (60 occurences)
; '''partial''' : the test partially failed but it may be easy to make it pass (28 occurences)
; '''fail''' : the test failed (72 occurences)
; '''crash''' : the test failed and Inkscape crashed (22 occurences)

----
== Results ==
=== Animation (not yet supported) ===
<i>A crash with the <tt><animate></tt> element has been corrected in CVS already.
This may fix some or all of the crash items in this section.</i>

; animate-elem-02-t.svg : '''crash'''
; animate-elem-03-t.svg : '''crash'''
; animate-elem-04-t.svg : '''fail''' (animation not supported)
; animate-elem-05-t.svg : '''fail''' (animation not supported)
; animate-elem-06-t.svg : '''fail''' (animation not supported)
; animate-elem-07-t.svg : '''fail''' (animation not supported)
; animate-elem-08-t.svg : '''fail''' (animation not supported)
; animate-elem-09-t.svg : '''crash'''
; animate-elem-10-t.svg : '''crash'''
; animate-elem-11-t.svg : '''crash'''
; animate-elem-12-t.svg : '''crash'''
; animate-elem-13-t.svg : '''crash'''
; animate-elem-14-t.svg : '''crash'''
; animate-elem-15-t.svg : '''crash'''
; animate-elem-16-t.svg : '''crash'''
; animate-elem-17-t.svg : '''crash'''
; animate-elem-18-t.svg : '''crash'''
; animate-elem-19-t.svg : '''crash'''
; animate-elem-20-t.svg : '''crash'''
; animate-elem-21-t.svg : '''crash'''
; animate-elem-22-b.svg : '''crash'''
; animate-elem-23-t.svg : '''fail''' (animation not supported)
; animate-elem-24-t.svg : '''fail''' (animation not supported)
; animate-elem-25-t.svg : '''crash'''
; animate-elem-26-t.svg : '''crash'''
; animate-elem-27-t.svg : '''crash'''
; animate-elem-28-t.svg : '''crash'''
; animate-elem-29-b.svg : '''crash'''

=== Colors ===
; color-prof-01-f.svg : '''fail'''
: <i>Tests color profile support. Hopefully the lcms work should address this: see InkscapeColor.</i>
; color-prop-01-b.svg : '''partial''' - red color stop not functioning
: <i>Current CVS now passes this, though there are bugs for variations of this test: see comment in sp_object_get_style_property.</i>
; color-prop-02-f.svg : '''pass'''
; color-prop-03-t.svg : '''pass'''

=== Coordinates ===
; coords-trans-01-b.svg : '''pass'''
; coords-trans-02-t.svg : '''pass'''
; coords-trans-03-t.svg : '''pass'''
; coords-trans-04-t.svg : '''pass'''
; coords-trans-05-t.svg : '''pass'''
; coords-trans-06-t.svg : '''pass'''
; coords-units-01-b.svg : '''partial'''
; coords-units-02-b.svg : '''partial'''
; coords-units-03-b.svg : '''partial''' - the red background is not clipped correctly
; coords-viewattr-01-b.svg : '''fail'''
; coords-viewattr-02-b.svg : '''fail'''
; extend-namespace-01-f.svg : '''fail'''

=== Filters (not yet supported) ===
; filters-blend-01-b.svg : '''fail'''
; filters-color-01-b.svg : '''fail'''
; filters-composite-02-b.svg : '''fail'''
; filters-comptran-01-b.svg : '''fail'''
; filters-conv-01-f.svg : '''fail'''
; filters-diffuse-01-f.svg : '''fail'''
; filters-displace-01-f.svg : '''fail'''
; filters-example-01-b.svg : '''fail'''
; filters-gauss-01-b.svg : '''fail'''
; filters-image-01-b.svg : '''fail'''
; filters-light-01-f.svg : '''fail'''
; filters-morph-01-f.svg : '''fail'''
; filters-offset-01-b.svg : '''fail'''
; filters-specular-01-f.svg : '''fail'''
; filters-tile-01-b.svg : '''fail'''
; filters-turb-01-f.svg : '''fail'''

=== Fonts ===
; fonts-elem-01-t.svg : '''pass'''
; fonts-elem-02-t.svg : '''fail''' (but close to what's requried)
; fonts-elem-03-b.svg : '''fail'''
; fonts-elem-04-b.svg : '''fail'''

=== Interaction (not supported) ===
; interact-cursor-01-f.svg : '''crash'''
: <i>Doesn't crash for me with either 0.41 or current CVS, on Debian Gnu/Linux -- pjrm</i>
: <i>Update: ScislaC has reproduced on windows with current CVS. I haven't yet created a corresponding bug report.</i>
; interact-dom-01-b.svg : '''fail'''
; interact-events-01-b.svg : '''fail'''
; interact-order-01-b.svg : '''fail'''
; interact-order-02-b.svg : '''fail'''
; interact-order-03-b.svg : '''fail'''
; interact-zoom-01-t.svg : '''fail'''

=== Linking ===
; linking-a-01-b.svg : '''fail'''
; linking-a-02-b.svg : '''fail'''
; linking-a-03-b.svg : '''fail'''
; linking-a-04-t.svg : '''fail'''
; linking-uri-01-b.svg : '''fail'''
; linking-uri-02-b.svg : '''fail'''
; linking-uri-03-t.svg : '''fail'''

=== Masking ===
; masking-mask-01-b.svg : '''partial''' - the string is incorrectly rendered
; masking-opacity-01-b.svg : '''pass'''
; masking-path-01-b.svg : '''pass'''
; masking-path-02-b.svg : '''partial'''
; masking-path-03-b.svg : '''fail'''
; masking-path-04-b.svg : '''pass'''
; masking-path-05-f.svg : '''partial''' - clip-rule=evenodd not functioning

=== Metadata ===
; metadata-example-01-b.svg : '''pass''' (I think)

=== Painting ===
; painting-fill-01-t.svg : '''pass'''
; painting-fill-02-t.svg : '''pass'''
; painting-fill-03-t.svg : '''pass'''
; painting-fill-04-t.svg : '''pass'''
; painting-marker-01-f.svg : '''pass'''
; painting-marker-02-f.svg : '''partial''' - mishandling of marker strokes
; painting-render-01-b.svg : '''pass'''
; painting-stroke-01-t.svg : '''pass'''
; painting-stroke-02-t.svg : '''pass'''
; painting-stroke-03-t.svg : '''pass'''
; painting-stroke-04-t.svg : '''pass'''

=== Paths ===
; paths-data-01-t.svg : '''pass'''
; paths-data-02-t.svg : '''partial''' - mqzmqz fails, all others are ok
; paths-data-03-f.svg : '''partial''' - MaZmAZmaz fails, all others are ok
; paths-data-04-t.svg : '''pass'''
; paths-data-05-t.svg : '''pass'''
; paths-data-06-t.svg : '''pass'''
; paths-data-07-t.svg : '''pass'''

=== Color Gradients ===
; pservers-grad-01-b.svg : '''pass'''
; pservers-grad-02-b.svg : '''pass'''
; pservers-grad-03-b.svg : '''pass'''
; pservers-grad-04-b.svg : '''pass'''
; pservers-grad-05-b.svg : '''pass'''
; pservers-grad-06-b.svg : '''pass'''
; pservers-grad-07-b.svg : '''pass'''
; pservers-grad-08-b.svg : '''partial''' - gradient is ok; font is incorrect
; pservers-grad-09-b.svg : '''pass'''
; pservers-grad-10-b.svg : '''pass'''
; pservers-grad-11-b.svg : '''pass'''
; pservers-grad-12-b.svg : '''pass'''
; pservers-pattern-01-b.svg : '''pass'''

=== Rendering ===
; render-elems-01-t.svg : '''pass'''
; render-elems-02-t.svg : '''pass'''
; render-elems-03-t.svg : '''fail'''
; render-elems-06-t.svg : '''partial''' - rendering is ok; font is incorrect
; render-elems-07-t.svg : '''partial''' - rendering is ok; font is incorrect
; render-elems-08-t.svg : '''partial''' - rendering is ok; font is incorrect
; render-groups-01-b.svg : '''partial''' - rendering is ok; font is incorrect
; render-groups-03-t.svg : '''partial''' - rendering is ok; font is incorrect

=== Scripting (not supported) ===
; script-handle-01-b.svg : '''fail'''
; script-handle-02-b.svg : '''fail'''
; script-handle-03-b.svg : '''fail'''
; script-handle-04-b.svg : '''fail'''

=== Shapes ===
; shapes-circle-01-t.svg : '''pass'''
; shapes-ellipse-01-t.svg : '''pass'''
; shapes-line-01-t.svg : '''pass'''
; shapes-polygon-01-t.svg : '''pass'''
; shapes-polyline-01-t.svg : '''partial''' - the pentagon ends are incorrect
; shapes-rect-01-t.svg : '''pass'''

=== Structure ===
; struct-cond-01-t.svg : '''fail'''
; struct-cond-02-t.svg : '''fail'''
; struct-defs-01-t.svg : '''pass'''
; struct-dom-01-b.svg : '''fail'''
; struct-dom-02-b.svg : '''fail'''
; struct-dom-03-b.svg : '''fail'''
; struct-dom-04-b.svg : '''fail'''
; struct-dom-05-b.svg : '''fail'''
; struct-dom-06-b.svg : '''fail'''
; struct-frag-01-t.svg : '''pass'''
; struct-group-01-t.svg : '''pass'''
; struct-group-02-b.svg : '''pass'''
; struct-image-01-t.svg : '''pass'''
; struct-image-02-b.svg : '''partial''' - problem with use element
; struct-image-03-t.svg : '''fail'''
; struct-image-04-t.svg : '''pass'''
; struct-image-05-b.svg : '''fail''' - Message: error loading pixbuf at close
; struct-symbol-01-b.svg : '''partial''' - the topleft image is not resized correctly

=== CSS (not yet supported) ===
<i>Current CVS has basic support for CSS stylesheets, which might be enough to make some or all of these pass; I haven't yet checked.</i>
; styling-css-01-b.svg : '''fail'''
; styling-css-02-b.svg : '''fail'''
; styling-css-03-b.svg : '''fail'''
; styling-inherit-01-b.svg : '''fail'''
; styling-pres-01-t.svg : '''fail'''

=== Text ===
; text-align-01-b.svg : '''pass'''
; text-align-02-b.svg : '''fail''' - baseline-shift not functioning
; text-align-03-b.svg : '''pass'''
; text-align-04-b.svg : '''partial'''
; text-align-05-b.svg : '''fail'''
; text-align-06-b.svg : '''fail'''
; text-altglyph-01-b.svg : '''fail'''
; text-deco-01-b.svg : '''partial''' - underline and strikethrough not functioning
; text-fonts-01-t.svg : '''pass'''
; text-fonts-02-t.svg : '''partial''' - font-weight="lighter" not functioning
; text-intro-01-t.svg : '''pass'''
; text-intro-02-b.svg : '''partial''' - right-to-left text not functioning
; text-intro-03-b.svg : '''partial''' - text is vertical but oriented incorrectly
; text-intro-04-t.svg : '''pass'''
; text-path-01-b.svg : '''partial''' - startOffset attribute of textPath not functioning
; text-spacing-01-b.svg : '''fail'''
; text-text-01-b.svg : '''fail''' - 'textLength' and 'lengthAdjust' not functioning
; text-text-03-b.svg : '''partial''' - underline and strikethrough not functioning
; text-tref-01-b.svg : '''fail''' - tref not functioning
; text-tselect-01-b.svg : '''partial''' - Inkscape's text selection mechanism is quite similar to the standard, but using a dialog (this could therefore be considered a '''pass''')
; text-tspan-01-b.svg : '''partial''' - char-by-char placement not functioning
; text-ws-01-t.svg : '''pass'''
; text-ws-02-t.svg : '''fail''' - xml:space="preserve" not functioning

SVG Test Suite Compliance

2005-07-03T13:48:53Z

PeterMoulder: * add note about color-prop-01-b failure

This table summarises the results of testing Inkscape against the [http://www.w3.org/Graphics/SVG/Test/ W3C SVG Test Suite].

This test was performed on Windows with v0.41.

== Key ==
; '''pass''' : the test passed fully (60 occurences)
; '''partial''' : the test partially failed but it may be easy to make it pass (28 occurences)
; '''fail''' : the test failed (72 occurences)
; '''crash''' : the test failed and Inkscape crashed (22 occurences)

----
== Results ==
=== Animation (not yet supported) ===
<i>A crash with the <tt><animate></tt> element has been corrected in CVS already.
This may fix some or all of the crash items in this section.</i>

; animate-elem-02-t.svg : '''crash'''
; animate-elem-03-t.svg : '''crash'''
; animate-elem-04-t.svg : '''fail''' (animation not supported)
; animate-elem-05-t.svg : '''fail''' (animation not supported)
; animate-elem-06-t.svg : '''fail''' (animation not supported)
; animate-elem-07-t.svg : '''fail''' (animation not supported)
; animate-elem-08-t.svg : '''fail''' (animation not supported)
; animate-elem-09-t.svg : '''crash'''
; animate-elem-10-t.svg : '''crash'''
; animate-elem-11-t.svg : '''crash'''
; animate-elem-12-t.svg : '''crash'''
; animate-elem-13-t.svg : '''crash'''
; animate-elem-14-t.svg : '''crash'''
; animate-elem-15-t.svg : '''crash'''
; animate-elem-16-t.svg : '''crash'''
; animate-elem-17-t.svg : '''crash'''
; animate-elem-18-t.svg : '''crash'''
; animate-elem-19-t.svg : '''crash'''
; animate-elem-20-t.svg : '''crash'''
; animate-elem-21-t.svg : '''crash'''
; animate-elem-22-b.svg : '''crash'''
; animate-elem-23-t.svg : '''fail''' (animation not supported)
; animate-elem-24-t.svg : '''fail''' (animation not supported)
; animate-elem-25-t.svg : '''crash'''
; animate-elem-26-t.svg : '''crash'''
; animate-elem-27-t.svg : '''crash'''
; animate-elem-28-t.svg : '''crash'''
; animate-elem-29-b.svg : '''crash'''

=== Colors ===
; color-prof-01-f.svg : '''fail'''
; color-prop-01-b.svg : '''partial''' - red color stop not functioning
: <i>The failing stop is specified as <tt>currentColor</tt>. Getting this right requires correct inheritance of the <tt>color</tt> property, even though neither <tt><stop></tt> nor <tt><gradient></tt> is an <tt>SPItem</tt>. I believe we are expected to inherit <tt>color</tt> even from the <tt><defs></tt> element if necessary, and that we should be using <tt>CRSelEng</tt> stuff as style.cpp does. -- pjrm</i>
; color-prop-02-f.svg : '''pass'''
; color-prop-03-t.svg : '''pass'''

=== Coordinates ===
; coords-trans-01-b.svg : '''pass'''
; coords-trans-02-t.svg : '''pass'''
; coords-trans-03-t.svg : '''pass'''
; coords-trans-04-t.svg : '''pass'''
; coords-trans-05-t.svg : '''pass'''
; coords-trans-06-t.svg : '''pass'''
; coords-units-01-b.svg : '''partial'''
; coords-units-02-b.svg : '''partial'''
; coords-units-03-b.svg : '''partial''' - the red background is not clipped correctly
; coords-viewattr-01-b.svg : '''fail'''
; coords-viewattr-02-b.svg : '''fail'''
; extend-namespace-01-f.svg : '''fail'''

=== Filters (not yet supported) ===
; filters-blend-01-b.svg : '''fail'''
; filters-color-01-b.svg : '''fail'''
; filters-composite-02-b.svg : '''fail'''
; filters-comptran-01-b.svg : '''fail'''
; filters-conv-01-f.svg : '''fail'''
; filters-diffuse-01-f.svg : '''fail'''
; filters-displace-01-f.svg : '''fail'''
; filters-example-01-b.svg : '''fail'''
; filters-gauss-01-b.svg : '''fail'''
; filters-image-01-b.svg : '''fail'''
; filters-light-01-f.svg : '''fail'''
; filters-morph-01-f.svg : '''fail'''
; filters-offset-01-b.svg : '''fail'''
; filters-specular-01-f.svg : '''fail'''
; filters-tile-01-b.svg : '''fail'''
; filters-turb-01-f.svg : '''fail'''

=== Fonts ===
; fonts-elem-01-t.svg : '''pass'''
; fonts-elem-02-t.svg : '''fail''' (but close to what's requried)
; fonts-elem-03-b.svg : '''fail'''
; fonts-elem-04-b.svg : '''fail'''

=== Interaction (not supported) ===
; interact-cursor-01-f.svg : '''crash'''
: <i>Doesn't crash for me with either 0.41 or current CVS, on Debian Gnu/Linux -- pjrm</i>
; interact-dom-01-b.svg : '''fail'''
; interact-events-01-b.svg : '''fail'''
; interact-order-01-b.svg : '''fail'''
; interact-order-02-b.svg : '''fail'''
; interact-order-03-b.svg : '''fail'''
; interact-zoom-01-t.svg : '''fail'''

=== Linking ===
; linking-a-01-b.svg : '''fail'''
; linking-a-02-b.svg : '''fail'''
; linking-a-03-b.svg : '''fail'''
; linking-a-04-t.svg : '''fail'''
; linking-uri-01-b.svg : '''fail'''
; linking-uri-02-b.svg : '''fail'''
; linking-uri-03-t.svg : '''fail'''

=== Masking ===
; masking-mask-01-b.svg : '''partial''' - the string is incorrectly rendered
; masking-opacity-01-b.svg : '''pass'''
; masking-path-01-b.svg : '''pass'''
; masking-path-02-b.svg : '''partial'''
; masking-path-03-b.svg : '''fail'''
; masking-path-04-b.svg : '''pass'''
; masking-path-05-f.svg : '''partial''' - clip-rule=evenodd not functioning

=== Metadata ===
; metadata-example-01-b.svg : '''pass''' (I think)

=== Painting ===
; painting-fill-01-t.svg : '''pass'''
; painting-fill-02-t.svg : '''pass'''
; painting-fill-03-t.svg : '''pass'''
; painting-fill-04-t.svg : '''pass'''
; painting-marker-01-f.svg : '''pass'''
; painting-marker-02-f.svg : '''partial''' - mishandling of marker strokes
; painting-render-01-b.svg : '''pass'''
; painting-stroke-01-t.svg : '''pass'''
; painting-stroke-02-t.svg : '''pass'''
; painting-stroke-03-t.svg : '''pass'''
; painting-stroke-04-t.svg : '''pass'''

=== Paths ===
; paths-data-01-t.svg : '''pass'''
; paths-data-02-t.svg : '''partial''' - mqzmqz fails, all others are ok
; paths-data-03-f.svg : '''partial''' - MaZmAZmaz fails, all others are ok
; paths-data-04-t.svg : '''pass'''
; paths-data-05-t.svg : '''pass'''
; paths-data-06-t.svg : '''pass'''
; paths-data-07-t.svg : '''pass'''

=== Color Gradients ===
; pservers-grad-01-b.svg : '''pass'''
; pservers-grad-02-b.svg : '''pass'''
; pservers-grad-03-b.svg : '''pass'''
; pservers-grad-04-b.svg : '''pass'''
; pservers-grad-05-b.svg : '''pass'''
; pservers-grad-06-b.svg : '''pass'''
; pservers-grad-07-b.svg : '''pass'''
; pservers-grad-08-b.svg : '''partial''' - gradient is ok; font is incorrect
; pservers-grad-09-b.svg : '''pass'''
; pservers-grad-10-b.svg : '''pass'''
; pservers-grad-11-b.svg : '''pass'''
; pservers-grad-12-b.svg : '''pass'''
; pservers-pattern-01-b.svg : '''pass'''

=== Rendering ===
; render-elems-01-t.svg : '''pass'''
; render-elems-02-t.svg : '''pass'''
; render-elems-03-t.svg : '''fail'''
; render-elems-06-t.svg : '''partial''' - rendering is ok; font is incorrect
; render-elems-07-t.svg : '''partial''' - rendering is ok; font is incorrect
; render-elems-08-t.svg : '''partial''' - rendering is ok; font is incorrect
; render-groups-01-b.svg : '''partial''' - rendering is ok; font is incorrect
; render-groups-03-t.svg : '''partial''' - rendering is ok; font is incorrect

=== Scripting (not supported) ===
; script-handle-01-b.svg : '''fail'''
; script-handle-02-b.svg : '''fail'''
; script-handle-03-b.svg : '''fail'''
; script-handle-04-b.svg : '''fail'''

=== Shapes ===
; shapes-circle-01-t.svg : '''pass'''
; shapes-ellipse-01-t.svg : '''pass'''
; shapes-line-01-t.svg : '''pass'''
; shapes-polygon-01-t.svg : '''pass'''
; shapes-polyline-01-t.svg : '''partial''' - the pentagon ends are incorrect
; shapes-rect-01-t.svg : '''pass'''

=== Structure ===
; struct-cond-01-t.svg : '''fail'''
; struct-cond-02-t.svg : '''fail'''
; struct-defs-01-t.svg : '''pass'''
; struct-dom-01-b.svg : '''fail'''
; struct-dom-02-b.svg : '''fail'''
; struct-dom-03-b.svg : '''fail'''
; struct-dom-04-b.svg : '''fail'''
; struct-dom-05-b.svg : '''fail'''
; struct-dom-06-b.svg : '''fail'''
; struct-frag-01-t.svg : '''pass'''
; struct-group-01-t.svg : '''pass'''
; struct-group-02-b.svg : '''pass'''
; struct-image-01-t.svg : '''pass'''
; struct-image-02-b.svg : '''partial''' - problem with use element
; struct-image-03-t.svg : '''fail'''
; struct-image-04-t.svg : '''pass'''
; struct-image-05-b.svg : '''fail''' - Message: error loading pixbuf at close
; struct-symbol-01-b.svg : '''partial''' - the topleft image is not resized correctly

=== CSS (not yet supported) ===
; styling-css-01-b.svg : '''fail'''
; styling-css-02-b.svg : '''fail'''
; styling-css-03-b.svg : '''fail'''
; styling-inherit-01-b.svg : '''fail'''
; styling-pres-01-t.svg : '''fail'''

=== Text ===
; text-align-01-b.svg : '''pass'''
; text-align-02-b.svg : '''fail''' - baseline-shift not functioning
; text-align-03-b.svg : '''pass'''
; text-align-04-b.svg : '''partial'''
; text-align-05-b.svg : '''fail'''
; text-align-06-b.svg : '''fail'''
; text-altglyph-01-b.svg : '''fail'''
; text-deco-01-b.svg : '''partial''' - underline and strikethrough not functioning
; text-fonts-01-t.svg : '''pass'''
; text-fonts-02-t.svg : '''partial''' - font-weight="lighter" not functioning
; text-intro-01-t.svg : '''pass'''
; text-intro-02-b.svg : '''partial''' - right-to-left text not functioning
; text-intro-03-b.svg : '''partial''' - text is vertical but oriented incorrectly
; text-intro-04-t.svg : '''pass'''
; text-path-01-b.svg : '''partial''' - startOffset attribute of textPath not functioning
; text-spacing-01-b.svg : '''fail'''
; text-text-01-b.svg : '''fail''' - 'textLength' and 'lengthAdjust' not functioning
; text-text-03-b.svg : '''partial''' - underline and strikethrough not functioning
; text-tref-01-b.svg : '''fail''' - tref not functioning
; text-tselect-01-b.svg : '''partial''' - Inkscape's text selection mechanism is quite similar to the standard, but using a dialog (this could therefore be considered a '''pass''')
; text-tspan-01-b.svg : '''partial''' - char-by-char placement not functioning
; text-ws-01-t.svg : '''pass'''
; text-ws-02-t.svg : '''fail''' - xml:space="preserve" not functioning

SVG Test Suite Compliance

2005-07-02T02:14:22Z

PeterMoulder: * interact-cursor-01-f.svg doesn't crash for me

This table summarises the results of testing Inkscape against the [http://www.w3.org/Graphics/SVG/Test/ W3C SVG Test Suite].

This test was performed on Windows with v0.41.

== Key ==
; '''pass''' : the test passed fully (60 occurences)
; '''partial''' : the test partially failed but it may be easy to make it pass (28 occurences)
; '''fail''' : the test failed (72 occurences)
; '''crash''' : the test failed and Inkscape crashed (22 occurences)

----
== Results ==
=== Animation (not yet supported) ===
<i>A crash with the <tt><animate></tt> element has been corrected in CVS already.
This may fix some or all of the crash items in this section.</i>

; animate-elem-02-t.svg : '''crash'''
; animate-elem-03-t.svg : '''crash'''
; animate-elem-04-t.svg : '''fail''' (animation not supported)
; animate-elem-05-t.svg : '''fail''' (animation not supported)
; animate-elem-06-t.svg : '''fail''' (animation not supported)
; animate-elem-07-t.svg : '''fail''' (animation not supported)
; animate-elem-08-t.svg : '''fail''' (animation not supported)
; animate-elem-09-t.svg : '''crash'''
; animate-elem-10-t.svg : '''crash'''
; animate-elem-11-t.svg : '''crash'''
; animate-elem-12-t.svg : '''crash'''
; animate-elem-13-t.svg : '''crash'''
; animate-elem-14-t.svg : '''crash'''
; animate-elem-15-t.svg : '''crash'''
; animate-elem-16-t.svg : '''crash'''
; animate-elem-17-t.svg : '''crash'''
; animate-elem-18-t.svg : '''crash'''
; animate-elem-19-t.svg : '''crash'''
; animate-elem-20-t.svg : '''crash'''
; animate-elem-21-t.svg : '''crash'''
; animate-elem-22-b.svg : '''crash'''
; animate-elem-23-t.svg : '''fail''' (animation not supported)
; animate-elem-24-t.svg : '''fail''' (animation not supported)
; animate-elem-25-t.svg : '''crash'''
; animate-elem-26-t.svg : '''crash'''
; animate-elem-27-t.svg : '''crash'''
; animate-elem-28-t.svg : '''crash'''
; animate-elem-29-b.svg : '''crash'''

=== Colors ===
; color-prof-01-f.svg : '''fail'''
; color-prop-01-b.svg : '''partial''' - red color stop not functioning
; color-prop-02-f.svg : '''pass'''
; color-prop-03-t.svg : '''pass'''

=== Coordinates ===
; coords-trans-01-b.svg : '''pass'''
; coords-trans-02-t.svg : '''pass'''
; coords-trans-03-t.svg : '''pass'''
; coords-trans-04-t.svg : '''pass'''
; coords-trans-05-t.svg : '''pass'''
; coords-trans-06-t.svg : '''pass'''
; coords-units-01-b.svg : '''partial'''
; coords-units-02-b.svg : '''partial'''
; coords-units-03-b.svg : '''partial''' - the red background is not clipped correctly
; coords-viewattr-01-b.svg : '''fail'''
; coords-viewattr-02-b.svg : '''fail'''
; extend-namespace-01-f.svg : '''fail'''

=== Filters (not yet supported) ===
; filters-blend-01-b.svg : '''fail'''
; filters-color-01-b.svg : '''fail'''
; filters-composite-02-b.svg : '''fail'''
; filters-comptran-01-b.svg : '''fail'''
; filters-conv-01-f.svg : '''fail'''
; filters-diffuse-01-f.svg : '''fail'''
; filters-displace-01-f.svg : '''fail'''
; filters-example-01-b.svg : '''fail'''
; filters-gauss-01-b.svg : '''fail'''
; filters-image-01-b.svg : '''fail'''
; filters-light-01-f.svg : '''fail'''
; filters-morph-01-f.svg : '''fail'''
; filters-offset-01-b.svg : '''fail'''
; filters-specular-01-f.svg : '''fail'''
; filters-tile-01-b.svg : '''fail'''
; filters-turb-01-f.svg : '''fail'''

=== Fonts ===
; fonts-elem-01-t.svg : '''pass'''
; fonts-elem-02-t.svg : '''fail''' (but close to what's requried)
; fonts-elem-03-b.svg : '''fail'''
; fonts-elem-04-b.svg : '''fail'''

=== Interaction (not supported) ===
; interact-cursor-01-f.svg : '''crash'''
: <i>Doesn't crash for me with either 0.41 or current CVS, on Debian Gnu/Linux -- pjrm</i>
; interact-dom-01-b.svg : '''fail'''
; interact-events-01-b.svg : '''fail'''
; interact-order-01-b.svg : '''fail'''
; interact-order-02-b.svg : '''fail'''
; interact-order-03-b.svg : '''fail'''
; interact-zoom-01-t.svg : '''fail'''

=== Linking ===
; linking-a-01-b.svg : '''fail'''
; linking-a-02-b.svg : '''fail'''
; linking-a-03-b.svg : '''fail'''
; linking-a-04-t.svg : '''fail'''
; linking-uri-01-b.svg : '''fail'''
; linking-uri-02-b.svg : '''fail'''
; linking-uri-03-t.svg : '''fail'''

=== Masking ===
; masking-mask-01-b.svg : '''partial''' - the string is incorrectly rendered
; masking-opacity-01-b.svg : '''pass'''
; masking-path-01-b.svg : '''pass'''
; masking-path-02-b.svg : '''partial'''
; masking-path-03-b.svg : '''fail'''
; masking-path-04-b.svg : '''pass'''
; masking-path-05-f.svg : '''partial''' - clip-rule=evenodd not functioning

=== Metadata ===
; metadata-example-01-b.svg : '''pass''' (I think)

=== Painting ===
; painting-fill-01-t.svg : '''pass'''
; painting-fill-02-t.svg : '''pass'''
; painting-fill-03-t.svg : '''pass'''
; painting-fill-04-t.svg : '''pass'''
; painting-marker-01-f.svg : '''pass'''
; painting-marker-02-f.svg : '''partial''' - mishandling of marker strokes
; painting-render-01-b.svg : '''pass'''
; painting-stroke-01-t.svg : '''pass'''
; painting-stroke-02-t.svg : '''pass'''
; painting-stroke-03-t.svg : '''pass'''
; painting-stroke-04-t.svg : '''pass'''

=== Paths ===
; paths-data-01-t.svg : '''pass'''
; paths-data-02-t.svg : '''partial''' - mqzmqz fails, all others are ok
; paths-data-03-f.svg : '''partial''' - MaZmAZmaz fails, all others are ok
; paths-data-04-t.svg : '''pass'''
; paths-data-05-t.svg : '''pass'''
; paths-data-06-t.svg : '''pass'''
; paths-data-07-t.svg : '''pass'''

=== Color Gradients ===
; pservers-grad-01-b.svg : '''pass'''
; pservers-grad-02-b.svg : '''pass'''
; pservers-grad-03-b.svg : '''pass'''
; pservers-grad-04-b.svg : '''pass'''
; pservers-grad-05-b.svg : '''pass'''
; pservers-grad-06-b.svg : '''pass'''
; pservers-grad-07-b.svg : '''pass'''
; pservers-grad-08-b.svg : '''partial''' - gradient is ok; font is incorrect
; pservers-grad-09-b.svg : '''pass'''
; pservers-grad-10-b.svg : '''pass'''
; pservers-grad-11-b.svg : '''pass'''
; pservers-grad-12-b.svg : '''pass'''
; pservers-pattern-01-b.svg : '''pass'''

=== Rendering ===
; render-elems-01-t.svg : '''pass'''
; render-elems-02-t.svg : '''pass'''
; render-elems-03-t.svg : '''fail'''
; render-elems-06-t.svg : '''partial''' - rendering is ok; font is incorrect
; render-elems-07-t.svg : '''partial''' - rendering is ok; font is incorrect
; render-elems-08-t.svg : '''partial''' - rendering is ok; font is incorrect
; render-groups-01-b.svg : '''partial''' - rendering is ok; font is incorrect
; render-groups-03-t.svg : '''partial''' - rendering is ok; font is incorrect

=== Scripting (not supported) ===
; script-handle-01-b.svg : '''fail'''
; script-handle-02-b.svg : '''fail'''
; script-handle-03-b.svg : '''fail'''
; script-handle-04-b.svg : '''fail'''

=== Shapes ===
; shapes-circle-01-t.svg : '''pass'''
; shapes-ellipse-01-t.svg : '''pass'''
; shapes-line-01-t.svg : '''pass'''
; shapes-polygon-01-t.svg : '''pass'''
; shapes-polyline-01-t.svg : '''partial''' - the pentagon ends are incorrect
; shapes-rect-01-t.svg : '''pass'''

=== Structure ===
; struct-cond-01-t.svg : '''fail'''
; struct-cond-02-t.svg : '''fail'''
; struct-defs-01-t.svg : '''pass'''
; struct-dom-01-b.svg : '''fail'''
; struct-dom-02-b.svg : '''fail'''
; struct-dom-03-b.svg : '''fail'''
; struct-dom-04-b.svg : '''fail'''
; struct-dom-05-b.svg : '''fail'''
; struct-dom-06-b.svg : '''fail'''
; struct-frag-01-t.svg : '''pass'''
; struct-group-01-t.svg : '''pass'''
; struct-group-02-b.svg : '''pass'''
; struct-image-01-t.svg : '''pass'''
; struct-image-02-b.svg : '''partial''' - problem with use element
; struct-image-03-t.svg : '''fail'''
; struct-image-04-t.svg : '''pass'''
; struct-image-05-b.svg : '''fail''' - Message: error loading pixbuf at close
; struct-symbol-01-b.svg : '''partial''' - the topleft image is not resized correctly

=== CSS (not yet supported) ===
; styling-css-01-b.svg : '''fail'''
; styling-css-02-b.svg : '''fail'''
; styling-css-03-b.svg : '''fail'''
; styling-inherit-01-b.svg : '''fail'''
; styling-pres-01-t.svg : '''fail'''

=== Text ===
; text-align-01-b.svg : '''pass'''
; text-align-02-b.svg : '''fail''' - baseline-shift not functioning
; text-align-03-b.svg : '''pass'''
; text-align-04-b.svg : '''partial'''
; text-align-05-b.svg : '''fail'''
; text-align-06-b.svg : '''fail'''
; text-altglyph-01-b.svg : '''fail'''
; text-deco-01-b.svg : '''partial''' - underline and strikethrough not functioning
; text-fonts-01-t.svg : '''pass'''
; text-fonts-02-t.svg : '''partial''' - font-weight="lighter" not functioning
; text-intro-01-t.svg : '''pass'''
; text-intro-02-b.svg : '''partial''' - right-to-left text not functioning
; text-intro-03-b.svg : '''partial''' - text is vertical but oriented incorrectly
; text-intro-04-t.svg : '''pass'''
; text-path-01-b.svg : '''partial''' - startOffset attribute of textPath not functioning
; text-spacing-01-b.svg : '''fail'''
; text-text-01-b.svg : '''fail''' - 'textLength' and 'lengthAdjust' not functioning
; text-text-03-b.svg : '''partial''' - underline and strikethrough not functioning
; text-tref-01-b.svg : '''fail''' - tref not functioning
; text-tselect-01-b.svg : '''partial''' - Inkscape's text selection mechanism is quite similar to the standard, but using a dialog (this could therefore be considered a '''pass''')
; text-tspan-01-b.svg : '''partial''' - char-by-char placement not functioning
; text-ws-01-t.svg : '''pass'''
; text-ws-02-t.svg : '''fail''' - xml:space="preserve" not functioning

CorelDraw

2005-06-30T07:44:33Z

PeterMoulder: * Add link to a comparison betw CorelDraw,Illustrator,iGrafxDesigner

Please post links to screenshots and/or insights of this vector app. We must learn from others.

[http://www.ex-astris-scientia.org/misc/software_test.htm Comparison] (from the point of view of technical drawing) of Corel Draw 9, iGrafx Designer and Adobe Illustrator 8. Fairly detailed. The comparison criteria paragraphs are also interesting in showing the features that the writer finds useful.

=== Screenshots ===

None yet...

=== Links ===

[http://www.coreldraw.com/ official site]

SVG Tiny Compliance

2005-06-21T12:12:10Z

PeterMoulder: * Give info on accessibility issues for SVG

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 "[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 SVG. Some 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&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 [[Beatware Mobile Designer]]

Animation-(Timeline)

2005-05-25T06:25:07Z

PeterMoulder: * Reinstate the claim that LimSee2 is not open-source.

=== User interface for timeline-based animation ===

==== Existing animation programs (Free & non-Free) ====

* MacromediaFlash is a good non-Free example.
* Macromedia Director prior to version MX had a different interface (http://www.rice.edu/fondren/erc/howto/director.html) which I prefer(ed) over Flash
* F4L is a non-functional free-software mock-up of the Flash 4 interface.
* [[Moho]] as a gratis-but-non-free example. (Written in Java.)
* LimSee2 (http://wam.inrialpes.fr/software/limsee2/) is an excellent almost-free basis. (The web site incorrectly claims open source, but it means only that the source code is visible: the actual license says in capital letters no commercial use or distribution.)
* Spalah Flash (http://spalah.sourceforge.net/?p=10) (not to be confused with Spalah CMS) "is a GTK2/GNOME2 based application for generating Macromedia SWF and W3C SVG animations." The GUI is today minimalist but the author is trying to integrate it with inkscape. See http://spalah.sourceforge.net/?p=19

==== Other thoughts ====

Suggestion from someone else: working like CinePaint (compaired with Gimp), with each frame independently from each svg document (working like this or providing this feature) - providing vectorial edition quality we can't get on apps like MacromediaFlash or any other (maybe ToonBoom or Moho) - allowing us to make our work fast publish without further lack of quality.
(One more suggestion about it: being able to convert .swf to .svg sequence (or animated .sgv) and vice versa.)

It is suggested that there be basically two modes: Local (Object) mode and Global mode. Below is a picture showing a very rough design of the local mode:
http://www.inkscape.org/wiki_uploads/anim_gui1.png

In local modes, all properties of the object editing will be shown on a timeline, and one can create and edit frame within the timeline. Then one may assign different value of that properties on different timeline, or make it change linearly, or inlinearly :)

==== Fantavision example ====
Back in the '80's there was a program on Apple IIE (Amiga and MS-DOS too) called "Fantavision". It allowed one to create vector artwork (although I didn't understand at the time that that was what it was called) and animations. It allowed one to create frames of animation where you manually repositioned, recolored, scaled, rotated etc. the objects from one frame to the next. However, it then automatically interpolated frames between the 2 frames (the number of interpolated frames was configurable) such that it create a smooth transition of the object moving from one frame to the other. The effect was very similiar to the "Morphing" effect for raster graphics (popularized in a Michael Jackson video, I believe). That is, the system calculated the trajectory of "Key Points" of the objects from one frame to the next. This process is often called "Tweening" (a term used by Macromedia Flash). [[Sketch|Skencil]] (formerly known as [[Sketch]]) supports this functionality and describes it as "Blending".

I guess what I'm saying is that I think a nice interface to create animations would be similiar. So to animate you would do the following:

* Draw the initial SVG Image

* Increment Frame (from say 1 to 20)

* Reposition the elements in frame 20 (including scaling, color changes, adding removing objects, etc, etc, etc)

* System would then calculate a trajectory for each key point from frame 1 to frame 20. Trajectories would be calculated for things like:
** Each "node" of an object
** Color
** Transformation Matrix
** etc

* You could display/manipulate the trajectories (using the trajectory editor shown above by the original creator of this topic)

* The system would then store the animations using SVG trajectories and the "Key Points" would be the frames you manually created

:So, to create say a 100 frame animation, one might only need to manually create/modify 10 frames and the system would interpolate the additional frames as necessary.

* Also, once the system interpolated frames it would allow you to manually modify the interpolated frames creating further "Key Points" and allow further refinement and interpolation.

NOTE: 3D apps such as blender also use a technique like this, which I think is most widely known as "keyframe animation" or simply "keyframing". However, many such systems tie the keys too closely to actual animation frames, and this creates problems when the frames-per-second rate changes. Particularly in the case of vector apps which are not so low-level as bitmaps and animation frames, I would suggest that frames should be as abstract as possible.

Having key positions in simple percentages of the total animation time might be a better solution. This would also need to be a global/local system, of course: animated objects would have their own animation time specified when inserted into a larger document. A character's walkcycle would end at 100%, but in the larger animation, it would perhaps only be 5% of the total time, yet repeating as the object moves across the screen.

One issue with this abstraction of frames might be that important animation effects do not occur exactly within frames: small things could be mistimed, or simply missed altogether. If you set the frame rate too low, this would be an obvious side effect, so it's not necessarily a problem
that Inkscape should try to fix. On the other hand, a few things could be done to ease this. For instance, "snapping" animation events to frames when exporting (thereby slightly altering the timing), or perhaps just warning that certain animation events are not visible at such a low frame rate.

Of course, on the web, with SVG and DHTML, where most Inkscape animations will hopefully be used one day, frames are not an issue at all, and we just worry about keys in time :)

CSS Support

2005-05-16T07:32:11Z

PeterMoulder: * Update status of @font-face support.

=== Current State ===

An initial implementation is now in CVS. Limitations:

* Allows a single <style> element in the document. Doesn't allow external stylesheets, doesn't allow more than one <style> element.
: (Or rather it ignores all but one of the <style> elements, possibly changing which one it respects based on which was most recently re-read.)

* No editing interface other than the XML editor.

: There are a number of aspects of editing:

** The most basic level: allow editing using the XML editor. (See Update section below.)
** Editing a stylesheet.
** Specifying what classes each object belongs to.

* Doesn't respect media restrictions (e.g. ignores "this rule applies only to non-visual media" directives, and doesn't allow having one style for print and another style for on-screen).

* <tt>@font-face</tt> hints are ignored.

* Doesn't handle any other at-rules (<tt>@media</tt>, <tt>@import</tt>, @page, ...).

==== An incomplete list of work needed: ====

* Ensure that this single stylesheet is updated whenever any of the <tt><style></tt> elements change (or are deleted or created etc.).

* Similarly, ensure that the picture is refreshed when the stylesheet is changed.

* Convert the simple user agent style sheet given at http://www.w3.org/TR/SVG11/styling.html#UAStyleSheet to libcroco structures (perhaps by passing strings to libcroco parsing functions) and store in <tt>desktop->style_cascade</tt>.

* Modify style.cpp to query the stylesheet. (Done but not checked in.)

* There may be some work needed for "shorthand properties", e.g. `<tt>marker</tt>' is shorthand for modifying <tt>marker-start</tt>, <tt>marker-mid</tt> and <tt>marker-end</tt> properties (http://www.w3.org/TR/SVG11/painting.html#MarkerProperty). A non-SVG CSS example is `<tt>margin</tt>'.

==== Updating for changes to <style> content ====

State so far: Every keystroke in the xml editor in the content of the <style> element gets sp_style_elem_read_content to be re-read.
One can force an object to get the revised stylesheet info by e.g. <Up> <Down> (forcing an update) then deleting its style attribute.
So one change is that we shouldn't be so keen to put things in the <tt>style</tt> attribute.
Currently, the stylesheet info gets merged into <tt>SPStyle</tt>, and set the <tt>style</tt> attribute to contain everything in <tt>SPStyle</tt> (and clear any styling attributes like <tt>fill=...</tt>).
One existing problem with this behaviour (other than how it interacts with stylesheets) is that we discard any <tt>style</tt> properties we don't know about. Whereas we ought to remember the content of the style attribute and only replace the properties we've changed, and add to if necessary.

One implementation would be to keep <tt>SPStyle</tt> but indicate which properties came from where, and hence which ones need to be written to the style attribute and which ones don't.
Apart from not writing if src==stylesheet, we can also avoid writing if src==attribute: i.e. don't gratuitously break SVG Tiny conformance of a document (or more generally break compatibility with implementations that don't honour CSS <tt>style</tt> attributes).
Not to say that we can't choose to use the <tt>style</tt> attribute for properties that the user changes during an inkscape session, but currently we change from attributes to <tt>style=</tt>... even for shapes that the user just changes the position of without changing any styling stuff.

==== Why can't we use libcroco-0.6's existing libxml interface to cr-sel-eng.c ? ====

Some CSS selectors (http://www.w3.org/TR/REC-CSS2/selector.html) can express "is preceded by X" or "is a descendent of X" (where X can itself be similarly constrained recursively), so we'd pretty much need to maintain the entire document in libxml form if we want to use libcroco for CSS selectors.

Suppose we want to find the style of node N. We pass libcroco a stylesheet and ask it what rules apply to N.
If the stylesheet says "nodes that are preceded by a node that is preceded by a node that's a descendent of (... etc. ...) have red stroking" then libcroco needs to be able to navigate through the tree.
So we can't pass libcroco just a libxml version of node N, we need to fill in its parent and sibling links, providing a libxml node for a significant proportion of all nodes in the tree.
(Short of using hardware watchpoints to check access to the sibling/parent links and supply them lazily.)

CSS Support

2005-05-13T00:18:55Z

PeterMoulder: * Mention lack of at-rules.

=== Current State ===

An initial implementation is now in CVS. Limitations:

* Allows a single <style> element in the document. Doesn't allow external stylesheets, doesn't allow more than one <style> element.
: (Or rather it ignores all but one of the <style> elements, possibly changing which one it respects based on which was most recently re-read.)

* No editing interface other than the XML editor.

: There are a number of aspects of editing:

** The most basic level: allow editing using the XML editor. (See Update section below.)
** Editing a stylesheet.
** Specifying what classes each object belongs to.

* Doesn't respect media restrictions (e.g. ignores "this rule applies only to non-visual media" directives, and doesn't allow having one style for print and another style for on-screen).

* Doesn't handle any at-rules (<tt>@font-face</tt>, <tt>@media</tt>, ...).

==== An incomplete list of work needed: ====

* Ensure that this single stylesheet is updated whenever any of the <tt><style></tt> elements change (or are deleted or created etc.).

* Similarly, ensure that the picture is refreshed when the stylesheet is changed.

* Convert the simple user agent style sheet given at http://www.w3.org/TR/SVG11/styling.html#UAStyleSheet to libcroco structures (perhaps by passing strings to libcroco parsing functions) and store in <tt>desktop->style_cascade</tt>.

* Modify style.cpp to query the stylesheet. (Done but not checked in.)

* There may be some work needed for "shorthand properties", e.g. `<tt>marker</tt>' is shorthand for modifying <tt>marker-start</tt>, <tt>marker-mid</tt> and <tt>marker-end</tt> properties (http://www.w3.org/TR/SVG11/painting.html#MarkerProperty). A non-SVG CSS example is `<tt>margin</tt>'.

==== Updating for changes to <style> content ====

State so far: Every keystroke in the xml editor in the content of the <style> element gets sp_style_elem_read_content to be re-read.
One can force an object to get the revised stylesheet info by e.g. <Up> <Down> (forcing an update) then deleting its style attribute.
So one change is that we shouldn't be so keen to put things in the <tt>style</tt> attribute.
Currently, the stylesheet info gets merged into <tt>SPStyle</tt>, and set the <tt>style</tt> attribute to contain everything in <tt>SPStyle</tt> (and clear any styling attributes like <tt>fill=...</tt>).
One existing problem with this behaviour (other than how it interacts with stylesheets) is that we discard any <tt>style</tt> properties we don't know about. Whereas we ought to remember the content of the style attribute and only replace the properties we've changed, and add to if necessary.

One implementation would be to keep <tt>SPStyle</tt> but indicate which properties came from where, and hence which ones need to be written to the style attribute and which ones don't.
Apart from not writing if src==stylesheet, we can also avoid writing if src==attribute: i.e. don't gratuitously break SVG Tiny conformance of a document (or more generally break compatibility with implementations that don't honour CSS <tt>style</tt> attributes).
Not to say that we can't choose to use the <tt>style</tt> attribute for properties that the user changes during an inkscape session, but currently we change from attributes to <tt>style=</tt>... even for shapes that the user just changes the position of without changing any styling stuff.

==== Why can't we use libcroco-0.6's existing libxml interface to cr-sel-eng.c ? ====

Some CSS selectors (http://www.w3.org/TR/REC-CSS2/selector.html) can express "is preceded by X" or "is a descendent of X" (where X can itself be similarly constrained recursively), so we'd pretty much need to maintain the entire document in libxml form if we want to use libcroco for CSS selectors.

Suppose we want to find the style of node N. We pass libcroco a stylesheet and ask it what rules apply to N.
If the stylesheet says "nodes that are preceded by a node that is preceded by a node that's a descendent of (... etc. ...) have red stroking" then libcroco needs to be able to navigate through the tree.
So we can't pass libcroco just a libxml version of node N, we need to fill in its parent and sibling links, providing a libxml node for a significant proportion of all nodes in the tree.
(Short of using hardware watchpoints to check access to the sibling/parent links and supply them lazily.)

CSS Support

2005-05-13T00:16:35Z

PeterMoulder: * Add section: updating for changes to <style> content

=== Current State ===

An initial implementation is now in CVS. Limitations:

* Allows a single <style> element in the document. Doesn't allow external stylesheets, doesn't allow more than one <style> element.
: (Or rather it ignores all but one of the <style> elements, possibly changing which one it respects based on which was most recently re-read.)

* No editing interface other than the XML editor.

: There are a number of aspects of editing:

** The most basic level: allow editing using the XML editor.
** Editing a stylesheet.
** Specifying what classes each object belongs to.

* Doesn't respect media restrictions (e.g. ignores "this rule applies only to non-visual media" directives, and doesn't allow having one style for print and another style for on-screen).

==== An incomplete list of work needed: ====

* Ensure that this single stylesheet is updated whenever any of the <tt><style></tt> elements change (or are deleted or created etc.).

* Similarly, ensure that the picture is refreshed when the stylesheet is changed.

* Convert the simple user agent style sheet given at http://www.w3.org/TR/SVG11/styling.html#UAStyleSheet to libcroco structures (perhaps by passing strings to libcroco parsing functions) and store in <tt>desktop->style_cascade</tt>.

* Modify style.cpp to query the stylesheet. (Done but not checked in.)

* There may be some work needed for "shorthand properties", e.g. `<tt>marker</tt>' is shorthand for modifying <tt>marker-start</tt>, <tt>marker-mid</tt> and <tt>marker-end</tt> properties (http://www.w3.org/TR/SVG11/painting.html#MarkerProperty). A non-SVG CSS example is `<tt>margin</tt>'.

==== Updating for changes to <style> content ====

State so far: Every keystroke in the xml editor in the content of the <style> element gets sp_style_elem_read_content to be re-read.
One can force an object to get the revised stylesheet info by e.g. <Up> <Down> (forcing an update) then deleting its style attribute.
So one change is that we shouldn't be so keen to put things in the <tt>style</tt> attribute.
Currently, the stylesheet info gets merged into <tt>SPStyle</tt>, and set the <tt>style</tt> attribute to contain everything in <tt>SPStyle</tt> (and clear any styling attributes like <tt>fill=...</tt>).
One existing problem with this behaviour (other than how it interacts with stylesheets) is that we discard any <tt>style</tt> properties we don't know about. Whereas we ought to remember the content of the style attribute and only replace the properties we've changed, and add to if necessary.

One implementation would be to keep <tt>SPStyle</tt> but indicate which properties came from where, and hence which ones need to be written to the style attribute and which ones don't.
Apart from not writing if src==stylesheet, we can also avoid writing if src==attribute: i.e. don't gratuitously break SVG Tiny conformance of a document (or more generally break compatibility with implementations that don't honour CSS <tt>style</tt> attributes).
Not to say that we can't choose to use the <tt>style</tt> attribute for properties that the user changes during an inkscape session, but currently we change from attributes to <tt>style=</tt>... even for shapes that the user just changes the position of without changing any styling stuff.

==== Why can't we use libcroco-0.6's existing libxml interface to cr-sel-eng.c ? ====

Some CSS selectors (http://www.w3.org/TR/REC-CSS2/selector.html) can express "is preceded by X" or "is a descendent of X" (where X can itself be similarly constrained recursively), so we'd pretty much need to maintain the entire document in libxml form if we want to use libcroco for CSS selectors.

Suppose we want to find the style of node N. We pass libcroco a stylesheet and ask it what rules apply to N.
If the stylesheet says "nodes that are preceded by a node that is preceded by a node that's a descendent of (... etc. ...) have red stroking" then libcroco needs to be able to navigate through the tree.
So we can't pass libcroco just a libxml version of node N, we need to fill in its parent and sibling links, providing a libxml node for a significant proportion of all nodes in the tree.
(Short of using hardware watchpoints to check access to the sibling/parent links and supply them lazily.)

CSS Support

2005-05-11T08:29:37Z

PeterMoulder: * Update now that an initial implementation is checked in.

Coding Style

2005-05-05T21:39:39Z

PeterMoulder: * Add to advantages of marking local names with `static'

== Inkscape Coding Style Discussion ==

The <a href="/doc/coding_style.php">official code style documentation</a> is on the main website.

This page is for discussing and working out changes and improvements to that document. When concensus
is reached, the document can be updated in CVS int he inkscape_web module.

=== Editor support ===

Place the following at the end of source files to help emacsen & vim users follow some of our guidelines automatically:
<pre>
/*
Local Variables:
mode:c++
c-file-style:"stroustrup"
c-file-offsets:((innamespace . 0)(inline-open . 0)(case-label . +))
indent-tabs-mode:nil
fill-column:99
End:
*/
// vim: filetype=cpp:expandtab:shiftwidth=4:tabstop=8:softtabstop=4:encoding=utf-8:textwidth=99 :
</pre>

Once you've added those lines, close the file and re-open it for it to take effect.

Then (for emacsen users), one can re-indent a region with C-M-\.

=== crazyCamelCase v. Underscores ===
* The new coding standards require non-static member functions to be in pseudoCamelCase, and every other type of function to use underscores.
* The current codebase has very few real C++ objects, half of these objects (or more) seem to use underscores for their member functions, the other half seem to use pseudoCamelCase.
** Over-all, 95% of Inkscape's codebase uses underscores in function names (of coures, 90% of the code is still C).
*** It seems underscores are what Inkscape developers are already used to.

* I prefer CamelCase for type names (classes), exceptions, namespaces, and the like. But pseudoCamelCase in member functions clutters the visual space; making types, exceptions, and namescapes stand out much less. And it makes the code much harder (for me) to read.
** Why is there this inconsistency with regard to function names in the new coding standard?
*** (I.e., why a few functions pseudoCamelCase, and everything else underscores?)
** Could all functions just use underscores? (Like the current codebase, like Gtkmm, like Linux, like the C & C++ standard libraries, and like almost every other project out there?)
** Is static vs. non-static member functions really that big of an issue to warrant a change to pseudoCamelCase?

* Hey, we're not programming in Java (or Qt) here! This is C++, where underscore reigns supreme.

=== Tabs and Alignment ===

* Something else to consider is developer culture -- most of our developers at this point will likely be accustomed to either GNU coding standards (2/4-space indent), or GNOME/Linux-kernel coding standards (8-space indention quantum). [What does KDE recommend?]

* Objective studies have found that indentions between 2 and 6 columns are optimal.
::Reference: [ProgramIndentation Miara, J. R., J. A. Musselman, J. A. Navarro, and B. Shneiderman. Program
Indentation and Comprehensibility. Comm. ACM 26, 11 (Nov. 1983), 861-867.]

* No tabs in files.
** By default many editors (and pagers as used for viewing diffs, and "diff -t") set tab stops to 8.
:: If files end up with mixed space & tab alignment (other than the "structural indentation" approach discussed below), then it breaks formatting to use anything but 8 as one's editor's tab stop size.

** Suggesting that people change their tab stop size is only practical if all source code uses spaces & tabs the same way.

:: This may be possible with mode lines if all Inkscape developers stick to editors with appropriate modeline support (emacsen, vim/gvim; anything else?).
:: Do any popular Windows/MacOS editors (other than the above) support mode lines?
:: What about KDevelop/anjuta/other IDE's on Un*x?

::It's fairly easy to define this behavior for Emacs and VIM. Having it explicit might be enough.

::It's possible to add checkin scripts to CVS to warn/prevent checkins with tabs, etc.

** A minor disadvantage of using spaces for indentation is that some text editors (not emacsen or vim) would require using the space key a lot. On the other hand, code written in such an editor probably requires reformatting anyway.

** Observing a rule of using tabs for structural indentation, and spaces for cosmetic (e.g. continuation) indentation, works fine regardless of a particular user's tab stops.

::Somewhat contrived example (as seen with an 8-character tab stop):

if (gromzalon) {
imagine_that_this_is_very_long(some, arguments,
go, here);
}

::The breakdown:

<=Tab====>if (gromzalon) {
<=Tab====><=Tab====>imagine_that_this_is_very_long(some, arguments,
<=Tab====><=Tab====><=Spaces======================>go, here);
<=Tab====>}

::What this looks like with a tab stop of 3:

if (gromzalon) {
imagine_that_this_is_very_long(some, arguments,
go, here);
}
::-- MenTaLguY

:: (By the way, anyone submitting code with identifiers like "gromzalon" or "sprunklefrink" will be summarily shot.)

:: However, such an indentation rule would only be a feasible recommendataion if it had automated support from at least one of {vim, emacsen, a standalone indenter like astyle}. We don't know of any software to support this. Indeed, most editors (including vim and emacsen) tend to "normalize" spacing when indenting or out-denting a block of code.

<=Spaces======================>go, here
will get mangled by most editors. Often like this:
<=Tab=Tab=Tab=Tab=Spaces=>go, here

** Can anyone give a specification for common editors or astyle/indent to give this behaviour, or suggest a script to check where this hasn't been done?
:: Without such automation, this approach won't be used by many developers.

=== Brace Placement ===

Arguments against "disco"/compact braces:

* Make it hard to match braces visually.

:Partial counter-argument: emacsen & vim each have brace-locating commands. (Emacsen: C-M-u, C-M-n, C-M-p, C-M-d (up/next/prev/down); vim: `[ {', `] }'.)

* The brace closes a block, not an if "statement".

:However, the block is intimately related to the if/for/while in ways that a normal block is not.

=== Functions vs methods, i.e. member vs non-member functions ===

* Information-hiding principle suggests that if a function doesn't need access to private variables then it's better not to make it a member function.

** In more detail: when one wants to change some detain about a private variable, then one must look through everything that has access to that variable. This is easier if there's less code that has access to the variable, e.g. if one uses non-member functions in preference to member-functions.

* Virtual functions must of course be member functions.

* Trivial getter/setter functions seem most natural as member functions. (This is mostly a matter of style or tradition rather than technical reasons.)
** "barType getBar() const { return _bar; }" / "void setBar(barType x) { _bar = x; }" are trivial. It's not clear how much else is to be considered trivial.

* For things needing access to private variables, the requirement of the `friend' declaration for non-member functions is a cost: extra clutter in the class definition, requires updating for changes in the signature; and many of the arguments for non-member functions disappear.

* Member functions must be declared in the class definition, which tends to require more recompilation because one can't use a separate header file.

** Sometimes one can break the class into smaller, simpler classes if there are lots of member functions.

* A related issue is that it's harder (impossible) to write private specializations (same name but subclass arguments): any specialization must be declared in the class definition too, so it isn't private other than through comments.

* The shorter names typical of member functions are harder to search for.

** (Counter-argument: this is a matter of custom, there's no technical reason why one can't use long names for member functions, or even short names for non-member functions.)

** Someone has claimed that some tools do relatively well at finding the right version of a given name. Can someone give examples of such a tool (and some comment as to how widely used that tool is or can be by our developers) ?

* Pointers to member functions aren't as easily used as pointers to non-member functions. ("unwieldy", "heavy-weight".)

* Member functions can't be given static linkage.

=== <tt>static</tt> vs anonymous namespaces for file-local functions/objects ===

The current C++ standard marks this type of `<tt>static</tt>' as deprecated, meaning "Normative for the current edition of the Standard, but not guaranteed to be part of the Standard in future revisions".

(Reference: Final Draft of the C++ standard, Annex D "Compatibility features"; and §7.3.1.1 "Unnamed namespaces", ¶2.)

However, g++ up to 3.4 (and possibly later) don't give anonymous-namespace names the same advantages given to static names:

* Warning if the name isn't referenced (and hence unused).
* Optimizations when the function/object can't be used from other object files.
* Static linkage (relevant to analysis using nm).

In addition, having a <tt>static</tt> tag in the declaration itself makes it easier for the programmer to see that the name isn't referenced outside of this translation unit.

Consequently, it is recommended that we use <tt>static</tt> for names not referenced from other translation units.

If and when we encounter a compiler that rejects `static' for objects in namespace scope, we can easily replace `<tt>static</tt>' with `<tt>namespace {</tt> ... <tt>}</tt>'.

=== What to put in what header file ===

Reasons for change:
* Reduce compilation times (most important)
* Fix the mess of NR::Point, NR::Matrix etc. header files. Less confusion as to what needs to be #included, or where to look for the definition of something (especially in the cases where tags-like programs don't help, e.g. if looking for something helpful for a known task rather than having a known name).

What won't change:
* foo.h will still provide the same things it always has (unless you count things "accidentally" provided, which we hope to become less). It's just that some content may be physically moved to a file that foo.h #includes.

The issues are:

* Ease for callers (what file/s to #include). This is largely taken care of by having files that #include other header files, and in particular having the foo.h file as at present.

* "I need to change the blah declaration/definition; what file do I edit?".

* Information we want ppl to be aware of.

Definitions are handled by tags/idutils/global etc (though all of these tools have limitations in their ability to find the _right_ definition).
Declarations that are separate from the definition: [non-member] function declarations are the main case. member functions (obviously kept in same physical file as their class definition); non-member functions

Here are some types of things to be found in header files. Whatever rules you hypothesize, check that the rules cover each of these cases.

* class foo definition
* "class foo;" forward declarations
* struct foo_class (i.e. GObject "class"/vtable type)
* IS_FOO, FOO cast etc. macros
* ancilliary types (e.g. struct StopOnTrue for marshalling)
* enums
* relevant instantiations (traits etc.)
* foo_do_blah (declaration of function defined in .cpp file)
* inline function definitions
* should declaration & definition of inline functions go in different files (there are pros & cons)
* other constants, including #defines
* other macros. Where is the line between "other macro" and "inline function" and IS_FOO macros?

The physical placement of the IS_FOO etc. macros (as distinct from what header files "provide" them) isn't important: we never need to edit them, and they're relatively easy to find by either primitive tags-like programs or by grep.
* This unimportance-of-physical-location is reflected in the inconsistency of current practice, sometimes placing them with foo.h and sometimes in blah-forward.h.
* Exception to unimportance-of-physical-location: IS_FOO etc. should not be physically in the same header file as something that's "expensive" and unneeded by one or more translation units that need IS_FOO etc. ("Expensive" in same sense as `amount' defined below in `Reducing compile times'.)

The main thing for IS_FOO etc. is what header file(s) provide the macro. Thankfully, this is easy in the common case: usually any function that needs the definition of IS_FOO also needs lots of other things relevant to the foo type, so would simply #include foo.h.

Relevant properties of function declarations:

* It is common to add or remove functions, or change the arguments.

* Typically not found by tags-like programs. E.g. neither `tags' nor `TAGS' files store the location of declarations (other than the definition).

* Programmers want to know what functions (including methods, macros, inline things) are available (or rather "is there something that does blah").

** Probably doxygen or the like is the best task for this, though we'd need to make it convenient to use.

* Needed in advance of function definitions (whether in .cpp file or inline function definitions). Not needed in advance by macro definitions per se (but needed in advance of function definitions where the macro is expanded).

Inline function definitions:

* Relatively expensive in compile time for translation units that don't use that inline function definition.
* Must come after (in the translation unit) all referenced declarations. Sometimes this requires that it be outside of the class definition or in a separate file from related declarations. (E.g. if foo.h and bar.h each provide an inline function definition that requires declarations provided by the other file.)

Operator overloading:

* Can be unclear whether to associate with the type of the left operand or the type of the right operand.
* We can simplify things for users of the function by having both left.h and right.h provide it (i.e. have both left.h and right.h #include it). This suggests that it should be physically neither in left.h nor right.h (unless it's OK for left.h to pull in all of right.h or vice versa).

Reducing compile times

* For each translation unit U, reduce the amount of material that gets included by U and isn't needed by U.
** "Amount" is measured by cost: how often that material changes (causing a recompile), and how expensive it is to compile (e.g. inline function definitions).

* In what circumstances does a translation unit include things that it doesn't need?
** Inline function definitions.
** Needs a function declaration but doesn't need the type definition.
*** A special [non-] case of this is needing a member function declaration. Member function declarations can't be separated from their class definition. See also `methods vs functions' above.
** Suppose that struct Foo has a `Bar _bar' member. The translation unit may need to create Foo objects (and thus need the type definition of Bar to know its size), but not need to access _bar (so not needing anything from bar.h other than the type definition of Bar).
*** This is very common. Common examples of Bar: SPShape, NR::Point/NR::Matrix.
** Needs some function declarations but not others.
** Needs some type forward declarations but not others.
** Comments are never needed for compilation.
** Definition of a marshaller is needed only by emitters. However, it's difficult to separate the marshaller from the signal, and difficult to separate the signal from the definition of the containing type (SPDesktop, SPItem).
** Including the definition of a type when its declaration would suffice.
** Copy&paste of #include lines.

* Ways of reducing the need for type definitions:
** Store just a pointer instead of the whole type.
** Provide a wrapper function (not inlined) for `new Foo'.

CSS Support

2005-03-08T00:38:34Z

PeterMoulder: * Draw attention to "Duplicating libcroco code" on inkscape-devel

=== Hack: Convert to style-less SVG ===
A short-term solution (hack) for style support would be an input filter that converts stylesheet-using documents to non-stylesheet-using documents. cssanno.c (http://lists.w3.org/Archives/Public/www-archive/2004Jun/att-0001/cssanno.c or see google) does most of the work for this (for a generic XML document); the remainder of the work is to feed it a stylesheet by parsing the SVG document looking for <tt><style></tt> elements and fetching external stylesheets, and to change the outputted namespace from css: to svg:.

Ideally change <tt>add_single_property</tt> to ignore properties other than SVG ones. I.e. add an array of names of SVG properties, and check whether <tt>name</tt> is in this list. A linear search should be fine, I'd guess, and it's not too difficult to change it to a hash table or use a pre-coded binary search routine (whether glib or STL).

=== libcroco ===

Peter Moulder is looking at using libcroco from Inkscape.

There are a number of aspects of the work, some of which Peter will need help with:

* Modify libcroco selection stuff (cr-sel-eng.c) to allow us to use <tt>SPRepr</tt> rather than maintaining a libxml copy of the entire tree.
: Done (not checked in). The implementation is to provide a generic interface to nodes in a struct of function pointers (with names influenced by DOM).
: If we wish to, we could keep a copy of this modified cr-sel-eng.c in Inkscape, so that we can use current libcroco.
: Message posted to inkscape-devel of subject "Duplicating libcroco code in Inkscape tree" seeking concensus on how much of libcroco to put in inkscape source tree; once this has been decided, Peter will modify his local sources accordingly and then check in the current state of most or all files (so long as this doesn't break anything). So reply to that message if you're keen to have the current work checked in as soon as possible.

* Parse <tt><style></tt> element content, gathering all rules (across possibly many <tt><style></tt> elements) into a single stylesheet.
: Progress so far: have a skeletal implementation of sp-style-elem.{cpp,h} that doesn't actually parse the CSS. (Not checked in.)

* Ensure that this single stylesheet is updated whenever any of the <tt><style></tt> elements change (or are deleted or created etc.).

* Similarly, ensure that the picture is refreshed when the stylesheet is changed.

* Convert the simple user agent style sheet given at http://www.w3.org/TR/SVG11/styling.html#UAStyleSheet to libcroco structures (perhaps by passing strings to libcroco parsing functions) and store in <tt>desktop->style_cascade</tt>.

* Modify style.cpp to query the stylesheet. (Done but not checked in.)

* There may be some work needed for "shorthand properties", e.g. `<tt>marker</tt>' is shorthand for modifying <tt>marker-start</tt>, <tt>marker-mid</tt> and <tt>marker-end</tt> properties (http://www.w3.org/TR/SVG11/painting.html#MarkerProperty). A non-SVG CSS example is `<tt>margin</tt>'.

==== Why can't we use the existing libxml interface to cr-sel-eng.c ? ====

Some CSS selectors (http://www.w3.org/TR/REC-CSS2/selector.html) can express "is preceded by X" or "is a descendent of X" (where X can itself be similarly constrained recursively), so we'd pretty much need to maintain the entire document in libxml form if we want to use libcroco for CSS selectors.

Suppose we want to find the style of node N. We pass libcroco a stylesheet and ask it what rules apply to N.
If the stylesheet says "nodes that are preceded by a node that is preceded by a node that's a descendent of (... etc. ...) have red stroking" then libcroco needs to be able to navigate through the tree.
So we can't pass libcroco just a libxml version of node N, we need to fill in its parent and sibling links, providing a libxml node for a significant proportion of all nodes in the tree.
(Short of using hardware watchpoints to check access to the sibling/parent links and supply them lazily.)

ReleaseAnnounce041

2005-02-09T11:37:45Z

PeterMoulder: * Try not to give the false impression that we've fixed all known crashes.

subject line for email: Announcing Inkscape 0.41 Release . www.inkscape.org

= Announcing Inkscape 0.41 Release . www.inkscape.org =

February 8, 2005 UTC — The Inkscape community announced the release 0.41 of Inkscape, "A Cross-platform Open Source Vector Graphics (SVG) Drawing Tool" today. Inkscape continues to develop at a rapid pace by focusing on bug fixes, stability, color bitmap-to-vector tracing capabilities, Internationalization, pattern tiling, and translation refinements.

Inkscape developers fixed many bugs and worked on overall stability for the 0.41 release. This significantly strengthened Inkscape on Windows and overall improved Internationalization in the program. Inkscape developer Bryce Harrington stated that "we owe deep thanks to the many users who have worked patiently with us to report the problems and validate these fixes." Several serious crashes, memory leaks and mis-features are now corrected and certain areas are noticeably snappier thanks to user submitted bug reports. Please see Inkscape's Known Issues section for noted problems that have work arounds and were not fixed for this release.

In addition to stability improvements, developers added several new features. First, Inkscape 0.41 builds on the black and white tracing functionality introduced in release 0.40. This functionality converts a bitmap (raster) image into an editable vector graphic. Now, Inkscape converts color and grayscale images with ease and the results are quite astounding. Second, is the addition of a new clone tiler facility which creates patterns, tesselations, and other sorts of geometric tiling arrangements with an easy-to-use dialog.

In addition, user requests and comments stimulated a number of improvements to units handling, extensions, the Invert Selection command, layers selector, and icon theming. Translations have
also received an amazing amount of attention this release, including several new translations of the ever-growing tutorials. All this and more is available in explicit detail in the 0.41 Release Notes, accessible at www.inkscape.org.

Inkscape 0.41 avoided the addition of new dependencies and developers pushed back implementing ambitious new features originally planned in order to make 0.41 especially stable. The only dependency change is a minor version update for the Boehm garbage collector, libgc, which increased to version 6.4 due to freezes that occurred in some circumstances on Windows and Linux.

However, for the upcoming Inkscape 0.42 release, the developers are going to make aggressive changes that have been worked on experimentally behind the scenes for several months. These changes are going to destabilize the codebase considerably during this development cycle; it may be a while before the next release. The first of these changes is a complete re-implementation of the graphical user interface using Gtkmm. The second is the incorporation of a new Document Object Model (DOM) which will provide a core that the developers can finally build a scripting system on. Both of these features are major requests and have been commented on heavily by reviewers.

As always, Inkscape is open to contributors and developers of all levels of experience. The Inkscape development community encourages people to join the development team by submitting bug reports, making feature requests and by contributing code. For more information, visit www.inkscape.org.

Inkscape. Draw Freely.

Download Linux, Windows, and Mac OSX packages:

http://sourceforge.net/project/showfiles.php?group_id=93438

For many more details, see the Release Notes for 0.41:

http://www.inkscape.org/cgi-bin/wiki.pl?ReleaseNotes041

Community submitted screenshots:

http://www.inkscape.org/screenshots/

OpenDocument SVG Correspondence

2005-02-01T04:48:06Z

PeterMoulder: * 9.2.15: subsection `View Box'

Section 9.2 (pp275-) of the OpenDocument specification (available at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office) is the most obviously related to SVG.

=== 9.2 Drawing Shapes ===
==== 9.2.1 Rectangle ====

draw:rect element: svg:rect (http://www.w3.org/TR/SVG11/shapes.html#RectElement)

draw:corner-radius attribute: rx. (OpenDocument has no equivalent of specifying both rx and ry, so we may forbid specifying ry in OpenDocument SVG fragments.)

==== 9.2.2 Line ====

draw:line element: svg:line (http://www.w3.org/TR/SVG11/shapes.html#LineElement)

==== 9.2.3 Polyline ====

draw:polyline element: svg:polyline (http://www.w3.org/TR/SVG11/shapes.html#PolylineElement)

svg:points attribute: points. The OpenDocument specification is (at first glance at least) ambiguous as to whether coordinates can contain units, whereas the SVG spec disallows units.

==== 9.2.4 Polygon ====

draw:polygon element: svg:polygon

==== 9.2.5 Regular Polygon ====

draw:regular-polygon element: svg:path supplemented by draw:blah attributes used as hints to editing programs (similar to the star tool in inkscape).

(Note that svg:polygon doesn't in general suffice, because of the draw:sharpness attribute.)

Consider hinting only what cannot be inferred from the path data, to reduce problems from conflicts between the path data and hints.

==== 9.2.6 Path ====

draw:path element: svg:path.

svg:d attribute: d. (Though note the OpenDocument comment "Some implementations may only supports a subset of the SVG path specification, for instance no mixtures of open and closed curves for one shape, or no elliptical arc command.")

==== 9.2.7 Circle ====

draw:circle element: can use svg:circle if draw:kind="full"; all kinds can be represented with svg:path. (http://www.w3.org/TR/SVG11/paths.html#PathDataEllipticalArcCommands for the curved part).

Note that in OpenDocument, its svg:cx and svg:cy attributes may be inferred from the position & size attributes (see section 9.2.15 below), whereas in SVG 1.1 cx and cy each default to 0 if unspecified.

In OpenDocument, absence of svg:r attribute means that the radius is to be calculated from the size attribute[*1], whereas SVG 1.1 requires an r attribute.

[*1]: The specification actually says calculated from both size and position attributes, though I think position is irrelevant, whereas I'd guess that the svg:start-angle and svg:end-angle attributes are relevant.
The OpenDocument specification gives no further information about how to calculate radius.

For converting between OpenDocument's start-angle,end-angle format to SVG's endpoint representation, see http://www.w3.org/TR/SVG11/implnote.html#ArcImplementationNotes, principally sections [http://www.w3.org/TR/SVG11/implnote.html#ArcConversionCenterToEndpoint F.6.4] and [http://www.w3.org/TR/SVG11/implnote.html#ArcConversionEndpointToCenter F.6.5].

==== 9.2.8 Ellipse ====

draw:ellipse element: Can use svg:ellipse if draw:kind="full"; the more general case is as for draw:circle (see above) except for its svg:rx and svg:ry attributes instead of svg:r.

OpenDocument allows svg:rx and svg:ry to be inferred from position & size attributes, whereas the rx and ry attributes of svg:ellipse are required.

(The OpenDocument spec has a typo saying svg:rx twice instead of "svg:rx and svg:ry".)

==== 9.2.9 Connector ====

draw:connector element: svg:path supplemented with hints for editor programs.

The OpenDocument spec doesn't seem very specific about how draw:connector elements are rendered. I didn't understand its "escapes" terminology.

draw:{start,end}-{shape,glue-point} may be retained as editing hints. (They should not affect positions of connectors, which would be fully specified in the path's d attribute. This allows plain (OpenDocument-unaware) SVG renderers to render the document correctly.)

draw:line-skew attribute: fully encoded in the path's d attribute. (The behaviour of draw:line-skew isn't fully specified in the OpenDocument specification.)

==== 9.2.10 Caption ====

draw:caption: svg:g.

Editing hints that may be useful:
* Make the children of the group editable without explicitly entering/opening the group: allow typing directly into the text element, and allow changing the radius of the caption box.
* Use connector facility to manage the lines between the "caption point" and the text & frame.

==== 9.2.13 Page Thumbnail ====

draw:page-thumbnail element: svg:use (http://www.w3.org/TR/SVG11/struct.html#UseElement).

draw:page-number attribute: appears to be subsumed by svg:use's xlink:href attribute.

==== 9.2.14 Grouping ====

draw:g element: svg:g

svg:y attribute: Relevant to how the draw:g is embedded inside for example textual data. This information would go on the embedding element.

If the intent of the svg:y attribute is to tie the positioning to the picture instead of the embedder (e.g. if the picture is glyph-like, in which the "baseline" is an inherent property of the glyph), then this can be achieved either by making the reference point the (0,0) of the <svg:svg> element, or perhaps using the svg:view element (http://www.w3.org/TR/SVG11/linking.html#ViewElement).

==== 9.2.15 Common Drawing Shape Attributes ====

===== Name =====

The OpenDocument specification doesn't mention the interpretation or use of its draw:name attribute.
Probably it's a human-readable name used only in dialog boxes of editors for OpenDocument documents.
If so, then it can stay as draw:name, and can safely be ignored by most SVG user agents.

===== Position =====

The OpenDocument standard allows specifying svg:x and svg:y attributes (though in some cases doesn't mention their interpretation; probably ignored); whereas the SVG 1.1 spec allows x and y attributes on only a few elements (typically those that don't otherwise specify their position).

===== Size =====

The OpenDocument standard allows specifying a svg:width and/or svg:height attribute for many shapes, typically saying that these attributes "may" be ignored. The SVG 1.1 standard does not allow specifying width or height attributes other than for rect, image, foreignObject, and a few other things (see http://www.w3.org/TR/SVG11/attindex.html).

===== Transformation =====

draw:transform attribute: transform.

SVG 1.1 says that individual transforms are separated by "whitespace and/or a comma" whereas OpenDocument spec says they are separated by "a white space and/or a comma", which may mean that OpenDocument format allows only one whitespace character, or possibly only a literal space character (ASCII 0x20); though this may simply be a typing mistake in the OpenDocument spec.

Both specifications say [a minor rearrangement of] "The available types of transform definitions <b>include</b>" (emphasis not in original), which might be interpreted as indicating an incomplete list of possibilities. The SVG 1.1 spec uses "includes" elsewhere in contexts that suggest it is to be interpreted as meaning "consists of" (i.e. a complete list).

The set of allowable transforms (and their syntax) is the same, with the following exception:

rotate in OpenDocument does not allow the cx,cy arguments (which are optional in SVG1.1). The behaviour in SVG 1.1 in their absence is identical to the OpenDocument behaviour, so the revised OpenDocument format could forbid them.

===== View Box =====

svg:viewBox attribute: N.B. this differs markedly in semantics from SVG's viewBox attribute, despite sharing the same syntax. In OpenDocument, svg:viewBox is required (I believe) on the draw:path element and on elements that allow an svg:points attribute (draw:polyline, draw:polygon, and some similar things outside of section 9.2).

Further, the OpenDocument spec says "Some implementations may ignore the view box attribute. The implied coordinate system then has its origin at the left, top corner of the shape, without any scaling relative to the shape."

The OpenDocument spec doesn't say much about the interpretation of the svg:viewBox attribute: in particular, it doesn't specify how to convert the svg:points or svg:d data into the coordinate system of the corresponding polyline/path element. Possibly the corners of the specified svg:viewBox are to be mapped to the size & position attributes of the corresponding shape.

In SVG 1.1, the viewBox attribute (http://www.w3.org/TR/SVG11/coords.html#ViewBoxAttribute) isn't allowed on any "normal shapes", but on "container"-like elements (like svg, symbol, image, foreignObject; not g) and view.

When translating OpenDocument svg:viewBox use to SVG, one could wrap the path/polyline with a new svg:svg element with a viewBox attribute; alternatively, one might just apply the transformation to the point list (if the transformation is known in advance; this may not be the case when mixing units).

OpenDocument SVG Correspondence

2005-02-01T04:07:47Z

PeterMoulder: * 9.2.15: subsection `Transformation'

OpenDocument SVG Correspondence

2005-02-01T03:51:47Z

PeterMoulder: * 9.2.14 Grouping

OpenDocument SVG Correspondence

2005-02-01T03:43:17Z

PeterMoulder: * 9.2.13 Page Thumbnail

OpenDocument SVG Correspondence

2005-02-01T03:38:12Z

PeterMoulder: * 9.2.10 Caption

OpenDocument SVG Correspondence

2005-02-01T03:17:58Z

PeterMoulder: * 9.2.9 Connector

OpenDocument SVG Correspondence

2005-02-01T02:05:20Z

PeterMoulder: * 9.8 ellipse

OpenDocument SVG Correspondence

2005-02-01T01:58:19Z

PeterMoulder: * Circle

OpenDocument SVG Correspondence

2005-02-01T01:36:38Z

PeterMoulder: * Path

OpenDocument SVG Correspondence

2005-02-01T01:30:48Z

PeterMoulder: * polygons. Some work on Common Drawing Shape Attributes

OpenDocument SVG Correspondence

2005-02-01T01:16:06Z

PeterMoulder: * Comment on width,height,x,y attributes

OpenDocument SVG Correspondence

2005-02-01T01:05:42Z

PeterMoulder: * Line, Polyline

OpenDocument SVG Correspondence

2005-02-01T00:57:11Z

PeterMoulder: * Comment on ry

OpenDocument SVG Correspondence

2005-02-01T00:54:18Z

PeterMoulder: * 9.2.1 correspondence

OpenDocument Proposal

2005-02-01T00:24:28Z

PeterMoulder: * archives of mailing list discussion

OpenDocument is a proposed standard office-type document format for use in the EU etc.; see http://www.groklaw.net/article.php?story=20050130002908154 for more detail.

Currently it has its own custom format for graphics elements, similar to OpenOffice.org's Draw format, and also somewhat similar to SVG in some areas.

Clearly it would be good both for SVG, Inkscape, and the success of the OpenDocument standard, if OpenDocument were to use SVG to the extent possible, such that any SVG-compliant renderer could render the <svg> parts of the document.

(See also the inkscape-devel mailing list, subject "filter for inkscape and OpenDocument".)

The current OpenDocument specification is available at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office .

To send comments, either click the "Send a comment" button on the above-referenced web-page, or use the office-comment@lists.oasis-open.org mailing list. Subscribe by sending the word "subscribe" in the body of mail to office-comment-request@lists.oasis-open.org.

Archives are at http://lists.oasis-open.org/archives/office-comments/ ; similarly, archives of discussions between committee members are at http://lists.oasis-open.org/archives/office/ .

From Daniel Carrera:

<blockquote>
It is very important to get representation in the OASIS TC from multiple
interested parties. The goal is to make a format acceptable to everyone,
and that can only be done if people participate in the discussion.

Also, right now they wer working on the next version of the format. The
one that'll meet all of the EU's requirements. And they are in the
official "request for public comentary" period until Friday. So, the best
time to raise a concern is right now. Send them a comment.
</blockquote>

No-one has yet done so; please edit this wiki page to indicate your progress in seeing/joining this discussion.

Something that may be helpful in getting greater SVG interoperability in the OpenDocument standard is to document what bits of the OpenDocument specification correspond to & differ from SVG. For example, this helps in changing any existing implementations of that part of the standard to use a more SVG-friendly replacement. See [[OpenDocument SVG correspondence]].

OpenDocument Proposal

2005-02-01T00:19:56Z

PeterMoulder: * Refer to new page OpenDocument SVG correspondence.

OpenDocument is a proposed standard office-type document format for use in the EU etc.; see http://www.groklaw.net/article.php?story=20050130002908154 for more detail.

Currently it has its own custom format for graphics elements, similar to OpenOffice.org's Draw format, and also somewhat similar to SVG in some areas.

Clearly it would be good both for SVG, Inkscape, and the success of the OpenDocument standard, if OpenDocument were to use SVG to the extent possible, such that any SVG-compliant renderer could render the <svg> parts of the document.

(See also the inkscape-devel mailing list, subject "filter for inkscape and OpenDocument".)

The current OpenDocument specification is available at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office .

The discussion list for committee members is office@lists.oasis-open.org, though I don't yet know how to see archives of this list.

To send comments, either click the "Send a comment" button on the above-referenced web-page, or use the office-comment@lists.oasis-open.org mailing list. Subscribe by sending the word "subscribe" in the body of mail to office-comment-request@lists.oasis-open.org.

From Daniel Carrera:

<blockquote>
It is very important to get representation in the OASIS TC from multiple
interested parties. The goal is to make a format acceptable to everyone,
and that can only be done if people participate in the discussion.

Also, right now they wer working on the next version of the format. The
one that'll meet all of the EU's requirements. And they are in the
official "request for public comentary" period until Friday. So, the best
time to raise a concern is right now. Send them a comment.
</blockquote>

No-one has yet done so; please edit this wiki page to indicate your progress in seeing/joining this discussion.

Something that may be helpful in getting greater SVG interoperability in the OpenDocument standard is to document what bits of the OpenDocument specification correspond to & differ from SVG. For example, this helps in changing any existing implementations of that part of the standard to use a more SVG-friendly replacement. See [[OpenDocument SVG correspondence]].

OpenDocument Proposal

2005-01-31T23:53:06Z

PeterMoulder: * Supply info on how to subscribe

OpenDocument is a proposed standard office-type document format for use in the EU etc.; see http://www.groklaw.net/article.php?story=20050130002908154 for more detail.

Currently it has its own custom format for graphics elements, similar to OpenOffice.org's Draw format, and also somewhat similar to SVG in some areas.

Clearly it would be good both for SVG, Inkscape, and the success of the OpenDocument standard, if OpenDocument were to use SVG to the extent possible, such that any SVG-compliant renderer could render the <svg> parts of the document.

(See also the inkscape-devel mailing list, subject "filter for inkscape and OpenDocument".)

The current OpenDocument specification is available at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office .

The discussion list for committee members is office@lists.oasis-open.org, though I don't yet know how to see archives of this list.

To send comments, either click the "Send a comment" button on the above-referenced web-page, or use the office-comment@lists.oasis-open.org mailing list. Subscribe by sending the word "subscribe" in the body of mail to office-comment-request@lists.oasis-open.org.

From Daniel Carrera:

<blockquote>
It is very important to get representation in the OASIS TC from multiple
interested parties. The goal is to make a format acceptable to everyone,
and that can only be done if people participate in the discussion.

Also, right now they wer working on the next version of the format. The
one that'll meet all of the EU's requirements. And they are in the
official "request for public comentary" period until Friday. So, the best
time to raise a concern is right now. Send them a comment.
</blockquote>

OpenDocument Proposal

2005-01-31T23:43:38Z

PeterMoulder: * First text, motivating work on this.

OpenDocument is a proposed standard office-type document format; see http://www.groklaw.net/article.php?story=20050130002908154 for its proposed use etc.

Currently it has its own custom format for graphics elements, similar to OpenOffice.org's Draw format, and also somewhat similar to SVG in some areas.

Clearly it would be good both for SVG, Inkscape, and the success of the OpenDocument standard, if OpenDocument were to use SVG to the extent possible, such that any SVG-compliant renderer could render the <svg> parts of the document.

The current OpenDocument specification is available at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office .

At the end of its first page, you can see how to submit comments. (See also the inkscape-devel mailing list, subject "filter for inkscape and OpenDocument".)

From Daniel Carrera:

<blockquote>
You can leave a comment (click on "Send a comment"), join the TC, or
simply just join their mailing list and participate in the discussion. The
list is office@lists.oasis-open.org but I can't figure out how to
subscribe. I know you don't have to be a TC member to participate, as I
know of other people who aren't members and still contribute there.

It is very important to get representation in the OASIS TC from multiple
interested parties. The goal is to make a format acceptable to everyone,
and that can only be done if people participate in the discussion.

Also, right now they wer working on the next version of the format. The
one that'll meet all of the EU's requirements. And they are in the
official "request for public comentary" period until Friday. So, the best
time to raise a concern is right now. Send them a comment.
</blockquote>

Inkscape

2005-01-31T23:33:04Z

PeterMoulder: * Add OpenDocument proposal link

== Inkscape Wiki ==
This is a freeform area for Inkscape development and discussion.
Curious about WikiSyntax?

<table borfdhdder="0"><tr><td valign="top">
=== About Inkscape ===
* [http://www.inkscape.org/ Inkscape Homepage]
* OtherProjects
* ArticlesAndPresentations
* TestimonialComments

=== User Documentation ===
* ReleaseNotes for 0.41 and past
* PressRelease for 0.41 and past
* ArticleIntroducingInkscape0_40
* InkscapeTerminology
* UserManual
* TutorialIdeas

=== Project Documentation ===
* ProjectInfo
* CreatingDists: how to build packages
* WebsiteEditing
* UpdatingTrackerItems
* ScribusInteroperability

=== Developer Documentation ===
* DeveloperManual
* CompilingInkscape
* WorkingWithCVS
* TranslationInformation
* HandlingPreferences: creating and using preference values
* AddSPObject: how to add a new SPObject type
* ReprListeners: responding to XML doc changes
* DebuggingTips: random tips to help debug problems
* [[http://livarot.sourceforge.net/ Livarot]]: for boolean ops

</td><td valign="top">
=== User Interface Discussion ===
* AccessibleGraphics
* ObjectManager
* DialogsReorganization
* ModalInterfaces
* TextUsability: text tool /dialog dialog
* KeyboardShortcutsToDo
** KeyboardProfiles: how you can help
* StatusbarAPI
* [[Animation-(Timeline)]]

=== Development Discussion ===
* URGENT: [[OpenDocument proposal]] Please help work on this before Feb 4!
* [[Roadmap]]: the main todo list
* NewFeatureProposals
* ExtensionArchitectureProposals
* [[Coding Style|Coding Style Discussion]]
* FileTypes
* [[Icons]] (Application + Interface)
* [[ApplicationIcons]] ( more application + interface )
* InkscapeColor
* [[PrintingSubsystem]]
* [[SVG Competitors Plan]] - M$ WVG vs SVG, etc
* [[SVG Tiny Compliance]]
* [[CSS Support]]
* OpenVG Standard (draft)

=== Rearchitecture Discussion ===
* SubsystemRearchitecture
* CPlusPlus: Convert to C++
* [[Pangoification]]: replace font rendering subsystem
* GtkMMification: replace C boilerplate with gtkmm objects
* PathRepresentation

=== [[Galleries]] ===

</td></tr></table>

----
* WikiAttic: pages that are no longer relevant but kept for historical value

Sketch

2005-01-26T09:48:15Z

PeterMoulder: * Add section on tweening/blending

Please post links to screenshots and/or insights of this vector app. We must learn from others.

=== Notable features ===

* About the only scriptable free-software vector graphics program.
* Bézier curves, rectangles and ellipses can be used as guides.
* Text along path, with choice between rotation or vertical skew of glyphs. (Inkscape has SVG text-on-path, which I think only allows rotation rather than skew.) (However, I think someone was saying that Inkscape allowed better editing of the path or text afterwards.)
* Can blend between paths (morphing).
* Written mainly in Python.
* "Conical gradients" as well as the linear & radial gradients supported by SVG/Inkscape.
* Claims to support masking; I haven't looked at its interface. (I believe Inkscape honours masking/clipping directives in SVG files, but has no user interface for this unless you count the boolean operations.)

=== Layers ===

[http://www.nongnu.org/skencil/Images/tiger.png screenshot showing layer dialog] has four toggle buttons for each layer: screen visibility; printing visibility (probably including visibility in exported bitmaps); lockedness; and a "show outline only" option. Each layer can have its own colour used when show-out-line-only is on.

There is a separate layer for guide objects/lines. The layer's show-outline-only option is always on, the print option is always off, while the visibility and lockedness options remain togglable.

The grid has its own layer too, unselectable, but useful as a consistent interface for controlling its visibility and the colour of the grid dots. (It uses dots rather than lines for its grid representation.) The grid layer is always locked an non-printing, while visibility and colour remain settable.

Having a separate grid layer may help in Inkscape if we use njh's suggestion for having canvas controls to edit the grid. This grid prototype is in experimental/grid-proto/

=== Styles ===

Skencil has a reasonable interface for named styles. Individual objects can override properties assigned by styles, and there is an "Update style" command to copy those changes back to the style.

There are some gaps in the interface: when creating a style, one can control whether the style controls line thickness, but I didn't see a way of changing that after creation. There seem to be some inconsistencies about whether an object can belong to more than one style or not.

Skencil style control certainly isn't as sophisticated as that offered by SVG/CSS, but we may borrow some things from it.

(Inkscape doesn't support named styles, unless you count inheriting styles from parents, such as layer membership.)

=== Tweening / Blending ===

[Consider moving/copying this to its own wiki page discussing how to implement tweening in inkscape.]

(N.B. This review of tweening is based on sketch 0.6, I haven't checked newer versions.)

Good points:
* "Dynamic": the mid-states are recomputed if you edit either of the end points. (See also bad points & limitations below.)

* Some degree of specialisation when begin & end objects have the same type. E.g. if the end objects are arcs/ellipses, then the tween states are arcs with interpolated start/end angles.
: I'd wondered whether it would be unintuitive/bad that tweening between some pairs of objects would give different tween states than if the objects had been converted to path, but I think skencil's behaviour is good: users can always explicitly convert to path if they wish.

Bad points & limitations:

* Little control over the interpolation:
** Can only specify the end points, can't specify one's own mid states except by doing n-1 tween operations (over each adjacent pair of one's objects), which would have to be plain linear (staight line segment) interpolation rather than curving.
:: What would be really cool would be to allow editing the tween states it gives to create new custom mid states (and having all the non-customized tween states adapt to the new hint).
** Can't choose whether to interpolate positions or angles: e.g. if interpolating between two (analog) clock faces showing 12:00 and 12:25, then should all the tween states have the same length minute hand (tracing an arc around the clock), or should the end-point of the hand trace a straight line, thus shortening the minute hand towards the centre?
:: (You may notice that angular interpolation is ambiguous in that there's a short and a long way, and two equal ways if the angle is 180 degrees. The same choice exists with SVG markers when choosing the "half way" angle. The resolution in each case is to take the shorter path, choosing arbitrarily in the 180 degree case. In the tweening case, the user can force the long route by specifying an in-between state.)
** Similarly, can't control colour interpolation. (SVG allows specifying colour interpolation for gradients & alpha compositing (http://www.w3.org/TR/SVG11/painting.html#ColorInterpolationProperties), though Inkscape doesn't currently implement this choice. Interpolating in HSV space would be useful for tweening -- not to mention animation and gradients.
* Tween states between a rectangle and an ellipse were unexpected: e.g. they aren't symmetrical (except 180-degree rotational symmetry), and aren't convex. I haven't looked into why; maybe just because the corresponding convert-to-path versions start & end in different places. If that is the only reason, then it can probably be fixed just by specializing the tweening for rectangle--ellipse pairs to use a different conversion to path than normal.
* I couldn't see how to "detach" the tween states (e.g. to edit them individually), other than by converting the whole lot to curves.
* Limitation to dynamicness: one can't change the number of mid-states after creating them. (Presumably can easily be fixed given that the tween states can't be edited in skencil.)
* Similarly, one can't edit the proportion parameter of an individual tween state (like the stop proportion value in a gradient stop, a number from 0 to 1 indicating how similar to the begin or end state this tween state should be).

If implementing in Inkscape, then note that SVG/SMIL animation involves a similar operation to tweening.

=== Ellipses/Arcs: node editing ===

Like Inkscape, Skencil uses one tool for circles, ellipses and arcs.
It uses the opposite convention for whether to show radial spokes (pacman, pie slice) or whether to show just the arc (with chord filling if filled): if the node tool is dragged outside of the corresponding ellipse, then it's a chord/pure arc in Skencil, whereas inside means pie slice / pacman.

For unfilled shapes, I think Skencil's choice is better (partly because pure arcs are more common than pie slices when unfilled, so it's good to assign it the alternative that gives more control.

For filled shapes, the argument of more-common-deserves-outside goes in Inkscape's favour.

When editing the placement of the radial spokes, it's slightly more intuitive putting the mouse inside the ellipse; though this is a minor argument.

=== Scriptability ===

Can we use Inkscape plugins to access any sketch features? Its web page says "many parts of Skencil can be used as a library (and are used by Skencil that way)".

=== Areas where Inkscape is better to use than Skencil ===

* Transparence in gradients. (In fact skencil may not yet have transparence at all.)
* Better support for patterns.
* Better SVG support, as one would expect. (SVG is a foreign format for Skencil.)
* Skencil stable version 0.6.x uses tk interface. (Development version 0.7.x uses gtk.)
* Kerning (including vertical kerning, useful with/instead of text-on-path).
* Text-in-shape (textFlow); though this isn't yet well-supported in Inkscape.
* Boolean operations (combining & breaking apart shapes).
* Clones (dynamically-updated copies)
* I think skencil gradients may have only start & end stops, whereas inkscape allows arbitrarily many mid stops.
* Inkscape has a few more exotic/weird tools (calligraphy pen, stars, spirals).

=== Screenshots ===

[http://www.skencil.org/screenshots.html Official Screenshots]

=== Links ===

[http://www.skencil.org/ official site]

=== License ===

LGPL

CSS Support

2005-01-17T02:27:55Z

PeterMoulder: * more info on user agent style sheet

=== Hack: Convert to style-less SVG ===
A short-term solution (hack) for style support would be an input filter that converts stylesheet-using documents to non-stylesheet-using documents. cssanno.c (http://lists.w3.org/Archives/Public/www-archive/2004Jun/att-0001/cssanno.c or see google) does most of the work for this (for a generic XML document); the remainder of the work is to feed it a stylesheet by parsing the SVG document looking for <tt><style></tt> elements and fetching external stylesheets, and to change the outputted namespace from css: to svg:.

Ideally change <tt>add_single_property</tt> to ignore properties other than SVG ones. I.e. add an array of names of SVG properties, and check whether <tt>name</tt> is in this list. A linear search should be fine, I'd guess, and it's not too difficult to change it to a hash table or use a pre-coded binary search routine (whether glib or STL).

=== libcroco ===

Peter Moulder is looking at using libcroco from Inkscape.

There are a number of aspects of the work, some of which Peter will need help with:

* Modify libcroco selection stuff (cr-sel-eng.c) to allow us to use <tt>SPRepr</tt> rather than maintaining a libxml copy of the entire tree.
: Partly done (not checked in). The implementation is to provide a generic interface to nodes in a struct of function pointers (with names influenced by DOM).
: If we wish to, we could keep a copy of this modified cr-sel-eng.c in Inkscape, so that we can use current libcroco.

* Parse <tt><style></tt> element content, gathering all rules (across possibly many <tt><style></tt> elements) into a single stylesheet.
: Progress so far: have an initial implementation of sp-style-elem.{cpp,h}. (Not checked in.)

* Ensure that this single stylesheet is updated whenever any of the <tt><style></tt> elements change (or are deleted or created etc.).

* Similarly, ensure that the picture is refreshed when the stylesheet is changed.

* Convert the simple user agent style sheet given at http://www.w3.org/TR/SVG11/styling.html#UAStyleSheet to libcroco structures (perhaps by passing strings to libcroco parsing functions) and store in <tt>desktop->style_cascade</tt>.

* Modify style.cpp to query the stylesheet. (Done but not checked in.)

* There may be some work needed for "shorthand properties", e.g. `<tt>marker</tt>' is shorthand for modifying <tt>marker-start</tt>, <tt>marker-mid</tt> and <tt>marker-end</tt> properties (http://www.w3.org/TR/SVG11/painting.html#MarkerProperty). A non-SVG CSS example is `<tt>margin</tt>'.

==== Why can't we use the existing libxml interface to cr-sel-eng.c ? ====

Some CSS selectors (http://www.w3.org/TR/REC-CSS2/selector.html) can express "is preceded by X" or "is a descendent of X" (where X can itself be similarly constrained recursively), so we'd pretty much need to maintain the entire document in libxml form if we want to use libcroco for CSS selectors.

Suppose we want to find the style of node N. We pass libcroco a stylesheet and ask it what rules apply to N.
If the stylesheet says "nodes that are preceded by a node that is preceded by a node that's a descendent of (... etc. ...) have red stroking" then libcroco needs to be able to navigate through the tree.
So we can't pass libcroco just a libxml version of node N, we need to fill in its parent and sibling links, providing a libxml node for a significant proportion of all nodes in the tree.
(Short of using hardware watchpoints to check access to the sibling/parent links and supply them lazily.)

CSS Support

2005-01-17T02:25:02Z

PeterMoulder: * typographical

=== Hack: Convert to style-less SVG ===
A short-term solution (hack) for style support would be an input filter that converts stylesheet-using documents to non-stylesheet-using documents. cssanno.c (http://lists.w3.org/Archives/Public/www-archive/2004Jun/att-0001/cssanno.c or see google) does most of the work for this (for a generic XML document); the remainder of the work is to feed it a stylesheet by parsing the SVG document looking for <tt><style></tt> elements and fetching external stylesheets, and to change the outputted namespace from css: to svg:.

Ideally change <tt>add_single_property</tt> to ignore properties other than SVG ones. I.e. add an array of names of SVG properties, and check whether <tt>name</tt> is in this list. A linear search should be fine, I'd guess, and it's not too difficult to change it to a hash table or use a pre-coded binary search routine (whether glib or STL).

=== libcroco ===

Peter Moulder is looking at using libcroco from Inkscape.

There are a number of aspects of the work, some of which Peter will need help with:

* Modify libcroco selection stuff (cr-sel-eng.c) to allow us to use <tt>SPRepr</tt> rather than maintaining a libxml copy of the entire tree.
: Partly done (not checked in). The implementation is to provide a generic interface to nodes in a struct of function pointers (with names influenced by DOM).
: If we wish to, we could keep a copy of this modified cr-sel-eng.c in Inkscape, so that we can use current libcroco.

* Parse <tt><style></tt> element content, gathering all rules (across possibly many <tt><style></tt> elements) into a single stylesheet.
: Progress so far: have an initial implementation of sp-style-elem.{cpp,h}. (Not checked in.)

* Ensure that this single stylesheet is updated whenever any of the <tt><style></tt> elements change (or are deleted or created etc.).

* Similarly, ensure that the picture is refreshed when the stylesheet is changed.

* Create a user agent style sheet as required by http://www.w3.org/TR/SVG11/styling.html#UAStyleSheet

* Modify style.cpp to query the stylesheet. (Done but not checked in.)

* There may be some work needed for "shorthand properties", e.g. `<tt>marker</tt>' is shorthand for modifying <tt>marker-start</tt>, <tt>marker-mid</tt> and <tt>marker-end</tt> properties (http://www.w3.org/TR/SVG11/painting.html#MarkerProperty). A non-SVG CSS example is `<tt>margin</tt>'.

==== Why can't we use the existing libxml interface to cr-sel-eng.c ? ====

Some CSS selectors (http://www.w3.org/TR/REC-CSS2/selector.html) can express "is preceded by X" or "is a descendent of X" (where X can itself be similarly constrained recursively), so we'd pretty much need to maintain the entire document in libxml form if we want to use libcroco for CSS selectors.

Suppose we want to find the style of node N. We pass libcroco a stylesheet and ask it what rules apply to N.
If the stylesheet says "nodes that are preceded by a node that is preceded by a node that's a descendent of (... etc. ...) have red stroking" then libcroco needs to be able to navigate through the tree.
So we can't pass libcroco just a libxml version of node N, we need to fill in its parent and sibling links, providing a libxml node for a significant proportion of all nodes in the tree.
(Short of using hardware watchpoints to check access to the sibling/parent links and supply them lazily.)

CSS Support

2005-01-17T02:23:36Z

PeterMoulder: * Note about shorthand properties such as marker

=== Hack: Convert to style-less SVG ===
A short-term solution (hack) for style support would be an input filter that converts stylesheet-using documents to non-stylesheet-using documents. cssanno.c (http://lists.w3.org/Archives/Public/www-archive/2004Jun/att-0001/cssanno.c or see google) does most of the work for this (for a generic XML document); the remainder of the work is to feed it a stylesheet by parsing the SVG document looking for <tt><style></tt> elements and fetching external stylesheets, and to change the outputted namespace from css: to svg:.

Ideally change <tt>add_single_property</tt> to ignore properties other than SVG ones. I.e. add an array of names of SVG properties, and check whether <tt>name</tt> is in this list. A linear search should be fine, I'd guess, and it's not too difficult to change it to a hash table or use a pre-coded binary search routine (whether glib or STL).

=== libcroco ===

Peter Moulder is looking at using libcroco from Inkscape.

There are a number of aspects of the work, some of which Peter will need help with:

* Modify libcroco selection stuff (cr-sel-eng.c) to allow us to use <tt>SPRepr</tt> rather than maintaining a libxml copy of the entire tree.
: Partly done (not checked in). The implementation is to provide a generic interface to nodes in a struct of function pointers (with names influenced by DOM).
: If we wish to, we could keep a copy of this modified cr-sel-eng.c in Inkscape, so that we can use current libcroco.

* Parse <tt><style></tt> element content, gathering all rules (across possibly many <tt><style></tt> elements) into a single stylesheet.
: Progress so far: have an initial implementation of sp-style-elem.{cpp,h}. (Not checked in.)

* Ensure that this single stylesheet is updated whenever any of the <tt><style></tt> elements change (or are deleted or created etc.).

* Similarly, ensure that the picture is refreshed when the stylesheet is changed.

* Create a user agent style sheet as required by http://www.w3.org/TR/SVG11/styling.html#UAStyleSheet

* Modify style.cpp to query the stylesheet. (Done but not checked in.)

* There may be some work needed for "shorthand properties", e.g. <samp><tt>marker</tt></samp> is shorthand for modifying marker-start, marker-mid and marker-end properties (http://www.w3.org/TR/SVG11/painting.html#MarkerProperty). A non-SVG CSS example is <samp><tt>margin</tt></samp>.

==== Why can't we use the existing libxml interface to cr-sel-eng.c ? ====

Some CSS selectors (http://www.w3.org/TR/REC-CSS2/selector.html) can express "is preceded by X" or "is a descendent of X" (where X can itself be similarly constrained recursively), so we'd pretty much need to maintain the entire document in libxml form if we want to use libcroco for CSS selectors.

Suppose we want to find the style of node N. We pass libcroco a stylesheet and ask it what rules apply to N.
If the stylesheet says "nodes that are preceded by a node that is preceded by a node that's a descendent of (... etc. ...) have red stroking" then libcroco needs to be able to navigate through the tree.
So we can't pass libcroco just a libxml version of node N, we need to fill in its parent and sibling links, providing a libxml node for a significant proportion of all nodes in the tree.
(Short of using hardware watchpoints to check access to the sibling/parent links and supply them lazily.)

CSS Support

2005-01-17T02:07:30Z

PeterMoulder: * More detail on progress

=== Hack: Convert to style-less SVG ===
A short-term solution (hack) for style support would be an input filter that converts stylesheet-using documents to non-stylesheet-using documents. cssanno.c (http://lists.w3.org/Archives/Public/www-archive/2004Jun/att-0001/cssanno.c or see google) does most of the work for this (for a generic XML document); the remainder of the work is to feed it a stylesheet by parsing the SVG document looking for <tt><style></tt> elements and fetching external stylesheets, and to change the outputted namespace from css: to svg:.

Ideally change <tt>add_single_property</tt> to ignore properties other than SVG ones. I.e. add an array of names of SVG properties, and check whether <tt>name</tt> is in this list. A linear search should be fine, I'd guess, and it's not too difficult to change it to a hash table or use a pre-coded binary search routine (whether glib or STL).

=== libcroco ===

Peter Moulder is looking at using libcroco from Inkscape.

There are a number of aspects of the work, some of which Peter will need help with:

* Modify libcroco selection stuff (cr-sel-eng.c) to allow us to use <tt>SPRepr</tt> rather than maintaining a libxml copy of the entire tree.
: Partly done (not checked in). The implementation is to provide a generic interface to nodes in a struct of function pointers (with names influenced by DOM).
: If we wish to, we could keep a copy of this modified cr-sel-eng.c in Inkscape, so that we can use current libcroco.

* Parse <tt><style></tt> element content, gathering all rules (across possibly many <tt><style></tt> elements) into a single stylesheet.
: Progress so far: have an initial implementation of sp-style-elem.{cpp,h}. (Not checked in.)

* Ensure that this single stylesheet is updated whenever any of the <tt><style></tt> elements change (or are deleted or created etc.).

* Similarly, ensure that the picture is refreshed when the stylesheet is changed.

* Create a user agent style sheet as required by http://www.w3.org/TR/SVG11/styling.html#UAStyleSheet

* Modify style.cpp to query the stylesheet. (Done but not checked in.)

==== Why can't we use the existing libxml interface to cr-sel-eng.c ? ====

Some CSS selectors (http://www.w3.org/TR/REC-CSS2/selector.html) can express "is preceded by X" or "is a descendent of X" (where X can itself be similarly constrained recursively), so we'd pretty much need to maintain the entire document in libxml form if we want to use libcroco for CSS selectors.

Suppose we want to find the style of node N. We pass libcroco a stylesheet and ask it what rules apply to N.
If the stylesheet says "nodes that are preceded by a node that is preceded by a node that's a descendent of (... etc. ...) have red stroking" then libcroco needs to be able to navigate through the tree.
So we can't pass libcroco just a libxml version of node N, we need to fill in its parent and sibling links, providing a libxml node for a significant proportion of all nodes in the tree.
(Short of using hardware watchpoints to check access to the sibling/parent links and supply them lazily.)

CSS Support

2005-01-17T01:39:18Z

PeterMoulder: * first text

=== Hack: Convert to style-less SVG ===
A short-term solution (hack) for style support would be an input filter that converts stylesheet-using documents to non-stylesheet-using documents. cssanno.c (see google) does most of the work for this (for a generic XML document); the remainder of the work is to feed it a stylesheet by parsing the SVG document looking for <tt><style></tt> elements and fetching external stylesheets, and to change the outputted namespace from css: to svg:.

Ideally change <tt>add_single_property</tt> to ignore properties other than SVG ones. I.e. add an array of names of SVG properties, and check whether <tt>name</tt> is in this list. A linear search should be fine, I'd guess, and it's not too difficult to change it to a hash table or use a pre-coded binary search routine (whether glib or STL).

=== libcroco ===

Peter Moulder is looking at using libcroco from Inkscape. He expects to need help ensuring that updates happen properly (e.g. refreshing the picture when the stylesheet is edited from the XML editor).

Inkscape

2005-01-17T01:33:14Z

PeterMoulder: * Add link to notes about CSS support

== Inkscape Wiki ==

This is a freeform area for Inkscape development and discussion.
Curious about WikiSyntax?

<table border="0"><tr><td valign="top">
=== About Inkscape ===
* [http://www.inkscape.org/ Inkscape Homepage]
* OtherProjects
* ArticlesAndPresentations
* TestimonialComments

=== User Documentation ===
* ReleaseNotes for 0.41 and past
* PressRelease for 0.41 and past
* ArticleIntroducingInkscape0_40
* InkscapeTerminology
* UserManual
* TutorialIdeas

=== Project Documentation ===
* ProjectInfo
* CreatingDists: how to build packages
* WebsiteEditing
* UpdatingTrackerItems
* ScribusInteroperability

=== Developer Documentation ===
* DeveloperManual
* CompilingInkscape
* WorkingWithCVS
* TranslationInformation
* HandlingPreferences: creating and using preference values
* AddSPObject: how to add a new SPObject type
* ReprListeners: responding to XML doc changes
* DebuggingTips: random tips to help debug problems
* [[http://livarot.sourceforge.net/ Livarot]]: for boolean ops

</td><td valign="top">
=== User Interface Discussion ===
* AccessibleGraphics
* ObjectManager
* DialogsReorganization
* ModalInterfaces
* TextUsability: text tool /dialog dialog
* KeyboardShortcutsToDo
** KeyboardProfiles: how you can help
* StatusbarAPI
* [[Animation-(Timeline)]]

=== Development Discussion ===
* [[Roadmap]]: the main todo list
* NewFeatureProposals
* ExtensionArchitectureProposals
* [[Coding Style|Coding Style Discussion]]
* FileTypes
* [[Icons]] (Application + Interface)
* [[ApplicationIcons]] ( more application + interface )
* InkscapeColor
* [[PrintingSubsystem]]
* [[SVG Competitors Plan]] - M$ WVG vs SVG, etc
* [[SVG Tiny Compliance]]
* [[CSS Support]]

=== Rearchitecture Discussion ===
* SubsystemRearchitecture
* CPlusPlus: Convert to C++
* [[Pangoification]]: replace font rendering subsystem
* GtkMMification: replace C boilerplate with gtkmm objects
* PathRepresentation

=== [[Galleries]] ===

</td></tr></table>

----
* WikiAttic: pages that are no longer relevant but kept for historical value

Animation-(Timeline)

2005-01-09T22:54:33Z

PeterMoulder: * Mention Spalah Flash

=== User interface for timeline-based animation ===

==== Existing animation programs (Free & non-Free) ====

* Macromedia Flash is a good non-Free example.
* F4L is a non-functional free-software mock-up of the Flash 4 interface.
* Moho as a gratis-but-non-free example. (Written in Java.)
* LimSee2 (http://wam.inrialpes.fr/software/limsee2/) is an excellent almost-free basis. (The web site claims open source, contradicted by the license which says no commercial use.)
* Spalah Flash (http://spalah.sourceforge.net/?p=10) (not to be confused with Spalah CMS) "is a GTK2/GNOME2 based application for generating Macromedia SWF and W3C SVG animations." I haven't looked at its GUI; can someone comment?

==== Other thoughts ====

It is suggested that there be basically two modes: Local (Object) mode and Global mode. Below is a picture showing a very rough design of the local mode:
http://www.inkscape.org/wiki_uploads/anim_gui1.png

In local modes, all properties of the object editing will be shown on a timeline, and one can create and edit frame within the timeline. Then one may assign different value of that porpoties on different timeline, or make it change linearly, or inlinearly :)

==== Fantavision example ====
Back in the '80's there was a program on Apple IIE (I believe) called "Fantavision". It allowed one to create vector artwork (although I didn't understand at the time that that was what it was called) and animations. It allowed one to create frames of animation where you manually repositioned, recolored, scaled, rotated etc. the objects from one frame to the next. However, it then automatically interpolated frames between the 2 frames (the number of interpolated frames was configurable) such that it create a smooth transition of the object moving from one frame to the other. The effect was very similiar to the "Morphing" effect for raster graphics (popularized in a Michael Jackson video, I believe). That is, the system calculated the trajectory of "Key Points" of the objects from one frame to the next.

I guess what I'm sayin is that I think a nice interface to create animations would be similiar. So to animate you would do the following:

* Draw the initial SVG Image

* Increment Frame (from say 1 to 20)

* Reposition the elements in frame 20 (including scaling, color changes, adding removing objects, etc, etc, etc)

* System would then calculate a trajectory for each key point from frame 1 to frame 20. Trajectories would be calculated for things like:
** Each "node" of an object
** Color
** Transformation Matrix
** etc

* You could display/manipulate the trajectories (using the trajectory editor shown above by the original creator of this topic)

* The system would then store the animations using SVG trajectories and the "Key Points" would be the frames you manually created

:So, to create say a 100 frame animation, one might only need to manually create/modify 10 frames and the system would interpolate the addional frames as necessary.

* Also, once the system interpolated frames it would allow you to manually modify the interpolated frames creating further "Key Points" and allow further refinement and interpolation.