eps+latex/pdf+latex export (v0.48): newline characters in svg not followed in LaTeX

[armando sano]

When exporting a svg figure as pdf+latex or eps+latex and recomposing the figure in a LaTeX document, some problems arise if text in the svg figure has been written with newline characters. Indeed, such newline characters are reproduced verbatim in the associated LaTeX file pdf_tex or eps_tex, which LaTeX doesn't interpret as newline characters, but as blank space. As a result, the newline characters in svg become equivalent to a blank space in LaTeX and the layout in LaTeX is not the same.

[su_v (suv-lp)]

Duplicate of bug #687344 “missing "%" characters in pdf_tex file”?

[armando sano (armando-sano)]

No, bug #687344 is a different issue. Here one would like newline characters typeset in inkscape to be reflected as some sort of \newline command in LaTeX. Bug #687344 is rather a LaTeX-only feature: it is interpreting newline characters issued after a LaTeX command (if not immediately followed by the comment identifier %) as an blank space, thus offsetting whatever comes next.

[Michael Jäntsch (michael-jaentsch)]

As I experienced the same issue, I therefore started digging into the code. I realize that you have already addressed the issue in the newest repository version. However, the solution implemented there does not compile in latex (no '\\' in the makebox environment). This is obviously related to Bug #898351.
I rewrote the sp_text_render function. Find the patch attached. I hope this helps and maybe my work will find its way into the next release. It works for my use case and several tests with multiline text elements, including italitcs and bold text. Note that I assume that text spans (as you call them) always end with a newline which the current implementation doesn't. This was always true in my examples but I can't be sure because I don't know the definition of a text span.

[mporten (mathias-porten)]

Can confirm, that the work around of Michael Jäntsch works for me, changed tex file manually regarding patch. This bug still occurs in 0.91 branch.

[Tetsuya Suga (tsuga)]

I also confirm the bug. Then, the patch by Michael Jäntsch (michael-jaentsch) posted on 2012-04-10 works. (I recompile with the patch applied.)

Why not publish the patch to the repository?

[jazzynico (jazzynico)]

> Why not publish the patch to the repository?

Unfortunately we forgot about the report and nobody in the dev or bug teams reviewed the patch.
Targeting to 0.93 to be sure we don't lose it again.

Thanks for the reminder!

@Johan - The report is currently assigned to you. Could you please confirm you still plan to review the patch or work on the bug? Thanks.

[Tetsuya Suga (tsuga)]

Thank you for pushing this up to the next milestone release.

@Michael - I have a question. I noticed that your patch posted on 2012-04-10 has an interesting behavior.
If I type
====
Line1
Line2
Line3
===
in a text element in inkscape, the exported code looks like
\shortstack[c]{\smash{Line1}\\Line2\\Line3}}
Why only the first line ('Line1') is wrapped by \smash ?
Do you have any intention to wrap only the first line?

Thank you in advance.

[Michael Jäntsch (michael-jaentsch)]

Hi,

I am not exactly sure anymore. This has been 5 years go. I explored the
possibilites back then. And I believe it had to do with where the anchor
for the text ends up. It is supposed to be on the baseline of the first
line in my opinion. The solution I posted worked for multiline text with
any alignment. This is what worked best for me. Hope this helps.

Michael

On 01/24/2017 03:23 PM, Tetsuya Suga wrote:
> Thank you for pushing this up to the next milestone release.
>
> @Michael - I have a question. I noticed that your patch posted on 2012-04-10 has an interesting behavior.
> If I type
> ====
> Line1
> Line2
> Line3
> ===
> in a text element in inkscape, the exported code looks like
> \shortstack[c]{\smash{Line1}\\Line2\\Line3}}
> Why only the first line ('Line1') is wrapped by \smash ?
> Do you have any intention to wrap only the first line?
>
> Thank you in advance.
>

[Patrick Storz (ede123)]

Fix for the issue commited in
https://gitlab.com/Ede123/inkscape/compare/f45c0191ca0797a39d98b0ddad3a79e6e1efad4c...82b42536b29ccb2f93f4bd156c7fa20367920348

(the first commit is the patch by Michael, the second commit fixes a related issue I found during review)

If no regressions are found I'll back-port this to 0.92.x soonish.

[Patrick Storz (ede123)]

Backported to 0.92.x in
https://gitlab.com/inkscape/inkscape/compare/c0ba38ff6418836b49d3835caf59231a73bdc58b...848936feb680e1c7205c89a2825fa75ad28ff932