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 <[email protected]> > > > > > > >> 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. _______________________________________________ poppler mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/poppler
