[poppler] SWIG wrapper for poppler
tdb2 at ecs.soton.ac.uk
Fri Nov 5 04:03:34 PDT 2010
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
>> > > most of the SWIG stuff from Xapian.
>> > I'm not sure if you are aiming for inclusion in mainline poppler or
>> > want to share your patch.
>> > If you aim for inclusion in poppler, i'm sorry but we don't want
>> > 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!). 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.
>> Basically I'm sruck with the same concern here:
> Care to elaborate?
The front-ends provide APIs for rendering PDF, whereas the core classes
also provide a PDF API. Given direct access to the PDF API I can achieve
anything I need to in a down-stream application. If I wanted to add/use an
attribute that isn't in the PDF spec. would poppler add accessors for that?
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? But
unlike cpp I absolutely want to have access to the PDF API and, from an OO
Object -> Dictionary -> Page
When adding functionality you can then add it to the API rather than
trying to patch xpdf while maintaining upstream compatibility.
All the best,
More information about the poppler