Behaviour stuff:
ok, sure I love this function, even though usually I don't need so far, but there are some things about it that are really strange:
- the menu item should be grayed out, as long as not a text _and_ a path are selected
- once I put the text on the path, I can move it around, but it's still dependend on the shape of the path.
- while I can move the text around, I can't move the path without the text following
my suggestion:
don't make the text movable and make the path visible if the text is selected, as a blue line or such, so that even when the path is invisible, you can easily edit it.
RFE:
- alignment (right, center, left, justify) of the text should apply in a way as that the path is the whole line
- put text not only on a path but also with a offset, underneath and centered... you know... :)
Guess I'm writing nothing new, but I'm excited about this new feature
David
- the menu item should be grayed out, as long as not a text _and_ a path
are selected
Sure, when we implement graying out for menu items in general, we won't forget about this one
- once I put the text on the path, I can move it around, but it's still
dependend on the shape of the path.
This is as designed. It adds flexibility. I agree that it may feel a bit strange at first but I don't want to remove this capability. If only because other programs may create SVG with text thus moved from its path, and we must be able to view and edit these files.
- while I can move the text around, I can't move the path without the
text following
Yes, because the relative position of path and text is stored in the text, not in path (if only because you can attach more than one text to one path).
don't make the text movable
Disagree, see above
and make the path visible if the text is selected, as a blue line or such, so that even when the path is invisible, you can easily edit it.
I don't think this is really necessary. If your path is invisible, you can still select it by selecting the text attached to it and pressing Shift+D (same key as for finding a clone's original).
- alignment (right, center, left, justify) of the text should apply in a
way as that the path is the whole line
I haven't looked into that yet, but I think I agree; whether this is easy/possible to implement in SVG is another matter. SVG textpath has one feature that really drives me mad: when a text is too long for its path, the spec says that the rest of the text must not be shown! (Instead of e.g. continuing along the direction of the last path segment.) I think this is really stupid and ugly, but we must obey if we are to be compliant.
One more aside note: Inkscape is the only SVG renderer that I tested fully implementing the correct character positioning algorithm from the spec. Others apparently use a simpler and less correct algorithm. This can be seen with paths that have sharp corners: in Inkscape, as you move text along such path (e.g. by kerning it forward bit by bit), each letter "flows around" a sharp corner smoothly; in all other renderers, it "jumps" so that there's always a large gap between letters over such a sharp node.
- put text not only on a path but also with a offset, underneath and
centered... you know... :)
That's what moving text and kerning is for. You can move text off the path a bit, or you can go to the first char of the text in text tool and press alt+up a few times to vertically shift all characters (perpendicular to the path in each point). Horizontal kerning also works. It's very flexible.
On Sa, 2004-10-16 at 17:47 -0300, bulia byak wrote:
- the menu item should be grayed out, as long as not a text _and_ a path
are selected
Sure, when we implement graying out for menu items in general, we won't forget about this one
- once I put the text on the path, I can move it around, but it's still
dependend on the shape of the path.
This is as designed. It adds flexibility. I agree that it may feel a bit strange at first but I don't want to remove this capability. If only because other programs may create SVG with text thus moved from its path, and we must be able to view and edit these files.
It does feel strange, and I agree that it's nice to have but then you should be able to move the path as well without moving the text.
- while I can move the text around, I can't move the path without the
text following
Yes, because the relative position of path and text is stored in the text, not in path (if only because you can attach more than one text to one path).
can't both objects have absolute positions? If i want to move both, I select both.
don't make the text movable
Disagree, see above
and make the path visible if the text is selected, as a blue line or such, so that even when the path is invisible, you can easily edit it.
I don't think this is really necessary. If your path is invisible, you can still select it by selecting the text attached to it and pressing Shift+D (same key as for finding a clone's original).
True, didn't even know, since I'm not using clones really. But since _I_ didn't know, using inkscape quite a bit, I feel that for this part the path should be some color... or inverted or what ever when the text is selected.
This could generally be done for paths without outline, when they are selected, id doesn't have to though, since usually you don't have invisible paths with no filling.
- alignment (right, center, left, justify) of the text should apply in a
way as that the path is the whole line
I haven't looked into that yet, but I think I agree; whether this is easy/possible to implement in SVG is another matter. SVG textpath has one feature that really drives me mad: when a text is too long for its path, the spec says that the rest of the text must not be shown! (Instead of e.g. continuing along the direction of the last path segment.) I think this is really stupid and ugly, but we must obey if we are to be compliant.
That _is_ quite stupid... is there a possibility to file a bug against the specs?
One more aside note: Inkscape is the only SVG renderer that I tested fully implementing the correct character positioning algorithm from the spec. Others apparently use a simpler and less correct algorithm. This can be seen with paths that have sharp corners: in Inkscape, as you move text along such path (e.g. by kerning it forward bit by bit), each letter "flows around" a sharp corner smoothly; in all other renderers, it "jumps" so that there's always a large gap between letters over such a sharp node.
good job, I don't know any other svg program, but it's really smooth! it's also very fast.
- put text not only on a path but also with a offset, underneath and
centered... you know... :)
That's what moving text and kerning is for. You can move text off the path a bit, or you can go to the first char of the text in text tool and press alt+up a few times to vertically shift all characters (perpendicular to the path in each point). Horizontal kerning also works. It's very flexible.
well, it doesn't really give you the desired effect because you have to do all the horizontal kerning manually... (all the letters and a being chuncked together and spread apart) basically the feature should put the text onto an outset path of the original path.
This is as designed. It adds flexibility. I agree that it may feel a bit strange at first but I don't want to remove this capability. If only because other programs may create SVG with text thus moved from its path, and we must be able to view and edit these files.
It does feel strange, and I agree that it's nice to have but then you should be able to move the path as well without moving the text.
This is only possible via a mechanism similar to the one used for clones to stay put when their original moves. This is quite a bit of additional code, and I'm not convinced that it's really that necessary. Anyone else has an opinion?
I don't think this is really necessary. If your path is invisible, you can still select it by selecting the text attached to it and pressing Shift+D (same key as for finding a clone's original).
True, didn't even know, since I'm not using clones really. But since _I_ didn't know, using inkscape quite a bit, I feel that for this part the path should be some color... or inverted or what ever when the text is selected.
It even shows a tip on Shift+D in the statusbar. As for highlighting paths, maybe, but we don't have infrastructure for that currently. It's a lot of work to make this possible.
This could generally be done for paths without outline, when they are selected, id doesn't have to though, since usually you don't have invisible paths with no filling.
You can switch on the bbox selection cue in prefs and this will give you at least a box for an invisible path.
I haven't looked into that yet, but I think I agree; whether this is easy/possible to implement in SVG is another matter. SVG textpath has one feature that really drives me mad: when a text is too long for its path, the spec says that the rest of the text must not be shown! (Instead of e.g. continuing along the direction of the last path segment.) I think this is really stupid and ugly, but we must obey if we are to be compliant.
That _is_ quite stupid... is there a possibility to file a bug against the specs?
Probably. I don't know how, though.
well, it doesn't really give you the desired effect because you have to do all the horizontal kerning manually... (all the letters and a being chuncked together and spread apart) basically the feature should put the text onto an outset path of the original path.
What prevents you from making a linked offset of the original path, outsetting it, and putting text to it? I.e. every component of what you need is there, you just need to combine them for your purposes.
Generally, I prefer to not make "compound" commands like this (unless the advantages are too high to ignore), because this just clutters the interface, often requires ugly hacks and special cases in code, and makes _understanding_ the interface more difficult. I think the program should provide a set of well-thought-out building blocks, so you are free to use them in any combinations you want.
I love the text on a path feature and I'm still exploring the way that it works. However, on a tangent I'd like to mention that I would like to see the same feature working with objects in general. In the same way that we can group objects and make patterns of them, I would like to be able to take the same objects and duplicate them and fit them to a path. A bit like a poor mans Xara system. In the long term of course an object hose a la Xara would be wonderful, but in the meantime the various bits appear to be there to use objects on a line. Any comments? Is it worth putting inan RFE for this?
vellum
participants (3)
-
bulia byak -
David Christian Berg -
vellum