Re: Conference call minutes, May 19.

On Wednesday, May 19, 2010, 5:26:56 PM, Vladimir wrote:
   
LV> I was not able to get minutes generated by the RRSagent, please
LV> see below the snapshot from the IRC channel:

HTML minutes made from Vlad's IRC log at
http://www.w3.org/2010/05/19-webfonts-minutes.html

and below as text for bots.

Thanks to Sylvain for minuting.

                           SV_MEETING_TITLE

20 May 2010

Attendees

   Present
          erik, jdaggett, +1.443.895.aabb, jfkthame, +1.206.324.aacc,
          sylvaing, +1.425.882.aadd, +1.510.816.aaee, +1.250.668.aaff

   Regrets

   Chair
          SV_MEETING_CHAIR

   Scribe
          sylvaing

Contents

     * [2]Topics
     * [3]Summary of Action Items
     _________________________________________________________

   <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

Summary of Action Items

   [End of minutes]



-- 
 Chris Lilley                    mailto:chris@w3.org
 Technical Director, Interaction Domain
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Received on Thursday, 20 May 2010 10:40:29 UTC