Hi,
I had a discussion with several people at the SVG Working group meeting in Leipzig this past week about user units vs. "real" units. I proposed that it be possible to set a ratio for the initial user unit to inch (or cm). This was not well received. My basic conclusion from these discussions is that the use of any real unit (inch, pt, etc.) inside an SVG file (other than on the root 'width' and 'height') is pointless. The correct way to proceed is to set the 'width' and 'height' of the SVG to the size of the drawing and then the 'viewBox' to the same values without units, e.g.:
<svg width="20in" height="15in" viewBox( 0 0 20 15 ) ... >
Once you have done this, one user unit is one inch. If you actually set a length to an inch inside the file (i.e. width="1in"), it will be interpreted as 90 inches since we use 90 user units per inch.
OK, so be it. The gods have spoken.
However, we should at some point change 90 user units per inch to the CSS 2.1 value of 96 which has now been fixed in stone. (Illustrator has the same problem, having used a value of 84.)
Tav
2014-04-11 13:39 GMT+02:00 Tavmjong Bah <tavmjong@...8...>:
<svg width="20in" height="15in" viewBox( 0 0 20 15 ) ... >
Once you have done this, one user unit is one inch. If you actually set a length to an inch inside the file (i.e. width="1in"), it will be interpreted as 90 inches since we use 90 user units per inch.
So the behavior is:
1. In the width / height attributes on the topmost <svg> element, "in" denotes the intended physical display size of the document. 2. Anywhere else, "in" denotes exactly 96px.
Is that correct?
Regards, Krzysztof
On Fri, 2014-04-11 at 13:52 +0200, Krzysztof Kosiński wrote:
2014-04-11 13:39 GMT+02:00 Tavmjong Bah <tavmjong@...8...>:
<svg width="20in" height="15in" viewBox( 0 0 20 15 ) ... >
Once you have done this, one user unit is one inch. If you actually set a length to an inch inside the file (i.e. width="1in"), it will be interpreted as 90 inches since we use 90 user units per inch.
So the behavior is:
- In the width / height attributes on the topmost <svg> element, "in"
denotes the intended physical display size of the document. 2. Anywhere else, "in" denotes exactly 96px.
Is that correct?
Almost... "in" denotes 96 user units which is equal to 96px if there is no scaling.
Tav
What impact will that have on all extensions that work in actual units. e.g. making mods to the Gears-dev extension which converts everything assuming 90dpi is px.
So entries in mm draw an object of the correct size for printing at 90dpi. I am not using Viewboxes. I don't know how to make one. If we need to update extensions for 0.91 - I am happy to try to fix some. Cheers...
On 4/11/2014 11:57 PM, Tavmjong Bah wrote:
On Fri, 2014-04-11 at 13:52 +0200, Krzysztof Kosiński wrote:
2014-04-11 13:39 GMT+02:00 Tavmjong Bah <tavmjong@...8...>:
<svg width="20in" height="15in" viewBox( 0 0 20 15 ) ... >
Once you have done this, one user unit is one inch. If you actually set a length to an inch inside the file (i.e. width="1in"), it will be interpreted as 90 inches since we use 90 user units per inch.
So the behavior is:
- In the width / height attributes on the topmost <svg> element, "in"
denotes the intended physical display size of the document. 2. Anywhere else, "in" denotes exactly 96px.
Is that correct?
Almost... "in" denotes 96 user units which is equal to 96px if there is no scaling.
Tav
Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 12-4-2014 2:26, Mark Schafer wrote:
What impact will that have on all extensions that work in actual units. e.g. making mods to the Gears-dev extension which converts everything assuming 90dpi is px.
There is the "unittouu" function to take care of this (so that the extension code need no longer worry). Look at rev. 12722 http://bazaar.launchpad.net/%7Einkscape.dev/inkscape/trunk/revision/12722. So when we have to change to 96 "px" per inch, for extension we would only have to make the change in one file (inkex.py).
So entries in mm draw an object of the correct size for printing at 90dpi. I am not using Viewboxes. I don't know how to make one. If we need to update extensions for 0.91 - I am happy to try to fix some. Cheers...
On 4/11/2014 11:57 PM, Tavmjong Bah wrote:
On Fri, 2014-04-11 at 13:52 +0200, Krzysztof Kosiński wrote:
2014-04-11 13:39 GMT+02:00 Tavmjong Bah <tavmjong@...8...>:
<svg width="20in" height="15in" viewBox( 0 0 20 15 ) ... >
Once you have done this, one user unit is one inch. If you actually set a length to an inch inside the file (i.e. width="1in"), it will be interpreted as 90 inches since we use 90 user units per inch.
So the behavior is:
- In the width / height attributes on the topmost <svg> element, "in"
denotes the intended physical display size of the document. 2. Anywhere else, "in" denotes exactly 96px.
Is that correct?
Almost... "in" denotes 96 user units which is equal to 96px if there is no scaling.
Tav
Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi,
Unless someone objects, I am going to make the change from 90 pixels to inch to 96 pixels to inch in the files:
share/extensions/inkex.py share/ui/units.xml
This may break some content but it is better to do it now than later, especially that we now are using the 'viewBox' attribute for scaling.
I am also wondering if the change to using 'pt' for the unit in 'font-size' is really the correct way to go. It appears that mixing 'px' and other units is not well advised.
Tav
On Mon, 2014-04-14 at 20:04 +0200, Johan Engelen wrote:
On 12-4-2014 2:26, Mark Schafer wrote:
What impact will that have on all extensions that work in actual units. e.g. making mods to the Gears-dev extension which converts everything assuming 90dpi is px.
There is the "unittouu" function to take care of this (so that the extension code need no longer worry). Look at rev. 12722. So when we have to change to 96 "px" per inch, for extension we would only have to make the change in one file (inkex.py).
So entries in mm draw an object of the correct size for printing at 90dpi. I am not using Viewboxes. I don't know how to make one. If we need to update extensions for 0.91 - I am happy to try to fix some. Cheers...
On 4/11/2014 11:57 PM, Tavmjong Bah wrote:
On Fri, 2014-04-11 at 13:52 +0200, Krzysztof Kosiński wrote:
2014-04-11 13:39 GMT+02:00 Tavmjong Bah <tavmjong@...8...>:
<svg width="20in" height="15in" viewBox( 0 0 20 15 ) ... >
Once you have done this, one user unit is one inch. If you actually set a length to an inch inside the file (i.e. width="1in"), it will be interpreted as 90 inches since we use 90 user units per inch.
So the behavior is:
- In the width / height attributes on the topmost <svg> element, "in"
denotes the intended physical display size of the document. 2. Anywhere else, "in" denotes exactly 96px.
Is that correct?
Almost... "in" denotes 96 user units which is equal to 96px if there is no scaling.
Tav
Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
what is the motivation for doing so? this is almost certain to create a great deal of confusion in the community that uses various kinds of output devices like dektop cutting plotters. I would suggest that you first get some feedback from people in this area, like: http://www.inkscapeforum.com/viewforum.php?f=31 or sebi@...2963...
Alvin
-- View this message in context: http://inkscape.13.x6.nabble.com/Units-tp4970153p4970302.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.
also, add gcodetools to that list of people to consult: Nick Drobchenko, nick@...3109...
-- View this message in context: http://inkscape.13.x6.nabble.com/Units-tp4970153p4970303.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.
On Wed, 2014-04-23 at 03:35 -0700, alvinpenner wrote:
what is the motivation for doing so?
Any use of non-pixel units will result in incorrect display in a web browser where since CSS 2.1 1in == 96px. For example, using 12pt for 'font-size' will result in a font that is 15px high in Inkscape but 16px high on the web. We were a bit immune to this problem in the past as Inkscape created files with only pixel values internally (despite offering other units in the GUI). With the change to using points in the text dialog one can optionally save the 'font-size' in points. SVG files created outside of Inkscape would also have problems.
this is almost certain to create a great deal of confusion in the community that uses various kinds of output devices like dektop cutting plotters.
As long as only px units were used, there should not be a problem. In any case, there is already breakage in units with extensions (see release notes). This is the time to fix this problem once and for all.
I would suggest that you first get some feedback from people in thisarea, like: http://www.inkscapeforum.com/viewforum.php?f=31 or sebi@...2963...
I will send email to sebi@...2963... and nick@...3109...
Tav
2014-04-23 15:06 GMT+02:00 Tavmjong Bah <tavmjong@...8...>:
As long as only px units were used, there should not be a problem. In any case, there is already breakage in units with extensions (see release notes). This is the time to fix this problem once and for all.
+MAX_DBL I empthatically agree, given the potential for future disruption and the fact that the gods have already spoken, this change absolutely must find its way into 0.91.
As far as I understand the interpretation of real world units such as "in" on the toplevel svg element is slightly different from everywhere else, e.g. when a document has width=5in, we should try to make it so that the document's display size at 100% zoom is 5in. Is this correct?
Regards, Krzysztof
El mié, 23-04-2014 a las 03:35 -0700, alvinpenner escribió:
what is the motivation for doing so? this is almost certain to create a great deal of confusion in the community that uses various kinds of output devices like dektop cutting plotters. I would suggest that you first get some feedback from people in this area, like: http://www.inkscapeforum.com/viewforum.php?f=31 or sebi@...2963...
Alvin
Because of the type sizes in pixels and the lack of a viewBox attribute I've been relying on the 90 dpi resolution for conversions. Since other programs like Scribus or Illustrator seem to use the standard postscript resolution (72dpi) to scale SVGs without viewBox the scaling factor for correct the size of imported SVGs was easy: 90/72=1,25. The same for type sizes. One PS typographic point is 1/72th of an inch, so the same ratio applied to scale type in inkscape to fit points.
All of the above becomes obsolete with a viewBox attribute set and type expressed in points instead of pixels (it was about time :-p).
Anyway, I just wanted to point a case where changing the resolution could be problematic, but fortunately with the addition of viewBox and type size in points it won't.
+1 for the change of resolution.
Gez.
On 4/24/2014 2:26 AM, Gez wrote:
El mié, 23-04-2014 a las 03:35 -0700, alvinpenner escribió:
what is the motivation for doing so? this is almost certain to create a great deal of confusion in the community that uses various kinds of output devices like dektop cutting plotters. I would suggest that you first get some feedback from people in this area, like: http://www.inkscapeforum.com/viewforum.php?f=31 or sebi@...2963...
Alvin
Because of the type sizes in pixels and the lack of a viewBox attribute I've been relying on the 90 dpi resolution for conversions. Since other programs like Scribus or Illustrator seem to use the standard postscript resolution (72dpi) to scale SVGs without viewBox the scaling factor for correct the size of imported SVGs was easy: 90/72=1,25. The same for type sizes. One PS typographic point is 1/72th of an inch, so the same ratio applied to scale type in inkscape to fit points.
All of the above becomes obsolete with a viewBox attribute set and type expressed in points instead of pixels (it was about time :-p).
Anyway, I just wanted to point a case where changing the resolution could be problematic, but fortunately with the addition of viewBox and type size in points it won't.
Providing its easy for people to add a viewbox. How is this done in 0.91 UI ?
+1 for the change of resolution.
Gez.
Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4569 / Virus Database: 3920/7380 - Release Date: 04/22/14
hi,
im just fiddling around with the pixels/inch definition to test it with the plotter extension, and are failing at compiling inkscape in windows.
is the information in the wiki correct/up-to-date?
when linking i get a ton of errors i put here: http://pastebin.com/G832LRgC
can someone hint me in the right direction? i am no c programmer and aunt google could not help me.
reagards, TimeWaster
On 23.4.2014 10:36, Tavmjong Bah wrote:
Hi,
Unless someone objects, I am going to make the change from 90 pixels to inch to 96 pixels to inch in the files:
share/extensions/inkex.py share/ui/units.xml
This may break some content but it is better to do it now than later, especially that we now are using the 'viewBox' attribute for scaling.
I am also wondering if the change to using 'pt' for the unit in 'font-size' is really the correct way to go. It appears that mixing 'px' and other units is not well advised.
Tav
On Mon, 2014-04-14 at 20:04 +0200, Johan Engelen wrote:
On 12-4-2014 2:26, Mark Schafer wrote:
What impact will that have on all extensions that work in actual units. e.g. making mods to the Gears-dev extension which converts everything assuming 90dpi is px.
There is the "unittouu" function to take care of this (so that the extension code need no longer worry). Look at rev. 12722. So when we have to change to 96 "px" per inch, for extension we would only have to make the change in one file (inkex.py).
So entries in mm draw an object of the correct size for printing at 90dpi. I am not using Viewboxes. I don't know how to make one. If we need to update extensions for 0.91 - I am happy to try to fix some. Cheers...
On 4/11/2014 11:57 PM, Tavmjong Bah wrote:
On Fri, 2014-04-11 at 13:52 +0200, Krzysztof Kosiński wrote:
2014-04-11 13:39 GMT+02:00 Tavmjong Bah <tavmjong@...8...>:
<svg width="20in" height="15in" viewBox( 0 0 20 15 ) ... >
Once you have done this, one user unit is one inch. If you actually set a length to an inch inside the file (i.e. width="1in"), it will be interpreted as 90 inches since we use 90 user units per inch.
So the behavior is:
- In the width / height attributes on the topmost <svg> element, "in"
denotes the intended physical display size of the document. 2. Anywhere else, "in" denotes exactly 96px.
Is that correct?
Almost... "in" denotes 96 user units which is equal to 96px if there is no scaling.
Tav
Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
*bump*
i still need help with this, otherwise i cannot confirm that the px/in change has no effect on the extension.
also when i send an email to this list it ALWAYS takes 6-9 hours till it shows up on the list, by that time usually 30 new emails arrived and no one sees my mail. any ideas what this could be? this is the only list with this problem.
regards, TimeWaster
On 26.4.2014 00:45, TimeWaster wrote:
hi,
im just fiddling around with the pixels/inch definition to test it with the plotter extension, and are failing at compiling inkscape in windows.
is the information in the wiki correct/up-to-date?
when linking i get a ton of errors i put here: http://pastebin.com/G832LRgC
can someone hint me in the right direction? i am no c programmer and aunt google could not help me.
reagards, TimeWaster
On 23.4.2014 10:36, Tavmjong Bah wrote:
Hi,
Unless someone objects, I am going to make the change from 90 pixels to inch to 96 pixels to inch in the files:
share/extensions/inkex.py share/ui/units.xml
This may break some content but it is better to do it now than later, especially that we now are using the 'viewBox' attribute for scaling.
I am also wondering if the change to using 'pt' for the unit in 'font-size' is really the correct way to go. It appears that mixing 'px' and other units is not well advised.
Tav
On Mon, 2014-04-14 at 20:04 +0200, Johan Engelen wrote:
On 12-4-2014 2:26, Mark Schafer wrote:
What impact will that have on all extensions that work in actual units. e.g. making mods to the Gears-dev extension which converts everything assuming 90dpi is px.
There is the "unittouu" function to take care of this (so that the extension code need no longer worry). Look at rev. 12722. So when we have to change to 96 "px" per inch, for extension we would only have to make the change in one file (inkex.py).
So entries in mm draw an object of the correct size for printing at 90dpi. I am not using Viewboxes. I don't know how to make one. If we need to update extensions for 0.91 - I am happy to try to fix some. Cheers...
On 4/11/2014 11:57 PM, Tavmjong Bah wrote:
On Fri, 2014-04-11 at 13:52 +0200, Krzysztof Kosiński wrote:
2014-04-11 13:39 GMT+02:00 Tavmjong Bah <tavmjong@...8...>: > <svg width="20in" height="15in" viewBox( 0 0 20 15 ) ... > > > Once you have done this, one user unit is one inch. If you actually set > a length to an inch inside the file (i.e. width="1in"), it will be > interpreted as 90 inches since we use 90 user units per inch. So the behavior is:
- In the width / height attributes on the topmost <svg> element, "in"
denotes the intended physical display size of the document. 2. Anywhere else, "in" denotes exactly 96px.
Is that correct?
Almost... "in" denotes 96 user units which is equal to 96px if there is no scaling.
Tav
Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 27-4-2014 14:42, TimeWaster wrote:
*bump*
i still need help with this, otherwise i cannot confirm that the px/in change has no effect on the extension.
also when i send an email to this list it ALWAYS takes 6-9 hours till it shows up on the list, by that time usually 30 new emails arrived and no one sees my mail. any ideas what this could be? this is the only list with this problem.
Mwah, our traffic is (luckily) not that high that your mails go unnoticed :-) Depending on the question, it can take a few days for someone who knows the answer to reply.
(your ID doesn't motivate spending time on reading your e-mails! ;-)
cheers, Johan
regards, TimeWaster
On 26.4.2014 00:45, TimeWaster wrote:
hi,
im just fiddling around with the pixels/inch definition to test it with the plotter extension, and are failing at compiling inkscape in windows.
is the information in the wiki correct/up-to-date?
when linking i get a ton of errors i put here: http://pastebin.com/G832LRgC
can someone hint me in the right direction? i am no c programmer and aunt google could not help me.
reagards, TimeWaster
On 23.4.2014 10:36, Tavmjong Bah wrote:
Hi,
Unless someone objects, I am going to make the change from 90 pixels to inch to 96 pixels to inch in the files:
share/extensions/inkex.py share/ui/units.xml
This may break some content but it is better to do it now than later, especially that we now are using the 'viewBox' attribute for scaling.
I am also wondering if the change to using 'pt' for the unit in 'font-size' is really the correct way to go. It appears that mixing 'px' and other units is not well advised.
Tav
On Mon, 2014-04-14 at 20:04 +0200, Johan Engelen wrote:
On 12-4-2014 2:26, Mark Schafer wrote:
What impact will that have on all extensions that work in actual units. e.g. making mods to the Gears-dev extension which converts everything assuming 90dpi is px.
There is the "unittouu" function to take care of this (so that the extension code need no longer worry). Look at rev. 12722. So when we have to change to 96 "px" per inch, for extension we would only have to make the change in one file (inkex.py).
So entries in mm draw an object of the correct size for printing at 90dpi. I am not using Viewboxes. I don't know how to make one. If we need to update extensions for 0.91 - I am happy to try to fix some. Cheers...
On 4/11/2014 11:57 PM, Tavmjong Bah wrote:
On Fri, 2014-04-11 at 13:52 +0200, Krzysztof Kosiński wrote: > 2014-04-11 13:39 GMT+02:00 Tavmjong Bah <tavmjong@...8...>: >> <svg width="20in" height="15in" viewBox( 0 0 20 15 ) ... > >> >> Once you have done this, one user unit is one inch. If you actually set >> a length to an inch inside the file (i.e. width="1in"), it will be >> interpreted as 90 inches since we use 90 user units per inch. > So the behavior is: > > 1. In the width / height attributes on the topmost <svg> element, "in" > denotes the intended physical display size of the document. > 2. Anywhere else, "in" denotes exactly 96px. > > Is that correct? Almost... "in" denotes 96 user units which is equal to 96px if there is no scaling.
Tav
Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
ok, i will change my name to TimeSaver ^^
On 28.4.2014 02:15, Martin Owens wrote:
On Mon, 2014-04-28 at 00:16 +0200, Johan Engelen wrote:
(your ID doesn't motivate spending time on reading your e-mails! ;-)
As long as he's "wasting" his time on Inkscape ;-)
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 26-4-2014 0:45, TimeWaster wrote:
hi,
im just fiddling around with the pixels/inch definition to test it with the plotter extension, and are failing at compiling inkscape in windows.
is the information in the wiki correct/up-to-date?
when linking i get a ton of errors i put here: http://pastebin.com/G832LRgC
"btool clean" should help. (looks like you still have some left-over compiled files in /obj/dom/... that should not be there)
-Johan
can someone hint me in the right direction? i am no c programmer and aunt google could not help me.
reagards, TimeWaster
On 23.4.2014 10:36, Tavmjong Bah wrote:
Hi,
Unless someone objects, I am going to make the change from 90 pixels to inch to 96 pixels to inch in the files:
share/extensions/inkex.py share/ui/units.xml
This may break some content but it is better to do it now than later, especially that we now are using the 'viewBox' attribute for scaling.
I am also wondering if the change to using 'pt' for the unit in 'font-size' is really the correct way to go. It appears that mixing 'px' and other units is not well advised.
Tav
On Mon, 2014-04-14 at 20:04 +0200, Johan Engelen wrote:
On 12-4-2014 2:26, Mark Schafer wrote:
What impact will that have on all extensions that work in actual units. e.g. making mods to the Gears-dev extension which converts everything assuming 90dpi is px.
There is the "unittouu" function to take care of this (so that the extension code need no longer worry). Look at rev. 12722. So when we have to change to 96 "px" per inch, for extension we would only have to make the change in one file (inkex.py).
So entries in mm draw an object of the correct size for printing at 90dpi. I am not using Viewboxes. I don't know how to make one. If we need to update extensions for 0.91 - I am happy to try to fix some. Cheers...
On 4/11/2014 11:57 PM, Tavmjong Bah wrote:
On Fri, 2014-04-11 at 13:52 +0200, Krzysztof Kosiński wrote:
2014-04-11 13:39 GMT+02:00 Tavmjong Bah <tavmjong@...8...>: > <svg width="20in" height="15in" viewBox( 0 0 20 15 ) ... > > > Once you have done this, one user unit is one inch. If you actually set > a length to an inch inside the file (i.e. width="1in"), it will be > interpreted as 90 inches since we use 90 user units per inch. So the behavior is:
- In the width / height attributes on the topmost <svg> element, "in"
denotes the intended physical display size of the document. 2. Anywhere else, "in" denotes exactly 96px.
Is that correct?
Almost... "in" denotes 96 user units which is equal to 96px if there is no scaling.
Tav
Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 11-4-2014 13:57, Tavmjong Bah wrote:
On Fri, 2014-04-11 at 13:52 +0200, Krzysztof Kosiński wrote:
2014-04-11 13:39 GMT+02:00 Tavmjong Bah <tavmjong@...8...>:
<svg width="20in" height="15in" viewBox( 0 0 20 15 ) ... >
Once you have done this, one user unit is one inch. If you actually set a length to an inch inside the file (i.e. width="1in"), it will be interpreted as 90 inches since we use 90 user units per inch.
So the behavior is:
- In the width / height attributes on the topmost <svg> element, "in"
denotes the intended physical display size of the document. 2. Anywhere else, "in" denotes exactly 96px.
Is that correct?
Almost... "in" denotes 96 user units which is equal to 96px if there is no scaling.
This is exactly what trunk is (trying) to do at the moment, right? (please check too!)
ciao, Johan
Hi Tav, Cam, Did they give a reason: was it difficulty in implementation, lack of demand, existing solution is sufficiently expressive? I wrote an idea to this list a while back about how to implement different independent units properly using vector units.
njh
On Fri, Apr 11, 2014 at 01:39:28PM +0200, Tavmjong Bah wrote:
Hi,
I had a discussion with several people at the SVG Working group meeting in Leipzig this past week about user units vs. "real" units. I proposed that it be possible to set a ratio for the initial user unit to inch (or cm). This was not well received. My basic conclusion from these discussions is that the use of any real unit (inch, pt, etc.) inside an SVG file (other than on the root 'width' and 'height') is pointless. The correct way to proceed is to set the 'width' and 'height' of the SVG to the size of the drawing and then the 'viewBox' to the same values without units, e.g.:
<svg width="20in" height="15in" viewBox( 0 0 20 15 ) ... >
Once you have done this, one user unit is one inch. If you actually set a length to an inch inside the file (i.e. width="1in"), it will be interpreted as 90 inches since we use 90 user units per inch.
OK, so be it. The gods have spoken.
However, we should at some point change 90 user units per inch to the CSS 2.1 value of 96 which has now been fixed in stone. (Illustrator has the same problem, having used a value of 84.)
Tav
Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Fri, 2014-04-11 at 23:17 +1000, Nathan Hurst wrote:
Hi Tav, Cam, Did they give a reason: was it difficulty in implementation, lack of demand, existing solution is sufficiently expressive? I wrote an idea to this list a while back about how to implement different independent units properly using vector units.
njh
Here is the response from Cameron (an SVG Working Group member):
<quote> I don't remember this being discussed; maybe it was a dinner conversation I was out of earshot of.
I don't think we should have an interpretation of CSS length units within a document that is different from CSS as used in HTML documents. and Web compatibility basically dictates that in, mm, etc. need to be interpreted as a fixed multiple of CSS px. I think the ability to set the ratio between initial user units and inches is exactly what width/height/viewBox allows you to do, if you interpret the width/height values as physical units when you go to print. That approach, and not using units other than px or user units within the document, is what I usually tell people when they ask how to write an SVG document with real-world dimensions. </quote>
On Fri, Apr 11, 2014 at 01:39:28PM +0200, Tavmjong Bah wrote:
Hi,
I had a discussion with several people at the SVG Working group meeting in Leipzig this past week about user units vs. "real" units. I proposed that it be possible to set a ratio for the initial user unit to inch (or cm). This was not well received. My basic conclusion from these discussions is that the use of any real unit (inch, pt, etc.) inside an SVG file (other than on the root 'width' and 'height') is pointless. The correct way to proceed is to set the 'width' and 'height' of the SVG to the size of the drawing and then the 'viewBox' to the same values without units, e.g.:
<svg width="20in" height="15in" viewBox( 0 0 20 15 ) ... >
Once you have done this, one user unit is one inch. If you actually set a length to an inch inside the file (i.e. width="1in"), it will be interpreted as 90 inches since we use 90 user units per inch.
OK, so be it. The gods have spoken.
However, we should at some point change 90 user units per inch to the CSS 2.1 value of 96 which has now been fixed in stone. (Illustrator has the same problem, having used a value of 84.)
Tav
participants (9)
-
alvinpenner -
Gez -
Johan Engelen -
Krzysztof Kosiński -
Mark Schafer -
Martin Owens -
Nathan Hurst -
Tavmjong Bah -
TimeWaster