EPS+LaTeX wrong size when text outside other drawing objects

[[e-mail]]

Hi, I'm back and still happy with the ps+LaTeX feature!

to reproduce: draw a box, put some text outside the box in 12pt font. Use eps+LaTeX to export to foo.eps and foo.tex and include these in a LaTeX document containing:

\documentclass{article}
\usepackage{graphicx}
\usepackage{color}
\begin{document}
  \input{foo}
\end{document}

When inkscape exports it thinks the bounding box for the drawing is at the limits of the text, but the eps file is only aware of the rectangle. Thus, when combined in the LaTeX document the rectangle is oversized and the text is in the wrong place.

I fix this manually by drawing an invisible box, but it is more complicated than this. When I write $\alpha$ on the far right of my image, I expect this to render as the greek letter, which is shorter than $\alpha$. So the right end of $\alpha$ is not the correct bound for exporting the non-text part. Making $\alpha$ right justified allows me to export an eps that is not larger than the latex that I expect to be rendered... but no one wants to estimate...

my platform is mac OS X and this is 0.47+devel r9504

[Henry Gomersall (hgomersall)]

Yeah, I too have experienced the problem.

The problem is in the way the eps file is generated using Cairo, with text objects effectively ignored (and so the bounding box not being stretched by them), and then using the whole image to define the height and width of the image box. This has a knock on consequence to making the unitlength incorrect and so the whole thing buggers up.

I had a look at fixing it, but i'm not sure of the best way to do it. The definitions of the width and height in latex-text-renderer.cpp need to use the size of the exported ps and not the size of the document as inkscape thinks it is.

[Johan Engelen (johanengelen)]

I think this is inherently unfixable, which is why I left the bug as it is. I thought I had described it in my CTAN document, but apparently didn't, sorry for that. (it has been added to my todo list for that document :)
The reason why it cannot be fixed is that it is impossible for Inkscape to know the boundingbox of any text when eps/pdf/ps+latex is used. So only approximate bbox calculations are possible, and I'd rather have the user clearly see that Inkscape cannot do it.
Perhaps there is a better solution than drawing the invisible square, but I do not know it. (i think exporting "page area" also works)

[Henry Gomersall (hgomersall)]

> I think this is inherently unfixable, which is why I left the bug as it is.

Surely that's not true. A hack would be to read in the size of the bounding box from the written ps file, and use that as the basis for the height and width. The issue is not about knowing the bounding box of the resultant latex rendered text+image, but of knowing the bounding box of the image without any text, what comprises the actual exported eps file.

Incidentally, perhaps I'm a fool for not actually knowing how to draw an invisible square that gets included in a the eps file, but the only way I can get it to work is to use an *almost* invisible square, 0.1pt line at 0.1% transparency; anything else seems to get ignored.

[Henry Gomersall (hgomersall)]

I didn't note the original bug report had essentially 2 problems rolled up in one. The issue that I think can be fixed is the problem of having the height and width being of the inkscape drawing including the text, but the exported eps having a height and width excluding the text. This is arguably more serious as it causes the latex text to be placed in completely the wrong place, and sometimes well outside the image (since the unitlength definition is incorrect). The problem of the latex rendered text being unpredictable is almost impossible to fix! How on earth could you know the, for example, the font size.

[[e-mail] (alejandro-erickson)]

If in doubt, do what xfig does (since it is the program containing the feature we want). Here is a file in which the rendered text is much wider than the eps file. The .pstex_t is just pasted here and the .pstex (eps) file is attached. Point is that xfig solves this by making two pictures. It seems to decide the size of the text picture after typesetting it. This renders fine in my document.

\begin{picture}(0,0)%
\includegraphics{projection.pstex}%
\end{picture}%
\setlength{\unitlength}{2368sp}%
%
\begingroup\makeatletter\ifx\SetFigFont\undefined%
\gdef\SetFigFont#1#2#3#4#5{%
  \reset@font\fontsize{#1}{#2pt}%
  \fontfamily{#3}\fontseries{#4}\fontshape{#5}%
  \selectfont}%
\fi\endgroup%
\begin{picture}(5355,2445)(961,-6973)
\put(976,-4711){\makebox(0,0)[lb]{\smash{{\SetFigFont{7}{8.4}{\familydefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}$(1,4,0),(3,2,0),(4,0,1),(3,2,0),(1,4,0),(1,4,0),(2,2,1),(2,2,1),(2,2,1),(2,2,1),(1,4,0)$}%
}}}}
\put(6301,-5161){\makebox(0,0)[lb]{\smash{{\SetFigFont{7}{8.4}{\familydefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}$(6,3,2)$}%
}}}}
\put(6301,-5536){\makebox(0,0)[lb]{\smash{{\SetFigFont{7}{8.4}{\familydefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}$(4,7,0)$}%
}}}}
\put(6301,-5986){\makebox(0,0)[lb]{\smash{{\SetFigFont{7}{8.4}{\familydefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}$(2,8,1)$}%
}}}}
\put(6301,-6361){\makebox(0,0)[lb]{\smash{{\SetFigFont{7}{8.4}{\familydefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}$(4,70)$}%
}}}}
\put(6301,-6811){\makebox(0,0)[lb]{\smash{{\SetFigFont{7}{8.4}{\familydefault}{\mddefault}{\updefault}{\color[rgb]{0,0,0}$(6,3,2)$}%
}}}}
\end{picture}%

[[e-mail] (alejandro-erickson)]

I should add that doing
>0.1pt line at 0.1% transparency; anything else seems to get ignored.
will cause your image to export to bitmap :(

[Henry Gomersall (hgomersall)]

>>0.1pt line at 0.1% transparency; anything else seems to get ignored.
>will cause your image to export to bitmap :(

hmm, interesting. So how should I create an invisible box?

[su_v (suv-lp)]

> how should I create an invisible box?

Set fill and stroke to 'None' ('No paint' for both in the Fill&Stroke dialog).

[Henry Gomersall (hgomersall)]

> Set fill and stroke to 'None' ('No paint' for both in the Fill&Stroke dialog).

Ah, I think I see where the problem is. Invisible boxes are not outputted to an encapsulated postscript file, but they are to a PDF file.

This means the work around as-is, is not applicable for eps+latex.

[Johan Engelen (johanengelen)]

So this is an inconsistency in EPS and PDF export? (and is not concerning LaTeX export in particular?

[Henry Gomersall (hgomersall)]

No, this is certainly a bug. Its just that the workaround of using an invisible box does not work with eps export.

[Johan Engelen (johanengelen)]

I meant: yes this is a bug, but the bug is an inconsistency between EPS and PDF export. So we should rename the bugreport and change tags.

The workaround is a good solution for the LaTeX option i think. There is not really another viable option.

[Henry Gomersall (hgomersall)]

No, I think the bug is more fundamental than that. There is an additional problem with the inconsistency, but that is a separate issue.

If an invisible box is the desired workaround, this should be implemented by the save function, not the user.

[su_v (suv-lp)]

Why not use a rectangle with a white fill (with the size of the bounding box of the text object - use bbox snapping for positioning and size) as workaround for EPS+LaTeX export (just make sure that it's below all other content with regard to stack order)? AFAIK EPS does not support transparency and defaults to a white background, so a white rectangle without stroke should not be visible (note: untested since I don't use LaTeX myself).

[su_v (suv-lp)]

With regard to EPS export omitting invisible objects: my guess is that this is expected and useful behavior for normal PS/EPS export since transparency is not supported by PS/EPS (why then would you want or expect transparent objects to be exported?).

If you consider it a bug, I think it should be reported separately as request to include invisible objects in PS/EPS export (if this is doable at all - I do not know specifics of the PostScript specification).

[Johan Engelen (johanengelen)]

Perhaps a better workaround is adjusting the document's page size and
exporting the page area.

[su_v (suv-lp)]

Then you might run into bug #380501 “eps export always sets bounding box to drawing, never to whole canvas” - unless the bounding box is calculated before the text objects are omitted form the list of objects to export?

[su_v (suv-lp)]

s/form/from/

[Henry Gomersall (hgomersall)]

>unless the bounding box is calculated before the text objects are omitted form the list of objects to export?
>
I looked at implementing exactly that solution, but thesis took precedence ;)

[[e-mail] (alejandro-erickson)]

you really want to make the box after rendering the LaTeX. ie the bounding box is decided in the LaTeX code while the eps/pdf or whatever bounds only the non-text part. see the code I posted from xfig output in https://bugs.launchpad.net/inkscape/+bug/595821/comments/5

[Johan Engelen (johanengelen)]

the code in #5 seems to not scale the ps image, therefore the size of the total image was set before rendering the latex text; or am i missing something?

[Johan Engelen (johanengelen)]

Sorry for the confusion I may have caused, finally I see what the described problem is. I thought I made it such that Inkscape ignores text when calculating the bbox of the image. Turns out I programmed it that Inkscape does not ignore text for the bbox. So for PDF, it works as one can expect. The problem for EPS is that Cairo calculates the bbox, while it shouldn't because Inkscape tells it what the bbox should be.

[Johan Engelen (johanengelen)]

This bug is only present for EPS output, right? Not for PS output?

[Henry Gomersall (hgomersall)]

Yeah, it seems to be working correctly with PS output. It doesn't render very nice output though, although I presume this is a function of it being a PS rather than an EPS.

[Johan Engelen (johanengelen)]

The issue is with the EPS export, marking as duplicate of 380501.