On Thursday, May 5, 2016, Brad Jorsch (Anomie) <bjorsch@wikimedia.org> wrote:
On Thu, May 5, 2016 at 9:49 AM, Brion Vibber <bvibber@wikimedia.org> wrote:
There's also the font issue: with the current rasterizing, only certain
free fonts are available and we know what it falls back to. Serve the SVG
to the client and those free fonts may well be missing (falling back to
who-knows-what), while other fonts with different metrics that our
rasterizer ignores might be present on the client.
Yep... It's worth experimenting with injecting fonts into the "thumbnail" SVG output. That'll increase total download size again, but common fonts should be shared between files, making them neatly cacheable, and if there are no relevant characters we have no need to inject them.
I think all the CSS @font stuff works in SVG as it does in HTML, so if we have known client-side-safe fonts we can reference them as we do in HTML land... For common cases where text is in the language of the surrounding site, that means we may have loaded the same font already if one was needed.
Making SVG safe for fallback fonts can indeed be tricky if the metrics don't match, though for simple labels it's usually a matter of setting reasonable bounding boxes and making use of the alignment specifications, rather than using the tightest possible bounding box and aligning things manually by x/y.
For extreme cases where exact glyph shapes and metrics matter because the text is mixed with graphical elements directly, files should probably use paths instead of text (or at least embed a specific SVG font made of specific paths). That can be something that good authoring tools can help with.
-- brion