Multi-line text object in plain SVG behaves strangely after re-opening

[Brianna Laugher]

I have an SVG with a text object that has newlines in it (to simulate text fitting in a column, "wrapped" text).

If I save that file as an Inkscape SVG and re-open it, I can edit the text objects fine, e.g. insert more newlines.

But if I save it as a plain SVG and re-open it (in Inkscape), the text object behaves very strangely:
* I can't press the up and down arrows amongst the different lines of the single text object (I can go right and left)
* inserting a newline in an existing line of text, causes it to write over the start of the same line. It also causes the text object to separate into two different text objects!

So I don't know if this is an expected consequence of plain SVG, or a bug...

This is Inkscape 0.46, built 7 April 2008

[Alvin Penner (apenner)]

running Windows XP, I cannot duplicate this problem, either on Inkscape 0.46 stable version or on the development version.
- could you specify the OS ?
- attach the .svg file that you are using?

[Brianna Laugher (brianna-laugher)]

Using Xubuntu 8.04.

[Alvin Penner (apenner)]

- confirmed on Windows XP, build 21210
- when I create new text in your svg file, it behaves as expected, with up/down arrow movement and appropriate new lines generated.
- when I attempt to edit the existing text in your .svg file, then I get the same behaviour as you described.
- I hate to ask this, but could you also submit the 'Inkscape svg' version that still works properly?

[Alvin Penner (apenner)]

thanks for the file, I was able to duplicate the problem again with this, Windows XP, build 21210.

[David Mathog (mathog)]

I just ran into this problem in another context and will be appending to this bug rather than filing another. The difference between the broken edit and the working edit is caused by the presence of

  sodipodi:role="line"

in every tspan in the working example. Add that to the tspan's in the "broken" set in the attached example and editing there will then work as expected.

What I don't understand is why this line is needed. Under what circumstances would one _ever_want the broken editing behavior???

On a related note concerning editing, is there now a method to fuse or break apart text objects? Symbolically these would be:
   [A] [B]->[AB]
and
  [AB] -> [A] [B]

The first would be (simple example)
 <text><tspan>A</tspan></text> with
 <text><tspan>B</tspan></text>

becomes
 <text><tspan>A</tspan> <tspan>B</tspan></text>

and the latter is (| being the point where the cursor lies)

  <text><tspan>A|B</tspan>C</text>

becomes

  <text><tspan>A</tspan></text>
  <text><tspan>B</tspan>C</text>

or

  <text><tspan>A</tspan>|<tspan>B</tspan>C</text>

becomes

  <text><tspan>A</tspan></text>
  <text><tspan>B</tspan>C</text>

and so forth.

When importing formatted text software can make guesses about what pieces should be one text object, but it cannot get it right every time. (For instance, three equally spaced lines, left justified, might be a paragraph that wrapped, which should be one text object, or it might be 3 text labels, which should be separate text objects.) These (missing?) commands would provide a way to fix any mistakes which the automatic conversion might have made.

Inkscape r11664.

[David Mathog (mathog)]

Here is another example using centered text. Again, all that it takes to convert the BROKEN part to make it work
is to put
          sodipodi:role="line"
in every tspan.

[David Mathog (mathog)]

A few other observations:

1. The code has three states enum'd: SP_TSPAN_ROLE_LINE, SP_TSPAN_ROLE_UNSPECIFIED, and SP_TSPAN_ROLE_PARAGRAPH. The last one seems not to actually be used anywhere.

2. The function, near as I can tell of SP_TSPAN_ROLE_LINE is to mark those <tspan> which are the first in a line. Subsequent <tspan> in the same line (ie, horizontal line of text, like the one you are reading now) do not need this tag. This information is later used if a line is split to set the X,Y position of the both fragments (both because for center justified both pieces have to move.) It is also used for cursor motion - there is no way to move the cursor down to a second line, lower in Y, unless there is a "sodipodi:role=line" tag preceding that section of the text.

3. The difficulty with text post "remove kerning" results because standard SVG has no: sodipodi:rule="line", and inkscape text editing seems to assume that these are present.

4. If there is no "sodipodi:role=line" pressing RETURN splits the line into two <text>. If there is a "sodipodi:role=line" present then whichever <tspan> the cursor was in is split instead. To my mind, if there is no explicit "line", then the code should act as if there was an implicit one on the first <tspan> in a <text>.

5. The ability to split a <text> to two <text>s is a desired feature, but it should not depend on the presence or absence of the sodipodi:role="line" tag, but should be the result of something like "ctrl-return" or "shift-ctrl-return".

The simplest fix for the kerning problem is probably to force the code which reads SVG into Inkscape to add a
sodipodi:role="line" tag to the first <tspan> in each <text>.

[David Mathog (mathog)]

The attached example uncovers what appears to be a rendering bug in Inkscape (all versions tested). When the 2nd line
(as indicated by the second <tspan> with a sodipodi:rule="line") is offset using the dy mechanism, it does not fall in the same
place as if they "y" mechanism was used. However, edit one of these, and the cursor moves like it should. Screen shot
of the incorrect render in next post.

As for editing, even though this example is formatted like:
<text>
<tspan sodipodi:rule="line">stuff</tspan>(<tspan>other stuff</tspan>)*
<tspan sodipodi:rule="line">stuff</tspan>(<tspan>other stuff</tspan>)*
<tspan sodipodi:rule="line">stuff</tspan>(<tspan>other stuff</tspan>)*
</text>

It does not edit properly. Put the cursor in one of the tspans past the first and hit "return" and the block
of text will not move properly. It does move properly for the first tspan in each line.

[David Mathog (mathog)]

Note that the multiline_issues.svg example does work properly with the left,center, and right justify buttons, and that
after those buttons are applied the cursor motion is still correct.

[David Mathog (mathog)]

Here is one way to write SVG using kerning that Inkscape will edit correctly. The trick is to wrap all of the <tspan></tspan>
pairs on a single line with an outer <tspan sodipodi:rule="line">(all the other pairs)</tspan>. The attached example is like that and it seems to have few if any editing problems. One could argue that what it does for a "return" when the cursor is inside a vertically kerned section isn't right. Rather than moving the baseline of the remaining line down to the next baseline, it moves
the baseline of the vertically kerned section down to the next baseline. This drops a superscript to the baseline, and drops the baseline text below the baseline.

[David Mathog (mathog)]

Text editing operations on vertically kerned letters do not always do the right thing. In the attached example there are some vertically kerned letters. (-6) followed by a correction back to the baseline (+6). If a kerned' letter (selection all -6)
is deleted the following +6 is not corrected. However, if the vertical kerning for that letter is set back to 0, then the +6
is also set back to 0. Similarly, line breaks entered into kerned regions pick up the kerning rather than operating from the baseline.

[David Mathog (mathog)]

Screen shot of the following example.
Inkscape version was r11664.

[Joel Obrecht (joel-obrecht)]

Still with this bug in 2015???

It is especially annoying for a webdev, who needs to clean up his svg files for web publication, then has a lot of text modifications to do like for instance translations. It is already annoying to have the tspan workaround because of browser and Inkscape non support of foreignObject tag which would provide support for text flow... And to need to reedit lines for each new file... Anyway...

This message to complete former information with a lacking point:

In order to re-edit the texts in files saved in plain svg in Inkscape, here's what you need to do :

- First add the sodipodi namespace, paste this in the svg tag :
   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"

- Then proceed to a replace, for instance editing the svg code in geany,
from: <tspan
to : <tspan sodipodi:rule="line"

Save, and done, it works. Thanks to all in this thread for providing this solution, and hope for a fix soon. A quick fix could be to keep sodipodi rule line in plain svg save...

In case of need my specs:
Archlinux
Inkscape 0.91

[Joel Obrecht (joel-obrecht)]

EDIT to my last comment:

You can work the text properly and it looks fine in Inkscape, but when you save it, either in plain or in Inkscape format, Inkscape doesn't reposition the tspans. By this I mean that whenever you added newlines you have overlapping tspans when you view it in firefox or edit it again in Inkscape.

Example code:
<tspan
         sodipodi:role="line"
         id="tspan13033"
         y="1212.197"
         x="945.15912">✗ J'entre les données et les catégories dans le tableau de bord sur </tspan>
<tspan
         sodipodi:role="line"
         y="1212.197"
         x="945.15912"
         id="tspan3412">monsite.org</tspan></tspan>

So now the only solution as far as I know is to edit all code manually, calculating myself the tspans y values.

My advice would be never to use another format than Inkscape's and not to use scour plugin either. The best option would be to have a custom scouring script that doesn't remove the ability to edit texts afterwards, if this is possible.

[David Mathog (mathog)]

Out of curiosity, if you save the SVG that is giving you problems in EMF format does it reimport properly back into Inkscape? I think 0.91 has the cross platform EMF support. The reason I ask is that on export SVG to EMF the spans must be broken down into separate text chunks anywhere there is a line break or font modification, but on re-import they pass through libTERE (TExt REassembler), whose sole function is to recognize bits of aligned text and reassemble them into an editable text object. It should work with French, not so much with Indic languages.

[Joel Obrecht (joel-obrecht)]

I gave to your suggestion a bit of testing. The emf import works not really great, the text is messed, a path has lost its color, ... So it's no use here I'm afraid...

What is strange, is that for this testing purposes, by doing the change again on my home computer, adding the sodipodi namespace, performing a replace on all tspans in vim to add role="line", I found that now FIrefox shows them properly and Inkscape edits and saves them properly as well. I cannot figure out what was different on the other computer or what thing I made to have this behaviour (on the other computer I used geany to edit the svg, on this one vim...).

I guess then my problem is solved.

In the meanwhile, I was looking for a vim solution, and found one :
http://stackoverflow.com/questions/33317532/vim-search-replace-regex-incremental-function

:let i=300 | 323,$g/y="/smagic![0-9]\+.[0-9]\+!\=i!g | let i+=50

Enables, in Vim, to re-position all the vertical tspans by increment. It works quite fine, you choose in the first let the initial positioning and in the last let the distance between two tspans.

With Firefox's auto-reload addon it is quite straightforward to find the good values with a bit of testing.

[David Mathog (mathog)]

Regarding the EMF problem, could you please post the test file (SVG), whatever options you used on EMF export, and the version number and platform for the Inkscape employed? The most likely cause for a color change is that the opacity was not 100%. EMF pen definitions do not support transparency, so any color seen in the SVG is exported as 100% of that color, which can make a "pink" or a "rose" into a "red". Text should never move or resize appreciably on an SVG->EMF->SVG cycle, if that is happening, there is a bug somewhere.

[Joel Obrecht (joel-obrecht)]

Dear all,
Just to share my sed scripts that enable to make scoured or plain svg files again editable in Inkscape :

cd /home/user/my/svg/files

sed -i.bak 's|<svg|<svg\nxmlns:xlink="http://www.w3.org/1999/xlink"\nxmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"|g' *.svg

This runs on all svg files in the current folder and :
1. Creates a .bak file which you can rename to svg in order to get your original files (but I nevetheless strongly advocate to duplicate your worrking folder in order to avoid terrible mistakes when fiddling with sed)
2. Adds the correct namespaces with newlines (\n)

sed -i.2.bak 's|<tspan|<tspan sodipodi:role="line" |g' *.svg

This appends sodipodi:role="line" to all tspan tags in the current folder and creates file.2.bak backups.

It takes two seconds and it is done.

Regarding the EMF problem, could you please redirect me either to an existing bug thread or adice me to create a new bug thread ?

[David Mathog (mathog)]

Please post it as a new bug and add me to the list of people to be notified. Until I see an example I could not tell you if there is already an open bug addressing it.

[su_v (suv-lp)]

Related reports (same symptom: <tspan> elements which represent lines in a multiline text do not have editing information):
* Bug #276456 “Extension bug at creating text elements”
* Bug #1514050 “Cannot type newline in text objects”

[FataL (fatal-mail)]

My case: I exported SVG from CorelDraw and wanted to continue editing it via Inkscape, but all the text can't be edited normally.

P.S. Subscribed people should click on "This bug affects me" link in the header of this ticket.

[Patrick Storz (ede123)]

Closing in favour of migrated bug #167904.

Closed by: https://gitlab.com/ede123
Moved to: https://gitlab.com/inkscape/inbox/issues/248

[David Mathog (mathog)]

On 27-Mar-2019 15:27, Patrick Storz wrote:
> Closing in favour of migrated bug #167904.

That is fine.

Regarding:

> Bug description:
> I have an SVG with a text object that has newlines in it (to simulate
> text fitting in a column, "wrapped" text).
>
> If I save that file as an Inkscape SVG and re-open it, I can edit the
> text objects fine, e.g. insert more newlines.

If that has happened accidentally in the past and there is no older
version of the file to recover from it is still possible to reassemble
the text object. Do this:

1. export to EMF and then close the document
2. import from EMF into a new previously blank document
3. save as Inkscape's usual SVG

EMF has nothing like Inkscape's multiline text object so complex text in
that format was always a mess on import into Inkscape - it was all in
little bits and pieces. Because of this EMF (and WMF) import go through
libTERE, (TExt REassembly) specifically to put it back together again.
It doesn't always work, but it does most of the time. At least, that
was the case the last time I touched any of this code, which was
admittedly not recently. The rules libTERE follows are basically that
if it looks like a paragraph of text, it is a paragraph of text. It
also tries to assemble mathematical formula. Text on any sort of curved
path or at different angles will not be reassembled.

Regards,

David Mathog
<email address hidden>
Manager, Sequence Analysis Facility, Biology Division, Caltech

[tbnorth (terry-n-brown)]

Closed by: https://gitlab.com/ede123