This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 451612 - dvipdfmx makes .pdf images created by inkscape invisible
dvipdfmx makes .pdf images created by inkscape invisible
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: xdvipdfmx (Show other bugs)
11
All Linux
low Severity high
: ---
: ---
Assigned To: Jonathan Underwood
Fedora Extras Quality Assurance
: Reopened
: 546517 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-16 02:31 EDT by Konstanty
Modified: 2015-07-27 09:42 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-07-27 09:42:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Simple latex file. (151 bytes, text/x-tex)
2008-06-16 02:33 EDT, Konstanty
no flags Details
Simple PDF file created using inkscape (1.30 KB, application/pdf)
2008-06-16 02:33 EDT, Konstanty
no flags Details
XDV output from xelatex (which dvipdfmx uses to create PDF) (364 bytes, application/octet-stream)
2008-06-16 20:16 EDT, Konstanty
no flags Details

  None (edit)
Description Konstanty 2008-06-16 02:31:34 EDT
Description of problem:

Since updating to dvipdfmx-0-0.23.20080520cvs.fc9.x86_64 images created in
inkscape are invisible in the PDF outputs of documents.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Create Image in inkscape (export as Cairo PDF)
2. Create simple latex file using includegraphics
3. Run "xelatex test"
  
Actual results:

Space where image is expected is blank - however the size of the blank space is
proportional to the size of the image.

Expected results:

Creates PDF file with image as created in inkscape

Additional info:
Comment 1 Konstanty 2008-06-16 02:33:11 EDT
Created attachment 309461 [details]
Simple latex file.
Comment 2 Konstanty 2008-06-16 02:33:55 EDT
Created attachment 309462 [details]
Simple PDF file created using inkscape
Comment 3 Konstanty 2008-06-16 02:37:08 EDT
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.
Comment 4 Jonathan Underwood 2008-06-16 19:01:58 EDT
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?
Comment 5 Konstanty 2008-06-16 20:15:29 EDT
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

Comment 6 Konstanty 2008-06-16 20:16:08 EDT
Created attachment 309556 [details]
XDV output from xelatex (which dvipdfmx uses to create PDF)
Comment 7 Konstanty 2008-06-16 20:25:30 EDT
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
Comment 8 Jonathan Underwood 2008-06-17 06:42:22 EDT
Aha, ok. Thanks for the clarification, I'll have a look at it.
Comment 9 Jonathan Underwood 2008-06-20 13:46:17 EDT
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
Comment 10 Jonathan Underwood 2008-06-20 13:47:16 EDT
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?
Comment 11 Jonathan Underwood 2008-06-20 13:51:31 EDT
For anyone interested, a similar thread:

http://lists.debian.org/debian-tex-maint/2007/11/msg00042.html
Comment 12 Konstanty 2008-06-20 20:38:08 EDT
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@9.96pt(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
Comment 13 Bug Zapper 2009-06-09 21:38:42 EDT
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
Comment 14 Bug Zapper 2009-07-14 14:02:15 EDT
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.
Comment 15 Konstanty 2009-07-21 04:46:41 EDT
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.
Comment 16 Jonathan Underwood 2009-07-21 07:30:13 EDT
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.
Comment 17 Jonathan Underwood 2010-01-27 13:57:53 EST
*** Bug 546517 has been marked as a duplicate of this bug. ***
Comment 18 Konstanty 2010-01-27 19:08:23 EST
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.
Comment 19 Dimitrios Apostolou 2010-12-20 16:41:27 EST
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?
Comment 20 Maciek Borzecki 2012-10-13 16:21:47 EDT
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?
Comment 21 Jonathan Underwood 2012-10-15 10:53:17 EDT
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.
Comment 22 Jonathan Underwood 2015-07-27 09:42:06 EDT
Closing again, as a number of years have passed and the packaging has changed significantly.

Note You need to log in before you can comment on or make changes to this bug.