WebFonts Working Group Teleconference -- 04 Nov 2010

<trackbot> Date: 04 November 2010

<jdaggett> http://www.w3.org/Fonts/WG/wiki/2010-TPAC#Agenda

<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> http://www.w3.org/Fonts/WG/wiki/2010-TPAC#Agenda

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> http://code.google.com/p/epub-revision/

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> http://dev.w3.org/webfonts/WOFF/spec/#Metadata

<Vlad> http://dev.w3.org/webfonts/WOFF/spec/#Metadata

<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 restriction?

[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 http://www.idpf.org/specs.htm ]

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> http://dev.w3.org/webfonts/WOFF/spec/

and http://www.w3.org/TR/2010/WD-WOFF-20100727/ as official public Working Draft

<Vlad> relevant to our discussion of the WOFF spec: http://lists.w3.org/Archives/Public/public-webfonts-wg/2010Nov/0000.html

<ChrisL> also relevant http://lists.w3.org/Archives/Public/www-font/2010OctDec/0067.html

<Vlad> and http://lists.w3.org/Archives/Public/www-font/2010OctDec/0066.html

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

[closes http://lists.w3.org/Archives/Public/www-font/2010OctDec/0067.html ]

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

http://lists.w3.org/Archives/Public/public-webfonts-wg/2010Nov/0000.html

(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> http://www.w3.org/Fonts/WG/track/actions/open

[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> http://www.w3.org/Fonts/WG/track/actions/15

<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 http://www.w3.org/2005/06/tracker/irc for help

<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> http://www.w3.org/Fonts/WG/track/actions/23

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

action-29?

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

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

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

action-33?

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

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

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

[action-33 ongoing]

action-35?

<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> http://www.w3.org/Fonts/WG/track/actions/35

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

<ChrisL> http://dev.w3.org/cvsweb/webfonts/WOFF/spec/Overview.html.diff?r1=1.24&r2=1.25&f=h

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

<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> http://www.w3.org/Fonts/WG/wiki/Main_Page#Introduction

<ChrisL> http://www.w3.org/Fonts/WG/wiki/TestPlan-UserAgent

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 sufficient

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 render

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 Whatever...

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 http://www.w3.org/Fonts/WG/wiki/TestPlan-Format 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

[break]

<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> http://www.w3.org/Fonts/WG/wiki/TestPlan-Format

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

<ChrisL> http://code.typesupply.com/wiki/woffTools

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 http://www.w3.org/2010/11/04-webfonts-minutes.html#action01]

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

<ChrisL> http://www.w3.org/Fonts/WG/wiki/TestPlan-Format

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> http://www.w3.org/Fonts/WG/wiki/TestPlan-AuthoringTool

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 interactive.
... 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 stuff.

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 categories.
... 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 fonts.

ChrisL: What's the license?

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

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 conformance.

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 container.

John: A lot of UAs will be relying on system resources for font rendering.
... 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 reftest.

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

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 decodes.

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

- DRAFT -

WebFonts Working Group Teleconference

04 Nov 2010

Attendees

Contents

Review WOFF spec text before Last Call

Action items

Review test plan, allocate actions for test creation

Summary of Action Items

Scribe.perl diagnostic output