xpdf.real crashed with SIGSEGV in GooHash::hash()

Bug #943195 reported by Łukasz Daniel on 2012-02-29
This bug affects 120 people
Affects Status Importance Assigned to Milestone
xpdf (Debian)
Fix Released
xpdf (Ubuntu)

Bug Description


All Xpdf users are affected. Xpdf fails to open any file and crashes.

Test case

* Run "xpdf" and ensure that it starts.
* Run "xpdf somefile.pdf" and ensure that it starts.
* Ensure that keybindings (i.e. "o", "?") work.

Development fix

This was fixed in Saucy by making Xpdf use Poppler's GlobalParams module and splitting all Xpdf-specific params to XPDFParams module in debian/code/XPDFParams.{cc,h}.

Stable fix

An adapted version of the fix is applied in package in raring-proposed.

Regression potential

While there may be regressions in configuration handling compared to upstream Xpdf, having Xpdf that works is many times better than having Xpdf that crashes on any file.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

ProblemType: Crash
DistroRelease: Ubuntu 12.04
Package: xpdf 3.02-21build1
ProcVersionSignature: Ubuntu 3.2.0-17.27-generic 3.2.6
Uname: Linux 3.2.0-17-generic x86_64
ApportVersion: 1.93-0ubuntu2
Architecture: amd64
Date: Wed Feb 29 12:42:12 2012
ExecutablePath: /usr/bin/xpdf.real
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012)
ProcCmdline: xpdf.real -title Xpdf:\ cv_pl_LD.pdf cv_pl_LD.pdf
 Segfault happened at: 0x7f953cedd420 <_ZN7GooHash4hashEP9GooString>: mov 0x20(%rsi),%r8
 PC (0x7f953cedd420) ok
 source "0x20(%rsi)" (0x01010021) not located in a known VMA region (needed readable region)!
 destination "%r8" ok
SegvReason: reading unknown VMA
Signal: 11
SourcePackage: xpdf
 GooHash::hash(GooString*) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.19
 GooHash::find(GooString*, int*) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.19
 GooHash::lookup(GooString*) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.19
 GlobalParams::getResidentUnicodeMap(GooString*) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.19
 GlobalParams::getUnicodeMap2(GooString*) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.19
UpgradeStatus: Upgraded to precise on 2012-02-19 (9 days ago)
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare

WORKAROUND: use Evince (Gnome/Unity) or Okular (Kubuntu)

Łukasz Daniel (lukasz-daniel) wrote :

 GooHash::hash(GooString*) () from /tmp/tmpuiID15/usr/lib/x86_64-linux-gnu/libpoppler.so.19
 GooHash::find(GooString*, int*) () from /tmp/tmpuiID15/usr/lib/x86_64-linux-gnu/libpoppler.so.19
 GooHash::lookup(GooString*) () from /tmp/tmpuiID15/usr/lib/x86_64-linux-gnu/libpoppler.so.19
 GlobalParams::getResidentUnicodeMap(GooString*) () from /tmp/tmpuiID15/usr/lib/x86_64-linux-gnu/libpoppler.so.19
 GlobalParams::getUnicodeMap2(GooString*) () from /tmp/tmpuiID15/usr/lib/x86_64-linux-gnu/libpoppler.so.19

Changed in xpdf (Ubuntu):
importance: Undecided → Medium
tags: removed: need-amd64-retrace
C de-Avillez (hggdh2) on 2012-04-09
visibility: private → public
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in xpdf (Ubuntu):
status: New → Confirmed
David Kastrup (dak) wrote :

Do we really have to have this bug every two releases again? IIRC, last time round was due to some poppler library upgrade, and was not fixed for the entire life time of the release. I recommend looking in the xpdf bug history to check how this got fixed last time. It is likely that the fix might be related.

David Kastrup (dak) wrote :

How is a crash at startup priority "Medium"? It does not get any worse than that, does it?

David Kastrup (dak) wrote :

The last time the bug stayed around for a year without being catered for it was called bug #669211. It is rather obviously the same bug with the same symptoms.

Marius B. Kotsbak (mariusko) wrote :

David: it is not a core application (probably in Universe). You can use Evince (Gnome/Unity) or Okular (Kubuntu).

David Kastrup (dak) wrote :

Evince does not interact with LilyPond's point-and-click functionality. It also does not work with AUCTeX's source special support. The same for Okular.

The previous package of xpdf works. It is not clear to me what the point in replacing it with a version that crashes when viewing any file is supposed to be.

@David: No one claimed that xpdf is useless -- it is just "only" community supported, i.e. in universe and not in main. The status has been set to "Medium" automatically by apport, as it does for all crash reports. The correct status would actually be "High" ("Prevents the application or any dependencies from functioning correctly at all ") but only someone with BugControl privileges can change the importance. However, I doubt this will make this problem go away any sooner... Note that xpdf has *not* been replaced with a new version, the poppler library has changed and simply rebuilding xpdf was not enough, obviously. It is worth looking at the Debian package for xpdf in debian experimental (maintained by Michael Gilbert who commented on some of the crash reports here in launchpad) that *seems* to be working with the same poppler version that Ubuntu is using.

Shouri Chatterjee (shouri) wrote :

It is not the same bug. Last time xpdf was crashing even before any window came up. This time xpdf is launching the window, rendering the first page of the pdf file (you can see it for a jiffy), and then crashing out.

Shouri Chatterjee (shouri) wrote :

So now that we have waited for over a month without the bug even being assigned - does this mean that xpdf will not be fixed through the lifetime of precise?

dreckkopf (dreckkopf) wrote :

I cannot believe comment #9. When I try to view this document http://www.hems.de/Allgemeinbildung/FormelsammlungPhysikMechanik.pdf , evince only shows garbage on the screen. This bug got never fixed. That's why I prefer xpdf.

Marius B. Kotsbak (mariusko) wrote :

It is displayed correctly in my evince 3.4.0. Which version do you use? Are you sure you have the required fonts installed (is package "ttf-mscorefonts-installer" installed?) ?

davidg (davidg2603) wrote :

On my Ubuntu 12.04 install, downgrading libpoppler19 from "0.18.4-1ubuntu2" to "0.18.4-1" (the latter available from Debian experimental) resolved this crash for me.

arnuschky (abrutschy) wrote :

I can confirm that downgrading to 0.18.4-1 from debian experimental works.Ubuntu versions 0.18.4-1ubuntu2 and 0.18.4-1ubuntu1 both caused xpdf to crash. I'm on 12.04 64bit.

For the lazy:

gamx (gllobet) wrote :

The debian package also seems to work for me. I had to install libopenjpeg2 manually, though.
BTW, xpdf is essential, for example, if you want to use whizzytex (http://cristal.inria.fr/whizzytex/), since AFAIK it does not support evince.

Strange: Using the original .deb from Debian prevents the crash, but taking the Debian sources, building a package from them in Ubuntu 12.04 and installing the package, does not.

Lorenzo Bettini (bettini) wrote :

and I confirm that installing from debian experimental libpoppler19_0.18.4-1_i386 works also for 32 bit

halfdog (halfdog) wrote :

I guess, I have an explanation for the bug and why it is emerging again now and then.

The memory location 0x80(%rdi) is written only once, that revealed that the libpoppler GlobalParams class constructor did not write it. In fact, the constructor is never called. Instead of that, the xpdf program brings an own and divergent version of the GlobalParams class, handling that over to libpoppler. Comparing the different definitions (xpdf/GlobalParams.h and poppler/GlobalParams.h) reveals, that xpdf class definition will copy boolean configuration values to that location, used by libpoppler to store textEncoding.

See http://www.halfdog.net/Security/2012/XpdfCrashAnalysisUbuntuPrecise/ for full analysis.

Sorry for the dump question: How do I downgrade libpoppler19? Downloading the deb file file gets me into "Error: A later version is already installed" from software center or gdebi. What would be the command line equivalent to install it?

Just run
sudo dpkg -i libpoppler19_0.18.4-1_amd64.deb
(or whatever .deb file you downloaded).

The debian-package downgrade worked for me, too.

Thanks! I have xpdf working again :-)

Nick Dokos (nicholas-dokos) wrote :

The downgrade worked in that xpdf does not crash any longer (I did have to install libopenjpeg2 as #18 points out). However, xpdf -z 50 foo.pdf does not seem to work: I get an initial zoom of 125%, no matter what I specify for the zoom value. Can somebody try to replicate this problem?

oddhack (developer-oddhack) wrote :

Another confirmation that the Debian 0.18.4-1 package (i386) fixes this problem for me.

Also, ISTM that bugs 992486 and 995829 are probably duplicates of this bug, although the reported symptoms differ slightly. Don't know who gets to make that call, though. There are a ton of other 'xpdf crashes on startup' bugs open too, although some are for previous versions.

D J Gardner (djgardner) wrote :

Debian bug 658264 has a discussion on this, and a propsed patch. I don't know if its been applied to the debian tree yet, but it seems to work.

Here is a link to the patch: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=49;mbox=yes;bug=658264
(wget it and apply!)

Changed in xpdf (Debian):
status: Unknown → Confirmed
Eric Anderson (kluwak) wrote :

Here's another pdf file that reliably produces this crash for me on x86 Precise: http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_2/iil.pdf (md5sum 4ee8af8ada7b8ca1303211a08b66bdef).

roots (roots) wrote :

Confirming the bug with Ubuntu Precise amd64.

After trying various fixes posted on the web and totally wrecking my package system (mixing in i386 packages by mistake), for me finally worked in Ubuntu Precise _64bit_ version:

$ apt-get purge libpoppler19*

$ wget http://us.archive.ubuntu.com/ubuntu/pool/main/p/poppler/libpoppler13_0.16.7-2ubuntu2_amd64.deb
$ wget http://us.archive.ubuntu.com/ubuntu/pool/universe/x/xpdf/xpdf_3.02-21_amd64.deb

$ sudo dpkg -i libpoppler13_0.16.7-2ubuntu2_amd64.deb
$ sudo dpkg -i xpdf_3.02-21_amd64.deb

Now there's a little catch to this because with daily ubuntu updates, the package manager will try to re-build xpdf against libpoppler19, which breaks xpdf again. To prevent this, put the xpdf package on hold via

$ echo "xpdf hold" | sudo dpkg --set-selections

This can be undone with

$ echo "xpdf install" | sudo dpkg --set-selections

To check the status:

$ dpkg --get-selections | grep xpdf

Done! ;-)

Good luck all!

Following comment #27 I rebuilt the precise source package using the patch from http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=49;mbox=yes;bug=658264 and the crashes stopped for me.

I hope a fix can make it into 12.04.1 -- it would be frustrating if the LTS Ubuntu boxes that will be around for years all have a completely broken xpdf.

I wish a clarification about comment #29
In my distro
 3.2.0-26-generic #41-Ubuntu SMP Thu Jun 14 17:49:24 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

$ apt-get purge libpoppler19*

The following packages will be REMOVED:
  bluez-cups* cups* cups-filters* dvipng* evince* gimp* hplip*
  indicator-printers* kile* latex-beamer* latex-xcolor* libevince3-3*
  libpoppler-glib8* libpoppler19* luatex* pgf* poppler-utils*
  printer-driver-gutenprint* printer-driver-hpcups* prosper* texlive*
  texlive-base* texlive-binaries* texlive-extra-utils* texlive-font-utils*
  texlive-fonts-recommended* texlive-generic-recommended* texlive-latex-base*
  texlive-latex-extra* texlive-latex-recommended* texlive-luatex*
  texlive-pictures* texlive-pstricks* tipa* xpdf*

is this rebuilt upon continuing with the reinstall?
$ wget http://us.archive.ubuntu.com/ubuntu/pool/universe/x/xpdf/xpdf_3.02-21_amd64.deb

$ sudo dpkg -i libpoppler13_0.16.7-2ubuntu2_amd64.deb
$ sudo dpkg -i xpdf_3.02-21_amd64.deb

roots (roots) wrote :

@ Comment 31:

Erm yes, isn't it a little weird that the application the fixed xpdf is intended for (tex) needs to be deinstalled to allow fixing?! ;-)

I have to admit this is a little drawback of the described method. The packages got deinstalled and needed to be reinstalled separately. However, I preferred reintalling cups and tex over not being able to use xpdf at all... ;-)


Ron Bakker (r0n) wrote :

The same problem in Xubuntu 12.10 alpha-1.

same problem with Ubuntu 12.10 64-bit Kernel Linux 3.5.0-4-generic

TBeholder (turbobeholder) wrote :

alas, on an attempt to reinstall they still "require" libpoppler19

> The following extra packages will be installed:
> libpoppler19

Ian Hutchinson (hutch) wrote :

I have attempted most of the proposed "solutions" for this problem. Patching 3.02, using nopopler binary, using the oneiric
package, etc, etc.

None (no not one) of them give a stable xpdf on my
Ubuntu Precise 64-bit system: 3.2.0-30-generic #48-Ubuntu SMP Fri Aug 24 16:52:48 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Even though some of the proposed fixes prevent the crashes on startup. They none of them avoid a crash when repeatedly switching from full-screen/presentation to windowed by repeatedly hitting Alt-f.

I have instead compiled xpdf 3.03 (not 3.02) from source as follows:
Remove all xpdf packages.
sudo apt-get install lesstif2-dev

wget ftp://ftp.foolabs.com/pub/xpdf/xpdf-3.03.tar.gz
tar xzf xpdf-3.03.tar.gz
cd xpdf-3.03
wget http://silas.psfc.mit.edu/xpdf3.03Viewer.patch
patch < xpdf3.03Viewer.patch
./configure --with-freetype2-library=/usr/lib/x86_64-linux-gnu/ --with-freetype2-includes=/usr/include/freetype2
sudo make install

This gives a robust xpdf. The patch is a trivial cast correction. I found it necessary to correct a compile failure.

Good luck to you all. Ian Hutchinson

Marius B. Kotsbak (mariusko) wrote :

I do not reproduce this problem in Quantal versions of xpdf and poppler.

Ashok Popat (ashok-popat) wrote :

Compiling from xpdf-3.03 source as Ian suggests (comment #36) works for me also. Thanks! :-)

I had to cd into the xpdf subdirectory of xpdf-3.03 when applying the patch.

For my 32-bit machine I changed the ./configure line to:

./configure --with-freetype2-library=/usr/lib/i386-linux-gnu/ --with-freetype2-includes=/usr/include/freetype2

I can reproduce this in quantal:

wget -nd http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_2/iil.pdf
xpdf iil.pdf

xpdf displays the first page for quite a while, then crashes.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff77716c0 in GooHash::hash(GooString*) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.28
(gdb) bt
#0 0x00007ffff77716c0 in GooHash::hash(GooString*) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.28
#1 0x00007ffff7771712 in GooHash::find(GooString*, int*) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.28
#2 0x00007ffff77718ce in GooHash::lookup(GooString*) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.28
#3 0x00007ffff771d8d4 in GlobalParams::getResidentUnicodeMap(GooString*) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.28
#4 0x00007ffff771f7a3 in GlobalParams::getUnicodeMap2(GooString*) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.28
#5 0x00007ffff7767d6a in TextPage::coalesce(bool, double, bool) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.28
#6 0x00007ffff776cf42 in TextOutputDev::endPage() () from /usr/lib/x86_64-linux-gnu/libpoppler.so.28
#7 0x00007ffff76f87ec in Gfx::~Gfx() () from /usr/lib/x86_64-linux-gnu/libpoppler.so.28
#8 0x00007ffff77392a5 in Page::displaySlice(OutputDev*, double, double, int, bool, bool, int, int, int, int, bool, bool (*)(void*), void*, bool (*)(Annot*, void*), void*) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.28
#9 0x00007ffff773934e in Page::display(OutputDev*, double, double, int, bool, bool, bool, bool (*)(void*), void*, bool (*)(Annot*, void*), void*) () from /usr/lib/x86_64-linux-gnu/libpoppler.so.28
#10 0x0000555555588fb2 in ?? ()
#11 0x000055555558c560 in ?? ()
#12 0x000055555558ef86 in ?? ()
#13 0x0000555555586bd2 in ?? ()
#14 0x000055555559c892 in ?? ()
#15 0x000055555558d453 in ?? ()
#16 0x000055555557e11a in main ()

tags: added: quantal
TBeholder (turbobeholder) wrote :

Back to circumventing the problem - from the current repositories, Debian/squeeze got xpdf 3.02-12+squeeze1 with libpoppler5 - this works.

Also, evince is good only for copypasting text. It got antialiasing always on, which is useless and eye-straining unless PDF is blurry (e.g. a bad scan) anyway or you use something other than a proper monitor. Few controls, no meaningful config and even zoom is a little buggy.
While gv is good, but slow and it can't search text.

Ronny Cardona (rcart) on 2012-11-23
Changed in xpdf (Ubuntu):
assignee: nobody → Ronny Cardona (rcart)
status: Confirmed → In Progress
tags: added: running-unity
Ronny Cardona (rcart) on 2013-02-20
Changed in xpdf (Ubuntu):
assignee: Ronny Cardona (rcart) → nobody
Changed in xpdf (Ubuntu):
status: In Progress → Incomplete
Logan Rosen (logan) on 2013-02-21
Changed in xpdf (Ubuntu):
status: Incomplete → Confirmed
description: updated
MMlosh (mmlosh) on 2013-03-03
tags: added: raring
31 comments hidden view all 111 comments
gregrwm (gregrwm) wrote :

looks interesting francis. if/when that becomes available as bin via an ubuntu repo please say so.

That is xpdf 3.03 form the Ubuntu repositories.

David Kastrup (dak) wrote :

I've fetched and installed the current xpdf binary package from Debian. Since it apparently is compiled with a compatible version of libpoppler (which is easily available and can be installed alongside the newer version), it works.

It evades me why Ubuntu thinks it is doing anybody a favor by delivering for several years now binaries that crash on every file. If they at least stopped distributing the crashing packages, people would be more likely to revert to the working Debian packages.

Andrew Tonks (a-tonks) wrote :

David, could you please please please (!) add detailed instructions - for 32 and 64 bit? I made the mistake of upgrading to 13.04 yesterday and now my workflow is severely disrupted :-(

Stefan Wagner (wagner-stefan) wrote :

@Andrew Tonks: Until David tells us the details, I can recommend xpdf_3.02-12ubuntu2nopoppler0_i386.deb for x32 which is an older version which works for me. I guess it is easy to find. With dpkg -i xpdf_3.02-12ubuntu2nopoppler0_i386.deb it should be installable.

Andrew Tonks (a-tonks) wrote :

Thanks Stefan, works for me

Iulian Udrea (iulian) on 2013-07-02
Changed in xpdf (Ubuntu):
importance: Medium → High
vitaly.v.ch (vitaly-v-ch) wrote :

What I can do in steps to rise priority for this bug? Ubuntu really does not have any useful viewer now :(((

Just to add some more chaff to keep the bug alive:

1) to this day the bug persists in Ubuntu 13.04 raring;
2) a manual solution consists in downgrading to xpdf_3.02-21build2 as of comment #55 by Ronny Cardona (rcart) dated 2012-11-23;
3) to install this xpdf package I had to apt-get install libtiff4;
4) in order to prevent apt-get to re-upgrade xpdf to the broken repository package of 3.03-10ubuntu1, xpdf_3.02-21build2 has to be pinned in the following way:
    *) create file /etc/apt/preferences.d/xpdf contatining the following lines:

Package: xpdf
Pin: version 3.02-21build2
Pin-Priority: 1001

I personally disagree with David Kastrup who on 2013-03-17 wrote comment #70. It is indeed a shame xpdf has been broken for so long a time even though a solution to the well known cause has been around for a pretty long time. However, the solution is nor surrender, the repository package just has got to be fixed and next upgrade versions must be checked against this well known and long standing bug.

David Kastrup (dak) wrote :

Regarding comment #76: sorry for the late reply, I am not reading this bug thread all too frequently any more (it's just too depressing). I just googled for the latest Debian .deb for xpdf, downloaded and installed it manually using "sudo dpkg -i [packagename.deb]". Which barfs and complains about a missing libpoppler library, so I downloaded that as well, and then did sudo dpkg -i on both packages.

Looking at my download directory, it would appear that the most recent possibly related downloads were
-rw-rw-r-- 1 dak dak 175754 Jul 12 12:30 xpdf_3.03-11ubuntu1_i386.deb
-rw-rw-r-- 1 dak dak 845206 Jul 12 12:32 libpoppler37_0.22.4-0ubuntu1_i386.deb
-rw-rw-r-- 1 dak dak 1194778 Jul 12 12:33 libxm4_2.3.4-4_i386.deb
-rw-rw-r-- 1 dak dak 13170 Jul 12 12:34 libmotif-common_2.3.4-4_all.deb

The proximity in download times makes it quite possible that libxm4 and libmotif-common were additional dependencies that I downloaded and installed, triggered by the respective complaint of dpkg (I don't actually remember doing that, but the modification times look suspiciously related, so it's likely that those were also involved). I used the Debian websites to locate the individual downloads and looked up the missing packages as they were announced by dpkg -i.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xpdf - 3.03-11ubuntu3

xpdf (3.03-11ubuntu3) saucy; urgency=low

  * Use GlobalParams module from Poppler and disable all settings that
    are not available in Poppler (LP: #943195, #1205732).
  * Remove fix-622877.patch and one hunk in
    track_libpoppler43_api_changes.patch that are no longer needed.
 -- Dmitry Shachnev <email address hidden> Wed, 04 Sep 2013 15:06:52 +0400

Changed in xpdf (Ubuntu):
status: Confirmed → Fix Released
Dmitry Shachnev (mitya57) wrote :

I've applied an ugly fix that just makes Xpdf use Poppler's GlobalParams module. The downside is that keybindings no longer work, but it's at least better than having Xpdf that doesn't start.

Saurabh Rindani (saurabh-prl) wrote :

How do I install xpdf-3.03-11ubuntu3 on Ubuntu 13.4? If I do

sudo apt-get install xpdf

it tells me I have the latest version. Should this latest package not be a part of a normal update?

Ian Hutchinson (hutch) wrote :

If the "fix" just applied disables controlling xpdf by the keys, then it's not a fix.
It totally escapes me why, since one can install xpdf from source (see #36 above) one can't simply package that and have done with it.

Dmitry Shachnev (mitya57) wrote :

@Saurabh: it is available in 13.10 (aka Saucy).

@Ian: keybindings now work again in 3.03-11ubuntu5.

Luke Maurer (luke-maurer) wrote :

Any chance the fix gets backported to Raring? Evince is hella sluggish on my 50+ pages of LaTeX'd research notes.

Dmitry Shachnev (mitya57) wrote :

I hope to be able to look at Raring backport next week.

Changed in xpdf (Ubuntu Raring):
importance: Undecided → High
status: New → Triaged
vitaly.v.ch (vitaly-v-ch) wrote :

@Dmitry: How about Precise backport?

Dmitry Shachnev (mitya57) wrote :

@Vitaly: Sorry, I don't have enough time for that :(
Patches welcome, as usual.

Dmitry Shachnev (mitya57) wrote :

I have prepared an update for raring in my ppa:mitya57/ppa. Please add that PPA, test the package and give your feedback.

Graham Inggs (ginggs) wrote :

@mitya57: I've installed xpdf for raring from your ppa and it has opened every pdf I have thrown at it so far.

description: updated
David Kastrup (dak) wrote :

Any chance to see that make it into the official Raring repositories soonish?

Dmitry Shachnev (mitya57) wrote :

@David: it's currently stuck in the Unapproved queue: https://launchpad.net/ubuntu/raring/+queue?queue_state=1, you can try to ping the SRU team to see if they are going to approve it.

James (pkx166h-1) wrote :

If it helps Dmitry - re a personal request from David Kastrup (above) via the LilyPond dev list - it works for me in Linux Mint 15 where xpdf was broken. I added your PPA and installed it that way.


Stefan Wagner (wagner-stefan) wrote :

Hash: SHA1

On 23.10.2013 08:10, Matthias Andree wrote:
> This needs to be backported to precise, too.


- --
Don't visit my blog: http://demystifikation.wordpress.de
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/


LAZA (laza74) wrote :

Can anybody say, why the priority in the upload queue is low?

The program crashes every time and doesn't work at all - so it should be high!

I really don't understand the priority feature at all...

BTW: Backport to Precise: +1

Colin Watson (cjwatson) wrote :

LAZA: The priority field has almost no effect in Ubuntu, so it really doesn't matter.

Changed in xpdf (Ubuntu Raring):
status: Triaged → Fix Committed
tags: added: verification-needed

Hello Łukasz, or anyone else affected,

Accepted xpdf into raring-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/xpdf/3.03-10ubuntu1.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Lenin (gagarin) wrote :

Backport to Precise++

Graham Inggs (ginggs) wrote :

xpdf 3.03-1ubuntu1.1 from raring-proposed working for me

tags: added: verification-done
removed: verification-needed
Dmitry Shachnev (mitya57) wrote :

I am a user of neither Xpdf nor Precise, and I don't have any plans (or time) to do a backport, sorry. If someone else does I'll be happy to sponsor it.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xpdf - 3.03-10ubuntu1.1

xpdf (3.03-10ubuntu1.1) raring; urgency=low

  * Use GlobalParams module from Poppler and move all settings that
    are not available in Poppler to a separate file (LP: #943195).
 -- Dmitry Shachnev <email address hidden> Thu, 19 Sep 2013 18:14:03 +0400

Changed in xpdf (Ubuntu Raring):
status: Fix Committed → Fix Released
TBeholder (turbobeholder) wrote :

3.03-10ubuntu1.1 (raring-updates) - works, thanks.

...of course, now it fails to understand "antialias no" explicitly set in .xpdfrc (sigh)

I recently upgraded to Xubuntu 13.10 with the xpdf package 3.03-11ubuntu6.

As TBeholder reported above, xpdf now runs without crashing, but the font display in the menus and index is abominable looking. It looks to me as if antialiasing of these fonts are not being used while those for the display document are. I have no ~/.xpdfrc but there is a global /etc/xpdf/xpdfrc initialization file.

Instead of trying to adjust antialiasing in the configuration file, I tried to set this and other parameters on the command line. What I discovered is that although xpdf -h reports these options, the following do not work:

-mattecolor <color> # error: "<color>" file not found
-z <value> # <value> is ignored
-t1lib <yes/no> # no message -- just displays help
-freetype <yes/no> # error: "<yes/no>" file not found
-aa <yes/no> # error: "<yes/no>" file not found
-aaVector <yes/no> # error: "<yes/no>" file not found
-paper <size> # error: "<size>" file not found


You get the idea. There is something seriously wrong with this build. These options all work on my Solaris build for version 3.02 of xpdf. The fact that you cannot set the antialias option on the command line may be a further key into the problem reported above. Please fix the program to get a font display that does not hurt so much to view it! :-) Thanks.

On 19/01/2014 05:18, C. Jeffery Small wrote:
> I recently upgraded to Xubuntu 13.10 with the xpdf package
> 3.03-11ubuntu6.
> As TBeholder reported above, xpdf now runs without crashing, but the
> font display in the menus and index is abominable looking. It looks to
> me as if antialiasing of these fonts are not being used while those for
> the display document are. I have no ~/.xpdfrc but there is a global
> /etc/xpdf/xpdfrc initialization file.
> Instead of trying to adjust antialiasing in the configuration file, I
> tried to set this and other parameters on the command line. What I
> discovered is that although xpdf -h reports these options, the following
> do not work:
> -mattecolor <color> # error: "<color>" file not found
> -z <value> # <value> is ignored
> -t1lib <yes/no> # no message -- just displays help
> -freetype <yes/no> # error: "<yes/no>" file not found
> -aa <yes/no> # error: "<yes/no>" file not found
> -aaVector <yes/no> # error: "<yes/no>" file not found
> -paper <size> # error: "<size>" file not found
> etc.
> You get the idea. There is something seriously wrong with this build.
> These options all work on my Solaris build for version 3.02 of xpdf.
> The fact that you cannot set the antialias option on the command line
> may be a further key into the problem reported above. Please fix the
> program to get a font display that does not hurt so much to view it!
> :-) Thanks.

  I would say this deserves a separate, new bug report.

  Have a good day,

Siep Kroonenberg (siepo) wrote :

xpdf has been renamed to xpdf.real, and xpdf now is a wrapper for xpdf.real. I tested -aa on xpdf.real and it works there.
As stated above though, this should be a new bug report.

Changed in xpdf (Debian):
status: Confirmed → Fix Released
Dmitry Shachnev (mitya57) wrote :

@ C. Jeffery Small:

As our package is now (mostly) in sync with Debian, I have forwarded your bug report to the Debian maintainer:

Martin Hecht (mrbaseman) wrote :

the patch from http://silas.psfc.mit.edu/xpdf3.03Viewer.patch is no longer available, found here: http://nawhko.tistory.com/66 attaching it to this post

Martin Hecht (mrbaseman) wrote :

I wanted to write "patch to comment #36" - I have built a working xpdf for Ubuntu 12.04 LTS with this.

Displaying first 40 and last 40 comments. View all 111 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.