Inkscape requires poppler internal private headers

Bug #254849 reported by John on 2008-08-05
This bug report is a duplicate of:  Bug #239544: direct usage of poppler (core). Edit Remove
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Inkscape
Medium
Unassigned

Bug Description

On compilation of 0.46 (stable) I get (as first errors):

In file included from extension/internal/pdfinput/svg-builder.cpp:19:
extension/internal/pdfinput/svg-builder.h:32:23: error: CharTypes.h: No such file or directory
In file included from extension/internal/pdfinput/svg-builder.cpp:20:
extension/internal/pdfinput/pdf-parser.h:29:24: error: goo/gtypes.h: No such file or directory
extension/internal/pdfinput/pdf-parser.h:30:20: error: Object.h: No such file or directory
extension/internal/pdfinput/svg-builder.cpp:41:22: error: Function.h: No such file or directory
extension/internal/pdfinput/svg-builder.cpp:42:22: error: GfxState.h: No such file or directory
extension/internal/pdfinput/svg-builder.cpp:43:21: error: GfxFont.h: No such file or directory
extension/internal/pdfinput/svg-builder.cpp:44:20: error: Stream.h: No such file or directory

Things go from bad to worse, so I'd like to resolve this first.

The problem is an #include "CharTypes.h", which I don't have on my machine. Because of the ""'s I suspect this should be part of Inkscape?

I compiled 0.45 some time ago without problems. I also downloaded svn, which had the same problem as above (after installing libgsl).
Attached is the complete error log.

John (john-jcoppens) wrote :
John (john-jcoppens) wrote :

Just info: Distro is mostly Slackware 12.0, several libraries were locally compiled and installed.
Kernel is 2.6.23...

Jim Clarke (jim-clarke-sun) wrote :

Same error on OpenSolaris
Solaris Express Community Edition snv_95 X86

John (john-jcoppens) wrote :

Searching the 'net, I found that CharTypes.h is related to the poppler library. I had recently
compiled poppler, so I was somewhat surprised the compilation didn't work.

So I downloaded the latest poppler lib, recompiled, installed, and again, no luck.

I _did_ find CharTypes.h in the poppler source directory, but install doesn't install it in the /usr/local/include directory (or elsewhere, as far as I can see).

Is this some header file -dev packages install for some reason, but poppler itself doesn't?

John (john-jcoppens) wrote :

According to the ./configure --help, --enable-poppler-cairo must be specified to enable
that feature. Why is it enabled by default then?

And --disable-poppler-cairo doesn't work either. Even after a 'clean', CharTypes.h is still
needed, even though the configure output says poppler is disabled.

Ok... I've found the problem it seems. Compiling poppler normally doesn't install the xpdf headers,
a policy decision of the poppler team (I can understand the reasons). But causes problems
for inkscape which can't access them.

To solve the problem: add --enable-xpdf-headers to the configure command when compiling
poppler, recompile and install.

Note that another problem pops up - an incompatibility. This reference:
http://www.nabble.com/Poppler-0.8.3-change-to-GfxFont-td17806656.html
indicates the solution. Note that I used ./configure CFLAGS="-DPOPPLER_NEW_GFXFONT",
not CPPFLAGS as is advised later in the thread - I hadn't read that far. But it does work!)

So, in short:
Recompile poppler:
./configure --enable-xpdf-headers (and other options - I needed --enable-zlib)
make
make install

Compile inkscape with
./configure CFLAGS="-DPOPPLER_NEW_GFXFONT" (and other options)
make
make install

And a fair amount of patience.
John

John (john-jcoppens) wrote :

Just to be sure, the incompatibility problem appears only for poppler 0.8.3 and higher.

ishmal (ishmalius) wrote :

John, yes, Inkscape uses internal Poppler calls, and is not using a public API. For win32 at least, we manually copy the poppler.h files to /include. The Poppler guys know about this, and maybe we can work out some kind of public api with callbacks to get the private information in a safe way in the future.

Luca Bruno (lucab) on 2008-08-30
Changed in inkscape:
importance: Undecided → Wishlist
status: New → Confirmed
Michal Svoboda (pht) wrote :

I recently stumbled across the very same problem and it took a fair amount of digging to get to (this) solution. I took the liberty of documenting this problem at the CompilingInkscape wiki page.

jazzynico (jazzynico) wrote :

It seems that some distros provide the missing headers in an extra package. In Debian, everything is in libpoppler-private-dev. But be aware that internal changes in the poppler libs could still prevent inkscape from compiling correctly (see Bug #239544 direct usage of poppler (core)).

Alex Valavanis (valavanisalex) wrote :

I agree that this seems like a bad situation... does anyone have an idea about whether a switch to public Poppler API would be painful to implement? I'd be willing to look into it, but first...

* Are we doing anything that *needs* non-public poppler API or are we just using it for legacy reasons?

* Is the public API actually more stable than the private stuff or will we still be stuck with assorted build failures and conditional builds whenever there is a new Poppler release?

Changed in inkscape:
status: Confirmed → Triaged
Alex Valavanis (valavanisalex) wrote :

Bumping importance because this seems to be a perennial reason for build failures in distros!

Changed in inkscape:
importance: Wishlist → Medium
Alex Valavanis (valavanisalex) wrote :

Marking this as a duplicate of bug #239544. The real issue is that we should be using the public API provided by Poppler rather than tapping into its internal headers.

A while ago I added "Adobe pdf via poppler cairo" that uses poppler API only.
The drawback is that some information might get lost and some options
are not available because the direct pdf poppler import build the SVG
directly.

Regards, Adib.

On Sat, Mar 2, 2013 at 1:01 PM, Alex Valavanis
<email address hidden> wrote:
> *** This bug is a duplicate of bug 239544 ***
> https://bugs.launchpad.net/bugs/239544
>
> Marking this as a duplicate of bug #239544. The real issue is that we
> should be using the public API provided by Poppler rather than tapping
> into its internal headers.
>
> ** This bug has been marked a duplicate of bug 239544
> direct usage of poppler (core)
>
> --
> You received this bug notification because you are a member of Inkscape
> Bug Team, which is subscribed to Inkscape.
> https://bugs.launchpad.net/bugs/254849
>
> Title:
> Inkscape requires poppler internal private headers
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/inkscape/+bug/254849/+subscriptions

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments