Re: Bug 304575 – support PDF forms

["Nickolay V. Shmyrev" <nshmyrev yandex ru>]

В Срд, 15/03/2006 в 08:42 -0800, Brian Ford пишет:
> On Wed, 2006-03-15 at 13:33 +0300, Nickolay V. Shmyrev wrote:
> 
> > Hello Brian
> > 
> > Really we've lost that deadline for PDF forms :) and it would be very
> > interesting to have such implementation. As far as I know nobody is
> > working on this. I suspect the implementation will affect poppler also,
> > so a mail to poppler list may have sense.
> > 
> > Please add comment to the bug as well and don't hide the intermediate
> > state, send us interfaces description and so on, even small movement in
> > this direction is interesting.
> > 
> > 
> > 
> 
> Thanks Nickolay, I'll post to the Poppler list.
> 
> The actual functionality that I most need is more along the lines of
> creating PDF forms to allow for automatically compositing a PDF document
> with field values from a database or web form. If anyone has ideas in
> this area, I'd appreciate hearing from you.
> 
> Thanks,
> Brian

Well, actually that seems a bit complicated task for me and probably I
event don't know how pdf forms should work actually. From different
points of view, for example in sight of task for implementing ally
support in evince I was thinking about the following:

Poppler should have markup output device that will out text marked with
locations + forms with locations, some kind of html probably. That will
allow implementation of ally cursor for text and we can use that markup
to render gtk widgets in EvView (it should not be hard since we are
using GtkLayout for EvView that is container actually and can have
embedded widgets).

Probably it's interesting to represent pdf document as set of images
(rendered in poppler) with such markup, but another representation can
be also natural. Although such point of view is a bit aside current
poppler organization.