Might I echo Johan's earlier comment about this possibly being a bit
much to squeeze in for this release? Obviously you (and others) have
done great work on getting Inkscape's coordinate system in better shape,
but it appears there are at least one or two major problems which need a
lot more changes to really get them right.
Krzysztof Kosiński wrote:
> W dniu 6 kwietnia 2010 03:21 użytkownik ~suv
> <email@example.com> napisał:
>> Inkscape 0.47+devel r9295:
>> Newly created horizontal guides don't stay where they are dropped but
>> immediately move to the mirrored location. Origins of vertical guides
>> move to the mirrored position. Diagonal guides can't be positioned as
>> intended either, guides converted from objects don't align with the objects.
> It's because the "namedview" element is stored without conversion to
> SVG coordinates.
> Here's how I would like to fix this and the 3D Box problem.
> 1. Introduce a file called document-compatibility.cpp.
> 2. Introduce versioning of documents' editing information. The editing
> info version will not be tied to the Inkscape version - it will be
> just a number. We start at editing info version 0, which is defined as
> what Inkscape 0.47 uses. Every subsequent version is defined as a
> series of transformations from version 0.
> 3. document-compatibility.cpp contains a function called
> upgrade_document(), or something like this. It takes an
> Inkscape::XML::Node to the root of the SVG and upgrades the document
> to the latest editing info version.
> 4. upgrade_document() reads the editing info version from an extra
> attribute in the SVG root (it can be called
> inkscape:document-version). It executes a series of transformations on
> the XML document to bring it in line with what the current SP tree
> 5. When you want to make a change in the XML, you bump the current
> version by one, add the necessary XML transformations and update all
> relevant SP tree code to only recognize the new XML. If you did
> everything correct, the SP tree code doesn't need to know about any
> document format other than the latest one.
> Why this is good:
> 1. Upgrade is performed before the SP tree is constructed. This means
> the SP tree doesn't have to retain backwards compatibility junk
> 2. We have a well defined backwards compatibility mechanism, rather
> than a collection of hacks.
> 3. We have a clear way forward to fix long time blunders like flowtext.
> Why this could be bad:
> 1. No semantic help from the SP tree.
> 2. ???
> Regards, Krzysztof
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> Inkscape-devel mailing list