Нет описания https://notofonts.github.io/
|
|
21 часов назад | |
|---|---|---|
| .github | 4 месяцев назад | |
| docs | 21 часов назад | |
| fonts | 2 месяцев назад | |
| megamerge | 9 месяцев назад | |
| scripts | 2 лет назад | |
| LICENSE | 4 лет назад | |
| README.md | 1 год назад | |
| all-results.json | 2 дней назад | |
| debug.json | 21 часов назад | |
| fontrepos.json | 6 месяцев назад | |
| renovate.json | 1 год назад | |
| state.json | 2 месяцев назад |
To report an issue in a Noto font, go here.
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, sources/config-<something>.yaml. 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:
includeSubsets:
- name: "GF Glyph Sets/GF-latin-core"
from: "Noto Sans"
or
includeSubsets:
- from: "Noto Sans Devanagari"
ranges:
- from: 0x1CD0
to: 0x1CE7
- from: ...
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:
make build builds the fontmake test runs the fontbakery checksThe following QA tests are run:
notofonts profile for the non-"full" builds and using the googlefonts profile for any outputs that are destined for Google Fonts onboarding. Fontbakery is also configured so that any shaping tests found in qa/shaping_tests are automatically run.gftools.diffenator is run to produce a report showing the differences. As well as the glyph-level differences, any strings found in files matching qa/*.txt are rendered and their differences are displayed.gftools-gen-html proof.In addition, the artefacts (latest font builds and QA reports) from the current main 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 <Family>-v<Version> (e.g. NotoSansBengali-v2.002). If everything goes well, the release GitHub Action will then:
Note that the action to produce the Google Fonts PR requires the organisational secrets
SSH_KEYandUSER_GITHUB_TOKENto be set, and thecategorykey to be set correctly in eachconfig.yamlfile.
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:
build.yaml) and releasing (release.yaml).setup.py) of the Python dependencies and their versions used to build all Noto fonts.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.
The Notobuilder class is a subclass of GFBuilder,
but with certain modifications to suit the Noto workflow.
fonts/<family>/unhinted/variable-ttffonts/<family>/unhinted/otffonts/<family>/unhinted/ttffonts/<family>/hinted/ttf-D) flag. (If autohinting fails, the unhinted font is copied to the hinted font path without erroring out.)As these are Noto-specific process requirements they have not been merged into the upstream GFBuilder.
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:
python -m notoqa runs fontbakery checks on each family, and is used to implement the make test target in the project repository Makefile.
python -m notoqa.regression downloads the latest release of the family and runs regression tests between the current build and the previous, using gftools.qa.
This repository does not contain the following fonts:
All Noto fonts (in the fonts/ 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.