[poppler] Drawing styledForm Widgets

Tue Oct 11 08:17:55 PDT 2011

On Tue, Oct 11, 2011 at 11:05 AM, Carlos Garcia Campos
<carlosgc at gnome.org> wrote:
> Excerpts from jose.aliste at gmail.com's message of mar oct 11 15:56:36 +0200 2011:
>> On Tue, Oct 11, 2011 at 9:53 AM, Albert Astals Cid <aacid at kde.org> wrote:
>> > A Dimarts, 11 d'octubre de 2011, Carlos Garcia Campos vàreu escriure:
>> >> Excerpts from Albert Astals Cid's message of mar oct 11 14:07:07 +0200 2011:
>> >> > A Dilluns, 10 d'octubre de 2011, jose.aliste at gmail.com vàreu escriure:
>> >> > > Hi list,
>> >> > >
>> >> > > there is idea, why not adding some support to draw style form
>> >> > > widgets
>> >> > > to poppler. I know that poppler is already doing that when
>> >> > > rendering,
>> >> > > but the idea would be to have a method that given a form widget,
>> >> > > either renders the contents of the widget for you with the correct
>> >> > > style, or some sort of struct with all the style information of the
>> >> > > corresponding constructed AP stream, so the frontends can use this
>> >> > > information to mimic poppler's rendering to render the widgets
>> >> > > themselves. In order for the first option to work, this rendering
>> >> > > should not depend on reparsing otherwise it would too slow
>> >> > > (Basically,
>> >> > > I consider that we could construct the AP stream and then using this
>> >> > > stream with some Gfx magic it should be possible to render the
>> >> > > widgets
>> >> > > value without reparsing and thus being fast enough to put this
>> >> > > method
>> >> > > in a widget-rendering callback)
>> >> >
>> >> > As I understand what you want is apps no longer "embedding" "real"
>> >> > widgets on top of the forms but the apps drawing the forms themselves
>> >> > based on info given by poppler?
>> >> >
>> >> > I am not sure this is going to be easy to do, since using "real" widgets
>> >> > gives you lots of functionality for free (e.g: copy/paste,
>> >> > keyboard/mouse handling, etc) and if we do what you say I understand we
>> >> > have to stop using "real" widgets and do all this stuff in the final
>> >> > app which will be lots of work. Of course that does not mean that we
>> >> > could still provide the option to have it and not make it mandatory.
>> >> >
>> >> > Or did I totally misunderstand what you meant?
>> >>
>> >> No, I think he means drawing current forms with the same style as the
>> >> widgets, using the current theme, but using real widgets for the
>> >> interactivity with the user. I don't know how it's done in okular, but
>> >> in Evince, we only use a real widget when the user clicks on a form,
>> >> and it's destroyed when the form is edited. This way we don't need to
>> >> keep widgets in the view all the time if they are not used. For some
>> >> forms like check and radio buttons we don't even use real
>> >> widgets. This way if you draw a choice widget exactly the same a
>> >> GtkComboBox would be, when you click on the form to edit it, ideally you
>> >> wouldn't even notice there wasn't a real widget.
>> >
>> > Ah, so instead of trying to render the real widgets like poppler renders the
>> > forms you mean trying to make poppler render like the "top level" application-
>> > widget is rendered.
>> >
>> Nop the idea is to takes poppler's rendering of the form field as it
>> is right now, and try to hook up this into the widgets rendering
>> painting method, or, to get the style from the field and apply this
>> style to the widget so you won't notice the difference between
>> poppler's rendering and the widget's rendering.
>
> I didn't understand this correctly then, in that case we just need to
> provide the font settings to the viewers, but that wouldn't work for
> other form widgets like lists or combos. The opposite makes more sense
> to me, drawing forms in document like the system widgets, like we do
> in WebKit.
You are right that I am not thinking yet of other types of form fields
or more complex form widgets, I first want to see if this is feasible
for text fields.

I think that  for html  makes sense to do it the way you describe, but
I am not sure it makes sense for PDF, as we are supposed to respect
the AP of the fields. So in this sense, I believe that to do either
approach (making poppler rendering similar to toolkits rendering, by
rendering the widgets offscreen i presume, or making the widgets
rendering similar to popplers rendering) would need a first step which
is a way of getting the Constructed  AP and then transform this into a
CSS that the corresponding toolkit will understand. So in this case,
it seems just easier to me to do the latter, i.e., just export the
CSS, and then use that to style the "Real" widgets.

Greets

>
>> > This probably makes more sense but i am not still sure how "easy/feasible"
>> > that is.
>> >
>> > Albert
>> >
>> >>
>> >> José, is that the idea?
>> >>
>> >> > Albert
>> >> >
>> >> > > Greetings
>> >> > >
>> >> > > José
>> >> > > _______________________________________________
>> >> > > poppler mailing list
>> >> > > poppler at lists.freedesktop.org
>> >> > > http://lists.freedesktop.org/mailman/listinfo/poppler
>> >>
>> > _______________________________________________
>> > poppler mailing list
>> > poppler at lists.freedesktop.org
>> > http://lists.freedesktop.org/mailman/listinfo/poppler
>> >
> --
> Carlos Garcia Campos
> PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x523E6462
>