Construction in Inkscape
Sometimes - increasingly perhaps - I find myself using Inkscape for constructing program assets.
Program assets are a different beast to standalone artworks because you start to have to recombine artistic elements in new ways programmatically.
Most of the time, when web programming, you don't really need to generate completely original artwork on the fly, but you often need to composite some selection of pre-drawn assets. There are a variety of ways to do this, but Inkscape doesn't seem to make any of them very easy for me.
Composition of minimal PNGs
Export PNGs from Inkscape and composite them elsewhere, using external data or hard-coding to get them all to composite in the right place. This involves working out offsets, either by trial and error or trying to read them off the rulers in Inkscape. But, madly, the rulers and coordinates in Inkscape have the y-axis inverted.
You also have to build the document in Inkscape so that the various elements can be exported with the alpha channel - independently of shapes above and below the one you're trying to export. This means everything has to either be cloned off the page, or drawn on a seperate layer so that it can be independently hidden.
If you're actually attempting to composite PNGs client-side in IE, you need to use the PNG alpha hack, which isn't universally applicable.
Composition of padded PNGs
Export PNGs that are padded such that they can all be composited using one origin. This can be done in Inkscape, but it still isn't easy, because Inkscape only has the option to export the selection. The trick is to create completely transparent bounding rectangles and use these to store Inkscape's export settings. The resulting graphics are larger in filesize than they might otherwise be, and composition could also be slower.
This DHTML clock I wrote a while back mainly uses this method.
Export SVG
Export SVG and write a program to import, modify/compose and potentially rasterise. Rasterisation is still tricky. It will be really useful when browsers get more widespread support for SVG.
Still, this method requires painstaking care making sure that all the symbols are easy to recombine. It often means using a lot of svg:use elements (clones in Inkscape lingo), or, more easily, rewriting the xlink:href attribute to repoint the link to a different symbol. Doing it this way preserves the affine transform, but creating your own transforms (for a newly created clone, say) is still tricky.
The SVG Cities interface I mentioned recently uses this method.
Draw out all the permutations
Generate lots and lots of permutations using Inkscape, perhaps using a script to accelerate exporting them. This only works if the number of permutations is small, if it's possible to use only a subset of them, or if they can be generated en masse using Inkscape's excellent Tile Clones tool.
This is the approach I'm about to take with this DHTML dice widget I'm working on. First I've drawn out my base dice, then I've cloned one face onto the sides of one die.
Now I can align the 5 currently unused faces over the 5-side, then modify the links using Inkscape's XML editor:
Some of the problems I've come across in Inkscape when used for this kind of work include:
- As mentioned, the y coordinates are all wrong so any coordinates you read off the UI have to be mapped y -> (document height - y)
- Inkscape doesn't offer any way to make symbols more invariant. Ungrouping and regrouping works, but is time-consuming.
- There isn't an easy way to manage which clones link where, or re-link clones on mass. In fact the only way to re-link clones is with the rather dire XML editor.
- Inkscape doesn't let you group 1 primitive, even though this is both valid and useful.
- Inkscape doesn't let you create offscreen symbols for use with clones.
- Inkscape doesn't make it easy to set IDs for things.
- All IDs generated by Inkscape are meaningless alphanumeric strings. Clones, for example, don't inherit any part of their parent symbol's ID.
- Inkscape has a "label" as well as IDs. Label overrides ID in all of Inkscape's UI, even though they are also meaningless alphanumeric strings, useless in the programming, and they must be set independently of the ID.
October 8th, 2006 at 10:02 pm
Your points:
1. Yes, it's a known problem, which will be fixed one day.
2. What do you mean by "making symbols more invariant"?
3. I don't think relinking a common enough operation to give it UI of its own. You can just clone a group, and then it's easy to delete old object from the group or add new ones into the group without ungrouping it, so all its clones update accordingly.
4. You can always group it with a temporary object and then delete that object from the group.
5. Support for is eventually planned.
6. The Object Properties dialog with its ID box looks easy enough to me.
7. Yes, using the original's ID as part of a clone ID is a good idea. Otherwise, of course IDs are "meaningless" - they are created automatically and not intended for user consumption, in general.
8. Labels are as "meaningless" as you set them. Their advantage is that unlike IDs they need not be unique and can contain any characters. This makes them useful for annotating objects if you need that. What do you require from them?
October 9th, 2006 at 12:42 am
Sorry, I didn't really go into detail about the problems I'd experienced with Inkscape.
The basic operation required to construct functional graphics in Inkscape is symbol swapping. Swapping symbols allows you to use all the drawing features to create 'source' objects, and also create a 'destination' affine transformation. Whichever symbol you swap in inherits the clone's transformation.
The dice are very good examples - I create 6 dice group in which the faces are seperate clones. Then I update the xlink:href for each face to link the right one in. That is the only way to ensure that the faces are put into exactly the right positions.
1. I know it's a known problem. I submitted a bug report three weeks ago.
2. Sorry, that was very terse of me. Transformations are split between the group element and its children depending on when you grouped it and what you've done to it since; this is about the worst possible situation for scripting. What is most needed is an 'insertion point', with the group's children specified relative to this. But an alternative would push the transformation into the group, multiplying the group's transformation with the children's transformation. 'Invariant' because then the transformation would be be described in one invariant way, not split between the group and its children in an unknown way.
3. No, that will update all the clones. I don't want to do that. I just want to swap the symbol being linked to, for some of the clones. This, as I say, is the one operation that I find absolutely indispensible, but I can't do it on a selection of clones. I have to do it one at a time. This is annoying when I have to do it for a small number of clones; when it's thousands it's unthinkable.
4. Yes. That's what I currently do. Strangely, Flash lets you group one element even though it's not a useful operation in Flash
(I found that out by accident on Friday).
5. Yes, I had read that on the wiki. Well, I look forward to it.
6. It breaks any clones linking to it. They should be automatically updated. Also it shouldn't require a 'Set' button because the UI paradigm throughout the program is for instant apply. Same goes for attribute assignment in the XML editor actually.
7. IDs are for programmer consumption. Labels are meaningless to programmers working with the DOM.
8. In view of the fact that programmers have to work with IDs, labels get in the way:
* They are pre-filled when they might as well be left blank.
* You have to set both ID and label manually - if you make the ID meaningful the label will still be junk unless you retype that too.
* They have a # in them. Don't understand why, if they are for user consumption.
June 24th, 2008 at 11:11 am
Added this article to the SVG link resource