[poppler] SWIG wrapper for poppler

[Albert Astals Cid]

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>
> 
> wrote:
> > A Dijous, 4 de novembre de 2010, Tim Brody va escriure:
> >> On Wed, 2010-11-03 at 18:52 +0000, Albert Astals Cid wrote:
> >> > A Dimecres, 3 de novembre de 2010, Tim Brody va escriure:
> >> > > I've reworked my SWIG wrapper into a patch (attached).
> >> > > 
> >> > > I'm no expert on automake and pretty new to SWIG - I've
> >> 
> >> copy-n-pasted
> >> 
> >> > > most of the SWIG stuff from Xapian.
> >> > 
> >> > I'm not sure if you are aiming for inclusion in mainline poppler or
> >> 
> >> just
> >> 
> >> > want to share your patch.
> >> > 
> >> > If you aim for inclusion in poppler, i'm sorry but we don't want
> >> 
> >> people
> >> 
> >> > using the internal core structures so we can't accept your patch. You
> >> > should be using any of the three public frontends qt/glib/cpp
> >> 
> >> The 0.12 front-ends don't do what I require:
> >> 1) Search PDF for patterns of words (or regexp a single word)
> >> 2) Add link annotations
> >> (And in 0.15 retrieving all text with positional data is very
> >> inefficient - re-display() for every word?)
> > 
> > Then you have two options:
> >  * We do not commit your patch and you apply it locally for your uses.
> >  * You send a patch to make the frontends do what you need.
> > 
> > Note that 0.12 is old and you shouldn't be using it.
> 
> 0.12 is the current release on Ubuntu/Fedora 13 (0.5 on RHEL5!).

So? 0.12 is still old and should not be used for development.

> For my
> current needs I'll just wrap the core classes, for reasons outlined below
> I don't want to put the effort into wrapping front-ends yet.

Ok, then it'll just won't be added into poppler. Good luck with your needs.

> 
> >> Basically I'm sruck with the same concern here:
> >> http://lists.freedesktop.org/archives/poppler/2006-January/001522.html
> > 
> > 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.

> If I wanted to add/use an
> attribute that isn't in the PDF spec. would poppler add accessors for that?

Don't understand the question.

> Putting aside my specific application and thinking about SWIG bindings. In
> glib I find_text() whereas in cpp I search(). In qt4 I can textList() but
> in cpp I can only text().
> 
> IMHO you should define an API that is neutral which you then wrap
> (consistently) in glib, qt, etc. Perhaps this is what cpp will be? 

No, cpp is just another frontend.

> But
> unlike cpp I absolutely want to have access to the PDF API and, from an OO
> perspective:
> Object -> Dictionary -> Page
> (not Page(Object(Dictionary)))

As said, patches to the frontends are welcome.

> When adding functionality you can then add it to the API rather than
> trying to patch xpdf while maintaining upstream compatibility.

Don't understand this sentence at all.

Albert