Option b) might get viable due to help of SVG functionality.

<text fill="#222" font-family="system-ui, -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, 'Oxygen-Sans', Ubuntu, Cantarell, Lato, 'Helvetica Neue', Helvetica, Arial, sans-serif" font-size="22">
    <tspan x="73.624" y="226.367">No saved pages yet</tspan>
</text>

This has already been exemplified in “Creating Illustrations” imagery implementation…

There's another example with recent patch: Trustworthy, yet joyful picture

IE 10(!) has issues with 'Charter', serif stack in SVGs, probably because it also can't load the fonts in general. Georgia needs to be the fallback here as well!

Above issue is tamed with https://github.com/wikimedia/WikimediaUI-Style-Guide/pull/118
Georgia makes that acceptable at least:

My concern about (b) is that I'm not sure how far we can apply the idea of making assets to be font-independent and which limitations those would bring. Some questions:

• In the example, you are adjusting the final SVG. Is that manual work that needs to be done each time the graphic asset is exported?
• If we create templates of our components available in usual design software, what are we supposed to use as fonts in those Sketch/Illustrator/etc. files?
• When we are illustrating elements with text such as buttons or lists, is there a way to prevent the variability of font sizes to cause misadjustments?

I think that using a font family like Noto for the examples which can be redistributed and is available for many scripts seems less problematic to me, than trying to recreate the device-specific font experience from the browser on design assets.

Not sure it is related to the discussion, but I noticed that the right margin for he image below looks to narrow when viewed as part of the styleguide page, while it looks better when the image is opened alone:

As part of the page	Individually

IMHO we can go with (a) except when imagery containing fonts is specific to a platform. So for example if we are using an eample image that it is a screenshot from the iOS app, it seems to be overkill to re-do this in Lato rather than using the iOS-specific UI font.

@RHo One issue related is, that we're not clearly stating currently where the screens originate from. In order to make your proposal work, this needs to be clear.

Makes sense @Volker_E - think captions in the case where it is platform specific could be all that's needed.

With the most recent changes, I added option d) as refinement of option c) for better distinction with binary/embedded fonts, platform-specific SVGs.

@Pginer-WMF Thanks for your inputs, replying to the points brought up:

• In the example, you are adjusting the final SVG. Is that manual work that needs to be done each time the graphic asset is exported?

That would stay one specific way. It could be semi-automated, replacing for example whenever designer chooses 'Lato' in the original SVG export to system-ui, -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, 'Oxygen-Sans', Ubuntu, Cantarell, Lato, 'Helvetica Neue', Helvetica, Arial, sans-serif in the SVG. Whenever any other font is chosen, for example in an app specific screenshot, we wouldn't touch it. Also although I agree with a higher engineering cost at start, when we've got process defined, I don't estimate that we're changing the imagery every few months (rather low maintenance).

• If we create templates of our components available in usual design software, what are we supposed to use as fonts in those Sketch/Illustrator/etc. files?

Already proposed a possible solution above. Let's say 'Lato' is the choice for being replaced by OS-independent font-stack in resulting SVG. Keep in mind, that if we're not integrating fonts in SVGs or use binary images (option a & b; both has issues for other reasons like performance, high DPI appearance or technical limitations), you'll never have full design control over the used font-family.

• When we are illustrating elements with text such as buttons or lists, is there a way to prevent the variability of font sizes to cause misadjustments?

No. Similar to what we have in normal HTML/CSS environment. In this sense, an approach like d) is closer to our production reality and also harmonious with the rest of the textual content in our guide and therefore seems preferable to me.

I'm going to care about the Illustration section glitches now that T193920 is mostly resolved.

From Design meeting:
@Pginer-WMF emphasises, that option d) – SVGs with OS-dependent fonts – could lead to unnecessary complexity in production of style guide imagery, for example on all kinds of layout issues when variable fonts come into play.
We've been then discussing generally SVG versus PNG, as latter would provide stronger design control and simpler export, with drawbacks of possible not so flexible scalability, and (much) more data necessary down the wire. Think 788px width at 4x image resolution for HiDPI resolutions.

Next step is on me, exporting four of the current images from Sketch and compare in details pros and cons.
To make this comparison clearer and simpler, will go for options a) PNG with Lato and d) SVG with OS-dependent fonts. b) and c) were modifications of the test.

Another take with new technical approach:
e) Enabling web fonts in the HTML page and make use of them in the SVG loaded within the font. This would only work when the SVG is not referenced as img as external fonts/scripts etc are disabled in img for security reasons.