[poppler] poppler-glib

[Kristian Høgsberg]

Jonathan Blandford wrote:
> 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.

Good news; I'm pretty happy with it, and more so after actually writing 
the code.  Making poppler easier to use and hiding the internals at the 
same time is a win-win situation.

 > 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.

I'm not sure what you mean... evince/backend looks to me just like 
boiler plate code for the evince interfaces.  I was just planning on 
exposing the functionality as plain C functions such as (just examples):

	poppler_document_get_links (...)
	poppler_document_start_search (...)

Using these in evince will require implementing the corresponding 
GInterfaces that evince use, but we shouldn't need that in poppler.  I 
probably misunderstood your comment?

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

This is just because it's bad style to have more than one GObject per 
header file, right?

> 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.

Yup, they aren't going away just yet.  The current wrapper is very 
incomplete, and we need to get that done before even considering 
removing the xpdf headers.

> 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.

Yes.  I'm hoping that we can get to a poppler-1.0 in a month or two, 
where we expose enough functionality that kpdf and evince can use it. 
What happens after that I don't know, but of the top of my head there's 
a couple of interesting areas that would require API changes: better 
(real) text selection and PDF forms.  But as long as we're just adding 
new features to poppler, I'm hopeful that it should be possible to 
maintain backwards compatibility.  If we get to a 1.0 release where both 
  kpdf and evince can use it, I don't see the need for a poppler-2.0 
that breaks ABI (famous last words?).

cheers,
Kristian