Suggestion: Supported way to override the SVG @font-face block

[ewels]

Hi folks,

Here to suggest a minor new feature addition. Happy to put up an issue + PR if folks think it's worthwhile.

Issue text initially drafted by AI (Claude Opus 5) and edited / added to by hand ✍🏻

Problem

The SVG export feature uses export_svg(), which references Fira Code via local() plus a cdnjs URL. When an SVG loads through an <img> tag browsers often block external resource fetches, fonts included. This means that the webfont never loads. Viewers without Fira Code installed get a substitute, and since Rich positions each text chunk at an absolute x derived from font_aspect_ratio, glyph advances drift within the chunk and the box drawing can comes apart.

There are a few issues on the repo that have come up due to this:

• [BUG] Misaligned box boundaries in SVG generated from a rich-click help dialogue #2279
• [BUG] SVG output is not compatible with most tools beyond browsers #2153
• [BUG] svg Tables seem bugged when trying to generate an png from them  #3034

And the reason I ended up here, a related issue in my derivative project rich-codex:

• Add Option to Flatten SVG Files ewels/rich-codex#65

The solutions here as I see them are to either:

1. Flatten the font glyphs to shapes (bad: requires the font on the user's machine, needs new deps, text no longer selectable / editable)
2. Embed the font in the SVG (bad: adds a bunch of filesize bloat)
3. Embed only the required font glyphs into the SVG (best, but still adds new deps, so bad)

None of these are really viable in rich itself, my request isn't for that - it's a new minor feature to allow consumers of rich to do it themselves in an easier way: a new field, rather than needing to chuck out + duplicate the entire SVG template.

What I'd like

A font_face / font_family pair of optional parameters on export_svg() and save_svg(), defaulting to current behaviour:

console.save_svg("out.svg", font_face=my_font_face_css, font_family="My Font")

font_face replaces the two @font-face blocks; font_family replaces the value in .{unique_id}-matrix. No behaviour change unless set. font_aspect_ratio is already a parameter, so there's precedent for font knobs in that signature.

Why not just third-party

It basically already is third-party: code_format lets me pass the whole template, and that's what I'll be doing now, so this isn't a blocker. The suggestion is only to make it cleaner and simpler to do so. Currently, to change three lines of CSS I'll need to vendor the entire CONSOLE_SVG_FORMAT string and re-syncing it whenever Rich touches the template (which does happen periodically).

Happy to open the issue + PR if this seems reasonable.

[ewels]

Update: in the end I used a regex replace on the rendered SVG output instead of vendoring the entire template. Less work but feels a bit hacky..

[Avalon2222]

Until something like font_face= exists, a middle ground between vendoring the whole template and regex-replacing the rendered output is to patch the template once at import time and pass it as code_format. The template is tiny and stable in the places that matter, so you can assert on the match count and get a loud failure the day Rich changes the block, instead of silently shipping Fira Code again:

import re
from rich._export_format import CONSOLE_SVG_FORMAT

MY_FONT_FACE = """@font-face {{
        font-family: "JetBrains Mono";
        src: url("data:font/woff2;base64,...") format("woff2");
        font-weight: 400 700;
    }}"""  # doubled braces: the template goes through str.format()

# drop the two Fira Code blocks, then insert ours right after <style>
template, n = re.subn(r"(?s)@font-face \{\{.*?\}\}\s*", "", CONSOLE_SVG_FORMAT, count=2)
assert n == 2, "Rich changed CONSOLE_SVG_FORMAT; check the @font-face replacement"
template = template.replace("<style>\n", "<style>\n\n    " + MY_FONT_FACE + "\n", 1)

template, n = re.subn(r"font-family: Fira Code, monospace;",
                      "font-family: JetBrains Mono, monospace;", template)
assert n == 1

svg = console.export_svg(title="demo", code_format=template, font_aspect_ratio=0.6)

Checked with Rich 15.0.0: the output has one @font-face, no cdnjs URL, and the .{id}-matrix rule uses the new family. Two details worth keeping in mind:

• Braces in anything you inject must be doubled, because export_svg runs code_format.format(...).
• font_aspect_ratio should be set to the real advance/height ratio of the embedded font, otherwise the absolute x positions drift exactly as you described (0.61 is Fira Code's).

For the <img> case specifically, a data: URI for a subsetted WOFF2 is the only thing that renders reliably, since browsers block external fetches from image-context SVGs regardless of CORS. On the feature itself: font_face/font_family keywords on export_svg()/save_svg() would be a small, backwards-compatible change, so I'd open the issue and PR.