The other day I was trying to draw a path to scale in inkscape 0.39 (Debian unstable) so that I could borrow the path data, put it into a pdf and print a path to scale spanning multple pages. I noticed that I don't quite understand units in inkscape and I was hoping someone could help me understand.
On the page tab of the document preferences dialog Inkscape appears to use 72 points to one inch. The units in the path data seem to be 90 units to one inch. What units are these? Is there a way to make Inkscape store the path data units as inches or centimeters?
If I change the grid units to inches in a new document, the ruler inches change to inches. When I open the document again for editing the ruler units switch back to the default mm and the grid units stay inches. Is there an independant way to control the ruler units or a way to sync them with the grid?
Is there a way to change the cursor position units? They default to points but change to ruler units while transformig objects.
Thank you, Aaron Spike
The path data stored in an SVG file is in "user units". If you want to know what they are in real-world units you should look at the width and height of the svg, as well as the viewBox. If you divide the width and height of the SVG by the width and height of the viewBox you'll get the size of user units. Note that the viewBox attribute acts as a transform, so if you use real-world units within an svg element with a viewBox they'll get the same transformation as the used user units (so if the viewBox attribute would imply a two-fold increase in size for user units the same would happen for all the real-world units inside the svg element).
The relevant chapter in the SVG specification: http://www.w3.org/TR/SVG11/coords.html
Aaron and Sarah Spike wrote:
The other day I was trying to draw a path to scale in inkscape 0.39 (Debian unstable) so that I could borrow the path data, put it into a pdf and print a path to scale spanning multple pages. I noticed that I don't quite understand units in inkscape and I was hoping someone could help me understand.
On the page tab of the document preferences dialog Inkscape appears to use 72 points to one inch. The units in the path data seem to be 90 units to one inch. What units are these? Is there a way to make Inkscape store the path data units as inches or centimeters?
If I change the grid units to inches in a new document, the ruler inches change to inches. When I open the document again for editing the ruler units switch back to the default mm and the grid units stay inches. Is there an independant way to control the ruler units or a way to sync them with the grid?
Is there a way to change the cursor position units? They default to points but change to ruler units while transformig objects.
Thank you, Aaron Spike
Jasper van de Gronde wrote:
Aaron and Sarah Spike wrote:
On the page tab of the document preferences dialog Inkscape appears to use 72 points to one inch. The units in the path data seem to be 90 units to one inch. What units are these? Is there a way to make Inkscape store the path data units as inches or centimeters?
The path data stored in an SVG file is in "user units". If you want to know what they are in real-world units you should look at the width and height of the svg, as well as the viewBox. If you divide the width and height of the SVG by the width and height of the viewBox you'll get the size of user units.
Yes. The first thing I did was to look for the viewbox in the parent SVG element. There isn't one. That is why I figured it must be stored in real-world units. So I sat down and reread the spec. I believe user units can also be decended from a parent element, perhaps my screen?
Aaron Spike
If it helps, here is an example of the svg created by Inkscape with no viewbox:
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 20010904//EN" "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd"> <!-- Created with Inkscape (http://www.inkscape.org/) --> <svg id="svg1" sodipodi:version="0.32" inkscape:version="0.39" width="13.500000in" height="21.000000in" sodipodi:docbase="/home/aaron/images/guitardesigns" sodipodi:docname="iceman2.svg" xmlns="http://www.w3.org/2000/svg" xmlns:cc="http://web.resource.org/cc/" xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:xlink="http://www.w3.org/1999/xlink"> <defs id="defs3" /> <sodipodi:namedview id="base" pagecolor="#ffffff" bordercolor="#666666" borderopacity="1.0" inkscape:pageopacity="0.0" inkscape:pageshadow="2" inkscape:zoom="0.75591361" inkscape:cx="1169.1367" inkscape:cy="1279.0340" inkscape:window-width="640" inkscape:window-height="480" gridspacingy="1.0000000in" gridspacingx="1.0000000in" gridoriginy="0.0000000in" gridoriginx="0.0000000in" showgrid="true" borderlayer="top" /> <metadata id="metadata4"> <rdf:RDF id="RDF5"> <cc:Work rdf:about="" id="Work6"> <dc:format id="format7">image/svg+xml</dc:format> <dc:type id="type9" rdf:resource="http://purl.org/dc/dcmitype/StillImage" /> </cc:Work> </rdf:RDF> </metadata> <path
style="fill:none;fill-opacity:0.75000000;fill-rule:evenodd;stroke:#f9010d;stroke-width:1.0000000pt;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1.0000000;" d="M 496.74862,192.09691 C 390.85340,301.40406 233.67083,318.25588 122.15130,395.68242 C 92.720391,416.11591 92.405673,429.33556 105.86446,468.97320 C 137.61482,566.02019 233.94529,706.61575 236.15918,827.28368 C 239.33801,993.93080 -0.37705483,1291.1399 1.1692917,1527.6178 C 2.1471214,1764.6755 436.06903,1785.2002 594.46967,1885.9283 C 624.54893,1653.3581 1138.5943,1747.8243 1180.7959,1446.1836 C 1211.2278,1228.6687 937.81053,930.27334 944.63673,745.84948 C 948.39734,540.10180 1200.9262,193.19916 1221.5130,69.945613 C 1228.6963,-26.549942 1068.5826,-37.988549 961.08256,139.36890 C 1128.8221,132.79385 859.91400,433.73961 788.38284,434.87061 C 698.89482,436.28554 697.28685,252.63932 659.61703,208.38375 C 606.54206,146.02978 573.14545,113.23859 496.74862,192.09691 z " id="path921" sodipodi:nodetypes="ccccccccccccc" /> </svg>
Aaron Spike wrote:
Yes. The first thing I did was to look for the viewbox in the parent SVG element. There isn't one. That is why I figured it must be stored in real-world units. So I sat down and reread the spec. I believe user units can also be decended from a parent element, perhaps my screen?
It's most definitely not stored in real-world units, it's still stored in user units, it's just trickier to find out what they are. If I read the SVG specification they should be in pixels (which is a unit that's coupled to the viewing device). I think it should theoretically not be possible to extract exact (as in device-independent) real-world units from such a document, but I might be wrong. I also don't know how InkScape defines what a pixel is, it might be a constant or it might the definition of your screen, I have no idea.
On 24 Sep 2004 at 15:03, Jasper van de Gronde wrote:
It's most definitely not stored in real-world units, it's still stored in user units, it's just trickier to find out what they are. If I read the SVG specification they should be in pixels (which is a unit that's coupled to the viewing device). I think it should theoretically not be possible to extract exact (as in device-independent) real-world units from such a document, but I might be wrong. I also don't know how InkScape defines what a pixel is, it might be a constant or it might the definition of your screen, I have no idea.
I'm betting on constant. I'm not sure but I think it was about 90 user units to an inch both at home on my small screen in linux and at work on my huge screen in windows.
Does anyone know for sure what pixels are in Inkscape?
I wonder if I could coerce Inkscape to use user units equal to inches by adding a viewbox. I'll have to try that after work.
Thanks
Aaron Spike
fretfind@...248... wrote:
On 24 Sep 2004 at 15:03, Jasper van de Gronde wrote:
It's most definitely not stored in real-world units, it's still stored in user units, it's just trickier to find out what they are. If I read the SVG specification they should be in pixels (which is a unit that's coupled to the viewing device). I think it should theoretically not be possible to extract exact (as in device-independent) real-world units from such a document, but I might be wrong. I also don't know how InkScape defines what a pixel is, it might be a constant or it might the definition of your screen, I have no idea.
I'm betting on constant. I'm not sure but I think it was about 90 user units to an inch both at home on my small screen in linux and at work on my huge screen in windows.
Does anyone know for sure what pixels are in Inkscape?
Inkscape still uses a hard-coded scaling factor of 0.8
Although from my reading of the SVG and CSS specs, it should only use 0.8 when it's unable to determine the display DPI. When it can determine it, then it should use that instead.
Now we see why I haven't actually done all the changes needed for that.
It's most definitely not stored in real-world units, it's still stored in user units, it's just trickier to find out what they are. If I read the SVG specification they should be in pixels (which is a unit that's coupled to the viewing device).
We usually call these "SVG pixels". Any anonymous units in SVG are supposed to be SVG pixels. Their relation to absolute units must be dependent on resolution, but Inkscape has it hard-coded as 1 SVG pixel equals 0.8 pt. Testing shows that Adobe SVG plugin uses the same value, while Batik has a slightly different coefficient (see https://sourceforge.net/tracker/index.php?func=detail&aid=964481&gro...) at least on my machine. I don't know if Batik or Adobe really change that coefficient depending on screen resolution (but I doubt that).
It is my opinion that introducing resolution-dependent units into SVG and especially allowing them to mix with absolute units was a very bad idea. One way to mitigate the consequences is to try to always use only pixels or only absolute units. This is what we do; we convert all lengths to SVG pixels internally and write them as anonymous SVG pixels on save. If you're interested in absolute units, just consider the SVG pixels as yet another absolute unit with the fixed 0.8 coefficient to points.
bulia byak wrote:
It is my opinion that introducing resolution-dependent units into SVG and especially allowing them to mix with absolute units was a very bad idea. One way to mitigate the consequences is to try to always use only pixels or only absolute units. This is what we do; we convert all lengths to SVG pixels internally and write them as anonymous SVG pixels on save. If you're interested in absolute units, just consider the SVG pixels as yet another absolute unit with the fixed 0.8 coefficient to points.
I agree this is the sane thing to do (especially since you can't even use real-world units everywhere), but if you're only using SVG pixels, why not specify a viewBox, this would make sure that other renderers display it identically. And it would also make the files "forwards-compatible", in the sense that even if InkScape would change it's definition of a pixel in the future old files would still be interpreted in exactly the same way.
On Sat, 25 Sep 2004 11:27:11 +0200, Jasper van de Gronde <th.v.d.gronde@...226...> wrote:
bulia byak wrote:
It is my opinion that introducing resolution-dependent units into SVG and especially allowing them to mix with absolute units was a very bad idea. One way to mitigate the consequences is to try to always use only pixels or only absolute units. This is what we do; we convert all lengths to SVG pixels internally and write them as anonymous SVG pixels on save. If you're interested in absolute units, just consider the SVG pixels as yet another absolute unit with the fixed 0.8 coefficient to points.
I agree this is the sane thing to do (especially since you can't even use real-world units everywhere), but if you're only using SVG pixels, why not specify a viewBox, this would make sure that other renderers display it identically. And it would also make the files "forwards-compatible", in the sense that even if InkScape would change it's definition of a pixel in the future old files would still be interpreted in exactly the same way.
As far as I remember from our testing of various renderers, viewbox does not have any effect on the pixel/absolute ratio. Mental, can you please summarize what you found out by posting to the SVG list about this?
On Sat, 2004-09-25 at 13:02, bulia byak wrote:
As far as I remember from our testing of various renderers, viewbox does not have any effect on the pixel/absolute ratio. Mental, can you please summarize what you found out by posting to the SVG list about this?
Correct; viewBox only applies a translation+scaling factor (which affects user and other units alike). [ user units (before any transformation) = pixels ]
If you try to use "real world" units within a viewBoxed document, they will be distorted by the viewBox depending on the particular UA's notion of the current resolution.
Conceivably, you could just avoid using a viewBox and user units altogether, except for one thing -- SVG paths can only be specified in user units.
Without a viewBox, of course, the real world -> user unit relationship will still vary depending on the resolution. So that won't work either.
In summary: everything but user and relative units (relative units being percent, em, and ex) are useless in SVG, except for the purpose of setting document size.
In practice, the only way to do "real world units" in SVG is to set the document dimensions in some absolute real world unit, establish a viewBox, and then use nothing but user and relative units in the document proper.
-mental
MenTaLguY wrote:
In practice, the only way to do "real world units" in SVG is to set the document dimensions in some absolute real world unit, establish a viewBox, and then use nothing but user and relative units in the document proper.
You just hit on my paradigm there. I have always written SVG in vi/notepad and that is exactly what I've been doing. Thanks for the explanation. 0.8 user units per point conincides perfectly with my notion of 90 units per inch. It makes some sense now. And it is a way more complicated than I had expected. I would still like to be able to control my path "units" but I usually have a backwards way of doing things and I'm not sure it would be useful to others. Perhaps I can use a transform to sync my way of thinking with how Inkscape/SVG works. Thanks again.
Does anyone want to take a stab at why I can't seem to control the units on the rulers once I reopen a previously saved document? Probably just an issue in Debian unstable.
Aaron Spike
MenTaLguY wrote:
In practice, the only way to do "real world units" in SVG is to set the document dimensions in some absolute real world unit, establish a viewBox, and then use nothing but user and relative units in the document proper.
You just hit on my paradigm there. I have always written SVG in vi/notepad and that is exactly what I've been doing. Thanks for the explanation. 0.8 user units per point conincides perfectly with my notion of 90 units per inch. It makes some sense now. And it is a way more complicated than I had expected. I would still like to be able to control my path "units" but I usually have a backwards way of doing things and I'm not sure it would be useful to others. Perhaps I can use a transform to sync my way of thinking with how Inkscape/SVG works. Thanks again.
Does anyone want to take a stab at why I can't seem to control the units on the rulers once I reopen a previously saved document? Probably just an issue in Debian unstable.
Aaron Spike
MenTaLguY wrote:
Correct; viewBox only applies a translation+scaling factor (which affects user and other units alike). [ user units (before any transformation) = pixels ]
If you try to use "real world" units within a viewBoxed document, they will be distorted by the viewBox depending on the particular UA's notion of the current resolution.
Conceivably, you could just avoid using a viewBox and user units altogether, except for one thing -- SVG paths can only be specified in user units.
Without a viewBox, of course, the real world -> user unit relationship will still vary depending on the resolution. So that won't work either.
In summary: everything but user and relative units (relative units being percent, em, and ex) are useless in SVG, except for the purpose of setting document size.
I know this, but as far as I can tell InkScape almost exclusively uses user units anyway (except in the styles as far as I can tell, for line widths and so on), so why not do what you propose below?
In practice, the only way to do "real world units" in SVG is to set the document dimensions in some absolute real world unit, establish a viewBox, and then use nothing but user and relative units in the document proper.
From MAILER-DAEMON Sun Sep 26 19:26:01 2004
MIME-Version: 1.0 In-Reply-To: <20040927022556.1F67422BDC@...252...> Message-Id: <VS19943-08@...252...> Content-Type: multipart/report; report-type=delivery-status; boundary="----------=_1096251962-19943-9" From: amavisd-new <postmaster@...252...> To: inkscape-user@lists.sourceforge.net Date: Mon, 27 Sep 2004 10:26:02 +0800 (CST) X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by sourceforge.net. See http://spamassassin.org/tag/ for more details. Report problems to http://sf.net/tracker/?func=add&group_id=1&atid=200001 0.0 SF_CHICKENPOX_SLASH BODY: Text interparsed with / 0.0 SF_CHICKENPOX_MINUS BODY: Text interparsed with - 0.0 SF_CHICKENPOX_AT BODY: Text interparsed with @ 0.0 SF_CHICKENPOX_PERIOD BODY: Text interparsed with . Subject: [Inkscape-user] VIRUS (Win32.Mix) IN YOUR MAIL Sender: inkscape-user-admin@lists.sourceforge.net Errors-To: inkscape-user-admin@lists.sourceforge.net X-BeenThere: inkscape-user@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Reply-To: inkscape-user@lists.sourceforge.net List-Unsubscribe: https://lists.sourceforge.net/lists/listinfo/inkscape-user, mailto:inkscape-user-request@lists.sourceforge.net?subject=unsubscribe List-Id: Inkscape User Community <inkscape-user.lists.sourceforge.net> List-Post: mailto:inkscape-user@lists.sourceforge.net List-Help: mailto:inkscape-user-request@lists.sourceforge.net?subject=help List-Subscribe: https://lists.sourceforge.net/lists/listinfo/inkscape-user, mailto:inkscape-user-request@lists.sourceforge.net?subject=subscribe List-Archive: http://sourceforge.net/mailarchive/forum.php?forum=inkscape-user
This is a multi-part message in MIME format...
------------=_1096251962-19943-9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline
VIRUS ALERT
Our virus checker found virus: Win32.Mix banned filenames: message.scr, .exe in your email to the following recipient: -> cwhuang@...251...
Delivery of the email was stopped!
Please check your system for viruses, or ask your system administrator to do so.
For your reference, here are headers from your email: ------------------------- BEGIN HEADERS ----------------------------- Received: from linux.org.tw (pcp05080054pcs.ivylnd01.pa.comcast.net [68.85.82.163]) by tlug.sinica.edu.tw (Postfix) with ESMTP id 1F67422BDC for <cwhuang@...251...>; Mon, 27 Sep 2004 10:25:56 +0800 (CST) From: inkscape-user@lists.sourceforge.net To: cwhuang@...251... Subject: Mail Delivery (failure cwhuang@...251...) Date: Sun, 26 Sep 2004 19:25:52 -0700 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_001B_01C0CA80.6B015D10" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: <20040927022556.1F67422BDC@...252...> -------------------------- END HEADERS ------------------------------
------------=_1096251962-19943-9 Content-Type: message/delivery-status Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Description: Delivery error report
Reporting-MTA: dns; tlug.sinica.edu.tw Received-From-MTA: smtp; tlug.sinica.edu.tw ([127.0.0.1]) Arrival-Date: Mon, 27 Sep 2004 10:26:02 +0800 (CST)
Final-Recipient: rfc822; cwhuang@...251... Action: failed Status: 5.7.1 Diagnostic-Code: smtp; 550 5.7.1 Message content rejected, id=19943-08 - VIRUS: Win32.Mix Last-Attempt-Date: Mon, 27 Sep 2004 10:26:02 +0800 (CST)
------------=_1096251962-19943-9 Content-Type: text/rfc822-headers Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Description: Undelivered-message headers
Received: from linux.org.tw (pcp05080054pcs.ivylnd01.pa.comcast.net [68.85.82.163]) by tlug.sinica.edu.tw (Postfix) with ESMTP id 1F67422BDC for <cwhuang@...251...>; Mon, 27 Sep 2004 10:25:56 +0800 (CST) From: inkscape-user@lists.sourceforge.net To: cwhuang@...251... Subject: Mail Delivery (failure cwhuang@...251...) Date: Sun, 26 Sep 2004 19:25:52 -0700 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_001B_01C0CA80.6B015D10" X-Priority: 3 X-MSMail-Priority: Normal Message-Id: <20040927022556.1F67422BDC@...252...>
------------=_1096251962-19943-9--
On Sun, 2004-09-26 at 04:33, Jasper van de Gronde wrote:
In summary: everything but user and relative units (relative units being percent, em, and ex) are useless in SVG, except for the purpose of setting document size.
I know this, but as far as I can tell InkScape almost exclusively uses user units anyway (except in the styles as far as I can tell, for line widths and so on), so why not do what you propose below?
In practice, the only way to do "real world units" in SVG is to set the document dimensions in some absolute real world unit, establish a viewBox, and then use nothing but user and relative units in the document proper.
Historical reasons, mostly. bulia and I have been moving things in this direction slowly, but neither of us have had time to devote to the wholesale rework necessary to get that implemented in one fell swoop.
I certainly wouldn't mind if someone jumped in and did it already.
-mental
participants (7)
-
unknown＠example.com -
Aaron and Sarah Spike -
Aaron Spike -
bulia byak -
Jasper van de Gronde -
Jon A. Cruz -
MenTaLguY