Apache OpenOffice (AOO) Bugzilla – Issue 19509
OOo doesn't know how to print EPS figures to Postscript printers
Last modified: 2004-03-12 13:17:07 UTC
If I insert an EPS graphic into a Writer document, and try to print (to Postscript), the EPS is not printed. Instead, Writer produces a listing of the Postscript code where the graphic should be. The same graphic works correctly in other Unix programs (e.g., tgif) and also in Windows programs (e.g., Microsoft Office). This is similar to but different from issue 14163, which deals with PDF generation.
Draw also can't print EPS correctly even though OpenOffice's built-in printer driver is specifically for printing to Postscript printers.
It seems that OOo can correctly print some EPS files while it would not print some others. I'll try to track down whether I can find a pattern as to what kind of EPS files it will print and what kind it will refuse to print.
Can you attach a non-working EPS file to this issue?
It seems that OOo is confused by Macintosh-style line endings (\r instead of \n or \r\n); when such files are imported, OOo seems to completely corrupt the Postscript code it has read. Only EPS files created on a Macintosh seems to be affected; EPS files with Unix line endings seems to be ok.
Simple hand-written EPS files do not trigger this bug; perhaps there is a buffer size problem in OOo. I'll try to create some relatively largish EPS files on the Mac as a test case. This and Bug 17128 seem to be the same bug. Sorry I missed that one when I file this; perhaps one of them could be marked as a dup of the other.
Created attachment 9740 [details] Sample problematic EPS
Note: This one crashes the resulting Postscript code, instead of producing a listing. I'll try to find out which file produced a listing in the Postscript output, and attach another sample when I find one.
component is gsl, but still writer is qa-contact. Reassigning and confirming (since very detailed report - cannot test myself)
*** Issue 17128 has been marked as a duplicate of this issue. ***
works for me. the resulting postscript file has the full eps file embedded. I can view it quite fine with plain ghostscript 8. please provide a complete document that fails (sxw and "print to file" file), a description which programs do fail (which revision), is there any error message ? cp->pl: please take care of this one.
Created attachment 9805 [details] Test sxw document
Created attachment 9806 [details] Test "print to file" output
I had indicated in my original report that swriter and sdraw from 1.1rc4 failed. No error message. I just found that swriter, sdraw, and simpress from 1.1rc5 also are failing. Also no error message. (scalc from 1.1rc5 segfaults, but it segfaults no matter whether the EPS has Mac or Unix line endings, it seems, so scalc doesn't count.) I have not checked the other OOo programs yet. If system library versions matter, kernel is GNU/Linux 2.4.21; libc is glibc 2.2.5; X is XFree86 4.3.0 + nvidia driver 4191. Happens whether I keep my usual locale or clears the locale before I run OOo.
For me the attached "testeps-m-ai.eps" shows the "preview problem" as per issue 12591, so I can not use the testkit for WIN. It seems that it is not a problem in WIN98, I successfully printed a textfile with EPS image in it for issue 10073 Rainer
I found that OOo handles the EPS I submitted correctly under Debian Sid on the x86. From past experience here, I'd guess the ticket will be immediately closed with WORKSFORME; but I think this is the wrong way to handle open-source software bugs, since this inconsistency just means that there is some unknown library dependency in OOo, and an open-source methodology is supposed to be good at tracking down (or at least cares to acknowledge the existence of) such things. OOo bug tracking seems so far to me to resemble commercial software development instead of open-source software development. I'm in the process of setting up some x86 box running Debian Woody (a deliberate attempt to use non-current but still reasonably stable library versions) and try to reproduce the problem on that box. Results will be posted when they are available. If the Debian install does not reproduce the problem, I'll continue to try Sarge (slightly newer but unstable) and then CLE (hacked Red Hat for Chinese locale).
I tried the attached text.ps, but I can not open it with GV, sometimes GV crashes, sometimes I get error messages like followint. Rainer GSview 4.3 2002-04-30 AFPL Ghostscript 8.00 (2002-11-21) Copyright (C) 2002 artofcode LLC, Benicia, CA. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Displaying DSC file D:/TEMP/oootestfiles/19509_postscriptprint/test.ps Displaying page 1 Error: /undefined in E1F202122 Operand stack: Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop 1 3 %oparray_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- Dictionary stack: --dict:1055/1123(ro)(G)-- --dict:0/20(G)-- --dict:85/200(L)-- --dict:85/200(L)-- Current allocation mode is local Last OS error: No such file or directory --- Begin offending input --- %%Page: 1 1 %%PageBoundingBox: 18 18 594 774 %%BeginPageSetup % [{ %%BeginFeature: *Resolution 720dpi 1 dict dup /HWResolution [720 720] put setpagedevice %%EndFeature } stopped cleartomark gsave [0.1 0 0 -0.1 18 774] concat gsave %%EndPageSetup grestore gsave readpath V096F0183B0003A3E03A300B0083A3~ closepath clip newpath /b4_Inc_state save def /dict_count countdictstack def /op_count count 1 sub def userdict begin /showpage {} def 0 setgray 0 setlinecap 1 setlinewidth 0 setlinejoin 10 setmiterlimit [] 0 setdash newpath /languagelevel where {pop languagelevel 1 ne {false setstrokeadjust false setoverprint } if }if grestore gsave readpath V09740186B000399E039900B008399~ closepath clip newpath 1208 5915 translate 10.01087 -10.01087 scale %%BeginDocument: (testeps-m-ai.eps) E1F202122 232425262728292A2B2B2C2D2E2F303132333435363738393A3B3C3D3E3E3F404142434445464748 494A4B4C4D4E4F505152535455565758595A5B5C5D5E5F60606162636465666768696A6B6C6D6E6F 707172737475767778797A7B7C7D7E7F808182838485868788898A8B8C > < FF --- End offending input --- file offset = 5505 gsapi_run_string_continue returns -101
Only an idea: can anyone check whether there is a relation to issue 10309?
This kind of crash is exactly what I am seeing. The "freezing", however, is a different thing; it is most likely because OOo is setting the device resolution (Bug 19521). (The freezing will stop if you manually take out the lines between the "*Resolution" feature DSC comments.)
What freezing, didn't see any freezing mentioned ? BTW: resolution is only set if you changed it in spadmin from the default value, so as a workaround you can try to set it back to default.
gv freezes when Ghostscript crashes (due to the setpagedevice call to set the HWResolution) but it fails to detect the crash; when this happens, the user sees the underlying gs crash as a gv freeze.
That's more of a gv problem then. The feature commands (usually set with setpagedevice) are straight from the PPD and of course only valid for the printer the PPD describes.
[The "freeze problem" does not belong to this bug. It should be moved out of here.] No, the problem is gs crashing due to unnecessary resolution setting, it's really a gs problem, not a gv problem. Currently, there is no way to specify "no specified resolution"; OOo always sets the resolution when the bulk majority of Unix programs (and even professional page layout programs in other platforms) do not generate such Postscript code.
OOo generates that code if you changed the printer resolution from the default in spadmin. Setting it back to the default value should solve the problem. As i said the resolution feature like all othe features comes directly from the PPD file used and is valid only for the printer that is described by that PPD file.
No, the default resolution is "300dpi" even for the "Generic" printer. If the resolution is reset to default, Postscript code to set the resolution to "300dpi" is emitted.
That sounds more like a bug to me. Still, the result should be valid for the printer concerned. What version of gs are you using ? I tried 8.11 and 7.05 which both do not have a problem with the resolution commands out of the "Generic Printer" PPD.
The bug hit me today again, OOo 1.1.0. With Illustrator 8 (Mac version)-saved EPS, OOo swriter will print the first few lines of Postscript comments if I save with either Mac 1-bit preview (should be same as no preview) or PC-style TIFF previews. If I use Ghostscript's ps2epsi to convert the EPS into an EPSI file, OOo displays a blank box on the screen but prints the EPS fine. I'll see if I can create a small EPS to reproduce the problem.
I don't have access to a Mac (or Adobe Illustrator) any more. :-( I wonder if there are other OOo users who use Illustrator and/or deal routinely with EPS files out there...
started
update target
pl->ja: i cannot reproduce the behaviour with 1.1.1. Unless someone can i'd suggest closing this one.
JA: reset target to ---. Unless this issue wasn't able to be reproduced I'll close this issue as worksforme. If somebody is able to reproduce it in the latest 1.1.1 build he/she can reopen it again.
.