#934 Fonts packaging policy rewrite
Opened a month ago by nim. Modified 8 days ago
nim/packaging-committee fonts-rpm-macros  into  master

@@ -0,0 +1,91 @@ 

+ # Packaging template: basic single-family fonts packaging.

+ #

+ # SPDX-License-Identifier: MIT

+ #

+ # This template documents the minimal set of spec declarations, necessary to

+ # package a single font family, from a single dedicated source archive.

+ #

+ # It is part of the following set of packaging templates:

+ # “fonts-0-simple”: basic single-family fonts packaging

+ # “fonts-1-full”:   less common patterns for single-family fonts packaging

+ # “fonts-2-multi”:  multi-family fonts packaging

+ # “fonts-3-sub”:    packaging fonts, released as part of something else

+ #

+ # A font family is composed of font files, that share a single design, and

+ # differ ONLY in:

+ # — Weight        Bold, Black…

+ # – Width∕Stretch Narrow, Condensed, Expanded…

+ # — Slope/Slant   Italic, Oblique

+ # Optical sizing  Caption…

+ #

+ # Those parameters correspond to the default axes of OpenType variable fonts:

+ # https://docs.microsoft.com/en-us/typography/opentype/spec/dvaraxisreg#registered-axis-tags

+ # The variable fonts model is an extension of the WWS model described in the

+ # WPF Font Selection Model whitepaper (2007):

+ # https://msdnshared.blob.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Components.PostAttachments/00/02/24/90/36/WPF%20Font%20Selection%20Model.pdf

+ #

+ # Do not rely on the naming upstream chose, to define family boundaries, it

+ # will often be wrong.

+ #

+ # Declaration order is chosen to limit divergence between those templates, and

+ # simplify cut and pasting.

+ #

+ Version: 

+ Release: 

+ URL:     

+ 

+ # The identifier of the entity, that released the font family.

+ %global foundry           

+ # The font family license identifier. Adjust as necessary. The OFL is our

+ # recommended font license.

+ %global fontlicense       OFL

+ #

+ # The following directives are lists of space-separated shell globs

+ #   – matching files associated with the font family,

+ #   – as they exist in the build root,

+ #   — at the end of the %build stage:

+ # – legal files (licensing…)

+ %global fontlicenses      OFL.txt

+ # – documentation files

+ %global fontdocs          *.txt

+ # – exclusions from the ”fontdocs” list

+ %global fontdocsex        %{fontlicenses}

+ 

+ # The human-friendly font family name, whitespace included, restricted to the

+ # the Basic Latin Unicode block.

+ %global fontfamily        

+ %global fontsummary       

+ #

+ # More shell glob lists:

+ # – font family files

+ %global fonts             *.otf

+ # – fontconfig files

+ %global fontconfs         %{SOURCE10}

+ #

+ # A multi-line description block for the generated package.

+ %global fontdescription   %{expand:

+ }

+ 

+ Source0:  

+ # Adjust as necessary. Keeping the filename in sync with the package name is a good idea.

+ # See the fontconfig templates in fonts-rpm-templates for information on how to

+ # write good fontconfig files and choose the correct priority [number].

+ Source10: [number]-%{fontpkgname}.conf

+ 

+ %fontpkg

+ 

+ %prep

+ %setup

+ 

+ %build

+ %fontbuild

+ 

+ %install

+ %fontinstall

+ 

+ %check

+ %fontcheck

+ 

+ %fontfiles

+ 

+ %changelog

@@ -0,0 +1,95 @@ 

+ # Packaging template: less common patterns for single-family fonts packaging.

+ #

+ # SPDX-License-Identifier: MIT

+ #

+ # This template documents less common spec declarations, used when packaging a

+ # single font family, from a single dedicated source archive.

+ #

+ # It is part of the following set of packaging templates:

+ # “fonts-0-simple”: basic single-family fonts packaging

+ # “fonts-1-full”:   less common patterns for single-family fonts packaging

+ # “fonts-2-multi”:  multi-family fonts packaging

+ # “fonts-3-sub”:    packaging fonts, released as part of something else

+ #

+ Version: 

+ Release: 

+ URL:     

+ 

+ %global foundry           

+ %global fontlicense       OFL

+ #

+ # The following directives are lists of space-separated shell globs

+ #   – matching files associated with the font family,

+ #   – as they exist in the build root,

+ #   — at the end of the %build stage:

+ # – legal files (licensing…)

+ %global fontlicenses      OFL.txt

+ # – exclusions from the “fontlicenses” list

+ %global fontlicensesex    

+ # – documentation files

+ %global fontdocs          

+ # – exclusions from the “fontdocs” list

+ %global fontdocsex        %{fontlicenses}

+ 

+ %global fontfamily        

+ %global fontsummary       

+ # A container for additional subpackage declarations.

+ %global fontpkgheader     %{expand:

+ Obsoletes: 

+ }

+ #

+ # More shell glob lists:

+ # – font family files

+ %global fonts             

+ # – exclusions from the “fonts” list)

+ %global fontsex           

+ # – fontconfig files

+ %global fontconfs         %{SOURCE10}

+ # – exclusions from the “fontconfs” list

+ %global fontconfsex       

+ # – appstream files, if any (generated automatically otherwise)

+ %global fontappstreams    

+ # – exclusions from the “fontappstreams” list

+ %global fontappstreamsex  

+ #

+ %global fontdescription   %{expand:

+ }

+ 

+ Source0:  

+ Source10: [number]-%{fontpkgname}.conf

+ 

+ %fontpkg

+ 

+ # Font creators love to bundle bulky documentation files, that show off their

+ # font (typically, as pdf specimens). Split those files in a dedicated optional

+ # doc package.

+ %package   doc

+ Summary:   %{name} optional documentation files

+ BuildArch: noarch

+ %description doc

+ This package provides optional documentation files shipped with %{name}.

+ 

+ %prep

+ %setup

+ # Convert upstream files to UTF-8 and Unix end of lines if necessary

+ # Optional arguments:

+ # -e [encoding] source OS encoding (auto-detected otherwise)

+ # -n            do not recode files, only adjust folding and end of lines

+ %linuxtext *.txt

where's this macro coming from?

+ 

+ %build

+ %fontbuild

+ 

+ %install

+ %fontinstall

+ 

+ %check

+ %fontcheck

+ 

+ %fontfiles

+ 

+ %files doc

+ %license OFL.txt

+ %doc *.pdf

+ 

+ %changelog

@@ -0,0 +1,132 @@ 

+ # Packaging template: multi-family fonts packaging.

+ #

+ # SPDX-License-Identifier: MIT

+ #

+ # This template documents spec declarations, used when packaging multiple font

+ # families, from a single dedicated source archive. The source rpm is named

+ # after the first (main) font family). Look up “fonts-3-sub” when the source

+ # rpm needs to be named some other way.

+ #

+ # It is part of the following set of packaging templates:

+ # “fonts-0-simple”: basic single-family fonts packaging

+ # “fonts-1-full”:   less common patterns for single-family fonts packaging

+ # “fonts-2-multi”:  multi-family fonts packaging

+ # “fonts-3-sub”:    packaging fonts, released as part of something else

+ #

+ Version: 

+ Release: 

+ URL:     

+ 

+ # The following declarations will be aliased to [variable]0 and reused for all

+ # generated *-fonts packages unless overriden by a specific [variable][number]

+ # declaration.

+ %global foundry           

+ %global fontlicense       

+ %global fontlicenses      

+ %global fontlicensesex    

+ %global fontdocs          

+ %global fontdocsex        %{fontlicenses}

+ 

+ # A text block that can be reused as part of the description of each generated

+ # subpackage.

+ %global common_description %{expand:

+ }

+ 

+ # Declaration for the subpackage containing the first font family. Also used as

+ # source rpm info. All the [variable]0 declarations are equivalent and aliased

+ # to [variable].

+ 

+ %global fontfamily0       

+ %global fontsummary0      

+ %global fontpkgheader0    %{expand:

+ }

+ %global fonts0            

+ %global fontsex0          

+ %global fontconfs0        %{SOURCE10}

+ %global fontconfsex0      

+ %global fontappstreams0   

+ %global fontappstreamsex0 

+ %global fontdescription0  %{expand:

+ %{common_description}

+ Additional text…}

+ 

+ # Declaration for the subpackage containing the second font family.

+ %global fontfamily1       

+ %global fontsummary1      

+ %global fontpkgheader1    %{expand:

+ }

+ %global fonts1            

+ %global fontsex1          

+ %global fontconfs1        %{SOURCE11}

+ %global fontconfsex1      

+ %global fontappstreams1   

+ %global fontappstreamsex1 

+ %global fontdescription1  %{expand:

+ %{common_description}

+ Other Additional text…}

+ #

+ # Continue as necessary…

+ 

+ Source0:  

+ Source10: [number]-%{fontpkgname0}.conf

+ Source11: [number]-%{fontpkgname1}.conf

+ 

+ # “fontpkg” will generate the font subpackage headers corresponding to the

+ # elements declared above.

+ # “fontpkg” accepts the following selection arguments:

+ # – “-a”          process everything

+ # – “-z [number]” process a specific declaration block

+ # If no flag is specified it will only process the zero/nosuffix block.

+ %fontpkg -a

+ 

+ # “fontmetapkg” will generate a font meta(sub)package header for all the font

+ # subpackages generated in this spec. Optional arguments:

+ # – “-n [name]”      use [name] as metapackage name

+ # – “-s [variable]”  use the content of [variable] as metapackage summary

+ # – “-d [variable]”  use the content of [variable] as metapackage description

+ # – “-z [numbers]”   restrict metapackaging to [numbers] comma-separated list

+ #                    of font package suffixes

+ %fontmetapkg

+ 

+ %package   doc

+ Summary:   %{name} optional documentation files

+ BuildArch: noarch

+ %description doc

+ This package provides optional documentation files shipped with %{name}.

+ 

+ %prep

+ %setup

+ %linuxtext *.txt

+ 

+ %build

+ # “fontbuild” accepts the usual selection arguments:

+ # – “-a”          process everything

+ # – “-z [number]” process a specific declaration block

+ # If no flag is specified it will only process the zero/nosuffix block.

+ %fontbuild -a

+ 

+ %install

+ # “fontinstall” accepts the usual selection arguments:

+ # – “-a”          process everything

+ # – “-z [number]” process a specific declaration block

+ # If no flag is specified it will only process the zero/nosuffix block.

+ %fontinstall -a

+ 

+ %check

+ # “fontcheck” accepts the usual selection arguments:

+ # – “-a”          process everything

+ # – “-z [number]” process a specific declaration block

+ # If no flag is specified it will only process the zero/nosuffix block.

+ %fontcheck -a

+ 

+ # “fontfiles” accepts the usual selection arguments:

+ # – “-a”          process everything

+ # – “-z [number]” process a specific declaration block

+ # If no flag is specified it will only process the zero/nosuffix block

+ %fontfiles -a

+ 

+ %files doc

+ %license 

+ %doc 

+ 

+ %changelog

@@ -0,0 +1,108 @@ 

+ # Packaging template: packaging fonts, released as part of something else

+ #

+ # SPDX-License-Identifier: MIT

+ #

+ # This template documents spec declarations, used when packaging one or several

+ # font families from a source rpm which is not named after the first packaged

+ # font family:

+ # – either because the project name differs from the main font family name

+ # – or when the source archive and rpm are used to package more than fonts.

+ #

+ # It is part of the following set of packaging templates:

+ # “fonts-0-simple”: basic single-family fonts packaging

+ # “fonts-1-full”:   less common patterns for single-family fonts packaging

+ # “fonts-2-multi”:  multi-family fonts packaging

+ # “fonts-3-sub”:    packaging fonts, released as part of something else

+ #

+ # The packaging style is identical to the one documented in “fonts-2-multi”,

+ # EXCEPT it should not use the zero/nosuffix declaration block, as this block

+ # will attempt to generate source rpm declarations by default.

+ #

+ # Usually appropriate for fonts-only packages

+ BuildArch: noarch

+ 

+ Version: 

+ Release: 

+ License: 

+ URL:     

+ 

+ %global foundry           

+ # If different from the main License

+ %global fontlicense       

+ %global fontlicenses      

+ %global fontlicensesex    

+ %global fontdocs          

+ %global fontdocsex        %{fontlicenses}

+ 

+ %global common_description %{expand:

+ }

+ 

+ %global fontfamily1       

+ %global fontsummary1      

+ %global fontpkgheader1    %{expand:

+ }

+ %global fonts1            

+ %global fontsex1          

+ %global fontconfs1        %{SOURCE11}

+ %global fontconfsex1      

+ %global fontappstreams1   

+ %global fontappstreamsex1 

+ %global fontdescription1  %{expand:

+ %{common_description}

+ Additional text…}

+ 

+ %global fontfamily2       

+ %global fontsummary2      

+ %global fontpkgheader2    %{expand:

+ }

+ %global fonts2            

+ %global fontsex2          

+ %global fontconfs2        %{SOURCE12}

+ %global fontconfsex2      

+ %global fontappstreams2   

+ %global fontappstreamsex2 

+ %global fontdescription2  %{expand:

+ %{common_description}

+ Other Additional text…}

+ #

+ # Continue as necessary…

+ 

+ Source0:  

+ Source11: [number]-%{fontpkgname1}.conf

+ Source12: [number]-%{fontpkgname2}.conf

+ 

+ Name:     

+ Summary:  

+ %description

+ %wordwrap -v common_description

+ 

+ %fontpkg -a

+ 

+ %fontmetapkg

+ 

+ %package   doc

+ Summary:   %{name} optional documentation files

+ BuildArch: noarch

+ %description doc

+ This package provides optional documentation files shipped with %{name}.

+ 

+ %prep

+ %setup

+ %linuxtext *.txt

+ 

+ %build

+ %fontbuild -a

+ 

+ %install

+ %fontinstall -a

+ 

+ %check

+ %fontcheck -a

+ 

+ %fontfiles -a

+ 

+ %files doc

+ %license 

+ %doc 

+ 

+ %changelog

@@ -1,156 +1,810 @@ 

- === Legal considerations

+ = Fonts

+ :toc:

+ :toclevels: 4

+ 

+ <<Checklist>> lists requirements for packaging font files in Fedora, in a short and easy to check form. <<Exceptions>> lists special requirements. <<Tooling>> documents how to implement those requirements with the minimum packager effort. <<Rationale>> explains some guideline requirements.

+ 

+ == Checklist

+ 

+ === Legal

+ 

+ * [x] Font files MUST comply with our https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Font_Licenses[licensing rules].

+ * [x] Trademark uses MUST be authorized by their owners,

+ ** trademarks may occur in font naming or font content (logos…).

+ * [x] Registered names or trademarks MUST NOT prevent downstream modifications,

+ ** requiring a rename on significant modification is acceptable.

+ 

+ === Packaging unit: an ideal font family

+ 

+ Because fonts upstreams are, on average, extremely messy, a large part of packaging fonts involves sorting files and fixing font file metadata to produce the consistent and reliable font catalog expected by applications and users.

+ 

+ [IMPORTANT]

+ ====

+ .Font family

+ A **font family** is composed of *font files, that share a single design, and differ ONLY in*:

+ [horizontal]

+ Weight:: Bold, Black…

+ Width∕Stretch:: Narrow, Condensed, Expanded…

+ Slope/Slant:: Italic, Oblique

+ https://developer.microsoft.com/en-us/microsoft-edge/testdrive/demos/variable-fonts/#font-optical-sizing[Optical sizing]:: Caption…

+ 

+ Those parameters correspond to the https://docs.microsoft.com/en-us/typography/opentype/spec/dvaraxisreg#registered-axis-tags[default axes] of OpenType variable fonts. The variable fonts model is an extension of the **WWS** model described in the https://msdnshared.blob.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Components.PostAttachments/00/02/24/90/36/WPF%20Font%20Selection%20Model.pdf[WPF Font Selection Model] whitepaper (2007).

+ ====

+ 

+ * [x] Packagers MUST apply the definition provided in this section to determine font family boundaries,

+ ** it takes precedence over application support concerns, over upstream and packager habits and practices.

+ 

+ See also the <<Fontconfig>> section.

+ 

+ === Font file formats

+ 

+ [NOTE]

+ ====

+ .OpenType: one standard, five formats

+ https://en.wikipedia.org/wiki/OpenType[OpenType] uses an _SFNT_ container around bitmaps (`+*.otb+`) and outlines in _TT_ (`+*.ttf+`) or _CFF_ (`+*.otf+`) formats. Multiple fonts can be consolidated in a single collection (`+*.ttc+` or `+*.otc+`).

+ ====

+ 

+ * [x] Font packages MUST contain font files in OpenType formats.

+ * [x] Other font formats MUST be converted to OpenType,

+ ** except for fonts, intended to be used in the console (NOT a terminal emulator): see <<Bitmap console fonts>>.

+ 

+ [NOTE]

+ ====

+ .Font packages

+ A *font package*, is an installation (RPM) package, containing OpenType font files. It MAY be produced by a source (SRPM) package, that also produces other (font or non-font) packages. Other kinds of font packages are out of scope for this document.

+ ====

+ 

+ * [x] A font family MUST NOT be packaged in multiple or mixed OpenType formats,

+ ** except for variable font data,

+ ** except when mixing is required, to achieve full symbol (glyph) coverage,

+ ** except as an application workaround; see <<Packaging a font family in multiple OpenType formats; application support>>.

+ * [x] Both variable and non-variable OpenType font files, SHOULD be packaged, for a given font family.

+ * [x] OpenType format mixing SHOULD be justified in a comment within the `spec` file.

+ * [x] OpenType collection formats SHOULD be avoided.

+ 

+ === Fontconfig

+ 

+ * [x] Font packages SHOULD include the fontconfig files, that define the selection and substitution rules applying to their font files,

+ ** written by the packager if upstream does not provide them.

+ * [x] Fontconfig rules MUST rewrite `family` and `style` when they are not compliant with https://docs.microsoft.com/en-us/typography/opentype/spec/name#name-ids[OpenType WWS] rules:

+ ** `family` MUST NOT contain _Weight_, _Width_ or _Slope_ attributes (ideal WWS family name, Name ID 21),

+ ** `style` MUST contain only _Weight_, _Width_ or _Slope_ attributes (ideal WWS subfamily name, Name ID 22),

+ ** refer to the  https://msdnshared.blob.core.windows.net/media/MSDNBlogsFS/prod.evol.blogs.msdn.com/CommunityServer.Components.PostAttachments/00/02/24/90/36/WPF%20Font%20Selection%20Model.pdf[WPF Font Selection Model] whitepaper for extensive WWS attribute documentation,

+ **  Name ID 21 & 22 fields may exist or not in the packaged font files, and may be correct or not. The packager MUST set the correct value at the fontconfig level if the value fontconfig extracts from font files is incorrect.

+ * [x] Fontconfig rules MUST rewrite `family` to remove format attributes when they exist,

+ ** for exemple: `OT`, `TT`, `Variable`, `Graphite`, `G`, etc,

+ ** except when <<Packaging a font family in multiple OpenType formats; application support>>; in that case the removal MUST only be done for the font package providing the default format.

+ * [x] Fontconfig rules MUST rewrite `family` to remove coverage attributes when they exist,

+ ** for exemple: `Math`, `Emoji`, `Color Emoji`, `Hebrew`, `Arabic`, `Thai`, `LGC`, etc,

+ ** except when several font files provide the same coverage, requiring a qualifier to distinguish between them; in that case the removal MUST be done for the default file, and other files MUST be treated as parts of separate font families.

+ * [x] Fontconfig rules MUST rewrite `fullname` to `<family> <style>` if it has a different value,

+ ** either natively or as a result of previous rewrites,

+ ** except for the default style, usually `Regular`, for which `fullname` = `<family>`.

+ * [x] Fontconfig rules MUST rewrite `fontversion` when several font files provide the same `fullname` and have overlapping coverage,

+ ** either natively or as a result of previous rewrites,

+ ** fontconfig will merge the result, higher `fontversion` taking precedence over lower,

+ ** therefore, `fontversion` MUST be set by the packager, to define the correct ordering.

+ * [x] Fontconfig rules SHOULD define the generic family, a font contributes to,

+ ** a single generic family: the packager MUST choose,

+ ** using the correct priority: lower takes precedence over higher.

+ * [x] Fontconfig rules SHOULD list what other font families, the provided font family can substitute for.

+ ** typically, anterior namings, known forks, alternatives with the same font metrics…

+ ** also, the reused fonts families when <<Assembling different-family font packages: partial designs>>.

+ * [x] Fontconfig rules SHOULD define the font families, that can be used to complete the font family,

+ ** in all cases: at least the generic family and the substitutes defined before,

+ ** generic family last in completion order.

+ * [x] Packagers SHOULD attempt upstreaming those fixes,

+ ** make the font naming correct in the upstream font files,

+ ** contribute the other fontconfig rules upstream, so they are distributed with the font files.

+ * [x] Packagers SHOULD consult the fontconfig https://src.fedoraproject.org/rpms/fontconfig/[maintainer] and https://lists.freedesktop.org/mailman/listinfo/fontconfig[mailing list] when in doubt,

+ ** to get guidance and identify real-world tricky cases that call for fontconfig evolutions.

+ 

+ See also the <<Tooling>> section for fontconfig syntax guidance.

+ 

+ === Source (SRPM) package break-up

+ 

+ * [x] Separate source archives MUST be packaged in separate `spec` files,

+ ** except when those contain parts of the same font family and upstream coordinates their release.

+ * [x] `spec` files SHOULD track a single font family,

+ ** except when distinct font families are only released upstream in a common archive.

+ * [x] Packagers SHOULD ask upstream to split unrelated font families in separate versioned source archives,

+ ** and package font families from their actual respective upstreams when they are bundled with other material in a third party project.

+ 

+ === Installation (RPM) package break-up: font packages

+ 

+ * [x] Packagers MUST ship each font family in a single dedicated font package,

+ ** all the files that, after fontconfig fixing,

+ *** share the same `family` value: `family` = `<common family>`

+ *** or differ only in optical sizing: `family` = `<common family> <optical sizing attribute>`,

+ ** except when released as un-coordinated sources, that are easier to track in separate `spec` files,

+ ** except for huge families, that consume a lot of storage space; huge font families MAY be broken up in coverage-specific font packages,

+ ** see <<Assembling same-family font packages>>.

+ * [x] Font packages MUST limit themsemselves to OpenType font files and their associated https://www.fontconfig.org/[fontconfig], https://www.freedesktop.org/software/appstream/docs/sect-Metadata-Fonts.html[appstream], legal and documentation files,

+ ** for reasonable non-bulky interpretations of documentation files.

+ 

+ See also the <<Tooling>> section.

+ 

+ [IMPORTANT]

+ ====

+ .Other upstream files

+ 

+ Support for other font systems, for specific applications, non-OpenType font formats, bulky documentation, TEX, CSS, or JSON files… MUST be split in separate non-font packages, that SHOULD install outside `/usr/share/fonts`, and MUST NOT use `_<something>_-fonts` naming.

+ 

+ For compatibility reasons, OpenType font files MAY be exposed outside `/usr/share/fonts`, with the rest of upstream files, using symbolic links. Those symbolic links SHOULD NOT be installed by the font package itself.

+ ====

+ 

+ === Building

+ 

+ * [x] Packagers SHOULD build font files from sources,

+ ** whenever their prefered modification format is not the packaged OpenType format

+ ** and if the required toolchain is available as free software under Linux

+ 

+ === Dependencies in font packages

+ 

+ * [x] Font packages MAY require or supplement other font packages, when they contain the same font family,

+ ** as defined in <<Assembling same-family font packages>>.

+ * [x] Font packages SHOULD recommend other font packages, when they contain a reused font family,

+ ** as defined in <<Assembling different-family font packages: partial designs>>.

+ * [x] Font packages SHOULD suggest other font packages, when they contain a better version of the same font family,

+ ** better: more complete coverage, later enhanced fork, canonical version of the design…

+ * [x] Font packages MAY suggest or enhance font packages, containing other font families,

+ ** this should be used sparsely, to avoid imposing packager preferences on users.

+ * [x] Font packages SHOULD depend on the basic font support package set, defined in the font packaging templates and macros.

+ * [x] Except for the preceding, font packages MUST NOT depend, in any form, on any other package.

+ 

+ === Dependencies to font packages in other packages

+ 

+ * [x] Non-font packages MAY suggest or recommend font packages,

+ ** the weakest `Suggests` form is preferred over `Recommends`, except in presence of strong pre-existing user habits.

+ * [x] Non-font packages SHOULD use the `font()` namespace to depend on font packages.

+ * [x] Non-font packages SHOULD NOT require specific font packages, and leave font selection to end-users,

+ ** except when the packaged software actually relies on those specific font packages,

+ ** except for convenience font metapackages, as defined in <<Assembling different-family font packages: font metapackages>>.

+ * [x] Non-font packages MAY require font packages by name, when relying on specific on-disk font file paths,

+ ** ie when software is not `fontconfig`-aware,

+ ** however, there is no obligation for font packagers to keep those paths stable between releases. Font file formats are flexible, making any on-disk file layout temporary. Converting applications to fontconfig use is best.

+ 

+ === Assembling different-family font packages: partial designs

+ 

+ [NOTE]

+ ====

+ .Font reuse and font extension

+ 

+ Because font creation is hard work, font designers will often publish partial new designs:

+ 

+ * they will copy part of an existing design, then add to it; this is common practice when designing a non-latin-oriented font family – the latin core is taken from an existing family,

+ * or they will publish their additions as a separate font family, documenting it should be used with the original family; this is common practice when publishing alternate designs for part of a font.

+ ====

+ 

+ When packaging such a partial design:

+ 

+ * [x] The font package containing the new font family SHOULD recommend the package containing the original font family,

+ ** only the core package of the original font family in case of <<Assembling same-family font packages>>.

+ * [x] Re-use recommendations SHOULD use the `font()` namespace.

+ 

+ === Assembling different-family font packages: font metapackages

+ 

+ * [x] Packagers MAY provide convenience font metapackages,

+ ** for example, when an upstream releases a collection of font families, intended to be used together,

+ ** a common case is matched _serif_, _sans-serif_ and _monospaced_ font families.

+ * [x] Font metapackages MUST NOT use the same naming conventions as actual font packages,

+ ** they MUST NOT be named `_<something>_-fonts`,

+ ** they MAY be named `_<something>_-fonts-all`.

+ * [x] Font metapackages MUST require, recommend or suggest separate font packages, that conform to this document,

+ * [x] Font metapackages SHOULD use the `font()` namespace to require, recommend or suggest actual font packages,

+ ** see <<Dependencies to font packages in other packages>>.

+ * [x] Font metapackages SHOULD NOT contain any other file, except for documentation.

  

- The FLOSS font scene is still too young to have evolved common licensing conventions. As a result packaging fonts will often require more legal work than packaging your average FLOSS app. Before you continue, check our https://fedoraproject.org/wiki/Legal_considerations_for_fonts[legal page].

+ == Exceptions

  

-  +

-  +

+ === Bitmap console fonts

  

- === Package layout for fonts

+ * [x] Bitmap console fonts MAY be packaged in a legacy font format, understood by http://www.kbd-project.org/[kbd].

+ * [x] Bitmap console fonts MUST be installed in `/usr/share/consolefonts/` not `/usr/share/fonts`.

+ * [x] Bitmap console font packages SHOULD be named `_<something>_-fonts-console` not `_<something>_-fonts`.

  

- .  Fonts released upstream in separate archives *MUST* be packaged in separate source packages (_src.rpm_), unless they belong to the same font family.

- .  Packagers *SHOULD* ask upstream to release each font family in a separate versioned archive, when it bundles in a common release archive:

- ..  fonts with other material such as application code, or

- ..  different font families.

- * As an exception, when a project is the upstream of several font families, which are all licensed the same way, and released on the same date, with the same version, the use of a common release archive is tolerated.

- .  Packagers *MUST* package each font family in a separate (_noarch.rpm_) (sub)package, notwithstanding on how they applied the previous source package (_src.rpm_) rules. The only admitted exceptions are:

- ..  source packages that only include one font family and no other code or content (font documentation excepted), in which case a simple package is fine,

- ..  font families which are designed to extend other font families with larger Unicode coverage (for example _Arial Unicode_, _Droid Sans Fallback_), in which case grouping the font family and its extension in a single (sub)package is acceptable.

- * such cases should be notified to the fontconfig maintainer and the Fedora https://fedoraproject.org/wiki/Fonts_SIG_mailing_lists[fonts list], so the font family split can be eventually hidden from users.

- ..  fonts that use a format that bundles different font families in a single file.

- .  On the other hand, the different faces of a font family *MUST* be packaged together in a common (_noarch.rpm_) (sub)package, and not spread over different (sub)packages

+ [NOTE]

+ ====

+ .Console fonts

+ As long as http://www.kbd-project.org/[kbd] and https://www.freedesktop.org/software/systemd/man/vconsole.conf.html[systemd-vconsole] can not use the same file formats as the rest of the system, bitmap console fonts are effectively private kbd resources. They will be ignored in the rest of this document. It does not apply to them.

+ ====

  

- *Rationale:*

+ === Assembling same-family font packages

  

- As noted in the xref:index.adoc#bundling[Packaging Guidelines], Fedora packages should make every effort to avoid having multiple, separate, upstream projects bundled together in a single package. This applies equally to font packages.

+ * [x] A font family MUST NOT be split over several font packages, unless one of the exceptions listed above applies.

  

- Multi-source packages are difficult to maintain and confusing to users. In addition, fonts are comparatively bulky, and big font packages will be blacklisted from live-cds and by low-bandwidth users.

+ When a font family is split over a set of several font packages:

  

- The functional font unit for users is the font family. Users don't understand partially installed fonts (font faces spread over different packages) and bundles (multi-family packages that force them to install fonts they may not care of or even like just to get the other fonts in the package). Because it is a unit, projects will extend or fork a font family as a whole, but not necessarily in step with other bundled families.

+ * [x] Involved packagers MUST choose a core font package.

+ * [x] This core package SHOULD contain the font files, necessary to provide a minimal scope of the font family.

+ * [x] This core package MAY contain fontconfig rules, for all the font files composinng the font family,

+ ** fontconfig ignores rules that do not match installed files.

+ * [x] This core package MUST be named as if it contained the whole font family.

+ * [x] This core package MUST NOT require any other package in the set.

+ * [x] The other packages of the set MUST require, directly or indirectly, this core package.

+ * [x] The other packages of the set MUST supplement, directly or indirectly, this core package.

+ * [x] The other packages of the set MUST NOT use the `font()` namespace to require or supplement other parts of the set,

+ ** Splitting a font family interacts badly with `font()` auto-provides.

+ * [x] All the packages involved in an indirect require or supplement chain MUST be part of the set.

  

- Lastly, multi-font packages unnecessarily complexify font auto-installation..

+ === Packaging a font family in multiple OpenType formats; application support

  

- === Naming

+ * [x] Packagers MUST make a reasonable effort, to get applications that do not support all OpenType formats, fixed upstream.

+ * [x] If that fails, as a last ressort, packagers MAY request a https://pagure.io/fesco[FESCo exemption], to package a limited number of font families in multiple OpenType formats.

+ * [x] Packagers MUST ensure that the resulting additional font data, is separated in distinct font packages,

+ ** that the average Fedora user can install those font families in a single format,

+ ** that he is not left wondering, which package to install.

  

- Fedora font packages are named *[foundryname-]projectname[-fontfamilyname]-fonts*, in lowercase.

+ == Tooling

  

- ==== Clarifications

+ Creating font packages by hand can be extremely repetitive, error-prone and labor-intensive. Therefore, fonts packaging is heavily automated. It relies on numerous macros and variables to define what goes where.

  

- 1.  For Fedora purposes a “foundry” is an entity that publishes a set of fonts with consistent font QA rules. Thus a generic hosting service such as http://www.sf.net[Sourceforge] is not a foundry, but the http://openfontlibrary.org/[Open Font Library] is.

- 2.  It is good practice to contract _foundryname-_ in a short prefix.

- 3.  The _foundryname-_ prefix can optionally be skipped:

- * for entities that never released more than one font family, or

- * when the font project and the publishing entity are one and the same.

- 4.  If _projectname_ or _foundryname_ are repeated in _fontfamilyname_, they can be dropped from _fontfamilyname_.

- 5.  When _foundryname_, _projectname_ or _fontfamilyname_ contain the _font_ or _fonts_ affix, this affix should be dropped from themfootnote:[To avoid _foofont-fonts_ packages.].

- 6.  _-fontfamilyname_ should not be included in the srpm name of a package that includes several different font families.

- 7.  If any element of the naming contains spaces, they should be replaced by “-”.

- 8.  The use of the _-fonts_ suffix is not dependant on the actual number of font files in the package.

+ Those macros and variables are defined in the `fonts-rpm-macros` package. The `fonts-rpm-templates` package contains `spec` and `fontconfig` templates, corresponding to common fonts packaging needs.

  

- When in doubt, ask the https://fedoraproject.org/wiki/Fonts_SIG_mailing_lists[mailing list] for clarification.

+ === Fontconfig

  

- ==== Examples

+ The `fonts-rpm-templates` package contains `fontconfig` templates, corresponding to common fonts packaging needs.

  

- .Font package naming examples

- [cols=",,",options="header",]

- |========================================================================================================================

- |Source package (_src.rpm_) |Binary (sub)package |Description

- |Fonts |Other |Fonts |Other

- |apanov-heuristica-fonts | |apanov-heuristica-fonts | |“Heuristica” font family published by Andrey Panov, “apanov”.

- |sil-abyssinica-fonts | |sil-abyssinica-fonts | |“Abyssinica SIL” font family published by the “SIL” foundry.

- |oflb-brett-fonts | |oflb-brett-fonts | |“BrettFont” font family published on the “Open Font Library”, “oflb” foundry.

- |dejavu-fonts | a|

- * dejavu-sans-fonts

- * dejavu-sans-mono-fonts

- * dejavu-serif-fonts

+ To verify the font names installed by a package named `${pkg}` are correct, use:

  

-  | |The three “DejaVu” font families self-published by the “DejaVu” project.

- | |dejavu-fonts-common |Utility subpackage with no font files inside.

- |google-droid-fonts | a|

- * google-droid-sans-fonts

- * google-droid-sans-mono-fonts

- * google-droid-serif-fonts

+ .Checking font naming fixes

+ [source,bash]

+ ----

+ fc-scan -f "%{family[0]}@%{style[0]}@%{fullname[0]}@%{file[0]}\n" /usr/share/fonts/${pkg}/* \

+   | sort -t@  -k1,1 -k2,2 -u | column --separator @ -t

+ ----

  

-  | |The three “Droid” font families published by “Google”, as part of its “Droid” release.

- | |google-droid-fonts-common |Utility subpackage with no font files inside.

- |un-core-fonts | a|

- * un-core-pilgi-fonts

- * un-core-dinaru-fonts

- * un-core-batang-fonts…

+ .Command output, before fixes

+ [source,options="nowrap"]

+ ....

+ Accanthis ADF Std         Bold                         AccanthisADFStd-Bold                       /usr/share/fonts/adf-accanthis-fonts/AccanthisADFStd-Bold.otf

+ Accanthis ADF Std         Bold Italic                  AccanthisADFStd-BoldItalic                 /usr/share/fonts/adf-accanthis-fonts/AccanthisADFStd-BoldItalic.otf

+ Accanthis ADF Std         Italic                       AccanthisADFStd-Italic                     /usr/share/fonts/adf-accanthis-fonts/AccanthisADFStd-Italic.otf

+ Accanthis ADF Std         Regular                      AccanthisADFStd-Regular                    /usr/share/fonts/adf-accanthis-fonts/AccanthisADFStd-Regular.otf

+ Dai Banna SIL Book        Bold                         Dai Banna SIL Book Bold                    /usr/share/fonts/sil-dai-banna-fonts/DBSILBB.ttf

+ Dai Banna SIL Book        Bold Italic                  Dai Banna SIL Book Bold Italic             /usr/share/fonts/sil-dai-banna-fonts/DBSILBC.ttf

+ Dai Banna SIL Book        Italic                       Dai Banna SIL Book Italic                  /usr/share/fonts/sil-dai-banna-fonts/DBSILBO.ttf

+ Dai Banna SIL Book        Regular                      Dai Banna SIL Book                         /usr/share/fonts/sil-dai-banna-fonts/DBSILBR.ttf

+ Dai Banna SIL Light       Bold                         Dai Banna SIL Light Bold                   /usr/share/fonts/sil-dai-banna-fonts/DBSILLB.ttf

+ Dai Banna SIL Light       Bold Italic                  Dai Banna SIL Light Bold Italic            /usr/share/fonts/sil-dai-banna-fonts/DBSILLC.ttf

+ Dai Banna SIL Light       Italic                       Dai Banna SIL Light Italic                 /usr/share/fonts/sil-dai-banna-fonts/DBSILLO.ttf

+ Dai Banna SIL Light       Regular                      Dai Banna SIL Light                        /usr/share/fonts/sil-dai-banna-fonts/DBSILLR.ttf

+ IBM Plex Arabic           Bold                         IBM Plex Arabic Bold                       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexArabic-Bold.otf

+ IBM Plex Arabic           ExtraLight                   IBM Plex Arabic ExtraLight                 /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexArabic-ExtraLight.otf

+ IBM Plex Arabic           Light                        IBM Plex Arabic Light                      /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexArabic-Light.otf

+ IBM Plex Arabic           Medium                       IBM Plex Arabic Medium                     /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexArabic-Medium.otf

+ IBM Plex Arabic           Regular                      IBM Plex Arabic                            /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexArabic-Regular.otf

+ IBM Plex Arabic           SemiBold                     IBM Plex Arabic SemiBold                   /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexArabic-SemiBold.otf

+ IBM Plex Arabic           Text                         IBM Plex Arabic Text                       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexArabic-Text.otf

+ IBM Plex Arabic           Thin                         IBM Plex Arabic Thin                       /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexArabic-Thin.otf

+ IBM Plex Sans             Bold                         IBM Plex Sans Bold                         /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSans-Bold.otf

+ IBM Plex Sans             Bold Italic                  IBM Plex Sans Bold Italic                  /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSans-BoldItalic.otf

+ …

+ ....

  

-  | |“UN Core” fonts published by the “UN” project.

- | |un-core-fonts-common |Utility subpackage with no font files inside.

- | |openoffice.org |openoffice.org-opensymbol-fonts | |The “OpenSymbol” font family published as part of “openoffice.org”.

- | a|

- * openoffice.org-writer

- * openoffice.org-calc…

  

-  |

- |ctan-cm-lgc-fonts | a|

- * ctan-cm-lgc-sans-fonts

- * ctan-cm-lgc-roman-fonts

- * ctan-cm-lgc-typewriter-fonts…

+ .Command output, once fixed

+ [source,options="nowrap"]

+ ----

+ Accanthis ADF Std  Bold                         Accanthis ADF Std Bold                     /usr/share/fonts/adf-accanthis-fonts/AccanthisADFStd-Bold.otf

+ Accanthis ADF Std  Bold Italic                  Accanthis ADF Std Bold Italic              /usr/share/fonts/adf-accanthis-fonts/AccanthisADFStd-BoldItalic.otf

+ Accanthis ADF Std  Italic                       Accanthis ADF Std Italic                   /usr/share/fonts/adf-accanthis-fonts/AccanthisADFStd-Italic.otf

+ Accanthis ADF Std  Regular                      Accanthis ADF Std                          /usr/share/fonts/adf-accanthis-fonts/AccanthisADFStd-Regular.otf

+ Dai Banna SIL      Bold                         Dai Banna SIL Bold                         /usr/share/fonts/sil-dai-banna-fonts/DBSILBB.ttf

+ Dai Banna SIL      Bold Italic                  Dai Banna SIL Bold Italic                  /usr/share/fonts/sil-dai-banna-fonts/DBSILBC.ttf

+ Dai Banna SIL      Italic                       Dai Banna SIL Italic                       /usr/share/fonts/sil-dai-banna-fonts/DBSILBO.ttf

+ Dai Banna SIL      Light                        Dai Banna SIL Light                        /usr/share/fonts/sil-dai-banna-fonts/DBSILLR.ttf

+ Dai Banna SIL      Light Bold                   Dai Banna SIL Light Bold                   /usr/share/fonts/sil-dai-banna-fonts/DBSILLB.ttf

+ Dai Banna SIL      Light Bold Italic            Dai Banna SIL Light Bold Italic            /usr/share/fonts/sil-dai-banna-fonts/DBSILLC.ttf

+ Dai Banna SIL      Light Italic                 Dai Banna SIL Light Italic                 /usr/share/fonts/sil-dai-banna-fonts/DBSILLO.ttf

+ Dai Banna SIL      Regular                      Dai Banna SIL                              /usr/share/fonts/sil-dai-banna-fonts/DBSILBR.ttf

+ IBM Plex Sans      Bold                         IBM Plex Sans Bold                         /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexArabic-Bold.otf

+ IBM Plex Sans      Bold Condensed               IBM Plex Sans Bold Condensed               /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Roman.ttf

+ IBM Plex Sans      Bold Condensed Italic        IBM Plex Sans Bold Condensed Italic        /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansVar-Italic.ttf

+ IBM Plex Sans      Bold Italic                  IBM Plex Sans Bold Italic                  /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSans-BoldItalic.otf

+ IBM Plex Sans      Condensed                    IBM Plex Sans Condensed                    /usr/share/fonts/ibm-plex-sans-fonts/IBMPlexSansCondensed-Regular.otf

+ …

+ ----

+ 

+ === Packaging a single font family

+ 

+ The `fonts-rpm-templates` package contains `spec` templates, corresponding to common fonts packaging needs.

+ 

+ This is the simplest packaging pattern, when upstream releases:

+ 

+ * a single font family,

+ * conforming to this guideline’s definition of a font family,

+ * in a single dedicated source archive,

+ * without any specific difficulty.

+ 

+ ==== Macros and variables

+ 

+ [IMPORTANT]

+ ====

+ .Declaration ordering

+ Changing the proposed line order will more often than not result in a `spec` file that still works. That may be tempting, since the suggested order is far from traditional.

+ 

+ Be aware that this particular order was selected after reworking a large pool of test files, to maximize commonalities, and reduce divergence between packaging situations. Reordering may still work but the result will be harder to review, refactor, and copy in other `spec` files.

+ ====

+ 

+ ===== SRPM generic declarations

+ 

+ This pattern starts with a block of traditional `spec` declarations:

+ 

+ .SRPM generic declarations

+ [source,RPMSpec]

+ ----

+ Version: 

+ Release: 

+ URL:     

+ ----

+ 

+ ===== Shared font declarations

+ 

+ Then it declares elements, that will be shared by all the packaged font families. Here, we only process one of those, but the block will be at the same place in the other patterns.

+ 

+ [horizontal]

+ %{foundry}:: an optional upstream identifier, when upstream publishes multiple font families, with consistent QA rules. Font families released by the same upstream will usually play well with one another. Marking them as such helps users choose good font package sets.

+ * for example, the http://openfontlibrary.org/[Open Font Library] identifier is `oflb`.

+ %{fontlicense}:: the identifier of the font family license, according to our licensing rules.

+ 

+ Those identifiers are followed by variables, containing:

+ 

+ * lists of space-separated shell globs,

+ * matching the files associated with the font family,

+ * as they exist in the build root at the end of the `%build` stage.

  

-  | |“CM LGC” font families published by the “CTAN” foundry.

- | |ctan-cm-lgc-fonts-common |Utility subpackage with no font files inside.

- | |ctan-cm-lgc-tex |TEX overlay for ctan-cm-lgc fonts

- (cooked up example, this page is not a TEX naming guideline)

- |========================================================================================================================

+ [horizontal]

+ %{fontlicenses}:: the font family legal files

+ %{fontdocs}:: the font family documentation files

+ %{fontdocsex}:: exclusions from the `%{fontdocs}` list

  

- === Building from sources

+ .Shared font declarations

+ [source,RPMSpec]

+ ----

+ %global foundry           SIL

+ %global fontlicense       OFL

+ %global fontlicenses      OFL.txt

+ %global fontdocs          *.txt

+ %global fontdocsex        %{fontlicenses}

+ ----

  

- Fonts *SHOULD* be built from source whenever upstream provides them in a source format footnote:[As documented in our general xref:what-can-be-packaged.adoc#prebuilt-binaries-or-libraries[packaging guidelines\].]. Automating the build ensures we'll be able to fix the fonts when problems are reported and upstream is not responsive. Sometimes that means working with upstream to sanitize its build processes.

+ ===== Family-specific font declarations

  

- === Technical implementation

+ This is followed by a family-specific declaration block.

  

- Creating font packages or subpackages in Fedora is done using the _fontpackages-devel_ package footnote:[Built from the https://apps.fedoraproject.org/packages/fontpackages[fontpackages] srpm.]. Its sources are published on https://pagure.io/[Pagure] in https://pagure.io/fontpackages[archive] and git (https://pagure.io/fontpackages.git) formats.

+ [horizontal]

+ %{fontfamily}:: the human-friendly font family name, whitespace included, restricted to the *Basic Latin* Unicode block.

+ %{fontsummary}:: the generated font package summary. It must be less than 80 columns in length.

  

- It contains a set of commented fontconfig templates, and the two official Fedora fonts spec templates:

+ This block contains its own shell glob lists.

  

- * a https://fedoraproject.org/wiki/Simple_fonts_spec_template[simple template] for font source packages containing a single font family,

- * a https://fedoraproject.org/wiki/Fonts_spec_template_for_multiple_fonts[complex template] for font source packages containing several different font families.

+ [horizontal]

+ %{fonts}:: the font family font files

+ %{fontconfs}:: the font family fontconfig files

  

- While this package has been created by Fedora for Fedora, its content should be pretty generic. Apart from the occasional reference to this wiki as documentation source, it should not include any blatant Fedora-ism.

+ Followed by:

  

- _fontpackages_ evolutions can be discussed on the Fonts SIG https://fedoraproject.org/wiki/Fonts_SIG_mailing_lists[mailing list].

+ [horizontal]

+ %{fontdescription}:: a multi-line description block for the generated package. Each line should be less than 80 columns in length.

  

- === Install-time dependencies

+ .Family-specific font declarations

+ [source,RPMSpec]

+ ----

+ %global fontfamily        Andika

+ %global fontsummary       SIL Andika, a font family for literacy and beginning readers

+  %global fonts             *.ttf

+ %global fontconfs         %{SOURCE10}

+ %global fontdescription   %{expand:

+ Andika is a sans serif, Unicode-compliant font family designed especially for

+ literacy use, taking into account the needs of beginning readers. The focus is

+ on clear, easy-to-perceive letterforms that will not be readily confused with

+ one another.}

+ ----

  

- Font packages in a generic format (TTF, OTF) are resources and *MUST NOT* force the installation of a particular font handler through direct or indirect _Requires_. Fonts can be used by many different software stacks, including outside an X11 context, you should not choose one of them in the stead of users.

+ ===== Source declarations

  

- Execution of stack-specific helpers in scriptlets is allowed, as long as it's conditioned on the presence of those helpers on the system, does not force their installation for the font package, and does not block package installation in their absence.

+ Then package sources are declared the usual way.

  

- Likewise, installation of stack-specific configuration files is allowed, if they have no effect in the absence of this software stack, and are auto-discovered on installation of the software stack package.

+ .Source declarations

+ [source,RPMSpec]

+ ----

+ Source0:  

+ Source10: [number]-%{fontpkgname}.conf

+ ----

  

- === Grouping

+ Keeping fontconfig file names in sync with the package name is a good idea. Take a look at the templates in `fonts-rpm-templates` for information on how to write good fontconfig files and choose the correct priority `[number]`.

  

- === Licensing Information in Metadata

+ [NOTE]

+ ====

+ .Font package names

+ Font package names will be automatically computed from the previous declarations, and put into the `%{fontpkgname}` variable. You MAY override this variable at need. However, needing an override usually indicates that either the upstream font naming is broken, or you’re trying to do something wrong.

+ ====

  

- The "copyright notice" field (tag #0) of the "name" table of TTF and OTF files *MUST* be populated and contain accurate information. Additionally, if information is provided in the "license description" (#13) or "license info URL" (#14) fields are populated, the information contained therein must also be accurate. You can use https://fedoraproject.org/wiki/User:Patches/ttname[`+ttname+`] to review the metadata included with the font to check it for accuracy.

+ ===== Remainer of the spec file

  

- If the metadata is incorrect, packagers should work with upstream to ensure the metadata is properly populated there, so all users of the font can benefit from the corrections. If upstream is non-responsive or you are waiting on a new release for the corrections, you can also use `+ttname+` in `+%prep+` to correct the metadata for the Fedora package.

+ All those declarations are used and processed in the rest of the `spec` file by the following macros:

  

- ==== Checking the metadata with ttname

+ [horizontal]

+ %fontpkg:: generate font package headers

+ %fontbuild:: perform font-related steps, at the end of the `%build` section

+ %fontinstall:: perform font-related steps, at the end of the `%install` section

+ %fontcheck:: perform font-related steps, at the end of the `%check` section

+ %fontfiles:: generate font package `%file` lists

  

- To view the contents of the entire name table of a font, just run:

+ .Remainer of the spec file

+ [source,RPMSpec]

+ ----

+ %fontpkg

  

- ....

- ttname -a font.ttf

- ....

+ %prep

+ %setup

  

- ==== Correcting the metadata with ttname

+ %build

+ %fontbuild

  

- You can also use ttname to set the fields if upstream is nonresponsive to your requests to correct it.

+ %install

+ %fontinstall

  

- For example, you could run this in `+%prep+` to populate all the relevant fields with information contained in the package:

+ %check

+ %fontcheck

  

- ....

- ttname -a --copyright="$(head -n1 LICENSE)" --license="$(cat LICENSE)" --license-url="http://scripts.sil.org/OFL" font.ttf

- ....

+ %fontfiles

+ 

+ %changelog

+ ----

+ 

+ ==== Annotated spec template

+ 

+ Putting it all together:

+ 

+ .spectemplate-fonts-0-simple.spec

+ [source,RPMSpec]

+ ----

+ include::{examplesdir}/fonts/spectemplate-fonts-0-simple.spec[]

+ ----

+ 

+ === Packaging a single font family (advanced)

+ 

+ Sometimes, packaging a font family requires a little more work, with the associated automation. You may need to complete the previous pattern.

+ 

+ ==== Macros and variables

+ 

+ ===== Shared font declarations

+ 

+ One more shell glob list:

+ 

+ [horizontal]

+ %{fontlicensesex}:: exclusions from the *%{fontlicenses}* list

+ 

+ ===== Family-specific font declarations

+ 

+ [horizontal]

+ %{fontpkgheader}:: multi-line container for package header directives

+ 

+ .Semi-complex family declaration

+ [source,RPMSpec]

+ ----

+ %global fontfamily        PT Sans

+ %global fontsummary       PT Sans, a grotesque pan-Cyrillic font family

+ %global fontpkgheader     %{expand:

+ Obsoletes: paratype-pt-sans-caption-fonts < %{version}-%{release}

+ }

+ %global fonts             PTS*.ttf PTN*.ttf PTC*.ttf

+ %global fontconfs         %{SOURCE10}

+ %global fontdescription   %{expand:

+ The PT Sans family was developed as part of the “Public Types of Russian

+ Federation” project. This project aims at enabling the peoples of Russia to

+ read and write their native languages, using free/libre fonts. It is

+ dedicated to the 300-year anniversary of the Russian civil type invented by

+ Peter the Great from 1708 to 1710, and was realized with financial support

+ from the Russian Federal Agency for Press and Mass Communications.}

+ ----

+ 

+ … and more shell glob lists:

+ 

+ [horizontal]

+ %{fontsex}:: exclusions from the *%{fonts}* list

+ %{fontconfsex}:: exclusions from the *%{fontconfs}* list

+ %{fontappstreams}:: the font family _appstream_ files, if any; those files are generated automatically if not specified

+ %{fontappstreamsex}:: exclusions from the *%{fontappstreams}* list

+ 

+ ===== Remainer of the spec file

+ 

+ Bulky documentation can be split in a separate subpackage

+ 

+ .Documentation subpackage

+ [source,RPMSpec]

+ ----

+ %package   doc

+ Summary:   %{name} optional documentation files

+ BuildArch: noarch

+ %description doc

+ This package provides optional documentation files shipped with %{name}.

+ 

+ […]

+ 

+ %files doc

+ %license OFL.txt

+ %doc *.pdf

+ ----

+ 

+ Text files published for other systems may need recoding.

+ 

+ [horizontal]

+ %linuxtext:: allows converting upstream files to UTF-8 and Unix end of lines if necessary. It takes the following optional arguments:

+ * `-e [encoding]` source OS encoding (automatically detected otherwise)

+ * `-n`            do not recode files, only adjust folding and end of lines

+ 

+ ==== Annotated spec template

+ 

+ Putting it all together:

+ 

+ .spectemplate-fonts-1-full.spec

+ [source,RPMSpec]

+ ----

+ include::{examplesdir}/fonts/spectemplate-fonts-1-full.spec[]

+ ----

+ 

+ === Packaging multiple font families

+ 

+ Those patterns can be extended the following way, when packaging multiple font families, from a project named after the main packaged family.

+ 

+ ==== Macros and variables

+ 

+ ===== Shared font declarations

+ 

+ `%{foundry}`, `%{fontlicense}`, `%{fontlicensex}`, `%{fontdocs}` and `%{fontdocsex}` are applied to all font families,

+ 

+ * unless overriden by the same variable, suffixed with a specific block number

+ * for example `%{fontdocs2}`

+ 

+ A variable, can be used to share a description block:

+ 

+ .Using a common description variable

+ [source,RPMSpec]

+ ----

+ %global common_description %{expand:

+ IBM wanted Plex to be a distinctive, yet timeless workhorse — an alternative to

+ its previous corporate font family, “Helvetica Neue”, for this new era. The

+ Grotesque style was the perfect fit. Not only do Grotesque font families

+ balance human and rational elements, the Grotesque style also came about during

+ the Industrial Age, when IBM was born.}

+ 

+ […]

+ 

+ %global fontfamily1       Plex Sans

+ %global fontsummary1      IBM Plex Sans, the new grotesque IBM corporate font family

+ %global fontpkgheader1 %{expand:

+ Suggests: font(ibmplexsansmono)

+ }

+ %global fonts1            IBM-Plex-{Sans,Sans-*,Arabic}/fonts/complete/otf/*otf

+ %global fontsex1          IBM-Plex-Sans-Thai-Looped/fonts/complete/otf/*otf

+ %global fontconfs1        %{SOURCE11} 65-%{fontpkgname1}.conf

+ %global fontdescription1  %{expand:

+ %{common_description}

+ This package provides the grotesque sans-serif variable-width IBM Plex Sans,

+ the main font family of the Plex set.}

+ 

+ %global fontfamily2       Plex Mono

+ %global fontsummary2      IBM Plex Mono, the monospace grotesque coding font family of the Plex set

+ %global fonts2            IBM-Plex-Mono/fonts/complete/otf/*otf

+ %global fontconfs2        %{SOURCE12}

+ %global fontdescription2  %{expand:

+ %{common_description}

+ This package provides the grotesque sans-serif fixed-width IBM Plex Mono, a

+ little something for developers, because monospace does not need to be monotone.}

+ ----

+ 

+ ===== Family-specific font declarations

+ 

+ * each font family is declared in a separate family-specific block,

+ * each block is identified by a number, suffixed to the corresponding block variables,

+ ** for example `%{fontfamily1}`

+ * the zero-suffix block is used to generate SRPM metadata,

+ * all the zero-suffix variables are aliased to no-suffix variables of the same name, and vice versa.

+ 

+ ===== Packaging macros

+ 

+ * `%fontpkg`, `%fontbuild`, `%fontinstall`, `%fontcheck` and `%fontfiles` accept the following arguments:

+ ** `-a` process everything

+ ** `-z [number]` process the `[number]` declaration block

+ * if no flag is specified they will only process the zero/no-suffix block

+ ** consequently, packaging multiple font families will usually require the `-a` option

+ 

+ [horizontal]

+ %{fontmetapkg}:: generate font package headers. Optional arguments (usually unnecessary):

+ 

+ * `-n [name]`  use `[name]` as metapackage name

+ * `-s [variable]`  use the content of `[text]` as metapackage summary

+ * `-d [variable]`  use the content of `[variable]` as metapackage description

+ * `-z [numbers]`  restrict metapackaging to `[numbers]`è space-separated list of font package suffixes

+ 

+ .Complex metapackaging example

+ [source,RPMSpec]

+ ----

+ %fontmetapkg -z 1,2,3

+ 

+ %global lgcmetasummary All the font packages, generated from %{name}, Latin-Greek-Cyrillic subset

+ %global lgcmetadescription %{expand:

+ This metapackage installs all the font packages, generated from the %{name}

+ source package, in a version restricted to coverage of Latin, Greek and

+ Cyrillic.

+ }

+ 

+ %fontmetapkg -n dejavu-lgc-fonts-all -s lgcmetasummary -d lgcmetadescription -z 4,5,6

+ ----

+ 

+ ==== Annotated spec template

+ 

+ Putting it all together:

+ 

+ .spectemplate-fonts-2-multi.spec

+ [source,RPMSpec]

+ ----

+ include::{examplesdir}/fonts/spectemplate-fonts-2-multi.spec[]

+ ----

+ 

+ === Packaging font families, released as part of something else

+ 

+ The last pattern concerns the packaging one or several font families from a source rpm which is not named after the first packaged font family:

+ 

+ * either because the project name differs from the main font family name,

+ * or when the source archive and rpm are used to package more than fonts.

+ 

+ It is almost identical to the previous one.

+ 

+ ==== Macros and variables

+ 

+ ===== Family-specific font declarations

+ 

+ Do not declare a zero/no-suffix family-specific block, as it will attempt to generate SRPM metadata, and collide with existing SRPM declarations.

+ 

+ ==== Annotated spec template

+ 

+ Putting it all together:

+ 

+ .spectemplate-fonts-3-sub.spec

+ [source,RPMSpec]

+ ----

+ include::{examplesdir}/fonts/spectemplate-fonts-3-sub.spec[]

+ ----

+ 

+ == Rationale

+ 

+ === Legal

+ 

+ Fonts are subject to specific copyright, trademark and patent laws. Reading our https://fedoraproject.org/wiki/Legal_considerations_for_fonts[fonts legal page] is recommended.

+ 

+ === Packaging unit: an ideal font family

+ 

+ Font upstreams will often deviate from the OpenType model in their naming:

+ 

+ * because mistakes happen,

+ * because font formats are complex, with a long history, and a huge amount of legacy compability bagage,

+ * because upstreams may focus on the artistic side of font creation, to the detriment of its technical side,

+ * because upstreams may attempt to workaround problems in the legacy proprietary applications available on their platform of choice,

+ * because upstreams may be dormant, and miss changes in the OpenType specification, or use font creation tools that have still not implemented those changes.

+ 

+ Those deviations occur in upstream file names and upstream font file metadata. Upstream choices in those elements can not be relied upon to define useful and consistent font family boundaries.

+ 

+ Shared font files, are no place to workaround application-specific problems. Fedora must apply the OpenType standard strictly, to enable the leveraging by Free Desktop applications, of the application capabilities this standard was designed to unlock. One can always find bits of code not updated to take into account decades-old changes in font standards. Waiting on this code to be fixed is being last, not _First_.

+ 

+ === Font file formats

+ 

+ ==== OpenType highlights

+ 

+ ===== Variable fonts

+ 

+ Application support for variable fonts is sparse right now. They can not replace older OpenType formats yet.

+ 

+ ===== TT versus CFF

+ 

+ * OpenType TT boasts https://en.wikipedia.org/wiki/Font_hinting[hinting] capabilities, but hinting is labor-intensive and does not scale to large-encoding fonts. In practice modern TT fonts are hinted using automated processes similar to the auto-hinter present in https://www.freetype.org/[freetype].

+ * OpenType CFF lacks hinting but uses the excellent rasterizer Adobe https://opensource.googleblog.com/2013/05/got-cff.html[contributed] to freetype, achieving similar results.

+ * Low-resolution rendering is increasingly irrelevant with the replacement of 96dpi screens by 4K+ HiDPI hardware.

+ 

+ Therefore, don’t use hinting as a format selection criterium, unless you’re sure a human actually proofed the result on a modern renderer, at the screen pixel densities exercised by Fedora users.

+ 

+ Choose the OpenType format best supported upstream, typically the one produced by upstream’s preferred font creation toolchain. For historical reasons the math behind OpenType TT and OpenType CFF differs, converting from one to the other may introduce corner cases problems.

+ 

+ ===== Collections

+ 

+ While collection formats save some storage space, they introduce a high level of complexity packaging and application-side, make it impossible to install font families separately, and create a user-unfriendly environment.

+ 

+ Avoid packaging `+*.ttc+` and `+*.otc+` files unless left no choice by upstream.

+ 

+ ==== Legacy deprecated formats

+ 

+ Legacy formats are too limited to handle Unicode-level coverage, fail to declare their encoding, do not permit the kind of style selection expected in modern fonts, do not provide human-friendly naming layers, etc. They’re full of quirks and a source of (security) bugs in applications.

+ 

+ In 2006, at the first https://www.freedesktop.org/wiki/TextLayout/[Text Layout] summit, all the major Free Desktop players agreed to converge on a unified text layout engine, built around the http://harfbuzz.org/[HarfBuzz] project and the OpenType format. As a result, modern Free Desktop applications and libraries https://bugzilla.redhat.com/show_bug.cgi?id=1753295[no] https://bugs.documentfoundation.org/show_bug.cgi?id=104701[longuer] https://gitlab.gnome.org/GNOME/pango/issues/368[support] other formats.

+ 

+ Use tools like https://fontforge.github.io/[fontforge] or https://fedoraproject.org/wiki/BitmapFontConversion[fonttosfnt] (provided by xorg-x11-font-utils) to https://gitlab.gnome.org/GNOME/pango/issues/386#note_568255[convert] legacy fonts to an OpenType format. Get it done upstream or script it within the `%build` section of your `spec` file.

+ 

+ Like any other format conversion it will need some proofing. That’s why packaging fonts in a *single* *correct* format is a requisite for reliable text rendering.

+ 

+ ===== Web fonts

+ 

+ Due to the limitations of the browsers that existed at the time, and due to the fear foundries had of widespread font piracy, initial support for web fonts used a hodgepole of obscure, broken and incomplete font formats (`svg`, `eot`, `woff`, etc).

+ 

+ All major browsers have been https://caniuse.com/#feat=ttf[fixed] long ago to accept OpenType fonts.

+ 

+ Do not package web fonts except in OpenType format. If your upstream still religiously cargo-cults other formats in its CSS files, get those fixed.

+ 

+ The only remotely useful web font format is `woff`. Its advantages compared to OpenType are marginal at best on a well-configured web server. The sole remaining reason for `woff` existence is to serve as a light form of DRM for proprietary fonts (Normal applications do not read `woff` files). That concern does not apply to Fedora. Fedora wants to _share_. Any so-called web font can be useful in https://fedoramagazine.org/tuning-your-bash-or-zsh-shell-in-workstation-and-silverblue/[other] parts of the distribution. That requires distributing fonts in a common generic format.

+ 

+ ===== Postscript fonts

+ 

+ The OpenType CFF outline format is derived from the one used in Postscript. It was designed by Adobe to permit lossless conversion of legacy Postscript fonts. The SFNT container used by OpenType is vastly more capable than the original PostScript format.

+ 

+ Therefore, there’s no risk, and lots of advantages, in converting Postscript fonts. If their upstream does not want to bother, do not bother packaging the result.

+ 

+ ===== X11 core fonts

+ 

+ Once upon a time every Linux GUI application used the so-called _Core fonts_ server-side X11 backend footnote:[Fonts accessed through the original _core_ X protocol, using tools like _mkfontdir_, _xfs_, _/etc/X11/fontpath.d/_, _XLFD_ strings, etc. See also this http://keithp.com/~keithp/talks/xtc2001/paper/[paper] written shortly before projects massively migrated to client-side fonts.]. It was riddled with problems. The FLOSS developers finally gave up on it, declared it legacy and broken by design, and moved to client-side font handling (fontconfig). Nowadays almost no modern Linux GUI application uses the _Core fonts_ backend. Few (if any) people are willing to fix its remaining bugs.

+ 

+ Therefore, unless your font has previously been registered in _Core fonts_, and the problems triggered by this font hopefully fixed, you *SHOULD NOT* declare it there. This is especially true of fonts in modern OpenType formats.

+ 

+ The users of this legacy backend won't thank you for destabilizing it with new fonts. They value stability. Otherwise they'd have moved to fontconfig like everyone else a long time ago.

+ 

+ === Fontconfig

+ 

+ Free Desktop systems rely on multiple upstreams to provide their fonts. They are heavily dependent on fontconfig to present a consistent user-friendly font pool in applications. High quality fontconfig rules are indispensable to permit easy substitution of font families, and to mask upstream messiness.

+ 

+ Applying strict WWS rules helps applications identify all the parts of a font family, and makes selectors like bolder possible.

+ 

+ Removing format attributes from `family` prevents breakage, when the technical format shipped by the distribution changes after an update. Because font technology continues to improve, format changes are bound to happen sooner or later. Applications can still request font format information via the fontconfig API if they need to.

+ 

+ Removing coverage attributes from `family` enables merging all matching files in a single synthetic family. That is more user friendly, and prevents breakage when upstream decides to split the font family over different lines. Because creating a wide-coverage font family is a hard, long-term endeavour — Unicode is not finalized yet — such changes are common.

+ 

+ The other decisions are just choosing good defaults for the font family. While fontconfig can take a guess at those, its guess will never be as accurate as packager decisions. Packagers can ask upstream for clarifications. Fontconfig can not.

+ 

+ Remember that a lot of upstream naming decisions are taken to accomodate systems, that are missing an automatic font substition / font merging layer. The format and coverage information in `family` names is intended to help manual selection of font files. Our guidelines ask packagers to convert those to information fontconfig understands. Free Desktop systems can do a lot more, as long as the information provided to fontconfig is correct.

+ 

+ Exemples:

+ 

+ - The Foo project releases `Foo Narrow Oblique`. Because upstream remembers early font formats only allowed 4-style family grouping (Name ID 1 and 2), it declares it as `family: Foo Narrow` and `style: Oblique`. The fontconfig rules for `Foo Narrow Oblique` MUST rewrite it in `family: Foo` and `style: Narrow Oblique` (Name ID 21 and 22).

+ - The Foo project releases the `Universal Foo` wide-coverage font family. To allow installing only part of this family, it splits it in `Universal Foo`, `Universal Foo Hebrew` and `Universal Foo Thai`. The fontconfig rules for `Universal Foo` MUST rewrite the `family` (and therefore `fullname`) for all `Universal Foo Hebrew` and `Universal Foo Thai` font files, so they declare `Universal Foo` instead. Fontconfig will present the result as a single wide-encoding family to applications, even if the files remain split on-disk, even if all of them are not installed.

+ - The Foo project releases `Foo Sans`. The fontconfig rules for `Foo Sans` SHOULD declare any missing glyph can be taken from the `sans-serif` generic font family.

+ - The GNOME project releases the `Bitstream Vera` set of font families; later the `DejaVu` project forks and extends those fonts. The fontconfig rules for `DejaVu Sans` SHOULD declare it can be substituted for `Bitstream Vera Sans`.

+ - Microsoft ships Windows with the `Arial` font family. Due to its long and wide availability, `Arial` is now used in many documents. However it can not be included in Free Desktop systems for licensing reasons. Red Hat commissions an `Arial` substitute, `Liberation Sans`, for use on Linux. Google commissions another `Arial` substiture, `Arimo`, for use on ChromeOS. The fontconfig rules for `Liberation Sans` SHOULD declare it can be substituted for both `Arial` and `Arimo`.

+ 

+ === Source (SRPM) package break-up

+ 

+ As noted in the xref:index.adoc#bundling[Packaging Guidelines], Fedora packages should make every effort to avoid having multiple, separate, upstream projects bundled together in a single package. This applies equally to font packages.

+ 

+ Multi-source packages are difficult to maintain and confusing to users.

+ 

+ === Installation (RPM) package break-up: font packages

+ 

+ Once all the preceding has been done, a font package should only contain:

+ 

+ * OpenType font files,

+ * in a single OpenType format,

+ ** baring coverage constrains.

+ * with WWS-compliant `style` values,

+ * sharing the same `family` value,

+ ** except for optical sizing atttibutes, which are appended to the common `family` root.

+ * fontconfig files,

+ * appstream files,

+ * legal files,

+ * documentation files.

+ 

+ === Building

+ 

+ Building from source ensures it will be possible to modify the font when problems are reported and upstream is not responsive. Sometimes that means working with upstream to sanitize its build processes.

+ 

+ === Packaging a font family in multiple OpenType formats; application support

+ 

+ Fonts are comparatively bulky. Shipping fonts in multiple formats makes the situation worse on user systems, mirrors and live images. Every font family that ships in multiple formats, consumes space that could be used by another font package, enhancing the user experience.

+ 

+ Because applications will make different choices in presence of multiple formats for the same font family, because different formats use different rasterization engines, because format conversions can introduce artefacts, shipping multiple formats reduces the effectiveness of Fedora QA.

  

- === Core fonts

+ Most applications in Fedora support indifferently all OpenType formats,

  

- Once upon a time every Linux GUI application used the so-called _Core fonts_ server-side X11 backend footnote:[Fonts accessed through the original _core_ X protocol, using tools like _mkfontdir_, _xfs_, _/etc/X11/fontpath.d/_, _XLFD_ strings, etc. See also this http://keithp.com/~keithp/talks/xtc2001/paper/[paper] written shortly before projects massively migrated to client-side fonts.]. It was riddled with problems. The FLOSS developers finally gave up on it, declared it legacy and broken by design, and moved to client-side font handling (_fontconfig_). Nowadays almost no modern Linux GUI application uses the _Core fonts_ backend. Few (if any) people are willing to fix its remaining bugs.

+ Most fonts in Fedora are only available in a single OpenType format,

  

- Therefore, unless your font has previously been registered in _Core fonts_, and the problems triggered by this font hopefully fixed, you *SHOULD NOT* declare it there. This is especially true of fonts in modern (TTF or OTF) formats.

+ Rendering text in all the locales supported by Fedora requires using multiple fonts in multiple formats,

  

- The users of this legacy backend won't thank you for destabilizing it with new fonts. They value stability. Otherwise they'd have moved to _fontconfig_ like everyone else a long time ago.

+ Therefore packaging a font family in multiple OpenType formats should only be done as a limited exception.

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

– updates of The OpenType standard
– variable fonts
– web fonts
– math fonts
– emoji 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. Without those enhancements the fonts-specific macro code would be a lot longer. fonts-rpm-macros started two 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.

I authored most of the current font packaging guidelines except for the ttname part) and was/am the main maintainer of fontpackages. So, this is a refresh of both the guidelines part, and the macro part, with the benefit of 11 years of hindsight.

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.

Just one comment so far about some changes regarding to the WPF font selection model. we should try to implement it in some font packages before asking for acceptance of this change because there might be some side effect on it like we saw some on Google Droid. I'm a bit concerned that. apparently some examples in this proposal implies about Noto though, that is huge families to be unified. that would be nice to avoid regressions as much as possible.

Oh, and this isn't actually a comment on changing the policy but that would be nice to have more flexible rpm macros for complicated font packages like google-noto-fonts. but that may be wrong place to ask.

where's this macro coming from?

It's part of the fonts-rpm-macros set. I did not make the effort to push it in redhat-rpm-config because I only use it in font packages (but there, all the time)

https://pagure.io/fonts-rpm-macros/blob/master/f/rpm/macros.d/macros.fonts-rpm#_145

Oh, and this isn't actually a comment on changing the policy but that would be nice to have more flexible rpm macros for complicated font packages like google-noto-fonts. but that may be wrong place to ask.

@tagoh the rpm side of things is now streamlined and flexible both in the general packaging instructions (the Checklist) and in the packaging macro implementation.

The fontconfig side is in the same state as before (only better and more forcefully documented in the guidelines). The fontconfig templates in fonts-rpm-macros are byte-to-byte identical with the fontconfig templates in fontpackages. They are still limited to the patterns Behdad reviewed and approved in 2007.

So, the guidelines rewrite does not include any improvement fontconfig side. I didn't want to block on hypothetical future enhancements. The existing guideline is in high need of rewrite even without fontconfig changes (to be honest, it's years past its due date, I got busy elsewhere and didn’t update it timely, and no one else did the work).

You know and I know packagers would really love some simplified higher level syntactic sugar fontconfig side, but we've known this for years and things do not seem to improve. We can update the fontconfig templates in fonts-rpm-macros as soon as a better syntax gets available in fontconfig. As for the previous packaging implementation, you're admin of fonts-rpm-macros in pagure.

We're finally wrapping up the task list defined around 2006, with pango and others finishing their migration to harbuzz-ng. It would be nice to start working on a new and improved text target. The guidelines can be updated when this target gets defined.

@tagoh

Just one comment so far about some changes regarding to the WPF font selection model. we should try to implement it in some font packages before asking for acceptance of this change because there might be some side effect on it like we saw some on Google Droid

https://copr.fedorainfracloud.org/coprs/nim/fonts-rpm-macros/builds/
includes those "some font packages". It's really not different from the past decade of Fedora Droid packaging, so there was a lot of time to iron out things (and they won’t get easier to iron out as more complex fonts get released upstream and packaged in Fedora).

Microsoft uses this model in its apps, it's included in the OpenType standards, it's getting done with or without us, so surely it's better to acknowledge this is the state of OpenType upstream and things that need fixing or improving infra side (if any) should be fixed. 12 years ago WWS was a new and forward-looking thing. It's not anymore.

Starting with Fedora 31, bitmap non-OpenType fonts are not found by Pango-based applications: https://bugzilla.redhat.com/show_bug.cgi?id=1753295. However, while producing OTB format using fonttosfnt makes them available, there are spacing issues with them (even with patched fonttosfnt), so the fonts are not really usable.

So far we don't have a solution to the problem. I'm against the policy change if at the same time Fedora package maintainers (of bitmap fonts, at least) do not seem to have a reasonable way to comply.

@adelton Fedora packaging guidelines document the way things are not the way you wish them to be (especially NOT the way you wish them to be in upstream code). Pango, and LibreOffice, and OpenJDK, and others have all migrated or are migrating to harfbuzz-ng, which is an OpenType-only solution (the solution agreed on upstream by Free Desktop apps a decade ago).

Fedora packaging guidelines should be clear on what the state of the art is for things to work in the distro, otherwise packagers expect it to be something else, complain loudly that this something else is not what they actually get, and that Fedora did not COMMUNICATE properly (as showcased in https://bugzilla.redhat.com/show_bug.cgi?id=1748495#c19 and https://bugzilla.redhat.com/show_bug.cgi?id=1753295#c57)

Encouraging people to package font files that won't work in all our major apps, and to hope that support for legacy formats will come back in some way, is not the way to get an healthy distribution.

And, BTW:

  • I started working on this refresh a year before pango made its move,
  • I had nothing to do with the upstream switchover date,
  • but I am neither surprised nor unhappy the switchover happened in the meantime,
  • it was a long time in coming,
  • it was communicated in many ways for many years
  • that pango did its move before my refresh was ready means people will spend less time shooting the messenger (me) instead of working on their OpenType migration strategy. So on the minus side I suck at updating guidelines timely but on the plus side I will get less abuse for documenting an unpleasant reality
  • not that I don't expect a lot of people to blame me because they are not ready, people being what they are

Noone proposes to package fonts in formats that won't work in Fedora so you might want to stop repeating that rhetoric.

People would actually like to (help to) move to the new working state. So far however we don't know how and you haven't provided any technical guidance for Terminus, Lucida, or ucs-miscfixed-fonts. History and politics lessons won't fix those fonts.

I don't wish the policy to become the stick used against maintainers when they haven't been given the tools to actually be able to comply.

@adelton Fedora does not have a guidelines police. Maintainers of existing packages can and will lag on the state of the art, forcing them to do the right thing is asking for lots of abuse (so no one has the skin thickness to do guidelines policing at scale).

Guidelines document how things should be done for things to work right

They’re enforced on initial import, to avoid importing packages with a technical debt from day one

So guidelines will state that you MUST NOT package legacy font formats in Fedora, because they're not expected to work. And indeed they are NOT working right now, or in the foreseeable future, and it's not a bug, it's the result of a long-term dev roadmap (in Libre Office, in Pango, and in many others).

1 new commit added

  • better rationale links
a month ago

1 new commit added

  • even better rationale links
a month ago

where's this macro coming from?

It's part of the fonts-rpm-macros set. I did not make the effort to push it in redhat-rpm-config because I only use it in font packages (but there, all the time)
https://pagure.io/fonts-rpm-macros/blob/master/f/rpm/macros.d/macros.fonts-rpm#_145

Also, it depends on uchardet for encoding detection and I didn’t want to expend the energy required to justify adding a new dep to redhat-rpm-config

1 new commit added

  • document default style exception for fonts
a month ago

rebased onto 62d50ad

a month ago

1 new commit added

  • add recipe to check naming
a month ago

rebased onto 20983f3

a month ago

The fontconfig side is in the same state as before (only better and more forcefully documented in the guidelines). The fontconfig templates in fonts-rpm-macros are byte-to-byte identical with the fontconfig templates in fontpackages. They are still limited to the patterns Behdad reviewed and approved in 2007.

I’ve started working on a newer and better fontconfig syntax here, taking into account what happened Fedora-side in the past decade
https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/187
(plus all the following issues)

However, even assuming it gets instant buy-in by the fontconfig community once I finish describing it, it will take quite a long time to be implemented by someone, make its way into Fedora, and be available to write guidelines around.

And the fontconfig proposal is done:
https://lists.freedesktop.org/archives/fontconfig/2019-November/006626.html

We’ll see how people like @tagoh react to it.

I know it’s probably quite a lot of work, but the current state is pretty dismal, and I don’t think getting to the point where external engines try to second-guess fontconfig and pilot it via thousands of lines of generated config is something to strive for.

That would be recreating the sendmail mess, in xml, for a something which is a desktop subsystem.

1 new commit added

  • Reference Peng Wu’s bitmap conversion instructions
8 days ago

2 new commits added

  • Reference Peng Wu’s bitmap conversion instructions
  • Fonts packaging policy rewrite
8 days ago