Overlapping/interfering bitmap output of shaded views on drawing - Creo

[dschenken]

There's a user with Creo 2, M120 who has a drawing with multiple shaded views. When the drawing is output as PDF there is a rectangular white opaque back ground for each of the views. This causes views which overlap to be masked.

Supposedly this was fixed in Creo after being seen as a problem in WF; but the user is using Creo 2.

Is there:

1) a config option that controls this or

2) a case of backsliding in software development or

3) a problem that only happens with an external distiller for Postscript

4) Other?

Any hints?

This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.

[TomD.inPDX]

Using the save-as>export>PDF (default), I get this when overlapping shaded views.

Should this show something as you are describing?

Creo 2.0 M040

[dschenken]

I think that should show it - It's a white backdrop rectangle that entire underlays view and covers the lower z-order views.

I'm leaning to #3 as Postscript output tends to be opaque and would require a clipping boundary to prevent overstamping; PTC has not treated Postscript well, certainly not well enough to suggest they would fix their raw Postscript output for external consumption. Adobe added transparency support to Postscript, but it was a late addition.

[TomD.inPDX]

I am pretty sure that the output to the postscript processor is a PNG underlay image with the linework on top.

I can see a few important improvements in the PDF export routine. What you describe I haven't seen. Hopefully it is not a problem introduced in later versions. I have a significant dependency on shaded PDF drawings for presentations.

[dschenken]

No PNG in postscript that I know of. It has it's own bitmap compression algorithms.

From Adobe Technical Note #5115,

The standard encoding and decoding filters available in PostScript Level 2

are: LZW, Run Length, CCITT Fax (Group 3 1-D, 3 2-D, and 4), DCT

(Discrete Cosine Transform, based on the proposed JPEG specification),

ASCII base-85, ASCIIHex, NullEncode, and SubFileDecode filters.

Since it is a programming language anyone can add their own compression/decompression so I guess someone could add PNG for a particular postscript stream.

I think the problem is that PTC doesn't create an image mask for the postscript output of the view bitmaps and that means the background is rendered as opaque white when distilled to PDF.

It's a shame that there isn't better postscript support in Creo. I begged for 2 bits to change setlinecap and setlinejoin and the developers never made the change (to WF5). I also begged that the headers and footers for postscript pages and the header and footer for postscript documents not be compiled into the Pro/E and Creo code, instead leaving it where it could be corrected. And I wanted even as little as post-header, pre-footer include file options to customize the output.

Instead of fixing the 2 bits, they added two config items for fixing the PDFs for setlinejoin and setlinecap.

[TomD.inPDX]

When I open the images in the PDF with PaperPort (PDF Viewer Plus), it opens as BMP 24 bit 72 DPI.

Funny thing is that somehow overlapping views have to understand priority. Once I edit overlapping images in PaperPort, these priorities are not assured.

The frame of each image for the most part is right up to the geometry. On some exploded views, this extent is significantly further.

I have a good reference with my views because I use only shaded views (no edges). On top of that I have the normal hidden (wireframe) views to make sure I get good black edges instead of gray ones. I also get explode lines to hide themselves in the hidden view where in shaded views, they are not clipped as expected.

I guess this could use some further experimentation. But to date, I have not had an issue with one view clipping another.