[font] resolve the initial viewport of SVG glyphs

[hajimehoshi]

What

Adds a ViewBox field to GlyphSVG, exposing the initial viewport of an SVG glyph document. It is resolved from the root <svg> element attributes with the following cascade:

1. the viewBox attribute, if present and valid;
2. the width/height attributes (the fallback FreeType's reference OT-SVG port also uses);
3. the em square (0, 0, upem, upem), as required by the OpenType specification:

The size of the initial viewport for the SVG document is the em square: height and width both equal to head.unitsPerEm.

Why

Updates #191: Noto Color Emoji's SVG documents have no viewBox attribute, so consumers relying on the document alone (e.g. go-text/render via oksvg) see a 0×0 viewport and render nothing. The library is the natural place to resolve the spec-defined default, since it knows unitsPerEm.

Notes for reviewers

• The root element is scanned with a small dedicated parser instead of encoding/xml: importing encoding/xml into the core font package measured ~175 KB of binary size overhead, a real cost for wasm-type builds, while only the root element's attributes are needed. The scanner handles BOM, XML declaration, comments, doctype (including internal subset), namespace-prefixed roots and both quote styles; any malformed input degrades to the em-square default rather than an error. Happy to switch to an xml.Decoder token loop if you prefer stdlib robustness over the size cost — svgRootAttributes keeps the same signature either way.
• The element is matched by its local name only; the namespace binding is intentionally not verified (a check could only reject broken fonts, and would yield the same em-square fallback anyway).
• Verified against the actual NotoColorEmoji-Regular.ttf from the issue: the 🍣 glyph now reports ViewBox {0, 0, 1024, 1024} (upem = 1024). The integration test uses toys/chromacheck-svg.ttf, whose document also lacks a viewBox.
• A companion change in go-text/render is still needed for the issue's user-visible fix: use GlyphSVG.ViewBox instead of oksvg's parsed (empty) one, and place the SVG origin at the baseline (the documents use font units, y-down, origin at baseline).

---

Authored by Claude (Claude Code), on behalf of @hajimehoshi.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR extends the font package’s OT-SVG support by resolving an SVG glyph document’s initial viewport and exposing it to callers, ensuring SVG glyphs without an explicit viewBox can still be rendered correctly (per the OpenType spec’s em-square default).

Changes:

• Add SVGViewBox and logic to resolve the initial viewport from root <svg> attributes (with spec-compliant fallback to (0,0,upem,upem)).
• Extend GlyphSVG to include the resolved ViewBox, and plumb upem into the SVG glyph data path.
• Add unit/integration tests covering viewport resolution and a real font fixture.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 7 comments.

File	Description
font/svg.go	Implements viewBox/width/height parsing and a lightweight root <svg> attribute scanner to resolve the initial viewport.
font/renderer.go	Extends GlyphSVG with ViewBox and computes it when extracting SVG glyph data.
font/svg_test.go	Adds tests for SVGViewBox resolution and verifies GlyphDataSVG(...).ViewBox on a fixture font.
font/export_test.go	Exposes the internal svgViewBox helper to tests.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[andydotxyz]

Nice one thanks, I can't see anything beyond the Copilot fixes

[benoitkugler]

This is a nice addition, thank you !

I would rather use the standard library encoding/xml : I would rather not have our own copy implementation and I note we already import it in fontscan to support fontconfig files.

I'm not sure I understand the need for
func SVGDocViewBox(doc []byte, upem uint16) SVGViewBox , could you double check it ?

[hajimehoshi]

I'm not sure I understand the need for func SVGDocViewBox(doc []byte, upem uint16) SVGViewBox , could you double check it ?

This is needed to test an unexported function svgViewBox from an independent test package (font_test). I now think this should be renamed to SVGViewBox. EDIT: This name is intentionally SVGDocViewBox to avoid a conflict with the existing SVGViewBox.

If this solution (exporting an API only for testing) is not conventional, I'm fine to change the way. What do you think?

[hajimehoshi]

I would rather use the standard library encoding/xml : I would rather not have our own copy implementation and I note we already import it in fontscan to support fontconfig files.

Sure. As the first comment says, this would increase the binary size by 175 KB. EDIT: As this is already imported, there is no problem!

[hajimehoshi]

@benoitkugler all done. Please take a look

[benoitkugler]

@benoitkugler all done. Please take a look

Thanks for the modifications. I think we could avoid the export_test.go file if we use package font instead of package font_test in svg_test.go

[hajimehoshi]

Thanks for the modifications. I think we could avoid the export_test.go file if we use package font instead of package font_test in svg_test.go

Done.

[benoitkugler]

Thank you, this looks great to me !