From 1aca727307aa8666b08e58d8ed89a83b61435377 Mon Sep 17 00:00:00 2001 From: Emma Marichal Date: Thu, 4 Dec 2025 11:56:17 +0100 Subject: [PATCH 01/11] starting to update according new tools --- gf-guide/qa.md | 6 +++--- gf-guide/tags.md | 7 ++----- 2 files changed, 5 insertions(+), 8 deletions(-) diff --git a/gf-guide/qa.md b/gf-guide/qa.md index 1fcc2c2..c9cea47 100644 --- a/gf-guide/qa.md +++ b/gf-guide/qa.md @@ -38,7 +38,7 @@ For the rest of this chapter, it would be better if you have basic knowledge of: ## Tools -### Checking the font tabes +### Checking the font tables Beyond the visible outlines of a typeface, each font binary is composed of an ensemble of [required tables](https://learn.microsoft.com/en-us/typography/opentype/spec/otff#font-tables). These tables store fundamental metadata for the font to transmit operating information to the different environments (OS, applications, browsers) and, therefore, for it to function properly in all of them. @@ -48,9 +48,9 @@ Hence, it is important to inspect them to verify all the information is as expec - [Font table viewer](https://glyphsapp.com/tools/fonttableviewer) to turn the UFOs into FontTools objects; - [DTL OT Master](https://www.fontmaster.nl/otmaster.html) to also edit them. -### Checking with Fontbakery +### Checking with Fontspector -Fontbakery is our primary quality assurance testing tool to make it easier to check that font projects are optimal, making sure that the fonts **are reliable** before they are submitted to the users. +Fontbakery was previously our primary quality assurance testing tool. We now use Fontspector, a Rust-based tool, which makes it easier to ensure that font projects are optimal and that the fonts are reliable before being delivered to users. #### Log levels results diff --git a/gf-guide/tags.md b/gf-guide/tags.md index 8cbafc2..573dbfe 100644 --- a/gf-guide/tags.md +++ b/gf-guide/tags.md @@ -14,11 +14,8 @@ A new step has therefore been added to the font onboarding process, managed by t
-Background reading:
- + Background reading:
+ nerd  Making a PR to Google Fonts
## Table of contents From 46099d0c7259ec6e58ce10e9a74989d5398984fe Mon Sep 17 00:00:00 2001 From: Emma Marichal Date: Fri, 5 Dec 2025 15:57:24 +0100 Subject: [PATCH 02/11] Put back Aarons version --- gf-guide/metrics.md | 126 +++++++++++++++++++++++++++++++++++++++----- 1 file changed, 112 insertions(+), 14 deletions(-) diff --git a/gf-guide/metrics.md b/gf-guide/metrics.md index 7531365..b14eaac 100644 --- a/gf-guide/metrics.md +++ b/gf-guide/metrics.md @@ -248,26 +248,124 @@ If the font is already hosted on [fonts.google.com](http://fonts.google.com/), y ## CJK Vertical Metrics -CJK vertical metrics are based on Source Han Sans and Noto CJK fonts. +Vertical metrics for CJK fonts are based on the font em-box values. This ensures that the ideographs (or syllables) are properly positioned in the center of the em-box both in horizontal and vertical typesetting. -The following vertical metric values must be applied to all CJK fonts +The following metrics are a distinct split from the standard approach of setting vertical metrics for CJK fonts, which normally set the `sTypo` metrics to align with the em-box values. This is also how the [OT spec recommendations](https://learn.microsoft.com/en-us/typography/opentype/spec/os2#stypoascender) are written. However, following [investigation into performance of CJK fonts](https://github.com/google/fonts/issues/8911) under the primary scenarios that Google Fonts prioritizes, the following new metrics have been established: -| Attrib | Value | Example using 1000upm font | +| Attrib | Value | Example using a 1000 UPM font such as [Iansui](https://github.com/ButTaiwan/iansui) | |-------------------------------------------|------------------------------------------|----------------------------| -| OS/2.sTypoAscender | 0.88 \* font upm | 880 | -| OS/2.sTypoDescender | -0.12 \* font upm | -120 | +| OS/2.sTypoAscender | ideoEmBoxTop \+ (10–20% \* em-box)/2 | 940 | +| OS/2.sTypoDescender | ideoEmBoxBottom \- (10–20% \* em-box)/2 | -180 | | OS/2.sTypoLineGap | 0 | 0 | -| hhea.ascender | Set to look comfortable (\~1.16 \* upm) | 1160 | -| hhea.descender | Set to look comfortable (\~0.288 \* upm) | -288 | +| hhea.ascender | OS/2.sTypoAscender | 940 | +| hhea.descender | OS/2.sTypoDescender | -180 | | hhea.lineGap | 0 | 0 | -| OS/2.usWinAscent | Same as hhea.ascent | 1160 | -| OS/2.usWinDescent | abs(value) of hhea.descent | 288 | -| OS/2.fsSelection bit 7 (Use_Typo_Metrics) | Do not set / disabled | 0 | +| OS/2.usWinAscent | Font bbox yMax | 1066 | +| OS/2.usWinDescent | Font bbox yMin | 273 | +| OS/2.fsSelection bit 7 (Use_Typo_Metrics) | Set / enabled | ✅ | +| BASE table | Required | | +| vhea / vmtx tables | Required | | -Our decision to follow the Adobe schema was based on Dr. Ken Lunde’s comments and his release notes on Source Han Sans: +In the case of `sTypoAscender` and `sTypoDescender`, a range of values is acceptable, per the designer's perspective and specific needs. Generally ~18% tends to produce good results, but depending on the project, wider or narrower metrics may be required. + +Unfortunately, many typesetting environments still expect that the `sTypoMetrics` will align with the em-box. As such, the `BASE` table and `vhea` / `vmtx` tables are now required. See sections below. + +These metrics were established based on investigations into improving metrics performance of CJK fonts across the library. Please see the following issue for more information: +- + +### Base Table + +In addition to the above metrics, CJK fonts are now required to include a `BASE` table (https://learn.microsoft.com/en-us/typography/opentype/spec/baselinetags) to ensure broad compatibility. + +For a standard square em-box font (1000 units / 1000UPM), such as [Iansui](https://github.com/ButTaiwan/iansui), the following BASE table is added to the `.fea` file. +``` +table BASE { + HorizAxis.BaseTagList icfb icft ideo romn; + HorizAxis.BaseScriptList DFLT ideo -67 827 -120 0, + hani ideo -67 827 -120 0, + kana ideo -67 827 -120 0, + latn romn -67 827 -120 0, + cyrl romn -67 827 -120 0, + grek romn -67 827 -120 0, + + VertAxis.BaseTagList icfb icft ideo romn; + VertAxis.BaseScriptList DFLT ideo 53 947 0 120, + hani ideo 53 947 0 120, + kana ideo 53 947 0 120, + latn romn 53 947 0 120, + cyrl romn 53 947 0 120, + grek romn 53 947 0 120, +} BASE; +``` +The BASE tags above are: + +- `icfb`: Ideographic character face bottom edge (in HorizAxis) / left edge (in VertAxis) +- `icft`: Ideographic character face top edge (in HorizAxis) / right edge (in VertAxis) +- `ideo`: ideographic em-box bottom edge (in HorizAxis) / left edge (in VertAxis) +- `romn`: Latin baseline. Usually 0 in HorizAxis, inverse of ideo in VertAxis + +Some additional tags which may be useful can be reviewed on the [official documentation](https://learn.microsoft.com/en-us/typography/opentype/spec/baselinetags). + +In the case of a design that varies from the standard square em-box, you must also include `idtp` to mark the 'top' / 'right' edge of the em-box (opposite of `ideo`). For example, [WD XL Lubrifont](https://github.com/NightFurySL2001/WD-XL-font), which has a rectangular em-box with an advance width of 765, has the following base table: + +``` +table BASE { + HorizAxis.BaseTagList icfb icft ideo idtp romn; + HorizAxis.BaseScriptList DFLT ideo -104 814 -120 880 0, + hani ideo -104 814 -120 880 0, + kana ideo -104 814 -120 880 0, + latn romn -104 814 -120 880 0, + cyrl romn -104 814 -120 880 0, + grek romn -104 814 -120 880 0; + + VertAxis.BaseTagList icfb icft ideo idtp romn; + VertAxis.BaseScriptList DFLT ideo 49 716 0 765 0, + hani ideo 49 716 0 765 0, + kana ideo 49 716 0 765 0, + latn romn 49 716 0 765 0, + cyrl romn 49 716 0 765 0, + grek romn 49 716 0 765 0; +} BASE; +``` +Note the `idtp` value in the VertAxis is present to indicate the narrower width. + +### vhea and vmtx tables +In order for the `vmtx` and `vhea` tables to be generated via `fontTools`, vert-specific metrics must be set in the source prior to build. + +In `Glyphs`, these are: +- `vheaVertAscender` +- `vheaVertDescender` +- `vheaLineGap` + +If building from `.ufo`, these are: +- `openTypeVheaVertTypoAscender` +- `openTypeVheaVertDescender` +- `openTypeVheaLineGap` + +`vheaVertAscender` is the distance from the center of the glyph to the left edge (generally 500 for a `1000UPM` font). +`vheaVertDescender` is the distance from the center of the glyph to the right edge (generally -500 for a `1000UPM` font). +`vheaLineGap` is the horizontal space between lines of text. + +Most build systems (such as `makeotf` & `glyphsLib`) expect the `sTypoMetrics` to align with the font em-box, and use the `sTypoMetrics` to determine values in the `vmtx` and `vhea` tables. So the advancedHeight set in the `vmtx` table will be larger than the intended em-box value, leading to undesireable space when the font is set vertically. + +**Solutions** +It is possible to add in an override method into the `.fea` file which can correct for this issue. For example: + +``` +table vmtx { + VertOriginY uni30FC.vert 830; + VertAdvanceY uni30FC.vert 900; +} vmtx; +``` + +However, this approach (unless scripted), is cumbersome for a font on the scale of CJK. + +Two alternate options using a post-production script: + +1) Insert the incorrect `sTypo` data into the font, then correct the font metrics afterwards. The downside of this approach is that the source is not accurate to the output of the font. + +2) Use the correct `sTypo` data in the font, then correct the `vhea` and `vmtx` tables in post-production to follow the em-box data. While this approach is not ideal either, once the toolchains catch up, the post-production script can be removed and the output will remain the same. -- -- [SourceHanSansReadMe.pdf](https://github.com/adobe-fonts/source-han-sans/raw/release/SourceHanSansReadMe.pdf) ------------------------------------------------------------------------ @@ -284,4 +382,4 @@ Our decision to follow the Adobe schema was based on Dr. Ken Lunde’s comments + --> \ No newline at end of file From 268de4fdfe0c0bb2459cf3095575c521adc4a7ec Mon Sep 17 00:00:00 2001 From: Emma Marichal Date: Fri, 5 Dec 2025 15:57:53 +0100 Subject: [PATCH 03/11] onboarding.md: fix formatting issues + typos --- gf-guide/onboarding.md | 31 ++++++++++++++++++------------- 1 file changed, 18 insertions(+), 13 deletions(-) diff --git a/gf-guide/onboarding.md b/gf-guide/onboarding.md index 647fd1e..8bc6d91 100644 --- a/gf-guide/onboarding.md +++ b/gf-guide/onboarding.md @@ -46,7 +46,7 @@ If you would like to include a new font family in the Google Fonts collection, w - **The project must be wholly licensed under the** **[SIL Open Font License v1.1](http://scripts.sil.org/OFL).**
- There must also be no proprietary/restricted-license versions of the project available elsewhere (such as additional weights/styles). Agreeing to publishing a font on Google Fonts means that you agree to licensing under the OFL all the existing styles of a same family, and the ones to come. For example, Mono, Proportional, Display, Text, Serif, Sans-Serif… are considered styles (or subfamilies) of the same font family, and should therefore be open source as well. + There must also be no proprietary/restricted-license versions of the project available elsewhere (such as additional weights/styles). Agreeing to publish a font on Google Fonts means that you agree to license under the OFL all existing styles of the same family, and future ones. For example, Mono, Proportional, Display, Text, Serif, Sans-Serif… are considered styles (or subfamilies) of the same font family, and should therefore be open source as well.

Refer to the dedicated chapter to know more about the [license file requirements](license-file.md). @@ -55,7 +55,7 @@ If you would like to include a new font family in the Google Fonts collection, w - **The copyright holders must all have filled in the** **[Google Contributor's License Agreement](https://cla.developers.google.com/)** **forms.** -- **The font family name should not include any sensitive, sexual, stereotype, annoying or otherwise objectional words.** +- **The font family name should not include any sensitive, sexual, stereotypical, annoying or otherwise objectionable words.** - **The font family name should not include any copyright holder's full names or acronyms.** @@ -73,7 +73,7 @@ If you would like to include a new font family in the Google Fonts collection, w - **The project must be developed on GitHub or similar platform.**
- A VCS open to public participation and actively maintained. Please read our [Github guide](hosting.md). + A VCS that is open to public participation and actively maintained. Please read our [Github guide](hosting.md). - **The source files are available** in your preferred font editor format.
@@ -149,15 +149,20 @@ You can request the addition or modification of your name, bio, and image using You can find more about the technical aspect of adding a profile to google/fonts repo by reading the [Designer Profile chapter](profile.md). --> -
- -Further reading: -**must→** **[Overall font requirements](./requirements)** -**must→** **[Static fonts specifics](./static)** -**must→** **[Variable fonts specifics](./variable)** -**must→** **[Vertical metrics](./metrics)** -**must→** **[Production requirements](./production)** -nerd→ [Project Prioritization](./prioritization) - + Further reading:
+ must→ Overall font requirements +
+ must→ QA - Local testing +
+ must→ Static fonts specifics +
+ must→ Variable fonts specifics +
+ must→ Vertical metrics +
+ must→ Production requirement +
+ must→ Project Prioritization
+ From 960debe6cf5200e99694d9990332c987185d8fd5 Mon Sep 17 00:00:00 2001 From: Emma Marichal Date: Thu, 18 Dec 2025 14:59:40 +0100 Subject: [PATCH 04/11] Index.md typos corrections --- gf-guide/index.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/gf-guide/index.md b/gf-guide/index.md index 113a61a..7c485f2 100644 --- a/gf-guide/index.md +++ b/gf-guide/index.md @@ -6,7 +6,7 @@ 🦜 This guide aims to help people navigate the requirements and recommendations for contributing to Google Fonts. The contents covered here range from general knowledge to contextualize the what and why of some of the requirements as well as the specifics regarding technical aspects with some suggestions on how to comply with them. It covers different levels of information for both newcomers and more experienced contributors. -Therefore, this documentation is not meant to be read at once. If you are already familiar with some of the concepts, for example, some people are more empowered with the use of Github please you can skip some chapters and jump to the other bits that you may be looking for. The guidelines have been separated into small bits to facilitate the search of specific information that you would need at a specific stage of the font production. +Therefore, this documentation is not meant to be read at once. If you are already familiar with some of the concepts, for example, some people are more empowered with the use of GitHub please skip some chapters and jump to the other bits that you may be looking for. The guidelines have been separated into small bits to facilitate the search of specific information that you would need at a specific stage of the font production.