#935 Fonts packaging policy rewrite
Opened 3 months ago by nim. Modified 5 days ago

https://pagure.io/packaging-committee/pull-request/934

It should be clearer, more opinionated, and take into account:

– updates of The OpenType standard
– variable fonts
– web fonts
– upstream depreciation of non OpenType formats: final stages of the Harfbuzz
consolidation decided at the 2006 Text Layout summit
https://www.freedesktop.org/wiki/TextLayout/
– appstream & fonts
– weak dependencies
– and probably more I forget here

It is based on the new fonts-rpm-macros project for automation:
https://pagure.io/fonts-rpm-macros/

This project builds on tooling enhancements in redhat-rpm-config and rpm
itself, done during the past two years for the Forge and Go sets of packaging
macros. It started 2 years ago as a fork of fontpackages, which is the core of
our current fonts packaging guidelines.

It will require putting the fonts-srpm-macros package in the default build
root, like is done for other domain-specific packaging macro sets.

Major additions:
– better documentation (clearer and more complete)
– better automation (less packager hassle for better and more complete results)

Major removals:
– tools and scripts
– fixing metadata with ttname

Mostly because no one seems willing to maintain those scripts, or port ttname
to python 3.

https://copr.fedorainfracloud.org/coprs/nim/fonts-rpm-macros/builds/
showcases the new policy on 62 real-world source packages, generating 139 installation packages. Some of those are badly delayed updates to Fedora packages, others are brand-new packages ready for Fedora inclusion. They include major font packages such as Stix, DejaVu, Droid, IBM Plex.

Existing Fedora packages will continue to build, the old fontpackages macros are grandfathered in fonts-rpm-macros for now. They will be removed in a few years to give packagers time to apply the new guidelines.


Metadata Update from @james:
- Issue tagged with: meeting

3 months ago

We discussed this at this weeks meeting (https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2019-11-21/fpc.2019-11-21-17.00.txt):

...this will probably be on hold until early next year, as people don't have enough free time to look at it.

Given lack of quorum, going to try voting in the tickets ... +1 from me.

Added some of my 2¢s to the PR, but I might as well vote +1.

My concern is that the policy is enormously long and complicated to comprehend. I don't expect many people going:

  1. I want to package a font
  2. let's read the guidelines
  3. sure, this makes sense, I'll just follow it

And I am seriously afraid, it will be:

  1. I want to package a font
  2. let's read the guidelines
  3. oh my...
  4. I just gonna bundle this font file here and hope nobody notices.

Is it acceptable that fonts will only ever be packaged by experts?

We didn't have quorum again, but the four of us did talk about this ticket. You can see the full log here:

https://meetbot.fedoraproject.org/fedora-meeting-1/2020-02-06/fpc.2020-02-06-17.00.log.html

Basically there is concern that packagers are going to want to look at packaging a font, look at this policy and then run away ... either not packaging it, or just winging it and hoping nobody notices.

My impression was that for simple font packages it should be very simple for a packager to create a font pacakge, just putting files in the right place and filling in an example specfile ... and the macros will do all the complicated bits, but I haven't tried creating a font package and other members thought I might well be wrong.
Is my impression correct?
If so is it possible to change the policy to highlight this fact to anyone looking to package a font? Eg. an intro. showing how to simple package a font, and then all the complicated bits hidden behind an appendix that says "you shouldn't need to read/understand any of this for simple cases"
If my impression isn't true, then is the intention that only a very small number of people will be packaging fonts (basically experienced packagers who deeply understand all of this policy)? If so how would you feel about adding a warning to the policy along the lines of "if you want to package a font, you should really speak to someone in XYZ group/irc-channel to help you out instead of trying to understand this page directly?"

Hi,

I added a short foreword to address your concerns
https://pagure.io/fork/nim/packaging-committee/c/6d702f4056142606693e1ba7272d579fa87659ec

That being written.

The difficulty in packaging fonts is not the rpm part. At least, not using the proposed templates. As @james noted, you take the templates, fill in the blanks, and things are done¹. If font upstreams released files in a sane state packaging a font family would be 5 minutes of work, most of this work consisting of spell-checking the package description.

However, to answer @churchyard

  • you can not rely on font makers to release fonts in a software-friendly state today
  • you can not rely on font makers to release fonts in a software-friendly state in the future
  • other operating systems had to sort and fix their system fonts themselves
    • that’s why Windows system fonts work well in apps
    • that’s why half of the OpenType spec consists of Microsoft begging font makers to stop doing stupid software-hostile things
    • however font makers have collectively decided they do not care about software problems, and someone else will fix their stuff
  • we wasted a decade Fedora, free desktop and fontconfig side hoping for the problem to go away by itself
    • it didn’t
  • on the contrary it got worse as OpenType gained new capabilities
    • font makers abused them the same way they abused past ones
  • Google injected a lot of money in the system, and caused the creation of a lot of OFL fonts.
  • however Google does not care if those fonts do not work in desktop apps as long as they work on the web using complex CSS rules
  • removing the associated documentation won’t make the problem go away either
  • yes the situation is complex and may not fit packager expectations of simplicity. Guidelines should be tailored for real-world state not for expectations

Therefore, packaging fonts, does require some level of domain knowledge, to transform the raw material dumps produced by font makers into something useful desktop and server side. The need for this domain knowledge is not occasional, it’s systematic, it can not be handled in an appendix.

On the positive side, the spec deviations software trips on are mostly dead simple and stupid, you do not need expert-level domain knowledge to identify and manage them, just a lot of tedious but easy checking.

That’s why most of the proposed document is a long and tedious (but simple) checklist. Anyone can package fonts in a good state just using this checklist.

And yes, the checklist is long, and it would be awfully convenient if all font project failed at the same part of the list. They do not oblige. They fail because checking things is tedious, not because a specific part of the checklist is hard.

And I would really love for fontconfig to do more of this sanity testing and fixing automatically, making it possible to automate large parts of this checklist, but it does not today and @tagoh can tell you getting to this point is not a couple weeks of work his side.

¹ That FPC feels unable to merge simple “to do X use spec template Y” instructions in guidelines and requires inflicting multiple screenfulls of template rehashing on guideline readers contributes to the length of the document; however that’s not my decision.

@churchyard

I just gonna bundle this font file here and hope nobody notices.

People are already doing this. They will feel entitled to do this as long as the published guidelines provide no value to packagers. To provide value to packagers the guidelines have to be clear and help them produce working packages. Artificialy shortened guidelines are not helpful, they’re a waste of time for everyone involved.

If you want the guidelines to get shorter fonts-side, you need first, to feed more domain knowledge into fontconfig, second to make all first class apps like libreoffice actually use the fontconfig fixes, and third, to win enough market share that font makers notice and do the same fixing by themselves to avoid being let out.

That’s a long-term endeavour.

Thanks for the explanation. +1 in general.

We discussed this at this weeks meeting: https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2020-02-13/fpc.2020-02-13-17.00.txt

  • #935 Fonts packaging policy rewrite (geppetto, 17:07:52)
  • ACTION: Fonts packaging policy rewrite (+1:5, 0:0, -1:0) (geppetto,
    17:16:47)

Metadata Update from @james:
- Issue untagged with: meeting
- Issue assigned to tibbs
- Issue tagged with: writeup

13 days ago

Metadata Update from @tibbs:
- Issue priority set to: In Committee (was: Needs Review)

6 days ago

The macro package is now in the buildroot in F33 and F32. For F31, see https://bodhi.fedoraproject.org/updates/FEDORA-2020-296917559c. Sadly the rebase button doesn't work but I will merge the PR soon. (I don't want to get too far ahead of F31 here, so karma on the update is appreciated.)

Login to comment on this ticket.

Metadata