Red Hat Bugzilla – Bug 142535
[patch]PDF Export does not print embedded EPS figures in documents
Last modified: 2007-11-30 17:10:56 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Description of problem:
When creating a PDF file using the PDF Export feature, if the document
has an embedded EPS figure, the EPS figure is not printed. Instead,
the "usual" EPS figure placeholder box is printed to the PDF file.
If the same document is printed to a PDF file using the PDF Converter
Printer, set up using spadmin, the embedded EPS figure is printed
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Embed an EPS file containing a figure in a Writer document
2. Use the Export to PDF function to create a PDF file
Actual Results: A PDF file is created with a placeholder box in the
document, instead of the actual EPS figure.
Expected Results: The PDF file should contain the actual EPS figure,
not the placeholder box.
Attachments to follow.
Created attachment 108314 [details]
The embedded EPS figure. A simple barplot created using R (http://www.r-project.org/)
Created attachment 108315 [details]
The Writer document containing the embedded EPS file
Created attachment 108316 [details]
The PDF file created using the PDF Export function
Created attachment 108318 [details]
The PDF file created using the PDF Converter printer type
Created attachment 108429 [details]
Ah!, is this what you see when you open the .sxw. i.e. a mere placeholder for
the eps. If so then the problem is that OOo itself doesn't render the eps, but
passes it through to the ps output file. So when print to pdf is done through
the external program gs renders it, but when we use direct print to pdf through
the internal OOo, then OOo cannot render it and shows the on-screen image.
If the eps contained a preview then this could be rendered instead,
http://qa.openoffice.org/issues/show_bug.cgi?id=9290 might be relevent here
What you have in the image is correct. OO.org does not render the EPS
image within the document, thus the placeholder box, possibly
including text for the title and the generating program, if added to
the EPS file as R does by default. That is what gets printed using the
PDF Export function in essence as a WYSIWYG approach.
The use of a preview image for the EPS file is a poor option for two
reasons. The preview images are usually bitmaps, which are both poor
in quality and substantially increase the file size for the EPS file
and therefore the OO.org document itself. Preview images are fine for
what they are intended to do, which is to simply enable the human
document creator to get a low-res view of what the document contains,
but are not worthy of being printed in the output, which is where the
high quality EPS content of course shines.
BTW, FWIW, this same issue applies to that other popular Word
processor in the Windows world and Abiword does not support importing
EPS files at all from what I can tell reviewing the import/export
filter matrix at their web site. There is a RFE over at the Abiword BZ
similar to the one at OO.org:
Thus, the present functionality is not unexpected and is why I wanted
to verify on the spadmin BZ report, whether I should or should not
post this as a bug (or consider it as a RFE, as it is on the OO.org
report you reference, which I was not aware of until now.)
My general feeling, is that as long as the PDF Convertor printer
option is available, that works fine for me. It provides a single step
process within OO.org, as opposed to the two step process of printing
to a PS file and then using ps2pdf for the final conversion to the PDF
It would be nice if the PDF Export feature worked transparently as
well, but it seems that the process is clearly different there and
perhaps, until and unless an internal EPS rendering capability is
introduced, that is not likely to occur.
I had also read someplace over at OO.org's web site, that there was
some discussion of the ability to import and render SVG graphics in a
future version. That would be nice and provide a platform independent
mechanism for the importation of high quality vector based images for
both viewing and printing, which would solve the problem of viewing
such images in Impress slides, for example. OO.org's Draw program can
export as SVG now, so perhaps half the battle has been won.
Of course, the ability to import and view PDF files would similarly
provide this functionality. There are commercially available filters
to do this in the Windows world, but of course, it all comes down to
time and resources.
As an alternative to the above, when I need to create a presentation
for viewing by an audience with EPS graphics/plots generated by R, I
use LaTeX with one of the slide packages such as Seminar, Prosper or
Beamer. I can then generate a PDF file and use the full screen viewing
functionality of the Acrobat Reader for the presentation.
As always, there are options to achieve a task. :-)
Thanks for following up on this. If you want to close this or leave it
as a RFE with a pointer to the OO.org report, that's fine. I'll defer
to your opinion here.
Created attachment 108525 [details]
use some external tools to make a preview
If pstoedit is available make an excellent quality emf preview, if not fallback
to making one with ghostscript to png conversion
Created attachment 108526 [details]
how the pdf from Export As PDF created like so end up
Yeah, but giving no preview for on-screen, and nothing in Export to
PDF is not really very nice. Should at least give something, and
ideally as good a quality as is possible. The above patch gives a very
nice rendered output if pstoedit is installed, and an alright fallback
if gs is installed.
caolanm->dcbw: I've attached this patch upstream at
and it looks alright, better than uselessly doing nothing, stuff into
a future RH rpm release ?
Thanks for your work on this. Curiously, pstoedit was just mentioned
on the R e-mail list in the past few days as one approach to
converting the formats of plot files for a particular user's application.
This type of functionality should probably be mentioned in a FAQ
someplace so that folks understand the pros and cons of the possible
approaches to these situations as we have been discussing.
Folks coming over from the Windows world (which was me a couple of
years ago, when I made the move to Linux during the late RH 8.0 Betas)
are used to a certain level of transparency when using images such as
WMF in their Office documents. They provide a very good visual
representation and also print well. Under Windows, R for example,
supports the native generation of WMF/EMF graphics and this is what I
had used in documents (both Office and OO.org) until I moved to Linux.
There really is not yet a parallel in the Linux world to WMF without
going through format conversions (pending the wider use of SVG) to get
both high quality visual images and high quality printed images.
OO.org (along with Firefox, etc.) provides a great vehicle for Windows
folks to make the move to FOSS in steps, though there are still some
gotchas, when they finally do move fully to Linux. This issue comes up
periodically on the R lists when Windows users make the move to Linux
and want to know how best to deal with statistical graphics in
documents. They are frequently sent in the direction of using EPS or
PDF with LaTeX, which results in some notable head scratching.
hmm, caolan, I didn't seem to stick this into any release, right?
BTW, where does pstoedit live?
Hmm, pstoedit.net seems to be the place. If we don't package it
already, perhaps we should?
cmc->dcbw: Yeah, seems like a nice piece of ps conversion work, could
be a good addition to our redhat office functionality.