Forms and JavaScript in PDF may be about as complex as xsl:fo. To get a
feeling for the learning, design and development effort see:
Acrobat JavaScript Object Specification, Version 5.0.5, Technical Note #
5186
Chapter Quick Reference Forms: 20 pages illustrated with Acrobat menues
Keyword
Hi Hansuli,
I see your point. A mininmal implementation that puts the effort onto the
users would be easier to implement and maybe it can be improved from that
starting point.
Exactly how complicated are these things if it would take 96 pages to
describe it to a user? Wouldn't one form type
Hi Keiron,
Let's fix a DESIGN GOAL. What can be realized in which time frame? I see 2
ways to go ahead:
1. Low level implementation using native PDF syntax: users have to learn PDF
syntax and to some extent PDF file structure. They can try experimentally
everything with the risk of invalid PDF
Hi Hansuli,
I think this idea will be useful to quite a few people. Others ahve shown
interest in these sort of pdf extensions in the past.
I agree with the general idea. Use an instream-foreign-object. Put in that
some xml markup that represents the PDF form (in this case). The data is
then
]
cc:
04/03/02 04:50 AM
Subject: Re: Designing PDF extensions: form fields
Please respond to fop-dev
I programmed PDF form fields into Fop-0.20.1. PDF form fields have an
annotation representation in PDF files with the subtype widget. So I
patched the external-link within the renderer code to process form fields.
Additionally a PDF fields object had to be added to the PDF stream and a
reference
