Yes, templates should be fixed. I had a quick look but didn't see an easy fix (need to wade through the template code). I probably won't have time to look into it seriously until the end of the month. If the 'viewBox' and the 'width' and 'height' are off, that will cause problems. I also need to understand the purpose of the 'inkscape:document-units' property.

Tav

On Tue, 2014-08-05 at 14:47 +0200, su_v wrote:

On 2014-08-05 13:29 , Tavmjong Bah wrote:

...

The experimental branch has been using 96 pixels per inch per the CSS 2.1 standard for over two months now without complaint. Is there any objection to switching trunk to this value? As Inkscape has switched to using 'pt' for text size by default, it is important that this change happen to ensure that the size of text rendered in browsers match the size of text rendered in Inkscape.

I don't use experimental builds often (mostly just to test the path effects), and have no clue about issues the change actually might trigger.

Here's a quick one:

0. launch experimental with default (new) prefs, locale: en_US
1. create a new file via procedural template: 'File > New > Templates > Empty page' (A4, vertical)
2. enable 'Snap to page border'
3. draw a rectangle snapped to the page corners
4. remove stroke from rectangle
5. compare size displayed in rect tool controls bar (px) to size displayed in select tool controls bar (px)

The width and height values unexpectedly differ (they should match).

Note that the procedural template creates the same viewBox size in trunk and experimental: viewBox="0 0 744.09448 1052.3622" I would have expected that with experimental, the viewBox would match the new internal resolution for an A4 page (210mm x 297mm): viewBox="0 0 793.7008 1122.5197"

The custom size of that viewBox attribute is sticky (in experimental), no matter how many variations are applied to default document units and (custom) page size units - with such a file, it's not possible to return to a 1:1 state (in SVG: width / height and viewBox match); the content is always scaled:

6. deselect the rectangle
7. open 'Document Properties' and change default units to 'mm'
8. repeat the comparison (width&height of rect with rect/select tool)

Width and height values (now in 'mm') as shown in the two tool contexts still differ.

The viewBox now has changed to: viewBox="0 0 196.875 278.4375" Expected (?) viewBox value AFAIU would be viewBox="0 0 210 297"

Regards, V

On Tue, 2014-08-05 at 22:10 +0200, Johan Engelen wrote:

On 5-8-2014 21:52, Tavmjong Bah wrote:

...

Yes, templates should be fixed. I had a quick look but didn't see an easy fix (need to wade through the template code). I probably won't have time to look into it seriously until the end of the month. If the 'viewBox' and the 'width' and 'height' are off, that will cause problems. I also need to understand the purpose of the 'inkscape:document-units' property.

In short, 'inkscape:document-units' is what links width/height to the viewBox. height = 297mm width = 210mm viewBox = 0 0 210 297 implies document-units = mm

Should the default.svg file use pixels or mm for width/height? The internationalized versions are about 50:50 mixed.

Tav

The first message in this thread seems not to be in the mailing list. Please post it.

On 18-Sep-2014 06:54, LucaDC wrote:

IMHO each file should adhere to the units related to the page format: A4 is expressed in mm, US Letter is expressed in inches, Icon 16x16 is in px and so on.

...

Tav wrote problems. I also need to understand the purpose of the 'inkscape:document-units' property.

There are two things going on.

1. Defining the size of the document in length units. For that, as Tav pointed out, we have the viewbox. For letter it could be:

<svg width="8.5in" height="11in" viewBox="0 0 816 1056">

After some consideration it seems to me that the viewbox coordinates should come out to 96dpi no matter what the physical length units are. Since they are not integers there is no reason to expand the "precision" by using extra digits, for instance "0 0 8160 10560". By always using 96dpi for the viewBox if the viewBox line was deleted nothing would change. (A viewBox is not really needed to specify the size of the drawing, if the viewBox uses 96 dpi, then it just tells the physical program the physical length units to use - for the same length.)

It would be natural for a letter sized document to be in inches, but there is no reason it could not be in mm, and there are probably applications where that would be useful. Changing from one to the other should be (but is not currently) as simple as changing that one line to:

<svg width="215.9mm" height="279.4mm" viewBox="0 0 816 1056">

and nothing else would need to change withing the document, since its "natural" unit would still be in use at 96dpi. This pixels to units conversion is used on export and import of data from the SVG file, including printing it and sending it to plotters.

2. Defining the length units for the GUI. This would affect what the user sees for cursor position, and any lengths, as in the rectangle drawing too. That would be set by:

inkscape:document-units

This should not affect the rest of the SVG document in any way. This is also broken in places, notably the rectangle drawing tool, which doesn't keep track of all the units/transforms.

Regards,

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

On 18-Sep-2014 10:25, LucaDC wrote:

mathog wrote

...

<svg width="8.5in" height="11in" viewBox="0 0 816 1056"> After some consideration it seems to me that the viewbox coordinates should come out to 96dpi no matter what the physical length units are.

I don't agree. I see no valid reason not to use:

<svg width="8.5in" height="11in" viewBox="0 0 8.5 11"> so all the numbers in the document are going to automatically be in inches and hence very frequently needing only few digits after the dot. Inkscape does not need to know what the numbers it's crunching mean in the physical world, but the user may appreciate having them written inside the file (I do). Please, share your "some consideration". Thanks.

96 dpi was a mistake, that should have been 90. 90 was what Inkscape did before this units work started (and still does if one creates a new drawing and doesn't change the default units). Create a document, draw a rectangle in it, and save it and it will say this:

viewBox="0 0 744.09448 1052.3622"

with no inkscape:units value.

The concept of "all the numbers in the document" being in inches is not generally possible. Long story short, if somebody hands you an SVG file and you read in some part of it:

<rect x="5" y="5" width="3.9" height="1.9"/>

the only way to know that those are inches is to traverse all the way back up the tree, taking each and every transform into account, to get the final numbers. They will only be in inches if the total scaling after all of those transforms is 1:1, which is not generally the case. On a unit change the current code enforces the "only unitary transform" constraint by traversing the tree, changing all of the coordinates and lengths. Which breaks things, because it does not enter defs, so references to defs fall in the wrong places or at the wrong scales. (Sorry to keep harping on this, but these unit related defects keep breaking working code elsewhere in the program. For instance, clipping and pattern fills.)

I guess what really mystifies me is why anybody cares what the numbers look like in the raw SVG. It may be a text file, but that does not mean it is intended for human (end user) consumption. Human interaction with an SVG should be through a viewer (for passive consumption), or an editor (like Inkscape, for composition). So why does it matter if the user units are px, inch, or mm? Are you extracting text from the raw SVG for other purposes, or is the GUI having problems representing the values, in some way, for some unit settings?

Regards,

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

On 18-Sep-2014 13:26, Martin Owens wrote:

On Thu, 2014-09-18 at 11:58 -0700, mathog wrote:

...

I guess what really mystifies me is why anybody cares what the numbers look like in the raw SVG. It may be a text file, but that does not mean it is intended for human (end user) consumption. Human interaction with an SVG should be through a viewer (for passive consumption), or an editor (like Inkscape, for composition). So why does it matter if the user units are px, inch, or mm? Are you extracting text from the raw SVG for other purposes, or is the GUI having problems representing the values, in some way, for some unit settings?

The ASCII/text nature of SVG is quite important mathog.

Convenient, anyway, since it lets us make changes to graphics with a text editor. As for the rest of it, we are not on the same page.

As developers we use this to read and write from our programs easily. As testers we craft documents by hand that break or test features.

check and check. (I do the same thing for some binary formats, and it is much less convenient, since instead of a text editor specially written code must be used to generate and read the files.)

As users we open the text admiringly in an editor and gawk at it's majesty.

Well you might, but that is a behavior I would not expect of a typical end user. I would be very surprised if most of them ever opened an SVG file, except maybe by mistake. (When was the last time you popped open a postscript file to admire its structure?)

And as students learn by looking at our sources, hacking on them, editing the css and playing with templating engines. (do you know how many contracts I've had that involved templating svg documents)

That is developer behavior, not end user behavior. For an end user SVG files are black boxes which contain drawings.

What we shouldn't do; is just assume text files are only machine-readable. XML and similar formats are intended to bridge the gap between human readable and machine readable. Our outputs should aim for machine consistency AND human beauty.

Within limits. The limit that we have exceeded in Inkscape is "breaking things left and right in order to achieve the (developer's) aesthetic goal". The current method of recursively rescaling all coordinates and lengths on a unit change is craziness, because, among other things, it outright breaks SVG files (clipping and pattern fills, for instance, pretty much anything that uses a reference into <defs>). Also its goal of making all user units be in mm (for instance) is only attainable in the most trivial of SVG files - those that contain no scaling, shearing, or skewing transforms. If they do contain such transforms, then yes, the end user can read the initial coordinate/length, but must multiply everything out to see what the actual values are. Aesthetically, my view is that actually transforming coordinates and lengths in place, instead of leaving those values alone and introducing or modifying an explicit transform, obfuscates the structure of the SVG. With an explicit transform the SVG literally says "here we modify the size of this group of objects in such and such a manner". When transforms are applied to coordinates and lengths, but not saved in the document, their presence is hidden.

Making the units human units is a nice thing to do for our human users.

Which human users? I see it as being of limited usefulness for certain developers using certain specific classes of SVG files (those that do not use scaling, skewing or shearing transformations). Barring an Inkscape GUI bug, the SVG user units are entirely invisible for a typical end user (ie, a graphics artist, not an Inkscape developer). The typical end user should neither know nor care what the file's internal units are.

All of that said, I am not averse to letting Inkscape set a user unit to inches or mm or whatever _at document creation_. The problem with the current units implementation is what it does when the units _change_. Once the document exists, changing the default units should not cause any changes outside the viewBox transform, it should leave everything else alone. KISS. That would eliminate a bunch of code, and restore an important behavior that has been lost: changing the defaults units must not break anything in an existing drawing. Ie:

https://bugs.launchpad.net/inkscape/+bug/1287288

When in normal work would an end user really need to change the user units in the drawing? Maybe if they started with the wrong units and wanted to correct that error. It doesn't seem like something they would need to do very much. Conversely an end user might want to change the GUI units more frequently, for instance, to draw a to scale metric object on a letter size page. "Document properties" doesn't really offer a way of changing just the GUI units though, the units there are either for "default" (the user units in the document) or for the page size. If one sets the units in the rectangle tool to "mm" it doesn't carry over to the measurement tool. The only way I see to change both at once is with "default" in "document properties", but that changes "viewbox" and all the coordinates and lengths in the document too. If they have a document with both "mm" and "in" objects there is no way to have everything in the "natural" units, pointless swapping everything back and forth in a situation like that, and probably not their intent to do so.

Why don't we have a separate default GUI units setting?

Regards,

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

On 19-Sep-2014 05:11, Tavmjong Bah wrote:

On Thu, 2014-09-18 at 09:50 -0700, mathog wrote:

...

After some consideration it seems to me that the viewbox coordinates should come out to 96dpi no matter what the physical length units are.

I am sympathetic to this view and that was my initial thinking before discussing it inside the SVG working group. It certainly has the advantage that the use of absolute units ('in', 'cm',) inside the SVG works as naively expected. But there are two disadvantages:

1. To get exact metric values of length you must include units such as

'2mm'. We would need to add this ability to Inkscape.

If "exact" means "terminates nicely in a digital representation" then we could also use a value like 127 dpi, which is 25.4 * 5.

127 * 2 / 25.4 = 10.0 # 2 mm to user units 25.4 * (10/127) = 2 # user units to 2 mm.

Let's see, is there something closer to 96? 25.4*4=101.6 has similar properties. Let's factor 254, and maybe get a little more wiggle room, that is 2 * 127. So this should work well too 25.4*3+12.7 = 88.9. (Numerically 101.6 and 88.9 might have problems, because while the base 10 representations are nice, the base 2 representations are not.)

101.6 * 2 /25.4 = 8.0 88.9 * 2 /25.4 = 7.0

For fractional inches it is a little ugly, adding a couple of digits beyond the decimal, but at least it doesn't run off to an infinite number of base 10 digits:

1.5 * 88.9dpi = 133.35 # 1.5 inches

88.9dpi is very close to the original 90dpi, but of course 90 doesn't have this numerical property even for base 10.

90 * 2 / 25.4 = 7.086614173228...

Using common factors like this gets messy if have to add more representations, but we should probably also add the point, since that is used for fonts. A point is 1/68th of an inch, and 68 is 4 * 17. So ignoring factors of 2, because they only add one or two digits after the decimal place, 12.7 * 17 = 215.9.

215.9 * 2 / 25.4 = 17.0 # 2mm 215.9 * 2 = 431.8 # 2 inches 215.9 * 2 / 68 = 6.35 # 2 pt

We should probably make this dpi value nice in both base 10 and base 2. To do that it would be 17 * 127 = 2159 dpi, or possibly that number divided by some power of 2. None of those come very close to 96 though, 134.9375 and 67.46875 are the closest, but they have enough digits that we could lose precision on multiplication with 32 bit floats.

So maybe 2159 dpi is the magic number?

Why are we trying to use 96? It seems like a pretty arbitrary number. Although I vaguely remember that Batik defaulted to that.

You know, all of this shows why it would be pretty useful to let all length/coordinate values specify a physical unit. At present that is uncommon, but Font-size allows that. If it did not having a user unit that was metric would result in awful values for the font-size, which are usually specified in points. If length/coordinate values had physical units there wouldn't be much reason not to lock the user unit at some arbitrary value (96 or 90 or whatever), because at that point what some of you are trying to accomplish implicitly with all of this user unit code would then be explicit in the SVG. And it would support mixed physical units, which the present approach (full conversion on every change of default units) does not.

Regards,

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

On 19-Sep-2014 10:12, mathog wrote:

A point is 1/68th of an inch

Ack, wrong Pt, that should have been Postscript points, at 1/72 of an inch. That's better, because it factors to 3^2 * 2^3. So 127*3/4 = 95.25 is available, which is pretty close to 96.

Tav just posted that 96dpi is specified by CSS, so there isn't much "point" in this line of argument.

Regards,

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

On Thu, 2014-09-18 at 19:05 +0200, Johan Engelen wrote:

On 18-9-2014 15:54, LucaDC wrote:

...

IMHO each file should adhere to the units related to the page format: A4 is expressed in mm, US Letter is expressed in inches, Icon 16x16 is in px and so on.

+1

I've just converted all the default SVG files (A4) to use 'mm' in the 'experimental' branch. Half of them were already doing so.

The new 'default_px.svg' (A4) file now uses dimensions based on 96px to inch.

Tav

Gez wrote

Why not using (for the default in pixels) something more "screenish" like 1024x768, or even 1024x1024 or something that fits in the average screens at 100%? In that case, if the user wants to create something for print, the format will be obviously wrong and it won't match any generic paper size, so she will have a hint that the page format has to be changed. Then choosing a real world paper size with the right units from the templates will be next step. Users who need always real world paper sizes and units will have to change the default template anyway, so no harm done.

+1

-- View this message in context: http://inkscape.13.x6.nabble.com/Changing-trunk-to-96-pixels-per-inch-tp4971... Sent from the Inkscape - Dev mailing list archive at Nabble.com.

El lun, 22-09-2014 a las 09:48 -0700, mathog escribió:

On 21-Sep-2014 15:38, Gez wrote:

...

Why not using (for the default in pixels) something more "screenish" like 1024x768, or even 1024x1024 or something that fits in the average screens at 100%?

If the drawing size and screen match exactly then the viewed part is 1:1 at 100% and cannot be all displayed on the screen due the window frame, tools, and so forth. The result is that the user has to pan/scroll to reach all parts of the drawing. If they want to see the whole drawing it cannot be at 100% zoom. So it is a bit of a pain to work at that resolution at 100%. If the resulting SVG is then embedded in a web page it will rarely be shown at full screen, although it can be forced to that by opening just the SVG in another window. (Almost, again, the viewer's window frame will remove some of the screen real estate.)

The one place where what you are suggesting is clear win is when the drawing is to be rendered to a bitmap and then presented in a slide show that is frameless. Then all the antialiasing matches up right on the intended pixels.

Sure, maybe I wasn't clear enough. I meant something that fits inside the editing area at 100%. Of course, it's pretty hard today to come up with an average size that fits in every screen keeping a reasonable size on lower resolutions and not looking like a stamp on high res. 1024px was an arbitrary number, and granted it's a bit large for average resolutions.

Anyway, the entire point was to discuss about the A4 size in pixels as a good default. I don't think it is because it's in part a real-world paper size with units that only make sense on a screen.