LaTeX text displaced (save as PDF/EPS+LaTeX)

[Peter Kobel]

When i export my drawing to eps+LaTeX or pdf+LaTeX the text, meant to be replaced by LaTeX, is not there, where it should be. I got a drawing with five text-objects, which are aligned in Inkscape so that it looks good. The font, i choose in Inkscape is similar to the used LaTeX-font. After the export and integration in my LaTeX-document, it looks as follows: one textobject is nearly placed like in Inkscape, two textobject, which are close together, are moved to the left; one has moved up an the last one has moved down.

This problem appeared after some changes in the drawing, in the first run it was all OK. Reopening the drawing doesn't help, rerun LaTeX neither.

I run Inkscape 0.48.0-1 on Windows 7.

[su_v (suv-lp)]

> This problem appeared after some changes in the drawing
Could you please attach the SVG file and the exported files for further investigation?

[Peter Kobel (kobilot)]

OK, now it becomes weird: when i prepared the example for you in another folder on my PC, but with a copy of the files (all the same: the drawing, the eps and png and my LaTeX-file), things worked very fine. Another run after copying the files back reproduced the displacement of the text. So maybe it's not a problem with Inkscape, but with LaTeX and my folder structure. I'll run some more tests and post a comment afterwards.

[Peter Kobel (kobilot)]

Ok, since my last posting all things went fine, with different files and changes. So i cannot determine the circumstances, which produce the failure, anymore.

[Paul van der Hulst (paul2-abulafia)]

Hello,

I have the same problems, the text is printed too low. A demonstration (I run miktex/texworks) will be attached

Paul

[Peter Kobel (kobilot)]

Good evening,

I still don't know, where the problem came from, but now it works fine with pdfLaTeX. I tested your data and it works too in pdfLaTeX, after i opened it in Inkscape and handled the file in my way (i only changed the papersize in Inkscape).

I never did before, but now i tested the Inkscape-files with plain LaTeX too and the text IS displaced again! After one houre, i can state, that this happens only with dvi-files (and with pdf and ps made from it), so maybe this bug is due to LaTeX (too). I thought it is usefull, if i am able to make pdf and dvi files which are all the same, but now i got to realize that it doesn't work (with dvi). So, dear Paul, maybe it works for you using pdfLaTeX.

How i handle Inkscape and LaTeX:
- drawing the picture
- resizing it to its content (nothing is selected and in File/Document settings/Page there is a button like "fit page to selection" (i don't know the english caption since i use the german version)
- saving it
- using the commandline-script for the export (it calls inkscape and makes an eps and a pdf, then calls a jar-file, which changes the name.xxx_tex (xxx of pdf, eps, ps) to name.tex, so that i am able to use only \input{name} and plain LaTeX or pdfLaTeX; furthermore it puts a % at every end of line, because otherwise i get unexpected figure sizes in LaTeX)
- building the document.

Best regards, Peter.

Attachment: incscape.zip, containing: 00-exportsvg.bat, ~.sh, ~README-eng.txt, ~tune.jar (written by a friend of mine, i hope he doesn't mind me publishing it), 00-Inkscape-commandline-eng.txt, nolinear.eps, ~pdf, ~svg, ~tex, September 2010.dvi, ~.pdf, ~.ps, ~.tex

[Peter Kobel (kobilot)]

Good evening the second,

now i got the solution: don't take eps but ps and it will work (i changed the scripts therefor). It works with pdf in pdfLaTeX and ps in plain LaTeX but not with eps, so i guess this is a bug in inkscape.

Regards, Peter.

[Peter Kobel (kobilot)]

Going, going, gone!

I forgot two things:
1. My system: Windows7 Professionell 32bit with MikTeX 2.7 (last update: 08/2010) and Inkscape 0.48.0-1, the jar-file was also tested under debian 2.6.32 (but the bash script will work too).
2. All the Windows command line script, the bash script and the jar file comes without any kind of warranty, even not, that it will work.

Best regards,
Peter.

[Paul van der Hulst (paul2-abulafia)]

In Texworks I'm using pdflatex.
However I assume that when you say that everything works when using pdflatex, you're using a pdf graphic generated by inkscape. This is not my workflow, I use epstopdf which autoconverts eps files to ...-eps-converted-to.pdf which are then used as graphics input for pdflatex. This means my pdf workflow uses the eps-tex file generated by save to eps in inkscape.

For eps I found and 'solved' the problem: I noticed that the picture (only the graphical elements) was too large when inserted. The reason is that this picture with text in inkscape is larger than the eps bounding box around only the graphical elements. In inkscape the text extends to the left of the graphics, but this section is clipped by the bounding box. Because the bounding box was narrower than intended, latex prints the figure larger than it should be, thus it seemed that the overlayed texts were misplaced, but actually they were correct, the graphics were wrong.
This seems to be related to the options 'export area is drawing' and 'export area is page'. These do not seem to do much for eps (these also should be radio buttons, see also bug #499965)
Anyway, I think that when eps+latex is selected the default bounding box should be the complete picture before stripping the text. This may violate eps specification though.
When an additional graphic element (line) is added such that the bounding box will enclose all the text, the test is placed correctly.

ps files behave correct.

For the pdf+latex export I suspect the default state (after a 1st time installation) of bounding box calculation is not reflected by the 'export area is page' and 'export area is drawing' checkboxes.
Originally I got a full page pdf, with both boxes checked. The labels were placed correctly, but the figure was too small.
After toggling them to and fro a few times, I now get only the drawing (with some additional room on the left side) when selecting 'export area is drawing' or both boxes checked (which is also reported in #499965)
This fixes the remaining pdf issue

All in all this problem seems not to be the same as your original issue. It does reveal some pretty annoying issues in inkscape in the first 24 hours that I'm using it
1) checkboxes which should have been radio buttons
2) incorrect bounding box calculation
3) eps generation through save as (leaving the working document as eps, not the source svg) This should be export
4) no export 'selected only' option

Thanks for your support though.
Paul

[su_v (suv-lp)]

> 1) checkboxes which should have been radio buttons

Bug #499965 “"exported area is the drawing" and "exported area is the page" aren't alternative in export”:
<https://bugs.launchpad.net/inkscape/+bug/499965>

> 2) incorrect bounding box calculation

Please read <http://wiki.inkscape.org/wiki/index.php/Release_notes/0.47#PDF.2C_PostScript.2C_and_EPS_export> for details about Inkscape's cairo-based export to PS/EPS/PDF:
«Note, the specification of the EPS format does not allow a bounding box to extend beyond the content. This is enforced by the Cairo graphics library which means that when --export-area-page is used with EPS export, the page bounding box will be trimmed inwards (but never expanded outwards) to the bounding box of the content if it is smaller. If you want a file which has a %BoundingBox different from the bounding box of its content, you can use PS or PDF export formats instead of EPS, or add a white background rectangle with the required size to source document before exporting to EPS. »

Related report (ignore the EPS specification and allow to create EPS files with larger bbox than the drawing contents):
Bug #380501 “eps export always sets bounding box to drawing, never to whole canvas”
<https://bugs.launchpad.net/inkscape/+bug/380501>

> 3) eps generation through save as

Bug #171054 “PDF better under "Export" than "Save As"”
<https://bugs.launchpad.net/inkscape/+bug/171054>
Blueprint "Sort out Save as vs Export formats"
<https://blueprints.launchpad.net/inkscape/+spec/save-as-vs-export>

> 4) no export 'selected only' option

Bug #168627 “RFE: 'export selection' to vector formats (PDF, eps,...)”
<https://bugs.launchpad.net/inkscape/+bug/168627>

Overall the originally reported issue seems related to or a duplicate of
Bug #595821 “EPS+LaTeX wrong size when text outside other drawing objects”
<https://bugs.launchpad.net/inkscape/+bug/595821>

[Paul van der Hulst (paul2-abulafia)]

This seemed to be the right place at first, but after some discussion here my problems turned out to be unrelated.
I did say so in my previous post by the way.

>1) I already pointed out that bug reference.

>2 I did mention violating eps specification.

>3,4 Just expressing some inkscape annoyances I ran into in such a short time. Wasn't meant as official bug report, yes it was off-topic, belonged on a social site.

Paul

[su_v (suv-lp)]

@Paul -

> >3,4 Just expressing some inkscape annoyances I ran into in such a
> short time. Wasn't meant as official bug report, yes it was off-topic,
> belonged on a social site.

Didn't want to imply that, just provided additional links... ;) Thank you for taking the time to closer investigate the reported issue(s) and providing details about your findings!

[Bernhard (drahnreb)]

I'm just automating the inclusion of svg files in lyx using this machanism in a way that i can typeset the text in lyx that is printed on the image and got the same problem.

I think i can tell you what the reason for the wrong scaling is: The whole computations that are done in inkscape for the export (image size, text positioning) are done with the original svg image. But the dvi is generated from the svg without text. Thus if the image with text is larger than without the scalings don't match because the bounding box of the eps file will be smaller as mentioned above.

Bernhard

[Bernhard (drahnreb)]

Imho it would be good if the whole export and the bounding box would be based on the image without text because otherwise the image can contain large empty margins that will not look very good in the latex document.

bernhard

[Bernhard (drahnreb)]

ok, i just saw that paul in comment #8 had already described the reason...sorry for the noise

i want to clarify that in my comment #13 i talk about all types of export+latex (pdf, ps), but maybe i should open a new bug report for that

bernhard

[su_v (suv-lp)]

@Bernhard - see also the related discussion in
Bug #595821 “EPS+LaTeX wrong size when text outside other drawing objects”
<https://bugs.launchpad.net/inkscape/+bug/595821

[Andrzej (ndrwrdck)]

I might have come across this bug some time ago (v0.48+) (unfortunately, I don't have the data atm).

AFAIR, I was seeing this behavior in some of the labels imported from other formats (ps, ...). The labels were wrapped with an object (visible in the xml editor). They behave normally in Inkscape, but during export to pdf/eps+latex align left/right/center properties were wrong (in the .pdf_tex file). This of course resulted in different positioning of labels in the ps/pdf file.

[Michael Schöll (3-michael-w)]

I have a similar/the same problem when exporting to PDF and LaTeX and figured out, that in my scenario only rotated text-boxes are affected. Find attached the svg-File generated to reproduce the problem, a screenshot from inkscape and from the generated PDF-file.

My setup:
Linux Mint 17 Qiana, 64bit
Inkscape 0.91pre2 r
Export from commandline: inkscape -z -D -f file.svg --export-pdf=filepdf --export-latex

[Michael Schöll (3-michael-w)]

Just to clarify: by text-boxes, I meant text in <flowRoot>, as opposed to text in <text>. For the flowRoots, the generated latex-code includes minipages. The width of these minipages are as well as the positions are wrong when the text is rotated. I hope, this information helps to track down the problem.

[Michael Schöll (3-michael-w)]

Comparing the functions LaTeXTextRenderer::sp_flowtext_render(SPItem * item) and LaTeXTextRenderer::sp_text_render(SPItem *item), I think, I further tracked down the problem to two small bugs:

1. In sp_flowtext_render, the anchor is not used to calculate the position after rotation. Instead, the upper left edge *of the bounding box* of the the rotated framebox is used. This causes the text to be placed erroneously. I suppose, the anchor must be used just like in sp_text_render.
2. The width of the minipage is calculated uncorrectly as the width of the rotated framebox, but must be the original width.

There is quite some code duplication in these methods, maybe a refactoring could improve code quality when fixing this bug?