function inkex.unittouu reports inconsistent results if Scale not equal to 1 in the Document Properties dialog

[Alvin Penner]

Attached is a modified version of the extension dimension.py. The purpose of the modification is to print out the value of the variable:
scale = self.unittouu('1px')
which is the conversion factor from px to current document units.

perform three experiments:
1. load Inkscape and open the template file default_px.svg which uses inkscape:document-units=px
   run the extension 'Visualize Path->Dimensions' to get the result: scale = 1.0.
   this is the expected result since document units are px.

2. load Inkscape and use the default template file which uses inkscape:document-units=mm
   run the extension 'Visualize Path->Dimensions' to get the result: scale = 0.264583333328.
   this is also expected since document units are mm, and the conversion factor is 25.4/96 = 0.2645833333333333.

3. now use the same document, and open the Document Properties dialog, and change Scale from 1 to 1.1.
   now run the extension 'Dimensions'. The expected result is that the scale should change by about 10%. Instead the actual result is that: scale = 1.0. This is inconsistent. The unittouu scale result has apparently been reset by changing the Scale in the Document Properties dialog.

4. now change the Scale parameter in the Document Properties dialog to any value at all, and note that the unittouu scale result will always be 1 regardless of the value of Scale in the Document Properties, which is also inconsistent.

[su_v (suv-lp)]

[ JFTR - this is the same issue I unsuccessfully tried to report well ahead of any affected stable release in bug #1508400. ]

--
<opinion>
Given changes in commits like rev 15590 and those recently proposed in bug #1653650, the project seems to have chosen to hard-code workarounds in a few select extensions, leaving everyone else stuck with Effect()'s partially broken (or rather: limited) unit conversions. Personally, I got so frustrated with all of this that I gave up trying to upstream other possible solutions for the underlying issue itself (in inkex.py) for further discussion/review, and am content to work on/use a different patch for inkex.py with just my local builds/installations.
</opinion>

[Alvin Penner (apenner)]

yes, in retrospect, I think it would probably be best to mark this as "Will Not Fix". As far as I can tell, the source of the problem comes from rev 13750, which was committed on Nov 23, 2014:
http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/13750

This commit introduced the new method getDocumentUnit(). This function will check the scale factor and if it happens to agree with a known value of the document units table, then it will switch the document units to this new value and will correspondingly change the value of inkex.unittouu('1px') to compensate for this change. If no match is found then px will be used as a default and apparently inkex.unittouu('1px') will revert to 1. This means that there will inevitably be discontinuities if one uses a scale factor that is close to, but not exactly the same as, a known scale factor for converting units. So we will have to live with this discontinuity, or avoid it by using Scale = 1 in the Document Properties dialog, or avoid it by using the viewbox scaling procedure that was used in the file hpgl_encoder.py, which appears to work very well. The basic problem is that Inkscape's view of scaling is not fully compatible with the SVG view of scaling, because Inkscape has a parameter called inkscape:document-units which is not present in the SVG spec, so therefore the two views will never be transparently interchangeable.

[su_v (suv-lp)]

On 2017-07-01 12:41 (+0200), Alvin Penner wrote:
> I think it would probably be best to mark this as "Will Not Fix".

<opinion>
I strongly disagree (this can be fixed properly in inkex.py).

We both know that we disagreed in how we understand and view units in SVG and in Inkscape in the past, so let's just agree to disagree on this issue, too.

The message the project sends to authors of custom extensions (developed and maintained externally) is clear too: migrate all of your custom python-based extensions away from any python modules distributed with Inkscape as soon and as entirely as possible.
</opinion>

[su_v (suv-lp)]

On 2017-07-01 13:25 (+0200), su_v wrote:
> The basic problem is that Inkscape's view of scaling is not fully
> compatible with the SVG view of scaling, because Inkscape has a
> parameter called inkscape:document-units which is not present in the
> SVG spec, so therefore the two views will never be transparently
> interchangeable.

That attribute in <namedview /> keeps track of the _display_ units used to represent lengths and coordinates in Inkscape's GUI. Display units used in Inkscape's GUI are independent of and do not affect the document's scale (which is defined by the SVG document's viewport size - 'width', 'height' attributes of the SVG root node denoting a physical size - and the 'viewBox' attribute combined with the 'preserveAspectRatio' attribute - defining the relation between physical size of the viewport and SVG user units).

I'm unsubscribing from this report now - sorry for all the noise.

[Alvin Penner (apenner)]

marking as duplicate