>From a users point of view, the XML tagging, like the inline SVG, sounds
great. I'd hate to have to program coordinates within the document.
However programming relatively to form position would not be so bad (like
SVG).
It may be good to keep in mind that someday other objects may be able to
call JavaScript in PDF's, like SVG's...
I'd be so psyched to see form fields available, even without JavaScript.
JohnPT
fop-dev-return-14092-jthaemlitz=oreillyauto.com@XML.
APACHE.ORG To:
[EMAIL PROTECTED]
cc:
04/03/02 04:50 AM
Subject: Re: Designing PDF extensions: form fields
Please respond to fop-dev
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 added to the PDFDocument.
From a users perspective the particular setup seems a bit awkward and too
specific. That is, why should a user need to insert PDF markup into the
xml which will have problems since it is incompatible with xml. The plugin
name "FOPplugin" is too general since plugins/extensions need to cover all
renderers and this is only for a specific renderer.
I don't like the renderClass and RenderMethod concept. That ties the xml
too closely with the implementation. For the xml input we should probably
be thinking more in terms of how the user should see the problem. They
want to insert a form into pdf.
So call the extension <pdfExt>. It could have an attribute type="form".
The form information could be more xml'ised. eg.
<form type="pb1">
<bg>red</bg>
<label>(Button)</label>
etc...
</form>
This way the information is xml, it is clear what the purpose is and the
code handles the implementation details.
We already have a system where extensions can be added that take the xml
and have access to the pdf document (eg for SVG), stream etc.
The pdf library will need to have the correct api for adding forms
including the xref data.
What do other people think? How does this fit with other ideas such as pdf
scripts etc.
Regards,
Keiron.
On 2002.04.02 10:08 J.U. Anderegg wrote:
> 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 to it into the PDF document catalog. So far quite easy.
>
> >From this experience I see now the design below for PDF plugins (rather
> "plugin" than "FOP extension", because this is only partially FOP
> business).
> Main areas of concern are the external interface and on the other hand
> general methods provided by FOP to generate valid PDF file structures.
> When
> this API is available, features like PDF JavaScript etc. will be easy to
> implement. Plugins are not allowed to modify any FOP code.
>
> XSL:FO will be device-dependent. So users will have to take care of that
> with XSLT.
>
> Hansuli Anderegg, Zurich, Switzerland
>
> ==================================================================
>
> EXTERNAL INTERFACE
>
> PDF Form Field Example:
>
> (1) <fo:instream-foreign-object width="50" height="12">
> (2) <FOPplugin type="PDFForm" renderClass
="PDFDocument"
> renderMethod="addFormField">
> (3) /T (pb1)
> (3) /FT /Btn
> (3) /Ff 65536
> (3) /H /P /F 4
> (3) /BS << /W 2 /S /B >>
> (3) /MK << /BC [ 0 0 0 ]
> (3) /BG [.7529 .7529 .7529]
> (3) /CA (Button) >>
> </FOPplugin>
> </fo:instream-foreign-object>
>
> (1) instream-foreign-object asks the FOP formatter for space.
> ________________________________________________________________________
>
> PDF RENDERER
>
> o The foreign-object method of the PDF renderer is called by FOP
> - arguments: type, renderer class, renderer method (Strings from
> 2) and
> rectangle coordinates, data.
>
> o control is passed to the specified class/method in "FOPplugin"
> - arguments: rectangle coordinates and unprocessed text of XML
> element
> "FOPplugin".
>
> (3) Just anything: in my case the text in native PDF form syntax from the
> FOPplugin XML element (transforming PDF form syntax into XML syntax does
> not
> make sense unless Adobe switches to XML). XML in case of SVG. Perhaps a
> differenciation between XML and non-XML data will be helpful. Of course
> the
> parser requires valid XML input. Character sets and line endings will
> have
> to be looked at.
> ________________________________________________________________________
>
> INVOKED METHOD by PDF renderer foreign object invokes in turn
>
> o special, separate plugin method(s) (most likely added to PDFDocument
> class)
> - the plugin has to setup his PDF objects, keep track of his
> object
> references.
>
> FOP has to enable the plugin to insert PDF objects by an API most likely
> to
> be implemented in the PDFDocument class.
> ________________________________________________________________________
>
> GENERAL PDFDocument METHODS provided by FOP
>
> - request a PDF object (including trailer objects) with ID and
> XREF
> maintenance
> - add entries/PDF reference ID's to catalog ("outline" requires
a
> catalog
> entry too)
>
> Basically this means providing external interfaces to the PDF package.
> Not
> so easy while keeping PDF integrity.
>
____________________________________________________________________________
> ______________________
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
