Opened 5 years ago

Closed 4 years ago

Last modified 4 years ago

#39334 closed defect (fixed)

texlive-basic: dvipdfmx fails with png and jpg

Reported by: tenomoto (Takeshi Enomoto) Owned by: drkp (Dan Ports)
Priority: Normal Milestone:
Component: ports Version: 2.1.3
Keywords: Cc: mojca (Mojca Miklavec), cooljeanius (Eric Gallager)
Port: texlive-basic

Description

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.

Attachments (1)

dvipdfmx-takanori.diff (862 bytes) - added by takanori@… 4 years ago.

Download all attachments as: .zip

Change History (16)

comment:1 Changed 5 years ago by larryv (Lawrence Velázquez)

  • Cc dports@… removed
  • Owner changed from macports-tickets@… to dports@…

You can assign new tickets directly :)

comment:2 in reply to: ↑ description Changed 5 years ago by 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.

comment:3 Changed 5 years ago by 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.

comment:4 Changed 5 years ago by 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}

comment:5 Changed 5 years ago by drkp (Dan Ports)

  • Status changed from new to assigned

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?

comment:6 Changed 5 years ago by drkp (Dan Ports)

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

comment:7 Changed 5 years ago by mojca (Mojca Miklavec)

  • Cc mojca@… added

Cc Me!

comment:8 Changed 4 years ago by 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.

comment:9 Changed 4 years ago by cooljeanius (Eric Gallager)

  • Cc egall@… added

Cc Me!

comment:10 Changed 4 years ago by 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 quite similar patch before, and it was released as a part of dvipdfmx-20110311. I should've fixed this bug at that time... ;-(

Version 0, edited 4 years ago by takanori@… (next)

Changed 4 years ago by takanori@…

comment:12 Changed 4 years ago by 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?

comment:13 Changed 4 years ago by 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...

comment:14 Changed 4 years ago by drkp (Dan Ports)

  • Resolution set to fixed
  • Status changed from assigned to closed

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.

comment:15 Changed 4 years ago by tenomoto (Takeshi Enomoto)

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

Note: See TracTickets for help on using tickets.