Meeting minutes
<chris> scribenick Garret
Vlad: first agenda item reviewing pull requests with changes to woff2 spec.
Vlad: also noticed that bitarray needs to still be added.
Vlad: chris can you remind us what other changes then the overlap simple addition.
Chris: definition of Uint32 was omitted. Obvious what it is but to be consistent I've added it.
Chris: instance of '=' that should have been '=='
Chris: I do see a uint8 overlapFlagStream.
Chris: another correction for wether a point is on/off curve. Doesn't say which value is which. I've added clarification.
Chris: that's it.
Vlad: one more item we should discuss is one more woff2 issue. Version field is defined and set to zero and no recommendation what it's for and what to do with it.
<chris> https://
Vlad: should we say something about it?
<chris> yeah it would not be backwards compat to require them to care about it
Garret: propose that we specify current behaviour that it should be ignored.
Vlad: should version number be incremented?
Garret: I think we shouldn't since we are already adding a bit to specify the presence of the new field. So it's redundant to also increment version.
Vlad: should we just have the version field be called reserved?
Garret: yes I agree.
Vlad: OK let's consider that the tentative proposal.
Garret: so to confirm version field will be reserved and spec will say to ignore what's in it.
Vlad: looking through the list of outstanding issues. Next one which was opened two years ago.
Vlad: bug in decoding of composite glyphs.
Vlad: when spec was initially drafted simple and composite decoding had steps defined where there was a shared step between them.
Vlad: but that was later removed, but because of the changes the reference to step 2 was left as is and now recursively refers to itself.
Vlad: that should have been chagned to 1a.
Vlad: I propose we should do it.
Vlad: should double cehck implementations are doing it right.
Garret: agreed, can you assign that issue to me and I'll double check the implementation.
Vlad: last one is about mimetype distinction for VF fonts.
Garret: does the woff2 spec define a mimetype?
Chris: initially it did, but nobody was using it. So I did some work to add it to the registry.
Chris: you can set parameters on the mimetype, but it's tricky to do that.
Chris: in practice not very often used.
Chris: in css not needed since you could use the supports tag.
Chris: but not supported in html attributes. We could make mimetypes up but likely nobody will use it.
Vlad: spec does have an annex specifying the mimetype.
Vlad: upper level type and subtype is woff2.
<chris> https://
Vlad: not sure if it's useful to describe additional parameters.
Vlad: not up to us to define what's in the font from the spec perspective.
Chris: I think we should close this, but give a reason.
Vlad: I would consider what we mentioned as a good enough reason.
Vlad: when defininig the encoder we don't care about the specific payload.
Vlad: what exactly is there and implemented by that font isn't something spec can predict.
Vlad: unless we want to define optional parameters to define a tool to do that.
Garret: vf is now widely supported so not sure what value there is to having a vf specific mimetype.
Vlad: unless a clear reason this is needed comes up don't think we need to do this.
<chris> also good discussion here https://
Garret: updates to the spec 1. added sections for the checksum computation using fast hash. Added a pseudocode implementation and link to c implementation.
2. added connection type field to allow client to give a hint about connection speed.
Garret: remaining item to propose adding VF fields that allow specify design space.
Garret: myles, any update on your ability to edit the spec?
Myles: no update yet.
Myles: don't want to block, maybe we can split off the range request into a seperate document.
Vlad: should we remove the section for now, and bring it back in the future.
Myles: probably don't want to delete it and maybe bring it back.
Vlad: Chris, have other specs been split into multiple documents.
Chris: yes that's pretty normal.
Vlad: just call it a range request module.
Garret: looking forward it would be good to be able to publish the patch/subset side of things even if range request isn't ready yet.
Chris: one down side is the first public draft has patent policy implications. So the range request stuff won't be covered. If we have a second document with a pointer from the first document then it would have coverage. Does that work for you Myles?
Myles: yes, will both documents get review period?
Chris: yes
Vlad: should we have a resolution?
Chris: yes, should we also have a resolution about first public working draft.
<chris> yes of course
Garret: would like to have a public working draft after adding vf fields, agreed?
Vlad: yes.
Resolution: we will split range request into a seperate document linked from the main one.
Resolution: we will create the first public working draft once current pr's are merged and variable font fields have been added to the patch subset approach.
Vlad: let's plan to reconvene next week and review candidate changes and take a break for the week after since it's a US holiday.