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