FS#50757 - [xpdf] gsfonts 2016 update breaks xpdf

Attached to Project: Arch Linux
Opened by Mike Sharov (msharov) - Monday, 12 September 2016, 21:00 GMT
Last edited by Gaetan Bisson (vesath) - Saturday, 01 October 2016, 22:18 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Levente Polyak (anthraxx)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
gsfonts 20160531 update contains an entirely new set of fonts that xpdf can not see. PDF documents without embedded fonts are rendered without text and output console errors such as:

Config Error: No display font for 'Helvetica'
Warning: Cannot convert string
"-*-helvetica-medium-r-normal--12-*-*-*-*-*-iso8859-1" to type FontStruct
Syntax Error: Couldn't find a font for 'Arial'

Downgrading to 20150811 fixes the problem.
This task depends upon

Closed by  Gaetan Bisson (vesath)
Saturday, 01 October 2016, 22:18 GMT
Reason for closing:  Won't fix
Comment by Gaetan Bisson (vesath) - Tuesday, 13 September 2016, 00:59 GMT
We had removed xpdf from our repos a while ago for being a terrible, unmaintained piece of software. No idea why it was reintroduced but until I fix this I strongly advise you stop using xpdf immediately: it is an unnecessary security risk. There are plenty of much better PDF viewer. See: https://wiki.archlinux.org/index.php/List_of_applications/Documents#PDF_and_DjVu .
Comment by Gaetan Bisson (vesath) - Tuesday, 13 September 2016, 01:25 GMT
The real issue here is that gsfonts moved from shipping fonts in the antique Type1 format to the more modern OTF format. And I don't want to change that just because xpdf has been unmaintained for as long as I can remember. Please use a better PDF viewer or see if the xpdf maintainer is willing to "fix" his package somehow.
Comment by Mike Sharov (msharov) - Tuesday, 13 September 2016, 01:39 GMT
Type1 format is not "antique". It has been replaced with OTF in many applications, but there is nothing inherently wrong with it. And there IS no better PDF viewer. Linux acroread has been broken for a while now, and none of the others support the accessibility feature of using non-white backgrounds. (White backgrounds are very hard on the eyes and I am physically unable to look at them for more than a few minutes). So that leaves xpdf. And the question of would it really be so hard to keep the old Type1 fonts in the package? ghostscript may not be using them now, but xpdf may not be the only application that needs them. Or are you going to make me downgrade and IgnorePkg?
Comment by Levente Polyak (anthraxx) - Tuesday, 13 September 2016, 01:45 GMT
Well IMO it could be simply be provided to satisfy xpdf and I still see the use-case for for xpdf even if its an old software. its tiny/small and minimalistic.
Comment by Gaetan Bisson (vesath) - Tuesday, 13 September 2016, 02:43 GMT
It sound to me like both of you would really like mupdf. I can assure you you won't regret leaving xpdf behind for it...

I'm really not keen to reintroduce Type1 fonts in gsfonts. Perhaps a gsfonts-type1 package or another maintainer would work...
Comment by Glenn (grepfor) - Saturday, 01 October 2016, 18:26 GMT
I was also a long-time user of xpdf, and annoyed by this gsfonts 20160531 update. But I took Gaetan's suggestion to try mupdf, and after playing with it for a while, have to agree that it really is superior to xpdf in all tasks that I've had occasion to use it for so far. Glad to leave xpdf behind after all these years. Tip o' the hat to Gaetan for the suggestion (and for pushing back at maintaining the unmaintainable).

Just my 2c. Maybe try mupdf if you haven't.
Comment by Mike Sharov (msharov) - Saturday, 01 October 2016, 18:46 GMT
Sorry, but mupdf is inadequate for my needs. For example, one of the many missing features is the ability to set paper color in configuration; the only way to do it is by passing a command line argument. That means hardcoding the color into every script that launches it. Yes, mupdf is a good start and does look like a cleaner code base, but it is not by any means a drop-in replacement. If I were to switch to it, I would have to spend a lot of time implementing the missing features in that project. That is either just difficult or maybe impossible if the project owner does not want such changes. So xpdf stays until you pry it out of my cold dead hands. And, evidently, so does the pre-20160531 gsfonts package.
Comment by Glenn (grepfor) - Saturday, 01 October 2016, 19:43 GMT
>
> "That means hardcoding the color into every script that launches it. "
>

A config file would be nice, but why not just define a function for a generic PDF viewer:

function mypdfview { mupdf -Crrggbb "$@"; }

After all, you're saying that one of the reasons you don't want to switch to mupdf is that "every script that launches it" has to be changed. But you'd have to do that anyway, no matter what new tool you might decide to use in its stead, whether mupdf or anything else. So why not just go thru all your scripts once and replace all calls to xpdf with "mypdfview" like above? This gives you the ability to effectively embed commandline options for whatever viewer tool you use, and also to even change the viewer tool itself at some point in the future, without changing anything but your function definition. If you have so many scripts that invoke PDF viewer, might as well improve the future maintainability. Few minutes of "find --exec grep xpdf" and some text editing.

Just trying to offer constructive suggestion.
Comment by Mike Sharov (msharov) - Saturday, 01 October 2016, 19:58 GMT
That does not work when the command is in a Makefile, as mine is, testing PS output of a program after it exits. Even if somehow it could be made to work, I have better things to do with my time than fix things that aren't broken. xpdf works. mupdf currently doesn't. So I use xpdf. WHY ARE YOU MAKING MY LIFE HARDER? :)
Comment by Glenn (grepfor) - Saturday, 01 October 2016, 20:21 GMT
>
> "That means hardcoding the color into every script that launches it. "
>

A config file would be nice, but why not just define a function for a generic PDF viewer:

function mypdfview { mupdf -Crrggbb "$@"; }

After all, you're saying that one of the reasons you don't want to switch to mupdf is that "every script that launches it" has to be changed. But you'd have to do that anyway, no matter what new tool you might decide to use in its stead, whether mupdf or anything else. So why not just go thru all your scripts once and replace all calls to xpdf with "mypdfview" like above? This gives you the ability to effectively embed commandline options for whatever viewer tool you use, and also to even change the viewer tool itself at some point in the future, without changing anything but your function definition. If you have so many scripts that invoke PDF viewer, might as well improve the future maintainability. Few minutes of "find --exec grep xpdf" and some text editing.

Just trying to offer constructive suggestion.
Comment by Mike Sharov (msharov) - Saturday, 01 October 2016, 20:28 GMT
Additionally, the pdf viewer is not always launched from a shell. Heck, it isn't even always the same shell; /bin/sh is dash, while I normally use bash. Then there is Midnight Commander config file, firefox, thunderbird, and whatever other places I can't currently think of. Put the command line option into all those and if you ever want to change the color, God help you. The right thing to do, of course, is to use Xrdb, as every Xlib-based program has done for the last 40 years. If I were going to switch to mupdf, that's what I'd implement there. But that's just one problem, and I don't want to be a mupdf maintainer right now.
Comment by Levente Polyak (anthraxx) - Saturday, 01 October 2016, 20:32 GMT
can we stop having a discussion in a xpdf related bug report how to use mupdf? thanks.
Comment by Glenn (grepfor) - Saturday, 01 October 2016, 20:35 GMT
Pain builds character! :)

In a Makefile, the situation is even easier, via a make(1) macro:

PDFVIEW= mupdf -Crrggbb

some_target:
$(PDFVIEW) $(SOMEFILE)


This is not a kludge, it's a standard approach, typically used to invoke build-related tools from within a Makefile, especially tools which may differ in name or calling syntax from system to system.

Comment by Glenn (grepfor) - Saturday, 01 October 2016, 20:40 GMT
Xlib hasn't existed for 40 years. And xpdf doesn't support Xresources either.
Comment by Gaetan Bisson (vesath) - Saturday, 01 October 2016, 22:17 GMT
Arch Linux does not have the resources or the will to maintain deprecated packages forever. We follow upstream when they move forward, as we have done with gsfonts.

If you have the resources and the will, you are of course welcome to upload and maintain a gsfonts-old and/or xpdf package on the AUR.

Loading...