[poppler] poppler-glib

[Jonathan Blandford]

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

> So, here's my attempt at a glib wrapper.  So far, it doesn't do much
> except load a document and render pages to a GdkPixbuf, but I think it
> shows promise, and I'm pretty sure this is the way we want to go.  We
> should get something similar going for Qt, but for now I'd like to
> flesh out the glib wrapper a bit more.  If somebody wants to work on
> the Qt wrapper in parallel (Jeff, Albert?), that would be great.
> 
> I'm attaching three files: poppler-glib.h and poppler-glib.c implement
> the glib wrapper.  Together they run to around 400 lines and I'm
> hoping that we won't have to write more than 1500 lines of wrapper
> code total. The third file, test-poppler-glib.c is a small example of
> rendering a part of a page into a png file using the glib wrapper.
> 
> If people are happy with this direction, my plan is to commit these
> files to CVS (with required auto* magic) and then gradually add the
> remaining features to allow evince to switch to this interface.  The
> glib wrapper would live in poppler-glib/.  This may sound very glib
> and evince centric, but it's all steps towards getting the kpdf
> patches landed and doing the same for qt and kpdf.

This is really nice, Kristian.  I'm a big fan of this approach.  It lets
us turn pdf-document.cc in evince into a really thin wrapper on top of
PopplerDocument.  It does mean, for at least the glib side, that you're
going to end up essentially reimplementing all the interface in
evince/backend, which implies your 1500 line estimate is a little low.

You are going to have to split it out into multiple header files.

Two other quick thoughts on this:

1) Practically speaking, we're going to have to keep the old headers
   around for a while.  I don't want to try to land the threading
   changes in evince while porting to a new backend at the same time.

2) Once we move to the new headers, we're going to be very careful on
   doing development on them.  As a distributor, I don't want us to find
   ourselves in a situation where we have to pick between versions of
   kpdf or evince.  That is to say, we're going to have to make stable
   releases.

   Here's an example, (with made up version numbers):

   Imagine kpdf-1.0, evince-1.0, and poppler-1.0 are all released.  kpdf
   and evince both start doing development work, and require changes to
   the poppler API.  kpdf finishes first, and wants to release kpdf-1.2.
   At this point, we're stuck either releasing poppler-1.2 with the
   poppler-1.0 glib bindings, releasing a poppler-1.2 with the
   half-finished glib bindings and a compat package for the stable
   poppler or waiting until evince finishes.

   The first seems to be the best approach, but it's going to require
   some exciting branching in CVS.  We can't really make HEAD be the
   development branch, as we can't release from it.  Additionally, we're
   going to be making a lot of releases

Thanks,
-Jonathan