Bug 452505 – libextractor-plugins-pdf: use default pdf plugin instead of one based on xpdf

Bug 452505 - libextractor-plugins-pdf: use default pdf plugin instead of one based on xpdf [NEEDINFO]

Summary:	libextractor-plugins-pdf: use default pdf plugin instead of one based on xpdf

Status:	CLOSED CURRENTRELEASE

Aliases:	None

Product:	Fedora
Classification:	Fedora
Component:	libextractor (Show other bugs)
Sub Component:
Version:	rawhide
Hardware:	All Linux

Priority	medium Severity high
Target Milestone:	---
Target Release:	---
Assigned To:	Enrico Scholz
QA Contact:	Fedora Extras Quality Assurance
Docs Contact:

URL:
Whiteboard:
Keywords:	FutureFeature

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2008-06-23 09:41 EDT by Tomas Hoger
Modified:	2009-10-28 07:14 EDT (History)
CC List:	1 user (show)

See Also:
Fixed In Version:
Doc Type:	Enhancement
Doc Text:
Story Points:	---
Clone Of:
Environment:
Last Closed:	2009-09-13 07:29:20 EDT
Type:	---
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Flags:	thoger: needinfo? (rh-bugzilla)

Attachments	(Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

Groups: None (edit)

Description Tomas Hoger 2008-06-23 09:41:47 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
Fedora packages.

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
subpackage).

Version-Release number of selected component (if applicable):
libextractor-0.5.20b-1

Comment 1 Enrico Scholz 2009-09-13 07:29:20 EDT

should be solved since 0.5.22-1

Comment 2 Tomas Hoger 2009-09-17 04:21:36 EDT

Thank you.

Anyway, configure log related to xpdf support is rather amusing:

with --disable-xpdf:
  configure: NOTICE: xpdf disabled (result: limited PDF support)

with --enable-xpdf:
  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.

Comment 3 Tomas Hoger 2009-10-28 07:14:00 EDT

Needinfo on the -pdf sub-package merge.

Note You need to log in before you can comment on or make changes to this bug.