FS#56840 - [gsfonts] Consider shipping the t1 version

Attached to Project: Arch Linux
Opened by Olivier (olive) - Sunday, 24 December 2017, 08:46 GMT
Last edited by Gaetan Bisson (vesath) - Monday, 07 May 2018, 05:09 GMT
Task Type Feature Request
Category Packages: Extra
Status Closed
Assigned To Gaetan Bisson (vesath)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No



In the past gsfonts was distributed with their T1 version. Archlinux decided to ship the otf version. While they are compatible with ghostscript, other package depends on these fonts and cause compatibility problem. Moreover the T1 version appears to be not compatible with legacy software that use the builtin ability of Xorg to display fonts (XFLD fonts). It was the subject of a xfig bug  FS#56728  that was more or less correctly by making xfig to use pixel fonts but that is not perfect (they only approximate the gsfonts and they are no equivalent for every font). It is a current problem in xpdf:  FS#50297  and I suspect that other packages dependent of these fonts may be broken.

Maybe the best would be to ship t1 fonts as before and add compatibility symlinks with the old names.

Additional info:
* package version(s)
* config and/or log files etc.

Steps to reproduce:
This task depends upon

Closed by  Gaetan Bisson (vesath)
Monday, 07 May 2018, 05:09 GMT
Reason for closing:  Won't implement
Comment by Gaetan Bisson (vesath) - Monday, 25 December 2017, 23:42 GMT
I'm not sure that adding t1 fonts back is a step in the right direction. If it fixes a few things, sure, we can probably make a gsfonts-t1 package.

Concerning this particular issue: xpdf is probably the most ancient PDF reader you can find. I strongly suggest you consider switching to more modern (implying: safer, better supported and more featureful) alternatives like evince or mupdf/zathura. Cheers.
Comment by Levente Polyak (anthraxx) - Tuesday, 26 December 2017, 00:02 GMT
xpdf got a full 100% rewrite based on QT in 2017 Aug 10 so if thats the most ancient stuff then i guess we are awesome in terms of pdf.
mupdf is far less safe if you consider the sheer amount of CVEs in the past 3 years, lots of them are popping up (still) as f.e. there is a heap buffer overflow leading to code execution just pending right now. saying its safer per se is a claim not based on any facts.
Comment by Olivier (olive) - Tuesday, 26 December 2017, 08:19 GMT
@Gaetan Bisson The otf fonts seems to pose some problems with ghostscript although this is not the only problem (see this bug report: https://bugs.archlinux.org/task/56849).

But I see other packages that depends on gsfonts that I do not use and do not have tested but I think we must take care of them too; I suspect other problems. What I would think would be the best would be to ship the ttf version (that is the general standard nowadays) for general availability and to have have a specific package for the software that depends on a very precise font. Sometimes it is IMHO even better to have the font in a directory specific to the software; it is how ghostscript is normally build unless you build it on a way that is not even documented upstream. It is how the TeX system is shipped.
Comment by Gaetan Bisson (vesath) - Monday, 07 May 2018, 05:08 GMT
The modern standard is OTF, not TTF or T1 fonts, so that is what we should all strive to use. Specific issues that arises from the use of OTF fonts should and will be fix. Please create bug reports on this tracker for these. However I will close this blanket report. Cheers.