[poppler] SWIG wrapper for poppler

[Tim Brody]

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!). 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:
>> 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. 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  
perspective:
Object -> Dictionary -> Page
(not Page(Object(Dictionary)))

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

-- 
All the best,
Tim.