Bug 142535
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] screenshot 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 Caolan, 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: http://bugzilla.abisource.com/show_bug.cgi?id=2462 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 file. 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. Marc 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 http://qa.openoffice.org/issues/show_bug.cgi?id=9290/http://qa.openoffice.org/issues/show_bug.cgi?id=14163 and it looks alright, better than uselessly doing nothing, stuff into a future RH rpm release ? Caolan, 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! Marc 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. |
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 properly. Version-Release number of selected component (if applicable): openoffice.org-1.1.2-11.5.fc3 How reproducible: Always 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.