direct usage of poppler (core)

Bug #239544 reported by Pino Toscano on 2008-06-12
This bug affects 7 people
Affects Status Importance Assigned to Milestone

Bug Description

Right now Inkscape uses and depends directly on the core library of Poppler.
This is an huge problem, given that Poppler core does not install headers by default, and does not maintain SC and BC, even between patch releases. Basically, the core library is "private". What should be used of Poppler is any of its frontends, being poppler-qt (Qt3), poppler-qt4 (Qt4) and poppler-glib (GLib), that can provide a more toolkit-like API and SC/BC at least for patch releases.

So, please port Inkscape to poppler-glib instead of poppler, otherwise it can break even after updating patch releases of Poppler.
(Of course, the Poppler developers are available for help.)

Pino Toscano (pinotree) wrote :

Example of the problem: bug #237574 (function in core changed between 0.8.2 and 0.8.3).

Changed in inkscape:
importance: Undecided → High
status: New → Confirmed

If I remember correctly, the original problem was that the "public" poppler API only let you render the PDF to a cairo context, discarding the PDF document structure. Has that changed since?

(If that is still a problem, we will need an additional public API from the poppler folks in order to address this.)

Luca Bruno (lucab) wrote :

This is also causing problem for some builders (see bug: #254849) as not all distro are providing these headers and we cannot properly check them at configure time.

jazzynico (jazzynico) on 2011-01-17
tags: added: build
jazzynico (jazzynico) wrote :

Just ran into the issue when trying to compile on Debian Wheezy, libpoppler-dev 0.18.4-3. Debian provides the headers in the libpoppler-private-dev package, but I'm unable to compile Inkscape due to changes in GfxColorSpace functions. Console messages:
/usr/include/poppler/GfxState.h: In member function ‘virtual void GfxColorSpace::getGrayLine(Guchar*, Guchar*, int)’:
/usr/include/poppler/GfxState.h:205:142: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings]
/usr/include/poppler/GfxState.h:199:25: note: static GfxColorSpace* GfxColorSpace::parse(Object*, Gfx*)
/usr/include/poppler/GfxState.h:199:25: note: candidate expects 2 arguments, 1 provided
and so on...
Could rapidly become a blocker.

Changed in inkscape:
status: Confirmed → Triaged
jazzynico (jazzynico) wrote :

Ok, just found my bug is fixed, but for Poppler=>0.20.0.
See Bug #1005565 (poppler 0.20 breaks build).

Luca Bruno (lucab) wrote :

That should be covered by previous POPPLER_NEW_COLOR_SPACE_API check, not by my latest 0.20 related commit.
Can you please show the non-cut error log, as well as check in config.log if the POPPLER_NEW_COLOR_SPACE_API test is failing and why?
Which branch are you building?

jazzynico (jazzynico) wrote :

Fixed. Inkscape just needed a clean build after installing libpoppler-private-dev.
Sorry for the noise.

Alex Valavanis (valavanisalex) wrote :

This has reared its head again in bug #1315142 <Build failure with poppler-0.26>.

Can anyone give an indication of how difficult it would be to port to the public Poppler API? Would it be unreasonable to aim for the 0.91 release... this is really a very persistent cause of build failures.

su_v (suv-lp) wrote :

Latest breakage: Bug #1399811 “inkscape 0.91.x build fails using poppler 0.29.0”

Patrick Storz (ede123) wrote :

Ubuntu 15.04, same problem.

Thomas Klausner (tk-giga) wrote :

Poppler-0.58 broke inkscape again.

Upstream is willing to talk if the API they provide is not sufficient:

Patrick Storz (ede123) wrote :

There's no doubt using stable API would be preferable.

Main issue is to find somebody who knows poppler (and Inkscape's implementation of it) well enough to work on this.

Changed in inkscape:
importance: High → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers