As you know, currently tutorials are written directly in SVG. This, among other things, prevents proper automated i18n - if a section changes, a translator will have to manually figure out what changed, manually find the matching text in his translation, and manually change it. Also, producing the tutorials in formats other than SVG is also pretty much manual work. In other words, it looks nice but is a nightmare to maintain.
Our attempts to change that ran into difficulties: a script or stylesheet which might generate an SVG tutorial would have to combine text (from some source file, e.g. Docbook) with illustrations (from separate SVG files). To do so, it would need to know the dimensions of the pieces of texts and the illustrations, because everything in SVG is absolutely-positioned. And that was the problem.
Now I got an idea: Why not use Inkscape itself for this? Here's how it might work:
1 Add a couple new command line switches to Inkscape that would force it to load the document, find the object with the specified id, and report on the command line the width or height of that object's bbox, then quit.
2 Write an XSLT stylesheet that, for each piece of text, would write a temporary SVG file with it (in flowtext, same as the finished tutorials would use), run Inkscape with these command line switches to figure out its dimensions, and then use these numbers to position it in the final SVG files it produces. Same thing is done with illustrations, except that no temporary files are needed - they are stored separately (and referenced from the master XML source) anyway.
If this sounds like a mess, it's not. I've done XSLT running external processes before. It works, and it is even portable (though portability may depend on the processor you use). It will be rather slow but in our case it does not matter much, I guess.
So, unless someone invents something still better, I can do 1 above (it will be useful for other things, too), and someone will need to do 2 (with my help if needed). Perhaps 2 can also be done in another language, but I vote for XSLT - it's a very nice and powerful language for XML processing, definitely worth learning.
On Mon, Nov 29, 2004 at 01:32:48AM -0500, bulia byak wrote:
1 Add a couple new command line switches to Inkscape that would force it to load the document, find the object with the specified id, and report on the command line the width or height of that object's bbox, then quit.
How about a query _mode_. That way inkscape load itself and the SVG only once, and the client can keep asking questions of it until it's finished? Might be handy for other stuff later on too.
So, what would be the source format? I have a good experience with DocBook/XML and XSLT for it, though I never managed to get it working with SVG.
The source format does not matter much, as the source-to-SVG stylesheet will be completely custom anyway. But DocBook is nice and probably rich enough to cover our modest needs, and with it we'll be able to use standard stylesheets for e.g. converting to HTML. So, let it be DocBook (unless anyone has a better idea).
On Mon, 29 Nov 2004 15:10:04 -0500, bulia byak <buliabyak@...400...> wrote:
So, what would be the source format? I have a good experience with DocBook/XML and XSLT for it, though I never managed to get it working with SVG.
The source format does not matter much, as the source-to-SVG stylesheet will be completely custom anyway. But DocBook is nice and probably rich enough to cover our modest needs, and with it we'll be able to use standard stylesheets for e.g. converting to HTML. So, let it be DocBook (unless anyone has a better idea).
The only alternative to DocBook/XML in XML docs area is DocBook Lite :) and IBM's TEI.
Alexandre
participants (3)
-
Alexandre Prokoudine
-
bulia byak
-
Kees Cook