如何跑通 FiraCode 的 Google Fonts 上线流程用 build.sh 构建字体并用 move-check 运行 FontBakery 检查【免费下载链接】FiraCodeFree monospaced font with programming ligatures项目地址: https://gitcode.com/GitHub_Trending/fi/FiraCode要把 Fira Code带编程连字的免费等宽字体提交进 Google Fonts仓库里给出的官方 QA 流程在googlefonts-qa/目录下先用build.sh构建 Google Fonts 要求的可变字体与静态字体文件再用move-check把字体放入本地 google/fonts 仓库目录、对每个字体运行 FontBakery 的check-googlefonts并把检查结果保存为 Markdown 报告。本文按 googlefonts-qa/README.md 的说明走完整的一轮准备环境 → 构建 → 移动并检查 → 读报告决定下一步修改。README 明确要求在仓库的qa分支上开展该流程开始前先检出该分支。流程里各脚本负责什么googlefonts-qa/scripts/build.sh构建 Google Fonts 要求的可变与静态字体文件。当前仓库快照中它是软链接指向script/目录下的对应构建脚本。googlefonts-qa/scripts/move-check.sh依次修正少量字体元数据以符合 Google Fonts 标准把字体移入本地 google/fonts 仓库的ofl/firacode目录为向官方仓库提 PR 做准备运行 FontBakery 检查并把结果保存到googlefonts-qa/checks子目录脚本末尾的 git 操作见下文副作用说明。README 特别强调这个过程必须运行多次——每轮根据 FontBakery 报告修改源文件、重新构建字体、再次检查直到报告标记的问题被解决。所以一轮跑通的目标是产出新报告而不是报告立即全部通过。准备条件1. 克隆 FiraCode 仓库并检出 qa 分支QA 流程基于qa分支开发README 指示先检出该分支git clone https://gitcode.com/GitHub_Trending/fi/FiraCode.git cd FiraCode git checkout qa2. 本地克隆 google/fonts 仓库FontBakery 检查要求字体位于 google/fonts 仓库的目录结构内才有意义因此本地必须有一份 google/fonts 克隆这是运行该 QA 流程的前置条件git clone gitgithub.com:google/fonts.git克隆位置随意README 的示例是放到一个type_repos之类的父目录下记住绝对路径即可。3. 创建 Python 3 虚拟环境并安装 QA 依赖在 FiraCode 仓库根目录执行virtualenv -p python3 venv source venv/bin/activate pip install -U -r googlefonts-qa/scripts/requirements.txtrequirements.txt 中列出的依赖是fontbakery、gftools从 googlefonts 的 gftools 仓库安装和fontmake。注意这里有一处文档内部不一致README 原文写的是virtualenv -p python3 build/venv但同一 README 的激活命令、move-check.sh 内部执行的激活命令、以及 requirements.txt 头部注释都是venv/bin/activate/virtualenv -p python3 venv。虚拟环境必须建在仓库根目录的venv下否则激活路径以及脚本内部的激活会失败。4. 给两个脚本加执行权限chmod x googlefonts-qa/scripts/build.sh chmod x googlefonts-qa/scripts/move-check.sh另外move-check.sh 还会调用ttx和xml sel命令来提取可变字体的fontRevisionREADME 只列出了 requirements.txt 中的 Python 依赖没有列这两个工具运行前请确认它们在你的环境里可用缺失则自行补装。运行 build.sh 构建字体终端位于 FiraCode 仓库顶层运行googlefonts-qa/scripts/build.shREADME 说明该步骤的产出是 Google Fonts 要求的可变与静态字体文件。构建完成后move-check.sh 会从这两个路径读取产出distr/variable_ttf/FiraCode-VF.ttf可变字体distr/ttf/*.ttf各字重的静态字体如果按 README 操作仍然跑不通README 建议在项目的 issue 跟踪器中提交 issue。运行 move-check移动字体并执行 FontBakery 检查README 的简写形式是move-check absolute_path_to_parent_dir/fonts按脚本--help输出给出的完整调用方式执行googlefonts-qa/scripts/move-check.sh 本地 google/fonts 仓库目录的绝对路径占位符替换为你刚才克隆的 google/fonts 仓库目录的绝对路径脚本帮助输出的示例形式如/Users/your-username/type-repos/google-font-repos/fonts。运行前必须了解该脚本的副作用均来自 move-check.sh 脚本正文开头用ttx -t head提取可变字体的fontRevision会在distr/variable_ttf/下生成一个临时.ttx文件随后删除。进入本地 google/fonts 目录后依次执行git checkout master、git pull upstream master、git reset --hard、git checkout -B firacode、git clean -f -d——该目录中未提交的修改和未跟踪文件会被丢弃请确保这份 google/fonts 克隆是可以随意重置的工作副本并且已配置名为upstream的远端脚本用它拉取 master。复制字体与元数据可变字体拷为ofl/firacode/FiraCode-Light.ttf静态字体拷入ofl/firacode/static/同时复制 METADATA.pb、根目录LICENSE存为OFL.txt和 gfonts-description.html存为DESCRIPTION.en_us.html。在ofl/firacode内对每个字体执行fontbakery check-googlefonts 字体文件 --ghmarkdown 报告路径。最后执行git add .、git commit -m fira code: fontRevision added.和git push --force upstream firacode——向upstream远端强推firacode分支。该远端应指向你有写权限的仓库比如你自己的 fork否则推送会失败。README 正文没有提到这一步推送只说明脚本用途是为官方 google/fonts 仓库准备/更新 PR即使推送失败前面的检查结果已经生成。验证结果按 README 的 If all goes well 与脚本正文成功完成一轮的标志是本地 google/fonts 仓库目录中出现firacode分支ofl/firacode/下包含可变字体、static/子目录中的静态字体以及METADATA.pb、OFL.txt、DESCRIPTION.en_us.htmlfiracode分支上出现新的提交提交信息形如fira code: fontRevision added.fontRevision 取自构建出的可变字体FiraCode 仓库的googlefonts-qa/checks/目录刷新出 Markdown 报告可变字体对应FiraCode-Light.checks.md静态字体在static/子目录下如FiraCode-Regular.checks.md。仓库中现存的报告可直接参考格式。README 的 usage 一节把报告输出目录写作googlefonts-qa/scripts/checks但 README 开头、move-check.sh 的实现和仓库中实际存在的检查文件都指向googlefonts-qa/checks/以实际路径为准。读懂报告并决定下一步修改报告里每一条都是 FontBakery 的检查项带有检查 ID如com.google.fonts/check/unitsperem_strict和严重级别 FAIL / ⚠ WARN / ℹ INFO。可以查看 FiraCode-Light.checks.md 与 static/FiraCode-Regular.checks.md 了解形态。README 定义的迭代循环是按报告条目修改源文件 → 重新构建 → 再次运行 move-check直到标记的问题被解决。仓库中的 QA-notes.md 记录了该流程实际经历过的条目类型与当时的处理方式例如unitsperem_strictWARNunitsPerEm 为 1000建议改为 2000 → 将 UPM 缩放到 2000NAME 表 ASCII-only 检查 FAILCopyright 条目包含©符号 → 移除该符号win_ascent_and_descentFAILOS/2.usWinAscent为 935要求 ≥1050、usWinDescent为 265要求 ≥500→ 用 set-vertical-metrics.py 修正垂直度量后重新检查usweightclassFAILLight 的OS/2 usWeightClass为 400 而期望 300 → 在源 master 中设置Axis Location自定义参数解决。QA-notes 同时记录了少数被标记为已提交 issue / 等待外部反馈的条目如版权字符串模式、字形命名约定检查并非每个 FAIL 条目都意味着要改自己的源文件处理前先对照笔记判断归属。一轮跑通后你得到的是本地 google/fonts 目录中排好字体与元数据的firacode分支以及googlefonts-qa/checks/下的新报告。流程的设计就是多轮运行报告中仍有 FAIL 条目时按上文对应条目修改源、重新执行 build.sh 与 move-check直至报告干净。【免费下载链接】FiraCodeFree monospaced font with programming ligatures项目地址: https://gitcode.com/GitHub_Trending/fi/FiraCode创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 如何跑通 FiraCode 的 Google Fonts 上线流程：用 build.sh 构建字体并用 move-check 运行 FontBakery 检查
如何跑通 FiraCode 的 Google Fonts 上线流程用 build.sh 构建字体并用 move-check 运行 FontBakery 检查【免费下载链接】FiraCodeFree monospaced font with programming ligatures项目地址: https://gitcode.com/GitHub_Trending/fi/FiraCode要把 Fira Code带编程连字的免费等宽字体提交进 Google Fonts仓库里给出的官方 QA 流程在googlefonts-qa/目录下先用build.sh构建 Google Fonts 要求的可变字体与静态字体文件再用move-check把字体放入本地 google/fonts 仓库目录、对每个字体运行 FontBakery 的check-googlefonts并把检查结果保存为 Markdown 报告。本文按 googlefonts-qa/README.md 的说明走完整的一轮准备环境 → 构建 → 移动并检查 → 读报告决定下一步修改。README 明确要求在仓库的qa分支上开展该流程开始前先检出该分支。流程里各脚本负责什么googlefonts-qa/scripts/build.sh构建 Google Fonts 要求的可变与静态字体文件。当前仓库快照中它是软链接指向script/目录下的对应构建脚本。googlefonts-qa/scripts/move-check.sh依次修正少量字体元数据以符合 Google Fonts 标准把字体移入本地 google/fonts 仓库的ofl/firacode目录为向官方仓库提 PR 做准备运行 FontBakery 检查并把结果保存到googlefonts-qa/checks子目录脚本末尾的 git 操作见下文副作用说明。README 特别强调这个过程必须运行多次——每轮根据 FontBakery 报告修改源文件、重新构建字体、再次检查直到报告标记的问题被解决。所以一轮跑通的目标是产出新报告而不是报告立即全部通过。准备条件1. 克隆 FiraCode 仓库并检出 qa 分支QA 流程基于qa分支开发README 指示先检出该分支git clone https://gitcode.com/GitHub_Trending/fi/FiraCode.git cd FiraCode git checkout qa2. 本地克隆 google/fonts 仓库FontBakery 检查要求字体位于 google/fonts 仓库的目录结构内才有意义因此本地必须有一份 google/fonts 克隆这是运行该 QA 流程的前置条件git clone gitgithub.com:google/fonts.git克隆位置随意README 的示例是放到一个type_repos之类的父目录下记住绝对路径即可。3. 创建 Python 3 虚拟环境并安装 QA 依赖在 FiraCode 仓库根目录执行virtualenv -p python3 venv source venv/bin/activate pip install -U -r googlefonts-qa/scripts/requirements.txtrequirements.txt 中列出的依赖是fontbakery、gftools从 googlefonts 的 gftools 仓库安装和fontmake。注意这里有一处文档内部不一致README 原文写的是virtualenv -p python3 build/venv但同一 README 的激活命令、move-check.sh 内部执行的激活命令、以及 requirements.txt 头部注释都是venv/bin/activate/virtualenv -p python3 venv。虚拟环境必须建在仓库根目录的venv下否则激活路径以及脚本内部的激活会失败。4. 给两个脚本加执行权限chmod x googlefonts-qa/scripts/build.sh chmod x googlefonts-qa/scripts/move-check.sh另外move-check.sh 还会调用ttx和xml sel命令来提取可变字体的fontRevisionREADME 只列出了 requirements.txt 中的 Python 依赖没有列这两个工具运行前请确认它们在你的环境里可用缺失则自行补装。运行 build.sh 构建字体终端位于 FiraCode 仓库顶层运行googlefonts-qa/scripts/build.shREADME 说明该步骤的产出是 Google Fonts 要求的可变与静态字体文件。构建完成后move-check.sh 会从这两个路径读取产出distr/variable_ttf/FiraCode-VF.ttf可变字体distr/ttf/*.ttf各字重的静态字体如果按 README 操作仍然跑不通README 建议在项目的 issue 跟踪器中提交 issue。运行 move-check移动字体并执行 FontBakery 检查README 的简写形式是move-check absolute_path_to_parent_dir/fonts按脚本--help输出给出的完整调用方式执行googlefonts-qa/scripts/move-check.sh 本地 google/fonts 仓库目录的绝对路径占位符替换为你刚才克隆的 google/fonts 仓库目录的绝对路径脚本帮助输出的示例形式如/Users/your-username/type-repos/google-font-repos/fonts。运行前必须了解该脚本的副作用均来自 move-check.sh 脚本正文开头用ttx -t head提取可变字体的fontRevision会在distr/variable_ttf/下生成一个临时.ttx文件随后删除。进入本地 google/fonts 目录后依次执行git checkout master、git pull upstream master、git reset --hard、git checkout -B firacode、git clean -f -d——该目录中未提交的修改和未跟踪文件会被丢弃请确保这份 google/fonts 克隆是可以随意重置的工作副本并且已配置名为upstream的远端脚本用它拉取 master。复制字体与元数据可变字体拷为ofl/firacode/FiraCode-Light.ttf静态字体拷入ofl/firacode/static/同时复制 METADATA.pb、根目录LICENSE存为OFL.txt和 gfonts-description.html存为DESCRIPTION.en_us.html。在ofl/firacode内对每个字体执行fontbakery check-googlefonts 字体文件 --ghmarkdown 报告路径。最后执行git add .、git commit -m fira code: fontRevision added.和git push --force upstream firacode——向upstream远端强推firacode分支。该远端应指向你有写权限的仓库比如你自己的 fork否则推送会失败。README 正文没有提到这一步推送只说明脚本用途是为官方 google/fonts 仓库准备/更新 PR即使推送失败前面的检查结果已经生成。验证结果按 README 的 If all goes well 与脚本正文成功完成一轮的标志是本地 google/fonts 仓库目录中出现firacode分支ofl/firacode/下包含可变字体、static/子目录中的静态字体以及METADATA.pb、OFL.txt、DESCRIPTION.en_us.htmlfiracode分支上出现新的提交提交信息形如fira code: fontRevision added.fontRevision 取自构建出的可变字体FiraCode 仓库的googlefonts-qa/checks/目录刷新出 Markdown 报告可变字体对应FiraCode-Light.checks.md静态字体在static/子目录下如FiraCode-Regular.checks.md。仓库中现存的报告可直接参考格式。README 的 usage 一节把报告输出目录写作googlefonts-qa/scripts/checks但 README 开头、move-check.sh 的实现和仓库中实际存在的检查文件都指向googlefonts-qa/checks/以实际路径为准。读懂报告并决定下一步修改报告里每一条都是 FontBakery 的检查项带有检查 ID如com.google.fonts/check/unitsperem_strict和严重级别 FAIL / ⚠ WARN / ℹ INFO。可以查看 FiraCode-Light.checks.md 与 static/FiraCode-Regular.checks.md 了解形态。README 定义的迭代循环是按报告条目修改源文件 → 重新构建 → 再次运行 move-check直到标记的问题被解决。仓库中的 QA-notes.md 记录了该流程实际经历过的条目类型与当时的处理方式例如unitsperem_strictWARNunitsPerEm 为 1000建议改为 2000 → 将 UPM 缩放到 2000NAME 表 ASCII-only 检查 FAILCopyright 条目包含©符号 → 移除该符号win_ascent_and_descentFAILOS/2.usWinAscent为 935要求 ≥1050、usWinDescent为 265要求 ≥500→ 用 set-vertical-metrics.py 修正垂直度量后重新检查usweightclassFAILLight 的OS/2 usWeightClass为 400 而期望 300 → 在源 master 中设置Axis Location自定义参数解决。QA-notes 同时记录了少数被标记为已提交 issue / 等待外部反馈的条目如版权字符串模式、字形命名约定检查并非每个 FAIL 条目都意味着要改自己的源文件处理前先对照笔记判断归属。一轮跑通后你得到的是本地 google/fonts 目录中排好字体与元数据的firacode分支以及googlefonts-qa/checks/下的新报告。流程的设计就是多轮运行报告中仍有 FAIL 条目时按上文对应条目修改源、重新执行 build.sh 与 move-check直至报告干净。【免费下载链接】FiraCodeFree monospaced font with programming ligatures项目地址: https://gitcode.com/GitHub_Trending/fi/FiraCode创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考