1. Overview

Each designer in the Google Fonts catalog has a profile page with a short biography. These bios serve as the public-facing introduction to the people and organizations behind the typefaces in the library. They should be concise, accurate, and professional.

Bios are stored as HTML in the bio.html file within each designer's directory in the google/fonts repository at catalog/designers/{designer_id}/bio.html.

2. Bio Structure

Every bio follows a consistent structure:

3. Voice and Perspective

4. Writing for Individual Designers

For individual type designers, the opening sentence should follow this pattern:

If the location is unknown, omit the "based in" clause. If the designer has multiple roles, list the most relevant ones:

After the opening, provide 1–3 sentences of context. Prioritize in this order:

1. Notable typefaces in the Google Fonts library
2. Professional background relevant to type design
3. Education in type design or related fields
4. Foundry affiliation or studio
5. Awards and recognitions (stated factually, not promotionally)

5. Writing for Studios and Foundries

For organizations, the opening should identify what the entity is, where it is located, and who founded it:

For companies with a broader mission statement (beyond type), keep it brief and focused on their type-related work.

6. Length Guidelines

The links paragraph at the end does not count toward the word limit.

7. What to Include

8. What to Avoid

The following elements must never appear in designer biographies. These policies ensure consistency, professionalism, and accuracy across the catalog.

9. Link Formatting

Links go in the final paragraph of the bio, separated by pipes with spaces:

Preferred link order: Personal website, then social profiles alphabetically (Behance, GitHub, Instagram, LinkedIn, X/Twitter).

10. HTML Format Reference

Bios are stored as HTML fragments (not full documents). The only tags used are:

Do not use <b>, <i>, <br>, <div>, <span>, or any other HTML tags. Keep the markup minimal.

<p>{Full Name} is a {role} based in {City, Country}. {Additional context}.</p>
<p><a href="https://website.com" target="_blank">website.com</a> | <a href="https://instagram.com/handle" target="_blank">Instagram</a></p>

11. Examples

Minimal bio (1 sentence + links)

<p>Alexander Örn is a type designer based in Malmö, Sweden
and co-founder of Kanon Foundry.</p>

Standard bio (2–3 sentences + links)

<p>Abdullah Aref is an Egyptian art teacher, calligrapher,
and Arabic type designer.</p>
<p><a href="https://www.behance.net/abdoullah_aref"
target="_blank">Behance</a> | <a
href="https://www.facebook.com/areffonts"
target="_blank">Facebook</a></p>

Detailed bio (multiple paragraphs + links)

<p>Alexei Vanyashin is a type designer and Cyrillic
specialist dedicated to thoughtful, collaborative work.
After graduating from BHSAD Moscow in 2010, he founded
Cyreal, the foundry behind popular open-source fonts such
as Lora, Prata, and Alice. ...</p>
<p><a href="https://alexeiva.cyreal.org">alexeiva.cyreal.org
</a> | <a href="https://instagram.com/avanyashin">Instagram
</a></p>

Studio/foundry bio

<p>Based in Lagos, Nigeria, Afrotype, founded by Seyi
Olusanya, intends to subvert cliches around African graphic
design and identity by creating typefaces that are grounded
in African history and culture.</p>
<p><a href="https://www.afrotype.com">afrotype.com</a>
| <a href="https://x.com/useafrotype">X
</a></p>

12. Pre-Submission Checklist

Key Finding: Most Patterns Already Covered

After reviewing the gftools-builder documentation, we discovered that the builder already has features covering the top pre-build patterns:

The originally proposed mergeUFOs config key is largely redundant with the existing includeSubsets, which already supports local files, remote repos, named glyphsets, codepoint ranges, layout handling, and force-replace.

Context

Many upstream Google Fonts repos need to run preparation commands before invoking gftools-builder. Currently they do this with custom wrapper scripts (build.sh, build.py, Makefiles), which means they can't use a pure config.yaml-driven build. Simon Cozens, and presumably also Rod Sheeter, oppose a generic preCompile shell-execution feature (issue #1170). Instead, we should implement well-defined, declarative builder operations for the most common patterns.

Data source: Full scan of 404 Makefiles and 86 build.py/build.sh files across 280 organizations in the fontc crater cache, plus GitHub code search results.

Action Types Summary

Priority Assessment (Revised)

Existing Feature: includeSubsets

~47 repos depend on ufomerge (5 with explicit merge scripts + ~42 as build dependency), making UFO merging the most widespread pre-compile operation. The builder's existing includeSubsets config key already provides declarative UFO merging:

sources:
  - sources/MyFont.designspace
includeSubsets:
  - from: "Noto Sans"
    name: GF_Latin_Core
  - from: {repo: "notofonts/devanagari", path: "sources/NotoSansDevanagari.glyphspackage"}
    name: Devanagari
    layoutHandling: closure
  - from: "path/to/local/donor.designspace"
    ranges:
      - start: 0x3000
        end: 0x30FF
    force: replace

includeSubsets supports local files, remote GitHub repos (with version refs), pre-defined Noto sources, named glyphsets, custom Unicode ranges, layout/kerning handling, force-replace, and glyph/codepoint exclusions. When used with Glyphs sources, the conversion to UFO happens automatically via glyphs2ds.

Repos to Investigate for includeSubsets Migration

These repos currently use custom merge scripts and should be checked to see if includeSubsets can replace them:

Migration Analysis

Per-repo assessment of whether pre-build scripts can be fully replaced by existing gftools-builder features.

Fully Convertible (3 repos)

These repos can eliminate their pre-build scripts entirely today by pointing sources: directly at their .glyphs/.glyphspackage files:

Partially Convertible (10 repos)

The merge/conversion parts can use existing features, but other operations still need custom scripts or new builder features:

Not Convertible (3 repos + 2 siblings)

These repos have pre-build scripts too custom for any existing builder features:

Grouped Missing Features (Proposals)

Missing gftools-builder features grouped by type, ordered by priority and number of repos that would benefit.

Full Repo Inventory

Complete inventory of repos and their pre-compile action types.

Key Insights (Revised)

1. 3 repos can convert today — 42dot-Sans, Asta-Sans, and Overpass can eliminate pre-build scripts by pointing sources directly at .glyphs/.glyphspackage files
2. 10 repos are partially convertible — merge/conversion parts work with existing features, but designspace manipulation, target subsetting, and source modification gaps block full migration
3. preCompile hooks would unblock all 13 repos — despite opposition to generic shell execution (issue #1170), it's the single most impactful missing feature
4. Source-level DS manipulation is the most targeted gap — a dropSources/axisRanges/dropAxes config would help 3 Google Sans repos
5. Other gaps are too niche — include_glyphs (youtube-sans only), target UFO subsetting (googlesans-gurage only), custom filter injection (2 repos)
6. ~66 repos have fully custom pipelines not using gftools-builder — builder features won't help them

Project Overview

The Google Fonts Agents Dashboard is a data-driven, single-page web application that serves as a centralized monitoring tool for the Google Fonts ecosystem. It is built using a vanilla tech stack (HTML5, CSS3, and JavaScript) to ensure it is lightweight and easy to deploy.

Key Features & Capabilities:

• Progress Tracking (Library Sources): Visualizes the status of documenting upstream font repositories.
• Repository Auditing: Verifying METADATA.pb repository_url and commit hash.
• Designer Catalog: Displays Google Fonts designer profiles and biographies.
• Workflow Management: Tracks pending PRs and questions for maintainers.
• Research & Diagnostics: Analyzes build approaches, fontc_crater failures, and disk usage.
• Reporting: Generates Friday Status updates and Bio Audit compliance reports.

Technical Details:

• Data Source: Fetches data from JSON files in the data/ directory, generated by Python scripts.
• Navigation: Tabbed interface with URL fragment tracking.
• Local Server: Uses a run.sh script (Python-based local server).

Workflow: Adding fontc_crater Targets

The workflow for adding more fontc_crater targets involves enriching font family metadata in the google/fonts repository. This allows the fontc compiler to identify, build, and test these fonts.

1. Requirements for Enrollment

A font family's METADATA.pb must contain:

• repository_url: Upstream Git repository URL.
• commit: Specific Git commit hash.
• config_yaml: Path to a gftools-builder configuration (e.g., config.yaml).

2. The Discovery Process

• Scanning Upstream: scripts/find_config_yaml.py scans cached repositories for valid build configs.
• Local Overrides: If config.yaml exists locally in the family directory, it overrides the need for the config_yaml field in metadata.

3. Implementation Steps

1. Find the Config: Run discovery scripts to identify eligible families.
2. Update Metadata: Use scripts/add_config_yaml_to_metadata.py to update METADATA.pb.
3. Submit PR: Commit changes to google/fonts.
4. Update Targets: The fontc_crater repository must have its targets.json file updated via a PR before it can recognize the new targets. Such PR is prepared by running the google-fonts-sources tool that detects the config.yaml overrides and the relevant fields in METADATA.pb files of the google/fonts repository.