Hi all,
Just a note to say that svgslice has been updated:
http://www.digitalunleashed.com/downloads/svgslice/svgslice_0.12.tar.bz2
No inkscape extension yet (I'm working on that next) but it does fix a few bugs, in case anyone has been struggling with it.
There are four demo files included, and the coordinates of the slicing in the last one are incorrect. The problem seems to be that Inkscape doesn't respect the units you select in the toolbar for rectangles, but perhaps I'm misunderstanding something there.
Currently, I'm not handling unit conversion, and the different inkscape unit options (document, grid, etc.) all have to be set to the same units. I'm sure there's some unit I could treat this as and then convert, but it looks like a bug, since it's in different units from everything else, and seems to resist change.
Anyway, if anyone feels like playing around, I'd appreciate any hints you might have on that issue.
On 4/22/05, Lee Braiden <lee.b@...786...> wrote:
There are four demo files included, and the coordinates of the slicing in the last one are incorrect. The problem seems to be that Inkscape doesn't respect the units you select in the toolbar for rectangles, but perhaps I'm misunderstanding something there.
You don't actually "set units" for objects. You just choose which unit to use in the UI. Internally, everything is stored in px (numbers without units), and all command line options are in px too.
Currently, I'm not handling unit conversion, and the different inkscape unit options (document, grid, etc.) all have to be set to the same units. I'm sure there's some unit I could treat this as and then convert, but it looks like a bug, since it's in different units from everything else, and seems to resist change.
Exactly what is in different units and resists change?
Meanwhile, you might be interested in the several new command line options I added recently:
* Determining the dimensions of an object in an SVG document is, in general case, impossible without fully rendering the entire document. Yet this information can be very useful for various automated tasks, such as building composite SVG documents from objects in separate source documents. Now, to accomplish this, you can run Inkscape with one of the command line options --query-x, --query-y, --query-width or --query-height. The --query-id option specifies the ID of the object that is queried; if not set, the corresponding dimension of the entire drawing is returned. For example:
$ inkscape tutorial-basic.svg --query-height 3998.6800 $ inkscape tutorial-basic.svg --query-y --query-id text1555 528.94486
The returned values are in px (SVG user units).
* For PNG export, the new option --export-area-drawing exports the entire drawing (not canvas), giving you a PNG of all visible objects without margins.
bulia byak wrote:
On 4/22/05, Lee Braiden <lee.b@...786...> wrote:
There are four demo files included, and the coordinates of the slicing in the last one are incorrect. The problem seems to be that Inkscape doesn't respect the units you select in the toolbar for rectangles, but perhaps I'm misunderstanding something there.
You don't actually "set units" for objects. You just choose which unit to use in the UI. Internally, everything is stored in px (numbers without units), and all command line options are in px too.
Currently, I'm not handling unit conversion, and the different inkscape unit options (document, grid, etc.) all have to be set to the same units. I'm sure there's some unit I could treat this as and then convert, but it looks like a bug, since it's in different units from everything else, and seems to resist change.
Exactly what is in different units and resists change?
Do take notice that these px are SVG's "user units". Bulia mentions this below. While there are normally 72 px per inch, there are 90 SVG user units per inch.
Meanwhile, you might be interested in the several new command line options I added recently:
* Determining the dimensions of an object in an SVG document is,in general case, impossible without fully rendering the entire document. Yet this information can be very useful for various automated tasks, such as building composite SVG documents from objects in separate source documents. Now, to accomplish this, you can run Inkscape with one of the command line options --query-x, --query-y, --query-width or --query-height. The --query-id option specifies the ID of the object that is queried; if not set, the corresponding dimension of the entire drawing is returned. For example:
$ inkscape tutorial-basic.svg --query-height 3998.6800 $ inkscape tutorial-basic.svg --query-y --query-id text1555 528.94486
The returned values are in px (SVG user units). * For PNG export, the new option --export-area-drawing exports theentire drawing (not canvas), giving you a PNG of all visible objects without margins.
Very interesting. What do you have to say about performance and memory usage when running a second instance of Inkscape from an extension script that is run by the first instance of Inkscape? This question came to mind the first time someone mentioned making an extension out of svgslice. Will the memory usage double, because the document is being parsed into memory twice?
Are options really to follow the filename, as in your examples? I can see how this sort of query will be very useful to extensions.
Aaron Spike
aaron@...749... wrote:
Do take notice that these px are SVG's "user units". Bulia mentions this below. While there are normally 72 px per inch, there are 90 SVG user units per inch.
Actualy...
There are *sometimes* 90 SVG user units per inch.
Currently that's the default Inkscape falls to, but is not required (or possibly even desired).
Section 7.10 of the SVG spec includes the bit "For example, suppose that the user agent can determine from its environment that "1px" corresponds to "0.2822222mm" (i.e., 90dpi)."
Notice "For example" and "suppose." It's a very subtle and tricky area, but probably subject to change once I figure out the best way to go about things. Also... just a little farther in the spec they have an example that assumes 96dpi, not 90dpi.
On 4/22/05, aaron@...749... <aaron@...749...> wrote:
Very interesting. What do you have to say about performance and memory usage when running a second instance of Inkscape from an extension script that is run by the first instance of Inkscape?
Performance is acceptable. For example my XSLT stylesheet that produces SVG tutorials runs Inkscape for every paragraph and every image in the source, to determine their height and layout the page accordingly. The total is 69 runs for basic tutorial, and the stylesheet takes 26 seconds to finish.
to mind the first time someone mentioned making an extension out of svgslice. Will the memory usage double, because the document is being parsed into memory twice?
Not really double, because the UI and renderer are not initialized when run from command line. I think they take more memory than the document itself.
Are options really to follow the filename, as in your examples?
The order does not matter.
I can see how this sort of query will be very useful to extensions.
Yes, that's why I added them :)
On Saturday 23 Apr 2005 00:35, bulia byak wrote:
On 4/22/05, Lee Braiden <lee.b@...786...> wrote: You don't actually "set units" for objects. You just choose which unit to use in the UI. Internally, everything is stored in px (numbers without units), and all command line options are in px too.
Ahh, that explains it. All working now; thanks.
Exactly what is in different units and resists change?
My mind, apparently ;D
On Saturday 23 Apr 2005 08:37, Lee Braiden wrote:
On Saturday 23 Apr 2005 00:35, bulia byak wrote:
On 4/22/05, Lee Braiden <lee.b@...786...> wrote: You don't actually "set units" for objects. You just choose which unit to use in the UI. Internally, everything is stored in px (numbers without units), and all command line options are in px too.
Exactly what is in different units and resists change?
Actually, something is still confusing me here. Three of my test files have worked fine when switching everything to px. However, the last one seems to be stuck in pt somehow....
I have a rectangle stretching across the width of the canvas. In the toolbar, it says this rect is 769px by 240px. But in the saved SVG, the width says 615 by 183. I would have expected this to be the same, if it's also in px. Maybe I'm misunderstanding something?
This size seems to correspond with the pt width of the document (which is 614pt by 384pt) ) rather than px. On the other hand, if I change the rectangle units to pt in the toolbar, it says 615pt by 192pt, so the heights seem to be in disagreement, and from earlier attempts, the height difference seems to increase as the document size increases. Maybe I'm seeing something entirely unrelated to pt, which just happens to correspond horizontally to the document width?
Again, maybe I'm missing something that should be obvious. Apologies if so.
On 4/23/05, Lee Braiden <lee.b@...786...> wrote:
I have a rectangle stretching across the width of the canvas. In the toolbar, it says this rect is 769px by 240px. But in the saved SVG, the width says 615 by 183. I would have expected this to be the same, if it's also in px. Maybe I'm misunderstanding something?
I don't find such a file in your svgslice tarball. Can you please send me the file you are speaking about?
participants (4)
-
unknown＠example.com -
bulia byak -
Jon A. Cruz -
Lee Braiden