Skip to content

fix(countdown): make every offered font work, and document every setting - #363

Merged
ChuckBuilds merged 1 commit into
mainfrom
docs/countdown-readme
Sep 2, 2026
Merged

fix(countdown): make every offered font work, and document every setting#363
ChuckBuilds merged 1 commit into
mainfrom
docs/countdown-readme

Conversation

@ChuckBuilds

Copy link
Copy Markdown
Owner

Fifth plugin in the README pass. Still avoiding the sports scoreboards while #359 is open.

Only two of five fonts worked

Hashing one render per family showed three producing byte-identical output — the default face:

9bd0dbce77: ['press_start']
b59efdfd01: ['four_by_six']
d6e4d86478: ['tom_thumb', 'tiny', 'picopixel']

Two separate causes:

  • tiny and picopixel have no font file in the core or the plugin. Phantom options; removed.
  • Everything .bdf hit the pixel-size problem — a bitmap face exists at exactly one size and FreeType rejects any other, so asking for font_size (8) failed every time. Now loaded at the size the file's own PIXEL_SIZE header declares.

That alone wasn't enough for five_by_seven, and the reason is worth knowing: the plugin only reached its own loader when the core FontManager's catalog missed a family. The catalog has five_by_seven, so resolve_font returned a silently degraded default and the plugin trusted it. Bitmap families now use the plugin's loader regardless of what the catalog claims. tom_thumb is also wired up — tom-thumb.bdf was always shipped, just absent from the family map.

All four now render distinctly, verified the same way:

9bd0dbce77 press_start   |  b59efdfd01 four_by_six
eb2d9294c8 five_by_seven |  0ed03a8f38 tom_thumb

Net: 2 of 5 working → 4 of 4 working, rather than just deleting the broken ones.

There is a latent core issue behind this: FontManager.resolve_font degrades to the default face for any .bdf without signalling it. I worked around it in the plugin rather than widening this PR into the core repo — say the word if you'd like the core fix too.

The old README documented strings the code never produces

It promised "1 Day" and "TODAY!" (shown in bright yellow). Neither exists anywhere in manager.py. The real ladder, now shown as six real renders:

Time to target Renders as
> 2 days N Days
1–2 days Tomorrow (no number)
1–24 hours Nh Nm
1–60 minutes Nm
< 1 minute NOW!
passed Nd ago, hidden unless show_expired

Also corrected: the stale Pillow >= 9.0.0 requirement is actually >= 12.2.0.

Audits before opening (as requested)

  • Config tokens vs the old README: none dropped
  • All 40 schema leaves documented (including the per-entry layout and style override objects)
  • No broken TOC anchors
  • Section-heading check surfaced the dependency and technical notes — restored

Worth noting the section check is a heuristic and flagged ten headings, most of them false positives once I read the content. It's a prompt to go look, not an oracle.

Verification

  • python scripts/check_plugin.py --plugin countdown8/8 PASS, goldens unchanged (the harness pins press_start, a .ttf, so the font work doesn't move them)
  • python scripts/run_plugin_tests.py countdown — 1 passed
  • render_docs_assets.py --plugin countdown --check — images match
  • check_module_collisions.py — OK across 43 plugins
  • manifest bumped 3.2.1 → 3.3.0, plugins.json regenerated

🤖 Generated with Claude Code

Only two of the five font families in the picker actually rendered. Hashing a
render per family showed three producing byte-identical output -- the default
face -- from two separate causes:

  9bd0dbce77: ['press_start']
  b59efdfd01: ['four_by_six']
  d6e4d86478: ['tom_thumb', 'tiny', 'picopixel']

tiny and picopixel have no font file in the core or the plugin, so they could
only ever fall back; they are removed. The rest is the .bdf pixel-size problem:
a bitmap face exists at exactly one size and FreeType rejects any other, so
asking for font_size (8) failed for every bitmap family. Bitmap faces are now
loaded at the size the file's own PIXEL_SIZE header declares.

That alone was not enough for five_by_seven. The plugin only reached its own
loader when the core FontManager's catalog *missed* a family, and the catalog
has five_by_seven -- so resolve_font returned a silently degraded default and
the plugin trusted it. Bitmap families now go through the plugin's loader
regardless of what the catalog claims. tom_thumb is also wired up: tom-thumb.bdf
was always shipped, just absent from the family map.

All four families in the new enum now render distinctly, verified the same way:

  9bd0dbce77 press_start | b59efdfd01 four_by_six
  eb2d9294c8 five_by_seven | 0ed03a8f38 tom_thumb

The README is rewritten around real screenshots and documents all 40 settings,
including the per-entry layout and style override objects. It also corrects the
countdown-value ladder, which the old version got wrong: there is no "1 Day"
and no "TODAY!" anywhere in the code. Between one and two days out the plugin
writes "Tomorrow" with no number, and a passed countdown reads "Nd ago" and is
hidden entirely unless show_expired is on. Every rung is now shown as a real
render. The stale Pillow >= 9.0.0 requirement is corrected to >= 12.2.0.

Audits before opening: no config token dropped, all 40 schema leaves
documented, no broken TOC anchors, and the dropped-section check surfaced the
dependency and technical notes, which are restored. Harness 8/8 with goldens
unchanged -- the harness pins press_start, a .ttf, so the font work does not
move them.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@coderabbitai

coderabbitai Bot commented Sep 2, 2026

Copy link
Copy Markdown
Contributor

Important

  • 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Team

Run ID: a8a7dcfa-bd8a-413d-8891-8dabe68a80ed


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@codacy-production

Copy link
Copy Markdown

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 13 complexity

Metric Results
Complexity 13

View in Codacy

NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.

@ChuckBuilds
ChuckBuilds merged commit 9ddef9a into main Sep 2, 2026
4 checks passed
@ChuckBuilds
ChuckBuilds deleted the docs/countdown-readme branch September 2, 2026 20:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant