Hi,
First, congrats to Matthew for some very nice work.
I've just given the latest code a quick test and I've got a few comments. I certainly haven't thought thing through carefully but I would be interested in what others think.
I start by opening a new (from Templates) Letter in landscape mode.
1. The Template dialog tells me I am about to create a 612x792 pixel drawing. But the size of the drawing in the SVG file is set to 11in x 8.5in. Pixels are no where to be seen.
2. I create a default grid. The grid spacing is in "pixels" or 1/90 of an inch. I would expect it to be in fractions of an inch (1/4 or 1/10).
3. I set the grid to 1/4 of an inch with major grid line every 4 lines. Looks good. Now I create a rectangle 1 in x 1 in. Ooops, it is 0.99999988 x 0.99999988 according to the XML dialog.
4. I use the XML dialog to set it to exactly 1 x 1. Hmm, why isn't it 1in x 1in?
5. Ah ha, the viewBox is set to 0, 0, 11, 8.5. This means that the "user unit" aka "px" is equivalent to 1 inch. Maybe this isn't so bad, but it means I can't mix different units inside the SVG file. If I use "1in" for a dimension, it will be interpreted as 90 user units or 90 inches. My 20 "pt" text is stored as 0.277777776px in the SVG file (and shows up as 19.99 in the font-size widget).
My thinking is that it might be better to set the viewBox to 0, 0, 792, 612 and then explicitly use dimensions with "in" if that is what the user wants.
Tav
On 23-9-2013 15:53, Tavmjong Bah wrote:
Hi,
First, congrats to Matthew for some very nice work.
I've just given the latest code a quick test and I've got a few comments. I certainly haven't thought thing through carefully but I would be interested in what others think.
I start by opening a new (from Templates) Letter in landscape mode.
- The Template dialog tells me I am about to create a 612x792 pixel
drawing. But the size of the drawing in the SVG file is set to 11in x 8.5in. Pixels are no where to be seen.
- I create a default grid. The grid spacing is in "pixels" or 1/90 of
an inch. I would expect it to be in fractions of an inch (1/4 or 1/10).
Currently, the default grid has its own unit setting. I agree that doesn't make sense, having a default document unit. I'm not too sure how to solve the issue with unitless default values: with inches, you'd want fractions of inches as default grid spacing, but with pixels I'd doubt that. Anyone have an idea how to resolve this?
- I set the grid to 1/4 of an inch with major grid line every 4 lines.
Looks good. Now I create a rectangle 1 in x 1 in. Ooops, it is 0.99999988 x 0.99999988 according to the XML dialog.
- I use the XML dialog to set it to exactly 1 x 1. Hmm, why isn't it
1in x 1in?
- Ah ha, the viewBox is set to 0, 0, 11, 8.5. This means that the "user
unit" aka "px" is equivalent to 1 inch. Maybe this isn't so bad, but it means I can't mix different units inside the SVG file. If I use "1in" for a dimension, it will be interpreted as 90 user units or 90 inches. My 20 "pt" text is stored as 0.277777776px in the SVG file (and shows up as 19.99 in the font-size widget).
My thinking is that it might be better to set the viewBox to 0, 0, 792, 612 and then explicitly use dimensions with "in" if that is what the user wants.
You know more about SVG than me, but, "user unit" =/= "px" right? I think it is pretty nice that one can now work in mm, and actually read mm values in the SVG. (path data for example) Setting the viewbox to 0, 0, 11, 8.5 in this case allows one to define things in inch values, like a proper document unit, right? It is 1 x 1, because the document unit is inches. No need to specify inches. But indeed, if you would write "1in" it should give the same result in this case. I think that is a bug that it does not do so at the moment.
Mixed unit functionality was intentionally left out for now.
cheers, Johan
On Mon, Sep 23, 2013 at 5:45 PM, Johan Engelen <jbc.engelen@...2592...>wrote:
It is 1 x 1, because the document unit is inches. No need to specify inches. But indeed, if you would write "1in" it should give the same result in this case. I think that is a bug that it does not do so at the moment.
Mixed unit functionality was intentionally left out for now.
You're right; it is a bug. It's a result of Inkscape using a fixed pixel to real world unit ratio. Per my reading of the SVG spec, the SVG user agent should determine the size of 1px, i.e. 1 user unit, and set the other unit ratios accordingly. In this case, since the document size is specified in real world units and a viewBox is set, Inkscape should calculate the size of one px from this and set the size of 1in to be 1px. However, Inkscape's current behavior of using a fixed 90px/in ratio is consistent with Firefox, Chrome, GIMP, Eye of GNOME, and gThumb (everything I tested).
-Matthew
On Mon, 23 Sep 2013 23:45:11 +0200 Johan Engelen <jbc.engelen@...2592...> wrote:
You know more about SVG than me, but, "user unit" =/= "px" right?
Here's the relevant quote from the SVG specification:
http://www.w3.org/TR/SVG/coords.html#Units
One px unit is defined to be equal to one user unit. Thus, a length of "5px" is the same as a length of "5".
That seems pretty definitive. "px" is perhaps an unfortunate abbreviation for "user units", because it does NOT mean "pixels":
in most circumstances, "px" units will not map to the device pixel grid.
On Mon, 23 Sep 2013 19:55:54 -0400 Matthew Petroff <inkscape-devel@...2975...> wrote:
It's a result of Inkscape using a fixed pixel to real world unit ratio. Per my reading of the SVG spec, the SVG user agent should determine the size of 1px, i.e. 1 user unit, and set the other unit ratios accordingly. In this case, since the document size is specified in real world units and a viewBox is set, Inkscape should calculate the size of one px from this and set the size of 1in to be 1px. However, Inkscape's current behavior of using a fixed 90px/in ratio is consistent with Firefox, Chrome, GIMP, Eye of GNOME, and gThumb (everything I tested).
Everything else is wrong.
The other absolute unit identifiers from CSS (i.e., pt, pc, cm, mm, in) are all defined as an appropriate multiple of one px unit (which, according to the previous item, is defined to be equal to one user unit), based on what the SVG user agent determines is the size of a px unit (possibly passed from the parent processor or environment at initialization time). For example, suppose that the user agent can determine from its environment that "1px" corresponds to "0.2822222mm" (i.e., 90dpi). Then, for all processing of SVG content:
- "1pt" equals "1.25px" (and therefore 1.25 user units) - "1pc" equals "15px" (and therefore 15 user units) - "1mm" would be "3.543307px" (3.543307 user units) - "1cm" equals "35.43307px" (and therefore 35.43307 user units) - "1in" equals "90px" (and therefore 90 user units)
This "for example" is the only mention of the 90px/in ratio. There is no suggestion that this should be considered a normative value.
It seems rather silly that a vector graphics program would be much concerned with "dpi" or "pixels" anyway, except when exporting to a raster image. Since it's up to the the "SVG user agent" to "determine the size of a px unit", shouldn't Inkscape do so by adopting whatever is specified as the default unit for the document? Doesn't "viewBox" provide for compatibility with the other programs that you mentioned? Why should Inkscape be constrained by their defective interpretation of the SVG specification?
On a somewhat related subject, could you comment on the current significance (after your work) of the "units.txt" and "units.xml" files? When I tested this earlier, these files contained duplicate information, but it seemed that some unit definitions were compiled into the program, and some were taken from "units.txt", whereas "units.xml" had no influence whatsoever.
It would seem to make sense that all unit definitions should be taken from one or more external files, rather than compiled in, so that new or changed definitions could be added easily. If XML was chosen as the file format, this would make it easier to specify the conversion factors between different measurement systems, without having to use seven-digit decimal fractions, as above. See example here:
http://sourceforge.net/mailarchive/message.php?msg_id=30063581
-- Ian Bruce
On a somewhat related subject, could you comment on the current significance (after your work) of the "units.txt" and "units.xml" files? When I tested this earlier, these files contained duplicate information, but it seemed that some unit definitions were compiled into the program, and some were taken from "units.txt", whereas "units.xml" had no influence whatsoever.
The code that reads units.txt was partially migrated to read from XML and then apparently abandoned before the XML parser was fully implemented. I replaced it with a simple GMarkup-based parser, so that now only units.xml is used.
Regards, Krzysztof
On Tue, Sep 24, 2013 at 1:27 AM, <ian_bruce@...2136...> wrote:
On a somewhat related subject, could you comment on the current significance (after your work) of the "units.txt" and "units.xml" files? When I tested this earlier, these files contained duplicate information, but it seemed that some unit definitions were compiled into the program, and some were taken from "units.txt", whereas "units.xml" had no influence whatsoever.
With the exception of SVG I/O code, Inkscape's sole source of unit information is now "units.xml"; "units.txt" has been removed along with all hard-coded unit definitions.
-Matthew
On Tue, 24 Sep 2013 15:10:46 -0400 Matthew Petroff <inkscape-devel@...2975...> wrote:
With the exception of SVG I/O code, Inkscape's sole source of unit information is now "units.xml"; "units.txt" has been removed along with all hard-coded unit definitions.
As of what version is this, or will this be, the case?
What did you think of the hierarchical unit definition format I suggested here:
http://sourceforge.net/mailarchive/message.php?msg_id=30063581
-- such that metric units are defined in relation to metres, and imperial units are defined in relation to yards, and the only relation defined between those systems is [1.0 yards = 0.9144 metres] ?
It may seem like a small thing, but when somebody wants to add new unit definitions, it would be very convenient if they could be specified in relation to the most appropriate existing unit, rather than "px" or something.
-- Ian Bruce
2013/9/24 <ian_bruce@...2136...>:
The other absolute unit identifiers from CSS (i.e., pt, pc, cm, mm, in) are all defined as an appropriate multiple of one px unit (which, according to the previous item, is defined to be equal to one user unit), based on what the SVG user agent determines is the size of a px unit (possibly passed from the parent processor or environment at initialization time). For example, suppose that the user agent can determine from its environment that "1px" corresponds to "0.2822222mm" (i.e., 90dpi). Then, for all processing of SVG content: - "1pt" equals "1.25px" (and therefore 1.25 user units) - "1pc" equals "15px" (and therefore 15 user units) - "1mm" would be "3.543307px" (3.543307 user units) - "1cm" equals "35.43307px" (and therefore 35.43307 user units) - "1in" equals "90px" (and therefore 90 user units)
So it seems that 1px should ideally correspond to 1in / dpi of the monitor. E.g. the units are supposed to map 1:1 to the real world when the document is displayed at 100% zoom.
The px, pc, mm, cm, in ratios are fixed, so it seems like they can be compiled in, while the DPI value could be obtained from the EDID of the monitor. GDK has functions which can be used for this:
gdk_screen_get_monitor_geometry() gdk_screen_get_monitor_height_mm() gdk_screen_get_monitor_width_mm()
Regards, Krzysztof
On 24-9-2013 22:16, Krzysztof Kosiński wrote:
2013/9/24 <ian_bruce@...2136...>:
The other absolute unit identifiers from CSS (i.e., pt, pc, cm, mm, in) are all defined as an appropriate multiple of one px unit (which, according to the previous item, is defined to be equal to one user unit), based on what the SVG user agent determines is the size of a px unit (possibly passed from the parent processor or environment at initialization time). For example, suppose that the user agent can determine from its environment that "1px" corresponds to "0.2822222mm" (i.e., 90dpi). Then, for all processing of SVG content: - "1pt" equals "1.25px" (and therefore 1.25 user units) - "1pc" equals "15px" (and therefore 15 user units) - "1mm" would be "3.543307px" (3.543307 user units) - "1cm" equals "35.43307px" (and therefore 35.43307 user units) - "1in" equals "90px" (and therefore 90 user units)So it seems that 1px should ideally correspond to 1in / dpi of the monitor. E.g. the units are supposed to map 1:1 to the real world when the document is displayed at 100% zoom.
The px, pc, mm, cm, in ratios are fixed, so it seems like they can be compiled in, while the DPI value could be obtained from the EDID of the monitor. GDK has functions which can be used for this:
gdk_screen_get_monitor_geometry() gdk_screen_get_monitor_height_mm() gdk_screen_get_monitor_width_mm()
I interpret the text slightly different. Indeed the name "px" for "user unit" is very unfortunate, and I think for the discussion it would help to not use "px" if it is not clear if "user unit" or "pixels" is meant.
In any case, I believe that the pc, mm, cm, in ratios are fixed (duh ;), but *not* the "px"/"user unit" ratio. The viewbox (together with a defined document height and width in real-world units) defines the ratio of user unit to the other units. In a document without viewbox or with non-real-unit document height&width, we have to resort to some arbitrary/default value. This default value might be what Krzysztof suggests: use whatever DPI the monitor is using. But that will cause non-viewbox documents to be shown with different sizes (mm, in, cm,...) on different machines. Confusing for people perhaps, because the default Inkscape document does not specify the relation between user units and real-world units, and so in that case if someone thinks he is using "mm", he is actually using an ill-defined "mm". I think it is better to have some fall-back dpi value stored in the preferences, so people have better control over it and can handle interoperability better (on documents without proper scale definition).
Now for rendering, I agree that it would be nice if we can map a "1in" rectangle to 1in on-screen. There are some means in Inkscape to do that, but I haven't looked if it uses gdk_screen_get_monitor_geometry() or friends.
I see three possibilities for the "px" unit in our UI: A) "px" in our UI means "user unit". And thus it does *not* mean "pixels". In this case, in a document with viewbox (0,0,10,10), and width=10mm, height=10mm, it means: 1px = 1mm. B) "px" in our UI means "pixel on your current device". And thus "1px" in our UI, does *not* always mean "1px" written in XML/SVG. In this case, in a document with viewbox (0,0,10,10), and width=10in, height=10in, with a 200 dpi monitor, it means: 200px (Inkscape UI) = 1in = "1px" (SVG/XML). C) same as B but with dpi value set in preferences (say, the current 90dpi). I think this is the current state (90dpi "hardcoded" in units.xml).
regards, Johan
Am Dienstag, 24. September 2013, 23:27:50 schrieb Johan Engelen:
On 24-9-2013 22:16, Krzysztof Kosiński wrote:
2013/9/24 <ian_bruce@...2136...>:
The other absolute unit identifiers from CSS (i.e., pt, pc, cm, mm, in) are all defined as an appropriate multiple of one px unit (which, according to the previous item, is defined to be equal to one user unit), based on what the SVG user agent determines is the size of a px unit (possibly passed from the parent processor or environment at initialization time). For example, suppose that the user agent can determine from its environment that "1px" corresponds to "0.2822222mm" (i.e., 90dpi). Then, for all processing of SVG content: - "1pt" equals "1.25px" (and therefore 1.25 user units) - "1pc" equals "15px" (and therefore 15 user units) - "1mm" would be "3.543307px" (3.543307 user units) - "1cm" equals "35.43307px" (and therefore 35.43307 user units) - "1in" equals "90px" (and therefore 90 user units)So it seems that 1px should ideally correspond to 1in / dpi of the monitor. E.g. the units are supposed to map 1:1 to the real world when the document is displayed at 100% zoom.
The px, pc, mm, cm, in ratios are fixed, so it seems like they can be compiled in, while the DPI value could be obtained from the EDID of the monitor. GDK has functions which can be used for this:
gdk_screen_get_monitor_geometry() gdk_screen_get_monitor_height_mm() gdk_screen_get_monitor_width_mm()
[...]
of user unit to the other units. In a document without viewbox or with non-real-unit document height&width, we have to resort to some arbitrary/default value. This default value might be what Krzysztof suggests: use whatever DPI the monitor is using. But that will cause
While you are designing something new I would like to ask you to keep those users in mind that have more than one monitor attached to the computer, using different DPI. This is especially common with laptop + external monitor setups. When moving the Inkscape window from one screen to the other it would be awesome if this ratio could somehow be updated. The technical side to know about the movement is not the problem but I guess a sudden change of px/mm ratio would confuse many parts of the current code base.
Tobias, a thankful user
[...]
On 25-9-2013 0:04, Tobias Ellinghaus wrote:
Am Dienstag, 24. September 2013, 23:27:50 schrieb Johan Engelen:
On 24-9-2013 22:16, Krzysztof Kosiński wrote:
2013/9/24 <ian_bruce@...2136...>:
The other absolute unit identifiers from CSS (i.e., pt, pc, cm, mm, in) are all defined as an appropriate multiple of one px unit (which, according to the previous item, is defined to be equal to one user unit), based on what the SVG user agent determines is the size of a px unit (possibly passed from the parent processor or environment at initialization time). For example, suppose that the user agent can determine from its environment that "1px" corresponds to "0.2822222mm" (i.e., 90dpi). Then, for all processing of SVG content: - "1pt" equals "1.25px" (and therefore 1.25 user units) - "1pc" equals "15px" (and therefore 15 user units) - "1mm" would be "3.543307px" (3.543307 user units) - "1cm" equals "35.43307px" (and therefore 35.43307 user units) - "1in" equals "90px" (and therefore 90 user units)So it seems that 1px should ideally correspond to 1in / dpi of the monitor. E.g. the units are supposed to map 1:1 to the real world when the document is displayed at 100% zoom.
The px, pc, mm, cm, in ratios are fixed, so it seems like they can be compiled in, while the DPI value could be obtained from the EDID of the monitor. GDK has functions which can be used for this:
gdk_screen_get_monitor_geometry() gdk_screen_get_monitor_height_mm() gdk_screen_get_monitor_width_mm()
[...]
of user unit to the other units. In a document without viewbox or with non-real-unit document height&width, we have to resort to some arbitrary/default value. This default value might be what Krzysztof suggests: use whatever DPI the monitor is using. But that will cause
While you are designing something new I would like to ask you to keep those users in mind that have more than one monitor attached to the computer, using different DPI. This is especially common with laptop + external monitor setups. When moving the Inkscape window from one screen to the other it would be awesome if this ratio could somehow be updated. The technical side to know about the movement is not the problem but I guess a sudden change of px/mm ratio would confuse many parts of the current code base.
Do you mean pixel/mm or userunit/mm? ("px" has become very ambiguous for us :S)
-Johan
On 25-9-2013 1:00, Martin Owens wrote:
On Tue, 2013-09-24 at 23:27 +0200, Johan Engelen wrote:
to be shown with different sizes
Yes, but oddly shown to a size that closely matches a real world print out. ;-) Maybe that's not a problem.
Original text for context:
" The viewbox (together with a defined document height and width in real-world units) defines the ratio of user unit to the other units. In a document without viewbox or with non-real-unit document height&width, we have to resort to some arbitrary/default value. This default value might be what Krzysztof suggests: use whatever DPI the monitor is using. But that will cause non-viewbox documents to be shown with different sizes (mm, in, cm,...) on different machines."
What will happen (in the case discussed in that paragraph) is that I draw a rectangle, set the width of that rectangle to 5mm, send the file to a friend, he opens it, draws another rectangle 5mm wide next to it and the sizes will be different. Because the "user units" to real-world units is set according to monitor DPI. This will then also not be close to a realworld printout. I'm arguing that the scheme proposed is not such a good idea. (note compatibility with older files, and default files now that have no proper definition of userunit to real-world)
Cheers, Johan
2013/9/25 Johan Engelen <jbc.engelen@...2592...>:
What will happen (in the case discussed in that paragraph) is that I draw a rectangle, set the width of that rectangle to 5mm, send the file to a friend, he opens it, draws another rectangle 5mm wide next to it and the sizes will be different. Because the "user units" to real-world units is set according to monitor DPI. This will then also not be close to a realworld printout. I'm arguing that the scheme proposed is not such a good idea.
If the rectangle has its sides expressed in mm, and the friend also uses mm to draw the new rectangle, they should have the same size regardless of screen DPI. If the user specifies the rectangle width to be 50 mm, we should write "50mm" to the XML, without converting it to user units. If the rectangle is inside a scaled group, and we want the UI to be independent of this, the width written to the XML should still be in mm, but compensated for the transform.
What would actually be weird is that a document which contains a mix of objects specified with real-world units and pixels would display differently depending on the monitor DPI. On the other hand, this is exactly what the SVG specification says should happen.
The advice in the SVG spec that all lengths except on the toplevel svg:svg element should be in user units does not match our use cases. All lengths should be in the default document unit.
Regards, Krzysztof
On Tue, 24 Sep 2013 23:27:50 +0200 Johan Engelen <jbc.engelen@...2592...> wrote:
On 24-9-2013 22:16, Krzysztof Kosi\u0144ski wrote:
So it seems that 1px should ideally correspond to 1in / dpi of the monitor. E.g. the units are supposed to map 1:1 to the real world when the document is displayed at 100% zoom.
It is surely unsurprising that if somebody chooses to dimension their drawing in inches, millimetres, or kilometres, that these units are supposed to relate to the real world.
However, it is not clear that every drawing needs to be displayed at a real-world scale of 1:1 . If some drawing contains a feature with a dimension of "100 inches", then it is unlikely that the whole thing can ever be displayed at full scale; if the dimension is "100 kilometres", it is clearly impossible.
Rather than interpreting "100% zoom" to mean "display at a real-world scale of 1:1", a better interpretation would be "display the drawing at the most appropriate and convenient scale for viewing and working on it." This will often, but not always, be such that the displayed size of the drawing is approximately the physical size of the monitor.
The author of the document is the best judge of exactly what display scale a zoom setting of 100% should produce, so there ought to be a per-document preference setting to control this.
I believe that the pc, mm, cm, in ratios are fixed (duh ;), but *not* the "px"/"user unit" ratio.
The px/user-unit ratio is very much fixed, at 1:1 , according to the SVG specification. But perhaps by saying "px/user-unit" you meant to suggest not a ratio, but the equivalence of those terms?
The viewbox (together with a defined document height and width in real-world units) defines the ratio of user unit to the other units.
Surely whatever unit is selected as the document default should then be considered equivalent to "user units" and "px", thus defining their ratios to other units?
Unless, of course, "px" is the document default, in which case we need a preference setting, as above, to control what display scale "100% zoom" actually produces.
In a document without viewbox or with non-real-unit document height&width, we have to resort to some arbitrary/default value.
Or an explicit preference setting controlling the ratio of document units to real display units, again at 100% zoom; other zoom factors will rescale the display accordingly.
This default value might be what Krzysztof suggests: use whatever DPI the monitor is using. But that will cause non-viewbox documents to be shown with different sizes (mm, in, cm,...) on different machines.
Monitor DPI is only relevant if the user intends to dimension their drawing in terms of "pixels". Even if they use real physical units, it is not clear that the default display scale should be 1:1 . As I suggested above, if the nominal size of the drawing is on the order of 100 inches, and it's being viewed on a 27-inch monitor, then a zoom setting of 100% should probably NOT produce a real display scale of 1:1 ; it would probably be better to choose a scale such that the borders of the document were aligned with the edges of the monitor.
But the best person to decide this question is the document author, so there should be a preference setting to control it directly.
Confusing for people perhaps, because the default Inkscape document does not specify the relation between user units and real-world units, and so in that case if someone thinks he is using "mm", he is actually using an ill-defined "mm".
If someone thinks they are using millimetres, it would be best if nothing happens to contradict that belief. If there is an explicit "Display Scale Factor" preference setting, they can control whether 100% zoom produces a 1:1 ratio of document millimetres to screen millimetres, or some other value, of their choosing. It's only ill-defined if people are given no way of defining it.
I think it is better to have some fall-back dpi value stored in the preferences, so people have better control over it and can handle interoperability better (on documents without proper scale definition).
"DPI" means "dots (pixels) per inch", and since we've established that SVG "px" have no necessary connection with pixels, it doesn't seem to be a very relevant concept. But as you say, there needs to be something in the preferences, so that people can directly control the default (100% zoom) scale their drawing is displayed with, regardless of what units they use to dimension it.
If it's not already clear, I think that preference setting should directly control the default ratio of document units to physical screen units; this would be multiplied with the zoom factor setting when the document was actually rendered on the display. In addition to "px" and real physical units, it should be possible to select the width or height of both the drawing and the screen; you could then specify that the document should be displayed so that its width (or height) was the same as (or half, or twice) that of the screen.
The PNG image attached to this message shows what such a preference dialog might look like: two number boxes, and two selection lists, to specify the ratio between document units and physical display units.
I have previously posted an extended discussion of these issues, archived here:
http://sourceforge.net/mailarchive/forum.php?thread_name=20121104003312.162f...
-- Ian Bruce
On 25-9-2013 11:39, ian_bruce@...2136... wrote:
On Tue, 24 Sep 2013 23:27:50 +0200 Johan Engelen <jbc.engelen@...2592...> wrote:
I believe that the pc, mm, cm, in ratios are fixed (duh ;), but *not* the "px"/"user unit" ratio.
The px/user-unit ratio is very much fixed, at 1:1 , according to the SVG specification. But perhaps by saying "px/user-unit" you meant to suggest not a ratio, but the equivalence of those terms?
Sorry, confusing. I meant: the "px a.k.a. user-unit" ratio toward the real-world units.
Cheers, Johan
On Wed, Sep 25, 2013 at 02:39:46AM -0700, ian_bruce@...2136... wrote:
On Tue, 24 Sep 2013 23:27:50 +0200 Johan Engelen <jbc.engelen@...2592...> wrote:
On 24-9-2013 22:16, Krzysztof Kosi\u0144ski wrote:
So it seems that 1px should ideally correspond to 1in / dpi of the monitor. E.g. the units are supposed to map 1:1 to the real world when the document is displayed at 100% zoom.
It is surely unsurprising that if somebody chooses to dimension their drawing in inches, millimetres, or kilometres, that these units are supposed to relate to the real world.
However, it is not clear that every drawing needs to be displayed at a real-world scale of 1:1 .
Really, there are (at least) three different ways the unit system touches the real world.
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.
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.)
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.
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. 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.
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. Establish different unit systems "modes" and let the user toggle which units mode to use in the Inkscape UI while drawing.
Bryce
On Wed, 2013-09-25 at 11:23 -0700, Bryce Harrington wrote:
On Wed, Sep 25, 2013 at 02:39:46AM -0700, ian_bruce@...2136... wrote:
On Tue, 24 Sep 2013 23:27:50 +0200 Johan Engelen <jbc.engelen@...2592...> wrote:
On 24-9-2013 22:16, Krzysztof Kosi\u0144ski wrote:
So it seems that 1px should ideally correspond to 1in / dpi of the monitor. E.g. the units are supposed to map 1:1 to the real world when the document is displayed at 100% zoom.
It is surely unsurprising that if somebody chooses to dimension their drawing in inches, millimetres, or kilometres, that these units are supposed to relate to the real world.
However, it is not clear that every drawing needs to be displayed at a real-world scale of 1:1 .
Really, there are (at least) three different ways the unit system touches the real world.
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.
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.)
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.
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. 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.
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. Establish different unit systems "modes" and let the user toggle which units mode to use in the Inkscape UI while drawing.
With SVG 2 there is the possibility to improve the unit situation. Can someone come up with a concrete proposal? I can then bring it to the working group. (I will also be thinking about this when I get a chance.)
A couple of notes:
I believe that we require "px" explicitly when writing out "font-size". There is a note in the code about this.
The whole concept of "px" is confused by the various screen resolutions out there. I know that the CSS working group is struggling with this.
Tav
On Wed, Sep 25, 2013 at 08:46:06PM +0200, Tavmjong Bah wrote:
On Wed, 2013-09-25 at 11:23 -0700, Bryce Harrington wrote:
On Wed, Sep 25, 2013 at 02:39:46AM -0700, ian_bruce@...2136... wrote:
On Tue, 24 Sep 2013 23:27:50 +0200 Johan Engelen <jbc.engelen@...2592...> wrote:
On 24-9-2013 22:16, Krzysztof Kosi\u0144ski wrote:
So it seems that 1px should ideally correspond to 1in / dpi of the monitor. E.g. the units are supposed to map 1:1 to the real world when the document is displayed at 100% zoom.
It is surely unsurprising that if somebody chooses to dimension their drawing in inches, millimetres, or kilometres, that these units are supposed to relate to the real world.
However, it is not clear that every drawing needs to be displayed at a real-world scale of 1:1 .
Really, there are (at least) three different ways the unit system touches the real world.
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.
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.)
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.
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. 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.
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. Establish different unit systems "modes" and let the user toggle which units mode to use in the Inkscape UI while drawing.
With SVG 2 there is the possibility to improve the unit situation. Can someone come up with a concrete proposal? I can then bring it to the working group. (I will also be thinking about this when I get a chance.)
I wouldn't mind working with you on developing a proposal. What would this entail? Can you point me at a good example?
Bryce
On Wed, 25 Sep 2013 13:09:36 -0700 Bryce Harrington <bryce@...961...> wrote:
On Wed, Sep 25, 2013 at 08:46:06PM +0200, Tavmjong Bah wrote:
With SVG 2 there is the possibility to improve the unit situation. Can someone come up with a concrete proposal? I can then bring it to the working group. (I will also be thinking about this when I get a chance.)
I wouldn't mind working with you on developing a proposal. What would this entail? Can you point me at a good example?
Proposal forthcoming, which can then be subjected to a rigorous critique.
I'll need a few days to work on it.
-- Ian Bruce
On Wed, 2013-09-25 at 13:09 -0700, Bryce Harrington wrote:
On Wed, Sep 25, 2013 at 08:46:06PM +0200, Tavmjong Bah wrote:
With SVG 2 there is the possibility to improve the unit situation. Can someone come up with a concrete proposal? I can then bring it to the working group. (I will also be thinking about this when I get a chance.)
I wouldn't mind working with you on developing a proposal. What would this entail? Can you point me at a good example?
The goal would be to come up with a solution that is approved by the SVG WG. Once approved, I can add it to the SVG 2 spec. The best way to proceed is probably to create a web page that presents the problems and the proposed solution, with sample SVG code and illustrations. See my "Connectors" page for an example of presenting the solution part.[1]
A couple of key things to keep in mind:
1. Cannot break existing content. 2. Must be compatible with CSS. (Which requires understanding how CSS/HTML sizes SVGs and how CSS approaches the screen resolution problem.)
Note that the majority of SVG WG members are only interested in SVG use on the Web.
Tav
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
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
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
On Thu, Sep 26, 2013 at 02:30:23AM -0700, ian_bruce@...2136... wrote:
On Wed, 25 Sep 2013 19:40:00 -0700 Bryce Harrington <bryce@...961...> wrote:
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.
Perhaps not ideal, but using SMUUs does sound like the practical solution to this.
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.
Right, because of that I don't think we can legally use km's there. So in the document SVG itself, the elements would have to be recorded in document units - cm's in this case. The user-visible units would be given as inkscape attributes, which we'd implement in inkscape initially like <g inkscape:scaling-factor="1.0E-7km:1cm"> or something equivalent.
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?
For this, need to look beyond just illustration, so Visio, AutoCAD, Libreoffice Draw, etc. Might find some good ideas in mapping software (esp. ones that converse in svg), or architectural drawing programs.
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.
Maybe, yeah. The window chrome is already so crowded with cruft though, and this feature will be relevant to a pretty distinct audience so I'm uncertain that adding it as another edge widget is ideal. Not that I have a better idea to suggest though...
Bryce
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.
Maybe, yeah. The window chrome is already so crowded with cruft though, and this feature will be relevant to a pretty distinct audience so I'm uncertain that adding it as another edge widget is ideal. Not that I have a better idea to suggest though...
This will be extremely confusing. The unit selector should always work in document (drawing) units.
Instead of adding an extra widget, we should add the variables "displayscale" and "exportscale" to the expression evaluator in the spinbox, so that writing e.g. "3in / exportscale" would yield a length which corresponds to 3in when exported.
There are other useful constants which could be added, e.g. pageheight, pagewidth, and so on.
Regards, Krzysztof
On Thu, 2013-09-26 at 13:45 -0700, Bryce Harrington wrote:
Maybe, yeah. The window chrome is already so crowded with cruft though, and this feature will be relevant to a pretty distinct audience so I'm uncertain that adding it as another edge widget is ideal. Not that I have a better idea to suggest though...
We should do a proper design session. We can do it on irc I guess (if only we had a tool that would share our drawings over a network ;-))
If you guys are serious about implementing a feature.
Just let me know and we'll set up a time.
Martin,
On Thu, Sep 26, 2013 at 2:39 PM, Martin Owens <doctormo@...400...> wrote:
We should do a proper design session. We can do it on irc I guess (if only we had a tool that would share our drawings over a network ;-))
It'll always be too soon for Inkboard jokes... :-(
Cheers, Josh
On Thu, 26 Sep 2013 13:45:02 -0700 Bryce Harrington <bryce@...961...> wrote:
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.
Perhaps not ideal, but using SMUUs does sound like the practical solution to this.
I have not the slightest idea of what the meaning of "SMUU" might be, so perhaps you could elaborate.
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.
Right, because of that I don't think we can legally use km's there. So in the document SVG itself, the elements would have to be recorded in document units - cm's in this case. The user-visible units would be given as inkscape attributes, which we'd implement in inkscape initially like <g inkscape:scaling-factor="1.0E-7km:1cm"> or something equivalent.
We've had an invitation to submit proposals for improved unit handing in future revisions of the SVG specification. A mechanism for defining new units for a document, and a means of specifying them as the default for a certain part of the SVG tree, as above, are about the most important things I can think of in that regard.
As I said in another message, proposal forthcoming shortly.
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.
Maybe, yeah. The window chrome is already so crowded with cruft though, and this feature will be relevant to a pretty distinct audience so I'm uncertain that adding it as another edge widget is ideal. Not that I have a better idea to suggest though...
Krzysztof Kosi\u0144ski <tweenk.pl@...400...> wrote:
This will be extremely confusing. The unit selector should always work in document (drawing) units.
Instead of adding an extra widget, we should add the variables "displayscale" and "exportscale" to the expression evaluator in the spinbox, so that writing e.g. "3in / exportscale" would yield a length which corresponds to 3in when exported.
I'm inclined to agree with that.
-- Ian Bruce
On Thu, Sep 26, 2013 at 05:19:58PM -0700, ian_bruce@...2136... wrote:
On Thu, 26 Sep 2013 13:45:02 -0700 Bryce Harrington <bryce@...961...> wrote:
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.
Perhaps not ideal, but using SMUUs does sound like the practical solution to this.
I have not the slightest idea of what the meaning of "SMUU" might be, so perhaps you could elaborate.
You defined it yourself... Reread your paragraph.
Bryce
Hi Ian, I guess we agree overall. (your inline replies during my argument of why something is not a good idea make it very hard to see where you are disagreeing / adding something new that was not written later on!)
One big issue is what to do with the "px" unit description in Inkscape's UI. It means "pixel" for most people I think. My question is, if it is OK to have the "px" unit in Inkscape's UI mean something different than the "px" (=user unit) in SVG. If no, then I believe we should remove "px" from Inkscape's UI. Given that some people do want to use pixel units (e.g. our icons file), I don't know how much trouble that removal will cause to people. So I'd like to keep the "px" unit description, and have it mean pixel with an explicitly defined DPI (if undefined, use 90dpi as old Inkscape did).
Sidenote: most Inkscape document do not have proper units defined. So almost all the "mm" stuff currently is ill-defined. We need some kind of fallback that works with older documents too, where 90userunits = 1 inch (if I'm not mistaken).
Cheers, Johan
On 25-9-2013 11:39, ian_bruce@...2136... wrote:
On Tue, 24 Sep 2013 23:27:50 +0200 Johan Engelen <jbc.engelen@...2592...> wrote:
On 24-9-2013 22:16, Krzysztof Kosi\u0144ski wrote:
So it seems that 1px should ideally correspond to 1in / dpi of the monitor. E.g. the units are supposed to map 1:1 to the real world when the document is displayed at 100% zoom.
It is surely unsurprising that if somebody chooses to dimension their drawing in inches, millimetres, or kilometres, that these units are supposed to relate to the real world.
However, it is not clear that every drawing needs to be displayed at a real-world scale of 1:1 . If some drawing contains a feature with a dimension of "100 inches", then it is unlikely that the whole thing can ever be displayed at full scale; if the dimension is "100 kilometres", it is clearly impossible.
Rather than interpreting "100% zoom" to mean "display at a real-world scale of 1:1", a better interpretation would be "display the drawing at the most appropriate and convenient scale for viewing and working on it." This will often, but not always, be such that the displayed size of the drawing is approximately the physical size of the monitor.
The author of the document is the best judge of exactly what display scale a zoom setting of 100% should produce, so there ought to be a per-document preference setting to control this.
I believe that the pc, mm, cm, in ratios are fixed (duh ;), but *not* the "px"/"user unit" ratio.
The px/user-unit ratio is very much fixed, at 1:1 , according to the SVG specification. But perhaps by saying "px/user-unit" you meant to suggest not a ratio, but the equivalence of those terms?
The viewbox (together with a defined document height and width in real-world units) defines the ratio of user unit to the other units.
Surely whatever unit is selected as the document default should then be considered equivalent to "user units" and "px", thus defining their ratios to other units?
Unless, of course, "px" is the document default, in which case we need a preference setting, as above, to control what display scale "100% zoom" actually produces.
In a document without viewbox or with non-real-unit document height&width, we have to resort to some arbitrary/default value.
Or an explicit preference setting controlling the ratio of document units to real display units, again at 100% zoom; other zoom factors will rescale the display accordingly.
This default value might be what Krzysztof suggests: use whatever DPI the monitor is using. But that will cause non-viewbox documents to be shown with different sizes (mm, in, cm,...) on different machines.
Monitor DPI is only relevant if the user intends to dimension their drawing in terms of "pixels". Even if they use real physical units, it is not clear that the default display scale should be 1:1 . As I suggested above, if the nominal size of the drawing is on the order of 100 inches, and it's being viewed on a 27-inch monitor, then a zoom setting of 100% should probably NOT produce a real display scale of 1:1 ; it would probably be better to choose a scale such that the borders of the document were aligned with the edges of the monitor.
But the best person to decide this question is the document author, so there should be a preference setting to control it directly.
Confusing for people perhaps, because the default Inkscape document does not specify the relation between user units and real-world units, and so in that case if someone thinks he is using "mm", he is actually using an ill-defined "mm".
If someone thinks they are using millimetres, it would be best if nothing happens to contradict that belief. If there is an explicit "Display Scale Factor" preference setting, they can control whether 100% zoom produces a 1:1 ratio of document millimetres to screen millimetres, or some other value, of their choosing. It's only ill-defined if people are given no way of defining it.
I think it is better to have some fall-back dpi value stored in the preferences, so people have better control over it and can handle interoperability better (on documents without proper scale definition).
"DPI" means "dots (pixels) per inch", and since we've established that SVG "px" have no necessary connection with pixels, it doesn't seem to be a very relevant concept. But as you say, there needs to be something in the preferences, so that people can directly control the default (100% zoom) scale their drawing is displayed with, regardless of what units they use to dimension it.
If it's not already clear, I think that preference setting should directly control the default ratio of document units to physical screen units; this would be multiplied with the zoom factor setting when the document was actually rendered on the display. In addition to "px" and real physical units, it should be possible to select the width or height of both the drawing and the screen; you could then specify that the document should be displayed so that its width (or height) was the same as (or half, or twice) that of the screen.
The PNG image attached to this message shows what such a preference dialog might look like: two number boxes, and two selection lists, to specify the ratio between document units and physical display units.
I have previously posted an extended discussion of these issues, archived here:
http://sourceforge.net/mailarchive/forum.php?thread_name=20121104003312.162f...
On Wed, Sep 25, 2013 at 08:37:42PM +0200, Johan Engelen wrote:
One big issue is what to do with the "px" unit description in Inkscape's UI. It means "pixel" for most people I think. My question is, if it is OK to have the "px" unit in Inkscape's UI mean something different than the "px" (=user unit) in SVG. If no, then I believe we should remove "px" from Inkscape's UI. Given that some people do want to use pixel units (e.g. our icons file), I don't know how much trouble that removal will cause to people. So I'd like to keep the "px" unit description, and have it mean pixel with an explicitly defined DPI (if undefined, use 90dpi as old Inkscape did).
Again, I think differentiating the display mode from document mode better (so we can have two different definitions of px - one that corresponds to SVG, the other that corresponds to what users actually expect), may be the safest way to go.
Sidenote: most Inkscape document do not have proper units defined. So almost all the "mm" stuff currently is ill-defined. We need some kind of fallback that works with older documents too, where 90userunits = 1 inch (if I'm not mistaken).
Agreed.
Bryce
On Wed, 25 Sep 2013 20:37:42 +0200 Johan Engelen <jbc.engelen@...2592...> wrote:
I guess we agree overall. (your inline replies during my argument of why something is not a good idea make it very hard to see where you are disagreeing / adding something new that was not written later on!)
I don't think we disagree. I just wanted to show that what I was proposing could address all the concerns that you mentioned, and to suggest that since "DPI" is not necessarily relevant in the context of vector graphics, a more general unit ratio setting would be a better option.
One big issue is what to do with the "px" unit description in Inkscape's UI. It means "pixel" for most people I think. My question is, if it is OK to have the "px" unit in Inkscape's UI mean something different than the "px" (=user unit) in SVG.
It seems that this is really the only viable option. But to clarify that there is a distinction, for people familiar with the unfortunately-named SVG "px", perhaps it would be better to use the term "pixel" or "pxl" in the Inkscape UI.
If no, then I believe we should remove "px" from Inkscape's UI. Given that some people do want to use pixel units (e.g. our icons file), I don't know how much trouble that removal will cause to people. So I'd like to keep the "px" unit description, and have it mean pixel with an explicitly defined DPI (if undefined, use 90dpi as old Inkscape did).
For "explicitly defined DPI", I suggest the use of my "display scale factor" preference setting. (Improved version attached here, detailed explanation in another message.)
Sidenote: most Inkscape document do not have proper units defined. So almost all the "mm" stuff currently is ill-defined. We need some kind of fallback that works with older documents too, where 90userunits = 1 inch (if I'm not mistaken).
If it is possible to autodetect "older documents" when opened, then the drawing:export unit ratio on my proposed preference setting could be initialized to [90 pixels : 1 inches], or any other appropriate value.
If the user doesn't like that default setting, then they can just change it to something else; if they don't even notice it, everything works as it did before.
-- Ian Bruce
participants (9)
-
unknown＠example.com -
Bryce Harrington -
Johan Engelen -
Josh Andler -
Krzysztof Kosiński -
Martin Owens -
Matthew Petroff -
Tavmjong Bah -
Tobias Ellinghaus