[poppler] Getting metadata?

[Kristian Høgsberg]

Brad Hards wrote:
> On Sat, 5 Mar 2005 09:13 pm, Albert Astals Cid wrote:
> 
>>Hi Brad, have a look at
>>PDFGenerator::generateDocumentInfo
>>PDFGenerator::getDocumentInfo
>>and
>>PDFGenerator::getDocumentDate
>>in kdegraphics/kpdf/core/generator_pdf/generator_pdf.cpp
> 
> Thanks. I have an inferior version of getDocumentInfo in my code (also adapted 
> from pdfinfo), so taking yours :-)
> 
> 
>>BUT i think this can be a quite common thing, so we could integrate it into
>>PDFDoc in poppler?
> 
> Having just grappled with the source code to pdfinfo, I'm totally hating the 
> GooString and Unicode stuff. I think that we need to add a standard compat 
> layer over the top. I'm not sure of the best way to do this - could be a Qt 
> specific layer inside of KDE, a Qt specific layer inside of Poppler, or a 
> wstring type layer inside of Poppler.

I'm not entirely opposed to this, but we need to do it the right way. 
As it is now, the poppler API is surely painful to work with, but it is 
nicely platform/desktop agnostic.  If we start linking to Qt, GTK+ or 
Xaw, we break that, which was very much not the idea of this fork.

Another problem is the poppler API.  I've been talking to Jeff about 
changing some of the internals to better utilize cairo.  The problem is, 
though, that currently there are no internals!  Every header file is 
installed and every implementation detail is part of the public API.

My thinking so far has been that each application just have to deal with 
the awkward API, typically by wrapping it one or more native objects. 
There is another way to do it though, which is much like how the DBus 
code is structured.  The DBus core is written in plain C with no 
dependencies.  It's pretty painful to work with if you're used to Qt or 
GTK+, but the point is that DBus provides Qt and GTK+ wrapper libraries 
so you don't deal with the core directly.  The Qt wrapper gives you a 
bunch of QObject subclasses to work with, the GTK+ wrapper gives you 
GObjects.

We could do the same and provide libpoppler-qt.so and 
libpoppler-glib.so.  So far I wasn't sure it was worth the effort but 
thinking about it, it does give us quite a few benefits:

  - We can export an easy to use API with well-known types without 
having to search and replace GooString with QString or GString.  We stay 
close to the xpdf source, while providing a nice API.

  - We avoid the exposing the internal design of poppler and instead 
provide an simple API designed to cover the current use cases.  This 
makes poppler easier to use and allows us the change the internal 
without breaking applications.

  - We don't have to merge the string constification patch.  Don't get 
me wrong, I'm all for constification, but it does create a lot of diff 
noise, and with poppler-qt we can cover it up it the Qt wrapper.

The API we export should be really simple.  Here's a rough outline of 
the functionality I think we need to support:

   - document object: load, ask about number of pages, get page object
   - page object: render to bitmap, X window or PS (or cairo context),
   - get meta data
   - get bookmarks
   - text selection

Comments?
Kristian