[poppler] SWIG wrapper for poppler

[Albert Astals Cid]

A Dilluns, 8 de novembre de 2010, Tim Brody va escriure:
> On Fri, 2010-11-05 at 19:12 +0000, Albert Astals Cid wrote:
> > A Divendres, 5 de novembre de 2010, Tim Brody va escriure:
> > > On Thu, 04 Nov 2010 18:55:25 -0000, Albert Astals Cid <aacid at kde.org>
> > > 
> > > >> Basically I'm sruck with the same concern here:
> > > >> http://lists.freedesktop.org/archives/poppler/2006-January/001522.ht
> > > >> ml
> > > > 
> > > > Care to elaborate?
> > > 
> > > The front-ends provide APIs for rendering PDF, whereas the core classes
> > > also provide a PDF API.
> > 
> > Because noone added a good API in the frontends to modify the PDF.
> 
> It looks like Annot could be a sub-class of Object rather than
> containing an Object copy?

What does this have to do with frontend API? Annot and Object are both 
core/nonfrontend classes

> 
> The dict* methods could then be exposed through the front-ends e.g.
> poppler_annot_dict_lookup( "foo" );
> poppler_annot_dict_set( "foo", Obj );
> With appropriate wrapping for Dicts/Streams etc.
> 
> Or I could add specific accessors to glib to read/write the Dict and add
> 'getAnnotObj()' to Annot.h.
> 
> 
> But I don't want to start on this if it is unacceptable that:
> poppler_annot_dict_set( "Color", ... );
> Would not update 'protected AnnotColor *color' - with the implication
> that get_color() won't return the new color of the Annotation.

That's glib API, i'll let Carlos answer that part.

Albert

> 
> (Of course in this instance you would use set_color but the idea is that
> for unsupported PDF attributes you can use the low-level methods)
> 
> 
> /Tim.