See also: IRC log
<Vlad> scribe: Vlad
mgylling: introductions and
opening of the meeting
... reviewing the agenda for the day
... ... and for the whole WG meeting including Tuesday
IG - discussing the additional agenda items for the meeting
mgylling: The home for pagintaion
spec will be CSS WG. We want to help them with pagination
support to improve support in existing browsers
... among many things we need to do is complete set of requirements
... asking Dave to present
<ivan> Dave's draft
Dave Cramer: CSS is working on many things that would be considered building blocks of pagination. We need to figure out what needs to happen there for CSS to become a complete tool kit.
Dave Cramer: It is not a easy job, page is a complex object and we need to be able to identify them (first page of a chapter, paragraph, objects in the page that may require different desing or content)
Dave Cramer: ... outlining the scope of work items that have been conducted in CSS
gerardo: is it problematic to accomplish the process of switching between pages?
Dave Cramer: some of this depends on user agent implementations, some are user-directed actions
Dave Cramer: some page switching is automatic (reached the end of the page and want to switch to the next)
Brady: how do we know what the page run is, what is the page box, etc. Sometimes you may have more than one page on screen?
gcapiel: what is the mechanism to file these questions and requirements?
Brady: beleives this may go outside of the CSS territory and will involve more concepts including work done in HTML
mgylling: today it is unclear
what needs to be done and most implementations don't do it
... suggests to populate the wiki page with the event requirements for pagination
Dave C, and Markus discussing the needs of the pagination work and how to collect a complete set of issues
Ivan: we may want to discuss this tomorrow (see agenda) when Robin is here
Ivan, Markus, Dave, Brady discussing the work done in HTML WG regarding DOM, pagination events (such as document.ready), etc.
It is unclear what is currently done / implemented vs. what else needs to be done
mgylling: creating a list of Functional Requirements on wiki, to be posted here later
<dauwhe_> Font load events module link: http://dev.w3.org/csswg/css-font-load-events/
mgylling: continuing the discussion of the requirements, catgorizing them for events, DOM, APIs
<ivan> Guest: Karen (karen) Myers, W3C
<ivan> Guest: Bobby (bobby) Tung, Wanderer
action gcapiel event s related to TTS and pagination
<trackbot> Created ACTION-9 - Event s related to tts and pagination [on Gerardo Capiel - due 2013-11-18].
actioin Brady paginations related to DOM access
action Brady paginations related to DOM access
<trackbot> Created ACTION-10 - Paginations related to dom access [on Brady Duga - due 2013-11-18].
<mgylling> notes for Brady and Gerardos action items:
<mgylling> Functional Requirements re dynamic pagination: events and DOM
<mgylling> - book load
<mgylling> - page load
<mgylling> - page change (e.g. reflow after font size change)
<mgylling> - what page loaded
<mgylling> - when a page is loaded
<mgylling> - when a font is loaded (cf CSS3 Fonts Loaded Events Module 3)
<mgylling> - TTS reaches end of page, event to auto-trigger page turn
<mgylling> (note two scenarios: external AT vs self-voicing)
<mgylling> Whats a page, how to I reference it
<mgylling> I get an event that a page is loaded, how do I get to that page
<mgylling> turn a page
<mgylling> go to a page
Dave Cramer: about to present pagintation document
(see link above)
Ivan: We need to separate the concepts of what's in the spec vs. what is current implementations do
Dave Cramer: we may need to identify additional constraints for aligning pages (speaking about wodows and orphans on a page)
RIshida: speaking about the need to identify clear items that need to be addressed by either CSS or HTML or other groups
Ivan: we need to capture and explain the issues that will define the direction for CSS and HTML WGs work
<ivan> Guest: Manu (manu) Sporny, Digital Bazaar
Brady: on the issue of optimizing for page breaks and how it is currently done. A lot of this is currently done manually and the question is if there is an algorithmic solution to this
mgylling: suggestion to review the TOC and discuss the areas that are covered / not covered yet
Dave Cramer: Most of it is jsut a sceleton now to outline what needs to be covered
mgylling: top level questions
about locales and cultures, how to transgress both the paper
print format and dynamic pagination for adaptive content
... Adobe joined the IG recently and we hope they can contribute from tools perspective
Dave Cramer: items to consider include internationalization, cultural differences, types of content (books, magazines, etc.) we need to address, etc.
coffee break - 20 min
<ivan> scribe: ivan
mgylling: we have to settle the scope question
… the document should be clear what is in scope and not
… probably in the status or in the abstract
… we have noted that we are not willing (yet) to rule out some of the locale issues
dauwhe_: some of us had discussions that widow has their counterpart in, eg, chinese
mgylling: how about we list candidates for exclusion
dauwhe_: maybe we start with domains, and then language etc.
gcapiel: what is the criteria for exclusion?
dauwhe_: which has some narrow rules that are not applicable outside of that domain
… althogh they may illustrate the extreme issues that are more in common
… eg, religious texts may have very complicated requirements, but, eg the footnotes used in a bible illustrate a lot of problems appearing elsewhere
brady_duga: and if we exclude by simplicity, then we may exclude features that are useful elsewhere
ivan: is fixed layout out of scope of this document?
brady_duga: fixed layout is based on explicit techniques and we may not need special css for it
ivan: if we exclude non-books (newspapers, magazines, etc), we have to make it clear that this is not out of scope for the IG but for the first version of the pagination document
brady_duga: it is not clear how to define what is a journal or not,
dauwhe_: one of the aspect is that the content spreads opver the document, inclusion of advertising, etc
… industries are organized around these distinctions
jeff: we have to be careful not to use the word 'out of scope', just not to be offputting?
dauwhe_: yes, we should say something like 'our initial concern', something like that
Guest: Jeff Jaffe, W3C
brady_duga: poetry? I am not even sure what the rules are?
koji: CSS has discussed on how much poetry should be covered, left alighn first line, and then other alignments..
… the group does not really know
dauwhe_: there are a number of books I have that can be turned into CSS without a problem
koji: it is fine to include poetry, but we have to know how publishers want to layout poetry
mgylling: some poetry publishers told me that they use fixed layout
… they did not want a new page for a poem, but rather scroll
… this is not doable
… breaking the poem into multiple pages is not acceptable
koji: we need to talk to poetry publishing
… we really need to discuss them
<mgylling> these are the domains for which we will request additional editors, and which will be covered in later versions of the pagination doc:
<mgylling> - newspapers
<mgylling> - magazines
<mgylling> - childrens picture books
<mgylling> - comics / manga
<mgylling> - poetry
mgylling: next area is locales
Guest: Richard Ishida, W3C
dauwhe_: there are ongoing efforts for other languages: indic, korean, chinese
richard: the Chinese IG for HTML5 is working on this
bobby: jlreq completed almost everything, but not applied fully for chinese, so what we have to document is the difference
richard: we would love to find people to do the same for tibetian, thai, hebrew, ...
dauwhe_: my initial insticts were that these should be out of scope
richard: we should have 2 different doc, western layout document, and then there is one that says where css has to cover certain issues. These latter are not necessarily for western only
dauwhe_: that would make sense, it would make it easier to move forward
<mgylling> Ivan: we need to be clear if we do westernoreq, also need to set up better contacts and relationship with the korean, chinese req groups, be in the loop for documents that are under preparation
richard: it is a bit difficult with i18n is being a separate group
… the best is to find somebody in both groups in general
… we are also looking at requirements, too
… eg I am looking at ways of having counter styles
… and that would be relevant to this group, too
mgylling: it sounds like a coordination nightmare
… we need to prepare a document quickly
koji: how about making levels
ivan: what about non-English cultures and usages?
dauwhe_: pragmatically the content should include what we get input for
mgylling: we would like to get the document good enough that it would be reliable for further work
brady_duga: are the other document (jlreq, etc) include all features for publishing
dauwhe_: yes, it does
richard: it is more oriented to print like stuffs than electronic ones
… the focus was printing, and not pages
koji: it says its focus is for regular priting
richard: the korean will be different, it may be underspecified
… klreq is probably oriented towards print, but will not have so much information than jlreq
… you will need more information
… we need people in countries to develop that
mgylling: and we have to be realistic here
… the core observation seems to be
<mgylling> Resolution: Dave's document will be recast as latinReq. It will once published include only layout expectations (no refs to CSS etc).
<mgylling> There will be an additional separate document which more directly poses requirements on CSS etc, which will draw from jlReq, latinReq, klReq etc.
mgylling: is there anyting in the question list?
dauwhe_: how would the group work on the document itself
… for simplicity is that I filter through me
manu: I am the chair of the RDFa WG and the JSON-LD community group, and I am also co-chair of the web payment CG
… the goal is to integrate payment into the architecture of the web
… ie, the browser should offer a facility where payment would go directly to the user
… web payment should make it very easy to buy books on line
… the question is whether this is of interest for this group?
dauwhe_: we are certainly interested in the concept
brady_duga: I am happy to bring the knowledge back
Vlad: is it something that you envisage something to be that would replace the commercial solutions?
manu: that is certainly what we would like to be
… json-ld as well as RDFa was for interest for us for this reason
… eg, having the license, bills, etc, sent back in machine readable ways
… it is not only getting money from A to B, but other things
mgylling: do we believe that the current ebook retail work has usage pattern that would challenge your model
… I do not know, but it is a question
dauwhe_: we are of course interested to change the patterns
manu: selling ebooks are of course a big use case for us
… we would like to have more expertise in the group
mgylling: we certainly have to take this back to our companies, because we are geeks here...
<dauwhe> scribe: dauwhe
mgylling: atomic advice from
... if you can't have a unicorn, can you have a pony?
... csswg asked what would be second-best solution for these use cases
... this idea of fallback may apply to more than csswg
... they asked for as much detail as possible
... document even edge cases; this will save solution designers lots of guessing
... don't have to prioritize everything, but certainly mention most important things of document
r12a: do on locale-by-locale
basis, with documentation
... asked for lots of examples
brady_duga: they also asked for
... if we can provide evidence for various requirements, the more the better
ivan: although a certain feature
is primarily for publishing, it's also useful for tradional
... Bert said that.
... the motivation was to convince those less interested in pagination to work on that
r12a: Dean was very focued on how
market prioritizes features.
... Apple agrees ruby feature is great, but won't implement because of lack of evicdence/market
mgylling: is it DPUB's place to
... asks Brady how they get data/priorities from publishers.
based on market pressures
... line breaking is terrible. But people still buy our books.
dsinger: it's important to say that your book can't be sold unless feature x is implemented.
brady_duga: hanging punctuation as example
ivan: reaching out to publishers
becomes very important
... use IPDF contacts to get data on priorities
mgylling: that applies across
everything we do
... this is something new. A dedicated survey: these are the requirements we've gathered. Prioritize them for us.
... that's one way to get there. I don't see how we can easily gather data.
ivan: we will see what we can do.
mgylling: in terms of moving
forward, concrete proposal. As soon as there's a new section in
pagination doc, to ask Dave to suggest agenda item for CSS
... so they can review. DPUB members can then join CSSWG telcom to discuss particular issue.
ivan: Bert is in both groups.
mgylling: anything else to encode
from previous session? Great!
... ten minutes till coffee break!
... Vlad, set stage for fonts and typography session. What kinds of problems/issues will we discuss?
... important for us to understand what you're working on.
... give us ten minutes to talk about overarching issues.
Vlad: it's not what's in my
brain, or from my company. It's from the people I interact
with, people with actual problems.
... that's how I created set of issues
... tried to create categorys.
... first: font licensing. From discussions with publishers.
... are publishing legally allowed to use existing font licensing?
... under what conditions can it be used?
... we cannot influence the license itself.
... if I have a license, is there enough of a toolset to embed fonts and satisfy conditions of license.
... license may say that font cannot *easily* be used.
... not clear how these tools work.
... some people are unaware of tools.
... they start with predisposition to assume they can't use fonts.
... my own position has been that if you use a font, in any format that cannot easily be pulled out and reused.
... if you just have to do something, touch font to reuse, then that takes responsibiliy away from publisher
... requires a willful act from the third party, so they are the infringer.
... that infringer is in violation of IP laws.
... the people who do this are not likely to be our customers.
... they are usually isolated acts which don't affect business in general.
... this is MT position, but not whole industry.
... obfuscating is enough
... so publishers doing something like this satisfies licensing requirements
Ivan: is this what WOFF was for?
Vlad: we didn't want to deal with licensing when creating WOFF format.
<dauwhe_> ... satisfies many requirements. Transparent mech. for fonts in the web, can't be immediately used by other
<dauwhe_> ... applications. No technical burden getting font out of WOFF format, but that makes infringement willful.
<dauwhe_> Vlad: In group we've agreed that's enough
<dauwhe_> ... WOFF has metadata on how to aquire font license
<dauwhe_> ... there's a secondary mechanism to put some boundaries on what type of content can be used
<dauwhe_> ... that access control mech. is universal
<dauwhe_> ... if it's normal web architecture, people ask questions
<dauwhe_> ... is situation the same for offline/packaged use?
<dauwhe_> ... most questions coming from publishers.
<dauwhe_> ... they are often at a loss whether they can use fonts without violating license.
<dauwhe_> ... so that's one big bucket.
<dauwhe_> ... this is a problem of educating users.
<dauwhe_> mgylling: can w3c or OWP help?
<dauwhe_> Vlad: make some document to refer to. EPUB has font obsfucation, to create strong tie between document and font resource
<dauwhe_> ... web doesn't have that. OK with dynamic content
<dauwhe_> Ivan: that's not a technical issue, but a usage issue
<dauwhe_> mgylling: OWP platform does not create a strong tie between font and document for
<dauwhe_> Ivan: that tie does exist. Do you want inverse?
<dauwhe_> Vlad: CSS gives mechanism to reference font. Doesn't say you can use that resource for ONLY that doc.
<dauwhe_> ... EPUB uses CSS declaration, but you also have font obsfucation that modifies font header with doc-specific key
<dauwhe_> ... so if you pull that font out of one epub and move to another it won't work.
<dauwhe_> ... that mechanism isn't clear to lots of publishers.
<dauwhe_> ... that removes you from license violation.
<dauwhe_> ... WOFF doesn't modify font.
<dauwhe_> ... is useable everywhere.
<dauwhe_> ... but WOFF gives you metadata saying font was licensed to publisher Y
<dauwhe_> ... at least it gives enough information for anyone to use that font legally.
<dauwhe_> ... also provides enough information to prevent anyone from claiming ignorance.
<dauwhe_> ... tryed to prevent unwilling infringement.
<dauwhe_> ... example: TTF font on server, can easily download, could claim you didn't know that was illegal.
<dauwhe_> ... WOFF is different.
<dauwhe_> ... can't claim you're innocent bystander.
<dauwhe_> Ivan: that mechanism exists today, the WOFF metadata
<dauwhe_> ... what is missing?
<dauwhe_> Vlad: Monotype says that WOFF file is embedded in digital publishing resource, portable offline document, that's good enough for me.
<dauwhe_> ... but people/publishers don't think that's the case, are afraid of becoming liable.
<dauwhe_> mgylling: OWP does not need a font obsfucation mechanism.
<dauwhe_> Vlad: we need more people be aware of issue.
<dauwhe_> ... so we can agree embedding WOFF resource is OK. Is good enough.
<dauwhe_> gcapiel: is there a machine-readable way to know if license is OK?
<dauwhe_> brady_duga: WOFF is restricted by origin? I'm confused about--if I figure out how to reference the same file from the original origin
<dauwhe_> ... if I sell that book is that a problem? Origin is the same.
<dauwhe_> Vlad: issue of origin is non-issue with offline content.
<dauwhe_> ... once file is offline, http doesn't apply.
<dauwhe_> ... don't see how that mech. can work for offline.
<dauwhe_> Ivan: from IG point of view, this is a non-issue.
<dauwhe_> Vlad: I agree.
<dauwhe_> ... users need clear guidance.
<dauwhe_> Ivan: IDPF developed technology.
<dauwhe_> ... IPDF should make it clear that obsfucation is not necessary for WOFF in EPUB
<dauwhe_> brady_duga: is this harmful?
<dauwhe_> Ivan: from IG perspective it's not an issue.
<dauwhe_> brady_duga: you're right.
<dauwhe_> mgylling: not seeing new requirements here.
<dauwhe_> ... IDPF says that foundries need to communicate better with customers to clarify offline usage rights.
<dauwhe_> ... are we misunderstanding?
<dauwhe_> Vlad: Monotype doesn't see an issue here.
<dauwhe_> ... question is asked multiple times.
<dauwhe_> ... not explained anywhere.
<dauwhe_> ... is it our job to explain?
<dauwhe_> ... do we need overview to reference?
<dauwhe_> Ivan: if I look at the IG charter:
Vlad: these are W3C technologys
important to publishing industry
... when we talk about digital publishing technologies are we online or offline
mgylling: scope of this group is
... cover needs of digital publishing both online and offline
Vlad: confusing part is diff.
between EPUB w/ two types of font resource and obsfucation can
work, but online only WOFF works
... needs to be better explained
mgylling: have OWP support obsfucation of non-WOFF fonts.
Vlad: if we agree to that,
... other choice is to only use WOFF
mgylling: what are the stats?
Vlad: on web, nearly everything
... we serve WOFF to every user agent that supports WOFF.
... next issue; not only about spec, but about what implementions actually do
... in EPUB2, many implementations had optional obsfucation
... not all RS implement.
... that's a problem.
mgylling: coffee break.
... to summarize prev. session, the first of the two "Vladimir Buckets"
... no obvious requirements on OWP regarding rights expressions on fonts
... generalizing from Vlad's position, WOFF features are enough for both online and offline use
... no equivalent metadata expression
Vlad: explicitly express restrictions
mgylling: not a W3C issue, more an issue of Foundries and IDPF being more clear on distinctions.
Vlad: can we document that WOFF is required technology that is relevant to Digital Publishing (as part of charter)
RESOLUTION: DPUB will add WOFF to list of required technologies for Digital Publishing.
Vlad: complaining about
typography being not as good as print
... different tools and processes.
... they have full control of content that is printed
... reproduction part of digital pubishing is delegated to unknown user agent
... so publishers have little control of final result
... don't know what typographic features will be there
... there are many checkpoints between digital content and final presentation of that content
... until recently CSS Fonts was fluid document
... implementation a year ago is now different
... is now CR
... even though we now have spec, we don't necessarily have implementaions
... how can interest group facilitate uptake of spec
... do we need stronger set of requirements that it must be supported.
... not talking about math
... have text flowing around objects with formulas, etc.
... or don't have control over kerning or vertical positioning
... combine chinese and english in one sentence
Ivan: the kind of question I was
asking on half-space around punctuation
... each feature in isolation has a small impact
... but the aggregate distinguishes good typography from bad
koji: but these things aren't about fonts
Vlad: typography has lots of
... year ago, CSS3 font features... demo from then doesn't work now
astearns: question about things
aren't up to snuff on web platform. One of them was kerning.
Letter position in general?
... or adding kerning table to document
Vlad: not kerning table, talking about info in font
astearns: so it's the font data itself.
Vlad: sometimes that information
is not presented in the font. Sometimes it is in font but not
used by reading system.
... people see end result, but don't see where issue is.
... people just see that it's wrong
... important small things.
astearns: requireing browsers to
use kern data in the font is something that would go in CSS3
... if browsers are not doing enough, that's what we need to lock down in CSS spec.
Vlad: I was talking about capturing high-level requirements to then translate into CSS
koji: Are you talking feature stablilty?
Vlad: one issue is lack of support for already-specified features
Ivan: try to collect both
pagination features and typographic features
... it's more work
Vlad: I'm the messenger
... I collect these from companies like Dave's
... these are people who struggle to control fine details of presentation
mgylling: parts is implemenation problem. Are there also specification issues?
astearns: yes, there are spec
... control over glyph position in line box is insufficiently specified for publisher requirements.
... line grids
dauwhe: control over justification parameters
Ivan: some stuff may be pushed to CSS 4
astearns: CSS decided to punt on justification ranges, it's future work.
r12a: there are specific things
we need to address, but there are things in css already that
are not being implemented.
... so we need to talk to implementers.
Vlad: yes. we need test suite to
... by zeroing down on specific issues we may lose bigger picture
... we may not be ready to drill down at individual spec level
... we need higher level conversation first, not dive directly to glyph positioning
... CSS3 fonts defines support for font features.
... to support font features you need implementations supporting that part of spec
... and you need to enable authors to discover the same features.
... a whole another issue.
... tools need to expose these features
... there's a set of tools developed by Monotype; tool will tell you what font features are available
... if characters are CT, some fonts will have a swash for these, some won't.
... discovery tools are needed.
mgylling: not obvious yes or no
for us to develop requirements for authoring tools
... this opens a can of worms.
Ivan: let's try to keep to what
we agreed to do
... authoring tool world becomes a nightmare
dsinger: will this put into the
CSS the fact that I want "CT" replaced with ligature
... finding what fonts do is not a problem for this group
astearns: CSS font spec allows us
to turn on substitution for particular element,
... this span with those two characters.
... can do character by character
... if you get to fallback font that doesn't support the feature, that turning on of feature does nothing.
r12a: that's an example of what Vlad was talking about.
Vlad: the bigger issue is that we
want to reduce the difference between creation and
... sometimes implementation problem
... sometimes resource get subsituted.
... sometimes can't reuse print process for digital
... trying to bring bigger scope
mgylling: to enable faithful
representation down the line
... we need to break down to concrete atomic problems
Vlad: one bucket is discovery of
... don't know if in scope
mgylling: authoring tool feature requirements is out of scope
astearns: there are stages
... gathering requirements
... then turn to features
... then see if those features can be exposed to tools
mgylling: how to translate easy to discover font features
astearns: we have a step where we
consider tooling 'cause one chair writes tools
... the font feature that exposes OT features is not tool-friendly
... but even less author friendly
... tools will expose eventually, and authors will use tools
... because feature is too obstruse for normal authors
mgylling: to translate to
requirement for OWP
... fonts have mechanism where fonts declare their available features
... and make it easy for tool providers
koji: for CSS fonts case
... matter of timing
... css fonts is WD
... not implemented in browser
... spec was unstable, unsupported
... once CR PR then more likely browser suppported and then tool supported
... using features after PR solves most issues
... help specs move faster to rec track
astearns: that timing issue will
factor in to the toolability of this particular feature
... web platform doesn't have introspection into features available for a particular font yet
mgylling: what other features are
... what have you heard, VLad?
gcapiel: let's check in with MathJax folks
Vlad: missing technology on font
side for math support
... ISO has published a proposal for math layout technology
<ivan> Guest: Richard (r12a) Ishida, W3C
<r12a> scribenick: r12a
dave: we want concrete imperatives, atomic?
<astearns> dave mentions justification and line breaking controls, composing fractions
dave: hanging punctuation,
fractions (font typography related) - in the old days we made a
fraction font, it was so important
... kerning pair editing
... sometimes we put spans around two letters with special spacing
... typically manually editng the html - eg. with drop caps, and maybe 4-5 different types of spacing
ivan: sounds frightening
dave: but thats what needs to be done
koji: format like epub, most publishers allow user to change font...
vlad: i don't dave is advocating to do the way previously done - its just an example of how much work goes into miniscule adjustments
koji: is the goal of this document to describe what was done in printing or what we want
dave: describe best practices
astearns: good sense to describe current practise whether or not
vlad: don't want digital publishing to be a poor relative of printing
dave: especially with the exquisite fonts that are now produced
brady: careful work for drop caps with hand adjustment fails when the user changes font
koji: group needs a list of
requirements for other groups
... in the middle we have another list of what we want in digital publishing
dave: requirement that drop caps
don't clash should be solved
... it doesn't work well in browsers now, but it should
markus: where do we document these?
ivan: who will do the work? may
be too much to ask dave to write it
... could someone else help create the content
markus: kerning etc do not need the tutorial stuff around them, so we may be able to put these requirements on the wiki directly
vlad: we need to collect these requirements from various publishers - they will have slightly different requirements
markus: vlad would you be willing to collect these things on the wiki
vlad: i'm not sure I can do
... i hear of the problems, but i don't work with them
dave: we need to snag someone
from the community who are trying to solve these problems in
the comp houses
... we don't have many such w3c members
ivan: we're working on that
koji: i'm working on a spreadsheet in japan and asking publishers to fill in issues - 40% author issues, 30% implementation, 10% css
vlad: any other publishers?
vlad: even educational book publishers
markus: there are two things, we
all know we need experts, but someone also needs to coordinate
... would you be willing to collect and describe (rather than be the expert)
vlad: i'll try
markus: so you'll be the hub and get things moving
ivan: on the long term i think this may become a separate document
markus: eventually nothing will remain a wiki page
r12a: don't forget jlreq
dave: i'm concerned that it might be hard to disentangle things - typography affects page layout
Agreed: Vlad agrees to be coordinator to collect and marshall these requirements - try to bring in people from Aptara and Jouve to supply expertise
vlad: can we get input from people outside the w3c
vlad: success depends on input - we shouldn't limit to members
walkley: i chair Uk digital publishing association so i can get them involved
ivan mentions others
ADJOURNED for today
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/test/TEST/ Succeeded: s/markus/mgylling/ Succeeded: s/WG/IG/ Succeeded: s/Gerardo/gcapiel/g FAILED: s/wowos/widows/ Succeeded: s/locals/locales/ Succeeded: s/somethign/something/ Succeeded: s/Richard/r12a/ Succeeded: s/Ivan:/Vlad:/ Succeeded: s/overveiw/overview/ Succeeded: s/blackmail/market pressures/ Succeeded: s/Ivan/Vlad/ Succeeded: s/positoin/position/ Succeeded: s/Ivan/Vlad/ Succeeded: s/restrospection/introspection into features available for a particular font/ Found Scribe: Vlad Inferring ScribeNick: Vlad Found Scribe: ivan Inferring ScribeNick: ivan Found Scribe: dauwhe Inferring ScribeNick: dauwhe Found ScribeNick: r12a Scribes: Vlad, ivan, dauwhe ScribeNicks: r12a, Vlad, ivan, dauwhe WARNING: Replacing list of attendees. Old list: Songshan Ralph New list: +1.917.447.aaaa Default Present: Songshan, +1.917.447.aaaa, benjaminsko Present: Songshan +1.917.447.aaaa benjaminsko Manu_Sporny Agenda: http://www.w3.org/dpub/IG/wiki/TPAC-F2F Got date from IRC log name: 11 Nov 2013 Guessing minutes URL: http://www.w3.org/2013/11/11-dpub-minutes.html People with action items:[End of scribe.perl diagnostic output]