I want to be able to merge incoming text fragments from an EMF file
a <text> object which might have multiple lines. The idea is that
something like "E=mc2" (formatted properly)
is editable immediately on import into Inkscape even though it might
have appeared in the EMF as the strings
"E","=mc", and "2". (Currently EMF import leaves them like that, which
is miserable to edit.)
One can get the right look using vertical and horizontal kerning.
(Figuring out super/subscript would be
awful, since those properties are not explicitly noted in the EMF
However, while the resulting text object looks normal, the editing is
For instance, for testing purposes, here an example of some text that
might have been imported from an EMF (the original dx/dy was simpler and
there were more tspans, but this is what inkscape simplified it down
dx="0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -60"
dy="0 0 0 0 0 0 -9 0 0 9 0 0 0 0 0 6 0 0 18"
style="font-size:17.5px">simpleSupsimpleSubNext long line blah
What displays is (use a fixed width font and imagine Sup and Sub are
Next long line blah blah blah blah
Now the bizarre part. Place the cursor before the "s" in the first
"simple" (AKA, before the first
letter) and move right with the arrow key. Until the last letter in
the first line is hit
any editing operations in the cursor take place in the first line.
However, after the
"b" the cursor jumps back to line up with the left edge of the "N" -
but stays in the first row.
(That is, it respects the dx information, but ignores the dy
information.) Enter a key there
and it appends after the final "b" in the first row - there does not
seem to be any way to enter
letters before the N on the 2nd row. Move the cursor one more position
right and enter a character and then it is entered into the 2nd row.
Move the cursor all the way
to the right and add characters and they append to the end. Press
return or shift-return
and the text to the right is shifted back and over the the first
character ("s" in the first "simple").
Ie, it acts like the classical CR without LF if there is only one row,
much stranger in the two
row case (try it right after "line").
Is all of this intentional? Naively since the dx/dy are all relative I
would have thought that pressing
"return" would have changed a kern at that location, (0,0) (for
instance) to (-M,+LS), where M is the
offset to line up at the start of the first row on X, and LS is the
Clearly all of this is related somehow to the kerning. So text ->
remove manual kerns. That reduces the two line
case to a single line. However, it does not resolve the bizarre CR
without LF effect - even though all of the kerning
has been eliminated.
Start a new text object and it edits normally, with a "return" acting
like both a CR and LF.
The difference between the two cases seems to be the presence of
in the tspan of the one that works. Adding that to the de-kerned text
makes it behave "normally".
However, adding it to the <tspan> in the svg above still does not work
quite right. Pressing a return
in the top row breaks the text exactly as expected, but doing so in the
second row moves the
fragment to the right, not to the beginning of the first row (as
before), but to the same place text moves
when the first line is broken in this manner.
So a little guidance would be helpful.
Is there something that could be added to the svg above, so that it is
editable like normal text?
If not, are these strange editing outcomes a bug or a feature?
Why is it that Inkscape cannot edit text "normally" unless the
sodipodi:role="line" is present?
Manager, Sequence Analysis Facility, Biology Division, Caltech