Bug 142535 - [patch]PDF Export does not print embedded EPS figures in documents
[patch]PDF Export does not print embedded EPS figures in documents
Product: Fedora
Classification: Fedora
Component: openoffice.org (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Caolan McNamara
Depends On:
  Show dependency treegraph
Reported: 2004-12-10 09:50 EST by Marc Schwartz
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version: 1.9.112
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-06-29 04:54:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
The embedded EPS figure. A simple barplot created using R (http://www.r-project.org/) (3.00 KB, application/postscript)
2004-12-10 09:54 EST, Marc Schwartz
no flags Details
The Writer document containing the embedded EPS file (6.81 KB, application/vnd.sun.xml.writer)
2004-12-10 09:55 EST, Marc Schwartz
no flags Details
The PDF file created using the PDF Export function (17.48 KB, application/pdf)
2004-12-10 09:55 EST, Marc Schwartz
no flags Details
The PDF file created using the PDF Converter printer type (3.47 KB, application/pdf)
2004-12-10 09:56 EST, Marc Schwartz
no flags Details
screenshot (50.31 KB, image/png)
2004-12-13 06:48 EST, Caolan McNamara
no flags Details
use some external tools to make a preview (12.18 KB, patch)
2004-12-14 11:05 EST, Caolan McNamara
no flags Details | Diff
how the pdf from Export As PDF created like so end up (13.31 KB, application/pdf)
2004-12-14 11:06 EST, Caolan McNamara
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
OpenOffice.org 9290 None None None Never

  None (edit)
Description Marc Schwartz 2004-12-10 09:50:45 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

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):

How reproducible:

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.

Additional info:

Attachments to follow.
Comment 1 Marc Schwartz 2004-12-10 09:54:02 EST
Created attachment 108314 [details]
The embedded EPS figure. A simple barplot created using R (http://www.r-project.org/)
Comment 2 Marc Schwartz 2004-12-10 09:55:02 EST
Created attachment 108315 [details]
The Writer document containing the embedded EPS file
Comment 3 Marc Schwartz 2004-12-10 09:55:53 EST
Created attachment 108316 [details]
The PDF file created using the PDF Export function
Comment 4 Marc Schwartz 2004-12-10 09:56:38 EST
Created attachment 108318 [details]
The PDF file created using the PDF Converter printer type
Comment 5 Caolan McNamara 2004-12-13 06:48:12 EST
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
Comment 6 Marc Schwartz 2004-12-13 09:45:12 EST

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.

Comment 7 Caolan McNamara 2004-12-14 11:05:45 EST
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
Comment 8 Caolan McNamara 2004-12-14 11:06:26 EST
Created attachment 108526 [details]
how the pdf from Export As PDF created like so end up
Comment 9 Caolan McNamara 2004-12-14 11:18:37 EST
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.
Comment 10 Caolan McNamara 2004-12-14 11:20:46 EST
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 ?
Comment 11 Marc Schwartz 2004-12-14 13:17:58 EST

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.

In time...

Thanks again!

Comment 12 Dan Williams 2005-02-18 10:54:10 EST
hmm, caolan, I didn't seem to stick this into any release, right? 
BTW, where does pstoedit live?
Comment 13 Dan Williams 2005-02-18 10:54:48 EST
Hmm, pstoedit.net seems to be the place.  If we don't package it
already, perhaps we should?
Comment 14 Caolan McNamara 2005-02-21 03:26:41 EST
cmc->dcbw: Yeah, seems like a nice piece of ps conversion work, could
be a good addition to our redhat office functionality.

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