On Wed, Sep 25, 2013 at 02:54:40PM -0700, ian_bruce@...2136... wrote:
On Wed, 25 Sep 2013 11:23:07 -0700 Bryce Harrington <bryce@...961...> wrote:
Really, there are (at least) three different ways the unit system touches the real world.
The improvement is to let the user explicitly specify the three ratios between screen/drawing/export units (although this obviously involves only two degrees of freedom). "Export" would mean PDF or similar, if the image was intended for paper, or PNG/JPG/GIF, if it was intended for electronic display.
Yes, looks like we're thinking along the same lines. I've some larger thoughts about stuff that we could consider building atop this some day, which I'll outline below.
The "zoom factor" setting would still be present; this would be multiplied with the "screen units" setting when displaying the document on a monitor, so that 100% zoom would produce the specified screen:drawing unit ratio. It would have no effect on the drawing:export unit ratio.
I think that if this factor is not literally exactly the % zoom as shown in the dropdown dialog in the UI, then we should come up with some other terminology, to avoid confusion.
First is the physical measurements of the page. For instance, if you're going to fold a 8.5"x11" paper into forths and want a logo to appear in the middle of the cover, you're going to care about seeing position in document inches.
In this case, you would set the drawing:export ratio at 1:1 , so that the measurements would come out right in the PDF or PostScript file.
The screen:drawing ratio can be set to any value that is convenient for working on the document, without having any effect on the eventual paper image.
Right.
Second is the physical measurement of the monitor. If you're making assets for a website or buttons for a cell phone UI, you'll care about display pixels, display mm's, etc. and probably don't care about paper at all. It's possible you care about the dpi of some product display that you don't have access to (so don't just assume the attached monitor's dpi is the one the user cares about.)
Here again, you would set the drawing:export ratio at 1:1 , specified in either "px" or "mm", depending on how you wanted to measure the image.
The screen:drawing ratio could also be set at 1:1 , if this provided an appropriate view of the image, or some larger value, for detailed work on icons, etc.
Yep.
I've had some vague thoughts that maybe this could benefit from allowing multiple factors, for like if you're designing for multiple website screen sizes, or for multiple cell phone displays. I'm a bit hand wavey about how this might work, but I guess it'd be like laying out your UI and then toggling different screen sizes and then [insert something interesting happening].
Third is the physical measurement of the thing the drawing is conceiving. If you're drawing a map, then you'll care about km's and miles. You may care about how many printed page inches or cm's correspond to how many miles or km's.
In this case you would set the drawing:export ratio at 1km:3cm , or 5miles:2inches , or something like that.
Right.
If the screen:export ratio is set to 1:1 , the drawing should appear on the monitor at the same size as it eventually will on a paper map, or whatever the target output is.
Sounds good. I'm sure there are situations where this attribute will be valuable to users.
Personally, this third use case is the one I care about, but when I was doing the original units system it became clear that the SVG spec cared mostly about the first one, and somewhat the second, and it wasn't at all clear how to handle the third.
It seems to me that <g transform="scale(x)"> nodes, possibly with Inkscape-specific attributes, could be used to control the relationship between document/image/display units, for the SVG tree, but this would require further thought.
That seems sensible.
This could permit having multiple unit systems in the drawing itself, each under a different <g>. So I guess for example, we can imagine a road map at scale 100km:1cm, but which includes highlight bubbles (perhaps rotated 90° to the main map) showing details of a few towns at a closer scale of 1km:1cm.
Or on an engineering drawing, you could imagine having automatic dimensions attached to a drawing object, which display the scaled units. And this could include close-up views of key details, also using automatic dimensions which are shown in the rightly scaled units.
I could also imagine this being used with layers, where one layer displays in one unit system, another layer on another.
Indeed, it seems there is even difficulty in trying to make it handle #1 and #2 in a user-intuitive way. At the least, it all made me very confused.
Leaving aside for the moment the question of how to do this in an SVG-compliant way, does my proposal above (and attached image) make sense to you? Does it adequately address the situations you've described, or any others that you can think of?
We're on the same page. The UI we should probably iterate on more though; your image looks okay conceptually but I'm thinking it will need to support arbitrary numbers of unit systems, for cases like the ones I outlined above.
Also, from a user point of view an idea I've kicked around is that rather than enter a scaling factor on some dialog, an intuitive usage would be to draw a rectangle on the document surface, select it and then in its object properties declare it to be 15 feet wide. Inkscape would then calculate the appropriate scaling factor off this for me (maybe I could still review and tweak it on a dialog somewhere.) Something like that.
I wonder if perhaps what we should do here is ignore SVG's units and consider the three (or more) use cases that users have, and think from their POV what would work best.
I agree with that. Decide first what the Inkscape UI should be like, and how it should control exported image sizes, and figure out later how to map that onto standard (or proposed, as <tavmjong@...8...> says) SVG.
Sounds good. We should also survey how other apps do this, since this may well be a problem someone else has already come up with a good design for.
Establish different unit systems "modes" and let the user toggle which units mode to use in the Inkscape UI while drawing.
Does it really require "modes", or does allowing the user to explicitly control the screen/drawing/export unit ratios provide all the control that is actually needed?
Well, I'm just thinking that Inkscape's going to show coordinates as something like (50mm, 250mm), but we need some way to make it obvious to the user whether those measurements are in reference to the screen, the printed page, or the real world.
Bryce