On Fri, Oct 6, 2017 at 10:51 PM, R P Herrold <herrold@owlriver.com> wrote:
I don't see a urw-base35-fonts SRPM in my RawHide ... has it
been packaged?
​Yes, it's in the Rawhide already:
https://src.fedoraproject.org/rpms/urw-base35-fonts


My mirror only fires weekly, but it seens ... hasty to retire
a package before its successor has 'aged' a bit to let
possible bugs appear.  In checking the CTAN site, it seems
pretty likely that font metrics will have changed and so the
appearance of documents will be affecte
​d
​I understand your concerns, but to clarify - technically, the urw-base35-fonts is a successor to successor of ghostscript-fonts:

  ghostscript-fonts -> urw-fonts -> urw-base35-fonts
​I took ownership of urw-fonts sometime in the last year, and I had been working with upstream (Artifex company) to fixing some bugs in the latest release of these fonts [a.k.a. (URW)++ fonts], as well as updating and creating fontconfig and AppStream files (respectively).

I really can't tell why the ghostscript-fonts were not killed before, since we had the urw-fonts already. You would have to ask previous maintainers about this.​

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

To clarify on what others wrote:

 * Nicolas is right, the fonts needed a proper cleanup, and that's why we went through this. We were already using an outdated fonts in Fedora 25 (and newer) for Ghostscript and other applications depending on it (like ImageMagick, GraphicsMagick, Evince, ...), and I received some bug reports for it that forced me to "hack" the Ghostscript configuration to temporary fix this situation -- but not completely.

   Since I hope to do a rebase of Ghostscript-9.22 in F27 (to fix quite few low-level CVEs and some annoying issues, but no API/ABI changes according to upstream, so it should be "safe"), I needed the urw-base35-fonts to be ready first.

   Ghostscript bundles a lot of stuff, but we're "de-bundling" it in Fedora. However the 'urw-fonts' were already too old now/outdated in F25. In past, any part needed for Ghostscript's "de-bundled" build often resulted in unnecessary bug-reports for upstream, if it was outdated. And it was IMHO mainly because of that why upstream started... to not like use very much. (In last ~1 year I'm working more closely with upstream to improve the relationship again, and to fix all the mess around Ghostscript.)

​ * Right now, we have a problem that some applications (ImageMagick at least, I expect others as well) depend on Type1 fonts, not just Ghostscript, which is not allowing us to completely move to OTF font format. But as Nicolas said, the LibreOffice in F26 no longer supports Type1 fonts.

  ->> I expect for us to ship both OTF and Type1 together for now (as a transition period), until we can work with upstreams & package maintainers to make complete shift to OTF.

 * Regarding the font family names and subpackages -- it's another mess. Not just in Fedora (the FPG for fonts are really outdated), but generally everywhere. Currently I'm seeing that every party (group) does something different, and IMHO we should first update the FPG, and to do a general fonts cleanup in Fedora. (For now I will keep the subpackages, until we decide on how to approach this on wide level across Fedora.)

 * I wouldn't say the upstream is dead, they have just moved fast-forward, and the fonts in ghostscript-fonts are no longer supported by them. However, orphaning the package does not make much sense to me. We need the maintainer/upstream of "hylafax+" to move to 'urw-base35-fonts', which are supposed to receive updates in the future if needed. Once they have moved, then we can kill the ghostscript-fonts.

 ->> For now the maintainer of 'hylafax+' should try to update the paths (if needed) in 'hylafax+' specfile, and try to build it against 'urw-base35-fonts'. If it succeeds, we can try to let it live in Rawhide for some time. If it does not succeed, we should inform its upstream so they can update their software.

2 Nico: I understand that 'hylafax+' is an extremely stable package, but that shouldn't block us from moving forward in fixing other stuff. Is my suggestion above OK for you as a solution for now? :)

-- Dee'Kej --