| |
@@ -1,156 +1,825 @@
|
| |
- === Legal considerations
|
| |
+ = Fonts
|
| |
+ :toc:
|
| |
+ :toclevels: 4
|
| |
+
|
| |
+ == Foreword
|
| |
+
|
| |
+ The bulk of Fedora software relies on OpenType compliance and was tested against compliant fonts.
|
| |
+
|
| |
+ Unfortunately, most font makers feel the OpenType specification is a document written by “software people” for “software people”. They spurn its recommendations. They can not be relied upon to release fonts in a software-friendly state, nor to fix the resulting problems, nor to provide useful advice.
|
| |
+
|
| |
+ To enable the packaging of fonts by non experts, <<Checklist>> provides a list of sanity rules. Most are short unambiguous one liners, easy to understand and apply. Do read this list, even if it feels long. Unless your upstream is a model of discipline, you WILL need it. Avoid <<Exceptions>> if you do not feel ambitious – here be dragons.
|
| |
+
|
| |
+ Once you sorted what to package using the checklist, the rpm-specific part of fonts packaging is simple:
|
| |
+
|
| |
+ * take our spec templates,
|
| |
+ * fill in the blanks with descriptions and the file lists resulting from the sorting.
|
| |
+
|
| |
+ Fedora automation will do the rest.
|
| |
+
|
| |
+ <<Tooling>> provides in-depth documentation of those templates, and other operational tips. The operational tips are useful. The spec templates documentation, not so much. The templates are commented and will usually be self-explanatory.
|
| |
+
|
| |
+ Lastly, <<Rationale>> provides some help, in case a third party attempts to confuse you. A lot of upstreams are dead set against applying OpenType recommendations. They will provide elaborate argumentation, on why the common rule does not apply to them.
|
| |
+
|
| |
+ == 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] 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>>.
|
| |
+ * [x] Font packages MUST NOT contain font files in non OpenType formats.
|
| |
+
|
| |
+ [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:
|
| |
|
| |
- 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].
|
| |
+ * [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
|
| |
|
| |
- === Package layout for fonts
|
| |
+ * [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.
|
| |
|
| |
- . 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
|
| |
+ == Exceptions
|
| |
|
| |
- *Rationale:*
|
| |
+ === Bitmap console fonts
|
| |
|
| |
- 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] 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 `/lib/kbd/consolefonts/` not `/usr/share/fonts`.
|
| |
+ * [x] Bitmap console font packages SHOULD be named `_<something>_-fonts-console` not `_<something>_-fonts`.
|
| |
+
|
| |
+ [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.
|
| |
+ ====
|
| |
+
|
| |
+ === Assembling same-family font packages
|
| |
+
|
| |
+ * [x] A font family MUST NOT be split over several font packages, unless one of the exceptions listed above applies.
|
| |
+
|
| |
+ When a font family is split over a set of several font packages:
|
| |
+
|
| |
+ * [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.
|
| |
+
|
| |
+ === Packaging a font family in multiple OpenType formats; application support
|
| |
+
|
| |
+ * [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.
|
| |
+
|
| |
+ == Tooling
|
| |
+
|
| |
+ 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.
|
| |
+
|
| |
+ 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.
|
| |
+
|
| |
+ === Fontconfig
|
| |
+
|
| |
+ The `fonts-rpm-templates` package contains `fontconfig` templates, corresponding to common fonts packaging needs.
|
| |
+
|
| |
+ Using fontconfig, you can help users and software make sense of broken font files.
|
| |
+
|
| |
+
|
| |
+ [NOTE]
|
| |
+ ====
|
| |
+ .On brokenness and interoperability
|
| |
+ Fixing may imply behaviour differences, with entities that chose another mitigation strategy. The root cause of those differences is the upstream release of files in a broken state. Producing daring glyph shapes is the designer prerogative. That artistic license does not extend to flouting technical conventions, software relies on.
|
| |
+
|
| |
+ Upstream should always be given the chance to fix its files. If it does not care about our needs, fixing downstream is second best. Inflicting intact breakage on our users is always worst.
|
| |
+ ====
|
| |
+
|
| |
+ ==== Some applications
|
| |
+
|
| |
+ - The Foo project releases `Foo Narrow Oblique`. Because the font maker remembers early font formats only allowed 4-style family grouping (https://docs.microsoft.com/en-us/typography/opentype/spec/name#name-ids[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 to the https://docs.microsoft.com/en-us/typography/opentype/spec/namesmp[recommended] https://docs.microsoft.com/en-us/typography/opentype/spec/name#nid21[WWS-compliant] `family: Foo` and `style: Narrow Oblique` (Name ID 16/17 or 21/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`.
|
| |
+
|
| |
+ ==== Style naming
|
| |
+
|
| |
+ The https://docs.microsoft.com/en-us/typography/opentype/spec/os2#usweightclass[OpenType] https://docs.microsoft.com/en-us/typography/opentype/spec/os2#uswidthclass[specification], the https://www.w3.org/TR/css-fonts-4/#font-weight-prop[CSS] https://www.w3.org/TR/css-fonts-4/#font-stretch-prop[specification] and the https://www.freedesktop.org/software/fontconfig/fontconfig-user.html[fontconfig manual] document the canonical mappings of style keywords.
|
| |
+
|
| |
+ Those mappings are not absolute. The addition of variable capabilities enabled the creation of new keywords and axes values, including in non variable font files.
|
| |
+
|
| |
+ Nevertheless, the OpenType specification requires correlating the new capabilities with the traditional keyword scale:
|
| |
+
|
| |
+ * [x] an axis step, with a value, close to one of the specification keywords, SHOULD be named with this keyword,
|
| |
+ ** a slight deviation from the canonical keyword value, for design reasons, is expected and accepted.
|
| |
+ * [x] an axis step, SHOULD NOT be named with a keyword, when its value differs greatly from the keyword canonical value,
|
| |
+ ** font files that define new intermediary steps should also define new keywords.
|
| |
+
|
| |
+ Additionnally:
|
| |
+
|
| |
+ * [x] axis keywords SHOULD NOT use whitespace, for obvious software processing constrains,
|
| |
+ ** `SemiCondensed` is a good keyword; `Semi Condensed` — not.
|
| |
+ * [x] keywords SHOULD be assembled in `width weight slant` order in style names, for historical reasons,
|
| |
+ ** with the default `Regular` ommited except when alone.
|
| |
+
|
| |
+ ==== Checking results
|
| |
+
|
| |
+ To verify the metadata of font files installed by a package named `${pkg}`:
|
| |
+
|
| |
+ .Check command
|
| |
+ [source,bash]
|
| |
+ ----
|
| |
+ fc-scan -f \
|
| |
+ %{family[0]};%{style[0]};%{fullname[0]};%{width};%{weight};%{slant};%{fontversion};%{file}\n" \
|
| |
+ /usr/share/fonts/${pkg} | sort -t ';' -k1,1d -k4,4n -k5,5n -k6,6n -k2,2d -k7,7dr \
|
| |
+ | uniq | column --separator ';' -t
|
| |
+ ----
|
| |
+
|
| |
+ .Command output, before fixes
|
| |
+ -----
|
| |
+ include::{examplesdir}/fonts/before-fontconfig-fixes.txt[]
|
| |
+ …
|
| |
+ -----
|
| |
+
|
| |
+ .Command output, once fixed
|
| |
+ [source,options="nowrap"]
|
| |
+ -----
|
| |
+ include::{examplesdir}/fonts/after-fontconfig-fixes.txt[]
|
| |
+ …
|
| |
+ -----
|
| |
+
|
| |
+ === Spec template documentation
|
| |
+
|
| |
+ The `fonts-rpm-templates` package contains `spec` templates, corresponding to common fonts packaging needs.
|
| |
+
|
| |
+ ==== Packaging a single font family
|
| |
+
|
| |
+ 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.
|
| |
+
|
| |
+ [horizontal]
|
| |
+ %{fontlicenses}:: the font family legal files
|
| |
+ %{fontdocs}:: the font family documentation files
|
| |
+ %{fontdocsex}:: exclusions from the `%{fontdocs}` list
|
| |
+
|
| |
+ .Shared font declarations
|
| |
+ [source,RPMSpec]
|
| |
+ ----
|
| |
+ %global foundry SIL
|
| |
+ %global fontlicense OFL
|
| |
+ %global fontlicenses OFL.txt
|
| |
+ %global fontdocs *.txt
|
| |
+ %global fontdocsex %{fontlicenses}
|
| |
+ ----
|
| |
+
|
| |
+ ====== Family-specific font declarations
|
| |
+
|
| |
+ This is followed by a family-specific declaration block.
|
| |
+
|
| |
+ [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.
|
| |
+
|
| |
+ This block contains its own shell glob lists.
|
| |
+
|
| |
+ [horizontal]
|
| |
+ %{fonts}:: the font family font files
|
| |
+ %{fontconfs}:: the font family fontconfig files
|
| |
+
|
| |
+ Followed by:
|
| |
+
|
| |
+ [horizontal]
|
| |
+ %{fontdescription}:: a multi-line description block for the generated package. Each line should be less than 80 columns in length.
|
| |
+
|
| |
+ .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.}
|
| |
+ ----
|
| |
+
|
| |
+ ====== Source declarations
|
| |
+
|
| |
+ Then package sources are declared the usual way.
|
| |
+
|
| |
+ .Source declarations
|
| |
+ [source,RPMSpec]
|
| |
+ ----
|
| |
+ Source0:
|
| |
+ Source10: [number]-%{fontpkgname}.conf
|
| |
+ ----
|
| |
+
|
| |
+ 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]`.
|
| |
+
|
| |
+ [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.
|
| |
+ ====
|
| |
+
|
| |
+ ====== Remainer of the spec file
|
| |
+
|
| |
+ All those declarations are used and processed in the rest of the `spec` file by the following macros:
|
| |
+
|
| |
+ [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
|
| |
+
|
| |
+ .Remainer of the spec file
|
| |
+ [source,RPMSpec]
|
| |
+ ----
|
| |
+ %fontpkg
|
| |
+
|
| |
+ %prep
|
| |
+ %setup
|
| |
+
|
| |
+ %build
|
| |
+ %fontbuild
|
| |
+
|
| |
+ %install
|
| |
+ %fontinstall
|
| |
+
|
| |
+ %check
|
| |
+ %fontcheck
|
| |
+
|
| |
+ %fontfiles
|
| |
+
|
| |
+ %changelog
|
| |
+ ----
|
| |
+
|
| |
+ ===== Annotated spec template
|
| |
|
| |
- 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.
|
| |
+ Putting it all together:
|
| |
|
| |
- 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.
|
| |
+ .spectemplate-fonts-0-simple.spec
|
| |
+ [source,RPMSpec]
|
| |
+ ----
|
| |
+ include::{examplesdir}/fonts/spectemplate-fonts-0-simple.spec[]
|
| |
+ ----
|
| |
|
| |
- Lastly, multi-font packages unnecessarily complexify font auto-installation..
|
| |
+ ==== Packaging a single font family (advanced)
|
| |
|
| |
- === Naming
|
| |
+ Sometimes, packaging a font family requires a little more work, with the associated automation. You may need to complete the previous pattern.
|
| |
|
| |
- Fedora font packages are named *[foundryname-]projectname[-fontfamilyname]-fonts*, in lowercase.
|
| |
+ ===== Macros and variables
|
| |
|
| |
- ==== Clarifications
|
| |
+ ====== Shared font declarations
|
| |
|
| |
- 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.
|
| |
+ One more shell glob list:
|
| |
|
| |
- When in doubt, ask the https://fedoraproject.org/wiki/Fonts_SIG_mailing_lists[mailing list] for clarification.
|
| |
+ [horizontal]
|
| |
+ %{fontlicensesex}:: exclusions from the *%{fontlicenses}* list
|
| |
|
| |
- ==== Examples
|
| |
+ ====== Family-specific font declarations
|
| |
|
| |
- .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
|
| |
+ [horizontal]
|
| |
+ %{fontpkgheader}:: multi-line container for package header directives
|
| |
|
| |
- | |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
|
| |
+ .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.}
|
| |
+ ----
|
| |
|
| |
- | |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…
|
| |
+ … and more shell glob lists:
|
| |
|
| |
- | |“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…
|
| |
+ [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
|
| |
|
| |
- |
|
| |
- |ctan-cm-lgc-fonts | a|
|
| |
- * ctan-cm-lgc-sans-fonts
|
| |
- * ctan-cm-lgc-roman-fonts
|
| |
- * ctan-cm-lgc-typewriter-fonts…
|
| |
+ ====== Remainer of the spec file
|
| |
|
| |
- | |“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)
|
| |
- |========================================================================================================================
|
| |
+ Bulky documentation can be split in a separate subpackage
|
| |
|
| |
- === Building from sources
|
| |
+ .Documentation subpackage
|
| |
+ [source,RPMSpec]
|
| |
+ ----
|
| |
+ %package doc
|
| |
+ Summary: %{name} optional documentation files
|
| |
+ BuildArch: noarch
|
| |
+ %description doc
|
| |
+ This package provides optional documentation files shipped with %{name}.
|
| |
|
| |
- 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.
|
| |
+ […]
|
| |
|
| |
- === Technical implementation
|
| |
+ %files doc
|
| |
+ %license OFL.txt
|
| |
+ %doc *.pdf
|
| |
+ ----
|
| |
|
| |
- 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.
|
| |
+ Text files published for other systems may need recoding.
|
| |
|
| |
- It contains a set of commented fontconfig templates, and the two official Fedora fonts spec templates:
|
| |
+ [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
|
| |
|
| |
- * 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.
|
| |
+ ===== Annotated spec template
|
| |
|
| |
- 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.
|
| |
+ Putting it all together:
|
| |
|
| |
- _fontpackages_ evolutions can be discussed on the Fonts SIG https://fedoraproject.org/wiki/Fonts_SIG_mailing_lists[mailing list].
|
| |
+ .spectemplate-fonts-1-full.spec
|
| |
+ [source,RPMSpec]
|
| |
+ ----
|
| |
+ include::{examplesdir}/fonts/spectemplate-fonts-1-full.spec[]
|
| |
+ ----
|
| |
|
| |
- === Install-time dependencies
|
| |
+ ==== Packaging multiple font families
|
| |
|
| |
- 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.
|
| |
+ Those patterns can be extended the following way, when packaging multiple font families, from a project named after the main packaged family.
|
| |
|
| |
- 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.
|
| |
+ ===== Macros and variables
|
| |
|
| |
- 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.
|
| |
+ ====== Shared font declarations
|
| |
|
| |
- === Grouping
|
| |
+ `%{foundry}`, `%{fontlicense}`, `%{fontlicensex}`, `%{fontdocs}` and `%{fontdocsex}` are applied to all font families,
|
| |
|
| |
- === Licensing Information in Metadata
|
| |
+ * 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]
|
|
ignatenkobrain commented 4 years ago
where's this macro coming from?