On Wed, 25 Sep 2013 19:40:00 -0700 Bryce Harrington <bryce@...961...> wrote:
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.
Currently you CANNOT set a zoom factor less than 1% , or greater than 25600% . This makes it quite impossible to use mile- or kilometre- (or nanometre-) scale dimensions. It's also a bit silly that if you want a magnification factor of 100, you have to write this as "10000%".
Presumably the screen:drawing unit ratio would default to 1:1 . If somebody takes the trouble to change this setting, this must be because they WANT "100% zoom" to result in that display scale. Otherwise why would they bother to change the setting, and what would be the point of even having it?
"100% zoom" should mean "the most common and convenient scale for viewing and working on this particular drawing", which may not be 1:1 . If somebody wants that to be 1:1 , they can just leave the screen:drawing ratio at its default setting and forget about it. If this control doesn't adjust the display scale independently of the zoom factor, then it's redundant, and there's no point having it.
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].
How about this: you dimension your drawing either in "px", or some made up unit, "yunits" or "metors" or something. Then you have some control, both in the Inkscape UI and the saved SVG file, which defines that unit relative to either real physical lengths or pixels. If your cell phone display changes size or resolution, you adjust that definition, and the drawing rescales automatically.
That would probably require some extension to the SVG specification, so in the absence of that, perhaps something could be done with "viewBox".
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 90dgr to the main map) showing details of a few towns at a closer scale of 1km:1cm.
It would help if we could introduce a new attribute to specify the default unit for the node it belongs to and all its descendents. So you could write <g unit="km" transform="scale(1.0E-7)"> ... </g> , and specify all the elements of that group in kilometres, without actually using any unit suffix, and the whole thing would display at a scale of 100km:1cm .
The meaning of "km" would have to be defined in "units.xml" or some other place; it isn't in the SVG specification.
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.
A layer is actually just a group with an added Inkscape-specific attribute, so if this is made to work for groups, layers shouldn't be much different.
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.
The intention was that the units in the selection lists would be taken from "units.xml"; if you add a new unit definition there, it shows up automatically in the preferences dialog. I did mention miles and kilometres in my previous message.
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.
What other vector graphics editors are important, or competitive with Inkscape? Adobe Illustrator? Karbon? Xfig? Is XaraLx still relevant?
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.
Next to the object size/position number boxes at the top edge of the Inkscape window, is a selection list which controls which units they are displayed in. We can add another selection list which controls whether the values displayed are relative to the screen, drawing, or export scales.
-- Ian Bruce