Issue 38874

Summary: Incorrect Postscript rendering of EPS objects
Product: Draw Reporter: vcjones <v.jones>
Component: printingAssignee: wolframgarten
Status: CLOSED IRREPRODUCIBLE QA Contact: issues@graphics <issues>
Severity: Trivial    
Priority: P3 CC: flibby05, issues
Version: OOo 1.1.4Keywords: needmoreinfo, oooqa
Target Milestone: ---   
Hardware: PC   
OS: Linux, all   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Attachments:
Description Flags
Page 7, rendered as bit map with opaque EPS outlines
none
Page 8, rendered correctly, notice the right side of the printer icon
none
Excerts from the postscript file generated by OOo Draw.
none
Drawing (sanitized) which exhibits broken EPS rendering
none
EPS Icons used in drawing Broken_Drawing.sxd none

Description vcjones 2004-12-12 23:03:45 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.
Comment 1 vcjones 2004-12-12 23:13:23 UTC
Created attachment 20448 [details]
Page 7, rendered as bit map with opaque EPS outlines
Comment 2 vcjones 2004-12-12 23:20:45 UTC
Created attachment 20449 [details]
Page 8, rendered correctly, notice the right side of the printer icon
Comment 3 vcjones 2004-12-12 23:32:46 UTC
Created attachment 20451 [details]
Excerts from the postscript file generated by OOo Draw.
Comment 4 wolframgarten 2004-12-13 08:50:54 UTC
Would it be possible to attach the original file? It would be helpful if I could
reproduce the problem here. Thanks in advance.
Comment 5 wolframgarten 2004-12-13 09:06:24 UTC
Duplicate. 

*** This issue has been marked as a duplicate of 36640 ***
Comment 6 wolframgarten 2004-12-13 09:07:24 UTC
Sorry, this was a mistake. Reopened.
Comment 7 wolframgarten 2004-12-13 12:13:08 UTC
Priority changed.
Comment 8 vcjones 2004-12-13 19:18:48 UTC
Created attachment 20488 [details]
Drawing (sanitized) which exhibits broken EPS rendering
Comment 9 vcjones 2004-12-13 19:35:45 UTC
Created attachment 20489 [details]
EPS Icons used in drawing Broken_Drawing.sxd
Comment 10 vcjones 2004-12-21 20:19:04 UTC
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.
Comment 11 flibby05 2005-04-03 18:18:23 UTC
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
Comment 12 vcjones 2005-04-04 17:45:32 UTC
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
Comment 13 flibby05 2005-04-04 19:47:30 UTC
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
Comment 14 thackert 2005-07-03 16:04:18 UTC
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?
Comment 15 thackert 2005-07-03 16:04:36 UTC
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?
Comment 16 wolframgarten 2005-07-19 11:40:34 UTC
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. 
Comment 17 wolframgarten 2005-07-19 11:40:57 UTC
Closed.