[poppler] SWIG wrapper for poppler
Albert Astals Cid
aacid at kde.org
Fri Nov 5 12:12:06 PDT 2010
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>
> > 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.
> unlike cpp I absolutely want to have access to the PDF API and, from an OO
> 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.
More information about the poppler