Apache OpenOffice (AOO) Bugzilla – Issue 3368
Postscript output wrong (DSC)
Last modified: 2003-09-08 16:56:16 UTC
The postscript output generated by the print option in OpenOffice apparently generates incorrect postscript. If I try to pass the output through a filter to juggle the pages (extracting certain pages, printing multiple pages per leaf etc.), incorrect results are generated. I am not a postscript expert, but as this problem occurs only with OpenOffice output, I assume it is a problem with OpenOffice. I assume the problem has to do with the document structuring convention being improperly implemented. My question would be, how soon is a problem like this likely to be fixed? It makes the program useless (to me). A secondary problem with the postscript output is that when a document contains certain fonts, the resultant postscript cannot be interpreted. I do not understand what determines whether a font fails. But some fonts, when viewed in the "Insert Special Character" dialog have a drop-down list box called "Subset," while others do not. Those fonts that do not, are the ones that fail. This secondary problem is less critical, since it can be worked around by not using the problematic fonts.
Further investigation reveals the apparent cause of the problem: OpenOffice does not insert the lines %%BeginDocument: and %%EndDocument at the beginning and end of included EPS files. I guess these comments serve to encapsulate the file and protect the rest of the document from being affected by comments (e.g. %%EOF) in the EPS file. Thus when EPS files are included, document structure comments in the EPS file incorrectly affect the overall document structure. Another fault in the EPS output is that page numbering starts at 0, whereas document page numbering starts at 1 in OpenOffice.
Further investigation on the font problem reveals that the problem seems to be associated with calls to psp_definefont, which seem to be incorrect when using those fonts which exhibit the problem. The faulty lines begin with "/ /", and a workaround is to simply remove those lines. A sed script for so doing is 's=^/ /=%/ /=' and by running this on StarOffice output, it is possible to correct faulty postscript data. An example of the faulty line when using the font Timmons is: / /TimmonsNormal psp_definefont It looks as if there should be a literal near the beginning of the line which is coming out blank. Not being a postscript expert, I was not able to immediately further diagnose the problem, but I hope that this information is sufficient for developers to identify the cause of the problem.
I've got problematic documents too (if needed, I can send them). Sending ps output to file, then opening using gv reports following gs error: Error: /undefined in 0.5: Operand stack: Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3 %oparray_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- Dictionary stack: --dict:1028/1476(ro)(G)-- --dict:0/20(G)-- --dict:92/200(L)-- Current allocation mode is local GNU Ghostscript 6.51: Unrecoverable error, exit code 1
Reassigned to Hasan.
Dublicate to closed task 6225 *** This issue has been marked as a duplicate of 6225 ***
As mentioned on the qa dev list on March 5th I will close all resolved duplicate issues. Please see this posting for details. First step in IssueZilla is unfortunately to set them to verified.
As mentioned on the qa dev list on March 5th I will close all resolved duplicate issues. Please see this posting for details.