From Bugzilla Helper: User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.19-pre8-ac1 i686) Description of problem: dvipdf (gs -sDEVICE=pdfwrite) simply doesn't work. Well, such a description is known to be bad, but I really have nothing to add. Version-Release number of selected component (if applicable): ghostscript-7.03-0 How reproducible: Always Steps to Reproduce: 1.produce a simple document with LaTeX 2.use xdvi to ensure that the document is not empty 3.use dvipdf 4.use xpdf to see that the produced pdf is empty 5.use xpdf on some other non-empty document to ensure that xpdf itself is OK Actual Results: pdf document is empty (xpdf) Expected Results: xpdf output is identical to xdvi output Additional info: I'll attach the .tex, .dvi and .pdf examples. Hmm, I have already filled quite a lot of bugreports trying to process several simple documents. Why the document processing contains so many gotcha's under RHL? :)
Created attachment 58965 [details] archived examples
ghostscript-7.03-0 is not a Red Hat Linux package. Please try the ghostscript package from the CD-ROM and re-open this bug report if you still see the problem.
..but looking at your PDF file it seems to me that it isn't blank. Use 'gs bug.pdf'. (It's a known issue that xpdf doesn't currently handle type 3 fonts.)
> ghostscript-7.03-0 is not a Red Hat Linux package. Yes, this was a definitely broken ghostscript from an unknown source. > ..but looking at your PDF file it seems to me that it isn't blank. Use 'gs > bug.pdf'. Thanks, ghostscript-7.05-6 can view that pdf. > (It's a known issue that xpdf doesn't currently handle type 3 fonts.) Hmm, what about dropping xpdf in favour of gs then?
xpdf is much faster for documents that restrict themselves to use only Type 1 fonts.