libreoffice probably just started to filter fonts in obsolete formats such as Postscript. Pre-opentype formats are really limitating for applications that do non-trivial text processing, and libreoffice folks did a huge amount of work lately to fix their text rendering stack.

Someone should really package tex gyre in Fedora, now that the legal issues have been solved (IIRC). That's basically the same fonts in an opentype container.

http://www.gust.org.pl/projects/e-foundry/tex-gyre

(In reply to Nicolas Mailhot from comment #1)
> Someone should really package tex gyre in Fedora, now that the legal issues
> have been solved (IIRC). That's basically the same fonts in an opentype
> container.
> 
> http://www.gust.org.pl/projects/e-foundry/tex-gyre

Is that different from texlive-tex-gyre that we already have? I just remembered filing #1394198 and I checked the messages we had exchanged with the developers. Judging by the "News" section of their website, we are still waiting for the Ghostscript and Tex Gyre teams to agree on a license.

I haven't checked texlive lately but unless the fonts are packaged using the Fedora packaging template they won't be available in fontconfig for non-tex apps such as libreoffice.

It does not matter if they are packaged as texlive subpackages or as independent projects as long as the template is applied. Also, whoever packages them needs to ship some fontconfig files that aliases the various past names of the fonts to the new one for backwards compat. Again there are templates to do so in fontpackages-devel.

Reading
http://www.gust.org.pl/projects/e-foundry/tex-gyre/index_html#Licensing

they got URW to publish the fonts under their own pet license to avoid dealing with Ghostscript licensing they didn't understood. So as long as they rebased to that release with no ghostscript import they are ok legal-wise (do check with spot if you feel like it, though I'm pretty sure he'd have blocked them from TexLive during its TEX audits if there was still a problem).

That sucks if GS added fixes over URW material, but that's how free software works when projects disagree on licensing.

(In reply to Nicolas Mailhot from comment #3)
> I haven't checked texlive lately but unless the fonts are packaged using the
> Fedora packaging template they won't be available in fontconfig for non-tex
> apps such as libreoffice.

There are no fontconfig.conf (nor metainfo.xml) files and the fonts are packaged in a number of different formats.
Interestingly, I discovered the texlive-tex-gyre-math package on my system, which contains nothing but the fonts in otf format plus their license and these fonts are available in LibreOffice.


> It does not matter if they are packaged as texlive subpackages or as
> independent projects as long as the template is applied. Also, whoever
> packages them needs to ship some fontconfig files that aliases the various
> past names of the fonts to the new one for backwards compat. Again there are
> templates to do so in fontpackages-devel.

I seem to have such rules in 30-metric-aliases.conf as well as in the fontconfig files from David's urw-base35 fonts.


> Reading
> http://www.gust.org.pl/projects/e-foundry/tex-gyre/index_html#Licensing
> 
> they got URW to publish the fonts under their own pet license to avoid
> dealing with Ghostscript licensing they didn't understood. So as long as
> they rebased to that release with no ghostscript import they are ok
> legal-wise (do check with spot if you feel like it, though I'm pretty sure
> he'd have blocked them from TexLive during its TEX audits if there was still
> a problem).
> 
> That sucks if GS added fixes over URW material, but that's how free software
> works when projects disagree on licensing.

This was on 2016-11-25:

"We are on our way to the reconciling both licenses. It takes time, though..."

(In reply to Alexander Ploumistos from comment #4)
> (In reply to Nicolas Mailhot from comment #3)
> > I haven't checked texlive lately but unless the fonts are packaged using the
> > Fedora packaging template they won't be available in fontconfig for non-tex
> > apps such as libreoffice.
> 
> There are no fontconfig.conf (nor metainfo.xml) files and the fonts are
> packaged in a number of different formats.
> Interestingly, I discovered the texlive-tex-gyre-math package on my system,
> which contains nothing but the fonts in otf format plus their license and
> these fonts are available in LibreOffice.

All the packaging template does is make sure the fonts are in  a location fontconfig looks at, aliasing rules are ok, package naming and split is consistent with other Fedora font packages, and fontconfig indexes are refreshed at install time so yes one can do the same as the template piecemeal (though it is much simpler to apply the template to make sure nothing was forgotten as is usually the case).

If libreoffice sees the fonts that confirms newer libreoffice expects OpenType only, ie ttf or otf files (which is rather sane in 2017, one can only workaround old legacy incomplete formats so long).

So there are two good options: make sure TEX Gyre fonts are well packaged in Fedora, or start a separate project to convert URW fonts to OpenType under GS licensing (and drop the legacy PS1 files)

And there is one bad option: convince libreoffice to accept PS1 fonts a bit longer, with the associated bugs and limitations, that no one will know to attribute to the legacy format, that no one will ever fix, and things will continue to slowly rot.

I hate when people ship legacy font formats "just because they may be useful for someone", OpenType won a long time ago, OpenType contains stuff with is required for state of the art text rendering, non-OpenType is a dead end, all modern apps work fine with OpenType and need nothing else.

(In reply to Nicolas Mailhot from comment #5)
> I hate when people ship legacy font formats "just because they may be useful
> for someone", OpenType won a long time ago, OpenType contains stuff with is
> required for state of the art text rendering, non-OpenType is a dead end,
> all modern apps work fine with OpenType and need nothing else.

I'm with you all the way.


@Dee'Kej:

David, I saw that the source package for urw-base35-fonts contains afm, otf, t1 and ttf formats. Is there a reason why you left OpenType and TrueType out?

Hello guys, sorry for the delayed response, I had a vacation. :)

(In reply to Alexander Ploumistos from comment #6)
> David, I saw that the source package for urw-base35-fonts contains afm, otf,
> t1 and ttf formats. Is there a reason why you left OpenType and TrueType out?

Actually, there is. I was also up for using either TTF or OTF formats for shipping those fonts, but after long discussions with (URW)++ fonts upstream (de-facto Artifex Company - creators of ghostscript), I was "forced" to use the Type1 formats with the metrics files (AFM).

Here's the justification (excerpt from urw-base35-fonts' specfile):

#    According to upstream, Ghostscript needs only Type 1 fonts to work properly.
#    It can use TTF or OTF fonts as substitutions as well in case the Type 1
#    fonts are missing, but the substitution is not (and can't be) guaranteed to
#    be absolutely flawless, unless the fonts use the CFF outlines:
#    > https://en.wikipedia.org/wiki/PostScript_fonts#Compact_Font_Format
#
#    The AFM (Adobe Font Metrics) are useful for layout purposes of other
#    applications, and they contain general font information and font metrics.
#    These AFM files were distributed in the previous 'urw-fonts' package, so in
#    order to avoid possible regressions in the future, we need to continue
#    distributing them.

#    NOTE: Fedora Packaging Guidelines (FPG) requires to use OTF or TTF format:
#          https://fedoraproject.org/wiki/Choosing_the_right_font_format_to_package
#
#          However, according to upstream, the OTF/TTF fonts cause problems
#          with 'pdfwrite' if we try to use them as base35 fonts. Otherwise,
#          they work fine, but according to upstream they will *never* be able
#          to use OTF/TTF fonts as the base35.
#
#          Since AFAIK no other package/utility requires the base35 fonts, and
#          Type 1 fonts with the AFM files are necessary for ghostscript to
#          function properly, this fonts package will only use these files. We
#          are not shipping the OTF alongside Type 1/AFM, because that would
#          approximately double the size of the packages, which is not wanted.
#
#          In case the ghostscript (specifically 'pdfwrite' device) will start
#          to work correctly with OTF fonts type, then we will make the switch.

I'm okay with shipping the fonts in the OTF format as well (it now easiery after several discussions with upstream), but I would expect people to start complaining about it that the fonts are duplicated on their systems and that the size of the packages is doubled unnecessary.

Do you have any suggestion on how to proceed from here? Should I take this to FESco and ask for official exception/permission to ship both Type1/AFM and OTF formats?

Because right now, we are kind of in a dead-end situation:
 * ghostscript will not work properly without Type1/AFM (and I've spent a lot of time to calm things down with ghostscript upstream, and I don't want to mess it up again - they kind of hated us already before, because we kept messing with their software improperly and they were receving not relevant bug reports because of it)
 * the new LibreOffice will not work with the old Type1/AFM and it needs the OTF, as you said

(In reply to Nicolas Mailhot from comment #3)
> Reading
> http://www.gust.org.pl/projects/e-foundry/tex-gyre/index_html#Licensing
> 
> they got URW to publish the fonts under their own pet license to avoid
> dealing with Ghostscript licensing they didn't understood. So as long as
> they rebased to that release with no ghostscript import they are ok
> legal-wise (do check with spot if you feel like it, though I'm pretty sure
> he'd have blocked them from TexLive during its TEX audits if there was still
> a problem).
> 
> That sucks if GS added fixes over URW material, but that's how free software
> works when projects disagree on licensing.

Actually, that note mentions Ghostscript 4.0, which is really old. We currently have 9.X for a quite long time in Fedora now. That might be worth poking in it, to see what the current status is... :)

(In reply to Nicolas Mailhot from comment #1)
> Someone should really package tex gyre in Fedora, now that the legal issues
> have been solved (IIRC). That's basically the same fonts in an opentype
> container.

Sorry, I'm not going through that rabbit hole again... :D The reason I went into updating urw-base35-fonts was that those are needed by ghostscript, and I want to finally fix all the issues related to f***ed building process. However, if you want, feel free to take inspiration from urw-base35-fonts specfile:
https://src.fedoraproject.org/rpms/urw-base35-fonts/blob/master/f/urw-base35-fonts.spec

It should be more or less OK (I'm trying to keep it up-to-date), and should be well commented.

(In reply to Nicolas Mailhot from comment #3)
> It does not matter if they are packaged as texlive subpackages or as
> independent projects as long as the template is applied. Also, whoever
> packages them needs to ship some fontconfig files that aliases the various
> past names of the fonts to the new one for backwards compat. Again there are
> templates to do so in fontpackages-devel.

That's another issue. Ideally, the good fonts should not only have the fontconfig files properly created for them, but AppStream files as well. I had to create/copy & modify those files manually for urw-base35-fonts, and it took quite some effort to convince usptream to include them in their releases.

The AppStream for font files allow users to see the preview of them in Gnome Software (and other software centers in other distros that are using AppStream).

> (In reply to Nicolas Mailhot from comment #3)
> > It does not matter if they are packaged as texlive subpackages or as
> > independent projects as long as the template is applied. Also, whoever
> > packages them needs to ship some fontconfig files that aliases the various
> > past names of the fonts to the new one for backwards compat. Again there are
> > templates to do so in fontpackages-devel.
> 
> That's another issue. Ideally, the good fonts should not only have the
> fontconfig files properly created for them, but AppStream files as well.

Yes, Appstream is yet another thing to have.

Note however that Appstream for fonts was heavily influenced by Debian, and Debian didn't rebase its font packaging around fontconfig as Fedora did a few years ago, so a lot of the "Need to do foo in appstream because fontconfig is insufficient or fonts are broken" do not really apply for Fedora.

If the font metadata is bad for example Fedora would prefer the packager to fix the font and patch the metadata rather than hide the brokenness under an Appstream overlay (which won't exist for apps that use the fonts anyway).

(In reply to David Kaspar [Dee'Kej] from comment #7)

> Do you have any suggestion on how to proceed from here? Should I take this
> to FESco and ask for official exception/permission to ship both Type1/AFM
> and OTF formats?

That's a poor situation to be in, but yes the minimum would be to ship the OpenType¹ versions as required by Fedora packaging guidelines, and maybe hide somewhere the Type1/AFM versions for GS private use (after asking Fesco). The first priority would be to avoid Ghostscript blocking progress in other apps that want to use those fonts. If that can help you in any way, you have my blessing, for the little it is worth.

As an aside I understand the reluctance of Ghostscript upstream to switch from "proven" Type1 fonts but let's be honest, Ghostscript is fed all kinds of stuff by third-party apps, the Type1 support of those apps is going away, they *will* preferentially use OpenType files, so long term there will be all sorts of subtle discrepancies between a Ghostscript that understands URW as "Type1", and the rest of the world that thinks "Opentype". But that's typically a "choose your poison" situation for the Ghostscript maintainer, it need not impact the rest of the distro the way it does now.

¹ Probably OTF not TTF given the Type1 history of those fonts

(In reply to Nicolas Mailhot from comment #9)
> Note however that Appstream for fonts was heavily influenced by Debian, and
> Debian didn't rebase its font packaging around fontconfig as Fedora did a
> few years ago, so a lot of the "Need to do foo in appstream because
> fontconfig is insufficient or fonts are broken" do not really apply for
> Fedora.
> 
> If the font metadata is bad for example Fedora would prefer the packager to
> fix the font and patch the metadata rather than hide the brokenness under an
> Appstream overlay (which won't exist for apps that use the fonts anyway).

I see. :) Well, I hope the AppStream and fontconfig metadata are mostly OK for the moment - at least for the urw-base35-fonts. I've spent a lot of time to get it right.

(Currently, there was a small issue with typo in AppStream metadata that has a pull-request waiting for acceptance, and small issue with Standard Symbols PS being to big when used for LGC fonts.)

BTW OTF *is* the OpenType (SFNT) format used to ship CFF outlines nowadays so unless upstream did something really weird with its OTF files they satisfy :

#    According to upstream, Ghostscript needs only Type 1 fonts to work properly.
#    It can use TTF or OTF fonts as substitutions as well in case the Type 1
#    fonts are missing, but the substitution is not (and can't be) guaranteed to
#    be absolutely flawless, unless the fonts use the CFF outlines:
#    > https://en.wikipedia.org/wiki/PostScript_fonts#Compact_Font_Format

https://blog.typekit.com/2010/12/02/the-benefits-of-opentypecff-over-truetype/

(In reply to Nicolas Mailhot from comment #10)
> That's a poor situation to be in, but yes the minimum would be to ship the
> OpenType¹ versions as required by Fedora packaging guidelines, and maybe
> hide somewhere the Type1/AFM versions for GS private use (after asking
> Fesco). The first priority would be to avoid Ghostscript blocking progress
> in other apps that want to use those fonts. If that can help you in any way,
> you have my blessing, for the little it is worth.

I'm OK to ship it all together (i.e. *.t1 living next to *.otf), in order for the fonts to have the same file path (I would like to avoid creating a symlinks in that folder). The reason why we now need the Type1 to be living in that exact folder name is that ImageMagick has just added support for 'urw-base35-fonts' and it is expecting the Type1 fonts in that specific location:

https://github.com/ImageMagick/ImageMagick/commit/fbca0d09324006b66b01e

(I forgot to mention that there are other packages still depending on the Type1 format - ImageMagick is the one of them, and AFAICT there are others.)

> As an aside I understand the reluctance of Ghostscript upstream to switch
> from "proven" Type1 fonts but let's be honest, Ghostscript is fed all kinds
> of stuff by third-party apps, the Type1 support of those apps is going away,
> they *will* preferentially use OpenType files, so long term there will be
> all sorts of subtle discrepancies between a Ghostscript that understands URW
> as "Type1", and the rest of the world that thinks "Opentype". But that's
> typically a "choose your poison" situation for the Ghostscript maintainer,
> it need not impact the rest of the distro the way it does now.

You're getting to the core of the problem here actually. As I mentioned before, Ghostscript upstream does not want to switch to OTF/TTF, because one of their "devices" (inside of Ghostscript called 'pdfwrite', used for conversions, etc.) would not work in quite few scenarios (I had some bug reports about it before IIRC), thus making the PS->PDF and PDF->PS conversions not working.

So as the rest of the World is slowly starting to use the OTF/TTF, the Ghostscript is using Type1 fonts (converted from the OTF files actually), and they most likely will be doing it for a long time to come. That's because they are bundling the Type1 fonts with the Ghostscript vanilla sources, so they do not need to care about the rest of the World going with OTF.

And that's because of the FPG that we actually ship a separate package for these fonts (because FPG forbids bundling of software, unless there is an exception from FESco). And that's why many other distros IMHO do not face these problems, because they do not care so much about bundling the software - they built it from vanilla sources (with a lots of other bundled libraries, etc.) and just ship it. When this happens, they can have both OTF fonts and Type1 fonts living next to each other. (Type1 is being shipped as part of Ghostscript's resources.)

Looking at the sizes of the OTF and TTF, the OTF seems to be "compressed", therefore in order to save users' space, I would again vote for using this format.

So to conclude, I will take this to a FESco, but I need to find out how to do this officially first. And I'm currently being under time pressure both from my primary job responsibilities and F27 release schedule - because the process of putting this package into F27 is already underway, and I can't stop it anymore - other packages are currently depending on it as well.

In this case, I will probably take the way of "EAFP" instead of "LBYL", make the changes ASAP, and then inform FESco about this and "ask for forgiveness"... :D

(In reply to Nicolas Mailhot from comment #12)
> BTW OTF *is* the OpenType (SFNT) format used to ship CFF outlines nowadays
> so unless upstream did something really weird with its OTF files they
> satisfy :
> 
> #    According to upstream, Ghostscript needs only Type 1 fonts to work
> properly.
> #    It can use TTF or OTF fonts as substitutions as well in case the Type 1
> #    fonts are missing, but the substitution is not (and can't be)
> guaranteed to
> #    be absolutely flawless, unless the fonts use the CFF outlines:
> #    > https://en.wikipedia.org/wiki/PostScript_fonts#Compact_Font_Format
> 
> https://blog.typekit.com/2010/12/02/the-benefits-of-opentypecff-over-
> truetype/

Yeah, I realize that. That's why there's that additional note in specfile, that even though most of the Ghostscript should work with OTF now, the 'pdfwrite' device is still not able to do so... :-/

And as I mentioned in my previous comment, the ImageMagick also expects the Type1 /AFM fonts, and I expect there are some other applications might require it as well. Here's the list of packages requiring the old 'urw-fonts' package:

ghostscript-core
grace
GraphicsMagick
graphviz
htmldoc
ipe
libwmf
mscgen
pdf-renderer
pokerth
root-core
synfig
xpdf
ImageMagick

(In reply to David Kaspar [Dee'Kej] from comment #13)

> Looking at the sizes of the OTF and TTF, the OTF seems to be "compressed",
> therefore in order to save users' space, I would again vote for using this
> format.

TTF uses quadratic splines whereas OTF uses cubic splines. Type1 uses cubic splines. That's why you can get lossless glyph shape conversion between Type1 and OTF but not between Type1 and TTF, and why upstream wrote they absolutely needed a CFF format to make sure there was no deviation in metrics from the standard.

(One can approximate a cubic spline with a series of quadratic splines, that's how font tools convert Type1/OTF to TTF, the result is good enough for the human eye, but technically it's not lossless. In your case absolutely no deviation is better than minimal deviations given the glyph sizes are standardised).

That's why generally speaking it's better to use OTF when evolving a Type1 font, except for legacy windows-oriented apps that understand TTF but not OTF. Linux systems do not care they have good support both for OTF and for TTF. Hardware has passed the point where computing cubics was significantly more expensive than computing quadratics a long time ago.

The spline part of OTF files is more compact than Type1. One is CFF2 the other is CFF1 — they are mathematically equivalent but the state of the art had improved between both specs (both written essentially by Adobe).

(In reply to David Kaspar [Dee'Kej] from comment #14)

> And as I mentioned in my previous comment, the ImageMagick also expects the
> Type1 /AFM fonts, and I expect there are some other applications might
> require it as well. Here's the list of packages requiring the old
> 'urw-fonts' package:
> 
> ghostscript-core
> grace
> GraphicsMagick
> graphviz
> htmldoc
> ipe
> libwmf
> mscgen
> pdf-renderer
> pokerth
> root-core
> synfig
> xpdf
> ImageMagick


All the usual suspects that concentrate "my text does not work" questions on Stack overflow…

Thanks for the explanation. That might help me to keep a little pressure on Ghostscript for them to move to OTF at some point. :)

(In reply to Nicolas Mailhot from comment #16)
> All the usual suspects that concentrate "my text does not work" questions on
> Stack overflow…

Heh, yeah. :D You've summed it up perfectly. I guess I should create a new tracking BZ in the future to track which of these apps now support OTF and which not.

David, OTF files would be useful also to be able to compile LilyPond (a music typesetting program, packaged in Fedora) without a warning:

WARNING: Please consider installing optional programs or files:  URW++ OTF fonts


These files are optional but it would be nice to have them.

Recent discussion on the subject is here:
http://lists.gnu.org/archive/html/lilypond-devel/2017-10/msg00141.html

Thanks for your efforts

Thank you Federico for the info. :)

Unfortunately, I'm currently really busy with my primary work responsibilities. I hope to look at this next week.

My guess is that this will land into F27 updates repo (too late for Final Freeze) and Rawhide. Is this okay for you?

Sure, no hurry here :)

Hey David, will you find the time for this in the next weeks?
Thanks in advance!

Hello Federico,

sorry for the delay. I'm actually working on Ghostscript package cleanup, which is kind of related to this. Once all issues (for both Ghostscript & urw-base35-fonts) are fixed I intend to release these packages at the same time.

I want to get this fixed ASAP, hopefully no later than start of Christmas. :)

Best regards,

 -- David --

The urw-base35-fonts isn't available in F26 anymore (it was unpushed from testing repository). However, the package is now available in F27.

I don't want to release the urw-base35-fonts (even with the fix for this) for F26. The risk of breaking something there is still high, and people now expect stability from F26, since the F27 is out.

Therefore my target on fixing this is in Fedora 27. I'm sorry for the inconvenience... :-/

thank you -0-

urw-base35-fonts-20170801-3.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-d6fb341f6d

(In reply to Nicolas Mailhot from comment #10)
> That's a poor situation to be in, but yes the minimum would be to ship the
> OpenType¹ versions as required by Fedora packaging guidelines, and maybe
> hide somewhere the Type1/AFM versions for GS private use (after asking
> Fesco). The first priority would be to avoid Ghostscript blocking progress
> in other apps that want to use those fonts. If that can help you in any way,
> you have my blessing, for the little it is worth.

So, to clarify few things:

 * The OTF format files are shipped now as well. I have decided to not create a special subpackage for the Type1/AFM files, even though I was considering it firstly. Creating this package would create a lot of confussion for many people out there, and given current state of the problem I didn't want to add oil into fire. The OTF files are not so big (for these days), so they are shipped right along the *.t1 and *.afm files.

 * I didn't go to FESco for permission, because it would be a waste of time for both me and them. There's not other solution at the moment so we could choose from. Current state is the one that I have to support if I don't want to break things for our users, and FESco approval doesn't have any significance right now for this case.

Anyway, please report any problems that you might find. Thank you! ;)

P.S.: I have merged the Nimbus Sans and Nimbus Sans Narrow, as you requested Nicolas. :)

Terrific, thanks a lot!

urw-base35-fonts-20170801-3.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-d6fb341f6d

urw-base35-fonts-20170801-4.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-74676ac3c1

urw-base35-fonts-20170801-4.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-74676ac3c1

urw-base35-fonts-20170801-4.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.