Re: Enriching Variable Fonts

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?
>
>
>