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 <suv-sf@...58...> 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.
- Introduce a file called document-compatibility.cpp.
- 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 expects. 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:
- Upgrade is performed before the SP tree is constructed. This means
the SP tree doesn't have to retain backwards compatibility junk indefinitely. 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:
- No semantic help from the SP tree.
- ???
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. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel