Add Ogonek 64 Mono

**Font Project Git Repo URL:**

https://github.com/arekbr/ogonek64

**Super short description of the Font Family:**

Ogonek 64 Mono is a monospaced pixel typeface on an 8×12 grid, in the spirit of early
8-bit home computer character sets, with the complete GF Latin Core glyphset and a full
set of Polish diacritics — something those character sets never had. Two styles, Regular
and Bold. Built for terminals and code.

The repository also contains two sibling families built from the same sources — Ogonek 64
Sans (proportional) and Ogonek 64 CRT (scanline display face). I am submitting Mono first;
happy to open separate issues for the other two if you would like to see them.

**Why this family, given the pixel faces already in the catalogue:**

General-purpose pixel faces in Google Fonts do cover Central European: VT323, Pixelify Sans and
Handjet all have 18/18 Polish letters and the full Latin Core, and Press Start 2P has 18/18 as well.
The gap is in one specific corner — faces that reproduce the raster character sets of 8-bit home
computers. Measured with `fontTools` on the TTF files currently in this repository (`cmap` coverage,
GF Latin Core taken from the `glyphsets` package). The last row is the family proposed here,
measured the same way:

| family in the catalogue | Polish letters | GF Latin Core |
|---|---|---|
| Sixtyfour | 2/18 | 201/319 |
| Workbench | 2/18 | 199/319 |
| Silkscreen | 2/18 | 209/319 |
| DotGothic16 | 4/18 | 220/319 |
| **Ogonek 64 Mono** *(this submission)* | **18/18** | **319/319** |

Sixtyfour is described in the catalogue as *"a rework of some old pixel versions of the Commodore 64
and Amiga Workbench fonts"* — that is exactly the tradition this family comes from, and exactly where
Central European diacritics are missing.

This is a long-standing, practical problem in the retro-computing community, not a theoretical one.
The TrueType conversion that the Commodore 64 scene actually uses has **no Polish letters at all**,
and its licence forbids modification and redistribution — so nobody can legally fix it, however much
they want to. People writing about these machines in Polish, Czech, Hungarian or Turkish either drop
their own diacritics or drop the typeface. Ogonek 64 exists to close that gap under a licence that
lets anyone build on it: the whole point of putting it under the OFL with no Reserved Font Name.

**Requirements:**

- [x] The entire font project is available in a Github repository (repo) and licensed under the OFL
- [x] I confirm that by 'entire font project', no "plus" or "pro" or other larger version of the project exists as a retail font anywhere
- [x] The source files are available in the repo
- [x] I am the sole copyright author of the entire project, or all other copyright authors have licensed their work to me under the OFL, and I commit to clearly disclosing if AI tools were used in the creation of this project.
- [x] There are no "Reserved Font Names" in the OFL license information, or in the project documentation of any known upstream projects.
- [x] The family name is unique according to namecheck.fontdata.com
- [x] The name of the font family expected to appear on app menus must be very clearly communicated and definitive. It should not include any copyright holder's full names or acronyms.
- [x] The font supports at least the Google Fonts 'Latin Core' glyphset
- [x] The repo has the Google Fonts preferred upstream repo structure
- [x] I have read, agree with, and comply with, the full Google Fonts contributing requirements
- [x] I will maintain the repository and participate in the onboarding process

**AI tools disclosure:**

The fonts are generated by code rather than drawn in a font editor, so I want to be precise
about what that means.

The build tooling (`sources/*.py`), the QA scripts and the glyph-composition rules were
written **with AI assistance (Claude, Anthropic)**, directed and reviewed by me throughout.
No part of the process is a black box: the composition is deterministic, and two independent
builds differ only in the `head.modified` timestamp.

What the code actually does:

- The Latin base is a **one-time export of the character ROM of a 1982 8-bit home computer**
into a pixel map, kept from then on as a plain text file in the repo (`#` = pixel on).
No ROM binary is redistributed. On an 8×8 grid a legible Latin capital has essentially one
solution; the US position on typeface designs (37 CFR § 202.1(e), *Eltra Corp. v. Ringer*)
is summarised in `documentation/PRAWO.md`.
- Diacritics, punctuation and the GF Latin Core additions are **composed deterministically**
from a base letter plus a mark, by rules in `sources/zrob_glify.py` and
`sources/glify_latin.py`.
- **Every shape decision was made and approved by me, on rendered proofs** — and those are
the decisions that determined whether the font is readable at all: giving accents two rows
plus a pixel of clearance from the letter; distinguishing `Ź` from `Ż` by stroke weight
rather than by a one-pixel offset; deriving the bar of `Ł`/`ł` from the position of the
stem instead of hardcoding it; letting the accent replace the dot on `i`/`j`. In each case
the table-level checks passed both the good and the bad variant — only looking at the
rendering caught the difference. The same applies to the standalone spacing marks, which
I moved to accent height after seeing a full glyph sheet.

**QA:**

`fontbakery check-googlefonts` — **0 FAIL across 455 check executions** for each of the three
families. Remaining WARNs are the ones inherent to a pixel face (`contour_count`,
`unreachable_subsetting`) plus `alt_caron`, where the Czech apostrophe-style caron for
`ď ľ ť` is a design choice I am happy to revisit if you prefer it.

Coverage: 321 characters — GF Latin Core complete, 18/18 Polish diacritics, 14 zero-width
combining marks, Polish punctuation. UPM 2048, `OS/2` version 4 with `USE_TYPO_METRICS`,
`fsType 0`, `gasp` and `prep` present, contours clockwise.

**Note:** I previously opened PRs #10815, #10816 and #10817 before understanding the process
— thanks to @emmamarichal for pointing me to the right way in. Closing that loop here.

**Image:**


All 321 characters at a glance: [`documentation/arkusz-znakow.png`](https://github.com/arekbr/ogonek64/blob/main/documentation/arkusz-znakow.png) · the four styles side by side: [`documentation/specimen-odmiany.png`](https://github.com/arekbr/ogonek64/blob/main/documentation/specimen-odmiany.png)

Start by reviewing the linked ogonek64 repository, especially sources/zrob_glify.py, sources/glify_latin.py, documentation/PRAWO.md, and the specimen images. Run fontbakery check-googlefonts against the submitted family and inspect the reported WARNs; done means the Google Fonts requirements are satisfied and the Mono family is ready for onboarding.

Written by the indexing model from the issue text.