Bug 691202 - Keeping the form resource during PS to PDF conversion
Summary: Keeping the form resource during PS to PDF conversion
Status: NOTIFIED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PDF Writer (show other bugs)
Version: 0.00
Hardware: All All
: P4 enhancement
Assignee: Ken Sharp
URL:
Keywords:
: 691220 693193 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-03-19 02:53 UTC by Marcos H. Woehrmann
Modified: 2013-09-29 20:09 UTC (History)
4 users (show)

See Also:
Customer: 210
Word Size: ---


Attachments
form_test.ps (843 bytes, application/postscript)
2010-03-19 02:53 UTC, Marcos H. Woehrmann
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marcos H. Woehrmann 2010-03-19 02:53:22 UTC
Created attachment 6102 [details]
form_test.ps

The customer would like a new feature:

During PS to PDF conversion, it seems that ghostscript always expands the content of a form onto the pages where the form is used.

form_test.ps is attached. It contains a very simple form definition which is used on 9 pages.

Running: gswin32c.exe -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -sOutputFile=tt3.pdf form_test.ps

The resulting pdf contains no form.

I also tested the file with Acrobat distiller, the resulting PDF can keep the form as resource and use "/Fm1 Do" on every papge
Comment 1 Ken Sharp 2010-03-19 08:04:43 UTC
I know this is a customer request, but I thought we normally rated enhancements at P4 even from customers ?
Comment 2 Ken Sharp 2010-08-13 10:44:05 UTC
*** Bug 691220 has been marked as a duplicate of this bug. ***
Comment 3 Ken Sharp 2012-07-21 08:43:14 UTC
*** Bug 693193 has been marked as a duplicate of this bug. ***
Comment 4 SaGS 2012-07-21 12:48:50 UTC
About this bug’s duplicates: there are at least 2 others.

    bug #687561 "Smaller PDFs when using execform"
    bug #688001 "Ghostscript doesn’t generate form XObjects"

Note the patch on bug #687561 uses an idea that did not go into the code (putting "multiple objects with same Distill-time name" at good use), and in any case needs some more though for the case of painting a same form with different clipping (so more/less of it is visible - any clipping existing at the time of execform must be kept outside the generated PDF Form XObject, and all marking operations from the PS form must be included into the XObject even if outside the current clipping path).
Comment 5 Ken Sharp 2013-09-26 09:01:16 UTC
I believe commit c561232cf26e060b89fc4f3bd4bf5c679731d4db will resolve this. 
Note that any form which relies on the CTM having particular settings will fail with this commit, because we reset the CTM in order to capture the form stream without the CTM baked in.

Two Quality Logic files break this, one uses setgstate inside the form to set the gstate to a stgate before the form was executed (this is of course completely barking mad). The other uses setflat and bases the value on the CTM at the time the form is executed. Because we reset the CTM for the course of the form, the setflat value is only appropriate for low resolution.

For these cases a new switch -dUNROLLFORMS will prevent pdfwrite attempting to preserve the form resource. The result will be correct, at the cost of the output being larger of course.