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.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net 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

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 <mschafer@...2596...> 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.cl...

...

---

Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net 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.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

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.

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 mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

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 mathog@...1176... 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.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

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 mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

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

-- View this message in context: http://inkscape.13.x6.nabble.com/Units-in-Inkscape-tp4971507p4971526.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.

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

On 12-Sep-2014 09:32, Tavmjong Bah wrote:

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

The example:

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

Is insufficient. Must the numbers in the viewBox match those in the width? In other graphics formats that isn't the case (see below). Can't tell from this svg example. The example could be more like this (for A4 paper):

<svg width="210mm" height="297mm" viewBox="0 0 2100 2970"> <g style="fill:#ff0000;stroke:none" > <g transform="scale(2)"> <rect x="10" y="20" width="50" height="100" /> <rect x="250" y="350" width="25" height="50" /> </g> <rect x="200" y="300" width="250" height="500" /> </g> </svg>

NOW, what happens if the user changes units from mm to in? If this was Microsoft's EMF format after that change the equivalent would be:

<svg width="8.267in" height="11.692mm" viewBox="0 0 2100 2970"> (no other change)

See for instance the description of the metafile header here:

http://msdn.microsoft.com/en-us/library/windows/desktop/dd162607%28v=vs.85%2...

where the drawing resolution is set by szlDevice and its physical size by szlMillimeters. They later added szlMicrometers for better precision on the latter, although in most files one encounters they differ by only a perfect factor of 1000. (Further on in the file it is commmon to run into other transforms including some mapping viewports onto windowextents.) The EMF format does not worry about what happens if a program chooses to show the physical units in inches instead of mm, that isn't anything it cares about. All it cares about is the internal precision and the physical size, with the latter always being in metric units. That said, there is a "SETMAPMODE" record in which the internals of the drawing can be in inches or "twips". However, documents that actually use these other modes are exceedingly rare.

Back to SVG. If the numbers in the viewBox need not match the numbers in the width/height, there is an implicit transform at the top of the SVG document, which converts from arbitrary internal units to defined external physical dimensions. If they must match then there is no such transform - and the reader needs to see how that plays out too. Explicitly.

Regards,

David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech

On 12-9-2014 15:11, LucaDC wrote:

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.

Going on a trip for few days, so just a quick answer.

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

That is already bad. The default template does not contain units. If you open a document, go to document props and click around a bit, then units should show up in width/height. Then try again what you did and see if it works better. The fix is easy: fix default templates + fix setting units on documents without units set. I believe, currently, changing document units ("Default units" should be renamed to "Document units") does not add units if they were not there.

regards, Johan

On 12-9-2014 18:49, LucaDC wrote:

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.

No, the page size should stay the same. One way to do that is to maintain width=100mm, and recalculate the viewbox (this is what Inkscape does now). Then indeed all the values in the document should be changed into inches.

-Johan

I had the page size specified in px. Changed to mm and width and height become 210mm and 297mm as expected:

width="210mm" height="297mm" viewBox="0 0 210 297"

But all the remaining problems in the file are still there (guides in px, rect coords upside-down) so to me Inkscape is not behaving as described.

Luca

-- View this message in context: http://inkscape.13.x6.nabble.com/Units-in-Inkscape-tp4971507p4971548.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.

Oh, that's clear now. I missed the "changing" and took it for "change". Thanks.

Luca

-- View this message in context: http://inkscape.13.x6.nabble.com/Units-in-Inkscape-tp4971507p4971549.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.