Meeting minutes
handling of invalid data
Garret: first up looking for input from Vlad on handling of linking to the beyond64k spec
Vlad: as part of 5th edition iso standard the hope is open type spec will be updated to match. Currently only on the iso side.
Vlad: the changes were originated from wanting to support >65k glyphs without breaking things. Any tables specific to that limit are duplicated with an alternate tag name. Old implementations use the old tables, while new ones can ignore old.
Vlad: therefore font is dual purpose to work with old and new implementations
Vlad: there's going to be tables duplicated with upper case tagnames. For human reader this is easy to understand.
Vlad: that's the general approach. Since we care about number of glyphs from maxp or MAXP the newer implementation will know what it is and ignore maxp.
Vlad: that's the scope and approach, implemented in the 5th edition standard. We've passed the working draft stage.
Vlad: the commitee draft is the first official version.
Garret: can we ref that version in the IFT spec?
Vlad: it is available for public review. It's probably not going to be proper to use that as a reference in our spec.
Vlad: can't really be referenced online
Vlad: getting the copy would involve downloading the spec.
Vlad: to make our work future proof I would just reference to the iso document without specific version.
Vlad: our spec is also a working draft and undergoing changes.
Vlad: candidate recommendation will probably be around for years.
Vlad: needs to wait for implementations to be available that pass the test suites
Vlad: for woff2 took 4 years
Vlad: in 2 years the new iso spec will be a standard.
<Vlad> we should just reference ISO/IEC 14496-22
Garret: sounds good, that's the approach we mostly landed on.
Skef: I'm bothered by the implications, what if it changes.
Skef: we should have a mechanism to be in sync with the current spec.
Garret: the only dependency we have is the glyph count field so we need to make sure that is future proof.
Vlad: maybe we should just say the glyph count must match the fonts glyph table.
Garret: is that understood that maxp is the source of truth
Vlad: yes
Vlad: if we don't provide specific reference, let's just reference the standard as a whole.
Skef: if there's some new development in the open font format that we have to track later, I would hope that our processes are robust enough to handle that. Even if our draft is a candidate draft.
Garret: we've left room in all of the encoded formats (reserved fields) to allow for future changes.
Vlad: so field looks good (24 bits) just need to say must match the font fields number of glyphs.
Skef: if we're looking for justification for size of the field then CFF2 already supports >65k
Garret: yes makes sense
Vlad: side comment, Garret you suggested the possibility we might reference something on github (for beyond64k). w3c has a very specific way of defining what's usable and unusable.
Skef: I believe when I reviewed the PR and that was my only question.
Garret: sounds good, otherwise I'm working on some additional changes to format 2 then that should get both font table formats in good shape.
Skef: I'd like to raise a new topic.
Skef: I was thinking about the specification and the ability to use it in more general situations where you don't know the details of your shaping engine. We discussed this in theprevious specification. When we switched over that discussion got lost.
Garret: previous spec, patch subset or IFTB?
Skef: patch subset.
Skef: I'm imagining an appendix with a list of features that are "on by default" which are used by a shaping engine without being explicitly turned on
Skef: in the encoder section say it might not make sense to separate the support for these because they are on by default.
Skef: in the client section say that these features may be used without being enabled. So if your shaping engine can be asked what's on by default you should include those, otherwise be conservative and always include these.
Garret: two thoughts one we could leave this entirely on the encoder side (eg. the encoder should always include them) or do like what you suggested.
Skef: on the client side should say something about if you're tightly itegrated with your shaper it can tell you what it needs.
Skef: if the shaper might need the info it might know for the specific context it's not needed.
Skef: if you don't have that info available here's a list of features that are considered on by default.
Garret: makes sense I can draft something. Can reuse the previous list we put together.
review open issues.
Garret: first up issue #201
Garret: how to make the initial font file as small as possible.
<Vlad> w3c/
Skef: since in these cases (embedding in css) there's a penalty for the base64 encoding. So you want to minimize that penalty.
Skef: so move most of the font level data into a patch. It will always be applied. In order to activate any codepoint you would end up applying the relevant patch.
Skef: so we want changes to clarify what's the minimum that needs to be there.
Garret: so some changes will be needed in the encoder guidance, and then some changes elsewhere about what is a valid initial font.
Garret: so approach looks to be agreed upon next steps are to draft some changes.
Garret: next 192
Skef: the base problem, let's say you have a font with two patch types. like glyph keyed for outline and optimizing the shaping data for some situations. eg. greek, latin, and Japanese. In that case you might have a font with shaping data for other languages. You have a latin, greek, japanese, and then everything else bucket. Do you have to list
everything in that patch. Can we find a way to shorten that info.
Skef: if you say everything else in the patch, the client won't be able to decide if a codepoint is supported by the font or not.
Skef: but then maybe that codepoint isn't supported by the font.
Skef: one answer is to not provide the option.
Garret: my current leaning is to not provide a specialized mechanism.
Skef: another option mark that means everything else but only valid if you have a complete.
Garret: one option then would be to make an addition to format 1 which already has a cmap dependency that allows you to associate entries with any codepoints from the cmap which haven't been listed yet elsewhere in the table. I'd like to avoid adding a cmap dep to format 2 which doesn't currently have one.
Skef: for this and the dessicated issue it makes sense for you to work on the editorial side. If you want my help on the research side of things, let me know in the issue.
Garret: sounds good, thanks
Skef: related to #101 (shared brotli expired).
Skef: any developments on the brotli compression streaming api?
Garret: nothing yet, we may have a chance to meet with the relevant people at TPAC if they are attending. I'll find out if they will be there.
any other business?
Vlad: next call? next best option would be Sept. 10th.
Garret: I'll be travelling then so only option for me is the 17th.
Skef: for the agenda of tpac - things seem most stable.
Skef: what's our strategy for using tpac.
Garret: my current ideas for topics is 1. we will have people not usual present so good opportunity to gather feedback. 2. Use the time to do a review of the current state of the spec and develop a plan to what needs to change to get to what we want to be the final state.
Vlad: what I think I want to do, I will ask Chris to ping all of them and remind them we are expecting a review from them and if we have review comments by TPAC we can set up some separate time for our discussions (either our working group time)
Vlad: for #196 can we priotize that prior to tpac?
Garret: yes.
Skef: one more extra business thing (outside of the spec)
Skef: if we're thinking about polyfills. How viable is it to solve the feature problem.
Garret: don't know enough about the behaviour of this, maybe it's possible to extract from CSS?
Skef: Adobe's implementation has to deal with it, but we've mostly avoided dealing with it for now.
Garret: poly fill could maybe include api for that and be conservative if no info is provided.
Vlad: we'll keep the 17th open as a possible next meeting if needed.
<Vlad> rrsagent. make minutes