FS#59281 - [poppler] depends on gsfonts

Attached to Project: Arch Linux
Opened by Tom Yan (tom.ty89) - Monday, 09 July 2018, 15:10 GMT
Last edited by Andreas Radke (AndyRTR) - Monday, 18 November 2019, 21:37 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Jan de Groot (JGC)
Andreas Radke (AndyRTR)
Jan Alexander Steffens (heftig)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:

The gsfonts package provides PDF base fonts which are useful/necessary for pdftocairo.

Currently gsfonts is pulled by evince (which pulls poppler-glib and in turn poppler) instead of poppler.


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


Steps to reproduce:
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Monday, 18 November 2019, 21:37 GMT
Reason for closing:  Won't fix
Comment by Jan de Groot (JGC) - Monday, 09 July 2018, 18:48 GMT
Required fonts depend on the document you want to convert. Poppler depends on fontconfig, so it can use any font instead of gsfonts.
gsfonts isn't even a suggestion on debian, so I don't see the need for a dependency.
Comment by Tom Yan (tom.ty89) - Monday, 09 July 2018, 19:45 GMT
Except the base/standard 14 fonts are way more expected to be substituted than other random fancy fonts, which are likely embedded (otherwise it wouldn't really be making sense). You can see them being listed in GfxFont.cc and PSOutputDev.cc anyway.

And gsfonts is pretty much the free de facto standard for standard 14 substition (tex-gyre, the only alternative I know of, arguably lost its point when Artifex/URW releases their fonts in otf). You hardly want to use dejavu fonts or whatsoever for that.

Though you can argue that it's not an Arch policy to make pdf readers or so pull the font set for proper standard 14 substition, it would be funny, for evince being one of the two exceptions.
Comment by Jan de Groot (JGC) - Monday, 09 July 2018, 21:46 GMT
On debian, gsfonts is pulled in through libspectre and libgs, where gsfonts is a recommended dependency.
I think evince should drop the dependency and move gsfonts as optdepend to ghostscript.
Comment by Tom Yan (tom.ty89) - Monday, 09 July 2018, 22:22 GMT
ghostscript ships a set of urw core35 fonts in Type 1 for its own use. gsfonts ships a set of that in OpenType. No idea if libspectre makes use of the latter.

If you decide to drop gsfonts dependency in evince, then I wouldn't bother to ask for that in poppler.

No idea why what debian does matters here.
Comment by Andreas Radke (AndyRTR) - Wednesday, 08 August 2018, 18:31 GMT
I'm for Jans solution to add gsfonts as optdepend to ghostscript. @heftig - any opinion?
Comment by Tom Yan (tom.ty89) - Wednesday, 08 August 2018, 20:11 GMT
May I ask what's even the sense in doing that?

Not only that it does not help and is not relevant at all to this issue, as I mentioned ghostscript already ships its own set of "gsfonts" in Type 1. If libspectre does not / cannot make use of that when it makes use of ghostscript, then libspectre should depends on it. (Yet no ones even attempted show that's a fact except from "hey debian does that".)

And this is issue is about making the base fonts a dependency to poppler so that they are available for it when it (i.e. pdfcairo) handles PDFs on its own. And that has nothing to do with ghostcript or libspectre at all.

So the problem here is really just whether in Arch we consider the base fonts essential enough to be a dependency. If yes, make poppler deps it (and undep it from evince), if not make poppler optdeps it (and undep it from evince), end of story.
Comment by Jan Alexander Steffens (heftig) - Wednesday, 08 August 2018, 20:45 GMT
ghostscript doesn't like gsfonts; see the ghostscript package history where I attempted to make it use fonts from gsfonts and cmaps from poppler-data, but had to revert both because of issues.

Loading...