Meeting minutes
<siterum> present
Vlad: introducing new member, Skef.
Skef: progammer, involved in fonts via open source work on font forge. Now at Adobe.
Skef: part of the group now because I'm doing some work on Adobe's internal solution to this. Goal is to transition to whatever specs come out of this group.
Skef: I'm free to share insights from our implementation.
Skef: just started, so still learning.
Vald: roots of this work are from the Adobe dynamic augementation. First discussions started in 2016 when multiple impelmentations were proposed.
Vlad: first agenda item - WOFF2 recommendation ammendments
Vlad: some small editorial issues, some link updates, and so on.
<jhudson> [Waiting for Zoom updates to install]
Vlad: we need formal group review and approval for it to go to final stage.
Vlad: need to say we've tested these changes.
https://
<Vlad> WOFF2 issues: https://
Garret: update for tests of the woff2 changes. The encoder/decoder implementations have been updated in the https://
Garret: I'm unsure on the status of the fonttools implementation. Will follow up on that.
Chris: not seeing the tests in the open source repo.
Garret: ah, looks like we haven't transferred the tests written internally to the open source repo. I'll see if I can get those files open sourced.
Garret: also there are conformance tests that probably need to be updated. I'll track that down.
<chris> https://
Vlad: do we need to public tests to proceed?
Chris: yes, need something public to point too.
Garret: I'll focus on doing the conformance tests first.
RESOLUTION: publish WOFF2 with corrections made normative
conformance tests demo
2. Patch Subset Server Conformance Tests demo: https://lists.w3.org/Archives/Public/public-webfonts-wg/2022May/0001.html
<chris> Test needs an address for the font on the server, plus path to a local copy of that font for checking
<chris> Also script to test all server-based assertions in the spec
Vlad: next topic is TPAC attendance in Vancouver, Canada.
3. TPAC 2022 planning: https://lists.w3.org/Archives/Public/public-webfonts-wg/2022May/0003.html
Vlad: linked email has a form that we will either need a group entry or individual entries.
<Vlad> Form: https://
Chris: need just one group entry, would be best if Vlad/Garret did it.
Vlad: some of the expected participants are not on this call.
<chris> I plan to be there
Chris: last week Jason gave us an idea of his attendance plan, not a hard no. May be able to attend in Sept.
Vlad: people who are on this call are you able to attend?
Vlad: Skef?
Skef: not sure, will take up with management chain.
Garret: I should be able to attend.
Sergey: should be able to attend.
Chris: plan to be there.
John: two days after fontstand conference, so question as to whether I'm back or not.
Vlad: I plan to be there.
Vlad: I'll respond to the form.
Issues
Vlad: now on to issues
Vlad: re: issue 83. I think the should, should be upgraded to must.
Garret: so this is about method selection I think it's fine to use must as long as it's clear the server is allowed to choose between either method.
Chris: I can update the text.
Vlad: number 87 requires additional discussion
Vlad: had similar discussion in 2018 in Tokyo about this.
Vlad: about stylistic sets and alternates.
<chris> https://
Garret: default set to me is the set of features that are required by default in shaping.
John: I was thinking of non-shaping features. Typographic layout features. Some are on by default, some are off by default.
John: delig for example, small caps, that are part of the typography rather than content.
John: which are specified at the CSS level.
John: without querying the css you don't know what a document might need.
Chris: I can see two ways one the client does CSS analysis, or that the author figures it out.
Garret: what I suggest is we have the default set, allow optional ones to be asked for, and also a mechanism to jsut ask for all.
<jhudson_> http://
Vlad: would it be feasible to have a paragraph or two to describe the features in the default set.
John: on page 6
John: everything I'd call default features should be part of the default set as they are required for shaping.
John: eg. there's stuff for arabic, cjk
John: then there's these standard typographic forms, so are used for shaping. It's possible to go through and make a list of the features used by shaping/layout engines.
Skef: we'll have information from css about the feature list. Can you give an example of off by default, that wouldn't be in the css feature list that would still be needed.
John: anything that's needed is on by default.
Skef: anything that's on by default, but not needed?
John: no
John: everytihng from 1 through 3a is needed.
John: this is just GSUB stuff, GPOS is a separate issue, probably all needed.
John: actually there's some GPOS stuff that's used in vertical layout which may not be needed.
Skef: if we could defer to a list of on by default that would be good.
John: I've had a long term goal to revamp the feature registry to make explicit on by defautl, off by default. In the meantime you could use the list in this document.
Garret: I can check with Behdad about on by default in harfbuzz.
John: in harfbuzz fraction feature is off by default. It uses a character trigger for that if the fraction character is present.
Garret: probably want to take a conservative approach and send anything that may be needed by default.
Skef: so does this mean that if it's there we want it.
Garret: yes.
Skef: shouldn't but the burden on the user agent. If there's info somewhere that harfbuzz is going to do a specific thing. We could just have an implicit list, like frac you might need that, but things evolve. So it'd be better to have some mechanism.
John: so subsetting GSUB you've got multiple layers of information, you have lookups, scripts, lang systems. So ideally if you have a document in hindi you've got devanagari characters you can make a decision on default subset based on the fact that it's devanagari. Then you've got the fact that it's in hindi.
John: language system may imply some differences
John: how specific is the subsetting
Garret: it operates at the feature tag level and retains everything that could be reached via the codepoint and feature tag set. So not language specific.
Skef: if you have a set of features that are already there, but you get additional codepoints you may get additional lookups.
Garret: my recommendation we add to the request ability to specify features have/needed and then make a recommended default list that is not a must level requirement. Leave the specific default list selection up to the client.
Skef: concerns about request length and cacheability of requests. Will file an issue on github.