Postscript import (PS, EPS, PDF): EPS fails

[foxcole]

Sorry for the long silence. Now I have finally contacted the developers of the NCL software that produces the %!PS-Adobe-2.0 EPSF-2.0 EPS format. Here's their reply:

What NCL produces is in fact PostScript Level 2. Level 3 should be backward
compatible with level 2. Some printers will not yet accept Level 3 and that is why
we hesitate to flag our Postscript files at Level 3. It is my opinion that any printer
or application that honors Level 3 should accept Level 2.

The question now goes back to OOo: is there any chance that import of EPS of PostScript Level 2 will be supported in a future release?

Please understand this is a user-to-user forum, so we have no more control over what is considered for future releases than any other user does. You might have more luck asking that question on the OOo wiki or posting it as an issue (if it has not already been) in the IssueTracker. You'll need to register and log in to post but not to search.

My own guess is that PostScript 2 will not be supported in the future. Just getting that request put in and prioritized and scheduled would take so long that by the time the request comes up, that technology will be even longer outdated than it already is. You'll rarely (if ever) get any developers of any software in the world to retro-engineer their products to support old versions of any software other than their own.

Technology moves forward, which is both good and bad at the same time. It means we enjoy ever-increasing functionality but also must constantly update our equipment and our own software (if we're developers) to keep up with it. Therefore, that reply you received is patently ridiculous and is the kind of attitude that buries software vendors. It's a laughably stereotypical example of the "it's not our problem" reply that users have come to expect.

[acknak]

I'm really not an expert on the various Postscript/EPS levels, but my gut feeling is that you're barking up the wrong tree here. I don't think the problem has anything at all to do with the PS level being 2 or 3.

Is it the message that OOo gives you when you try to insert the graphic that leads you to this: "Unknown Graphic Format"?

If so, you should know that OpenOffice has about the worst error handling of any software I have ever used. The only good thing I can say about it is that it doesn't crash when it encounters an error. But the messages you get seldom give you any specific, useful information. Further, what they do tell you is often misleading or outright wrong. So always take an error message from OOo with a big grain of salt.

Here's some little experiments I did with your file:

File      Created by                Content Header  Insert > Picture
--------  ------------------------  ------- ------  ----------------
val.eps   (original)                 EPSF-2 EPSF-2    FAIL
val3.eps  eps2eps val.eps val3.eps    2+3     3       OK
val2.eps  edit header of val3         2+3     2       OK
val1.eps  eps2eps                     1       3       OK
           -dLanguageLevel=1
           val.eps val1.eps
val12.eps edit header of val1         1       2       OK
val3x.eps edit header of val          2       3       FAIL

It's a little hard to follow there, but you can see that no matter what the header says, the original file content always fails (top+bottom rows). OTOH, no matter what the header says, or whether the content is level 2+3 or level 1, the file content after processing by eps2eps always works (middle rows).

My conclusion from this is that it does not matter what Postscript level is used, or what the PS header says. What matters is the content of the file.

I don't know what features OOo is looking for in the file to conclude that the "graphic format is unknown" but I am convinced that it's not the PS level.

I'm not sure what your best next step is, but I don't think waiting for OOo to change is going to get you where you want to go.

[acknak]

Ok, here's the real kicker.

The result of eps2eps on your file is not so great. So, I took your file and ran it through epstool, which adds a preview image to an EPS file.

The result of that was far better: Writer would insert it, the preview was better, and Writer's performance was far better.

Looking at the EPS output from epstool, the only change it had made to the Postscript code was to move the bounding box statement from the end up to the top of the file. And in fact, if I do the same to your original file manually using a text editor, OOo will insert the file just fine.

So the Postscript level has nothing to do with whether OOo will handle the file, and it looks like epstool is the better EPS-file-fixer for you.

[foxcole]

Wow, acknak -- great job, as usual! I'm bookmarking this one for future reference.

(It might be interestng, letmo, to hear NCL's response if you were to send them ackhak's findings.)

[letmo]

Thanks a lot for your feedback and especially for your series of tests on my NCL-produced EPS file, acknak. Thanks to your help the core of my problem is finally identified.

With the command "epstool --copy val.eps val_new.eps" I could reproduce your results: on importing val.eps Writer produces "Unknown graphic format", whereas importing val_new.eps works fine. The only difference between both files is the position of the bounding box statement. My hypothesis is that this is because OOo is not able to handle the "%%BoundingBox: (atend)" statement in val.eps.

Concerning the bounding box, http://www.tug.org/docs/html/dvips/dvips_28.htm tells

If the file contains [...] a line like
%%BoundingBox: (atend)
the file is still probably Encapsulated PostScript, but the bounding box is given at the end of the file. [...] (The bounding box is given in this way when the program that generated the PostScript couldn't know the size in advance, or was too lazy to compute it.)

Thus, if it is possible for NCL to calculate the bounding box size in advance, the problem could be solved on their side. If this is not possible, then running epstool would be a workaround solution for me. A general solution would be to enable OOo to handle the "%%BoundingBox: (atend)" statement. A search for "atend" in Issue Tracker shows that this problem has been raised in Issue 9357 and is currently handled as Issue 28260 with priority P4.

As you suggested, foxcole, I have emailed the results along with a link to our thread to the NCL developer team. I will post their reply here.

[acknak]

Good work! Thanks for reporting that here; This seems like the right way forward.

OOo's support for EPS is not very robust, unfortunately. It seems to require lots of extra help. There have been some improvements though, so hopefully some of these things will be addressed.

[letmo]

Well, here is the reply from a member of the NCL developer team:

Putting the bounding box information at the beginning of the file is something
that we have on our list, but it requires that the information needs to be gathered
during the file creation and then inserted at the beginning when the picture
is terminated. Since we create the file during execution instead of saving it
in a buffer and writing it at the end, we would have to read the file that has
been created and then re-write it with the bounding box information inserted.
Since the ps2ps and ps2epsi tools are readily available, we have not assigned
a high priority to this task. My recommendation would be to write a normal
Postscript file and then run that through ps2ps. The version of ps2ps that I
have (which is two years old) also changes the Postscript level from 2 to 3.

If this becomes a big issue for people, then we will reconsider its priority.

It seems that at least three workarounds (ps2ps, ps2epsi, epstool) are working, which is one of the reasons why currently neither OOo nor NCL assign a high priority to this issue.

My thanks go to all involved for their help in identifying and solving this issue. I continue to wait for a better solution but I am happy to know rather easy workarounds for the meantime.

[xxhc]

NLC wrote

If this becomes a big issue for people, then we will reconsider its priority.

letmo wrote

It seems that at least three workarounds (ps2ps, ps2epsi, epstool) are working, which is one of the reasons why currently neither OOo nor NCL assign a high priority to this issue.

ok, here is my voice: I think it would be great to reconsider priority status of these issues.

The various issues submitted on this bug are as old as 4 years. As for me, I am frequently switching between LaTeX and OOo and dont feel like converting eps files too often by hand.

Thank you for the workarounds though!

[foxcole]

ok, here is my voice: I think it would be great to reconsider priority status of these issues.

This is a user-to-user forum. To make your voice heard, you need to go vote for and/or add comments to the issues you found in the issue tracker. This increases the issue's visibility because it helps increase the issue's 'popularity' ranking, one of many aspects that figure into an issue's priority assignment.

[markush]

I saw the issue is closed. Is it possible to reopen the issue?

[Bhikkhu Pesala]

Issue 28760 is not closed.

[markush]

Thank you, I overlooked this issue. But it is only about inserting the eps preview picture, which means that it is not possible to resize an eps graphic without quality loss. Eps is kind of a standard format in mathematics and physics, so I am sure that a lot of people would like to see open office to be able to treat eps files as vector graphics.

[acknak]

That issue is about a specific problem that prevents OOo from understanding certain EPS files. There are workarounds for that specific problem mentioned above in this thread.

There is no general problem with inserting or resizing EPS files in OOo.

If you have a problem that's still unresolved, please start a new thread, and explain exactly what your problem is. If you have a particular EPS file that OOo doesn't like, it would be helpful to attach it to your message.

[markush]

The problem is, that afaik open office cannot treat eps as a vector graphic. You can just insert (and rescale) a preview pixel picture of the original vector graphic. And that is a serious shortcoming. Open office should be able to render eps as a vector graphic.

Please correct me if I'm wrong...

[acknak]

That is not really correct. OOo supports EPS files as a vector format, including scaling. However, there are some important limitations.

Under circumstances where the output can't handle the vector information, OOo will substitute the preview image. E.g. the screen display always shows the preview image, as does PDF output. Printed output, or "Print to File" output (Postscript), will include the vector information at full resolution.

At least, that's the case on Unix/Linux (&Mac?) where the printing system handles Postscript well. I'm not sure about Windows, where Postscript support is not always available.

If you're finding that you're getting the preview image in your output, you may be able to take a different route and get better results. You can either convert the EPS to a different format, or use "print to file" to get Postscript output and then print that, or convert it to PDF.

[markush]

Good to know. I am mainly interested in screen display (making presentations with impress). In which format should I convert my eps files?

[acknak]

Beats me. I really don't know what EPS features OOo requires--well, I guess we know about the "(atend)" problem.

I use the command line utilities eps2eps (comes with ghostscript) and epstool (Google for it) are adequate to do whatever conversions I've needed. Sometimes it's easier to simply convert the EPS to an image. I use "convert" for that (part of Image Magick) and it's easy to get a nice image at any resolution--more than adequate for screen display.

[shardalule]

For me PS is also not opening in Openoffice calc or word.please can people help me out.How to export PS Script in OpenOffice by using which tool .

[Hagar Delest]

Have you read the first reply of this thread???

.ps file cannot be imported in word processors.

And please stop multi-posting.