texlive-basic: dvipdfmx fails with png and jpg

[tenomoto (Takeshi Enomoto)]

dvipdfmx can't convert dvi to pdf if images such as jpg and png are included. The Japanese TeX community has identified that the binary compiled with clang has this problem. I compiled dvipdfmx with macports-gcc-4.7 and it does work. I'm not familiar with how texlive-basic install binaries, but building with configure.compiler=macports-gcc-4.7 doesn't work; it appears that the texlive-basic port doesn't build from source.

[larryv (Lawrence Velázquez)]

You can assign new tickets directly :)

[drkp (Dan Ports)]

Replying to takeshi@…:

dvipdfmx can't convert dvi to pdf if images such as jpg and png are included. The Japanese TeX community has identified that the binary compiled with clang has this problem. I compiled dvipdfmx with macports-gcc-4.7 and it does work.

I haven't heard about this; do you have any more information?

I'm not familiar with how texlive-basic install binaries, but building with configure.compiler=macports-gcc-4.7 doesn't work; it appears that the texlive-basic port doesn't build from source.

The binaries are built by texlive-bin and symlinked into place by texlive-basic, so if you need to change the compiler you'll need to do it for texlive-bin.

[drkp (Dan Ports)]

BTW, if you're interested in testing with a prerelease version of texlive 2013, there is a preliminary portfile in my testing repository, ​https://svn.macports.org/repository/macports/users/dports/ports/

The port isn't yet complete, and not quite ready for general testing, but it's at a point where it's basically functional.

[tenomoto (Takeshi Enomoto)]

Japanese users seem to replace MacPorts dvipdfmx with an unofficial binary on a BB (called 2ch), the one in other TeX distributions or the one built from source. This is not what the MacPorts should be. This ​link reports the problem and how to build dvipdfmx by hand. Those who are not familiar with compilers seem to believe that this is a problem related to Lion and Mountain Lion since the one built on Snow Leopard (on which clang is not the default) works .

Try latex and dvipdfmx with some image file. Images in jpg always cause abort, but some png files (e.g. macports-logo-top.png) are OK and others fail. The image (fuji320.jpg, renamed) is found ​here.

\documentclass{article}
\usepackage[dvipdfm]{graphicx}
\begin{document}
\includegraphics{fuji320.jpg}
\end{document}

[drkp (Dan Ports)]

Thanks for the test case. This is definitely a bug.

I would of course much rather get the problem with clang fixed rather than requiring all of texlive-bin to be built with a different compiler.

Do you know if anyone has reported this yet to the dvipdfmx maintainers?

[drkp (Dan Ports)]

It also looks like this only happens when dvipdfmx is built using clang -O1 or higher.

[mojca (Mojca Miklavec)]

Cc Me!

[mojca (Mojca Miklavec)]

Just a few notes: the problem doesn't manifest on MacTeX. (Maybe that one is not built with optimisation turned on. But it was definitely built with clang and statically linked libraries.)

Backtrace shows

#0  0x00007fff824d082a in __kill ()
#1  0x00007fff87e30b6c in __abort ()
#2  0x00007fff87e2d070 in __stack_chk_fail ()
#3  0x0000000100026295 in iccp_load_profile ()
#4  0x00000001000208c8 in jpeg_include_image ()
#5  0x000000010003ebd0 in pdf_ximage_findresource ()
#6  0x0000000100049c16 in spc_handler_pdfm_image ()
#7  0x000000010004ef0a in spc_exec_special ()
#8  0x0000000100017496 in dvi_do_special ()
#9  0x0000000100019251 in dvi_do_page ()
#10 0x000000010001bc16 in main ()

The function iccp_load_profile is defined in pdfcolor.c. It would probably help to keep the debugging flags on and test further. It would also help a lot if the problem can be reproduced outside of MacPorts.

[cooljeanius (Eric Gallager)]

Cc Me!

[takanori@…]

Could anyone try the following patch? In my view, this is a dvipdfmx's own bug, not a clang's issue.

# By the way, I have written a quite similar patch before, and it was released as a part of dvipdfmx-20110311. I should've fixed this bug at that time... ;-(

[takanori@…]

This problem has been fixed in the official TeXLive repository.

• ​http://tug.org/pipermail/tex-live/2013-September/034265.html
• ​http://www.tug.org/svn/texlive?view=revision&revision=31700

[mojca (Mojca Miklavec)]

Dan: do you have any plans for other fixes for TeX Live (to combine multiple patches in a single commit/revision upgrade) or should someone else commit the patch in case that you don't have time to take care of it?

[drkp (Dan Ports)]

This is great, thanks for finding the fix.

I'm planning to look through Norbert's tl2013 changes this week and will apply this along with them...

[drkp (Dan Ports)]

Backported to TL2013 (for both dvipdfmx and xdvipdfmx) and applied in r111792.

I am sending the backported fix upstream with the suggestion that it be applied to the tl2013 branch.

[tenomoto (Takeshi Enomoto)]

I confirmed that dvipdfmx works as expected. Thanks you all.