Re: [Inkscape-devel] Units / display scale factor
Bryce,
Is it possible to just set the amount of pixels per unit in Inkscape?
The use case is as follows.
I have a work flow that uses files created in Inkscape and I want to use 10px per mm. Why? Well,.. that way I can easily use these files in a web site editor where clients can edit the file and give it back to me.
At this moment I have to contend with the insane 3.45etc. pixels per mm, bloating my files by a factor 9 or so and conversion errors on their way back into Inkscape that goes all Inches again. Writing a script for that is hell and it makes operations on the browser client a tad slow as it has to contend with constant conversions from 3.45etc. to wanted scale, to back to Inkscape hardcoded 90pdi, back to mm etc. Relations get lost and anyone manually checking the SVG code cracks his head (okay, 12mm border on a A4 page, so the x,y should be where again? 3.45etc. and that times 12, makes..ehm. Okay,.. calc,.. calc,.. now the right side should be exactly..duh). Would be so nice if it was just 120 left and 1980 right. I can dream those numbers and checking that is easy. My code would start making sense and I have no conversion loss.
This whole sad nonsense would be over if I could just use a pixel / unit setting in Inkscape that allows me to define exactly how many pixels I want to use in the SVG file for what amount of unit. Wouldn't matter if those would be Inches, Meters, Zorkmits or whatever as long as I can define those lengths somewhere.
I would think that for vector graphics, a pixel per unit setting should be fairly straightforward and we can prevent this hapless Inches to mm or whatever conversion swapping, work at much better precision (integers!), probably speed up things a bit with it and lo and behold create a wee bit cleaner files. For people that make icons it would be nice as well I bet to be able to set a 10 px:1 pixel ratio and have nice clean files.
For anyone in the metric system, using a pixel per metric unit setting would be an absolute bliss. I could finally read my files and I would think that viewPort settings are intended to do just this. Define the friggin scale it is in.
Cheers, Jelle Mulder
Message: 4 Date: Wed, 25 Sep 2013 14:54:40 -0700 From: <ian_bruce@...2136...> Subject: Re: [Inkscape-devel] Units / display scale factor To: Bryce Harrington <bryce@...961...> Cc: inkscape-devel@lists.sourceforge.net Message-ID: <20130925145440.7405c192.ian_bruce@...2136...> Content-Type: text/plain; charset="us-ascii"
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.
Thanks for this well-thought-out explanation; it clarifies the situation considerably.
I think a modified version of my "display scale factor" proposal can accommodate all the cases you describe; see attached image.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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?
-- Ian Bruce
Hi Jelle,
For Inkscape trunk there is a units.xml file in /usr/share/inkscape/ui/ where the scaling factors are specified.
I think there's some limits for how much tweaking can be done currently, which is why we're discussing ideas to make it more flexible. Thanks for explaining your use case in detail, we should ensure it can handle cases like what you described.
Bryce
On Thu, Sep 26, 2013 at 05:50:47AM +0200, Jelle wrote:
Bryce,
Is it possible to just set the amount of pixels per unit in Inkscape?
The use case is as follows.
I have a work flow that uses files created in Inkscape and I want to use 10px per mm. Why? Well,.. that way I can easily use these files in a web site editor where clients can edit the file and give it back to me.
At this moment I have to contend with the insane 3.45etc. pixels per mm, bloating my files by a factor 9 or so and conversion errors on their way back into Inkscape that goes all Inches again. Writing a script for that is hell and it makes operations on the browser client a tad slow as it has to contend with constant conversions from 3.45etc. to wanted scale, to back to Inkscape hardcoded 90pdi, back to mm etc. Relations get lost and anyone manually checking the SVG code cracks his head (okay, 12mm border on a A4 page, so the x,y should be where again? 3.45etc. and that times 12, makes..ehm. Okay,.. calc,.. calc,.. now the right side should be exactly..duh). Would be so nice if it was just 120 left and 1980 right. I can dream those numbers and checking that is easy. My code would start making sense and I have no conversion loss.
This whole sad nonsense would be over if I could just use a pixel / unit setting in Inkscape that allows me to define exactly how many pixels I want to use in the SVG file for what amount of unit. Wouldn't matter if those would be Inches, Meters, Zorkmits or whatever as long as I can define those lengths somewhere.
I would think that for vector graphics, a pixel per unit setting should be fairly straightforward and we can prevent this hapless Inches to mm or whatever conversion swapping, work at much better precision (integers!), probably speed up things a bit with it and lo and behold create a wee bit cleaner files. For people that make icons it would be nice as well I bet to be able to set a 10 px:1 pixel ratio and have nice clean files.
For anyone in the metric system, using a pixel per metric unit setting would be an absolute bliss. I could finally read my files and I would think that viewPort settings are intended to do just this. Define the friggin scale it is in.
Cheers, Jelle Mulder
Message: 4 Date: Wed, 25 Sep 2013 14:54:40 -0700 From: <ian_bruce@...2136...> Subject: Re: [Inkscape-devel] Units / display scale factor To: Bryce Harrington <bryce@...961...> Cc: inkscape-devel@lists.sourceforge.net Message-ID: <20130925145440.7405c192.ian_bruce@...2136...> Content-Type: text/plain; charset="us-ascii"
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.
Thanks for this well-thought-out explanation; it clarifies the situation considerably.
I think a modified version of my "display scale factor" proposal can accommodate all the cases you describe; see attached image.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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?
-- Ian Bruce
participants (2)
-
Bryce Harrington -
Jelle