On Thursday, May 5, 2016, Brad Jorsch (Anomie) <bjorsch(a)wikimedia.org
wrote:
On Thu, May 5, 2016 at 9:49 AM, Brion Vibber
<bvibber(a)wikimedia.org
<javascript:;>> 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