RE: Enriching Variable Fonts

I’ve been thinking about it some more over the weekend, and my major concerns seem to be correlated with what Jason mentioned in his email.

Let’s make a working assumption that designers and developers know what they are doing, and are able to make informed decisions on whether they need to use specific instances of a font [which are available as single, standalone products such as “Roboto Regular” or “Roboto Condensed”, as per the example below] vs. Roboto VF [in which case, they’d likely know when and why variations may need to be triggered]. Let’s also assume [per my previously described example] that the page is designed so that the page layout and font variations are triggered when a screen orientation changes from portrait to landscape. In a portrait orientation, layout is designed to show a single column of text and asks for “Roboto Regular”, and in landscape orientation text layout changes to two columns using a slightly more condensed version of “Roboto” where variations are required. Assuming that “Roboto Regular” is one of the master designs used as part of “Roboto VF”, this is relatively simple case – the initial font subset can be delivered based on Regular master with all variations data stripped, and the subsequent incremental update would add a second [“Condensed”] master with variation data needed to build a “slightly more condensed” version of the font the page asks for.

If, however, we modify the condition for two screen orientations where both portrait and landscape screen positions call for two different variations of “somewhat condensed” typeface – the decisions a server would need to make become more complicated. It is possible that, if we know the variations settings to be applied, in order to speed up the initial page render we might decide that instead of sending two masters and variation data subset we can build a specific instance of a font and send just that. However, when screen orientation changes and different variations settings are to be applied, the possible outcome would be more complicated and require to either send an extended incremental subset with both masters and variation data (thus, significantly increasing the total font data transferred for this page), or build and send another specific instance (kind of defeats the purpose of using VF). Either way, the orientation change that triggered variation settings update would cause a delay in page render until a new incremental font update is loaded, which [I think] would be highly disruptive and could’ve been avoided if the initial subset included both masters and the variation data from the start. Things could become exponentially more complicated if more than one variation axes are in use (e.g. weight and width at the same time).

I do agree with the initial premise that looking at the variations as yet another possible “enrichment target” is worthwhile, but it seems to call for a more nuanced approach supporting developers’ design decisions from the get go. E.g., if a VF supports multiple axes of variation and the page is only designed to use one (or two) – sending a stripped-down version of VF eliminating the unused axis is probably a good call. If VF supports multiple masters for the same variation axis, and a variation range the page asks for is within a subrange between two masters – eliminating other masters along the same axis (outside the applicable range) could also be a good idea. However, I am not sure if making a decision to substitute a VF with a single particular instance that is currently needed [and send just that limited data set] would be a good idea; it can be, but only under certain conditions, as previously mentioned. In general case, I’d trust the developer decision knowing whether to ask for a static font instance, or for a VF version of the same font, because he/she is in better position to know what is going to happen down the road.

Vlad

From: Jason Pamental <jason@rwt.io>
Sent: Monday, March 25, 2019 10:12 AM
To: Roderick Sheeter <rsheeter@google.com>
Cc: Levantovsky, Vladimir <Vladimir.Levantovsky@monotype.com>; WebFonts WG <public-webfonts-wg@w3.org>
Subject: Re: Enriching Variable Fonts

I wonder if we have enough information yet on that last point. I suspect that (if I am able to make the impression I’m trying to make on designers and developers) once people start to use variable fonts more, they will use more of the range of those axes rather than only using one or two weights. There may still e a large number who don’t, at least for now, but probably something we’ll need lots more data  on before being able to draw meaningful conclusions.


On Mar 22, 2019, at 7:19 PM, Roderick Sheeter <rsheeter@google.com<mailto:rsheeter@google.com>> wrote:

We don't have a good analysis pipeline for testing different theories yet. We aspire to build one and share #s but it's going to take some time to plan, prioritize, build, and begin to have "real" results to share. For now it's all a bit hand-wavy :)

Imagine you have a font that varies on wght 100-900 and you know the user is using only a single instance. We might choose to send an instance (particularly if it happened to be at the default position on all axes) rather than a VF, potentially saving a fair bit.

If the user is using multiple points or ranges you may save, potentially substantially, but it depends on how the delta sets within the font are arranged. For example, if the font had masters at 100, 400, 900 on wght it might have two main sets of deltas, one for 100-400 and one for 400-900. If we know the user is using only weights in [400, 900] we can discard one set of deltas entirely.

We expect, based on our logs, that there will be many cases where only a single position, especially the default, for an axis gets used. For example, today we have both Roboto (https://fonts.google.com/specimen/Roboto, 70B requests last week) and Roboto Condensed (https://fonts.google.com/specimen/Roboto+Condensed, 4.5B requests last week) as standalone families. In a VF world we might have a single Roboto with wdth,wght. If all we knew was "user wants Roboto, these codepoints" we could end up having to send all the wdth variation information even though most users never use it.

Cheers, Rod S.

On Fri, Mar 22, 2019 at 2:40 PM Levantovsky, Vladimir <Vladimir.Levantovsky@monotype.com<mailto:Vladimir.Levantovsky@monotype.com>> wrote:
Hi Rod,

Thank you for raising this issue, which, in my opinion, warrants a substantial discussion (and it’s good to have it sooner rather than later so thanks again for being forward-looking!)

My initial reaction on the subject you raised produced more questions [and no answers], those being:

  1.  If we have multiple variations enabled by a font and the page is using only some of them (or none at all) – how much data do we expect to save? If variations [that are in use] are encoded as a range of variations values along a particular axis, and the page would only be using a subrange of that variation space – do we save anything in this case?
  2.  How much savings we could realistically expect if we chose to treat the variation space as an incremental update? (i.e. if you have the estimate numbers and can share them with the group)
  3.  Variations are typically applied as delta vectors to outline points, and I guess it is possible that a font designer could define extra points along a glyph outline to enable a particular variation (i.e. points that would not be needed as part of the base glyph design) – how easy/difficult it would be to identify/eliminate those points if a particular variation they serve is not utilized?
  4.  If we chose to treat the variation space as an incremental update, and if font variations are applied by a browser as a result of the viewport changes (e.g. rotating mobile device from portrait to landscape screen orientation) with no content changes – what would the performance impact [latency] be if a browser needs to ask for additional variation data at that moment in time, as opposed to having it delivered within the initial subset?

I will sleep on it and see if I can come up with some answers (or more questions), but it is the topic that definitely deserves a detailed discussion, thank you again for raising it.
Vlad

From: Roderick Sheeter <rsheeter@google.com<mailto:rsheeter@google.com>>
Sent: Friday, March 22, 2019 4:28 PM
To: WebFonts WG <public-webfonts-wg@w3.org<mailto:public-webfonts-wg@w3.org>>
Subject: Enriching Variable Fonts

Good afternoon,

So far we have largely been imagining that the client tells the server what it has, and what it needs, in terms of codepoints. Variable Fonts (VF) might offer the opportunity for incremental transfer to encompass more.

Imagine a page that references a VF that has {wdth,wght,opsz}. If the browser can tell the server the specific points or ranges of axes that it needs, then the server can opt to drop a potentially substantial portion of the variation space when building a patch.

The client would likely need both a reasonable default (harvest all the weights/widths actively visible or some such) and a way for a developer to express exactly what they want (I am definitely going to use the full range of grade, I animate on it for emphasis).

For a web page using a VF this could substantially reduce the delivery cost, aligning well with the goal to "pay for what you use". Using 1,000 unique codeponts of a CJK font at a single optical size, weight, and width on a page? - why pay for all the variations of those glyphs.

That is, today we (at least on our side) have largely been contemplating:

f(codepoints_present, codepoints_needed) => delta

What if we changed that to:

f(codepoints_present, axes_present, codepoints_needed, axes_needed) => delta

WDYT?