RE: Enriching Variable Fonts

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?