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
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
|
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
I'm really not keen to reintroduce Type1 fonts in gsfonts. Perhaps a gsfonts-type1 package or another maintainer would work...
Just my 2c. Maybe try mupdf if you haven't.
> "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.
> "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.
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.
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.