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 simply require an example 
and a brief explanation of the variables.

On 2002.04.04 12:07 J.U. Anderegg wrote:
> 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
> syntax and to some extent PDF file structure. They can try experimentally
> everything with the risk of invalid PDF in the document test phase. The
> document development might look like this:
>       - get documentation: PDF reference manual or see PDFmarks in
> http://www.math.uakron.edu/~dpstory/tutorial/pdfmarks/forms.pdf
>       - develop document without form fields
>       - use Acrobat to add the form fields to the document
>       - view the PDF document in ASCII e.g. with Windows WordPad and
> copy form
> field PDF objects into FOP markup
>       - test, modify FOP markup
> 2. Perfect, complete XML syntax for PDF forms covers all functions.
> Perhaps
> XHTML could do this job. The system is fully documented, so that users
> never
> have to care about PDF internals (my favorite reference document has 96
> pages). The PDFextension takes over FOP properties and uses existing PDF
> methods. Additional properties needed for PDF form fields are handled.
> Of course a clean system (2) is preferable. Where is the expert to take
> over
> this task? Not very elegant system (1) can be set up within 1 month
> assumed
> the pdf library offers an API to allow PDF extensions - the base for
> other
> developments. Once priorities are set, technicalities will be solved
> efficiently.
> Hansuli Anderegg, Zurich, Switzerland

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to