Created attachment 12781 [details] PS source with nested forms pdfwrite appears to generate incorrect output on documents with nested forms. First page renders correctly, after which subsequent pages are incomplete. Example PS attached... (Not sure if this applies to other high-level drivers.)
Created attachment 12782 [details] Distiller output
Created attachment 12783 [details] GS output
The pdfwrite device does not support nesting of form XObjects, because Forms are not commonly used in PostScript, are even less commonly used sensibly and still less so nested. Note that until relatively recently we didn't preserve PostScript Forms as PDF Form XObjects in pdfwrite at all. If you want this to work you will have to use -dUNROLLFORMS, which will result in a PDF file where there are no Form XObjects, each iteration being drawn over again, just as it did before we introduced Forms support.
Hi Ken. Thanks for the workaround. The PS code is for demonstration purposes anyway. I'll accept a WONTFIX unless this bugs you enough to improve the entire form framework ;-) All the best.
(In reply to Terry Burton from comment #4) > Hi Ken. > > Thanks for the workaround. The PS code is for demonstration purposes anyway. > > I'll accept a WONTFIX unless this bugs you enough to improve the entire form > framework ;-) I'd like to fix it, because on the rare occasions people do use forms sensibly it can make a big difference to the output size of the PDF file, but I won't get to it in the near future. FWIW current code throws an error and suggests using -dUNROLLFORMS, this was (of course) added in 9.19 after someone complained that a file containing an invalid form didn't work: ----------------------------------------------------------------------------- GPL Ghostscript GIT PRERELEASE 9.20 (2016-03-23) Copyright (C) 2015 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. Loading NimbusSans-Regular font from /ghostpdl/Resource/Font/NimbusSans-Regular. .. 4053880 2473827 3047800 1737900 1 done. WARNING - Form PaintProc left operands on the stack after execution. This is technically illegal and these have been removed, if output is incorrect run again with -dUNROLLFORMS. WARNING - Form PaintProc left operands on the stack after execution. This is technically illegal and these have been removed, if output is incorrect run again with -dUNROLLFORMS. Error: /stackunderflow in --.execform1-- Operand stack: ----------------------------------------------------------------------------- Pedantically speaking the forms in your file don't leave junk on the stack, but the code for detecting that condition also finds the nested form and throws the warning. Because it also restores the stack to what it thinks is the correct condition it breaks the outer form (the inner processing has removed its form dictionary from the stack). So usefully it tells you there's a problem and how to fix it, even if the warning is a little misleading, so I plan to leave it like that until I can look at the pdfwrite code to see if it can be made to begin a new Form XObject while its in the middle of an existing one...... If it can't then I'll probably opt to detect the condition and disable the special form processing for high level devices, at least that way the file will work.
Thanks for sharing your thoughts. Sounds like a good plan.
For future reference the latest, most-clear version of the problematic document will be kept here: https://github.com/bwipp/postscriptbarcode/blob/master/contrib/Examples/variable_data_printing/vdp.ps
This turned out to be not so hard as I expected. Commit 5f4319612f1837f89b9586a5695018d3554325d8 resolves the problem with current code throwing an error on nested forms. Commit f7ffeb0319e112a1657987a9e5bad5b0f834a074 allows PDF output to contain nested forms. For 9.19 both of these commits are required, I suspect that 9.18 requires only the latter. For me this produces a file 114,561 bytes in size, compared to the same file executed with -dUNROLLFORMS which comes in at 6,197,754 bytes and the Acrobat Distiller X output which is 91.216 bytes. Additionally the file executes many times faster with this commit. Note that we still will not preserve forms used in a Pattern colour space, and will only preserve one level of Forms in PostScript output.
Awesome work. Tested and also works for me. Thanks!
User disabled due to spam, spam comment marked private to make it invisible