On 11-Sep-2014 13:47, Johan Engelen wrote:
On 11-9-2014 14:58, Tavmjong Bah wrote:
Changing the "Inkscape GUI unit" should not introduce any 'transforms' on elements (as seems to being done now)
Inkscape is not doing the transforms thing. David Mathog added code that did so, and subsequently removed that code.
A clarification is certainly in order! Inkscape is most definitely applying transforms on unit conversions. However, it is not doing it by placing or modifying a single transform at the top level, and letting it apply to the underlying lengths and coordinates. Instead Inkscape is recursively traversing the entire tree and changing each and every one of those lengths and coordinates. The idea being that instead of being in pixels, they are now in document units. So if a length in some object was 1.0 while the document units was "in" changing the units to "mm" changes that length to 25.4.
This method currently breaks every object that has a preexisting clip when the document units changes. I strongly suspect that it breaks pretty much every other object that references something in <defs>, since the units conversion is not applied in <defs>. For instance, it also changes the relative size of patterns with respect to the objects they fill, this is yet another bug resulting from this section of code. Example:
1. New document. 2. Draw a square 3. Fill it with 1:1 stripes 4. Change the document to mm (from px). 5. Draw a second square 6. File it with 1:1 stripes
The two squares have stripes of different widths, even thought the pattern is the same. In the fill and stroke dialog there is nothing to indicate why this should be so. Change it again to "in", make another square, fill it with 1:1 stripes, and yet another scale for the same pattern appears.
My patch which Johan referred to stopped the recursion at groups, and placed the transform there, so the internal content was not modified at all. This behavior is controlled by SPGroup::scaleChildItemsRec in sp-item-group.cpp. For the example above, it caused it to be placed on the first layer. The patch was entered because the current way unit conversion works made it impossible to import clipped objects from EMF. The patch was not so much withdrawn as re-patched, so that the routine in question could be called with a switch so that it would work in either mode. When that patch was in place the "pattern" issue described above did not occur, both squares had the same pattern. Also clipping worked. But I had asked for feedback on this patch, and Johan didn't like it, so I (partially) backed it out, leaving the part that let clipping import work (with a conditional parameter), and (re)breaking problems like this pattern issue.
inkscape:document-units is exactly that: *document* units. Not UI units.
This is I think were we are on very different pages. I believe what Johan means by "document units" is "the units used to represent every length and coordinate WITHIN the actual SVG". So a 1" length in an "in" document must be "1" in the SVG. It cannot be "96" with a transform somewhere above that converts it, in the end, to "1". In order to maintain this correspondence, on a document units change, all lengths and coordinates must be changed throughout the document.
I don't see any point in having document-units of this sort. None. The only units that make sense in SVG, as Tav indicated, are with respect to a viewbox for the document, so that the final drawing has a scale in mm or inches, or whatever, without regard to its internal representations.
My view is that that the current document-units approach is daft. It replaces, at worst, a single transform (per layer?), with potentially thousands of changes throughout a document. To successfully do this throughout the document there cannot be any transforms with a scale different than 1.0, which is a ridiculous restriction on the construction of the SVG. Plus the implementation causes real bugs (see above). The argument for the current behavior is, as far as I can tell, aesthetics, that somebody reading the SVG should encounter all of the length and position values in the units declared by the document, everywhere within that document.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech