auto-increment object id's?
hey,
i use inkscape a lot - it is my primary svg editor - and i'm very impressed with it. but there's one thing that frustrates me, and that is the way it handles auto-id assignment.
ideally i'd like to be able to select a group of objects, set the ID property of one, with a -1 at the end, and have the rest all be enumerated based on the first one..
is there any way to tell inkscape to use specific id's for objects, and auto-increment properly? i've dl'ed the code and had a look at the sd-object "sp_object_get_unique_id" function, but it doesn't look to me as if theres' an 'easy' way to get it to handle auto-increments properly without majorly restructuring things .. anyone got clues?
On Thu, 11 Nov 2004, Jay Vaughan wrote:
i use inkscape a lot - it is my primary svg editor - and i'm very impressed with it. but there's one thing that frustrates me, and that is the way it handles auto-id assignment.
ideally i'd like to be able to select a group of objects, set the ID property of one, with a -1 at the end, and have the rest all be enumerated based on the first one..
Ooh, interesting idea.
is there any way to tell inkscape to use specific id's for objects, and auto-increment properly? i've dl'ed the code and had a look at the sd-object "sp_object_get_unique_id" function, but it doesn't look to me as if theres' an 'easy' way to get it to handle auto-increments properly without majorly restructuring things .. anyone got clues?
Yes, in fact I recently was working on the section of code that does this, so can tell you exactly where to make these changes. Look in the routine sp_item_widget_label_changed() in item-properties.cpp. This is the code that is run when you click on the "Update Properties" (aka "Set ID") button in the Object (or Item) Properties dialog.
Look at the section of code beginning with
/* Retrieve the label widget for the object's id */
This code takes the text typed into the ID text box, verifies that it's a valid new ID, and then applies it via the 'sp_object_setAttribute()' routine.
Currently, you'll note that if you select multiple object, the fields in this dialog box grey out. So your first task is to figure out a way to make the dialog not grey out the ID box, but somehow indicate that the user can enter an ID pattern according to your idea. My guess is that this is done at the start of sp_item_widget_setup() where it says:
if (!selection->singleItem()) { gtk_widget_set_sensitive (GTK_WIDGET (spw), FALSE); return;
} else { gtk_widget_set_sensitive (GTK_WIDGET (spw), TRUE);
}
Experiment with changing that first clause to setting the sensitivity of the ID field to TRUE (but leaving the rest of the dialog to be insensitive).
Next, the fun part: Back in sp_item_widget_label_changed(), in the object id section, replace the line
sp_object_setAttribute (SP_OBJECT (item), "id", id, &ex);
with some logic that does something like:
if (!selection->singleItem()) { /* TODO: * Parse the entered ID into 'name' and 'incrementable' * Generate an array of old ID's to new ID's * If any of the new ID's are taken, issue an error message * Else, foreach old ID: * Set the new ID using sp_object_setAttribute() */ } else { sp_object_setAttribute (SP_OBJECT (item), "id", id, &ex); }
obviously replacing the commented out section with your own logic.
Hope this helps, Bryce
While fiddling with the text on a path function I came across a simple tip or trick which allows you to get your text inside an object rather than outside.
Draw a circle Duplicate circle and flip horizontally Separate the two circles
Write text sample Duplicate text sample
Take original circle and one of the text samples and put text on path The text goes on the outside of the path
Take flipped circle and other text sample and put text on path The text goes inside the circle
This technique also works with text objects if they are converted to paths first
See attached example I have not seen this documented before. vellum
When you have a path, not a shape, a simpler way is to reverse the path (Path > Reverse). However shapes cannot be reversed, so for them the flipping trick is useful (fortunately most shapes are symmetric).
Can you add this trick to http://inkscape.org/cgi-bin/wiki.pl?TricksAndTips?
Joshua: as you're working with documentation, can you move the tips from that page to the Tips tutorial?
On Fri, 12 Nov 2004 21:35:22 +1100, vellum <vellum@...68...> wrote:
While fiddling with the text on a path function I came across a simple tip or trick which allows you to get your text inside an object rather than outside.
Draw a circle Duplicate circle and flip horizontally Separate the two circles
Write text sample Duplicate text sample
Take original circle and one of the text samples and put text on path The text goes on the outside of the path
Take flipped circle and other text sample and put text on path The text goes inside the circle
This technique also works with text objects if they are converted to paths first
See attached example I have not seen this documented before. vellum
When you have a path, not a shape, a simpler way is to reverse the path (Path > Reverse). However shapes cannot be reversed, so for them the flipping trick is useful (fortunately most shapes are symmetric).
Can you add this trick to http://inkscape.org/cgi- bin/wiki.pl?TricksAndTips?
Joshua: as you're working with documentation, can you move the tips from that page to the Tips tutorial?
Will do!
Joshua A. Andler wrote:
When you have a path, not a shape, a simpler way is to reverse the path (Path > Reverse). However shapes cannot be reversed, so for them the flipping trick is useful (fortunately most shapes are symmetric).
Can you add this trick to http://inkscape.org/cgi- bin/wiki.pl?TricksAndTips?
Joshua: as you're working with documentation, can you move the tips from that page to the Tips tutorial?
Will do!
Thanks man! It is great that you are helping out!
Jon
This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Bulia wrote:
When you have a path, not a shape, a simpler way is to reverse the path (Path > Reverse). However shapes cannot be reversed, so for them the flipping trick is useful (fortunately most shapes are symmetric).
Thanks for the path reverse trick. I had not used that command before. So many commands so little time...:-)
Can you add this trick to
http://inkscape.org/cgi-bin/wiki.pl?TricksAndTips?
Yes.
vellum
Bulia,
When text is added to a circle, star or spiral, it goes on the outside. When you add it to a rectangle or a square it goes on the inside. This looks like a bug? Should I file it or is there something subtle going on that I am not aware of? vellum
When text is added to a circle, star or spiral, it goes on the outside. When you add it to a rectangle or a square it goes on the inside. This looks like a bug? Should I file it or is there something subtle going on that I am not aware of?
Whoa. In fact this reveals a bigger problem which I'm not immediately sure how to fix.
In SVG, you can attach text ONLY to a path - that is, <path> element. Nothing else. This works for Inkscape ellipses, stars, and spirals, because they are implemented as <path> with some extension attributes. But rectangle is not - it's the <rect> element of SVG. So, while Inkscape allows you to put text on rect, this won't render in other SVG software (Adobe drops the text, Batik gives an error message).
The best solution is to switch Inkscape rectangles to using <path> as well, as we switched ellipses some time ago. But this is a relatively big change which I don't want to do before the release. So, for now, should I put in a quick and dirty check forbidding the user from putting a text to a rectangle?
Testing also revealed a bug in ellipse: Inkscape has its path direction opposite to that of other renderers. But this is simpler to fix - it's just a direction mismatch between the d= attribute and the SPCurve generated for the ellipse. I'll fix that now.
Just to introduce myself (hence top-posting, forgive my netiquette) - I'm a graphic designer, and while not a coder, I've joined several of the graphics tools developer lists to contribute from a designer's / usability point of view (an idea originally suggested to me by RMS when I explained to him why designers weren't moving to GNU/Linux).
I assume that Inkscape is attempting to be a form of Adobe Illustrator / Quark Xpress clone.
Text inside a box, in Quark, is the essence of the program. This is a big problem if SVG code doesnt allow this.
Also, there doesnt seem to be an option to draw a text area, in which you could fill text, align left, right, center or justified.
I'm no SVG coder but I would presume these things to be possible - and if Inkscape is going to compete with proprietary products (which at this stage it is already doing well) - then this will be an absolute essential.
The attaching text to path is excellent though, and works very intuitively - this is my issue as a designer, as designers think in pictures- we don't work very well with an application that thinks like code. So far I've found Inkscape the most intuitive out of GIMP, Inkscape and Sodipodi (which I fail to get my head around).
Hello to all, and hope that my comments are of some use,
best,
mC~
bulia byak wrote:
When text is added to a circle, star or spiral, it goes on the outside. When you add it to a rectangle or a square it goes on the inside. This looks like a bug? Should I file it or is there something subtle going on that I am not aware of?
Whoa. In fact this reveals a bigger problem which I'm not immediately sure how to fix.
In SVG, you can attach text ONLY to a path - that is, <path> element. Nothing else. This works for Inkscape ellipses, stars, and spirals, because they are implemented as <path> with some extension attributes. But rectangle is not - it's the <rect> element of SVG. So, while Inkscape allows you to put text on rect, this won't render in other SVG software (Adobe drops the text, Batik gives an error message).
The best solution is to switch Inkscape rectangles to using <path> as well, as we switched ellipses some time ago. But this is a relatively big change which I don't want to do before the release. So, for now, should I put in a quick and dirty check forbidding the user from putting a text to a rectangle?
Testing also revealed a bug in ellipse: Inkscape has its path direction opposite to that of other renderers. But this is simpler to fix - it's just a direction mismatch between the d= attribute and the SPCurve generated for the ellipse. I'll fix that now.
This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Text inside a box, in Quark, is the essence of the program. This is a big problem if SVG code doesnt allow this.
That's different. You're talking about wrapped text inside a box - that is in SVG 1.2 and we will have that in the next version. I'm talking about text that goes along the outline of a rect.
Also, there doesnt seem to be an option to draw a text area, in which you could fill text, align left, right, center or justified.
Sure. Slated for the next version.
I'm no SVG coder but I would presume these things to be possible
Only in SVG 1.2 which is not finalized yet. But we already have read-only support for that.
Hello to all, and hope that my comments are of some use,
Thanks for the feedback - we need more of it :)
bulia byak wrote:
Text inside a box, in Quark, is the essence of the program. This is a big problem if SVG code doesnt allow this.
That's different. You're talking about wrapped text inside a box - that is in SVG 1.2 and we will have that in the next version. I'm talking about text that goes along the outline of a rect.
Yes... I've already experimented with text along a path, but at present one has to draw a rectangular path. Text around a rectangle would be cool - but i'm yet to see its functionality. Text within a box is essential, I'm glad to hear its implemented in SVG 1.2...
Hello to all, and hope that my comments are of some use,
Thanks for the feedback - we need more of it :)
Thank you, and thanks for the warm welcome. Coming in as a designer to a devel-list is difficult, but as RMS said to me - how is anyone going to know unless you tell them :).
Its advantageous that I have both tools, and on Windows - I presume everyone else is testing on Os X which as a kind of *nix flavor (not a real one - have you noticed that you can never have real root control, even as the root user - Apple has to be there to hold the newbies hands ;)... try deleting a locked file....
in any case, yes, I'm glad I can test on another platform as I have both Mandrake 10.0, Win XP and ME....
Does anyone have info on what the latest compatible bleeding edge versions are which are compatible fully with Mandrake - I'm going to play with this for a review for London's Linux User and Developer while on holiday in Mexico, and would like to give an up-to-date and thorough review, with a stable but new version, without crashing immediately (not sure how easily i'll have internet access there and the pressure is on to write it during that time)...
Best,
Miriam.
bulia byak wrote:
Yes... I've already experimented with text along a path, but at present one has to draw a rectangular path.
Of which the simplest way is to draw a rect and do ctrl+shift+c.
Is this listed in the menu?
Designers arent the types to RTFM... in fact they'll usually throw it at you (with the exception of me, most of the time ;P )
Designers would prefer little tools to group, or draw a path rectangle - or alternatively, a menu if at last resort.
We think visually... thats the purpose of me coming here really, to demonstrate from a designers point of view how we think. At the moment designers are struggling with GNU/Linux because everything is written from a coder's point of view, therefore it's hard to get our heads around how an application works, or even to locate and understand the functionality of the tools.
Best,
mC~
bulia byak wrote:
Of which the simplest way is to draw a rect and do ctrl+shift+c.
Is this listed in the menu?
Of course, Path > Convert to Path.
Ahh, i see what you are driving at now - converting the rectangle to a path. I was under the impression the entire text and rectangle process was done with those keystrokes....
best
mC~
On Fri, 12 Nov 2004, miriam clinton (iriXx) wrote:
Just to introduce myself (hence top-posting, forgive my netiquette) - I'm a graphic designer, and while not a coder, I've joined several of the graphics tools developer lists to contribute from a designer's / usability point of view (an idea originally suggested to me by RMS when I explained to him why designers weren't moving to GNU/Linux).
Cool, well welcome aboard. :-)
I can't speak for other graphics projects but we definitely value getting feedback from users, especially those with design backgrounds. Usability is a key issue for us as well, and often put out new features for review and feedback on usability. We encourage downloading and testing the nightly snapshots, so you can provide critique on stuff that's getting development attention right now. We also place importance on keeping discussions friendly - as you can imagine we often find people with a lot of diverse viewpoints on things. :-)
I assume that Inkscape is attempting to be a form of Adobe Illustrator / Quark Xpress clone.
No, not exactly. We pull in ideas from a lot of different tools, and occassionally even come up with our own. We have no intent to clone any particular application, and are certain to disappoint someone looking for e.g. an open source drop-in replacement for Illustrator or Xpress. Obviously, there's pros and cons to this approach, but it's the approach we decided on pretty early on and it's been working fairly well so far.
We do have a rule that if we find ourselves in a tither over how to implement a feature, or can't come up with a better approach, to default to mimic Illustrator, although so far I don't think we've had to invoke that rule. I think this has forced us to really struggle to get each feature as high quality as possible.
Text inside a box, in Quark, is the essence of the program. This is a big problem if SVG code doesnt allow this.
SVG permits this using the TextFlow capability. We've implemented this for 0.40, but it's not yet advanced enough to say Inkscape implements true "Text In Box". Definitely a needed feature, and I'm sure we'll get it in time. For now it's a bit on the experimental side:
http://inkscape.org/screenshots/gallery/inkscape-0.40-CVS-linux-flow-01.png
Also, there doesnt seem to be an option to draw a text area, in which you could fill text, align left, right, center or justified.
Right. That is still to be implemented.
I'm no SVG coder but I would presume these things to be possible - and if Inkscape is going to compete with proprietary products (which at this stage it is already doing well) - then this will be an absolute essential.
You're correct. These are also necessary features for doing technical drawing (flowcharts and the like), which a number of people are passionate to see. This has actually been a long term goal since the start, and Text In Box is one of a set of needed features to achieve that. Line markers were added a while back, and work is underway to add object-linking.
Generally, the way development goes is that the backend rendering of a feature comes into being first, with the GUI controls to edit that feature following on later. For instance, I understand that with this release, Inkscape can render and manipulate linked objects, but there's no controls to create or edit the links within the tool. These can be expected in upcoming releases.
Same thing happened with layers; the basic core for layer management was there in 0.39, but there was no way to edit layers; that's been the focus for this release.
The attaching text to path is excellent though, and works very intuitively - this is my issue as a designer, as designers think in pictures- we don't work very well with an application that thinks like code. So far I've found Inkscape the most intuitive out of GIMP, Inkscape and Sodipodi (which I fail to get my head around).
Thanks! I think our secret is that our developers are also designers, and that we also have a tight feedback loop with users. So if you have ideas, please don't be shy about sharing them.
Bryce
On Fri, 12 Nov 2004 14:52:07 -0800, miriam clinton (iriXx) <irixx@...569...> wrote:
Just to introduce myself (hence top-posting, forgive my netiquette) - I'm a graphic designer, and while not a coder, I've joined several of the graphics tools developer lists to contribute from a designer's / usability point of view (an idea originally suggested to me by RMS when I explained to him why designers weren't moving to GNU/Linux).
It's a pleasure to see you here, Miriam! Are we going to see a contest similar to WTFYTYD in designers world? :)
Alexandre
Alexandre Prokoudine wrote:
On Fri, 12 Nov 2004 14:52:07 -0800, miriam clinton (iriXx) <irixx@...569...> wrote:
Just to introduce myself (hence top-posting, forgive my netiquette) - I'm a graphic designer, and while not a coder, I've joined several of the graphics tools developer lists to contribute from a designer's / usability point of view (an idea originally suggested to me by RMS when I explained to him why designers weren't moving to GNU/Linux).
It's a pleasure to see you here, Miriam! Are we going to see a contest similar to WTFYTYD in designers world? :)
Alexandre
hey there!
well, perhaps - although I designed the album covers which were a mashup of Madonna and various other things, Barbie dolls etc - based under UK law that you can use small amounts of copyrighted material for the purposes of journalistic and/or other commentary. We had our legal-eagles at ukcdr.org check that one out :)
Hmm... will have to think of that one. But for the moment I'd love to help with the tools, I'd like to migrate fully to GNU/Linux rather than being stuck in proprietary-land....
mC~
Bulia said:
Whoa. In fact this reveals a bigger problem which I'm not immediately sure how to fix.
In SVG, you can attach text ONLY to a path - that is, <path> element. Nothing else. This works for Inkscape ellipses, stars, and spirals, because they are implemented as <path> with some extension attributes. But rectangle is not - it's the <rect> element of SVG. So, while Inkscape allows you to put text on rect, this won't render in other SVG software (Adobe drops the text, Batik gives an error message).
The best solution is to switch Inkscape rectangles to using <path> as well, as we switched ellipses some time ago. But this is a relatively big change which I don't want to do before the release. So, for now, should I put in a quick and dirty check forbidding the user from putting a text to a rectangle?
No. I'd say leave it as it is until we can fix it properly. At present text to path with a rectangle shape gives text on the inside. However, if you then flip the rectangle it goes to the outside. Actually this works for all the shapes.
vellum
On Sat, 13 Nov 2004, vellum wrote:
The best solution is to switch Inkscape rectangles to using <path> as well, as we switched ellipses some time ago. But this is a relatively big change which I don't want to do before the release. So, for now, should I put in a quick and dirty check forbidding the user from putting a text to a rectangle?
No. I'd say leave it as it is until we can fix it properly. At present text to path with a rectangle shape gives text on the inside. However, if you then flip the rectangle it goes to the outside. Actually this works for all the shapes.
We can't release like this; this is a standards-compliance issue: attaching a <textPath> to a <rect> results in a malformed SVG document.
From section 10.13.2 of the SVG 1.1 spec:
If <uri> is an invalid reference (e.g., no such element exists, or the referenced element is not a 'path'), then the 'textPath' element is in error and its entire contents shall not be rendered by the user agent.
We must avoid creating such documents at all costs.
Actually this may be an issue for more than just <rect> ... while we create ellipse/arc objects as <path>s now, I believe we still support the native <ellipse>, <circle> or whatever objects if they are already present in the document.
What happens if we load a document with such an ellipse in it, then attach text to it?
For this release I think the best thing to do is to force all shapes to <path>s when text is attached to them, and document it in the errata.
-mental
We can't release like this; this is a standards-compliance issue: attaching a <textPath> to a <rect> results in a malformed SVG document.
Yep. I just added a check with an error message in statusbar.
Actually this may be an issue for more than just <rect> ... while we create ellipse/arc objects as <path>s now, I believe we still support the native <ellipse>, <circle> or whatever objects if they are already present in the document.
I'm not sure what is done with them now, but I think the best we can do is convert them to <path> on save.
There is no loss in precision because our ellipse path uses A (elliptic arc) anyway.
IMHO the <ellipse>, <rect> etc are little more than shortcuts for those who writes SVG by hand. It would be nice if we preserve them but it's not absolutely essential. And keeping everything in <path> is so much simpler and more flexible, as this textPath issue demonstrates.
For this release I think the best thing to do is to force all shapes to <path>s when text is attached to them, and document it in the errata.
Why _all_ shapes when only rects are affected? And I'm against turning it into path automatically. For now let it just display a message, and if you really need it, convert the rect to path yourself. When we switch rects to always use <path> the problem will be moot.
bulia byak wrote:
IMHO the <ellipse>, <rect> etc are little more than shortcuts for those who writes SVG by hand. It would be nice if we preserve them but it's not absolutely essential. And keeping everything in <path> is so much simpler and more flexible, as this textPath issue demonstrates.
if rects are switched always to paths we lose the ability to modify at a later time the corner roundness, this is why i believe <rect> should be switched to <path> only when it receive a text attached.
if rects are switched always to paths we lose the ability to modify at a later time the corner roundness, this is why i believe <rect> should be switched to <path> only when it receive a text attached.
No. The only thing that changes is the internal representation. For the user, nothing changes. Rect will have all the same capabilities as before. Compare all the other shapes - they have their own handles and parameters yet they are all implemented as <path> (look in the xml editor).
participants (10)
-
Alexandre Prokoudine -
Bryce Harrington -
bulia byak -
Jay Vaughan -
Jon Phillips -
Joshua A. Andler -
MenTaLguY -
miriam clinton (iriXx) -
Nicu Buculei -
vellum