poppler API, and cairo dependency (was: [poppler] Poppler as a library for parsing and manipulating PDF files?)

[Frank Küster]

Kristian Høgsberg <krh at bitplanet.net> wrote:

> The only
> reservation I have is that we've been trying to wrap up the xpdf API
> that tetex (and cups and others) use in a smaller, simpler API with
> glib and qt bindings.  To motivation for this is that the xpdf API is
> basically an internal API that wasn't designed to be installed as
> public headers. It's a huge API (80+ C++ header files) and it exposes
> too much of the xpdf internals.  Thus, it is not really possible to
> give any kind of API/ABI guarantee for this interface, since
> everything except the smallest changes are going to cause at least ABI
> breakage.
>
> Having said that, if that is acceptable for tetex, I don't see why
> this shouldn't work.  

There's one thing here that I don't understand: Indeed libpoppler
exposes its huge API, and the smaller, organised and, it seems,
well-thought API is only available with the glib and qt bindings.
Obviously, these are useless for us, since we don't need any user
interface.  Why can't the clean API be provided without the bindings,
too? 

> Another issue is that libpoppler.so currently pulls in a number of X
> libraries and the cairo stack if you enable that.  That shouldn't be
> too hard to work around though, we could just move those dependencies
> to the wrapper libraries (libpoppler-glib.so etc).

As I said previously, I'd really appreciate if the cairo dependency
would be moved to the wrapper libraries, or alternatively to at least
provide a stripped-down version without cairo support.


Personally, I'm willing to help, and to learn, but to be honest I don't
expect to be of much help here, except for testing and maybe critical
comments.  Is there anybody in the team who is interested in such an
improvement? 

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)