On Tue, Mar 20, 2007 at 01:34:54PM -0500, Jeff Schiller wrote:
Frankly, I think the SVG tutorials included with Inkscape are excellent - I haven't found a strong need for anything else, in terms of documentation. I find the "work-in-the-tutorial" paradigm in Inkscape to be very effective way of learning and quite unique - are there any other software products that do this? And thankfully these tutorials are all offline, meaning I can travel and still learn how to use Inkscape. If anything, I would like to contribute to improving/correcting these tutorials as a first contribution (already found a couple bugs/typos).
Great, well there's more then plenty of work needed for new tutorials. We'd love to see tutorials on subjects not already covered, or even non-Inkscape-specific things like general guidelines about making good art, diagrams, logos, and so on.
One way to see what tutorial topics people need is to browse through mail archives of the inkscape-user@ mailing list for questions that get asked repeatedly, and create tutorial entries to address them. For instance, we get *many* questions related to document export (PDF, JPG, etc.), and lately have gotten a number regarding blur.
Of course, also just general updates to the existing tutorials are quite welcomed.
So how does one go about submitting patches to these tutorial SVG files? Is it best to edit the tutorial in Inkscape directly and then do a svn diff?
Actually the best way is to edit the source files. The source files for the tutorials are written in Docbook format, which is XML like SVG, but a much simpler syntax. You check these out from the doc-docbook subversion module, and there are directions in that module.
However, if you don't want to mess with subversion and docbook, you could go ahead and edit them in Inkscape and post a diff to the patch tracker. I would probably make a non-edit to the original and save it to do a diff against, to avoid the huge differences.
I found that there are huge differences when I do this, even for a one-word change. And the resultant patch is not very review-friendly (lots of RDF stuff seem touched, etc). Is it better to just submit the entire SVG file instead of a diff patch? If so, how do reviewers tell what has changed?
Again, I think most people use the original docbook files, which avoids pretty much all these issues.
Other people just write textual descriptions of what should change in the text into a bug report, especially when it's just text changes.
By the way, would it maybe be better to save the tutorial files as Plain SVG (without metadata) to avoid such metadata-like changes?
It wouldn't matter since the SVG is all generated from the docbook files automagically. Plain SVG strips out information from some things which would make the drawings less useful in the inkscape tutorial; for example, stars or spirals would lose their star-ness or spiral-ness, so in general even aside from docbook I think for the tutorials you want to save in regular svg not plain svg.
After that, I would like to work on the code, though I'm still struggling to build Inkscape in OpenSUSE 10.2. Unfortunately I've had no end of problems in doing this thus far, though when I discover something out, I'll contribute to pages like http://wiki.inkscape.org/wiki/index.php/CompilingSuse
Great, that's exactly the right approach. Historically, getting Inkscape to work on SuSE has always been a bit problematic, but it can be done. I don't know that any of our developers test against SuSE regularly, though, so your efforts here will probably help out a lot of future SuSEr's.
Bryce