W3C

Publishing and the Open Web Platform - day 2

17 Sep 2013

Agenda

See also: IRC log

Attendees

Chair
Liam Quin, Peter Linss
Scribe
fjh, glazou, fantasai, newt, others

Contents


intro

<fsasaki> liam introduces the 2nd day

phil madans nd dave cramer presentation, trade publishing

culture and workflo

phil during career introducing more technology, bridging technology and business, promoting standards

see slides regarding Hachette Book Group

<inserted> following from phil

did cd-roms and now solely using epub2 as ebook format

when part of Time Inc using XML

shifted from Quark to XML for workflow, books and descriptions

at end of process

wanted XML first

moved earlier but not first

goal to transition from print centric to content centric work flow with high quality for all formats, including print

60-70% revenue comes from print, so do not want to neglect print

using a tool ???

another goal was to move from chaos to standardization related to outsourcing

got some files back from compsitors that was in Quark with no style sheets, merged content and presentation

the books looked good but were concerned once looking at details

shift to Docbook

uniform instructions for various parties, looking for uniformity, move to templates versus 1 of

james paterson books have same style, look and feel, so wanted templates for such

moved from outsourced to in house

in 2005 thought about going digital, using Word track-change, new approach for copy-editing

problems - authors could not figure this out, also various incompatible versions of Word

evolution of comfort with technology with authors etc

success! now cannot get people off of Word track-changes

so now the question is now, why change since people now comfortable with this?

trade publishing has tight schedule, announce books in Sept for April publication, yet manuscript not even written yet, creating a tight publication schedule

tried again in 2009, documented detailed workflow, evaluated workflow time, 4 weeks for novel, 20 Fed-EX transitions

lose a day or two on each shipment, risk of loss etc

proofreading stage - output pages in PDF - those pages are printed, mark up corrections on paper, production editor has to correlate author/editor changes

then need to proof the proof changes

need tool to allow markup and avoid re-key of correction proof edits

thus PDF annotations can work but still require re-key

key offering of publisher is quality, benefit to author

production editor - biography of musical icon, manual typewritten, cut outs from magazine pasted, mimeograph - like reading 300 page ransom note

publishing includes manufacturing and distribution but really relationship business, buy books in advance, relationship with author, PR etc

arguments re space around em dash, type of space, at some point ask if it matters, will reader notice?

continuum of such decisions, if ignore some details, then start ignoring even more details

<fil> HoTMetaL

it would have been easier to go straight from typesetting to HTML CSS rather than via desktop publishing, couldn't change fonts after typesetting

every change used to be expensive, yet with desktop publishing changes became cheap, now more cycles

but with CSS going back to having changes being harder again, yet now used to much change

Dave speaks now

dave cramer

typeset books using HTML+CSS (PrinceXML)

slides examples of complicated books with complex layouts

novels contain new content - text messages, screen plays, fake magazine artilce

handwriting font used by murderer - but justified?

everyone aways wants more and new fonts, hard to organize

<fil> Fuck You David Foster Wallace (http://www.infinitydayweekend.com/2009/01/29/david-foster-wallace/ )

CSS issue - font weight ultimate sumu?

corrections made with pencil and paper making it more difficult, word breaking can become an issue, not enough control over hyphenations

wysiwig + outsourcing has taught people that changes are easy and isolate them from the consequences

cycles of corrections - enlarge, reduce, enlarge

in date in text, changed for '1' the font, separate from others

number 1 lesson - every book unique, always a surprise

CSS - slide of CSS properties including a number of extension properties

can do CSS generation using python to parameterize etc

prince-page-group allow each chapter to have formatting at start

work includes issues of details like using ellipsis versus periods with spaces, different for print and ebooks

punctuation is a major effort to get the details right

open type font features are critical - use all kinds of special features for the details

running heads are hard to do

slide shows some detailed CSS to accomplish this

can get tricky if running chapters together, managing head on top of page

many editions of same book - large print, hardcover, paper, ebooks, international etc

thus need for conditional text includes

predefine class attributes, XSL to filter

thus need for XHTML

PDF not enough, needs to be acceptable to printer, need slug, markings, using margin box CSS

why is math so hard?

:)

line breaks a common issue

control thereof

end presentation

bill Kasdorf apex: 3 Q, these difficulties were always difficult

dave: ???

bill Kasdorf: need to understand what professional typesetters do, they've solved pagination, line breaks, hyphenation

scribe: ... w3 interest group is collecting use cases
... need to be clear what is needed that is not in CSS
... be careful with term authoring, traditional publishing is different than colloquial of creating ebook, end product, considered production in traditional
... much easer to deal with if we leave Malcolm Gladwell out of the picture :)

daniel glazman: all CSS extensions need to be submitted to CSS WG

scribe: long time since proposed, 13 years ago
... problem is that the extensions are under-specified when submitted, need more detail
... hard since they are being deployed yet not well specified
... the CSS WG cares about this but needs to achieve interoperability and adoption

adam wentworth: antennahouse extensions, surmising looks like they created table for XSL-FO to see what from that can be added to CSS

scribe: who writes the CSS stylesheets

dave: have a group of full time production designers, take marked up version and implement final version, including updates to CSS default
... goal includes competence in CSS, ability to use same CSS for print and epub, so doing this for print helps with ebooks

liam: they are migrating from XSL-FO, they are adding to CSS features from XSL-FO as customers need them

Kathy fletcher: will issus with print typography go away with migration to digital, or other way

dave: would love to have these problems in digital, see digital quality improve

Eric Aubourg: need expressiveness in CSS and fix faulty rendering engines

scribe: workflow question, paragraph is interspacing by 5%, do you do this and how

<glazou> in other terms, where are Google, Microsoft, Mozilla and Opera in the room?

dave: to solve common paging problems will add word spacing etc

liam: line breaking fix via TeX was not so good
... underfill hbox is example
... not as easy as we might think, still ongoing research

???: PrinceXML implementing javascript?

dave: underway

???: headless browsers vs prince route?

fantasai: not there yet

<Karen> Pierre Thierry

thierry: issue is dual usages, source for human reading, also for technical workfow
... need CSS extension with more power but less friendly

dave: want both, user friendly and power
... CSS so much easier to work with than XSL-FO, so don't want to go back to lack of usability

what is a book

<glazou> RRSAgent: generate minutes

liam: introduction are we doing what happened with automobiles, originally put wooden horse on front to make people comfortable (on cover of o'reilly book)

ed: introduction of what is a book with slides (see slides)
... often conveying information in different media, convergence on web with site including text video etc
... now focus on content not media

fjh: I guess the medium is no longer the message

ed: convergence to digital , focus on what the content is
... Open Web Platform (OWP) driving this
... same tools, same distribution channels
... so what makes book different from others: self-contained, stand-alone, versus web interconnectivity
... can link to web site from ebook, can link within book, but how to link to a referenced book?
... second - can read offline, without data connection, anywhere
... offline important use case
... AppCache (mentioned again)
... collaboration needed for getting offline self-contained to work
... web outlook different - not the main perspective toward pagination, offline etc

ivan: another difference, typically web site is relatively small, a few pages, can understand site in one bit; book can be very large
... readers help with reading a book, e.g. bookmarking into center of text

ed: cycle, browser optimized for short form, chicken and the egg here

robin berjon: browser vendors need to pay more attention to users, e.g. look at the HTML5 specification, it is long, 700 pages

ed: browser vendors use it to test page load time, but not usabilty

daniel glazman: rendering engine implementer not browser vendors

ed agreed::

Luc Audrain: remember that a book page is not the same thing as a web page

karen myers: storytelling and rich multimedia - bringing newspaper to life in film scene - how about watching video in an ebook?

scribe: is a book with multimedia still a book?
... if interactive is it a book?

liam: getting a cd-rom with a book when the cd-rom is not self-contained, a link printed in the book would be still as good
... early ebook was a book with added multimedia which was ignored or a live application but web better for this with links

todd carpenter: is convergence simply result of trying to use same tools with community of web designers with similar experience so with more time might diverge

scribe: also push back on lack of being well specified, note MathML is not implemented but well-specified

daniel glazman: concerns have changed over time related to web, now concerned about books, TV, mobile etc

scribe: before we saw emergence now at the beginning

Case from ibook: definition of what is a book is changing based on features desired by customers. not based on tools. about the media

scribe: text , media, video and frequency of delivery

scribe: can distinguish app from book via ???

Adam Hyde: need to think about user requirements and what they need

ed: remember those adventure boks with different endings

fjh: or Infocom?

ed: imagine can visit web site on mechanical engineering, with information, fill out query of interests, get dynamic ebook from site based on interests and needs

<stearns> choose-your-own-adventure books are in some ways still better in print. Can't flip back and forth through options as well in an ebook

liam: is wikipedia a book?
... publisher adds review process

nic gibson: idea of sequence is key, mentioned by a number of people now

scribe: you choose own sequence on the web, ebook has sequence

ed: news has soft sequence, placement of main articles

Alain Pierrot: challenge self-contained,

scribe: ???

<Luc> Alain Pierrot is speaking

phil: need to keep reader in mind. Novel is different from text book. Novel is self contained what to forget what the medium is.
... whether ebook or print

<Karen> Pierre Thierrry

<stearns> part of Alain's point is that sequence isn't an essential characteristic of a book. reference books are read non-sequentially. that's why indices and TOCs exist

<Karen> Pierre Thierry

pierre thierry: semantic web should allow many layers or reviewing on the web

scribe: need to be open to new ideas of what a book is

liam: nervous when hearing that technology will solve a social problem
... originally had rel= agree and disagree but in fact solved no problem - identity and authority not addressed

julie morris: are readers looking for a different way to read books with digital books or is it the same act and need

scribe: thinking about what we add to ebooks, media, is it a different experience

ivan: a gradual process of evolution is not yet clear
... some features were not available in print, convenience of built in dictionary for example
... should not expect rapid change of books

daniel glazman: hard to buy books from other countries on web sites

scribe: don't ask users about future technology, cannot answer

<Karen> +1

fjh: raphael:Gallardo: a book is not aways a novel
...

Guided discussion CSS formatting

Liam introduces the topic: guided discussion of CSS formatting

Liam: Topic is various things that make it difficult or impossible to use the web platform for books

Liam holds up a fancy red book he declares to be "out-of-scope".

Liam: Initial caps, engravings

Liam: Typography had become mechanized, less careful about that

Liam: I love such books, but that's not the point. Point is to be grounded in the practical.

Liam: Not interesting to reproduce this book exactly.

Liam: But it's about taking technology and process, and creating something beautiful out of it.

Liam: CSS for babies: premise is CSS is easy, does everything you need.

Liam: But as we saw, many extensions

Liam: When we talk about CSS, talking about stable CSS modules from CSSWG

Liam: Not about things vaguely CSS-like, but that's not CSS.

Liam: One more remark. Who's been to McDo?

Liam: When I first went to Rome, was so suprised to see it that I went in.

Liam: Was said that when McDo was designing their restaurants, they had a problem.

Liam: They would come in, have their food, stay for a couple hours, have wine, and then go away.

Liam: Doesn't work very well for their business model.

Liam: So they made the chairs hard, so too uncomfortable to stay for very long.

<stearns> liam is describing the venue prep for this workshop?

Liam: Typography is like that. If you read a book with bad typography, e.g. inconsistent letter-spacing, it becomes uncomfortable.

Liam: After 20min, you put it down and go do something else.

Liam: Idea that typography for comfortable reading should be unnoticeable.

Liam: I don't want us to get into details of how much to kern W

Liam: Let's talk instead, imagine, that we are improving the typography of the details, but question is how do we get that info

Liam: What are problems for publishers practically using CSS technology.

Liam: How do we get that feedback back to the CSSWG that's specific enough to act on, but also handles all languages and can be put into all products.

<Karen> Fantasai introduces self

Liam: In all W3C specs, there's a Status section. Really boring. Have a coffee first. But it tells you where to send comments.

fantasai: Our specs put feedback link to the top as well

Liam: W3C WGs must address all comments, no matter who sent them.

Liam: If you're not in the WG, don't get to say *how* the comment is addressed, but must address them.

Liam: Can say, we're not going to solve that. You can go back and explain why it's important and what the use cases are.

Liam: WG will generally agree to solve problems that are commonly encounter. Might not agree to solve it now, might agree to solve it later.

Liam: ... discuss various solutions.

Liam: Might take a few months; WG gets lots of comments. But should get to it eventually.

Alan: wrt vendor extensions...

Alan: Several classes of extensions.

Alan: Much more important to get things into CSS than to leave them in specific implementation, like PrinceXML.

Alan: Prince's extensions are great for their workflow, but locked into their impl

Alan: Another type of extension, can agree on an extension that can be implemented via JS. Can be important for certain industries.

Bill: Suggestion that we use these vendor extensions as input... not suggesting that we need to do favors to vendors. Using that as an example of evidence for need of functionality that is missing.

Bill: How that gets addressed is whole separate issue.

Alan: important to get it addressed, but making something interoperable doesn't *require* convincing the CSSWG to put it in a spec

Bill: Don't want to make something that only works in Prince.

Bill: My main concern is issue of alignment with Print

Bill: 2 aspects to that, one deserves our focus, other not.

Bill: Alignment with print, needing to know where page breaks are for a11y in a reflowable book.

Bill: That's not something about doing the way print does, but serving user's needs.

Bill: Other is "look like print". Not sufficient in my mind.

Bill: Needs to accomplish the same things

Bill: But making it look the same, not so much.

Liam: Unless you're trying to format for print

Bill: Yes, that's a separate issue.

Adam Wanting to create print vs. look like print

adam: Consideration on which one has the priority

Adam: Personally I'm very much of the position that browser can create beautiful rendering for print

Adam: Rendering to paper, seems odd to me to leave that out of the equation.

Bill: 2 examples

Bill: hyphenation. In trade print world, want pages to look good, want pages to have even color

Bill: In a digital book, when a reading system can't break a word, and there's a horrendously short line, it's a distraction to the reader. That's what the problem is.

Bill: Butting spaces around emdashes -- aesthetics there, but also allows to break there

Liam: So what I heard is a requirement to have breakable and nb thin spaces

Bill: Yes.

Bill: Digital environment needs to be inherently reflowable.

Bill: You're fixing the pages when you do print

Bill: For digital, you need to put the intelligence into the document, because can't futz with it later.

Liam talks about documenting cases like this, along with the use cases

??: ...

??: Numbering of paragraphs or notes, not a position of Unicode, hidden in InDesign

??: InDesign doesn't do a good job of that.

??: Have a lot of issues like this, if should control via CSS or control via some other rendering engine, or font

??: Another is direction of writing.

Alain: Defer to the font

Ivan: Unicode spec will give you info about words being written rtl

Ivan: However there are cases where this goes wrong

Ivan: E.g. british abbreviation inside Arabic text, exclamation mark somewhere, need some extra control. That's necessary.

Ivan: Things in Unicode, yes, but also need higher level controls.

Adam: Want to push back on reflowable vs. ?

Adam: They're much more similar

Adam: Need to be able to design for multiple page sizes.

Adam: Once they're flowed into that space, yes, static, but static books are still flowable objects

Ivan: More general quesiton

Ivan: Discussion yesterday and today, sounded like CSSWG has to solve all the miseries of this world, and once solved, everything will be fine.

Ivan: They can try to do that.

Ivan: But looking as outsider as whole production workflow we discussed yesterday.

Ivan: To me sounds like everything is perfect in the workflow, except for CSS bits

Ivan: ...

<bert_> liam: That is for another discussion. This session is CSS only.

Ivan: We do have mechanism, to have this process

Ivan: We have an interest group. Job of that interest group is gathering requirements, etc.

Ivan: These issues should be handled by Markus & WG

Ivan: Eventually get to CSSWG, where we get to nitty gritty details.

Ivan: What I want to find out is, are there other problems?

Liam: Let's step back. Clear that people have problems with formatting. Question isn't what are those issues, but how do we go about addressing them.

Liam: Part of this is joining WGs, other is following Interest Group

Liam: [refers to workflow diagram]

Liam: Who here has worked for publisher with workflow issues? Or any project with more than 100 steps, that's repeated? :)

Liam: Will come back to that this afternoon.

Liam: And get more concrete next steps, creating mailing list or whatever

???: Initial pilots works very well, but starting to hit limits of what it provides.

Adam: CSS is about functionality

???: I would say, 80-90% of my issues are not print-specific. General typographic issues

It's a different Adam, then...

<Karen> Adam Witwer, O'Reilly

<stearns> first Adam is Adam Hyde, second Adam is Adam Witwer

Pierre: Extensions, need to be specified in a way such that browsers can implement it.

Pierre: But there are things that no browser will ever need or want.

Pierre: We want a set of extensions that we can will mandate to browsers. If we restrict to those that fit the browsers, might refuse extensions needed in print world.

plinss: Want to address that.

plinss: Sometimes when these extensions get rejected, it's because in CSS try to solve with a different model than what you deal with in print world.

plinss: In print world, laying out with specific text to specific sizes

plinss: In CSS, it's reflowable.

plinss: Many of these extensions are for tweaking things. We don't do that in CSS.

plinss: We don't know the paper size, or font size in CSS.

plinss: Have to be able to describe document in declarative model so that rendering engine can do its best to get it right.

plinss: Instead of tweaks, want to describe in a generic way the problem. Not describe result.

plinss: If we talk about things in that abstract way, then more likely to spec and implement.

plinss: Because then the solution applies everywhere.

plinss: Instead of saying "I want these line breaks", say want even color, and have browser figure it out.

plinss: That's what we're trying to achieve with CSS.

...

Gerry: Problems with typefaces. Hard to get right

Gerry: Nobody either form MS Typography or Adobe Type Group

Gerry: Major flux because of web fonts

Gerry: New tech that puts fonts in the cloud

Gerry: To make type world ... to people that use the type

Gerry: ...

Gerry: What's needed, e.g. for Regions ppl, for Location feature in OpenType, or ? in documents

Gerry: ppl specifying different dashes in OpenType,

Gerry: This dialog doesn't happen

Gerry: Need a workshop like this, inviting type people

Gerry: ... meaningful in CSS

Gerry: Regardless need to have type faces

Gerry: elephant in room is Monotype, pushing cloud-based font solutions, should be here

Ivan: They are in the IG

Liam talks about liaison among WGs, IGs, and industry

Gerry: Start by getting people to have drinks together.

Alain: I'd like to come back on expectations that print publishers can expect form CSS.

Alain: It's about control, and obtaining best layout, but it's about control.

Alain: Web is much more reader-oriented

Alain: One useful evolution would be for publisher to indicate limits within which engine can conform to author intent

Alain: When reader is non-conformant, still get some of the content, but indicate that it's not conformant

Alain: Reader, user, has much more ability to appropriate initial work, re-use it, trace the intents, know when he is respecting the meaning/layout of initial publisher and when not.

Liam: Remember when I first introduced Web to a print designer and told him user can pick his own fonts, e.g. always use Comic Sans

Dave: I would be happy to give up a lot of control over line breaking and justification if the result met the common standards that have evolved across history.

Dave: Don't *want* to tweak things. Would prefer not to tweak them.

Dave: I would like engine to break lines in a way that is beautiful and readable.

Dave: Issue of line breaking / hyphenation is great interest to all of us, print and digital

Dave: Wrt fonts, I as a publish may not have a good understanding of boundary between what is a [...]

Luc: I don't expect that HTML will solve so soon what we have solved in our publishing over many years

Luc: We are ok with current results that we are getting currently

in print

Luc: But we are not satisfied wrt ebooks

Luc: Very common problems, hyphenation, vertical justification, running headers, that are not solved currently

Luc: Want them solved

Liam gives example of handing a suggestion to WG, getting something else instead.

Liam: Must always be vigilant, can't just give a request and walk away.

Kathy: Is there a good place with really simple digital examples of the effectiveness of typography?

Kathy: I think end users see it, notice the difference, but developers might not notice how much easier it is to read something that is well-designed.

Kathy: Wold be great to have A/B examples

Liam: There's books, of course

??????: Does the developer need to understand and care about what they are creating? Or just creating the tools that were requested.

Gerry: To explain the complexities that typographer to the developer suggests that typographic knowledge is simple and can be compressed in easily digested form by non-specialist

Gerry: ...

Gerry: Why would ppl spend so much time on a book.

Gerry: Have to be careful, otherwise have simplistic view of typography

Gerry: Knuth studied old works, and worked with Zapf. If worked with someone else, results would be very different.

Ted: Richard Rudder put an interpretation of Bringhursts' Elements of Typographic Style for the Web

Liam: Unfortunately, somewhat incomplete...

Liam: But very nice

Cristina: Typographic knowledge is not in the publishing house, but is given to publisher by external supplier, e.g. grpahic designer.

Cristina: Value chain, not just single person in production

Cristina: Ppl think publishers know everything. Not true.

Cristina: These kinds of problems not managed, except in wide general

Cristina: If you deciding fonts for a book, it's not publisher

Gerry: But somebody, some expert, knows

Kathy: I think that there are two things at tension here.

<stearns> there are risks in compartmentalizing expertise as well - the developer needs to know *something* about what they are implementing

Kathy: Having something that gives wider audience an appreciation for this is not the same as having somebody else be able to do it.

Kathy: Also, want newer generations to understand effectiveness of all the little details that we care about

Kathy: Not asking for Typography for Dummies

Liam: Lots of research on effect of typography on readability, but [[...]]

plinss: Hard to read it, too.

Dave: I don't expect perfection from tools, but think we can do better than today.

<Karen> Fantasai: I want to respond to the developer not needing to know what they are doing

<Karen> ...it's not just about knowing the tool

<Karen> ....they need to understand and be motivated to do

<Karen> ...they need to understand the essence of what they are trying to accomplish

<Karen> ...you get requirements...then it's a weird collection of stuff

<Karen> ...and is not as effective or elegant as it could have been if they had known the restrictions or other elements from the start

<Karen> ...similar challenge across other industries besides design like engineering and architecture

<Karen> ...get architects and engineers in the same room and they reflect off each other

<Karen> IM Pei worked with an engineer to get better solutions

Gerry: ...

Pierre: I don't know enough about typography, but sciences and crafts where it's been shown where if you don't have at least one person who is a real developer, real craftsman, you cannot succeed

Pierre: I would suspect the same for typography

Pierre: All developers don't need to understand and know typography, but will need at least a few who are almost typographers. If we don't have this bridge, probably will fail.

Liam: Had wide-ranging discussion about formatting and issues.

Liam: Go and have lunch, and when we come back, will talk more about how to address problems.

Liam: Think over lunch, how would you go about explaining to developers, that allowing fixed string in headers is not enough for a mathematical journal

Liam: What relations can we set up among typographers, toollmakers, publishers, etc. ?

Liam: Education needed in both directions.

Break for lunch

Barriers preventing us to use web standards for ebooks

Topic "what are the barriers preventing us to use web standards for ebooks"

liam: we do have problems otherwise you would not be here

... question is what are the barriers and what can we do about it

Casey: what's the proper way to do this?

... go through what IDPF and EPUB have done? Starting point?

... Markus what do you think?

Liam: in scope? yes.

... what you look for is a strategy to move forward

... what's happening in the IG

Markus Gylling: to a full extent, what's happening in IG

... describe repertoire of needs and wants for the OWP

... every time IDPF has to invent something, it means OWP lacks something for us

... Dave Cramer going to lead some activity in the IG for declarative pagination

... major effort of the IG

... including differences in locale and culture

glazou_: what means declarative pagination?

Markus: all what is needed to to pagination in the browser ; input for CSS WG

... and write specs that meet use requirements

Ivan: if we decide to concentrate on what IDPF doing, will lead to EPUB-only area

... let's move to higher level, not only ebooks but broader issues for everyone

Bill: problem is to get them online

... two paradigms: fixed width and browser

... need to specify behaviour in pages

... screen real estate issues, we use a lot of Media Queries

... addressing the page metaphor

Liam: prit publishers need to be aware of responsive design?

Bill: need to specify specific break points

Liam: lemme ask a question

... clear to me that part of your problems in life caused by outreach from us incomplete

... training courses would be useful?

... hearing yesses

Bill: that's an aspect yes

... publishers aren't exploiting the features already there

Ivan: it is part of IG charter to produce a doc/view of W3C components we feel are relevant to publishing industry

... has to be some sort of channel between us

... only doable if enough people in IG

... targeted events, something we can organize

... one more action that came up yesterday in discussions: interactive books imply border between web and books become blurry

... on another hand, developing webapps and intercative ebooks require a lot of specific knowledge, JS, etc.

... creating a bridge between pub community and webapps community would match both interests

<karen> Pierre Thierry

Pierre Thierry: about MQ, one of the problems is the basic CSS model

... one document and many stylesheets

... with mobile the web is failing

... one markup/style for desktop and different for web

... same for publishing?

Liam: STTS do help

... specify transformations in your markup

... Blink has taken away XSLT

... changing markup on the fly

... people are using xhtml to use the xml toolkit

.. transform your markup from one common basis

... reorder content

...XSLT is a way how people are doing that today

... does not always work on mobile so do it server-side

Vlad Stirbu (Nokia): bringing together developers is exactly why we are there

... use libraries

... creating books for multiple devices and responsive web design is involved there

... IDPF Workshop

Massimiliano: we deliver content to web and mobile and now ebook

... we use transformations

... not affordable to have different representations and styles

... we need to separate content and preso

... matter of cost

... we can't afford to have a lot of content

Liam: people have said we need requirements

... but also it's hard to translate requirements into a spec

... have to have the right persons talking together

... sync is needed

... difficulty is that work is done by volunteers

... problem of workforce

... would you be willing to donate someone's time to do spec writing and editing and turn requirements into a spec?

... we need manpower

Adam Hyde, Booksprints: does it work to have longer workshops to do spec writing?

<karen> Daniel: To do spec writing, you need the editors and contributors in same room

<karen> ...that makes a lot of people to gather

<karen> ...our schedules are quite busy

<karen> ...having a longer session would be quite difficult

<karen> Adam: would it work if we could?

<karen> Daniel: we already have the working groups and interest groups

<karen> ...it would help to give direct input to the right people

<karen> ...not sure it would help to write specs

<karen> ...you have one contributor here

<karen> ...others not on web site

stearns: in the past we had 1 day of CSS meetings joint meetings with other WGs

<karen> Daniel: yes

... perhaps coordination with publishing during on of our scheduled meetings would help

Ivan: one issue often repeated is that one of the problems of the pub toolchain, there must be interaction between author and editor

... format conversion issues

... annotation issues

... clear that all solutions are absolutely wrong

... why is that?

... does the pub industry has so strong requirements they can't be included in the OWP?

... what are the features missing from OWP?

... pratical painpoint

Pierre Thierry: am a SW developer

... I wish I had a rich visualization of differences for software

... half-baked solutions

... anything we suggest and provide must meet 90% of paper technology

Liam: budget is not enough (metaphor)

... narrow bridge for 3/4 of the original traffic?

... or larger but 3/4 of the ravine ?-)

... need both worlds

Dave Cramer: seems to be two things

... formatting issues

... hugely important

... cannot do it to online because we need to see EXACTLY what will be printed as final output

... PDF output in browser would increase quality

<karen> Alan: improvements in rendering content, not PDF

stearns and davecramer fighting

<karen> Alan: step back before PDF

<karen> Daniel: Given the question

<karen> ...what are the barriers

<karen> ...I want to come back to the roots of the problems

<karen> ...are not technical

<karen> ....I think

<karen> ...the roots of the problem I think are time and strategy

<karen> ...IDPF wanted to release ePub as quickly as possible

<karen> ...and could not wait for us to standardize

<karen> ...question of time to market on both sides

<karen> We will not solve technical questions until we address time to market

<karen> ...question of strategy

<karen> ...when a technology using OPW is built

<karen> ...can it wait until we finish the standardization process

<karen> Ivan: my original question is, is it a matter of some technical features missing in OWP that makes it difficult or impossible in the reviewing process

<karen> ...if they are identified, then we can work on that just as we identify CSS features

<karen> Daniel: If we don't resolve time to market discrepancies on both sides, we will miss the opportunity to solve again in the future

Luc Audrain: I think that is missing in OWP upstream is better separation tools for authoring

... semantic content on author's side

... structure captured at authoring level

... word processors don't do that

... love to find an authoring tool for that

... I think the OWP can bring us these tools

Liam: easy authoring is the holy grail of sgml and xml people

Luc: cascading is like structure

Adam: one thing is the ability to track the revisions of a document

<Dave_Cramer> authoring tools are less useful if there are not proofreading and revision tools

Liam: there's a Community Group about that

<karen> Hajar Ghaem Sigarachian

Hajar: we should also consider interactivity and JS

... don't worry too much about printing

... just for the future

Bill: going back to Ivan's issue

<Luc> Dave: good point, needed too

... two aspects

Luc, Dave_Cramer please use /me otherwise disrupts minutes

Bill: aspect of correction of things

... authors make changes

... certain classes of publication are layout-driven

... content secondary compared to presentation

... seee realtime the effects of changes of corrections

... dynamic interaction between change tracking and rendering

Ivan: the way I could see this thing

... a. clealy important browsers have full understanding of all you need, technically wise

... in that case, no need for pdf viewer

... b. annotations, changes tracking

... that requires some sort of browser storage

... are the specs existing today good enough for that?

... just asking, naive question?

... can we identify a range inside a document?

... IDPF has to go through media fragments

... enough for your other needs? We don't know and have to know

... SW implies money, we won't pay for it

... but what are the missing bits?

Adam: local storage is not enough IMO

... kind of a gray area here

... discussion about what JS is already doing

Pierre Thierry: about change tracking, storing the changes is complicated

... the way you store changes is not satisfactory ; we store the versions

... the tool is reponsible for rendering the diff

... yes

<karen> Daniel: we started tracking

<karen> ...to change tracking in mark-up languages

<karen> ...we concluded it's impossible to do post-schema; you need attributes

<karen> ...Microsoft did same study and came to same conclusion

<karen> ...MS change tracking is so widely used, we should develop a substitute

<karen> ...they are world leaders

<karen> ...why don't we ask them

<karen> ....When I ask them

<karen> ...they reply 'show us the metrics and the proofs'

<karen> ...Microsoft has tried to show it 10-15 years ago; they don't want to do it any more; we did not listen; your problem

<karen> ...One of major issues with change tracking is not technical

<karen> ...it is well known in @ community

<karen> ...we decided not to listen to them 15 years ago

<karen> ...the process is missing metrics and proofs

<karen> Liam: you have made a good and clear point

<karen> ...we should have a break now

<break type="coffee"/>

Wrap-up session

Liam - Intro to final session

[liam shows summary points]

liam - my interpretation of outcomes of discussions, issues that are barriers to publishers

or where work can be done to reduce barriers

we need to turn that to a set of work activities

liam - publishing interest group is creating task force

markus - topic of the taskforce is "to describe the digital publishing communities requirements and uses cases for pagination"

planning to spend time at 1st f2f working on pagination w CSS group.

[half know about the JL Rec doc]

plan to create an equivalent document with the detailed descriptions of issues for pagination

ivan - parallel to that the css working group has discussed creation of a group to concentrate on same issues

ivan - already had ideas for other taskforces - this just one.

markus - interest group is focussing on topics of interest to members

markus - other topics include annotations & social reading (already have initial requirements), accessibility & useability (focussing on how web accessibility translates to digital publishing - differences with print disabled?)

markus - interactivity (not just education sector but also childrens' books - huge interest in use of interactivity).

markus - smaller pub houses can't do this easily - need to be able to share libraries - move to declarative approach desirable

markus - looking to identifiy pragmatic approaches to this most from a workflow viewpoint

markus - also looking at metadata - not sure how ambitious - likely to create a separate group - huge area

liam - with respect to this group - paged media taskforce - only working on issues presented by those present. people here can join the IG (member only)

liam - also mentioned (and in css wg) having a mirroring taskforce - one is requirements, css wg does specs. Need resources to edit the specs.

pierre thierry - advice for training - do not teach publishers how to do markup, teach them to understand the basic models and how they fit. May fail if training is too deep

ivan - already have a task in IG to distill those features of the W3C output that are relevant to the publishing industry. May well need to emphasise the outreach and move out of the IG to create an outreach activity - to bring W3C tech to publishing world

ivan - W3C should try to make it easier for the publishing industry to find their way through the W3C maze

ivan - W3C doesn't yet know how to do the outreach

liam - list is just random notes

liam - several people using XML toolchains because HTML tools not suitable for some reason. XML role in OWP remains to be seen. XSLT in web browser is going away (gone from Blink). Talking about adding javascript hooks.

liam - who is using xslt in browser?

liam - we should look at the xml stack and see why people are using it and see if the functionality should be migrated to HTML

markus - using xslt & xproc is very common. these people are worried about xhtml serialisation and it's possible death. What is the future of the xhtml serialisation?

robin berjon - xhtml serialisation is not being killed. xhtml fully specified. there are issues with xhtml in conjunction with scripting that W3C cannot fix.

robin - do not use it for scripting or interaction

ivan - what about polyglot?

robin - polyglot is a document that describes authoring content that both xhtml dom and html dom are as close as possible. does not take into account scripting.

robin - constrains use of some things such as script as data

robin - polyglot has its uses, please provide feedback if you are using it

ivan - is it still an official doc

robin - still current, being updated. Not sure of the final status of the doc, might be a note or might be a rec.

ivan - publishing industry should look at this document and give feedback? Who can do that?

ed (apple) - great bedtime reading

liam - anyone can comment on specs; even to say that it was useful as then W3C knows it's being used

liam - one-day f2f with CSS and publishers and publishers IG

ivan - would be hard to get an extra f2f given economic realities

pierre thierry - the goal might be to get occassional meetings for some of the interested parties to create the dynamic (references the french bible development)

emily - are the enough publishers using CSS to contribute in the IG?

liam - who uses CSS in their org to do paged media and might go to a meeting ?

[two publishers respond]

todd - how many publishers are actually using this?

todd - there are more than two

emily - would be surprised if more than 10% of publishers (trade, education, etc)

ivan - many publishers outsource - do you mean directly or indirectly through others

bill - this is a very narrow statement - CSS for paged media only. Many more publishers are using CSS as part of their publishing?

liam - how many people would go to a meeting to discuss and meet with CSS specs people?

philip schatz - would go - there are more than two here!

luc audrain - we should delegate someone from our organisation, we need this for EPUB

liam - arranging this does not make it happen!

liam - the topic is worth revisiting but no definite outcome from this meeting

liam - final issue raised was revision tracking and formatting

liam - xml early and xml first, revision tracking is a major blocking issue

bill - at this stage formatting is not the issue

liam - page proofs are a separate issue

pierre thierry - we should experiment - find some funding and get someone or a group to create an interface and try things out - publishers can provide better testers

liam - in the web browser world, beta testers are users

nicolas (hachette) - structured authoring needs to be an issue

dave cramer - several related ideas - structured authoring, track changes, online proofing/marking - distinct portions of the idea

karen myers - what is pierre thierry asking for when he mentions funding?

pierre thierry - possible to plug this onto existing software (openOffice perhaps).

pierre thierry - possibly plugging into git; cheapest is git, then openOffice

<Dave_Cramer> \me there are existing online editors with track changes, but maybe are inadequate

bill - revision tracking doesn't need *final formatting*

jirka - open office change tracking is not sufficient - some features are missing (like tracking changes in tables)

adam hyde - strong believer in HTML first - up to offering development time to work with publishers to implement this

ivan - do not get carried away defining a software project

ivan - the question was "does the OWP today provide the required features"?

ivan - at the W3C theres is a community group system, lets set up a community group - have a year charter - the goal would be to answer the question - do we need to go back to the drawing board for major OWP elements to add the required features

ivan - the w3c doesn't solve the problem but creates the specs/requirements

robin - we can do this now with a name and scope

liam - before starting a group look at the Change Tracking Markup Community Group

pierre thierry - never create a spec with no implementation, if we know this is so important...

ivan - we are not creating a specification, we are asking the question - can we do this with the current specification?

ivan - the point is not to create a product at the end of the group

bill bras - one more possible topic - what is the relationship to research - academic research - how do we talk to researchers in this area?

bill - Document Engineering conference in Italy last week for example - revision tracking research, document querying, metadata, semi-automated layout

<fsasaki> conference doceng 2013 site is at http://www.doceng2013.org/

bill - talking to people about getting the results of their research

angelo - there is interest in the research community in these topics - research stops and meets implementation and specification at some point. research cannot provide implemations

angelo - there was a topic at DocEng on how to manage changes

angelo - researchers need to reach the other way as well as the W3C reaching towards them

liam - not many researchers here because of the time of year

ivan - is structured authoring a problem created by the current OWP standards or is it a lack of development?

adam hyde - people trying to solve problems and the tools are not adopted. not currently fluid enough and the W3C could help in this space

ivan - can the change tracking and structured authoring issues be handled via the same group?

luc - more about getting information about structure and semantics into authoring. Cannot say if it can be done with current OWP tools.

robin - there are precedents with this sort of issue.

robin - community groups should be on specific topics - the IG is for the general issues

liam - are there any topics/future work that can be done with people in the publishing/book/flyer/etc world?

emily - suggests including archivists into this conversation - solutions to metadata, change tracking, character encodings, etc. These are things on the periphery of modern publishing

liam - any more business?

liam - thank you

[applause!]

[End of minutes]