Apache OpenOffice (AOO) Bugzilla – Issue 9290
Render EPS graphics without previews
Last modified: 2010-08-03 12:15:32 UTC
If I have a document open in the word processor and I import a eps graphic it doesn't actually get drawn in the document display window. I have been told this is because OpenOffice/Star/Office doesn't include a postscript renderer. Since you are using ghostscript for printing (at least on Linux) why not use it as a postscript renderer too? I just tried this with OpenOffice643 and it draws a bounding box where the graphic would appear but not the actual graphic.
Why not include a preview-image in the eps? OOo can then display the preview image. It is not true that OOo uses ghostscript for printing. OOo creates postscript itself. ghostscript is in turn used by your printing system. OOo is using ghostscript to create pdf-files (in the next release there will be native-pdf export - so gs is then not used/needed anymore). I myself think that implementing a ps renderer would not make much sense, since all you have to do is create eps with preview (that's why it is possible to add a preview to eps). If you insist on your RFE, then please tell me.
Yes, if you have a preview in EPS, tihs is correctly displayed. But if you print such document on non-postscript printer, only this preview is printed - if this EPS contains some text - the quality is much decreased. Such OpenOffice document is not full transferable between users. Some user has poscscript printer, some not.
Reassigned to Bettina.
This is a rather old RFE which has been duplicated with some other Issues in the meantime. Have searched Issuezilla for a "Render EPS" request that has been set to New. There is none. As this seems to be a reasonable request I will set this to new and will close the other as duplicates of this.
*** Issue 22251 has been marked as a duplicate of this issue. ***
Summary changed following the reporters intentions as expresses in comment dated May 2003
*** Issue 22113 has been marked as a duplicate of this issue. ***
If people embed eps files that do not have previews into a document, and use the OOo Export as PDF function then they'll get the placeholder graphic rather than the rendered eps, seeing as there isn't an eps rendered in OOo. Is that correct ?
Yes this is correct when using the native PDF-export. See issue 14163
Created attachment 20510 [details] a patch that attempts two fallbacks on external tools to make a good preview for eps.
The attached patch tries to use pstoedit to make a very nice quality emf preview if one is missing, and then falls back to trying to make a not so good png one with ghostscript to png. (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=142535) How about that for a relatively painfree solution ?
Retarget to OO.o 2.0.1.
I find convert (from ImageMagick) more robust/not so picky about the input compared to using ghostscript directy. With ghostscript I had bounding-box troubles (I ended up with a white "preview" because the real image was offset out of the visible area) with ghostscript that I did not have when using convert so I modified the attached patch to use convert instead of ghostscript - you can even specify a density/resolution value. The good thing about this issue is that the preview is stored within the document so it is available to OOo versions that don't have this patch applied. (And this is the drawback as well since the filesize increases because of this preview) ############## Summary: I'd appreciate if another fallback would be introduced: 1st try pstoedit, then convert, then ghostscript or just replace the ghostscript-solution by the convert one.
*** Issue 50447 has been marked as a duplicate of this issue. ***
cloph: can you attach the modified patch to use convert as well ? In #i14163# thb proposes that I go ahead with the patch.
Since I adapted the patch only for myself, I did not *add* convert, but simply replaced the ghostscript-command with a convert-command. Also note that I did not properly adapt the ifdef windows case!
Created attachment 27158 [details] modified patch - uses convert instead of ghostscript
Hi Thorsten, please take this patch to your ownership. Thank you. Having spoken about I think this is no OO.o 2.0.1 issue.
Created attachment 27236 [details] clophs stuff merged into my orig patch
@bh: indeed. At least for myself, I probably won't make it for 2.0.1, especially since the Windows side is still open. Retargetted to OOo later, but set 'needhelp' keyword - if somebody is willing to implement and QA a fully working cross-platform solution, I'll be happy to take that into an earlier release.
? What is the problem with windows? ghostscript exists for windows, ImageMagick (=convert) exists for windows and even pstoedit is available for windows. So the exact same mechanism is used on linux and windows. This solution is cross-platform and is working fine. IMHO the helper-programs should /always/ be used, not only if there is no preview available. When the helper-programs are not installed, it doesn't mean loosing anything, it falls back to drawing the red-box.
@cloph: I'm well aware of that, but consider the probability of having pstoedit in the %PATH on Windows to be extremely low - in contrast to *nix.
I am personnaly against using convert for handling eps. I am frustrated with the inability of OOo to handle eps properly in linux. I usually use latex so it is usually not a problem but when I have to use OOo it is a pain. I thought I could just use convert to transform my eps in png or jpg or whatever. The problem is those format are not vector format and don't scale well. I often need to rescale those eps figures (Mathematica export microscopic figures whatever the format). I thought I could use "convert -resize xxx%" to make a bigger figure that I could then scale down, unfortunately it converts the vector graphic to a bitmap and then resize the bitmap (even if you want to resize an eps to an eps) which makes again an ugly figure.
@fbissey: and naked ghostscript produces better output for your testcases?
@fbissey: If you use the wrong parameters, you cannot expect a decent result. Resize alone is not enough. Much more important is the density (that is what I use in my patch). For more details please read the ImageMagick manpage. When blowing up a 72dpi image (that is the default density when not specified otherwise) it is not surprising that you'll get a pixelated result. ############## @thb: You wrote: > I'm well aware of that, but consider the probability of having pstoedit > in the %PATH on Windows to be extremely low - in contrast to *nix. Not necessarily. I don't know pstoedit, but other software such as GTK set the path accordingly. And even if it would not find one of the helper programs: You'd simply get the old behaviour with the red box. I don't really see that as a drawback.
*** Issue 54772 has been marked as a duplicate of this issue. ***
Seriously ? I have to patch recompile and OpenOffice by hand now ? I don't know, I've heard the compile process is very long and I had to send my work tomorow morning :( Maybe you can't point me to a binary version of OpenOffice where the patch has already been applied ?
thb - what is your opinion? Even when the programs are not available on windows, the patch doesn't remove functionality for those systems and doesn't render the files incompatible. ##### @thb: You wrote: > I'm well aware of that, but consider the probability of having pstoedit > in the %PATH on Windows to be extremely low - in contrast to *nix. Not necessarily. I don't know pstoedit, but other software such as GTK set the path accordingly. And even if it would not find one of the helper programs: You'd simply get the old behaviour with the red box. I don't really see that as a drawback. ##### I can only see benefits (even though not everyone can benefit from it without installing additional software). ImageMagick has a windows-binary version with installer that does set up everything necessary. So please rethink the target (I'd love to see this is 2.0.2 - I used the patch with every version I compiled and could not see any regression)
@cloph: this was even scheduled for 2.0 - in principle, I have no problems with this patch, I even asked cmc whether he would champion to add that to one of his CWS. Thus, as always: if time permits, 2.0.2 is possible.
oky doky, I propose to do the "try some external programs to make a preview" patch under this id. issue 14163 can be left for some alternative native OOo solution.
done in epspreview. will build installsets and make up a testcase
change component
Created attachment 31784 [details] sample eps
reopen for qa
reassign
implemented in epspreview
*** Issue 59327 has been marked as a duplicate of this issue. ***
Verified.
*** Issue 61182 has been marked as a duplicate of this issue. ***
closed, in master
I tried OpenOffice 2.0.2 on Windows XP SP2 and the problem is not solved. When I print an eps image produced by matplotlib, I get a red rectangle with some text inside : "Title:C:\Documents and Settings\ Creator:matplotlib version 0.87.2, http: CreationDate:Wed Jun 14 22:30:44 2006" (This works with MsWord for example)
Why is this CLOSED/FIXED? OOo Draw 2.4 most certainly does NOT render EPS images, but uses the awful, low-resolution bitmap preview embedded in it.
Strange behaviour OO3/Windows: summary: it does not work - path is searched for: pstoedit, convert and gswin32c, first without then with exe suffix - if any of the executables are found, they execute with correct command line and they do the right thing (verified with procmon) - still no preview appears in openoffice - is there a problem with i/o-redirection? another anomaly: - oo3 disregards the order of search paths in the %PATH% environment variable and always searches c:\windows\system32 first, where it findes convert.exe, which is a Windows filesystem tool.
Can you please integrate the ability to use EPS graphics native in OpenOffice.org? It is not working in 3.2.1. Only a placeholder is shown. Thanks.