PDF export cannot use non-Latin-1 characters (e.g. ≥) in built-in fonts #11

New Issue

2026-07-31T12:20:35Z

willemjan commented

2026-07-31 12:20:35 +00:00

Symptom

Adding ≥ (or any other non-Latin-1 Unicode character) to text that goes into pdf_export.py crashes PDF generation:

fpdf.errors.FPDFUnicodeEncodingException: Character "≥" ... is outside the range of characters supported by the font used: "helveticaBI". Please consider using a Unicode font.

Root cause

pdf_export.py uses fpdf2's built-in core fonts (Helvetica), which only support Latin-1 encoding. Any text passed into pdf.cell()/pdf.multi_cell() must stick to Latin-1-safe characters. This bit us in reporting.completeness_warning(), whose message is shared between the Streamlit UI (fine with full Unicode, e.g. ≥) and the PDF summary section (not fine) — worked around for now by writing >= instead of ≥ in that specific string.

Proper fix (not urgent)

Embed a Unicode TTF font (e.g. DejaVuSans) via pdf.add_font(...) and switch pdf_export.py to use it, so PDF text isn't constrained to Latin-1 and doesn't silently diverge from the on-screen wording elsewhere in the codebase. Low priority — current workaround (avoid non-Latin-1 characters in any string that might reach the PDF) is sufficient until this is picked up.

**Symptom** Adding `≥` (or any other non-Latin-1 Unicode character) to text that goes into `pdf_export.py` crashes PDF generation: ``` fpdf.errors.FPDFUnicodeEncodingException: Character "≥" ... is outside the range of characters supported by the font used: "helveticaBI". Please consider using a Unicode font. ``` **Root cause** `pdf_export.py` uses fpdf2's built-in core fonts (Helvetica), which only support Latin-1 encoding. Any text passed into `pdf.cell()`/`pdf.multi_cell()` must stick to Latin-1-safe characters. This bit us in `reporting.completeness_warning()`, whose message is shared between the Streamlit UI (fine with full Unicode, e.g. ≥) and the PDF summary section (not fine) — worked around for now by writing `>=` instead of `≥` in that specific string. **Proper fix (not urgent)** Embed a Unicode TTF font (e.g. DejaVuSans) via `pdf.add_font(...)` and switch `pdf_export.py` to use it, so PDF text isn't constrained to Latin-1 and doesn't silently diverge from the on-screen wording elsewhere in the codebase. Low priority — current workaround (avoid non-Latin-1 characters in any string that might reach the PDF) is sufficient until this is picked up.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: willemjan/glucose-dashboard#11