Bug 451612

Created attachment 309461 [details]
Simple latex file.

Created attachment 309462 [details]
Simple PDF file created using inkscape

In the previous version dvipdfmx-0-0.20.20071115cvs.fc9.x86_64 the output of
running xelatex test is correct.

I had a similar problem to this on a very old version of latex running on MacOSX
- however after upgrading the problem went away.

Files post processed in other tools such as Adobe Illustrator, or even
"Preview"/Quartz on Mac OS X seem to fix up the PDFs so that they are no longer
invisible in PDF output.

OK, naive question - what makes you think this is a bug with dvipdfmx? As far as
I can see, dvipdfmx isn't involved at all in this?

I guess it seems like xelatex is at fault - however the only difference between
my two systems is that on one I upgraded dvipdfmx and one I did not.

I found that I can modify the way xelatex works, by stopping at the .xdv file -
which I think is what is passed into dvipdfmx - on both systems the .xdv file is
the same.

OK System Package list:
dvipdfmx-0-0.20.20071115cvs.fc9.x86_64
texlive-2007-30.fc9.x86_64
texlive-debuginfo-2007-30.fc9.x86_64
texlive-dvips-2007-30.fc9.x86_64
texlive-latex-2007-30.fc9.x86_64
texlive-texmf-2007-22.fc9.noarch
texlive-texmf-dvips-2007-22.fc9.noarch
texlive-texmf-errata-2007-4.fc9.noarch
texlive-texmf-errata-dvips-2007-4.fc9.noarch
texlive-texmf-errata-fonts-2007-4.fc9.noarch
texlive-texmf-errata-latex-2007-4.fc9.noarch
texlive-texmf-errata-xetex-2007-4.fc9.noarch
texlive-texmf-fonts-2007-22.fc9.noarch
texlive-texmf-latex-2007-22.fc9.noarch
texlive-texmf-xetex-2007-22.fc9.noarch
texlive-utils-2007-30.fc9.x86_64
texlive-xetex-2007-30.fc9.x86_64

Bad system:
dvipdfmx-0-0.23.20080520cvs.fc9.x86_64
texlive-2007-30.fc9.x86_64
texlive-dvips-2007-30.fc9.x86_64
texlive-latex-2007-30.fc9.x86_64
texlive-texmf-2007-22.fc9.noarch
texlive-texmf-dvips-2007-22.fc9.noarch
texlive-texmf-errata-2007-4.fc9.noarch
texlive-texmf-errata-dvips-2007-4.fc9.noarch
texlive-texmf-errata-fonts-2007-4.fc9.noarch
texlive-texmf-errata-latex-2007-4.fc9.noarch
texlive-texmf-errata-xetex-2007-4.fc9.noarch
texlive-texmf-fonts-2007-22.fc9.noarch
texlive-texmf-latex-2007-22.fc9.noarch
texlive-texmf-xetex-2007-22.fc9.noarch
texlive-utils-2007-30.fc9.x86_64
texlive-xetex-2007-30.fc9.x86_64

Created attachment 309556 [details]
XDV output from xelatex (which dvipdfmx uses to create PDF)

Looks like this type of file (XDV) it first sent to xdvipdfmx - which is somehow
linked to dvipdfmx. (Both machines have the same version of xdvipdfmx:
xdvipdfmx-0.4-3.fc9.x86_64)

Calling them both manually I get this output:

(bad)$ xdvipdfmx test.xdv 
test.xdv -> test.pdf
[1
** WARNING ** Version of PDF file (1.4) is newer than version limit specification.
** WARNING ** No image converter available for converting file "./testme.pdf" to
PDF format.
** WARNING ** >> Please check if you have 'D' option in config file.
** WARNING ** pdf: image inclusion failed for "./testme.pdf".
]
3598 bytes written

(good)$ xdvipdfmx test.xdv 
test.xdv -> test.pdf
[1
** WARNING ** Version of PDF file (1.4) is newer than version limit specification.
]
4278 bytes written

Also, this bug in debian seems to be very similar to my problem:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=483019

Aha, ok. Thanks for the clarification, I'll have a look at it.

The upstream maintainer has this to say on the matter:

In my opinion, it is not a bug. In this case you are trying to include a pdf image
the version of which is greater than the version of the final pdf to be generated
by dvipdfmx. More specifically, if you do not give no other option, the version of
the final pdf is 1.4. However, you are trying to include a pdf image of version 1.5.

Actually there is no problem in many cases even if the lower version is included.
However, I think that it would be better to avoid this situation. So the current
dvipdfmx does not allow this situation. Then how to solve it? Just give an option
-V5 to make the version of final pdf 1.5. It's simple.

http://project.ktug.or.kr/pipermail/dvipdfmx/2008-June/000036.html

I can confirm that this fixes the problem:

xelatex --output-driver="xdvipdfmx -v -V 5" test.tex 

I think this is therefore not a bug, but desired behaviour. Would you agree?

For anyone interested, a similar thread:

http://lists.debian.org/debian-tex-maint/2007/11/msg00042.html

Thanks for finding out the solution to my problem. With the alternate command
line everything works correctly.

(Just a note that dvipdfmx is defaulting to V.1.3 PDF and my graphics file is 1.4)

I'm not sure on the differences between PDF 1.4/1.3 etc, but many of the tools
in fedora output by default to PDF1.4 - so maybe
/etc/texmf/dvipdfmx/dvipdfmx.cfg could set the default to 1.4 or maybe the old
dvipdfmx was better - as it converted from PDF 1.4 to PDF 1.3 automatically.

** WARNING ** No image converter available for converting file "./testme.pdf" to
PDF format.

----

OLD DVIPDFMX behavior:

 xdvipdfmx -vv test.xdv 
DVI Comment:  XeTeX output 2008.06.17:1011
test.xdv -> test.pdf
[1<cmr10(TFM:cmr10[/usr/share/texmf/fonts/tfm/public/cm/cmr10.tfm])
fontmap: cmr10 -> cmr10[remap]
pdf_font>> Simple font "cmr10" enc_id=<builtin,-1> opened at font_id=<cmr10,0>.
>(Image:./testme.pdf[./testme.pdf]
** WARNING ** Version of PDF file (1.4) is newer than version limit specification.
[UNKNOWN]
pdf_image>> Converting file "./testme.pdf" --> "/tmp/dvipdfmx.wRjBVe" via:
pdf_image>>   gs -q -dNOPAUSE -dBATCH -sPAPERSIZE=a0 -sDEVICE=pdfwrite
-dCompatibilityLevel=1.3 -dAutoFilterGrayImages=false
-dGrayImageFilter=/FlateEncode -dAutoFilterColorImages=false
-dColorImageFilter=/FlateEncode -dUseFlateCompression=true -sOutputFile=%o %i -c
quit
pdf_image>> ...pdf_image>> deleting file
"/tmp/dvipdfmx.wRjBVe")](cmr10[CMR10][built-in][Type1][16 glyphs][1976 bytes])
Compression eliminated approximately 635 bytes
4278 bytes written

This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

This problem still occurs with Fedora 11.

** WARNING ** "TrimBox" different from current CropBox found.
** WARNING ** TrimBox (PDF): [ 0 0 612 792 ]
** WARNING ** CropBox/MediaBox (PDF)   : [ 102.854 507.631 486.782 754.886 ]
** WARNING ** Version of PDF file (1.4) is newer than version limit specification.
** WARNING ** No image converter available for converting file "./test.pdf" to PDF format.
** WARNING ** >> Please check if you have 'D' option in config file.
** WARNING ** pdf: image inclusion failed for "./test.pdf".

Before Fedora 9, xdvipdfmx automatically had an image converter to down convert the PDF files from version 1.4 to 1.3.

Although I guess it would also be OK to change pdflatex/xelatex to default to version 1.4 PDF output instead of 1.3.

Well, I think this is working as designed, please see earlier comments with the explanation and workarounds. I'll close as NOTABUG, but reopen if you genuinely regard this as a bug after trying the suggestions above.

*** Bug 546517 has been marked as a duplicate of this bug. ***

I think the best solution for anyone experiencing this bug is to create a file called "dvipdfmx.cfg" in the directory with your .tex file and put in the line "V 4" into it. 

By doing this no extra command line paramters are required to run xelatex, and files created with other tools distributed with Fedora actually display in pdf output (instead of silently failing, and resulting in empty figures).
As stated previously in workarounds, this allows xelatex (with dvipdfmx) to output PDF 1.4 files instead of the default PDF 1.3.

I just faced this bug on fedora 14, and it took me a good half hour to find out the workaround proposed here. I'm also working with xelatex and PDFs on other distros, never noticed this happening.

Can't we apply the configuration fix Konstanty proposed, but in a system-wide file?

Still valid for F17, just wasted an hour just to eventually find this bug report. Adding 'V 5' to /etc/texmf/dvipdfm/dvipdfmx.cfg fixed the problem and I guess it can be a system wide solution. 
Can we reopen this bug or should I file another one?

I'll re-open, but I am not convinced that making such a system wide configuration change for an already released Fedora version is wise.

Closing again, as a number of years have passed and the packaging has changed significantly.