Inkscape: A Vector Drawing Tool

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

Reported by armando sano on 2011-04-27
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Inkscape
Wishlist
David R. Bild

Bug Description

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!)

~suv (suv-lp) on 2011-04-27
tags: added: exporting latex pdf

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
>

Changed in inkscape:
status: New → Won't Fix
armando sano (armando-sano) wrote :

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) wrote :

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

Changed in inkscape:
status: Won't Fix → Confirmed
importance: Undecided → Wishlist
David R. Bild (drbild) wrote :

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) wrote :

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!

Changed in inkscape:
status: Confirmed → In Progress
assignee: nobody → David R. Bild (drbild)
David R. Bild (drbild) wrote :

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) wrote :

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) wrote :

is this "fix committed" now in trunk?

~suv (suv-lp) wrote :

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.

Changed in inkscape:
milestone: none → 0.49
status: In Progress → Fix Committed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments