0.92.x, 0.92.1, 0.92.0 Default.svg using mm as units and scale of 1 causes problems

svg file, symbol library

dxf file generated from 254mmSq-Scale_set_to_1perMM.svg

There was recently a change made in the scaling of the dxf output. This will have an effect on the output when using units that are not px. The change was made in:
http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/15469
in response to Bug 166097
https://bugs.launchpad.net/inkscape/+bug/1660967
There is also some discussion of the base unit at:
https://bugs.launchpad.net/inkscape/+bug/1643383/comments/8

Hi Alvin, thank you for your comment.

You might want to review that change in light of the difference in *scale* of the two files in 1660474.

The scale set to px in the file shapes_px.svg is 1, and no scale shift should be expected on output, since the internal hardcode of 96 dpi is respected.

The scale set to mm in the file shapes_mm.svg is 1, when it would be more appropriate for it to be 3.77953, which respects the internal 96dpi (not 25.4dpi)

I'm using 0.92.1 r15371, and behavior is as expected when the scale (or viewbox) is set commensurate to 1px per 1 display unit.

When I set display units to px and scale to 1, any change of display units in the document properties in, mm, cm, etc. updates the scale commensurately and file output is scaled correctly, as are symbols created for use in other files.

Correspondence with the "real world" would suggest:

1:1 == px:px
1:96 == px:in
1:3.77953 == px:mm

Respectfully,
TD

Typo correction:

1:1 == px:px
96:1 == px:in
3.77953:1 == px:mm

TD

as far as I can tell, this report is a duplicate of Bug 1660967

- using Inkscape 0.92.1 r15371
- load the file 254mmSq.svg
- perform Cone->Unlink Clone
- save as dxf using the Base Unit mm
- get a dxf file with a rectangle whose sides are 67.204167 mm long, which is wrong

- using trunk Inkscape 0.92+devel 15563
- perform the same sequence using the same Base Unit
- get a dxf file with a rectangle whose sides are 254 mm long, as expected

the changes in the dxf_outlines.py routine were committed to the 0.92.x branch in rev 15390:
http://bazaar.launchpad.net/~inkscape.dev/inkscape/0.92.x/revision/15390
however, as far as I know, I don't think this is yet part of any stable release, so it will probably be necessary to download the latest version from the repository at:
http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/files/head:/share/extensions/

While the new dxf_outlines.py resolves the output to plotter filetypes workflow, the issue of symbols, browsers and other programs remains.

To replicate

Browser (Chrome):
Open each of the following files in a browser, note that 100mmSq-Units_Cm-Scale_1_Symbol.svg is not visible.
100mmSq-Units_Px-Scale_1_Symbol.svg
100mmSq-Units_Cm_Scale_37.79527_Symbol.svg
100mmSq-Units_Cm-Scale_1_Symbol.svg

Symbols use within Inkscape:
Copy the three files to the symbols folder, launch Inkscape and use a symbol from each file. Note that the symbols from 100mmSq-Units_Px-Scale_1_Symbol.svg and 100mmSq-Units_Cm_Scale_37.79527_Symbol.svg are the same size as their respective original symbol files, but the symbol from 100mmSq-Units_Cm-Scale_1_Symbol.svg is much smaller (~38x smaller). One would expect the symbols made in one Inkscape file would be the same size when used in another.

One vector illustration program that does not interrogate for units/scale when opening SVGs is Affinity Designer. 100mmSq-Units_Cm-Scale_1_Symbol.svg opens with the object at 10px square.

Simple solution for above issues is to use a default.svg having px as units and scale set to 1. Suggest this as the packaged default.svg, now that output of plotter filetypes has been resolved to correct for scale/viewbox.

Regards,
TD

I cannot comment on the browser issue because I don't have Chrome installed, but I can confirm the scaling issue with symbols. The file 100mmSq_CM_scale_1 is too small when used as a symbol.

- confirmed on Windows 10, Inkscape 0.92.1 r15371
- confirmed on Windows 10, Inkscape 0.92+devel 15592

Duplicated browser issue in IE v11, Safari 5.1.7, and Firefox v52.

I think the browser issue should be reported separately because it is not related to the behavior of symbols.
   With browsers the problem that will be encountered is the fact that Inkscape sometimes uses variables that are not part of the svg spec. For example the variable:
<svg viewBox="0 0 397.95275 397.95278"> is part of the svg spec while the variable:
<sodipodi:namedview inkscape:document-units="cm"> is not part of the svg spec.
Therefore any Inkscape file that uses both of these variables, set to non-default values, is more or less guaranteed to differ from a browser at some point. However, it is reasonable to expect that the symbols would still scale correctly independently of that since they are entirely internal to Inkscape.

It appears that symbols created in documents with scale that doesn't directly correlate to 96dpi are at the root of these issues whether used in a browser, other programs, or even Inkscape itself. So, I don't think browsers should be divorced from this report.

The sodipodi document units would be irrelevant if the scale for cm were set to the value that correlates to 96 dpi (that is 37.79527). However, the default.svg that is released in 0.92 (having display units as mm and a scale of 1 which do not correlate to 96dpi) imposes a non-standard scale and typical users will unaware that documents are non-standard until they correct the scale in the properties panel. (And plainly stated, it is beyond reasonable to expect typical users to know how and why.) When users change the units to px, in, cm, etc. the scale adjusts to remain non-standard unless explicitly changed to 96dpi or its correlates.

The simple solution is to release Inkscape with a default.svg having units=px and a scale=1:1. This is fully SVG standard document. If users change to any other display unit (mm, cm, in, etc.) the scale adjusts to a correlate value and the user need not concern themselves whatsoever and will still work with a fully standard compliant document.

Non-typical users that require a non-standard scale should have to explicitly change scale and opt-out of standard. It is beyond reasonable to expect typical users should modify scale in order to use the standard scale which they should expect to be a program default.

Considering how much effort has gone into updating Inkscape for the standard of 96dpi and the means to deal with non-standard legacy files, it's downright baffling to find that the default Inkscape configuration will create new non-standard files unless scale is modified by the user.

Regards,
TD

Also likely cause of Bug #1673924
"Outset (and inset) fails to offset by amount set in preferences"

Outset scales too large by a factor of 3.77953.

Steps to reproduce:
Use document having mm as display units and scale of 1.
Create square rectangle object having no stroke and sides of 10mm.
Set Outset preference to steps of 2mm.
Apply outset to 10mm square, with result of 25.117mm sides.
(Expected size would be 14mm on W & H.)

Use document having mm as display units and scale of 3.77953.
Create rectangle object having no stroke and sides of 10mmSq.
Set Outset preference to steps of 2mm.
Apply outset to 10mm square, with result of 14mm.

(15.117/4=3.779525)

Regards,
TD

Issue also seems to affect creation of fonts.

Fonts created using the default.svg are small in relation to original paths. Fonts created using units=px and scale=1 are same size.

Attached example of correct glyph size with units=px and scale=1.

Likely related to new report:
https://bugs.launchpad.net/inkscape/+bug/1688997
"Scale issues on cli export"

TD

This issue seems to also affect the stroke style modified by percentage:

New report:
https://bugs.launchpad.net/inkscape/+bug/1670913
"Scaling stroke width by percentage gives wrong stroke width"

Recent(ish) report:
https://bugs.launchpad.net/inkscape/+bug/1673096
"Stroke width can not be adjusted in percent from Stroke style tab"

TD