18

I use Inkscape to create graphics which I export to PDFs in order to include them into a LaTeX documents (with \includegraphics and using pdflatex). I didn't notice that there is something wrong until someone told me that my figures do not display correctly on Mac OS X. Basic graphic parts, e.g. boxes or circles which have a Opacity setting less than 100% are not displayed at all.

The problem seems to be in pdflatex since the exported PDF from inkscape alone displays just fine on a Mac. Since I'm using Linux and sometimes Windows I never realized that there is even a problem!

After trying to figure out what could cause the problem, i stumbled over

\includegraphics PDF, color problem and Inkscape → PDF → includegraphics → XeLaTeX → changed colors

However, this did not solve my problem.

A similar question was asked in Opaque-to-transparent gradient lost in embedded PDF figure but now answer was really given.

I found out that the conversion of the exported PDF to a PS and then back to PDF resolves the issue but the graphic quality is quite bad afterwards.

What did I miss? Thanks for any suggestion.

Below is a minimal working example:

\documentclass[a4paper]{article}
\usepackage[pdftex]{color,graphicx}

\begin{document}

\begin{figure}[htb]
 \begin{center}
  \includegraphics[width=\columnwidth]{test_diagram}
  \caption{Block diagram created with Inkscape 0.48}
 \end{center}
\end{figure}

\end{document}

The included graphic can be downloaded here: https://www.dropbox.com/s/mrtj0c3u0ng6a39/test_diagram.pdf

Inkscape: 0.48.3.1 r9886
pdfTeX, Version 3.1415926-2.4-1.40.13 (TeX Live 2012/Debian)

Community
  • 1
xlr8t
  • 193
  • I was able to get the LaTeX output figure to render on a Mac by first opening the PDF in Acrobat Pro, then re-saving it as an optimised PDF with Transparency enabled. This leads me to believe that your software (Inkscape) MAY have a save (or export) setting that can do the same... – commonhare Mar 17 '14 at 18:20
  • @commonhare, thanks for pointing that out. Since converting the PDF to a PS and than back to a PDF works as well (pdf2ps test_diagram.pdf tmpPS.ps; ps2pdf tmpPS.ps test_diagram.pdf) ,but the image gets rasterized. I thought that there should be an export option in inkscape. Unfortunately, these options are quite limited and I don't have much experience with it. I played around with them but without any luck – xlr8t Mar 17 '14 at 21:12

6 Answers6

14

I have seen this problem as well if Inkscape images are embedded via pdflatex and then displayed on on a PDFKit-based viewer. (PDFKit is the built-in PDF rendering engine of OS X and used by Skim, Preview, and many other programs).

Apparently, Inkscape has an "unusual" way of specifying transparencies, which do not survive the embedding done by pdflatex.

The only workaround that has reliably worked for me is to "sanitize" the PDF by flattening the transparencies. I use ghostscript (via the ps2pdfwr script) with the dHaveTransparencies=false switch for this purpose:

ps2pdfwr -dCompatibilityLevel=1.4 -dHaveTransparency=false test_diagram.pdf sanitized.pdf

The downside is that this comes down to rasterizing the image. The default resolution for this is 720 dpi, which should be fine for most use cases. If, however, you need better (or lower) quality you can specify the resolution as well: 

ps2pdfwr -dCompatibilityLevel=1.4 -r1200 -dHaveTransparency=false test_diagram.pdf sanitized.pdf

At 1200 dpi, your ~5 KiB image increases to ~78 KiB in its rasterized version. However, PDF transparencies are a source of many strange problems if it comes to output devices – not only if produced by Inkscape. See, for instance: Using opacity in TikZ makes the entire page become "more coarse" when printed. Hence, I consider this as the price to pay.

Community
  • 1
Daniel
  • 37,517
  • thanks for this input. I didn't know about ps2pdfwr. The result is pretty much the same as using pdf2ps and then ps2pdf but with the flexibility of defining the resolution. However, its kind of sad that we have to live with that. The question for me is, if this is a problem of Inkscape or one from the rendering engine of OS X. – xlr8t Mar 17 '14 at 21:22
  • 1
    @xlr8t: Or maybe one of pdflatex, as the Inkscape image itself renders fine? Sorry, but I don't really know. However, given the printing problems on many printers when using transparencies, I have made it a habit to rasterize the respective images. – Daniel Mar 17 '14 at 21:47
  • you are right, it might be pdflatex since the inkscape image itself renders fine. – xlr8t Mar 18 '14 at 16:11
5

It Seems to work here, tweak alpha opacity than general opacity.

http://www.inkscapeforum.com/viewtopic.php?f=28&t=15739&p=65180#p65180

I am using pdftex and Inkscape 0.91

Mohammad Sleiman
  • 51
2

I had the same issue with Inkscape/Mac OS/LaTeX. I was able to deal with this by rasterizing only the problematic parts of the image and leaving the rest vectorized. To do this I opened the SVG file selected the object(s) in question in Inkscape and did Edit -- >Make a Bitmap Copy, and then saved as PDF. I couldn't get anywhere on this issue with Inkscape 0.91 but this worked with Inkscape 0.48.

Mike
  • 21
1

I solved the problem by storing the SVG file first as PS, then opening the PS file and storing it as PDF file.

RalfB
  • 825
  • It seems very random and sometimes not even this solution works. I really hope that there would be a good explanation for this somewhere... – RalfB Jun 19 '15 at 12:02
1

Going through an intermediate '.ps' file helps

Like RalfB, I found that converting first to a PS, then to a PDF made latex happier. Using this script helped:

inkscape foo.svg --export-ps=foo.ps
pstopdf foo.ps -o foo.pdf

Then just compile your latex file as normal.

It must be the case that inkscape's conversion to '.pdf' is messing something up, compared to its conversion to '.ps', as Daniel mentioned.

Results

Here are before/after pictures, showing that the desired transparency is present going through the ps:

Before (svg -> pdf)

Before intermediate ps

After (svg -> ps -> pdf)

After intermediate ps

heisenBug
  • 113
0

I've made a python3 script (available here & critical code copied below) that swaps the opacity with the alpha channel (first discussed here).

While I'm not sure why, LaTeX doesn't apply the opacity style attribute to the element, but fill-opacity works as intended. The python script simply works through the XML and (for example) sets any occurrence of:

style="opacity:0.5; ... "

to

style="opacity:1.0; ... ;fill-opacity:0.5"

This is tested to work with lines, shapes, and paths (generated via python's matplotlib SVG plotter).

# Open svg file with ElementTree XML parser
xmlRoot = et.parse('/path/to/input.svg').getroot()

opacityTarget = re.compile(r'((?<=^opacity:)|(?<=;opacity:))\d+\.?\d*')
for target in xmlRoot.findall('.//*[@style]'):
    m = opacityTarget.search(target.attrib['style'])
    if m and float(m.group(0)) < 1.0:
        # replace opacity target to 100%
        target.attrib['style'] = re.sub(opacityTarget, '1', target.attrib['style'])

        # move opacity to new fill-opacity attribute, supported by pdfs
        target.attrib['style'] += ';fill-opacity:{0}'.format(m.group(0))

# write to output file (can be the same file as input)
with open('/path/to/output.svg', 'wb') as outputFile:
    et.ElementTree(xmlRoot).write(outputFile)
Ancantus
  • 101