Apache OpenOffice (AOO) Bugzilla – Issue 38874
Incorrect Postscript rendering of EPS objects
Last modified: 2005-07-19 11:40:57 UTC
Large network drawing (32" by 42") containing several hundred EPS icons (most with associated text), several hundred polylines, tens of boxes and texts fields, and a half dozen bit maps for 1309 objects all together. I cannot get draw to generate correct output. SuSE Linux 9.1, 2.6.9-ac8 kernel, X.org 6.8.1, KDE 3.3.1 level a, Pentium-M 1.4Ghz, 768 MB RAM, 1 GB swap, plenty of disk space. Printing to postscript printer using US Letter sized paper, shrink to fit mode. Drawing is rendered (in postscript) as bit maps, which render incorrectly (bounding box of EPS icons are printed as opaque white rectangles). Printing to postscript printer using 8-1/2 by 11 paper and posterizing, the first seven pages are printed as portrait oriented bit maps with incorrect rendering of the EPS icons and 1/4" margins on the page. The last nine pages are printed using EPS encoding of the icons and is correctly rendered as far as transparency of the bounding boxes but are landscape mode with no margins on the page (but overlapping rendering from page to page allowing easier cut and paste). Tried various settings of printer resolution, postscript level, etc., and have been unable to change the behavior. Ditto with various releases of OOo and StarOffice. All behave the same. Test drawings using the same icons work fine render correctly. There are NO error messages and console output.
Created attachment 20448 [details] Page 7, rendered as bit map with opaque EPS outlines
Created attachment 20449 [details] Page 8, rendered correctly, notice the right side of the printer icon
Created attachment 20451 [details] Excerts from the postscript file generated by OOo Draw.
Would it be possible to attach the original file? It would be helpful if I could reproduce the problem here. Thanks in advance.
Duplicate. *** This issue has been marked as a duplicate of 36640 ***
Sorry, this was a mistake. Reopened.
Priority changed.
Created attachment 20488 [details] Drawing (sanitized) which exhibits broken EPS rendering
Created attachment 20489 [details] EPS Icons used in drawing Broken_Drawing.sxd
Finally tracked down what was causing the incorrect rendering. There was a transparent bit map in the drawing. As has been noted before, transparent bit maps and encapsulated postscript are a fatal combination for the print engine in OpenOffice/StarOffice. A more descriptive warning message might be appropriate. However, this does not close the issue, because trying to render the same drawing with openoffice.org1.9.65 fails completely, running out of memory (768M real, 1.5G swap) after a few hours of grinding away on a 1.4 GHz Pentium-M. This compares with OOo 1.1.3, which only required about 30 minutes and 500M of swap.
Hello vcjones, since you reported this issue for Linux, please attach the Icon zip-file as *gz or *bzip with paths preserved. I was not able to open the sample file without link errors. Creating /Gallery/Cisco in the same directory did not help either. Regards, Max, OOo Volunteer
Max, Thanks for taking a look at this. The drawing was created with the icons located in the directory /home/vcjones/gallery/Cisco and the drawing itself in the directory /home/vcjones/Active/DuaneRd/StoreUpgradeT1/Documentation If this does not work for you, please let me know and I will try to retrieve everything from backups and recreate the problems. Note that now that we know that the cause is handling of a bit mapped graphic, it should be easy to recreate in a much simpler diagram. Vincent C Jones
Hello Vincent, i could open the doc now, however it is just too big to work on this with my system. As you seem to be quite familiar with Draw (congratulations to this masterpiece! ;-) could you please create the reduced testcase. I cannot promise anything but having a testcase will result in quick confirmation of this issue and developer attention then. Thanks a lot, Max
I have seen that the last entry here was in April and that this issue is OOo 1.1.4 related ... @vcjones: Have you tried this with a newer version of OOo like 1.9.1xx (not sure which is the last official one ... :( )? Does your problem occur there, too?
Since there is no smaller testcase available and nothing is wirtten about the behaviour in a more current version I have to close this issue. Please feel free to reopen it if someone has more info. Thanks to all.
Closed.