Bug 687561

With the current GhostScript version (8.30), there is no special 
processing for execform. For each call, the marking operations in 
PanintProc are convered to PDF operators and included directly in 
the page stream. If the same form is painted multiple times (as is 
the case for logos/ watermarks/ etc), the equivalent PDF operators 
are included each time, resulting in a larger than needed. Not even 
an external tool can successfully detect and "collapse" the 
multiple occurences of the same form.

The proposed patch introduces a new implementation of .execform1 
specifically for PDF conversion. This new implementation is 
installed by .setpdfwrite, so normally won't affect output if 
using devices other than pdfwrite. If, however, a user executes 
.setpdfwrite with a different device (or changes the device 
afterwards), this implementation works as a "bare-bones" one (no 
caching) and the PostScript file still renders fine. The only loss 
may be some speed, because the implementation that does "caching 
using patterns" is unistalled (is gs_fform.ps used?).

The new .execform1 automatically calls pdfmark to convert the form 
into a separate Form XObject. Starting with the 2nd rendering of 
the form, only an /SP pdfmark is called, gaining both processing 
speed and output file size.

Some forms and some usage patterns produce better result than 
others, as described in the following paragraphs.

(A) Forms with a XUID
For these forms a single Form XObject is created, no matter how 
many times the form is loaded into VM, and no matter if it placed 
into local or global VM. .execform1 derives the xobject name passed 
to /BP pdfmark from the form's XUID; then, if the form is loaded 
into VM multiple times, it relies on the proposed patch for 
bug 687560 "Invalid PDF if /BP pdfmarks with non-unique /_objdef" 
to collapse the XObjects that correspond to th same form (the 
"same /_objdef == same XObject policy") into a single one.

(B) Forms without an XUID
For all form without an XUID, the /_objdef name is derived from a 
global counter. As long as the form dictionary does not loose 
its /Implementation key, .execform1 won't generate an extra 
Form XObject. 

(B1) Forms loaded into global VM won't loose this key unless the 
form is unloaded and reloaded, so the output PDF will normally 
contain a single copy of it.

(B2) Forms in local VM may loose the /Implementation after a 
restore, and a new XObject will be generated the next time the 
form is painted. Note: is such a case, the read/only attribute of 
the form dictionary is removed too, so it can be changed 
(/PaintProc replaced, etc). Any "caching" info has to be discarded, 
and a trick like the redefinition of restore in gs_fform.ps is 
not desirable ans may produce incorrect output.