Re: Enriching Variable Fonts

Assuming optimistically our data transfer test suite (once that exists)
supports the notion partial transfer of VF is a win, I think our spec needs
to do a couple of key things:

1) Do something sane by default. This probably involves looking at what's
actually used and informing the server of that in some fashion. The most
obvious example I can think of is telling the server the optical size
needed so it can *potentially* discard unused parts of opsz or even
instance opsz at that point. Similarly, collecting the used weights,
widths, etc seems somewhat plausible (would need to sanity check with
browser vendors ofc)

2) Allow an expert user to take full control. For example, use a VF with
say wght,grade and explicitly declare that some range of grade MUST be
downloaded because the developer knows their JS applies that in some
situations. Provide a means to specify, in which case the default for that
axis is overriden or replaced. Arguably this could be left to service
providers, the url from which content is to stream could allow
specification of additional guidance and how that works need not be
specified.

Wherever decisions can be left to the server they should not be specified.
Whether or not to send an instance, whether or not to delete an axis, and
the like are all things a server can intelligently decide, tuning it's
decision making over time based on measurement of the results. Our spec
just needs to be sure to send enough information to the server to make good
decisions, the server can be a black box as far as the spec is concerned.

I think you will find a lot of developers are not tremendously aware of
variable fonts (I have survey data to back that up but not permission to
share it). Good default behavior will go a long way here. Good defaults
also potentially allow for service providers to roll out the new hotness
without telling users.

I would dearly love to be able transparently upgrade Google Fonts to send
all supporting UAs progressive enrichment and have most of our users have
no idea their page loads just got faster. If we can do that, and we have
compelling evidence the web gets faster, I think convincing browsers to
prioritize implementing progressive enrichment gets a LOT easier. WOFF2
rolled out this way, hitting billions of daily requests almost immediately
after the first browser had support.

Rod S.

On Thu, Mar 28, 2019 at 8:57 AM Jason Pamental <jason@rwt.io> wrote:

> I think that part of the answer here might be that the evaluation of what
> to send for a page load should look at all of the CSS for the page, which
> should be present and availabile to inspect. That way media query choices
> about width, etc. would be known before subsetting occurs so the right
> aspects/axes could be determined.
>
> Jason
>
>
> On Mar 25, 2019, at 12:00 PM, Levantovsky, Vladimir <
> Vladimir.Levantovsky@monotype.com> wrote:
>
> 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> 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> 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>
> *Sent:* Friday, March 22, 2019 4:28 PM
> *To:* WebFonts WG <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?
>
>
>