notofonts / notofonts.github.io

To report an issue in a Noto font, go here. High level overview and instructions for font developers Here's what you need to know for general font-level work on the Noto project: • Each *script* in Noto gets its own repository. The script repository is based on the noto-project-template repo. If you are in the position of needing to **add a new script to Noto**, do so by visiting https://github.com/notofonts/noto-project-template and clicking the green "Use this template" button. *Make sure you click the "Include all branches" option on the page which follows.* • Each *family* within a script gets its own configuration file, . In many cases, you will want to automatically add a subset of glyphs from Noto Sans, Noto Serif or Noto Devanagari into the source UFOs. You can do this by adding the following to the configuration file: or These subsets will be added to the font by Notobuilder, explained below. • Try to work on font problems in branches and make pull requests. When you work in a branch, GitHub actions will build the font, perform QA tests, and create QA reports and proof sheets. You can download these reports as a build artefact by going to the "Actions" page. • As well as the GitHub actions, you can trigger builds and tests manually using the Makefile: • builds the font • runs the fontbakery checks • The following QA tests are run: • Fontbakery is run using the profile for the non-"full" builds and using the profile for any outputs that are destined for Google Fonts onboarding. Fontbakery is also configured so that any shaping tests found in are automatically run. • The previous released version of the font is fetched and is run to produce a report showing the differences. As well as the glyph-level differences, any strings found in files matching are rendered and their differences are displayed. • Proof sheets are generated with . • In addition, the artefacts (latest font builds and QA reports) from the current branch are published on the repository's GitHub Pages site. (see e.g. https://notofonts.github.io/vithkuqi/) • Repositories are organised by *script* but releases are organised by *family*. **When it's time to create a new release**, push a new tag of the form (e.g. ). If everything goes well, the release GitHub Action will then: • Build and test the font. • Create a GitHub Release including a Zip file of font binaries. • Create a PR to Google Fonts to onboard the new release. > Note that the action to produce the Google Fonts PR requires the organisational secrets and to be set, and the key to be set correctly in each file. Build, QA and onboarding automation All of the above is wonderful if everything works. Here's what you need to know if there are problems with the build process itself. The main design goal for the build process has been *forward compatibility*. In other words, providing a consistent build experience across all Noto script project repositories while ensuring that any changes which need to be made to the build or its environment do not need to be repeated across all 150+ repos. The main way this is achieved is through the notobuilder repository. All script repositories use notobuilder, which provides: • The GitHub workflows which control building ( ) and releasing ( ). • A declaration (through its ) of the Python dependencies and their versions used to build all Noto fonts. • The build process itself. (We will discuss below why Noto needs its own bulid process!) • The QA process. The aim is that Noto project repositories would pull the latest version of this repository and use to get the latest actions as well as to use it to build the fonts; this means that both the way that font building happens, and the required versions of fonttools, fontmake, etc., can all be defined and updated in one single place, and also that any updates to the build methodology or the required versions will be automatically carried over to new builds. notobuilder The class is a subclass of GFBuilder, but with certain modifications to suit the Noto workflow. • We expect a certain directory structure for the output files: • - • - • In Noto, we produce unhinted and hinted versions of the font; hinted versions are produced by trying to run ttfautohint with an appropriate script ( ) flag. (If autohinting fails, the unhinted font is copied to the hinted font path without erroring out.) • We try to produce a variable font by default but also don't error out if that fails. • We also (based on a configuration file) use UFO merging to add subsets of Noto Sans, Noto Serif or Noto Sans Devanagari into the sources to produce a "full" build of the font. As these are Noto-specific process requirements they have not been merged into the upstream GFBuilder. notoqa This Python module defines the process used to test Noto fonts. In a similar vein to notobuilder, the point is that we define the test procedures in one location, and all project repositories automatically receive updated versions of the test protocols when this repository changes. It defines two kind of tests: • runs fontbakery checks on each family, and is used to implement the target in the project repository Makefile. • downloads the latest release of the family and runs regression tests between the current build and the previous, using . Note This repository does not contain the following fonts: • Noto CJK fonts: https://github.com/notofonts/noto-cjk • Noto Emoji: https://github.com/googlefonts/noto-emoji Licensing All Noto fonts (in the directory) are licensed under the SIL Open Font License. This documentation and all tooling in this repository is licensed under the Apache 2.0 License.