- From: Chris Lilley <chris@w3.org>
- Date: Thu, 4 Nov 2010 14:25:31 +0100
- To: "Levantovsky, Vladimir" <Vladimir.Levantovsky@MonotypeImaging.com>
- CC: "public-webfonts-wg@w3.org" <public-webfonts-wg@w3.org>
On Thursday, November 4, 2010, 12:32:50 PM, Vladimir wrote:
LV> http://www.w3.org/2010/11/04-webfonts-minutes.html
LV>
and below as text for trackbot.
WebFonts Working Group Teleconference
04 Nov 2010
[2]Agenda
[2] http://www.w3.org/Fonts/WG/wiki/2010-TPAC#Agenda
See also: [3]IRC log
[3] http://www.w3.org/2010/11/04-webfonts-irc
Attendees
Present
Roseraie_1
Regrets
Chair
SV_MEETING_CHAIR
Scribe
Liam
Contents
* [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]http://www.w3.org/Fonts/WG/wiki/2010-TPAC#Agenda
[9] 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> [10]http://www.w3.org/Fonts/WG/wiki/2010-TPAC#Agenda
[10] 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> [11]http://code.google.com/p/epub-revision/
[11] 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> [12]http://dev.w3.org/webfonts/WOFF/spec/#Metadata
[12] http://dev.w3.org/webfonts/WOFF/spec/#Metadata
<Vlad> [13]http://dev.w3.org/webfonts/WOFF/spec/#Metadata
[13] 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 [14]http://www.idpf.org/specs.htm ]
[14] 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> [15]http://dev.w3.org/webfonts/WOFF/spec/
[15] http://dev.w3.org/webfonts/WOFF/spec/
and [16]http://www.w3.org/TR/2010/WD-WOFF-20100727/ as official
public Working Draft
[16] http://www.w3.org/TR/2010/WD-WOFF-20100727/
<Vlad> relevant to our discussion of the WOFF spec:
[17]http://lists.w3.org/Archives/Public/public-webfonts-wg/2010Nov/0
000.html
[17] http://lists.w3.org/Archives/Public/public-webfonts-wg/2010Nov/0000.html
<ChrisL> also relevant
[18]http://lists.w3.org/Archives/Public/www-font/2010OctDec/0067.htm
l
[18] http://lists.w3.org/Archives/Public/www-font/2010OctDec/0067.html
<Vlad> and
[19]http://lists.w3.org/Archives/Public/www-font/2010OctDec/0066.htm
l
[19] 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
[20]http://lists.w3.org/Archives/Public/www-font/2010OctDec/0067.htm
l ]
[20] http://lists.w3.org/Archives/Public/www-font/2010OctDec/0067.html
DECISION: add text to say that a URI can be a IRI anywhere
[21]http://lists.w3.org/Archives/Public/public-webfonts-wg/2010Nov/0
000.html
[21] 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> [22]http://www.w3.org/Fonts/WG/track/actions/open
[22] 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> [23]http://www.w3.org/Fonts/WG/track/actions/15
[23] 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 [24]http://www.w3.org/2005/06/tracker/irc for
help
[24] http://www.w3.org/2005/06/tracker/irc
<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]http://www.w3.org/Fonts/WG/track/actions/23
[25] 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> [26]http://www.w3.org/Fonts/WG/track/actions/29
[26] 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> [27]http://www.w3.org/Fonts/WG/track/actions/33
[27] 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> [28]http://www.w3.org/Fonts/WG/track/actions/35
[28] http://www.w3.org/Fonts/WG/track/actions/35
chris: Jonathan had proposed some syntax but I wasn't happy with it
<ChrisL>
[29]http://dev.w3.org/cvsweb/webfonts/WOFF/spec/Overview.html.diff?r
1=1.24&r2=1.25&f=h
[29] 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> [30]http://www.w3.org/Fonts/WG/wiki/Main_Page#Introduction
[30] http://www.w3.org/Fonts/WG/wiki/Main_Page#Introduction
<ChrisL> [31]http://www.w3.org/Fonts/WG/wiki/TestPlan-UserAgent
[31] 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
[32]http://www.w3.org/Fonts/WG/wiki/TestPlan-Format after the break
[32] http://www.w3.org/Fonts/WG/wiki/TestPlan-Format
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> [33]http://www.w3.org/Fonts/WG/wiki/TestPlan-Format
[33] http://www.w3.org/Fonts/WG/wiki/TestPlan-Format
ChrisL: The majority of these tests appear to be testable by a WOFF
validator.
<ChrisL> [34]http://code.typesupply.com/wiki/woffTools
[34] 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
[35]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> [36]http://www.w3.org/Fonts/WG/wiki/TestPlan-Format
[36] 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> [37]http://www.w3.org/Fonts/WG/wiki/TestPlan-AuthoringTool
[37] 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
Summary of Action Items
[NEW] ACTION: chris to recategorise the general conformance criteria
[recorded in
[38]http://www.w3.org/2010/11/04-webfonts-minutes.html#action01]
[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