Page MenuHomePhabricator

Resemble font stack in images/components
Open, HighPublic

Assigned To
None
Authored By
Volker_E
Apr 13 2018, 6:46 AM
Referenced Files
F18082890: Screen Shot 2018-05-08 at 18.42.54.png
May 8 2018, 5:13 PM
F18082894: Screen Shot 2018-05-08 at 19.13.00.png
May 8 2018, 5:13 PM
F17772129: image.png
May 5 2018, 12:01 AM
F17768884: image.png
May 4 2018, 11:44 PM
F17768690: image.png
May 4 2018, 11:44 PM

Description

Resemble font stack update at T188799 in Style Guide's images and components.

Options for imagery/components typesetting:
a) Remain with Lato in our Style Guide imagery as aspirational choice and be clear when web fonts are available to choose
b) Provide specific images (binary files, or SVGs with embedded fonts) depending on visitor's platform (I'm cautious about both, engineering and maintenance overhead with that option)
c) Provide imagery in a widely used system font like Arial
d) Provide images as SVGs which are featuring OS-dependent fonts like the surrounding HTML currently does.

Update 2018-05-14:
Added option d) to be explicit about variability in output.

Event Timeline

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…

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!

image.png (686×1 px, 275 KB)
and
image.png (1×1 px, 341 KB)

Volker_E renamed this task from Resemble fontstack in imagery/components to Resemble fontstack in images/components.May 5 2018, 12:04 AM
Volker_E renamed this task from Resemble fontstack in images/components to Resemble font stack in images/components.
Volker_E updated the task description. (Show Details)
Volker_E updated the task description. (Show Details)

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 pageIndividually
Screen Shot 2018-05-08 at 18.42.54.png (530×406 px, 118 KB)
Screen Shot 2018-05-08 at 19.13.00.png (754×444 px, 211 KB)

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.

Removing task assignee due to inactivity, as this open task has been assigned to the same person for more than two years (see the emails sent to the task assignee on Oct27 and Nov23). Please assign this task to yourself again if you still realistically [plan to] work on this task - it would be welcome.
(See https://www.mediawiki.org/wiki/Bug_management/Assignee_cleanup for tips how to best manage your individual work in Phabricator.)