3

Given file.tex

\documentclass[
  convert={
    density=300 -alpha deactivate,
    outext=.png
  },
]{standalone}

\begin{document}
\begin{tabular}{|c|c|}
  \hline
  a & b \\ \hline
  c & d \\ \hline
\end{tabular}
\end{document}

when I ran pdflatex -shell-escape file with

ImageMagick 6.9.3-4 Q16 x86_64 2016-02-29

I got a transparent background.

After upgrading to

ImageMagick 6.9.4-4 Q16 x86_64 2016-06-29

I now get a full A4 page (for both pdf and png), with a page number, but with a white background.

In both cases I'm running TeX Live 2015 on OS X 10.11.5.

What could be going wrong? How might upgrading ImageMagick have affected the pdflatex step that precedes convert?

Update

Logging in from a new user account on OS X, everything works fine. So I figured that it's just the difference between the two ~/.bash_profile. After using a single export PATH line in the ~/.bash_profile in both accounts and confirming that I am indeed running the same two executables from both accounts:

$ which pdflatex
/Library/TeX/texbin/pdflatex
$ which convert
/opt/local/bin/convert

the problem persists. (I am aware that this is no longer a TeX issue. I can delete the question if you like.)

Community
  • 1
Calaf
  • 1,471
  • 2
    Why do you think it is pdfLaTeX at fault? You've updated ImageMagick and now something involving ImageMagick doesn't work. Why isn't that the obvious initial suspect? – cfr Jun 29 '16 at 23:38
  • -alpha deactivate switches transparency off, surely? – cfr Jun 29 '16 at 23:40
  • There is a problem with image corruption in jpegs reported in earlier versions and fixed in 6.9.4.10. Whether corruption manifests depends on how the binary is compiled. However, the patched version is also outdated. Version 7.0.2 is current stable; 6.9.5 is current legacy. So I suspect the answer is to wait for an update. However, I can't confirm this as I don't have an updated version available to test. – cfr Jun 30 '16 at 00:12
  • Since you're on OS X, though, presumably you can easily test with upstream's binary versions. However, if it was a bug in your case, it should affect both accounts. Try converting on the command line and cross-checking the results. – cfr Jun 30 '16 at 00:15
  • I'm getting a weird behavior from texstudio's internal pdf viewer when compiling the MWE (I took the convert bit away). I just opened a ticket on texstudio SF forum with the description: https://sourceforge.net/p/texstudio/bugs/1836/ . But now I wonder if could be a changed spec or bug in standalone class that maybe is causing different displays on different software versions. @cfr Can you confirm the bug in case you have texstudio installed? Tx. – alwaysask Jun 30 '16 at 00:55
  • @alwaysask I don't have TeXstudio, sorry. Works fine in Kile. – cfr Jun 30 '16 at 01:06

1 Answers1

1

-alpha deactivate switches transparency off. Compiling your example with pdfLaTeX and convert version ImageMagick 6.9.4-6 Q16, I get the following:

no alpha

The grey backdrop is included just to demonstrate that the image is correctly cropped.

Here's the PNG:

no alpha PNG

cfr
  • 198,882
  • Transparency seems to be broken, though, for convert. – cfr Jun 30 '16 at 00:00
  • For ImageMagick 7.0.7-21 Q16 x64 2018-01-06 the only command that seems to work is magick input.pdf -alpha remove output.png. The problem is that -alpha must be between two files, so appending it to density value (which comes before the first file) does not work. There is a way to reconstruct the command that is sent by standalone (sub-option command, Pg. 17 in manual), which however does not work. – Pygmalion Feb 05 '18 at 08:39
  • @Pygmalion Is there a bug recognised upstream? – cfr Feb 05 '18 at 19:03
  • No idea. BTW, you might find this thread interesting: https://tex.stackexchange.com/questions/413743/standalone-package-reconstruction-of-the-command-line/413764 – Pygmalion Feb 05 '18 at 19:05