Debian Bug report logs - #622343
Return xpdf-utils to Debian

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Yitzchak Gale <gale@sefer.org>

To: submit@bugs.debian.org

Subject: Return xpdf-utils to Debian

Date: Tue, 12 Apr 2011 14:11:13 +0300

Package: xpdf-utils
Version: 3.02-12
Severity: grave

xpdf as a rendering library was removed from Debian, with
the justification that a fork of this library, poppler, could be
used instead.

However, the command-line utilities in poppler-utils are significantly
different than those of xpdf and are in no way a drop-in replacement.

For example, in pdftotext: xpdf does better with ligatures,
and with ordering of text in tables; the two behave differently w.r.t.
PDF crop boxes. In general, the output of the tools from the two
packages are completely different, so programs that parse their output
cannot easily be ported from one to the other. Xpdf-utils are also
much easier to use for cross-platform applications due to the availability of
pre-compiled binaries for other platforms.

The change to poppler for rendering seems to have inadvertently
caused xpdf-utils to disappear completely from Debian.
Xpdf is one of the classic examples of a quality well-supported
free software project. It is a grave oversight for it to be removed
completely from Debian.

Unfortunately, the poppler fork chose the exact same names for
its incompatible command-line executables as the names used
by xpdf. That does require some care to avoid conflicts.
In MacPorts, that issue was solved simply by renaming the
executables in xpdf-utils: pdftops => xpdf-pdftops, etc.
See: http://trac.macports.org/ticket/17540

Thanks,
Yitz

Message #10 received at 622343-close@bugs.debian.org (full text, mbox, reply):

From: Michael Gilbert <michael.s.gilbert@gmail.com>

To: 622343-close@bugs.debian.org

Subject: Re: Bug#622343: Return xpdf-utils to Debian

Date: Tue, 12 Apr 2011 19:29:22 -0400

Yitzchak Gale wrote:

> Package: xpdf-utils
> Version: 3.02-12
> Severity: grave
> 
> xpdf as a rendering library was removed from Debian, with
> the justification that a fork of this library, poppler, could be
> used instead.
> 
> However, the command-line utilities in poppler-utils are significantly
> different than those of xpdf and are in no way a drop-in replacement.

The tools come from the same codebase, and while poppler has evolved
more than xpdf in the past few years, I fail to see how the differences
mentioned below can be considered "significant".  That's simply
over-dramatizing the problem.

> For example, in pdftotext: xpdf does better with ligatures,
> and with ordering of text in tables; the two behave differently w.r.t.
> PDF crop boxes. In general, the output of the tools from the two
> packages are completely different, so programs that parse their output
> cannot easily be ported from one to the other. Xpdf-utils are also
> much easier to use for cross-platform applications due to the availability of
> pre-compiled binaries for other platforms.

These minor regression bugs should be submitted against poppler
(preferably upstream poppler) where they can actually get fixed.

> The change to poppler for rendering seems to have inadvertently
> caused xpdf-utils to disappear completely from Debian.
> Xpdf is one of the classic examples of a quality well-supported
> free software project. It is a grave oversight for it to be removed
> completely from Debian.

It was not inadvertently dropped; it was intentional.  I see no need to
provided duplicate functionality, and I very much disagree with your
"grave oversight" categorization.

> Unfortunately, the poppler fork chose the exact same names for
> its incompatible command-line executables as the names used
> by xpdf. That does require some care to avoid conflicts.
> In MacPorts, that issue was solved simply by renaming the
> executables in xpdf-utils: pdftops => xpdf-pdftops, etc.
> See: http://trac.macports.org/ticket/17540

I'm not interested in the mac ecosystem or how they do things.

It's simply not worth it to maintain a highly vulnerable code copy just
because there are a couple minor bugs/differences in the poppler
versions, so I am not interested in reverting the current behavior.
Besides this is the first complaint I've gotten about this transition,
even though it has been in debian for almost a year now.

If you simply must have xpdf-utils and nothing else, it is certainly
straightforward to compile it directly from the upstream source.  Or
preferably, get the poppler implementation fixed.

Best wishes,
Mike

Send a report that this bug log contains spam.