Miklós Erdélyi wrote:
On 10/25/07, Joshua Facemyer / Impressus Art <faceman@...1574...> wrote:
Jon A. Cruz wrote:
It might mean that it is an internal part of poppler, and not a public include file.
OK, so a guy on poppler's irc told me "bad inkscape svn for using a private header".
He said it should use the glib frontend for that functionality.
The poppler PDF importer was coded to introduce the least possible number of new package dependencies into Inkscape, so that's why we're using CairoOutputDev instead of calling the glib wrapper functions to generate a page preview using CairoOutputDev... But if we took poppler-glib on our dependency list, modifying the pdf import dialog code to use poppler-glib for preview would be straightforward.
Regards, miklos
But then we'll have the perpetual problem of people not having the proper header file, which is unsupported by poppler as a public file.
Considering the importance of PDF functionality (looking over the list archives, back in the summer, bulia said something to the effect that Inkscape was now able to compete with professional apps because of the new pdf stuff) I think the dependency on poppler-glib is not a significant disadvantage, especially if the option to not compile with poppler support exists. (Wasn't there talk recently of having a compile-time switch determine whether to include poppler or internal pdf support? Not a perfect solution, but might help if people are determined to keep deps down.)
Also, I'd guess that many gtk apps which use/will use poppler will depend on poppler-glib functions anyway - but I really don't know, so can't say for certain.
The problem here is not just that the missing header prevents functionality. The problem is that it breaks compilation. If poppler is installed correctly (according to poppler devs), and you compile Inkscape with poppler support, it fails.
I understand the need to keep dependencies to a minimum; however, such powerful functionality may merit a new set of dependencies. Maybe it's time to reconsider?
JF