Diggory Hardy

Yes; however, the `bounds` in a `Section` are used to calculate glyph positions by the layout. I think a supplemental `draw_bounds` rect is needed here. Since the draw bounds may...

I was just looking at `GlyphPositioner::bounds_rect`: this calculates bounds based on glyph geometry. I'd like to use the intersection of this rect with user-provided `draw_bounds`.

I'm now moving to using the `prepositioned_glyphs` API with my own caching, so don't really care about the cache management aspect of this issue any more (and clipping I solved...

Completely off-topic, I now want serde support for `Weight`, `Stretch` and `Style`. Shall I just implement locally (`serialize_with` etc)? Edit: [this was pretty easy](https://github.com/kas-gui/kas-text/pull/49/commits/05b50366a0a2fe7d1e611d93acbb2d9f83c52f0a) with [thanks to serde](https://serde.rs/remote-derive.html).

Since there is already logic for matching by weight, I would assume that would deal with "light"/"medium" variants. The weight matching logic is almost redundant with this restriction. But I...

I wonder if it's a deliberate mis-parameterisation. Practically, most people don't care for the difference between oblique and italic, and when they do they would normally select a specific font...

I guess the specifics of the matching algorithm shouldn't matter: this matching only happens within a single font family. If there's no match, CSS says try the next candidate family...

Note: otherwise the SVG renders well, only failing to resolve the `small-caps` font variant and possibly fails to wrap text with `inline-size` (though wrapping behaviour is identical to Firefox).

It's not just the alignment of the bid text, but the ordering: some of these (including resvg) get it wrong. (Not that I care personally, just thought I'd point it...

Barely worth a mention here, but [KAS-text](https://github.com/kas-gui/kas-text/) implements: - BiDi layout - line breaking - very primitive rich text The library vaguely follows the relevant Unicode specifications but isn't fully...