9:18 a.m.
Zdenek Dohnal wrote:
I am going to retire ghostscript-fonts package in F27 because its
fonts
are deprecated and replaced by urw-base35-fonts package.
NACK. They are _extra_ fonts:
http://git.ghostscript.com/?p=ghostpdl.git;a=blob_plain;f=Resource/Init/F...
9:39 a.m.
New subject: Removing ghostscript-fonts package
On Fri, Oct 6, 2017 at 4:18 PM, Xose Vazquez Perez <xose.vazquez(a)gmail.com>
wrote:
Zdenek Dohnal wrote:
> I am going to retire ghostscript-fonts package in F27 because its fonts
> are deprecated and replaced by urw-base35-fonts package.
NACK. They are _extra_ fonts:
http://git.ghostscript.com/?p=ghostpdl.git;a=blob_plain;f=
Resource/Init/Fontmap.GS
Well, the ghostscript-fonts might be *extra* fonts, but they are only being
used by 'hylafax+' package ATM. Ghostscript is *NOT* using these fonts
anymore. They are many years old (and outdated). These fonts are completely
irrelevant and obsoleted nowadays.
The Fontmap.GS you have shared actually uses fonts from urw-base35-fonts
package, not ghostscript-fonts. You would see the names mapping there if
you look closely.
I'm ACKing this request as the maintainer of ghostscript and
urw-base35-fonts.
-- Dee'Kej --
3:51 p.m.
New subject: Removing ghostscript-fonts package
On Fri, 6 Oct 2017, Xose Vazquez Perez wrote:
Zdenek Dohnal wrote:
> I am going to retire ghostscript-fonts package in F27 because its fonts
> are deprecated and replaced by urw-base35-fonts package.
I don't see a urw-base35-fonts SRPM in my RawHide ... has it
been packaged?
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 affected
-- Russ herrold
2:53 a.m.
New subject: Removing ghostscript-fonts package
Hi,
Thank you both for starting to clean up the awful mess that URW fonts had become over
time. It had come to the point they were totally unusable by anything but a few apps that
hardcoded them. They were tripping many many users (countless why *awful things* happen as
soon as I try to use one of the urw fonts in my app, it's time proven right ?)
The next step of course is to replace Postscript fonts with Opentype CFF versions (.otf),
since that's what most apps expect. The few apps that used to work with Postscript
fonts are getting sick of them (LibreOffice is filtering legacy font formats now for
example).
Since OpenType .otf versions ship CFF outlines like Postscript there is no risk of
breaking metric compatibility.
Nitpick: Fedora packages are supposed to group fonts by family. As Microsoft noted in its
WPF font model whitepaper, the CSS model and apps only know to manage weight, width or
slant qualifiers. So anything which is a weight, width or slant qualifier is a font face
name (in the same Fedora package), and anything else a different font family. Therefore
urw-base35-nimbus-sans-fonts and urw-base35-nimbus-sans-narrow-fonts should be merged
(narrow is a width qualifier). But even though splitting those what a mistake,
over-spitting is much better for users than under-splitting! (the 4 faces only thing is
actually another Postscript legacy limitation IIRC).
Regards,
--
Nicolas Mailhot
3:44 a.m.
New subject: Removing ghostscript-fonts package
On Fri, Oct 6, 2017 at 9:51 PM, R P Herrold <herrold(a)owlriver.com> wrote:
On Fri, 6 Oct 2017, Xose Vazquez Perez wrote:
> Zdenek Dohnal wrote:
>
> > I am going to retire ghostscript-fonts package in F27 because its fonts
> > are deprecated and replaced by urw-base35-fonts package.
I don't see a urw-base35-fonts SRPM in my RawHide ... has it
been packaged?
https://koji.fedoraproject.org/koji/packageinfo?packageID=24486
If you're just doing a dnf query you probably need to do urw-base35*
> 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 affected
>
> -- Russ herrold
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
7:37 a.m.
New subject: Removing ghostscript-fonts package
On Fri, Oct 6, 2017 at 10:51 PM, R P Herrold <herrold(a)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 --
9:17 a.m.
New subject: Removing ghostscript-fonts package
So, I have tried to rebuild 'hylafax+' with 'urw-base35-fonts' and it
passed:
https://koji.fedoraproject.org/koji/taskinfo?taskID=22352204
I suggest we rebase it newer version (5.5 -> 6.0.6 -- the latest stable
release is already 5 years old -- http://www.hylafax.org/content/Download),
rebuild it against 'urw-base35-fonts', and get it to Rawhide for testing.
-- Dee'Kej --
11:25 a.m.
New subject: Removing ghostscript-fonts package
----- Mail original -----
De: "David Kaspar [Dee'Kej]"
* 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.
Since I wrote those, I'd like to qualify this:
1. Fedora basic packaging principles for fonts are sound, since they are based around
fontconfig capabilities, OpenType capabilities, and the CSS model (mostly the same thing
since fontconfig is architectured around OpneType and the CSS font model). All of those
are pillars of any font-manipulating app in Fedora currently and in the near future. If
anything they've become stronger requirements since the guidelines were written. The
basic CSS font family is a set of faces that only differ in width, weight or slant.
Because apps can only apply width, weight or slant attributes to text (not serif or
sans-serif or whatever). Since in the past years some advanced apps have gained the
ability to select optional opentype features such as advanced ligatures, I'd tend to
think files that add those features also belong in the same font family.
2. Those principles are much better than the Debian ones of a few years ago, that reposed
on layers of custom Debian-specific metadata that was supposed to work with every possible
font system, working well with none, all very maintainer-intensive. I haven't checked
if Debian managed to sort this mess since. What I've seen of the Appstream font spec
reeks of the same metadata overlaying, and misunderstanding of the CSS font model. When
you reinvent the wheel you can redefine everything. Contrariwise, when you reinvent the
wheel you need to maintain your wheel ad vitam eternam + deal with every piece of code not
written around your square wheel. Apps are written around fontconfig and the CSS model,
not the appstream abstraction, even when developers do not realise it (the CSS model is
really pervasive, since it was defined by Microsoft around what monsters like Office did
at the time, and has been adopted by the web and web-derived techs since). Even TEX that
long stood for its own font model has switched to OpenType lately – gaining access to the
vast trove of OpenType fonts trumped being "better" with a limited font set.
3. Therefore, I would caution against anything that proposed abandoning the CSS font model
and redefined the font family/font faces split of the CSS model. A strength of our
guidelines is that our package split follows a logical font family split which is
understood both by users and the application code.
4. However there are many broken fonts out there. The metadata of actual font files may be
suboptimal upstream, requiring font packagers to understand the limits of ideal
(application-wise) font families, and fixing the metadata of the fonts we ship either by
patching the fonts of via fontconfig directives. This is a major PITA but we can't
avoid it if we want the fonts we ship to work well in apps. So :
– font files differ only in width, weight, slant, or optional OpenType features → same
font family, belongs in the same package
— font files differ in another stylistic attribute → different font families in practical
terms, the best and most advanced app will still treat them as different (even if they
have a close human name such as DejaVu Sans and DejaVu Serif)
– font files are split by encoding or region → they still are a logical unit that belongs
in a single package. Helping people install part of a font is a source of multiple bugs
(that disincentives checking that all the parts wall together, and is an i18n disaster)
– the metadata says otherwise, because of legacy technical limitations or because the font
author was confused → the metadata needs to be fixed, either by patching the font or via
fontconfig overrides (and past fontconfig maintainers worked with us to define good
templates for those)
Now, for the bad part of our font packaging:
— all Fedora font packages were not converted a few years ago. Some maintainers proved
resistant (gs is a good example) and I got tired of nagging them.
– it's been a long time anyone checked all the distro font packages. It's
unfortunately probable some FPG deviations have been introduced since, because the
packagers didn't understand the guidelines, were confused by broken upstream font
metadata, or cargo culted special font formats (most everything works with OpenType
nowadays, including CSS fonts. IE6 is deader than dead).
— someone need to figure an appstream style compatible with our guidelines, document it
and make it part of our packaging
– we couldn't go as far as I wanted last time due to rpm limitations. rpm has improved
a lot since. It would be worthwhile to revisit macros and scriptlets to take advantage of
new rpm features I think this does not require patching individual packages since the
macros are centralized in one place
— likewise, fontconfig improved. It would be nice to change the autoprovides to take the
fontconfig files shipped in the package into account, which was not possible in the past.
Right now rpm evaluates the font against minimal system fontconfig rules, that the package
itself is likely to override.
– a lot of the font packaging tooling was broken by the dnf migration, it needs refreshing
(I haven't found the time to do it yet, I suck loads, feel free to replace it with
something better).
– likewise the packaging templates need to be refreshed with general FPG changes of the
past years (nothing critical, just a general refresh).
Regards,
--
Nicolas Mailhot
7:39 p.m.
New subject: Removing ghostscript-fonts package
On Mon, Oct 9, 2017 at 10:17 AM, David Kaspar [Dee'Kej]
<dkaspar(a)redhat.com> wrote:
So, I have tried to rebuild 'hylafax+' with
'urw-base35-fonts' and it
passed:
https://koji.fedoraproject.org/koji/taskinfo?taskID=22352204
I suggest we rebase it newer version (5.5 -> 6.0.6 -- the latest stable
release is already 5 years old -- http://www.hylafax.org/content/Download),
rebuild it against 'urw-base35-fonts', and get it to Rawhide for testing.
-- Dee'Kej --
Ahh. That's a known source of confusion. HylaFAX++ Is a fork of
HylaFAX. It's much better maintained. HylaFAX++ is up to 5.5.9, over
at http://hylafax.sourceforge.net/. Lee Howard is the beneveloent
dictator over there. I reached out to him on the mailing list, and
he's following the thread. I'm sure he'll be delighted to know that it
passed, and I think we can rely on him seeing this thread to know to
test it on hardware that I don't have available.
7:21 a.m.
New subject: Removing ghostscript-fonts package
Sorry for the delay in reply, vacation... Anyway, back to work! :)
On Mon, Oct 9, 2017 at 6:25 PM, <nicolas.mailhot(a)laposte.net> wrote:
----- Mail original -----
De: "David Kaspar [Dee'Kej]"
> * 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.
Ah, darn it. Apparently I have oversimplified and didn't express myself
correctly. :-/
Since I wrote those, I'd like to qualify this:
1. Fedora basic packaging principles for fonts are sound, since they are
based around fontconfig capabilities, OpenType capabilities, and the CSS
model (mostly the same thing since fontconfig is architectured around
OpneType and the CSS font model). All of those are pillars of any
font-manipulating app in Fedora currently and in the near future. If
anything they've become stronger requirements since the guidelines were
written. The basic CSS font family is a set of faces that only differ in
width, weight or slant. Because apps can only apply width, weight or slant
attributes to text (not serif or sans-serif or whatever). Since in the past
years some advanced apps have gained the ability to select optional
opentype features such as advanced ligatures, I'd tend to think files that
add those features also belong in the same font family.
To clarify - the FPG for fonts is okay in principles. It just still
mentions some things that are no longer used in Fedora's specfiles, or some
things are not so clear when reading through them. IMHO, just a regular
cleanup/update in the wiki (and maybe unifying all the related wikis into
one) should be enough. :) If you wish, we could create a BlueJeans meeting
(open for everyone) to go through these guidelines and fix them together.
;) I unfortunately don't have right to edit the wiki, nor I want to mess
with something which you maintain(?).
2. Those principles are much better than the Debian ones of a few
years
ago, that reposed on layers of custom Debian-specific metadata that was
supposed to work with every possible font system, working well with none,
all very maintainer-intensive. I haven't checked if Debian managed to sort
this mess since. What I've seen of the Appstream font spec reeks of the
same metadata overlaying, and misunderstanding of the CSS font model. When
you reinvent the wheel you can redefine everything. Contrariwise, when you
reinvent the wheel you need to maintain your wheel ad vitam eternam + deal
with every piece of code not written around your square wheel. Apps are
written around fontconfig and the CSS model, not the appstream abstraction,
even when developers do not realise it (the CSS model is really pervasive,
since it was defined by Microsoft around what monsters like Office did at
the time, and has been adopted by the web and web-derived techs since).
Even TEX that long stood for its own font model has switched to OpenType
lately – gaining access to the vast trove of OpenType fonts trumped being
"better" with a limited font set.
Again, I'm OK with the principles, it's just some small things need update
in FPG, that's all. I don't want us to reinvent the wheel (again). I agree
that fontconfig is good way to go. The only reason why I created the
AppStream files is for the 'urw-base35-font's to be available in
Gnome-software if possible, so users can possibly preview them before
installing them. That's the only actuall benefit I see from AppStream files
for fonts in Fedora. (+1 for moving to OTF/TTF.)
3. Therefore, I would caution against anything that proposed
abandoning
the CSS font model and redefined the font family/font faces split of the
CSS model. A strength of our guidelines is that our package split follows a
logical font family split which is understood both by users and the
application code.
I'm not proposing abandoning what we have in Fedora. I would like to just
to have the FPG updated. For example IIRC, there was a suggestion somewhere
there, to use fontforge to display the font family, and then to use that
font family name for the font subpackage. However, this contradicts what
you wrote about the CSS model and the width/weight/slant. That's why I
think we should update the FPG and unite them. ;)
4. However there are many broken fonts out there. The metadata of
actual
font files may be suboptimal upstream, requiring font packagers to
understand the limits of ideal (application-wise) font families, and fixing
the metadata of the fonts we ship either by patching the fonts of via
fontconfig directives. This is a major PITA but we can't avoid it if we
want the fonts we ship to work well in apps. So :
– font files differ only in width, weight, slant, or optional OpenType
features → same font family, belongs in the same package
— font files differ in another stylistic attribute → different font
families in practical terms, the best and most advanced app will still
treat them as different (even if they have a close human name such as
DejaVu Sans and DejaVu Serif)
– font files are split by encoding or region → they still are a logical
unit that belongs in a single package. Helping people install part of a
font is a source of multiple bugs (that disincentives checking that all the
parts wall together, and is an i18n disaster)
– the metadata says otherwise, because of legacy technical limitations or
because the font author was confused → the metadata needs to be fixed,
either by patching the font or via fontconfig overrides (and past
fontconfig maintainers worked with us to define good templates for those)
I'm not aware of this being in FPG.
Now, for the bad part of our font packaging:
— all Fedora font packages were not converted a few years ago. Some
maintainers proved resistant (gs is a good example) and I got tired of
nagging them.
– it's been a long time anyone checked all the distro font packages. It's
unfortunately probable some FPG deviations have been introduced since,
because the packagers didn't understand the guidelines, were confused by
broken upstream font metadata, or cargo culted special font formats (most
everything works with OpenType nowadays, including CSS fonts. IE6 is deader
than dead).
— someone need to figure an appstream style compatible with our
guidelines, document it and make it part of our packaging
– we couldn't go as far as I wanted last time due to rpm limitations. rpm
has improved a lot since. It would be worthwhile to revisit macros and
scriptlets to take advantage of new rpm features I think this does not
require patching individual packages since the macros are centralized in
one place
— likewise, fontconfig improved. It would be nice to change the
autoprovides to take the fontconfig files shipped in the package into
account, which was not possible in the past. Right now rpm evaluates the
font against minimal system fontconfig rules, that the package itself is
likely to override.
– a lot of the font packaging tooling was broken by the dnf migration, it
needs refreshing (I haven't found the time to do it yet, I suck loads, feel
free to replace it with something better).
– likewise the packaging templates need to be refreshed with general FPG
changes of the past years (nothing critical, just a general refresh).
Again, could we schedule a meeting for all fonts maintainers to discuss
this, and update the FPG if needed? And maybe create some Fedora project
for this, and start working on these changes for F28?
===========
@Reindl - yes you're right, I juste learned about it after sending that
e-mail... :D So, right now we have the latest version of hylafax+ in
Fedora. :)
@Nico - that's good to hear. Anyway, the hylafax+ should be tested in
Rawhide first for stability issues.
8:33 a.m.
New subject: Removing ghostscript-fonts package
----- Mail original -----
De: "David Kaspar [Dee'Kej]"
If you wish, we could create a BlueJeans meeting
(open for everyone) to go through these guidelines and fix them together.
;) I unfortunately don't have right to edit the wiki, nor I want to mess
with something which you maintain(?).
I'm generally OK with people cleaning up in my place :) and will try to help if
someone sets un a cleanup session.
However as official guidelines they are locked (even against changes from the original
author). Changing them requires creating a draft of the changes somewhere else and then
asking FPC to replace the existing guidelines with the new version.
> I'm not proposing abandoning what we have in Fedora. I would like to just
to have the FPG updated. For example IIRC, there was a suggestion
somewhere
there, to use fontforge to display the font family, and then to use that
font family name for the font subpackage. However, this contradicts what
you wrote about the CSS model and the width/weight/slant. That's why I
think we should update the FPG and unite them. ;)
For "good" fonts using the name displayed in fontforge would be OK
For "broken" fonts fontforge will just display the broken metadata in the font
file.
Besides legacy formats like Postscript have very limited metadata possibilities, even
though fontconfig hides those from apps by emulating modern font naming even for legacy
fonts. So you need the naming as interpreted by fontconfig not the naming inside the font
files themselves.
And even then fontconfig does not autofix all the kinds of brokeness, it needs manual
declarations in fontconfig xml files to handle some of them. There was talk some years ago
to implement full naming autofixing in fontconfig, but unfortunately and IIRC it got
nowhere (the Microsoft WWS draft documents pretty completely the algorithm to implement,
and modern Microsoft font libs do implement it).
That's a pity because it would remove the need for manual fontconfig overrides except
in the most extreme cases, and the guidelines could be simplified in "just use the
font family naming as outputed by fontconfig".
> 4. However there are many broken fonts out there. The metadata
of actual
> font files may be suboptimal upstream, requiring font packagers to
> understand the limits of ideal (application-wise) font families, and fixing
> the metadata of the fonts we ship either by patching the fonts of via
> fontconfig directives. T
> I'm not aware of this being in FPG.
It is in FPG (the short § about font families). Much more succinctly, because I was less
aware at the time of the many ways people choose to misinterpret that, and refuse to read
the numerous detailed Adobe and Microsoft documents that describe OpenType naming best
practices and why deviating from them breaks some application workflows.
> Again, could we schedule a meeting for all fonts maintainers to discuss
this, and update the FPG if needed? And maybe create some Fedora
project
for this, and start working on these changes for F28?
Sure, there are no huge technical problems, it's just a lot of tedious cleanup work,
and the more the merrier for this kind of activity.
Regards,
--
Nicolas Mailhot
10:12 a.m.
New subject: Removing ghostscript-fonts package
Based on this thread, I will retire now this package.
--
Zdenek Dohnal
Associate Software Engineer
Red Hat Czech - Brno TPB-C
5:24 a.m.
New subject: Removing ghostscript-fonts package
On Mon, Nov 6, 2017 at 5:12 PM, Zdenek Dohnal <zdohnal(a)redhat.com> wrote:
Based on this thread, I will retire now this package.
That's should be save to do IMHO:
*
https://src.fedoraproject.org/rpms/hylafax+/c/4886f02ec6327a54488750acf4b...
* https://bodhi.fedoraproject.org/updates/FEDORA-2017-b20e04f6ce
Thanks! :)
-- Dee'Kej --
2353
days inactive
2387
days old
12 comments
7 participants
participants (7)
-
David Kaspar [Dee'Kej] -
Nico Kadel-Garcia -
nicolas.mailhot＠laposte.net -
Peter Robinson -
R P Herrold -
Xose Vazquez Perez -
Zdenek Dohnal