Embed Andika in BloomPUBs made for RAB apps (BL-17007)

[andrew-polk]

Problem

In apps built on Publish > Apps (Reading App Builder), text in Andika shows in the phone's own font. A reader sees a two-story "a" instead of Andika's single-story one. Other fonts work. A tester reported it on 6.5.101 Beta.

Cause

BloomPUBs never embed Andika, because Bloom Reader and other hosts supply it to bloom-player. A RAB app doesn't:

• It ships Andika's files under host/fonts/Andika-Regular.woff2 and similar names, but bloom-player asks for host/fonts/Andika, so it never finds them (sillsdev/app-builders#2510).
• RAB apps have no internet permission, so bloom-player's last fallback (downloading the font from bloomlibrary.org) fails even when the phone is online.

Status: a stopgap

The real fix belongs in Reading App Builder (sillsdev/app-builders#2510). We've decided to ship this Bloom-side stopgap until it arrives. After it merges to master, it also goes to Version6.5 in a separate PR.

What the PR does

• BloomPUBs made for an app now embed Andika like any other font: only the faces the book's text uses, with the usual fonts.css rules. Other BloomPUBs (Bloom Reader, the library, USB/Wi-Fi) are unchanged.
• Text set in "Andika New Basic", the font Andika replaced, gets the same treatment. Bloom Reader answers requests for that font with Andika, but an app can't, so in an app's BloomPUB the book's references to it are rewritten to Andika by the rewrite Bloom already uses for fonts it can't embed.
• The rewrite Bloom uses to replace a font it can't embed now also catches a font name in double quotes, or in quotes in a book's own text styles. Before, such references kept the old font. This applies to every ePUB and BloomPUB, not just apps.
• A comment at the pinned RAB version says to remove this once Bloom moves to a RAB that fixes Move non-xml files to subfolders in epubs (BL-6037) #2510.

An earlier version of this branch, which shipped one copy of Andika per app, showed Andika on a phone. This final version hasn't been on a phone yet. Its APK holds only the faces the book uses (Regular and Bold for the test book), and the book's own Andika rules come last in fonts.css, so they win.

Risk Evaluation

Low. Most of the change sits behind a flag that only the app path sets. When it isn't set, EmbedFonts behaves exactly as before. The exception is the font-replacement rewrite (FixCssReferencesForBadFonts, FixXmlDomReferencesForBadFonts), which every ePUB and BloomPUB runs when a book uses a font Bloom can't embed. It now also matches quoted names, and treats the font name as literal text rather than a pattern. When it is set, Andika goes through the same embedding code every other font already uses. Bloom's font lookup already includes the fonts Bloom serves from DistFiles/fonts, the same route ABeeZee takes.

Ecosystem Impact

• Apps built outside Bloom: not fixed. A BloomPUB saved from the BloomPUB tab and added to RAB by hand still has no Andika. Only RAB's fix covers that.
• RAB apps: each book that uses Andika carries the faces it needs (about 0.27 MB each). That's the same per-book cost as any other embedded font.
• Other BloomPUBs, Bloom Reader, bloom-player, ePUB, PDF: unchanged.
• When RAB fixes Move non-xml files to subfolders in epubs (BL-6037) #2510: an app would carry Andika twice until we remove this. Nothing breaks.
• Localization: no new strings. Dependencies: none changed.

E2E Coverage

No end-to-end test builds an app, because that needs RAB and a Gradle build. The opt-in RabRealBuildTests real-build test passed on Andrew's machine. New unit tests check that EmbedFonts embeds Andika, and points Andika New Basic text at it, only when asked.

Notion Test Suite

Two existing manual test cases now check Andika and Charis SIL in the built app on an offline phone (6.6 runs). Both are manual (no automation).

• 831 Basic Install of RAB for Bloom
• 799 Bloom Apps using stand-alone RAB

Preflight report: https://bloombooks.github.io/dev-process-artifacts/deciders/bloomdesktop-bl-17007-rab-andika.html

Ref: https://issues.bloomlibrary.org/youtrack/issue/BL-17007

🤖 Generated with Claude Code

Devin review

---

This change is 

[andrew-polk]

[Claude Opus 5.5 from Andrew Polk's machine during preflight] Consulted Devin on 2026-10-09 up to commit 7f96c5e. It raised one bug (Andika New Basic text still uses the phone's font in apps; left open for the developer's decision) and one flag to investigate (cached BloomPUBs bypassing the new flag; not an issue, since the cache is cleared each time the Apps screen opens). Both have their own review threads. No informational items.

[hatton]

[Claude Opus 5.5 from Hatton's machine during preflight] Consulted Devin on 2026-10-10 up to commit 9a8aa8b. Since the last log it found one new bug, that quoted "Andika New Basic" names were not rewritten. That is fixed in 9a8aa8b, and Devin now marks it resolved. It also raised two flags: one about the test was not an issue, and one about the out-of-date PR description was already fixed. The earlier Andika New Basic bug is fixed in 565f078. Each has its own resolved thread. No other findings.