inkscape --export-text-to-path - linebreak-bug with flowed text

[Frederick]

hello

i try to transform in the bash-console a inkscape svg file to a normal svg file

my text (inside the inkscape svg) looks like
+---------------+
| my text with |
| a line breaks |
| like this |
+---------------+

$ inkscape --export-text-to-path in.svg -l out.svg

when i do this in the bash, inkscape did not make the line break, like he will do perfect in the gui (with marked text, convert object to path)

i get the wrong result liks this

+----------------------------------------+
| my text with a line breaks like this |
+----------------------------------------+

i try this with the new inkscape versions Inkscape 0.48+devel r (Oct 6 2013), 0.48.4.90~siduction.2, Inkscape 0.48+devel r (Dec 19 2013)

thanks

[su_v (suv-lp)]

Reproduced with r11420 [1] and latest revision 12852 on OS X 10.7.5 - AFAICT the bug only occurs with flowed text (regular text with hard line breaks exports as paths to Plain SVG as expected).

[1] Revision 11418 introduced the new feature:
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/11418>
based on
- Bug #903772 “Support --export-text-to-path when outputting plain SVG”
  <https://bugs.launchpad.net/inkscape/+bug/903772>

[jazzynico (jazzynico)]

Reproduced on Crunchbang Waldorf, Inkscape trunk revision 13295.

[David Mathog (mathog)]

Using a very much simplified in.svg ran

src/inkscape --export-text-to-path /tmp/in.svg -l /tmp/out3.svg

(Will attach both files.)

Not only is the wrap lost, but the position on the page in out3.svg is different, in the latter the letters are closer to the upper left corner of the drawing surface in both x and y. The page size is the same in both files. The size of the letters is the same in both files.

This test:

src/inkscape /tmp/in.svg -l /tmp/out4.svg

produced an output file with the text in the same position in the output file as in the input file (not shown).

[David Mathog (mathog)]

in path_chemistry.cpp sp_selected_item_to_curved_repr() the transform is the same when run from the command line or through the GUI. In both cases:

matrix(0.28222223,0,0,0.28222223,378.98413,-3.2253969

however the paths produced by

            SPCurve *curve = te_get_layout(item)->convertToCurves(iter, iter_next);
// lines omitted
            gchar *def_str = sp_svg_write_path(curve->get_pathvector());

differ in the offset (as one would expect from in.svg vs. out3.svg) . The rest of the path is identical (again, as expected). The command line method for first letter "a":

16.09375,0 -2.96875,0

The interactive method for first letter "a"

501.80859,869.61719

I don't have time right now to work back from there, perhaps next week.

[David Mathog (mathog)]

Ah, now this is interesting:

src/inkscape --export-text-to-path /tmp/in2.svg -Y -l /tmp/out3.svg

and

src/inkscape /tmp/in2.svg -Y -l /tmp/out3.svg

yield different results, as does -X. But -W and -H are the same. The difference between the -Y/-X outputs is exactly the offset between the location of the first character and the final position of the first character when conversion to path occurs. If there are other elements in the drawing (rectangles and normal text were tested) they end up in the correct position, only the flowed text goes to the wrong place. But, if the input SVG has no flowed text elements (in5.svg) then

src/inkscape --export-text-to-path /tmp/in5.svg -Y -l /tmp/out3.svg

and

src/inkscape /tmp/in5.svg -Y -l /tmp/out3.svg

are the same!

[David Mathog (mathog)]

This patch fixes the problem - testing was not extensive, unknown if it breaks something else. It consists of adding a single instance of

                    doc->ensureUpToDate();

in main.cpp, and since it is in a conditional location, I suspect it really should be much higher in the code to cover other cases - but I'm not sure how to go about testing all of those variants. I will commit the current patch.

[David Mathog (mathog)]

Note, also resolves bug #1262792.

[David Mathog (mathog)]

Fix committed in revision 13406.