Units in Inkscape

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Units in Inkscape

Tavmjong Bah

                       Units in Inkscape
                       =================

Introduction
-----------

The recent debate about units in Inkscape highlights the fact that we do
not have a clearly defined approach on how to handle units in Inkscape.
Units are not as straight-forward as one should think they are. This
essay attempts to resolve this problem.

Historical View
---------------

Part of the problem with units in SVG and CSS in general is why they are
there in the first place. In the early days it was assumed that one
would want to display drawings on a screen at full scale. In other
words, a "one inch square" would be display on a screen as a physical
one inch square. This required that displays be queryable as to what
there true DPI was. Display manufactures rarely provided the means to
query the DPI of the display, and when they did, they often returned
incorrect results. Thus, the use of "real" units never became popular
and in reality is usually not what one wanted. Eventually, after long
arguments, the CSS working group dictated that one inch would be fixed
to 96 pixels regardless of screen resolution (ironically, with so called
"Retina" displays, there is once again interest in scaling drawings
based on DPI).


A Philosophy
------------

Absolute units should not be used inside an SVG file with one exception:

The 'root' width and height may have units, which with a proper
'viewBox' determines an appropriate scale for a drawing. (This sets the
'real' world value of the SVG 'user unit.) This reflect the opinion of
the majority of the SVG working group.

It should be noted that the relative units 'em', 'ex', and '%' can be
useful in some cases.


Inkscape & Units
----------------

Inkscape should not write out absolute units other than in the root SVG
element. Inkscape must, however, be able to interpret units from
non-Inkscape produced files according to the CSS defined value of 96
pixels (initial user-units) per inch.

The use of units in the Inkscape GUI is for ease of authoring only. The
actual values should be stored as 'user-units'.

Changing the "Inkscape GUI unit" should not introduce any 'transforms'
on elements (as seems to being done now) nor should changing the SVG
root 'width'/'height units or the 'viewBox'.

The GUI should reflect the chosen Inkscape GUI unit scaled to take into
account the SVG root 'width'/'height' and 'viewBox'.


For example:

<svg width="100mm" height="100mm" viewBox="0 0 100 100">

describes a drawing 100mm x 100mm where one 'user-unit' is equivalent to
one mm.

If the Inkscape property inkscape:document-units="mm" then the GUI would
show a width of '25.4' for a rectangle 25.4 'user-units' wide. If
inkscape:document-units="in", the GUI would show '1.0'.


To implement this, one either needs to find the proper scaling from
examining the SVG root 'width'/'height' and 'viewBox' properties or
create a new Inkscape property that fixes this scale (in which case
changing the 'width'/'height' would change the 'viewBox' and vice
versa).


Tav











------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Units in Inkscape

Mark Schafer
In Inkscape - can you have multiple Viewboxes ?
If so how should it be interpreted ?

On 9/12/2014 12:58 AM, Tavmjong Bah wrote:

>                         Units in Inkscape
>                         =================
>
> Introduction
> -----------
>
> The recent debate about units in Inkscape highlights the fact that we do
> not have a clearly defined approach on how to handle units in Inkscape.
> Units are not as straight-forward as one should think they are. This
> essay attempts to resolve this problem.
>
> Historical View
> ---------------
>
> Part of the problem with units in SVG and CSS in general is why they are
> there in the first place. In the early days it was assumed that one
> would want to display drawings on a screen at full scale. In other
> words, a "one inch square" would be display on a screen as a physical
> one inch square. This required that displays be queryable as to what
> there true DPI was. Display manufactures rarely provided the means to
> query the DPI of the display, and when they did, they often returned
> incorrect results. Thus, the use of "real" units never became popular
> and in reality is usually not what one wanted. Eventually, after long
> arguments, the CSS working group dictated that one inch would be fixed
> to 96 pixels regardless of screen resolution (ironically, with so called
> "Retina" displays, there is once again interest in scaling drawings
> based on DPI).
>
>
> A Philosophy
> ------------
>
> Absolute units should not be used inside an SVG file with one exception:
>
> The 'root' width and height may have units, which with a proper
> 'viewBox' determines an appropriate scale for a drawing. (This sets the
> 'real' world value of the SVG 'user unit.) This reflect the opinion of
> the majority of the SVG working group.
>
> It should be noted that the relative units 'em', 'ex', and '%' can be
> useful in some cases.
>
>
> Inkscape & Units
> ----------------
>
> Inkscape should not write out absolute units other than in the root SVG
> element. Inkscape must, however, be able to interpret units from
> non-Inkscape produced files according to the CSS defined value of 96
> pixels (initial user-units) per inch.
>
> The use of units in the Inkscape GUI is for ease of authoring only. The
> actual values should be stored as 'user-units'.
>
> Changing the "Inkscape GUI unit" should not introduce any 'transforms'
> on elements (as seems to being done now) nor should changing the SVG
> root 'width'/'height units or the 'viewBox'.
>
> The GUI should reflect the chosen Inkscape GUI unit scaled to take into
> account the SVG root 'width'/'height' and 'viewBox'.
>
>
> For example:
>
> <svg width="100mm" height="100mm" viewBox="0 0 100 100">
>
> describes a drawing 100mm x 100mm where one 'user-unit' is equivalent to
> one mm.
>
> If the Inkscape property inkscape:document-units="mm" then the GUI would
> show a width of '25.4' for a rectangle 25.4 'user-units' wide. If
> inkscape:document-units="in", the GUI would show '1.0'.
>
>
> To implement this, one either needs to find the proper scaling from
> examining the SVG root 'width'/'height' and 'viewBox' properties or
> create a new Inkscape property that fixes this scale (in which case
> changing the 'width'/'height' would change the 'viewBox' and vice
> versa).
>
>
> Tav
>
>
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Inkscape-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2014.0.4765 / Virus Database: 4015/8192 - Release Date: 09/11/14
>
>


------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Units in Inkscape

Tavmjong Bah
On Fri, 2014-09-12 at 01:15 +1200, Mark Schafer wrote:
> In Inkscape - can you have multiple Viewboxes ?
> If so how should it be interpreted ?

In SVG you can have the 'viewBox' on any element that establish a new
viewport plus a marker, pattern, or view element. See:

http://www.w3.org/TR/SVG/coords.html#ViewBoxAttribute

Effectively, it acts like a transform. Units are not allowed in a
'viewBox'.


> On 9/12/2014 12:58 AM, Tavmjong Bah wrote:
> >                         Units in Inkscape
> >                         =================
> >
> > Introduction
> > -----------
> >
> > The recent debate about units in Inkscape highlights the fact that we do
> > not have a clearly defined approach on how to handle units in Inkscape.
> > Units are not as straight-forward as one should think they are. This
> > essay attempts to resolve this problem.
> >
> > Historical View
> > ---------------
> >
> > Part of the problem with units in SVG and CSS in general is why they are
> > there in the first place. In the early days it was assumed that one
> > would want to display drawings on a screen at full scale. In other
> > words, a "one inch square" would be display on a screen as a physical
> > one inch square. This required that displays be queryable as to what
> > there true DPI was. Display manufactures rarely provided the means to
> > query the DPI of the display, and when they did, they often returned
> > incorrect results. Thus, the use of "real" units never became popular
> > and in reality is usually not what one wanted. Eventually, after long
> > arguments, the CSS working group dictated that one inch would be fixed
> > to 96 pixels regardless of screen resolution (ironically, with so called
> > "Retina" displays, there is once again interest in scaling drawings
> > based on DPI).
> >
> >
> > A Philosophy
> > ------------
> >
> > Absolute units should not be used inside an SVG file with one exception:
> >
> > The 'root' width and height may have units, which with a proper
> > 'viewBox' determines an appropriate scale for a drawing. (This sets the
> > 'real' world value of the SVG 'user unit.) This reflect the opinion of
> > the majority of the SVG working group.
> >
> > It should be noted that the relative units 'em', 'ex', and '%' can be
> > useful in some cases.
> >
> >
> > Inkscape & Units
> > ----------------
> >
> > Inkscape should not write out absolute units other than in the root SVG
> > element. Inkscape must, however, be able to interpret units from
> > non-Inkscape produced files according to the CSS defined value of 96
> > pixels (initial user-units) per inch.
> >
> > The use of units in the Inkscape GUI is for ease of authoring only. The
> > actual values should be stored as 'user-units'.
> >
> > Changing the "Inkscape GUI unit" should not introduce any 'transforms'
> > on elements (as seems to being done now) nor should changing the SVG
> > root 'width'/'height units or the 'viewBox'.
> >
> > The GUI should reflect the chosen Inkscape GUI unit scaled to take into
> > account the SVG root 'width'/'height' and 'viewBox'.
> >
> >
> > For example:
> >
> > <svg width="100mm" height="100mm" viewBox="0 0 100 100">
> >
> > describes a drawing 100mm x 100mm where one 'user-unit' is equivalent to
> > one mm.
> >
> > If the Inkscape property inkscape:document-units="mm" then the GUI would
> > show a width of '25.4' for a rectangle 25.4 'user-units' wide. If
> > inkscape:document-units="in", the GUI would show '1.0'.
> >
> >
> > To implement this, one either needs to find the proper scaling from
> > examining the SVG root 'width'/'height' and 'viewBox' properties or
> > create a new Inkscape property that fixes this scale (in which case
> > changing the 'width'/'height' would change the 'viewBox' and vice
> > versa).
> >
> >
> > Tav
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ------------------------------------------------------------------------------
> > Want excitement?
> > Manually upgrade your production database.
> > When you want reliability, choose Perforce
> > Perforce version control. Predictably reliable.
> > http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Inkscape-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/inkscape-devel
> >
> >
> > -----
> > No virus found in this message.
> > Checked by AVG - www.avg.com
> > Version: 2014.0.4765 / Virus Database: 4015/8192 - Release Date: 09/11/14
> >
> >
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Inkscape-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel



------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Units in Inkscape

Oscar Scheepstra
In reply to this post by Mark Schafer
I know this is not really related, but Mathias Wandel, a Canadian Woodworker did something similar for printing. He developed a really simple program called Big Print that manages to print images with amazing precision on regular printers. This means that he managed to master the "virtual vs real world" proportions...

On 11 September 2014 10:15, Mark Schafer <[hidden email]> wrote:
In Inkscape - can you have multiple Viewboxes ?
If so how should it be interpreted ?

On 9/12/2014 12:58 AM, Tavmjong Bah wrote:
>                         Units in Inkscape
>                         =================
>
> Introduction
> -----------
>
> The recent debate about units in Inkscape highlights the fact that we do
> not have a clearly defined approach on how to handle units in Inkscape.
> Units are not as straight-forward as one should think they are. This
> essay attempts to resolve this problem.
>
> Historical View
> ---------------
>
> Part of the problem with units in SVG and CSS in general is why they are
> there in the first place. In the early days it was assumed that one
> would want to display drawings on a screen at full scale. In other
> words, a "one inch square" would be display on a screen as a physical
> one inch square. This required that displays be queryable as to what
> there true DPI was. Display manufactures rarely provided the means to
> query the DPI of the display, and when they did, they often returned
> incorrect results. Thus, the use of "real" units never became popular
> and in reality is usually not what one wanted. Eventually, after long
> arguments, the CSS working group dictated that one inch would be fixed
> to 96 pixels regardless of screen resolution (ironically, with so called
> "Retina" displays, there is once again interest in scaling drawings
> based on DPI).
>
>
> A Philosophy
> ------------
>
> Absolute units should not be used inside an SVG file with one exception:
>
> The 'root' width and height may have units, which with a proper
> 'viewBox' determines an appropriate scale for a drawing. (This sets the
> 'real' world value of the SVG 'user unit.) This reflect the opinion of
> the majority of the SVG working group.
>
> It should be noted that the relative units 'em', 'ex', and '%' can be
> useful in some cases.
>
>
> Inkscape & Units
> ----------------
>
> Inkscape should not write out absolute units other than in the root SVG
> element. Inkscape must, however, be able to interpret units from
> non-Inkscape produced files according to the CSS defined value of 96
> pixels (initial user-units) per inch.
>
> The use of units in the Inkscape GUI is for ease of authoring only. The
> actual values should be stored as 'user-units'.
>
> Changing the "Inkscape GUI unit" should not introduce any 'transforms'
> on elements (as seems to being done now) nor should changing the SVG
> root 'width'/'height units or the 'viewBox'.
>
> The GUI should reflect the chosen Inkscape GUI unit scaled to take into
> account the SVG root 'width'/'height' and 'viewBox'.
>
>
> For example:
>
> <svg width="100mm" height="100mm" viewBox="0 0 100 100">
>
> describes a drawing 100mm x 100mm where one 'user-unit' is equivalent to
> one mm.
>
> If the Inkscape property inkscape:document-units="mm" then the GUI would
> show a width of '25.4' for a rectangle 25.4 'user-units' wide. If
> inkscape:document-units="in", the GUI would show '1.0'.
>
>
> To implement this, one either needs to find the proper scaling from
> examining the SVG root 'width'/'height' and 'viewBox' properties or
> create a new Inkscape property that fixes this scale (in which case
> changing the 'width'/'height' would change the 'viewBox' and vice
> versa).
>
>
> Tav
>
>
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Inkscape-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2014.0.4765 / Virus Database: 4015/8192 - Release Date: 09/11/14
>
>


------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel



--
Oscar Scheepstra


+55 (11) 99977-0977
 
Oscar Scheepstra on about.me
 
Oscar Scheepstra
about.me/oscar.scheepstra
 

------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Units in Inkscape

LucaDC
In reply to this post by Tavmjong Bah
+1e9 for writing this in such a clear way.

One question for completeness: what is Inkscape implementing now with regard to this "view" and what is not?

Example: I opened a new document in an A4 page with mm as default units. I placed two vertical guides then manually edited their origin positions to 10,110 mm and 110,10 mm (the GUI is all in mm). Then I drew a rectangle between the two origins.
The final file contains:

<svg
   ... blah blah blah

   width="744.09448"    (? not mm and 90 DPI)
   height="1052.3622"    (? not mm and 90 DPI)
   inkscape:version="0.91pre2 r13550"
   viewBox="0 0 210 297"

   ... blah blah blah

  <sodipodi:namedview
     inkscape:document-units="mm"
     units="mm"

   ... blah blah blah

<sodipodi:guide
       orientation="1,0"
       position="35.43307,389.76377"    (? not mm, from bottom left and 90 DPI)
       ...

    <sodipodi:guide
       orientation="1,0"
       position="389.76377,35.43307"    (? not mm from bottom left and 90 DPI)
       ...

And:

<rect
       style= ... blah blah blah
       id="rect3341"
       width="100"
       height="100"
       x="9.999999"    (? why?)
       y="187" />    (? is this 297-110 i.e. from top left?)

It's a mix between mm and non mm and top-down coordinates...
My expectation was to find the numbers I entered inside the file (i.e. 10, 110 and 100) so it seems that there still are some inconsistencies to be fixed.

I use guides a lot to shape my drawings (entering their coordinates in mm) so having objects in mm and guides in px (@ 90 DPI!) is a contradiction and neutralizes all efforts towards precision.

Regards.
Luca
Reply | Threaded
Open this post in threaded view
|

Re: Units in Inkscape

LucaDC
In reply to this post by Tavmjong Bah
Just a clarification: I used the term "precision" in the sense of preserving the user input, that is his intention in generating his document.
It's not a matter of how many digits after the dot Inkscape is able to crunch but just the ability to store 10 as "10" and not as "9.99999999999".
Of course it could happen that the user inputs 7,05 and, due to internal binary float representation, it becomes 7,049999999 but this is another issue that should be fixed by other means (e.g. specifying a 2 digits precision in the output file: try this now!). Let's say that, at least, I expect all input integers to be stored as integers in the file.

Regards
Luca
Reply | Threaded
Open this post in threaded view
|

Re: Units in Inkscape

Chris Lilley
In reply to this post by Tavmjong Bah
Hello Tav,

Thursday, September 11, 2014, 2:58:48 PM, you wrote:


> Absolute units should not be used inside an SVG file with one exception:

> The 'root' width and height may have units, which with a proper
> 'viewBox' determines an appropriate scale for a drawing. (This sets the
> 'real' world value of the SVG 'user unit.) This reflect the opinion of
> the majority of the SVG working group.

> It should be noted that the relative units 'em', 'ex', and '%' can be
> useful in some cases.

Yay, excellent summary. Full agreement.


> Inkscape should not write out absolute units other than in the root SVG
> element. Inkscape must, however, be able to interpret units from
> non-Inkscape produced files according to the CSS defined value of 96
> pixels (initial user-units) per inch.

> The use of units in the Inkscape GUI is for ease of authoring only. The
> actual values should be stored as 'user-units'.

This would be awesome.


--
Best regards,
 Chris                            mailto:[hidden email]


------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Units in Inkscape

mathog
In reply to this post by LucaDC
On 11-Sep-2014 07:50, LucaDC wrote:
> Let's say that, at least, I
> expect all input integers to be stored as integers in the file.

Unfortunately that often turns to be impossible.  Any transform in the
object path can change a "10" into a float like "4.2452... , which has
no exact binary representation.  The transform math is with floats, so
on a 32 bit system there are only ~7 digits of precision.  Every time
the value is transformed, a little more precision is lost.  However,
there are transforms, and then there are transforms.  If the initial
coordinates entered into an object for some length never change, then
the final coordinate is just the result of multiplying all the
transforms above it and then applying the final combined transform to
those coordinates.  If the pixel (internal unit) to units (external
units) conversion is accomplished by a single transform at the viewbox
stage, then changing the units from mm to inches, and back, need not
degrade the precision of the internals of the drawing.  Just that
transform is modified, and the internal coordinates never change.  Doing
it that way, it would be possible to change from pixels, to pixels->mm,
to pixels->in, then back to just pixels, and end up with exactly the
same document as when you started.  That is not the case with Inkscape
at present though, because at each change code runs through the entire
document modifying all of the coordinates and lengths, and this degrades
the precision at each conversion.

As an aside in some very special instances it is possible to check for
this sort of precision problem and snap the units back to what they
should be.  For instance, in EMF import clipping there is an "exclude
clip operation".  SVG doesn't have an exact equivalent, so the clip is
emulated by drawing a huge square with the four corners at
{+-faraway,+-faraway}, where "faraway" is a very large integer which
should be outside any sane drawing, and then  the actual clip path in
the opposite direction within it.  This makes a subtractive clipping
object.  At present "faraway" is 10000000 - pixels.  Later in the import
process the entire image is scaled to produce an SVG drawing in mm, and
this slightly reduces the precision of the "faraway" corners.  If the
image is then emitted back to EMF the output driver sees coordinates
like 9999823 (made up number, something like that).  In this case though
the code looks for coordinates that are within a rounding error of
{+-faraway,+-faraway} and snaps them to that exact value.  This allows
clipped drawings to be read in and written out by inkscape from/to EMF
without the values wandering.

In general though, there is no way of knowing what any coordinate {x,y}
is supposed to be with absolute precision, so no way to correct back to
those exact values.  This is why Inkscape should do everything it can to
NOT change the base lengths and coordinates within the document when it
changes the document units.  Instead it does exactly the opposite.

Regards,

David Mathog
[hidden email]
Manager, Sequence Analysis Facility, Biology Division, Caltech

------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Units in Inkscape

Nathan Hurst
In reply to this post by LucaDC
I think the term you want is 'rounding'.  If you have enough internal
precision then rounding will get you want you want.

Perhaps we should switch to doubles everywhere?  memory is cheap,
javascript means that double performance is already core to most of
the world.

njh

On Thu, Sep 11, 2014 at 07:50:18AM -0700, LucaDC wrote:

> Just a clarification: I used the term "precision" in the sense of preserving
> the user input, that is his intention in generating his document.
> It's not a matter of how many digits after the dot Inkscape is able to
> crunch but just the ability to store 10 as "10" and not as "9.99999999999".
> Of course it could happen that the user inputs 7,05 and, due to internal
> binary float representation, it becomes 7,049999999 but this is another
> issue that should be fixed by other means (e.g. specifying a 2 digits
> precision in the output file: try this now!). Let's say that, at least, I
> expect all input integers to be stored as integers in the file.
>
> Regards
> Luca
>
>
>
>
> --
> View this message in context: http://inkscape.13.x6.nabble.com/Units-in-Inkscape-tp4971507p4971513.html
> Sent from the Inkscape - Dev mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Inkscape-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel

------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Units in Inkscape

Nathan Hurst
In reply to this post by mathog
Ok, that's another vote for using double precision everywhere.  That
gets us 14-15 digits, which should be enough for anybody.

njh

On Thu, Sep 11, 2014 at 09:43:03AM -0700, mathog wrote:

> On 11-Sep-2014 07:50, LucaDC wrote:
> > Let's say that, at least, I
> > expect all input integers to be stored as integers in the file.
>
> Unfortunately that often turns to be impossible.  Any transform in the
> object path can change a "10" into a float like "4.2452... , which has
> no exact binary representation.  The transform math is with floats, so
> on a 32 bit system there are only ~7 digits of precision.  Every time
> the value is transformed, a little more precision is lost.  However,
> there are transforms, and then there are transforms.  If the initial
> coordinates entered into an object for some length never change, then
> the final coordinate is just the result of multiplying all the
> transforms above it and then applying the final combined transform to
> those coordinates.  If the pixel (internal unit) to units (external
> units) conversion is accomplished by a single transform at the viewbox
> stage, then changing the units from mm to inches, and back, need not
> degrade the precision of the internals of the drawing.  Just that
> transform is modified, and the internal coordinates never change.  Doing
> it that way, it would be possible to change from pixels, to pixels->mm,
> to pixels->in, then back to just pixels, and end up with exactly the
> same document as when you started.  That is not the case with Inkscape
> at present though, because at each change code runs through the entire
> document modifying all of the coordinates and lengths, and this degrades
> the precision at each conversion.
>
> As an aside in some very special instances it is possible to check for
> this sort of precision problem and snap the units back to what they
> should be.  For instance, in EMF import clipping there is an "exclude
> clip operation".  SVG doesn't have an exact equivalent, so the clip is
> emulated by drawing a huge square with the four corners at
> {+-faraway,+-faraway}, where "faraway" is a very large integer which
> should be outside any sane drawing, and then  the actual clip path in
> the opposite direction within it.  This makes a subtractive clipping
> object.  At present "faraway" is 10000000 - pixels.  Later in the import
> process the entire image is scaled to produce an SVG drawing in mm, and
> this slightly reduces the precision of the "faraway" corners.  If the
> image is then emitted back to EMF the output driver sees coordinates
> like 9999823 (made up number, something like that).  In this case though
> the code looks for coordinates that are within a rounding error of
> {+-faraway,+-faraway} and snaps them to that exact value.  This allows
> clipped drawings to be read in and written out by inkscape from/to EMF
> without the values wandering.
>
> In general though, there is no way of knowing what any coordinate {x,y}
> is supposed to be with absolute precision, so no way to correct back to
> those exact values.  This is why Inkscape should do everything it can to
> NOT change the base lengths and coordinates within the document when it
> changes the document units.  Instead it does exactly the opposite.
>
> Regards,
>
> David Mathog
> [hidden email]
> Manager, Sequence Analysis Facility, Biology Division, Caltech
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Inkscape-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel

------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Units in Inkscape

mathog
In reply to this post by Tavmjong Bah
On 11-Sep-2014 10:23, Nathan Hurst wrote:
> Ok, that's another vote for using double precision everywhere.  That
> gets us 14-15 digits, which should be enough for anybody.

Adding more digits to the numerical representation does not in itself
provide numerical stability, it just makes it easier to sweep the
problem under the carpet of "looking at a smallish number of digits".

Conversely, at least with respect to this units question, numerical
stability, which for the purposes of this conversation means when a diff
of two SVG's shows no changes, can be achieved if the lengths and
coordinates inside the document are never changed, instead only one
transform (or its equivalent) at the top level is.  Then an end user
could flip endlessly between different document units and never corrupt
the numerical representations in the drawing.  The only change that
would show up, if no other changes were made, would be the values for
that one transform.

This assumes that the code did this:

   "we are currently using mm, user wants inches, REPLACE document unit
transform
    with the pixels to inch transform"

If instead it did:

   "we are currently using mm, user wants inches, MULTIPLY document
transform
   by mm to inches conversion"

then the single unit transform itself might not be numerically stable.  
(It could be if all of the units scaling factors have terminating binary
representations with precision to spare, and the same is true for all
combinations of their products.)

Regards,

David Mathog
[hidden email]
Manager, Sequence Analysis Facility, Biology Division, Caltech


------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Units in Inkscape

Johan Engelen-4
In reply to this post by Tavmjong Bah
On 11-9-2014 14:58, Tavmjong Bah wrote:
>                         Units in Inkscape
>                         =================
>
> Introduction
> -----------
>
> The recent debate about units in Inkscape highlights the fact that we do not have a clearly defined approach on how to handle units in Inkscape. Units are not as straight-forward as one should think they are. This essay attempts to resolve this problem.

This is not true, from my point of view.
We had and have a very clearly defined approach to units. This was
implemented as part of a GSoC project last year, and has not changed.
The approach has been communicated several times on the mailing list.
Inkscape is behaving exactly as you write in your email. If it is not,
it is a bug, and we are aware of some of them.

Some issues that we are aware of for a long time now (you touch upon
some of them in your mail):
- explicit units in certain areas (font size, stroke width, ...)
- "px" should be renamed
- bugs related to toplevel width/height specs without units (e.g. in our
default document template) or it going out-of-sync with
inkscape:document-units.


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.


On 11-9-2014 14:58, Tavmjong Bah wrote:
> <svg width="100mm" height="100mm" viewBox="0 0 100 100">
>
> describes a drawing 100mm x 100mm where one 'user-unit' is equivalent to
> one mm.
>
> If the Inkscape property inkscape:document-units="mm" then the GUI would show a width of '25.4' for a rectangle 25.4 'user-units' wide. If inkscape:document-units="in", the GUI would show '1.0'.

inkscape:document-units is exactly that: *document* units. Not UI
units.  Although in practice, the default unit in the UI is taken from
inkscape:document-units. If document-units is different from the unit
defined by

<svg width="..." height="..." viewBox="...">

then that is the start of a disaster; it is a bug to allow that to happen.


I do not know why it seems that there is no clear view about how we want
units to behave.
(sorry, I'm pissed off about again a unit discussion where we have to
reiterate the basics)

-Johan

------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Units in Inkscape

mathog
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
[hidden email]
Manager, Sequence Analysis Facility, Biology Division, Caltech

------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Units in Inkscape

Nathan Hurst
In reply to this post by mathog
Actually, with enough extra bits of precision you do indeed get the
right behaviour.  And it's not sweeping anything under the rug, it's
simply accepting that every calculation has a loss of precision.
Conversion between units will cost about 0.5 sp every time, which
seems pretty reasonable.

At the cost of appeal to authority, I've actually implemented quite a
lot of arbitrary precision numerics, so I know what I'm talking about :)

njh

On Thu, Sep 11, 2014 at 01:01:17PM -0700, mathog wrote:

> On 11-Sep-2014 10:23, Nathan Hurst wrote:
> > Ok, that's another vote for using double precision everywhere.  That
> > gets us 14-15 digits, which should be enough for anybody.
>
> Adding more digits to the numerical representation does not in itself
> provide numerical stability, it just makes it easier to sweep the
> problem under the carpet of "looking at a smallish number of digits".
>
> Conversely, at least with respect to this units question, numerical
> stability, which for the purposes of this conversation means when a diff
> of two SVG's shows no changes, can be achieved if the lengths and
> coordinates inside the document are never changed, instead only one
> transform (or its equivalent) at the top level is.  Then an end user
> could flip endlessly between different document units and never corrupt
> the numerical representations in the drawing.  The only change that
> would show up, if no other changes were made, would be the values for
> that one transform.
>
> This assumes that the code did this:
>
>    "we are currently using mm, user wants inches, REPLACE document unit
> transform
>     with the pixels to inch transform"
>
> If instead it did:
>
>    "we are currently using mm, user wants inches, MULTIPLY document
> transform
>    by mm to inches conversion"
>
> then the single unit transform itself might not be numerically stable.  
> (It could be if all of the units scaling factors have terminating binary
> representations with precision to spare, and the same is true for all
> combinations of their products.)
>
> Regards,
>
> David Mathog
> [hidden email]
> Manager, Sequence Analysis Facility, Biology Division, Caltech
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Inkscape-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel

------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Units in Inkscape

LucaDC
In reply to this post by Nathan Hurst
No, you didn't get the point.
I wrote the clarification for who, like you, could misinterpret my observation.
Please read again what I wrote and think a bit more about it before responding.

Luca
Reply | Threaded
Open this post in threaded view
|

Re: Units in Inkscape

LucaDC
In reply to this post by mathog
Your observations are correct but my example is far simpler.
If I drag some guides, set the coordinates manually and draw objects based on that guides, tell me why on earth different numbers should go inside my documents?
Of course if I select all and apply a 76,234% transformation or a skew the situation becomes completely different and I may not want a rounding of 2 digits only anymore.

Luca
Reply | Threaded
Open this post in threaded view
|

Re: Units in Inkscape

LucaDC
In reply to this post by Johan Engelen-4
Johan Engelen-4 wrote
Inkscape is behaving exactly as you write in your email. If it is not,
it is a bug, and we are aware of some of them.
Could you please elaborate this on the example I posted?
Thanks.

Luca
Reply | Threaded
Open this post in threaded view
|

Re: Units in Inkscape

LucaDC
In reply to this post by mathog
mathog wrote
   "we are currently using mm, user wants inches, MULTIPLY document
transform
   by mm to inches conversion"

then the single unit transform itself might not be numerically stable.  
Personally I expect this behavior. I see changing the document unit (not the GUI input and visualization unit) as a deep operation that means that all internal numbers should be recalculated with respect to this new selected unit, if this is really what the user wants.
I see the "document unit" as the user selection about how the numbers should be internally represented.
Of course if you change the document unit having existing objects already created in a different unit, rounding errors could happen in the conversion.
I assume that one usually first selects the document unit and then starts drawing. The document unit is not supposed to change at all during a document lifetime, unless a real need arises and then you should know what you are doing. If this is the case, Tav's description perfectly fits; unless I misinterpreted it and what he meant was that only the root viewbox was going to change and so 1 mm would become 1 inch (this sound so crazy that I feel it can only be a wrong interpretation).

Luca
Reply | Threaded
Open this post in threaded view
|

Re: Units in Inkscape

Tavmjong Bah
In reply to this post by Johan Engelen-4
On Thu, 2014-09-11 at 22:47 +0200, Johan Engelen wrote:

> On 11-9-2014 14:58, Tavmjong Bah wrote:
> >                         Units in Inkscape
> >                         =================
> >
> > Introduction
> > -----------
> >
> > The recent debate about units in Inkscape highlights the fact that we do not have a clearly defined approach on how to handle units in Inkscape. Units are not as straight-forward as one should think they are. This essay attempts to resolve this problem.
>
> This is not true, from my point of view.
> We had and have a very clearly defined approach to units. This was
> implemented as part of a GSoC project last year, and has not changed.
> The approach has been communicated several times on the mailing list.
> Inkscape is behaving exactly as you write in your email. If it is not,
> it is a bug, and we are aware of some of them.

I've just looked back at the mail archives. I can find parts of the
approach described in the emails but it is hard to pick out the overall
philosophy. I have started a wiki page for future reference. Please
review:

http://wiki.inkscape.org/wiki/index.php/Units_In_Inkscape

> Some issues that we are aware of for a long time now (you touch upon
> some of them in your mail):
> - explicit units in certain areas (font size, stroke width, ...)

> - "px" should be renamed

I don't think renaming 'px' is a good idea. While it perhaps was not the
best choice for 'user unit' it is what web developers are use to seeing.

> - bugs related to toplevel width/height specs without units (e.g. in our
> default document template) or it going out-of-sync with
> inkscape:document-units.

I don't really understand the need for 'inkscape:document-units'. Can't
this be determined by looking at the 'width' and/or 'height'? Then there
is no problem with keeping things in sync.

> 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.

I've just run a test on r12558, which should predate David's code
changes. If one creates a rectangle inside a document with

        inkscape:document-units="mm"

and with the preference setting "Store Transformation" set to
"Preserve", a scaling transform is added. This is not what I would
expect.


> On 11-9-2014 14:58, Tavmjong Bah wrote:
> > <svg width="100mm" height="100mm" viewBox="0 0 100 100">
> >
> > describes a drawing 100mm x 100mm where one 'user-unit' is equivalent to
> > one mm.
> >
> > If the Inkscape property inkscape:document-units="mm" then the GUI would show a width of '25.4' for a rectangle 25.4 'user-units' wide. If inkscape:document-units="in", the GUI would show '1.0'.
>
> inkscape:document-units is exactly that: *document* units. Not UI
> units.  Although in practice, the default unit in the UI is taken from
> inkscape:document-units. If document-units is different from the unit
> defined by
>
> <svg width="..." height="..." viewBox="...">
>
> then that is the start of a disaster; it is a bug to allow that to happen.

It can happen with the XML editor...

> I do not know why it seems that there is no clear view about how we want
> units to behave.
> (sorry, I'm pissed off about again a unit discussion where we have to
> reiterate the basics)

Relying on collective memory of long email threads from the past is not
the best way to preserve a clear view. Hopefully, the Wiki page I
started will help.

Tav




------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Inkscape-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Reply | Threaded
Open this post in threaded view
|

Re: Units in Inkscape

LucaDC
Tav, I'm a bit confused.

>Changing the Inkscape Document unit should not introduce any transforms
>on elements nor should changing the SVG root width/height or the viewBox.

So what should happen to

   <svg width="100mm" height="100mm" viewBox="0 0 100 100">

when the "Inkscape Document unit" is changed to inches?
Is it going to become

   <svg width="100in" height="100in" viewBox="0 0 100 100">

and hence 1 mm becomes 1 in? If so a 3,937% scaling must be applied to the whole document to get a unit change while preserving the original physical dimensions. Are you saying that one should (or may want to) apply this scaling manually after changing the document unit?

For sure if the "Inkscape Document unit" has been changed something must happen somewhere.
12