See also: IRC log
<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
<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
...
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
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"/>
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]