units of viewBox are not defined, or known, after changing Display Units

[Alvin Penner]

- Windows XP, Inkscape rev 13775

trial 1:

- load Inkscape, using file default.svg
- interrogate Document Properties to find Display Units = mm, Page Size Units = mm
- interrogate XML editor to find width, height, viewBox are all in mm as expected
- in Document Properties change both Display Units and Page Size Units to px.
- in XML editor note that width and height are converted to px as expected
- however the viewbox is still in mm, which is unexpected.
- note that there is not a single reference to mm anywhere in the file, nothing that would indicate that the viewBox was intended to be in mm

trial 2:

- load Inkscape, using file default_px.svg
- interrogate Document Properties to find Display Units = px, Page Size Units = mm
- interrogate XML editor to find width, height are in mm as expected, viewBox is in px as expected.
- in Document Properties change Display Units to mm.
- in XML editor note that viewBox is still in px, which is unexpected

There does not appear to be any relationship between the units of viewBox and anything else.
Previously the units of viewBox were specified by the Default units (Display Units).
Now it looks as if the viewBox units are initially specified by the original value of Display Units when the file is first loaded, but are subsequently not responsive to any changes that are made.

This will break a lot of code if it is kept this way.

For example, in the Python Extension system, one of the more common calls is the call inkex.unittouu() which is used to convert from one system of units to another. This call no longer functions as expected since it depends on the call inkex.getDocumentUnit(self). This call no longer works properly because it loads the correct units on the initial file load, but it is subsequently unresponsive to any changes that are made in Display Units, or anything else.

[Tavmjong Bah (tavmjong-free)]

The values in the 'viewBox' represent initial 'user units'.

The real world values of the ''user unit' is defined by the ratio of the root SVG width/height to the 'viewBox' values. There is represented by an "SVG scale" factor.

Changing the "SVG scale" factor has been disabled in 0.91 due to the large number of bugs it causes.

The "document" or "display" unit indicator was not intended to change the "SVG scale". In the run-up to 0.91 this value started to be used in that way. This introduced a number of bugs, which is why "document" unit was renamed "display" unit. Changing the "display" unit should only effect things in the GUI.

Since the SVG scale factor cannot be changed in 0.91 I don't see how the Python Extension system can be broken.

We should have a way of finding the SVG scale factor. Johan wants to use a single value. I believe this is already in trunk. I prefer to use something more like Geom::Scale which can handle an asymmetric scaling (which is allowed by SVG).

[Alvin Penner (apenner)]

>> The real world values of the ''user unit' is defined by the ratio of the root SVG width/height to the 'viewBox' values.

The above statement suggests that the viewBox has units associated with it. The point is that in current trunk the viewBox does not have any units associated with it, therefore it cannot be compared to anything. The viewBox used to have units associated with it, and those units were previously called Default Units and now possibly called Display Units. However those units have now been destroyed or lost due to the recent changes. You cannot compare numbers when you don't know what units the numbers are in.

[su_v (suv-lp)]

Attaching a small demo extension which creates guides and rects based on
position and size defined in a custom unit, and works no matter how the
user changes the display units or the page size units of the default
template.

It even is supposed to work with scale factors of the SVG user unit
which aren't matching a predefined unit (such documents can't be created
with Inkscape at the moment, see discussion on the mailing list).

I don't claim that all extensions shipping with Inkscape would support
this out-of-the-box right now - the extension is a snapshot of an
on-going attempt to explore the relationship between the size of the
viewBox, the scale factor of the SVG user unit and the absolute
dimensions defined by the page size (<svg> width, height + page size
unit identifier) [1].

Tested successfully in current trunk and stable 0.91.x. The extension
takes the changed interpretation of guides position in trunk into
account (the Inkscape version detection is very simplistic though).

The extension installs itself as
'Extensions > Debug > Bug 1397564: viewBox scale factor'

--
[1] Doesn't take relative unit identifiers like '%' or 'em' used for
<svg> width, height attributes into account at the moment.

[Johan Engelen (johanengelen)]

Some notes to perhaps help you understand the recent changes to the unit system in Inkscape:

It is not possible to set the SVG user units from the current UI.

Display/Default units are only used for Inkscape's UI widgets, and is completely unrelated to the values in SVG.

The Python extensions work fine with units in current trunk. As you can see in rev 13750, inkey.py now calculates the SVG user-unit based on viewbox and document width (like Inkscape does internally). This unit is completely unrelated to the "Default" or "Display units" in Inkscape's UI. The output values of a python extension should not and does not depend in any way on Inkscape's UI unit.

The viewbox has no units associated with it, it's just 4 numbers without any unit. The viewbox combined with a document width/height specified /with/ units, that combination defines SVG user units.

Upon default document load, SVG user units == default display (UI) units. When the user changes the UI units, indeed the SVG user unit does not and should not change.

The remaining issue is updating the SVG user units when the viewbox changes independently of document width/height. For this, the user would have to go into the XML editor.

[Alvin Penner (apenner)]

well, I give up, this is a waste of time. My initial instinct was to say nothing, and I should have followed that instinct. There are two points however that I would like to make. The first point is that as far as I can see the viewbox is currently totally disabled in trunk and has no physical meaning whatsoever. If it is disabled and actually has no meaning then we should simply say so openly and honestly without using a great deal of smoke and mirrors and sleight-of-hand to attempt to artificially attribute significance to something that currently has none.
    The second point is a more pragnatic one, namely that we cannot currently fix the remaining bugs that are associated with the conversion of document units. There are a few remaining unit-conversion-related bugs that still need to be fixed, and they cannot be fixed with trunk in the state it is currently in.

[su_v (suv-lp)]

On 2014-12-01 24:14 (+0100), Alvin Penner wrote:
> The second point is a more pragnatic one, namely that we cannot
> currently fix the remaining bugs that are associated with the
> conversion of document units. There are a few remaining
> unit-conversion-related bugs that still need to be fixed, and they
> cannot be fixed with trunk in the state it is currently in.

Can you think of (intermediate, temporary, provisional) ways to re-enable conversion of "document units" (what exactly do you refer to here? [1]) to allow working on remaining bugs (AFAIU this refers to regressions exposed when the viewBox scale factor of an existing document is changed and the drawing content needs to be rescaled) - but without undoing the recent refactoring which attempts to clarify the scope of the various types of unit identifiers used in SVG and Inkscape documents [1] to improve support for native SVG features (viewBox) and prepare for additional Inkscape features (for example allowing users to set a drawing scale)?

Maybe as temporary step on the way to 0.92 (or 1.0) - with the sole purpose of helping developers to continue working on related internal features - a new widget could be added in the document properties which would allow to explicitly change the scale factor of the viewBox, and thus trigger a rescaling of the drawing content if used on an existing document? There's still plenty of time to figure out how exactly such a feature would be exposed to users in a next major release (0.92 or 1.0 isn't going to be released tomorrow) ...

[1] see also:
http://wiki.inkscape.org/wiki/index.php/Units_In_Inkscape

[Alvin Penner (apenner)]

 First of all, I would like to apologize for the nasty tone of my previous email. I did not mean to offend anyone, and I am grateful for the fact that no one has taken offence. I was just trying to express some frustration at the pace at which things are moving. I believe that we are almost within sight of reaching the goal of having a meaningful conversion between different systems of units. I believe that there are only about 3 or so serious bugs that remain to be dealt with before we reach that goal. So I would like to agitate for one final push to complete.
 As to how to proceed, I am not entirely clear on who has done what, and why, but I think rev 13748 is probably the most critical one that needs to be undone. Possibly rev 13751 is relevant as well, I am not entirely sure here. The point is that I can understand very clearly why this was done to the branch 0.91.x, it makes perfect sense to do it there because we are preparing for a release. But it would be nice to get trunk back to normal again.