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 <https://fonts.google.com/specimen/Roboto>, 70B requests last week) and Roboto Condensed (https://fonts.google.com/specimen/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:
> 
> 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?
> 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)
> 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?
> 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?
>  
>