pdf+latex export (v0.48): text cannot be placed below transparent objects

[armando sano]

If the svg figure in inkscape contains text placed below transparent objects, after pdf+latex export and recomposition of the figure in a LaTeX document, the text is always placed by LaTeX on top of the (text-less) drawing, thus preventing it from being partially shadowed by the semi-transparent shapes. However, transparent text placed on top of other objects works as expected, provided the \usepackage{transparent} LaTeX package is used in the preamble of the LaTeX document. (Transparent (non-text) objects also work as expected (at least in adobe acrobat: not all pdf viewers currently support transparency very well!)

[Johan Engelen (johanengelen)]

Setting status to Won't Fix. Fixing this bug properly would require
generating a separate image for each set of elements between text
objects in z-order. And then have LaTeX put them all on top of each
other with text in between. This is obviously way too much for most
users. I'm sorry, but what you need is too complicated. I advise to
solve it by manually placing two separate images on top of each other.

status wontfix

On 27-4-2011 20:14, armando sano wrote:
> Public bug reported:
>
> If the svg figure in inkscape contains text placed below transparent
> objects, after pdf+latex export and recomposition of the figure in a
> LaTeX document, the text is always placed by LaTeX on top of the (text-
> less) drawing, thus preventing it from being partially shadowed by the
> semi-transparent shapes. However, transparent text placed on top of
> other objects works as expected, provided the \usepackage{transparent}
> LaTeX package is used in the preamble of the LaTeX document.
> (Transparent (non-text) objects also work as expected (at least in adobe
> acrobat: not all pdf viewers currently support transparency very well!)
>
> ** Affects: inkscape
> Importance: Undecided
> Status: New
>

[armando sano (armando-sano)]

It's a shame, you seem to have the fix readily available ;)! I am not an expert in svg but I think the z-order info must be already in the svg file somewhere. You could have these separate image elements exported in a single multipage pdf file (one figure element (one z-coordinate) per page). LaTeX's \includegraphics command is able to select the wanted page. Of course you'd have to intercalate the text part in between.

For now I actually don't use this feature and was rather testing the capabilities of the pdf+LaTeX export (didn't find mention of this limitation in the doc). Nevertheless, improving transparency support seems to me to be something users will want, sooner or later (when transparency support among pdf viewers will be more widespread.)

It is also about opening up new possibilities for creating amazing figures to include in LaTeX... :)

Thanks anyway for this export function!

[Johan Engelen (johanengelen)]

Ok, changing to wishlist. You convinced me. Don't expect this soon though!

[David R. Bild (drbild)]

I needed this feature for my work, so I implemented this (for pdf/pdflatex) in branch: https://code.launchpad.net/~drbild/inkscape/multilayer-pdf-latex-output

It works for me and could probably be easily massaged to conform with what style/preferences the CairoRender and LaTeXTextRender maintainer has.

[Johan Engelen (johanengelen)]

Great work!

The simple_test.svg contains a text object at the bottom, then a square, and then text on top. This creates a pdf with two pages.
Could you tweak the code so that it only creates one page in this case? (perhaps detect an empty page?) Interestingly, the tex output seems to know that page 0 is empty:
  \begin{picture}(1,0.91051562)%
    \put(0.31889273,0.41323565){\color[rgb]{0,0,0}\makebox(0,0)[lb]{\smash{bottom}}}%
    \put(0,0){\includegraphics[width=\unitlength,page=1]{patch.pdf}}%
    \put(0.57766272,0.5146827){\color[rgb]{0,0,0}\makebox(0,0)[lb]{\smash{top}}}%
  \end{picture}%

Thanks!

[David R. Bild (drbild)]

Done. Fix is overwritten into the same branch.

Thanks for the catch. Thought I had that logic tested and correct...

FYI, a file with just text still outputs one blank page (like before), but it is not actually included (no includegraphics in the *.pdf_tex output). This keeps things simple for the user---we always generate a *.pdf and *.pdf_tex, even if the former is actually not necessary.

[Johan Engelen (johanengelen)]

Thanks for the quick response. Looks fine to me, please contact someone on the maillist to merge it into trunk (I don't know how and don't want to know :)
Don't forget to add yourself to the Author list of files you modified!

[Johan Engelen (johanengelen)]

is this "fix committed" now in trunk?

[su_v (suv-lp)]

Johan Engelen wrote:
> is this "fix committed" now in trunk?

Based on the branch status:
> Merged into lp:inkscape at revision 12489
it seems that yes, bug status needs an update - thx for the hint.

[su_v (suv-lp)]

Follow-up report:
- Bug #1417470 “PDF+Latex export creates multipage pdf, pages missing”
  https://bugs.launchpad.net/inkscape/+bug/1417470

[[e-mail] (martin-vermeer-7)]

Yep, my problem too, in my daily tool chain. Please roll out fix.

[Patrick Storz (ede123)]

As the previous implementation didn't work with clipped/masked/transparent objects I had another shot at the PDF+LaTeX renderer, see
https://gitlab.com/inkscape/inkscape/merge_requests/135

As the renderer (especially the hack we use to make PDF+LaTeX work) is a fragile thing and I'm not too familiar with it yet this requires a lot of testing. I'd appreciate if you could check with your own samples if Inkscape produces proper output.

Attached is an example document that should highlight the new functionality.

[Patrick Storz (ede123)]

All recent fixes related to PDF+LaTeX export backported in
https://gitlab.com/inkscape/inkscape/compare/af5ac6bc522ff4b715d482d3eda11e0e0408ad15...cb54205aa21bcd227c62fce1a356f6f2c6039b64

This should fix all remaining issues with missing pages in the output and produce proper stacking order of text and graphics in all cases.