Re: F2F minutes, Thursday Nov. 4th

On Thursday, November 4, 2010, 12:32:50 PM, Vladimir wrote:


and below as text for trackbot.     

                 WebFonts Working Group Teleconference

04 Nov 2010



   See also: [3]IRC log







     * [4]Topics
         1. [5]Review WOFF spec text before Last Call
         2. [6]Action items
         3. [7]Review test plan, allocate actions for test creation
     * [8]Summary of Action Items

   <trackbot> Date: 04 November 2010

   <jdaggett> [9]


   <ChrisL> guys, my time is split between svg and webfonts. So I will
   do webfonts in the mornings and svg in the afternoons

   <Liam> scribe: Liam

   <jdaggett> [10]


   added to agenda: discussion about ePub

   Vlad: let's start there

   John: christopher and I sent out some email to colleagues, not yet
   heard back...

   May be some concern from some foundries

   <jdaggett> [11]


   We may need in the woff spec to look at coming up with language...
   if it looks like there's an open-ended creep, woff becoming a
   general font format, foundries may be concerned

   cslye: we need to set boundaries, didn't want woff to be just
   another font format

   vlad: section 1 last para and note says, woff is intended for use
   with @font-face, which spells out the scope

   howcoe: I think it's too restrictive

   maybe end the sentence with @font-face

   John: from a foundry's perspective it's down to licensing issues

   jdaggett: I don't think we're tied to different licensing models

   vlad: [speaking for Monotype] we can license a font for a specific
   use, it's not the technology

   [discussion of differences between ePub and Web pages, and whether
   the spec allows this usage today]

   <cslye> Proposed change: "The WOFF format is intended for use with
   @font-face to provide fonts linked to specific documents."

   jdaggett: ePub 2.1 (current), but what's really being discussed is
   3.0 ...

   I posted a link to their wiki page. It's not (yet) a very coherent
   site though

   howcome: I think we could see this being used very quickly in ePub

   John: might there be useful extensions to metadata for ePub?

   <ChrisL> woff gives an unambiguous license link so is more suited
   for epub than obfuscation

   vlad: tells you the description of the font, who it's licensed for,
   I think it's all about the font, in woff

   <ChrisL> [12]


   <Vlad> [13]


   <Vlad> looking at the metadata section

   [discussion of christopher's text, and the word "specific" in it]

   howcome: the acronym WOFF needs to be explained in the abstract as
   well as the introduction

   vlad: the normative text also has downloaded fonts

   John: suggest use Web Documents instead of Web pages

   ChrisL: we can always add a glossary if we need to

   <jdaggett> I would change this to "The WOFF format is intended for
   use with @font-face to provide fonts linked to web documents"

   cslye: does that mean an ePub reader must implement a same-origin

   [several people] yes

   <ChrisL> need to avoid the idea that 'localhost' as an origin gives
   access to all fonts on all publications

   jdaggett: if epub is going to use woff they need to use css3 fonts,
   otherwise there's no guarantee they're loading the font in such a
   way that it doesn't affect other things

   e.g. there are APIs that allow you to activate a font system-wide on
   some systems

   vlad: the woff spec addresses that

   jdaggett: maybe we need to say to the ePub, you need to follow the
   spec in this area

   <John> Proposal: the WOFF spec contains four references to 'web
   page(s)'; all four of these should be changed to 'web document(s)'.

   cslye: agreed

   ChrisL: do we want to send an explicit message to epub or just rely
   on shared membership?

   jdaggett: the DAISY consortium, an accessibility group, ended up
   creating ePub; Japanese are pushing for EPUB 3 to become (when
   ready) a JIS standard

   vlad: if we make a statement to say that we're OK with EPUB using
   woff I think that's OK

   but I wouldn't want to push it too much, because it only makes sense
   if they mandate linked fonts in the first place

   EPUB current spec at [14] ]


   DECISION: replace Web page with Web document in our spec, in all
   four places

   <ChrisL> edit done

   DECISION: change downloadable to linked, in para before note in
   intro, User agents supporting the WOFF file format for downloadable
   fonts MUST...

   and next sentence in same pararaph

Review WOFF spec text before Last Call

   John: current status is public working draft

   ChrisL: we also have an editor's draft

   [we have had public feedback and it's been incorporated into the
   editor's draft]

   <ChrisL> [15]


   and [16] as official
   public Working Draft


   <Vlad> relevant to our discussion of the WOFF spec:


   <ChrisL> also relevant


   <Vlad> and


   howcome: I am happy to concur with the majority decision to go to
   last call

   (since won't be here tomorrow)

   ChrisL: suggestion to add a URL attribute to the description element

   DECISION: add a URL attribute to the description element, as per
   other elements

   l ]


   DECISION: add text to say that a URI can be a IRI anywhere



   (and response from Sylvain)

   DECISION: delete the paragraph, In addition, vendors MAY include
   additional types of metadata as new elements, ... on request).

   (since it is no longer correct)

Action items

   <Vlad> [22]


   [action 15]

   <ChrisL> action-15?

   <trackbot> ACTION-15 -- Jonathan Kew to split intro to remove these
   requirements and insert them into a new section, "normative
   references" -- due 2010-08-24 -- OPEN

   <trackbot> [23]


   <ChrisL> action-15 closed

   <trackbot> ACTION-15 Split intro to remove these requirements and
   insert them into a new section, "normative references" closed

   <Vlad> trackbot, close action 15

   <trackbot> Sorry, Vlad, I don't understand 'trackbot, close action
   15'. Please refer to [24] for


   <ChrisL> action-23?

   <trackbot> ACTION-23 -- Jonathan Kew to verify whether, with zlib,
   it's possible to have a stream that allows an EOF midstream, so
   extra data can be padded on mid-stream. -- due 2010-08-24 -- OPEN

   <trackbot> [25]


   jonathan: it turns out that you can add things that decompression
   will ignore, so nothing to stop you add stuff on the end of a
   compressed stream

   ChrisL: we already have a private data blob

   Jonathan: there's zillions of ways you could hide private data, so I
   don't think it's a problem

   we do reject a font if you leave extra dead space between tables

   john: and if the uncompressed size doesn't match... but that's a
   different thing

   jonathan: we could reject if people are trying to slip extra data
   in, but that'd require reading the whole stream first

   <ChrisL> close action-23

   <trackbot> ACTION-23 Verify whether, with zlib, it's possible to
   have a stream that allows an EOF midstream, so extra data can be
   padded on mid-stream. closed

   DECISION: action-23, extra data after the font, isn't an issue


   <trackbot> ACTION-29 -- John Hudson to review woff faq with chris
   and vlad -- due 2010-10-06 -- OPEN

   <trackbot> [26]


   vlad: is there something we need to change for EPUB?

   John: I like the phrase "Web-served typography"...

   we might want to review it, part of the purpose of the FAQ is to
   popularise fonts on the Web

   vlad: the FAQ must not be more restrictive than the spec itself


   <trackbot> ACTION-33 -- Chris Lilley to write up the proposed text
   for WOFF processing model -- due 2010-10-27 -- OPEN

   <trackbot> [27]


   [action-29 remains open, new stuff to look at]

   [action-33 ongoing]


   <trackbot> ACTION-35 -- Jonathan Kew to add the language expalining
   that attributes with 'id' as a name should not be treated as element
   ids. -- due 2010-10-27 -- OPEN

   <trackbot> [28]


   chris: Jonathan had proposed some syntax but I wasn't happy with it



   chris: XML doesn't have a standard element called id, it does have

   <ChrisL> so we should say "of type ID"

   DECISION: proposed changes from Chris accepted

   close action-35

   <trackbot> ACTION-35 Add the language expalining that attributes
   with 'id' as a name should not be treated as element ids. closed

   <Vlad> trackbot, close action-27

   <trackbot> ACTION-27 Write up a test suite plan closed

Review test plan, allocate actions for test creation

   <ChrisL> [30]


   <ChrisL> [31]


   chris: each testable assertion in the spec is marked up in the spec

   the test plans link back to those assertions

   One in particular, css3font, is not clear

   jdaggett: it's important to have this, but I don't think it's

   I think there's lots of cases where you want to create many tests,
   and in others you may want to test combinations

   so this [plan] is important, but it's not like you want to have one
   test for each one

   ChrisL: I've said for some of them you need e.g. 4 tests, but I'll
   add more tests if suggested.
   ... Quite a lot of these tests will require fonts with a known flaw,
   to test "you must not..." and we'll also need a font that does

   jdaggett: I made a font with an encoding that displays the word
   "FAIL" as "PASS" for CSS
   ... it would be ice to use reftest format

   a reftest is the idea that you have 2 versions of a Web page that
   should render identically, and you can test them automatically, by
   rendering both and comparing the results

   Some people will have test suites with tests and images, but problem
   is hard to maintain, and too likely that people regenerate lots of
   images without checking carefully.

   ChrisL: another reftest advantage is that e.g. sub-pixel rendering
   will always be the same

   jdaggett: example page 1 uses an invalid font, so it'll render with
   the default font; page 2 uses the default page... so, the pages
   should end up looking the same

   vlad: how would it work if you _should_ see the font?

   jdaggett: there's a set of tests, you have to install some fonts on
   your system

   and they're set up so you see FAIL if you didn't install them

   Jonathan: it can be difficult to make a font that has _only_ the
   flaw you're trying to test for

   <ChrisL> Tal can make fonts with specific flaws

   jdaggett: I'd like to see some common name, e.g. I've produced fonts
   starting with CSS-Test, so they all appear together in font lists

   cslye: how about WFWG?

   jdaggett: I think WOFF-Test would be clearer, e.g. Woff-Test Invalid

   Specific items...

   e.g., langselect, behaviour is optional, so hard to have a fail,
   current spec not testable

   Liam: if it's a SHOULD, your spec passes the test if it's
   implemented, it's not about whether the UA conforms but about
   whether the spec can be implemented

   ChrisL: for lang it seems it could be automated
   ... next steps? we can still find flaws, and additional tests

   jdaggett: some of these are going to be hard

   e.g, whether a font is available to the OS

   Liam: what about availability to plugins?

   jdaggett: ascending-recreated harder to test

   with certain system font APIs you don't have access to all the font
   data structures

   Liam: if it's not testable, might be better not to be normative

   vlad: we really want it as MUST though

   jdaggett: we don't necessarily need to test all elements in the spec

   ChrisL: I did this approach so we can make a conscious decision
   about what to test

   <ChrisL> ok lets go to
   [32] after the break


   John: on font being the same... we've used a couple of references to
   "the original font data"

   ChrisL: I plan to challenge it, to clarify

   John: for font vendors "the original font" is something a long way
   upstream from what we mean, the font that gets shoved into woff

   jdaggett: describing this has always been hard

   vlad: whatever is provided to woff

   John: we need to define that clearly, a glossary maybe or a
   definition, or a better term


   <TabAtkinsTPAC> ScribeNick: TabAtkinsTPAC

   jdaggett: For the test suite, we'll categorize things that are
   required, but can't be tested.

   ChrisL: Let's go through the format tests.

   <ChrisL> [33]


   ChrisL: The majority of these tests appear to be testable by a WOFF

   <ChrisL> [34]


   ChrisL: The current validator ^^^ actually already tests several.
   ... It creates an HTML file with the test data.

   [chris shows an example of the results file]

   <ChrisL> ACTION: chris to recategorise the general conformance
   criteria [recorded in

   <trackbot> Created ACTION-36 - Recategorise the general conformance
   criteria [on Chris Lilley - due 2010-11-11].

   <ChrisL> [36]


   ChrisL: Where I think the assertions are etestable with the
   validator, I noted that in the test nme.
   ... One requires you to have access to both the sfnt and the woff
   font, because the tables have to be in the same ordere.
   ... I believe it would be fairly easy to knock together a quick
   program to do that.
   ... The WOFF validator does test that the metadata is well-formed,
   and our schema tests that it matches.
   ... There's one that now falls into the general category, which
   isn't testable.
   ... The "may compress" test.
   ... You can test that the UA supports it, but it's not something
   testable for the format.

   <ChrisL> [37]


   ChrisL: Many of these require you to compare the woff and the sfnt.
   ... Like the one that says you must not compress if the compression
   would make it larger.
   ... So some of these we'll require an opentype file to be brought
   into your tools, and if it makes a woff it fails.
   ... So say you have a fixer program that makes a woff, do you pass
   if you emit a warning before fixing? Or if you just fix it?
   ... Currently the spec says that for [that one?], it's okay to emit
   a warning.

   [chatter about that test, about how changing the padding can alter
   the checksum]

   Vlad: We talked about the scope. Whatever is given to the WOFF
   converter is the input; whatever happened to the font *before* that
   is out-of-scope.
   ... So if some tool changes things and corrects the checksums, we
   don't care.

   jdaggett: It seems the testsuite for this is a bit tricky.
   ... In some cases we have to say "the tool must spit out an error",
   but in other cases we can just inspect the woff.

   Vlad: There is a requirement for the WOFF converter to complain
   about the input.

   jdaggett: If I have a conversion tool that fixes up bogus fonts
   before the import, that makes it somewhat hard to test.

   ChrisL: Right. So for all thesee authoring tools ones, it's heavily
   ... We can allude to that - "If your tool does [this], you can't
   test [that]."
   ... So I've made wiki pages for these categories.

   Vlad: I asked Tal if he'd be available for phone discussion.

   jdaggett: I think we should set a date for testsuite, and then work
   our way back to see what has to happen by when.
   ... Ideally we'd have something by Xmas, maybe middle of January.

   ChrisL: Definitely my idea - by the time we exit LC, we should be
   ready for CR immediately.

   jdaggett: Did we decide on style conformance?
   ... CR exit criteria?

   ChrisL: I'd suggest the usual "2 independent impls" rule.
   ... I'd suggest *not* adopting CSS's "no nightly build" thing.

   jdaggett: We'd have to be careful. Chrome, frex, only releases
   nightlies as source. I don't want to allow source-only releases as
   ok, because it's too hard to ensure that you have the exact same

   ChrisL: The validation tool is built from source, though.

   jdaggett: That's Python. A bit different from a huge C++ project.
   ... Also, do we require 2 *complete* impls, or just 2 impls of each?

   ChrisL: That's somewhat risky.

   howcome: But it's a pretty small spec.

   ChrisL: As long as it's achievable, I'm happy. It's obviously
   stronger and better.
   ... Firefox currently allows things we now say you must reject.

   RESOLUTION: To go from CR to PR, require two full passes of the test
   suite for each category.

   ChrisL: We've got gneral, useragent, authoring tool, font format
   ... For the authoring tools, what do we have? We have fontforge,
   jonathan's tool, tal's tool. That's 3 tools.
   ... I suspect FontSquirrel might not work.

   Ask BitStream or Laurence Penney if they have a woff authoring tool.

   jdaggett: Do we have strict requirements as to whethere the tools
   must be public?

   ChrisL: Well, they need to be available.
   ... So it sounds like we have CR exit criteria pinned down.
   ... Should I take an action to start making tests?

   ACTION chrisl to get cracking on test suite.

   <trackbot> Created ACTION-37 - Get cracking on test suite. [on Chris
   Lilley - due 2010-11-11].

   jdaggett: I'd like to be involved in getting/making the test fonts,
   so we can use them elsewhere, or reuse CSS fonts.

   action jdaggett to help with font creation for the test suite.

   <trackbot> Created ACTION-38 - Help with font creation for the test
   suite. [on John Daggett - due 2010-11-11].

   cslye: Is there interesting in having both TTF and OTF?
   ... I can help with the guts of otf.

   Vlad: Monotype provided a set of test fonts that are valid ttf

   ChrisL: What's the license?

   Vlad: ISO license.
   ... But it doesn't matter - we can give it to the W3C directly if

   ChrisL: It would be useful to hav a set of tests that involve
   "convert all these fonts" that exercise a bunch of features.
   ... What about AAT and graphite? They're also sfnt.

   jdaggett: I'm not sure eyou have testabl requirements.

   Vlad: We don't really care what tables are implemented in the font,
   just that *whatever* the tables are, they're also in WOFF.

   jdaggett: There's a real security problem here, though.
   ... Especially on OSX, it's easier to cause exploitable system
   crashes with fonts, so we're now using the google sanitizer with a
   few tweaks.
   ... So private tables are dumped, as an unknown.
   ... But that happens *after* WOFF has been unpacked.

   ChrisL: The UA is explicitly allowed to not decode all tables.
   ... But we're talking about an authoring-tool requirement.

   jdaggett: My concern was that trying to test AAT fonts to see if
   they'r rendered correctly, they won't be.

   Vlad: But we can just test that the tables are present directly.

   jfkthame_afk: One ething we didn't address is that if a UA supports
   WOFF, they're required to support both TTF and CFF outlines packaged
   in WOFF.

   John: In LA we talked about reference to an iso level for

   jdaggett: OFF is a file format that covers an sfnt-like structure,
   it defines a set of tables, but a font could contain tables that
   arene't in the OFF spec. Doees that make it not an OFF spec?
   ... The OFF spec just has a set of base tabls.
   ... And all these formats will have those base tables.

   Vlad: The MS site says that current OTF1.6 is indeed fully
   technically compliant with the ISO spec.

   John: They'll probably never diverge, but there's nothing
   technically requiring them to always converge.

   jdaggett: I think we should include CFF. We're not a conformance
   spec, so it doesn't really matter if a particular UA supports them.

   Vlad: There has to be some basic level of behavior that you must
   have to pass.

   John: The professional design market, a large number of fonts
   marketed to them are CFF.

   jdaggett: Should we make it a requirement to support rendering both
   TTF and CFF?

   howcome: No.
   ... This is just a container; you can't start pointing into the

   John: A lot of UAs will be relying on system resources for font
   ... On desktop/laptops, that's probably not an issue for CFF. But on
   mobile devices, the system may only provide support for TTF, or only
   unhinted TTF.

   Vlad: So establishing a minimal baseline, we can at least test that
   things work.

   howcome: We can use Ahem for that.

   jdaggett: I don't understand why we have a problem with requiring
   CFF support on the authoring tool.

   cslye: Is there anything that just compares the data bit-by-bit?

   Vlad: Yes.

   cslye: So the issue about rendering is mmot, right?

   Vlad: No, we still need to test some rendering, to ensure that
   browsers successfully download and unpack.

   howcome: You can reftest it, by sending the bare font and the
   woff-packaged variant.

   Vlad: So on a mobile platform that doesn't support CFF...?

   TabAtkinsTPAC: They'd both fail to render, which is a pass for a

   ChrisL: You can ask UAs for a form listing what they claim to

   howcome: But as a browser vendor, can I make guarantees, when I'm
   relying on the system to do my rendering?

   ChrisL: At the end of the day, authors are asking if CFF will work.

   jdaggett: And we're kind of implicitly saying no.

   cslye: I don't care if it doesn't render, I just care if it gets
   mangled or not.
   ... To ensure that theree's nothing unique in the format that makes
   it come out badly from the formatter.

   jdaggett: We can make tests that pass trivially if the UA dosn't
   support CFF, or passes if the UA does support CFF and correctly

   Vlad: There are several conformance levels for TTF.

   ChrisL: We plan to do LC at the next possibility, have a 4-week LC
   period ending around christmas, then do CR in January.

   <Vlad> Adjourned, will continue in the joint CSS/SVG WG meeting

Summary of Action Items

   [NEW] ACTION: chris to recategorise the general conformance criteria
   [recorded in

   [End of minutes]

 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups

Received on Thursday, 4 November 2010 13:25:52 UTC