Hey All,
As we know, I like my distro to be bleeding... With libpoppler 0.16.0 we're again broken with compilation. I really think that we need to work on a proper solution for this because it seems like every 6 months we have to add additional checks to compensate for how things change. Also, I noticed that libwpg 0.2 isn't detected either, I tried mucking w/ configure.ac and had no success.
Cheers, Josh
2011/1/16 Josh Andler <scislac@...400...>:
As we know, I like my distro to be bleeding... With libpoppler 0.16.0 we're again broken with compilation. I really think that we need to work on a proper solution for this because it seems like every 6 months we have to add additional checks to compensate for how things change. Also, I noticed that libwpg 0.2 isn't detected either, I tried mucking w/ configure.ac and had no success.
At the moment the only supported solution is to use the poppler-glib frontend and write to a Cairo SVG surface, then postprocess the resulting SVG file. It works well most of the time, but I'm not sure how font embedding and ICC is handled.
Regards, Krzysztof
On Jan 16, 2011, at 12:19 PM, Krzysztof Kosiński wrote:
2011/1/16 Josh Andler <scislac@...400...>:
As we know, I like my distro to be bleeding... With libpoppler 0.16.0 we're again broken with compilation. I really think that we need to work on a proper solution for this because it seems like every 6 months we have to add additional checks to compensate for how things change. Also, I noticed that libwpg 0.2 isn't detected either, I tried mucking w/ configure.ac and had no success.
At the moment the only supported solution is to use the poppler-glib frontend and write to a Cairo SVG surface, then postprocess the resulting SVG file. It works well most of the time, but I'm not sure how font embedding and ICC is handled.
The *proper* solution is to get the Poppler team feedback on the direct API that is needed. They've asked for that input and are willing to provide what Inkscape needs once it is clarified. They've mentioned that a backend surface hack is not really the way to go.
On 16/1/11 03:54, Josh Andler wrote:
As we know, I like my distro to be bleeding... With libpoppler 0.16.0 we're again broken with compilation. I really think that we need to work on a proper solution for this because it seems like every 6 months we have to add additional checks to compensate for how things change. Also, I noticed that libwpg 0.2 isn't detected either, I tried mucking w/ configure.ac and had no success.
JFTR - tested on OS X 10.5.8 (all dependencies installed via MacPorts):
Inkscape 0.48.1 and current trunk configure and build without failure using poppler 0.16.2 (just upgraded from 0.14.5)
The patch to build with poppler >= 0.15.1 provided for
Bug #676271 [PATCH] Does not build with recent poppler https://bugs.launchpad.net/inkscape/+bug/676271
had been committed to trunk (r9910) and the 0.48.x branch (r9727).
Autotools installed: Autoconf 2.68 Automake 1.11.1 Libtool 2.4
~suv
On Tue, Feb 1, 2011 at 4:53 PM, ~suv <suv-sf@...58...> wrote:
JFTR - tested on OS X 10.5.8 (all dependencies installed via MacPorts):
Inkscape 0.48.1 and current trunk configure and build without failure using poppler 0.16.2 (just upgraded from 0.14.5)
I had modified my source in a hacky way after that to build, it appears that a few days later a newer libpoppler package was uploaded that it builds fine against. Thanks for getting me to revert my local hack-change. :)
Either way, this doesn't negate the issue of us not using poppler properly. Hopefully in the next few weeks I'll have more of a chance to check out Adibs re-enabling of poppler-glib as I don't recall seeing any bugs filed about it.
Cheers, Josh
participants (4)
-
Jon Cruz -
Josh Andler -
Krzysztof Kosiński -
~suv