Bug 691486

Something is wrong here. We should see the static view of the teapot which is
shows up with the 'display' device on windows when the following steps are
executed (-dPDFSTEP):

q    step # 129 ?
/GS0 gs    step # 130 ?
%Resolving: [15 0]
255 0 0 225 0 0 cm    step # 131 ?
/Im0 Do    step # 132 ?
%Resolving: [16 0]
Q    step # 133 ?

The job proceeds to the 'showpage' with the teapot still showing. The teapot
also shows up when running without -dPDFSTEP.

So the problem is that this static view is missing when I run (with 8.71 or
HEAD) to a device such as png16m.

Changing this to a 'normal' bug, not an enhancement. I will attach the screen
snapshot that we want to be able to get to print.

Created attachment 6529 [details]
fts_39_3905.png

Generated with 8,71 using:
    gswin32c -r150 fts_39_3905.pdf
then capturing the screen and saving it as a PNG.

This 3D annotation doesn't have /F attribute, which is considered 0 by default.
I.e. the annotation is visible but not printable. So Ghostscript skips the
annotation when the device has OutputFile attribute.

However, contrary to the spec, AR8 and AR9 consider Print flag (0x4)
to be always set for 3D annotations.

Created attachment 6544 [details]
patch

Render 3D annotations (using appearance stream) on the printer device even
if Print flag (0x4) is not set. This is done following AR8 and AR9 example
but contrary to PDF 1.7 spec.

Currently, /Printed attribute is set when currentpagedevice has /OutputFile
attribute. The customer, probably, needs to define /Printed attribute
explicitly.

Rendering of 3D annotations without appearance streams is a big project
that goes beyond this bug report.

The patch has been committed as a rev. 11541.
Regression testing shows no significant differences besides
progressions in the sample files rendering.

Changing customer bugs that have been resolved more than a year ago to closed.