Your message dated Tue, 12 Apr 2011 19:29:22 -0400
with message-id <20110412192922.5e4f7924.michael.s.gilb...@gmail.com>
and subject line Re: Bug#622343: Return xpdf-utils to Debian
has caused the Debian Bug report #622343,
regarding Return xpdf-utils to Debian
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
622343: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622343
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
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
--- End Message ---
