Symbols scales wrong when document unit is not px (rev >= 12554)

[Björn Jadelius]

Steps do reproduce:
1. Set the documents default units to px.
2. Creata a box 100px x 100px
3. Set the documents default units to px.
4. Creata a box 100mm x 100mm
5. Select both squares and click the add button in the Symols panel.
6. Drag the symbol out to the document next to the original.

Expected behavior is that the symbol sholud be the same size as the original.
What happends is that the symbols big square is equal in size as the originals small square.

[su_v (suv-lp)]

Reproduced with Inkscape 0.91pre2 r13543 on OS X 10.7.5 (inkscape launched with default (new) prefs; in a new document based on the default template for locale "en_US" (default.svg)).

[su_v (suv-lp)]

Based on tests with archived builds:
- not reproduced with rev <= 12552
- reproduced with rev >= 12554
this unexpected behavior is related to the merge of the GSoC unit improvement branch in r12554:
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/12554>

[Alvin Penner (apenner)]

fix committed to rev 13709

[ScislaC (scislac)]

~suv: I'm trying to reproduce the original issue in 0.91.x while investigating backporting this, but I am not produce anything strange based on the instructions in the report. Do you have any recommendations for me to try?

[su_v (suv-lp)]

@ScislaC - possibly the recent switch to 'Display units' (bug #1387864) no longer exposes the reported issue (since now the viewBox values are no longer affected when changing default units).

IIRC the bug description has a typo (step 3 likely refers to setting default units to 'mm' - it doesn't make sense otherwise).

I'll test with archived builds of 0.91.x and trunk and report back.

[su_v (suv-lp)]

Based on the reporter's "steps to reproduce", there is no need for backporting: 0.91.x rev >= 13661 doesn't reproduce it. But there might be other use cases where this might occur - @Alvin, what do you think about backporting the fix to the stable release branch?

Related commit:
http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/13709

[Alvin Penner (apenner)]

I'm not sure exactly what the status of 0.91.x is, but I get the impression that the changing of default units has been disabled in it. If that is so, then the bug will not be reproducible. In that case there is no point in applying the patch for the bug. The patch executes only if the routine onDocUnitChange executes and I gather that this routine has been disabled by Johan.
       Somewhat off the record, it is imperative that this particular routine needs to be re-enabled in trunk as soon as possible, because we will not be able to fix, or even evaluate, any of the remaining issues associated with document units until the code is returned back to normal in trunk.

[su_v (suv-lp)]

<off-topic>
On 2014-11-30 05:17 (+0100), Alvin Penner wrote:
> Somewhat off the record, it is imperative that this particular
> routine needs to be re-enabled in trunk as soon as possible, because
> we will not be able to fix, or even evaluate, any of the remaining
> issues associated with document units until the code is returned back
> to normal in trunk.

"imperative"? Please take such statements | warnings to the 'inkscape-devel' mailing list for discussion. Adding it buried somewhere in the comments section (of a closed report) in the bug tracker will go unnoticed by most, no matter how "imperative" the issue is declared there.
</off-topic>

[ScislaC (scislac)]

Alvin: Given how you've been going after units related bugs lately, it would be really useful if you were to participate in the inkscape-devel list discussions about 0.91 and units (unfortunately it's a little fragmented at this point, but feel free to start a new and definitive one). The units changes were for 0.91 compatibility, but part of Johan's reasoning involved needing to do it differently for 0.92 and after to maintain compatibility.

[Alvin Penner (apenner)]

    thanks for the thoughts, I guess my problem is that I'm not sure where to start. And I am afraid to even enter the conversation because the issue is so extremely volatile and everyone is so extremely opinionated on this subject. It reminds me of the famous icon battle, which I would rather avoid.
     In any event my position is very simple: From a technical point of view we are already 90% there, the job is almost complete, this is not the time to turn tail and run.
    I think my position is probably best summarized by the Bug 1397564 which I encountered yesterday morning, and which I think deserves immediate attention. Perhaps the conversation can be continued there...?

[Björn Jadelius (boj-s)]

Hello.

My suggestion in the matter of units is to not use any unit at all except in output. And that there are two settings in document settings: "Printing scale" and or "Export scale". One internal unit scales to for example one mm when printing and to one px when exporting png.

Björn Jadelius

[Alvin Penner (apenner)]

jftr, I have added my wishlist to the mailing list:

http://inkscape.13.x6.nabble.com/Roadmap-brainstorming-for-0-92-and-forward-td4972161.html

[su_v (suv-lp)]

It seems to me that r13709 (trunk only) needs to be adjusted to the "new reality" that 'document units' now are 'display units' again (and do no longer change the document's scale).

With rev >= 13709 changing the display units in document properties affects the scale (on the canvas) of symbols inserted later on - this seems odd to me (display units in trunk rev >= 13748 only affect Inkscape's GUI, not the document's scale):

1) launch current trunk with default (new) prefs, default template
2) open 'Object > Symbols...'
3) select the 'AIGA' symbol set, and insert e.g. the 'Mail' symbol
4) open 'File > Document properties' and change 'Display units' to 'px'
5) repeat step 3

Expected result:
The size of the inserted symbols is the same relative to the page.

Actual result:
The display unit for the GUI affects the scale of the inserted symbol (the symbol inserted with 'px' as diplay unit is much smaller than the one inserted with 'mm' (default) as display units).

Revisiting this report after having encountered a regression in current trunk (r13803) with documents which don't have 'inkscape:document-units' in the document's <namedview> element: symbols get inserted upside-down with rev >= 13709. A test case can be found here:
<https://dl.dropboxusercontent.com/u/65084033/irc/drawing-1-via-pdftocairo-2.svg>

[su_v (suv-lp)]

On 2014-12-18 18:03 (+0100), ~suv wrote:
> Revisiting this report after having encountered a regression in
> current trunk (r13803) with documents which don't have
> 'inkscape:document-units' in the document's <namedview> element:
> symbols get inserted upside-down with rev >= 13709. A test case can
> be found here:
> <https://dl.dropboxusercontent.com/u/65084033/irc/drawing-1-via-pdftocairo-2.svg>

Just to clarify - the regression with symbols inserted upside-down if the document's <namedview> element doesn't have the attribute 'inkscape:document-units' happens with rev >= 13709, hence the comment here.

[Alvin Penner (apenner)]

yes, the code in rev 13709 no longer makes sense, given that the document units have been disabled. I will try to revert it within the next few days if someone does not beat me to it...

[Alvin Penner (apenner)]

revert committed to rev 13806.
rev 13709 consisted of two parts. The first part, in sp-item-group.cpp, routine ScaleChildItemsRec, had already been disabled previously in rev 13748, which makes this code unreachable. The second part, in clipboard.cpp, has now been disabled in rev 13806.
further developments in this area will need to await a decision as to how to proceed with a re-implementation of the concept of document-units.

[Alvin Penner (apenner)]

the original commit, rev 13709, has been re-instated with a few additions to deal with comments 13 and 14.

- the first addition is not to perform any scale changes if "document-units" is not defined.
- the second addition is to convert stock symbols from units of "px" to units of "document-units" during a copy and paste operation.

committed to rev 13853

[Alvin Penner (apenner)]

a further change was committed to rev 13854.
This is to allow scaling of stroke width even if the stroke color is not defined. This was made necessary by the fact that sometimes stroke and stroke_width may be present in different <svg> elements which are not necessarily aware of each other, especially for stock symbols, see Bug 1409458

[Shai Efrati (shaief)]

I'm on Inkscape 0.91+devel r (Jul 20 2015) and this bug still affects me with a slight change - changing the units to px doesn't solve the issue.

[Alvin Penner (apenner)]

it depends entirely on how you make the switch from mm to px as document units. In previous versions of Inkscape, in development versions, it was possible to do a live switch from mm to px using the Document Properties dialog. In current trunk, that live switch is no longer possible. So if you open the Document Properties dialog and switch Display Units from mm to px, then the document units will still be mm, despite what the dialog says.
    The simplest way to use px as document units is to load the file share\templates\default_px.svg directly into Inkscape and then continue with your test.

[Shai Efrati (shaief)]

Thanks. That's a huge UI issue then.
When i change the units using the button i assume they changed.

Is there a way to change the units on an open document?

[Alvin Penner (apenner)]

not that I know of. This has been discussed a lot in the last year. The issue has not been satisfactorily resolved. I am attaching a few references, there are many more, but these are the ones that come to mind immediately.

https://bugs.launchpad.net/inkscape/+bug/1369197
http://wiki.inkscape.org/wiki/index.php/Units_In_Inkscape:_Document_Unit_Change
http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/13748

[Shai Efrati (shaief)]

Thank you for the links!
I don't understand - it affects also the stable version, and it seems to me like a major issue.

BTW - i changed the document-units also in the XML of a file i'm working on to be like the template file, but it didn't solve the issue.

The template file works as expected.

[Anonymous (susi-8888)]

Like to report that I can confirm the bug in the stable r0.91 on my Windows system, and I see it fixed on a r14358dev version compiled for Windows 32 bit. Operating system is Windows 7, 64 bit with 4 GB ram. I also see a unintended scaling, if I am coping a element from the stable version into the developer version (having two different instances of inkscape in parallel active. This is not a use case, not seen as a bug, just for your info.