[poppler] Drawing styledForm Widgets

jose.aliste at gmail.com jose.aliste at gmail.com
Tue Oct 11 06:56:36 PDT 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.

> 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
>>
>> --
>> Carlos Garcia Campos
>> PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x523E6462
> _______________________________________________
> poppler mailing list
> poppler at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/poppler
>


More information about the poppler mailing list