Red Hat Bugzilla – Bug 452505
libextractor-plugins-pdf: use default pdf plugin instead of one based on xpdf
Last modified: 2009-10-28 07:14:00 EDT
Description of problem:
libextractor sources contain two pdf reader plugins - one based on embedded copy
of xpdf code (plugins/pdf/pdfextractor.cc) and (as of 0.5.12) own minimal pdf
extractor sufficient to read meta-data out or the pdf (plugins/pdfextractor.c).
pdfextractor.c seems to be a default pdf extractor in current libextractor
versions, unless overridden at compile time by --enable-xpdf as is done in
As xpdf code is frequently patched for security issues that may (or may not)
affect libextractor. Please consider using default pdf extractor unless there
is a well-known reason why xpdf-based version should be used.
As a side effects, using minimal pdfextractor.c may allow you to merge -pdf
subpackage to -base, as it is written in C and hence does not require extra libs
(C++ libs) needed by xpdf-based version (which is probably a reason for separate
Version-Release number of selected component (if applicable):
should be solved since 0.5.22-1
Anyway, configure log related to xpdf support is rather amusing:
configure: NOTICE: xpdf disabled (result: limited PDF support)
configure: NOTICE: xpdf enabled (xpdf has a bad security record)
Enrico, have you considered -pdf sub-package to -base as proposed above? -pdf no longer has any extra dependencies compared to -base, which, I guess, was the main reason for separate -pdf sub-package.
Needinfo on the -pdf sub-package merge.