Bug 252403 - poppler - pdftops ignores configuration file and destroys stdout
poppler - pdftops ignores configuration file and destroys stdout
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: poppler (Show other bugs)
8
All Linux
low Severity high
: ---
: ---
Assigned To: Kristian Høgsberg
Fedora Extras Quality Assurance
bzcl34nup
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-08-15 16:20 EDT by Michal Jaegermann
Modified: 2008-04-04 13:00 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-04 13:00:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2007-08-15 16:20:01 EDT
Description of problem:

'man pdftops', and 'man pdftopmm' as well, are pretty emphatic:

 Pdftops reads a configuration file at startup.  It first tries to  find
 the  user’s  private config file, ~/.xpdfrc.  If that doesn’t exist, it
 looks  for  a  system-wide  config  file,  /etc/xpdf/xpdfrc.   See  the
 xpdfrc(5) man page for details.

AFICS 'man xpdfrc', and reality, locate a system wide config file
in /etc/xpdfrc.  The more serious issue is that regardless if
~/.xpdfrc exitst, or what are locations, those files are completely
ignored.

In particular there is no way to specify a paper size, other than
by an explicit switches on a command line, and 'pdftops' output
(and most likely of 'pdftoppm' too) is always in A4 format even
for locales where a default paper size is "letter".  There are
other possible issues too.

This will silently break all those setups which rely on a long
established 'pdftops' behaviour governed by documented configuration
files.

Thanks to the above poppler-0.5.91-1.fc8 avoids bug 252391 but
replaces that even with something worse.  Namely on every invocation
it prints first on _stdout_:

PARSING /usr/share/poppler/nameToUnicode/Thai
PARSING /usr/share/poppler/nameToUnicode/Bulgarian

This means that trying

  pdftops some_file.pdf - | lpr

will end up with a complete disaster.  Instead of the above do

  pdftops some_file.pdf - | head

and see for yourself why.

Version-Release number of selected component (if applicable):
poppler-0.5.91-1.fc8

How reproducible:
always
Comment 1 Matthias Clasen 2007-08-15 20:21:59 EDT
I've fixed the leftover debug spew.
Comment 2 Bug Zapper 2008-04-04 09:36:25 EDT
Based on the date this bug was created, it appears to have been reported
during the development of Fedora 8. In order to refocus our efforts as
a project we are changing the version of this bug to '8'.

If this bug still exists in rawhide, please change the version back to
rawhide.
(If you're unable to change the bug's version, add a comment to the bug
and someone will change it for you.)

Thanks for your help and we apologize for the interruption.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

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