[poppler] Poppler as a library for parsing and manipulating PDF files?

[Frank Küster]

Albert Astals Cid <aacid at kde.org> wrote:

>> Therefore I'd like to know whether you plan any changes that might
>> affect such uses of poppler, and whether you actually encourage such
>> use.
>
> Well, poppler (xpdf) for it self is not able of manipulting files as of now.
>
> In my opinion having manipulation capabilities inside poppler would be a nice 
> thing, but AFAIK nobody is working on that.

Sorry if I was unclear:  I'm not talking about adding features, but
rather about continuing to support features.  In the end it boils down
to:  If I approach other projects' authors, or Debian maintainers, and
request them to switch from their xpdf code copy to libpoppler, and they
ask me "Why, poppler says on their website they're for rendering, but my
application doesn't render anything?", can I tell them to safely use
libpoppler nevertheless?

I must admit that I do not know anything about the internals of
xpdf/poppler, nor do I know a lot about the internal structure of PDF
files.  But it's a fact that programs that do parse and manipulate PDF
files, and in particular extract parts, already use xpdf code, and for
pdftex it works equally well with libpoppler.  This is our list of
includes:

#include <poppler/poppler-config.h>
#include <poppler/goo/GooString.h>
#include <poppler/goo/gmem.h>
#include <poppler/goo/gfile.h>
#include "poppler/Object.h"
#include "poppler/Stream.h"
#include "poppler/Array.h"
#include "poppler/Dict.h"
#include "poppler/XRef.h"
#include "poppler/Link.h"
#include "poppler/Catalog.h"
#include "poppler/Page.h"
#include "poppler/GfxFont.h"
#include "poppler/PDFDoc.h"
#include "poppler/GlobalParams.h"
#include "poppler/Error.h"

but I don't know offhand which functions are actually used.  This is the
patched version of the source file:

http://people.debian.org/~frank/pdftoepdf.cc

So the question I have is whether any of these (unkown to me) functions
might diverge from xpdf because your focus is on rendering, and become
less useful for us.  I fear that's a bit tough to answer if I don't come
up with function names.  But on the other hand you, who know the code,
might be able to say that the functionality of analysing and dissecting
PDF files is so central to the rendering task that it won't be dropped?

Or if you say "we'll implement existing functions faster or better, and
we'll add functions, but we'll not remove "obsolete" functions (and/or
functionality) just because they are no longer needed *by*us*", then I
guess that would be sufficient for us.

TIA, Frank

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