trackbot, start telcon

<trackbot> Date: 27 May 2015

oh zakim, get your act together

<RSheeter> I want to believe that's a command

IA_Fonts()10:00AM

Started at 13:55Z and now has 3 participants:

https://www.w3.org/1998/12/bridge/Zakim.html

ok the dialing works, zakim bot has incorrect info

zakim bot appears not to be reading the call info correctly

<scribe> scribenick: ChrisL

Vlad: one pending review item. behedad said lgtm

http://www.w3.org/Fonts/WG/track/actions/pendingreview

close action-175

<trackbot> Closed action-175.

KenLundeAdobe: when discarding redundant data in cff, when it is reconstructed is it restored or discarded

Vlad: currently silent on cff processing

KenLundeAdobe: yes but in the proposal
... adobe apps prefer the data in the cff

Vlad: we don't remove anything. behedad says redundant data could be removed, why keep it in 2 places. its a question to the group and we have not discussed

KenLundeAdobe: pointing out that adobe apps prefer cff metrics ove hmtx etc if they differ

Vlad: opentype spec says a different thing

ChrisL: would be good to know what adobe apps do there if the cff dupes are removed

KenLundeAdobe: textedit on osx prefers the hmtx if they differ
... our tools may reject building such a font

Vlad: that would be useful info to know
... point was that it makes the font smaller
... no mandate to desubroutinise

open action items

http://www.w3.org/Fonts/WG/track/actions/open

RSheeter: cosimo tried that (??that) do we need more data

action-116?

<trackbot> action-116 -- David Kuettel to Decoder performance analysis on mobile devices -- due 2015-06-30 -- OPEN

<trackbot> http://www.w3.org/Fonts/WG/track/actions/116

kuettel: compression team are woring on improvement on decompression speed, with get to a chrome release; once it gets to stable we have new numbers. that will take time.
... so we could close it and make a new action for round 2

Vlad: or bump due date to october

kuettel: ok

action-168?

<trackbot> action-168 -- Roderick Sheeter to Measure RAM usage for woff2 vs. woff1 -- due 2015-05-13 -- OPEN

<trackbot> http://www.w3.org/Fonts/WG/track/actions/168

RSheeter: nope

action-171?

<trackbot> action-171 -- Vladimir Levantovsky to Review conformance reqs to ensure they can actually be implemented -- due 2015-05-06 -- OPEN

<trackbot> http://www.w3.org/Fonts/WG/track/actions/171

vl this is an all-group assinment. everyone should look at the spec to check this. before f2f if poss

scribe: found one or two, will need to deal with at f2f

action-174?

<trackbot> action-174 -- Chris Lilley to Ask webappsec to review woff2 -- due 2015-04-29 -- OPEN

<trackbot> http://www.w3.org/Fonts/WG/track/actions/174

ChrisL: asked at tpac, could give them a deadline

action-176?

<trackbot> action-176 -- Roderick Sheeter to Test hmtx transformation over google fonts corpus (how many lsb == x-min for all glyfs, what savings) -- due 2015-05-27 -- OPEN

<trackbot> http://www.w3.org/Fonts/WG/track/actions/176

Vlad: preliminary tests show not much benefit, confirms earlier analysis on MTX vs woff2 preprocessing
... it doesn't buy much in term of compression gains
... unless you have additional info lets decide now - drop or pursue?

KenLundeAdobe: leave it alone is safest

Vlad: jfkthame you acked considering this, any ideas?

jfkthame: dont feel strongly one way or the other. its a very simple transform to deal with on decoder side and gets 1% which is worthwhile
... so really we should do it
... but ok either way with group decision

Vlad: Cosimo seemed to say we reduce the data size into brotli but loose some entropy efficiency
... so not a 1% gain overall

jfkthame: (checks)

Vlad: avg saving 548 bytes on the corpus.

jfkthame: and avg font size?

Vlad: avg glyphs was 700. so less than a byte per glyph saved

jfkthame: link to data?

<Vlad> http://lists.w3.org/Archives/Public/public-webfonts-wg/2015May/0028.html

Vlad: we can defer decision if we want to research more

RSheeter: if we are really saving 1% we should do it

jfkthame: it is indeed 1% looking at mean filezize

ChrisL: agree we should keep looking at it if 1% and if reconstruction is easy

Vlad: bigger question is spec extensibility

<KenLundeAdobe> As long as the decoding restores the removed 'hmtx' data, I have no objection.

Vlad: we identified a set of transforms it makes sense to keep. insteead of a flag for transformed tables, decision was to reserve the fla for something else

<KenLundeAdobe> (I am about to take my daughter to school, but will stay connected as I should be back in 10 to 15 minutes.)

Vlad: now we see no need for reserved flags but a clear ne to make the spec extensible if we find another preprocess transform
... including possible future releases of the spec
... unfortunate at this point but can still do
... does not affect wire format, would affect implementations
... do we do a bit more now to make the spec extensible?
... um, silence?

jfkthame: we should intruduce a table transform flag, ignored for loca and glyf
... used for hmtx

ChrisL: a one bit flag only lets us do this once

Vlad: we would have to change the spec and update implementations. existing fonts still be compliant

RSheeter: what happens when i get a better hmtx transform. one bit is not enough

ChrisL: this is what version numbers are for, not single bits

with flag we can extend it. once

ChrisL: dont follow how it helps more than once

Vlad: suppose we use it for hmtx processing
... later we have a new idea

<scribe> ... new spec defines that. flag on cff will now be set

ChrisL: ok its one flag *per table* i get it now

RSheeter: but we get to extend each table exactly once

Vlad: agreed
... we could have been smarter. likelihood is less than that we find something for anew table
... glyf and loca are always preprocessed so that is a consequence of the late spec change. impls will do this anyway
... for any other table, flag bits will show the optional transform

ChrisL: current impls will do what with it?

jfkthame: if its reserved we should check if its zero

ChrisL: yes, clearly
... otherwise it can't be relied on

jfkthame: says reserved, does not say must be zero

Vlad: if we reserve bits 6 and 7 then we must check they are zero. if we use one as a transform flag then both values are allowed

<KenLundeAdobe> (I'm back)

RSheeter: think we should have an extensibility mechanism, concerned about only once

jfkthame: propose using 2 bits for a 4 value version number
... on a per table basis

ChrisL: feel more comfortable with 4 values rather than 2

jfkthame: we only need a few bits so this gives us a coule of chances per table to improve things

ChrisL: i like jfkthame's proposal

Vlad: we could, yes, use it like that to define over time. wondering if theyre is anything else we would want to flag

RSheeter: worse comes to worse we can say that v2 is like v1 plus an extra thing

Vlad: ok sleep on it and follow up in email
... jfkthame please send a message for benefit of others not on the call

action jfkthame to propose two-bit per table version number

<trackbot> Created ACTION-177 - Propose two-bit per table version number [on Jonathan Kew - due 2015-06-03].

kuttel; we want to factor in dropping fonts into this versioning discussion

Vlad: if unknown transform is found on a table, temporarily it will cause older decoders to drop the font so we would not do lihtly and is not a long term problem
... must spell out what to do with unknown transformed tables
... ok that was a good discussion which we should continue on the list
... agenda items concluded. eob?

f2f

Vlad: we have conf room for the full two days
... want to be 100% set on conformance test suite definition ie for each test, what is needed to implement it

so test plan is final

scribe: aside from tht, additional agenda items welcome. good point for final decision on extensibility and versions

kuttel: sounds good to me.

RSheeter: we are at about 55% test coverage now

kuettel: of the ones defined so far

RSheeter: yes

kuttel: so would like to see us focuss on the ones undefined, can go faster on the existing ones

Vlad: quite a few new requirements, need to check there are none missing and some are placeholders

kuttel: important to have khaled comment on ease of implementation on the new ones

Vlad: yes
... but first check the requirements are reasonable. we eliminated one unreasonable one
... organising a social for tues night. any dietary restrictions?

kuuttel: yes, steak only
... (grins)

jfkthame: suitable for emailing to the rest of us

Vlad: we will email you pictures

adjourned

rrsagent where are you!!

Vlad: remote participants welcome