<jdaggett> jfkthame: is ??p4 you?

<jfkthame> jdaggett: no, that's me

<jdaggett> oh sorry

<jdaggett> ;)

<jdaggett> Vlad: you're buzzing like crazy...

<jfkthame> hmm

<jdaggett> ok, sorry... ;)

<jfkthame> muted my phone, is that better?

<jdaggett> YES

<jfkthame> i'm on a cellphone this week and apparently it's really noisy, so i'll probably avoid speaking if possible

<jfkthame> Vlad: could someone else lead this, given my noisy line?

<jfkthame> Vlad: suggest you email a proposal of what you'd like to add there, it's not clear to me what further detail is appropriate at this point but seeing a specific description might help me understand

<erik_> (Chris Lilley isn't here to make notes - are we on our own?)

<erik_> (I;m in a noisy room and struggling to hear)

scribenick is sylvaing

<scribe> scribenick: sylvaing

<discussion of field description>

<cslye> Asking: Is there anything in the header that isn't described anywhere in the spec?

<cslye> Correction: Talking about s4 Table Directory.

<jfkthame> vlad suggesting that prose description should describe the fields one by one, each in its own standalone paragraph

Vlad: I wonder if it would be appropriate to have a section describing WOFF creation tools as well

suggests moving on with reviewing the actual content and keep overall spec formatting issues separate

<jfkthame> sect 2 para 2 (edited version) should explicitly note that no "dead space" except alignment padding is allowed

Vlad and sergey discuss possible redundant or repetitive statement between section 2 and 5

jdaggett: it may be repetitive, but it does not hurt

<jfkthame> there may be some repetition between requirements in the intro and overall structure and then the lower-level details, but i don't think that's a problem - last week people were wanting to include more explicit requirements in the intro sections

<jfkthame> no, last font table *should* be padded even if no metadata, required for checksumming (as longs)

sergeym: the repetition is incomplete however; it does not always repeat that the last section of the file does not need to be followed by padding

<jfkthame> (oh, sorry, that applies to decompressed tables, not strictly necessary for compressed tables)

<jfkthame> section 4 says explicitly that all font data tables must be padded

<jfkthame> "WOFF font tables have the same requirement: they MUST begin on 4-byte boundaries and be padded with nulls to the next 4-byte boundary"

<jfkthame> as currently written, padding IS required for all font data tables

<jfkthame> always pad

<jdaggett> ditto, always pad

<jfkthame> right, there's no end-of-file exception for the font data tables; we could state that explicitly, to remove the current confusion

issue: make it clear that font table padding is always present even if optional blocks are not there

<tiro_j> If the OT spec is vague on this, might there be existing tool issues resulting in source fonts having unpadded tables?

<jfkthame> tiro_j: there have been some issues in the past, i think current tools have converged on the always-pad interpretation

<discussion about DSIG removal requirement in section 5; jdaggett differentiates between the tool that produces OpenType and the tool that converts the latter to WOFF>

<jfkthame> the spec suggests (SHOULD) "simple" packaging that will be 100% reversible, it's just noting that if the woff-creating tool is modifying the font in any way, it MUST deal with the dsig and checksums

sergeym: I do not really care what happens before the binary font is produced. but on the user agent side, while I do not want to discourage editing the font data, it should be clear that 'you're on your own'

??: can you elaborate on user agents editing/removing font data ?

sergeym: yes, Chrome removes OpenType layout tables. I'd like to make it clear that's outside the scope of this spec

??: but how ?

<tiro_j> Except for installing

sergeym: everything that happens before bits are provided to WOFF for encoding and after the font has been unpacked should be outside the scope of the spec

<tiro_j> Since the point of the WOFF standard is to define a format for web served fonts distinct from locally installed fonts, the installation of an unpacked font is not outside the scope of the spec.

<cslye> The process begins when ANY kind of font data is presented to a WOFF creation tool. It ends when that same data is unwrapped from WOFF at the UA end... yes?

cslye: yes

<jfkthame> issue: rewrite last para of section 5

issue: attempt to define the boundaries of WOFF's losslessness clearly e.g. Chrome's OTS edits are out o scope

<jfkthame> i didn't touch that section yet

<jfkthame> there are two kinds of possible error - the offset/length are bad, or the content of the metadata is invalid

<jfkthame> suggest we reject the file if the offset/length are bad, as that means the file STRUCTURE is incorrect

<jfkthame> but if the metadata CONTENT is bad, we should simply ignore it

<jfkthame> as some UAs may not even load/look into it

<jfkthame> no, i don't think the metadata block should be required

<cslye> I like the idea of requiring WOFF creation tools to make valid XML.

<jfkthame> i agree we should change the spec to reject the file if the block offset/length are bad

<erik_> if the structure of the file is incorrect, all bets are off. File should be rejected.

<jfkthame> (same applies to the private data block)

issue: in section 6, a metadata offset/length invalidates the entire file; if the metadata block's XML content is invalid, the block is IGNORED

<jdaggett> csyle: i'm concerned about whether invalid xml in the metadata should be ignored

<jdaggett> sergeym: if you can't interpret metadata, ignore it

<jfkthame> if the XML content is bad, it would be appropriate for the UA to warn, but it should NOT reject the font because UAs that don't read metadata will proceed to use the font, and behavior should be consistent

<cslye> Foundries have an interest in ensuring that their metadata is not disposed of or ignored by the UA (if it's there).

<jfkthame> it's fine to require producers to give valid xml, but we must not require the UA to validate it

agree

<jdaggett> yes

a conformant tool may be required to produce valid XML; a conformant UA can only be required to process valid metadata XML

<erik_> I have to run to another meeting in a couple of minutes.

<jfkthame> in gecko we want to provide some way to display font information to the user, and if woff metadata is present we'd want to use that, but i don't believe there should be any *requirement* for it to be present or to be used

<erik_> bye

<tiro_j> Bye

<sergeym> bye

<Vlad> bye

<jfkthame> trackbot: make minutes

<jfkthame> anyone know how trackbot works? :)

<Vlad> Suggestred discussion point: whether processing of properly formatted XML metadata shold be optionla or mandatry for a user agent