Re: intent to do a poppler transition

[Frank Küster <frank@kuesterei.ch>]

[taking out -release]

Ondrej Sury <ondrej@sury.org> wrote:

>> However, they are aware at least that other projects are interested in
>> using poppler proper, and I think I told them we are already using it.
>> We even talked about the possibility to provide a backend-free version
>> with a clean API.  AFAIR, the only reason for not providing it was that
>> nobody had time to do it.
>
> I don't have an idea how this API should like, but I would be happy to
> join such project.  (Better to help then deal with ABI breakages in
> libpoppler).

Well, me neither.  I have no experience with actually writing C++ code,
let alone designing an API.

But the way I would approach this is:  Look at existing projects that
include a copy of xpdf code, and are non-gui.  Besides pdftex, that's at
least pdftohtml, but I think there was one more in Debian (recalling
faintly from one of the rounds of security patches to xpdf).  Maybe
looking at those that do *not* use xpdf is also interesting (pdftk).

Then check which functions from xpdf are already used.  That should give
a set of needed exported symbols.  It'll be things to read, analyse and
dissect a PDF, and maybe also to write it.

Then we just write a simple wrapper that calls the things with nice
names.  Easy, isn't it?  Just kidding.

>> It's completely inacceptable for pdftex to acquire a dependency on gtk
>> or qt.
>
> It's just glib and not gtk, but I see your point.

Hm, libpoppler0c2-glib Depends: libgtk2.0-0.  Whereas a
"libpoppler-nogui" wouldn't even need the cairo dependence.

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