F2F Meeting, Shenzhen, 1st day -- 11 Nov 2013

<gcapiel> TEST

<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

Pagination

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 right
... 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> Events:

<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> DOM

<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> API

<mgylling> turn a page

<mgylling> go to a page

<dauwhe_> http://w3c.github.io/dpub-pagination/index.html

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)

s/wowos/widows/

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
... layout
... 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> DOMAINS

<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

Web payments

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

<manu> https://payswarm.com/intro

… it is not only getting money from A to B, but other things

<manu> https://payswarm.com/join

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

csswg summary

mgylling: atomic advice from discussion
... 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 data.
... 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 browsing.
... 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 gather evidence?
... asks Brady how they get data/priorities from publishers.

brady_duga: publisher-driven 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 telcom
... 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 the future.
... 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, yes.
... other choice is to only use WOFF

mgylling: what are the stats?

Vlad: on web, nearly everything is WOFF.
... 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.

Ivan: example?

Vlad: scientific publications
... 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 parts
... 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 text
... 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 issues.
... 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 help developers
... 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 rendering.
... 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 font features
... don't know if in scope

mgylling: authoring tool feature requirements is out of scope

astearns: there are stages involved.
... 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 needed?
... 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 this
... 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?

pearson

vlad: even educational book publishers

markus: there are two things, we all know we need experts, but someone also needs to coordinate the work
... 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

answer yes

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

- DRAFT -

F2F Meeting, Shenzhen, 1st day

11 Nov 2013

Attendees

Contents

Pagination

Web payments

csswg summary

Summary of Action Items

Scribe.perl diagnostic output