W3C


Informal Telco between CSS and EPUB experts

22 Mar 2013

See also: IRC log

Attendees

Present
Peter Linss, Daniel Glazman, Janina Sajka, Makoto-san, hober, Philippe le Hégaret, Markus Gylling, casey, Alan Stearns, Bert Bos, Brady Duga, Jeff Jaffe, Luc Audrain, Thierry Michel, Ivan Herman, fantasai, Richard Ishida, Takeshi Kanai, Liam Quin, Jim Dovey
Chair
Markus Gylling and Daniel Glazman
Scribe
fantasai

Contents



glazou: My name is Daniel Glazman. Am co-chair of CSSWG in W3C. Will be one co-chair for this telecon. Other is Markus Gylling

mgylling: I work in IDPF on Epub spec and also with DAISY consortium

glazou: Let's do intros

janina: Janina, will be fly on wall. Chair PF and will pay attention to a11y

hober: I'm Ted from WebKit team at Apple, a CSSWG rep, also participate on IDPF side with some colleagues from iBooks

<liam> Liam Quin

liam: Liam Quin, with W3C. Background is in XML and digital typography

Ivan Herman: Also W3C, sort of leader of digital publishing effort

<plh> plh: Philippe Le Hegaret, W3C.

plinss: Peter Linss, other CSSWG co-chair

plh: [...]

<glazou> Luc Audrain

Luc: Work [...] XML, HTML, etc. Supposed to digitalize their (?) content
... metadata and digital formats in IDPF. Metadata with editorX, EPUB3 with IDPF

stearns: Alan Stearns, CSSWG rep from Adobe

<duga> Brady Duga, /wave

duga: Longtime EPUB person

<jeff> jeff: Jeff Jaffe, W3C

jjaffe: CEO W3C, here for high-level questions, otherwise mostly fly on wall

takeshi: Working in Ebook area for more than 10 years

makoto: Longtime ago was member of original XMLWG, but now participate in IDPF. Leader of EGLS (i18n-focus) of IDPF, also co-chair of Advanced Layouts subgrou of EPUBWG

fantasai: CSSWG, write a lot of specs, also worked in testing and little bit of browser implementation, ~13yrs

<r12a> Richard Ishida

<tmichel> Thierry MICHEL W3C Team contact

r12a: i18nwg

Thierry: Working in various WGs, working recently on digital publishing effort with Ivan

<inserted> Bert: Bert Bos, W3C Staff Contact for CSSWG

glazou: Bert said his comp crashed, he'll be back asap
... We decided to have this discussion after workshop on electronic books ~1mo ago
... Goal of this call is to identify the areas of CSS that need a better focus from the W3C to help the electronic books industry and publishing industry
... Markus and I will chair the call, but mostly want to listen, esp. to IDPF side, on what we miss and what should be our focus. What are your current requirements, how can we help you guys.
... We will carefully note what you say, and extract the best of the minutes after end of call to provide feedback to future Interest Group that will be formed at W3C.

Luc: We produce associative ebooks as .. version of our books
... We expect at soft level, but can produce quality Ebooks at top of what is possible of many centuries of typography
... .. don't think at the level of ...
... We think also that there is something like page-padding in ebooks, that is quite contrary to what is a page and what is a web page
... Web page is very long, it has no length, it is continuous
... But epub & web technology, there is something that appears on screen that we call a "page", you have experience of turning pages, but those are not HTML files each,
... It's not what's a web page, but also not what's a print page
... In CSS we also lack vertical justification
... As soon as certain height in pages, we have problems that have been solved in pages
... widows & orphans, lines, etc.
... As soon as we're going through these kind of new paradigm of pages inside open web platform, we should have some new abilities to code with vertical justification we don't have today

glazou: Seems you are interested most in CSS3 Fonts, Paged Media, and layout mechanisms for better positioning on the page

Luc: Not quite in terms of absolute positioning, but the composition and ? that is available in ???
... This engine is available as HTML composition engine
... In this case there should be more possibilities to code with vertical elements
... Fonts, you're right, because ... one of 2 ppl sent to workshop in NYC
... One of those papers was about fonts
... Because we experience that any time we are unable for technical reasons or legal reasons to put fonts... not able to put original fonts in the file.
... Would like some mechanism to switch ?????, available in PDF world

Luc: Original font that was used in PDF to print, to be substituted by more generic fonts, embed to use by CSS instructions

<glazou> ah thanks hober

Luc: focus size and position

glazou: Not sure if it's specific to CSS, or specific to converter
... Thank you Luc, others?

makoto: Support of bopomofo ruby is important for Taiwanese

mgylling: Can I ask you and Takeshi, in scenario of pagination driven by CSS, would page progression direction be a concern?

<plh> [relation to Ruby, see also HTML Ruby Extensions as well: http://darobin.github.com/html-ruby/ ]

makoto: Some issues wrt page progression direction, but they are IDPF issues, such as having more than one content document

<glazou> plh, ruby is almost not active in csswg

makoto: Page progression between them. This is purely and IDPF issue. Don't have any requests wrt CSS page progression direction.

duga: Something that came up from Japanese publishers were things like hanging punctuation and other typographic features that are required
... Lots of little things, like what are legal line breaks, etc.

http://www.w3.org/TR/css3-text/

takeshi: Each publisher has different line breaking rules, but now we only have 4 sets of rules in CSS3 Text
... If possible to customize line-breaking rules somehow, very helpful to Japanese publishers
... On other hand, not sure if such a capability is good for CSS or HTML

glazou: Implementors of readers and authoring environments?

duga: One area that is Wild West right now, but nobody knows how to do correctly, is user styling.
... User styling is much more common in ebooks than on the Web.
... They want to switch their reading font, or ?
... It's very difficult to handle with publisher styling
... Being able to apply in user styling, been a nightmare for very long time

glazou: That probably requires additions in CSS, but also on API side

fantasai: In what way is the cascade insufficient here?

glazou: Might be wrt detecting fonts

duga: Applying Sepia mode
... How do you decide to do that?
... Switching day-night mode, or low-contrast mode or extended reading
... Difficult to apply that styling without butting heads with whatever publisher has done
... Do you apply that bg color with !important rule to everything?

glazou: Alan, do you think CSS filters could help?

fantasai: Could maybe use MQ. A11y has been requesting ability to query for contrast settings.

janina: Happy that a11y requirement is also mainstream requirement
... Question would be, don't necessarily want to change all the pixels on the screen, just some of them. E.g. not affect pictures

<stearns> I don't know that filters would be the right tool to use - it certainly could work

glazou: Sounds like extending MQ to device apis

duga: Not looking for solution, but pointing out areas of pain

glazou: Trying to convert your input to something we can do on CSSWG side. Only thinking out loud...

+Casey from Apple

glazou: Anyone else?

stearns: One thing I get a lot of request for is some form of a baseline grid
... If you have one columnof content, you have no problem, but multiple columns, it's a problem

hober: Yeah, CSSWG has heard that, but hasn't prioritized

glazou: iBooks uses old versions of @slot or ::slot or whatever. What are your expectations/wishes, because you never told us

hober: Talking about content created with iBooks Author, which is not EPUB
... So kindof orthogonal to this meeting

casey: iBooks author has nothing to do with EPUB. Separate file extension, etc.
... Still supporting EPUB, happy to talk about that

glazou: iBooks format was not far away from EPUB

hober: Suggestion: AHL group at IDPF has been working on Regions Of Interest (ROI)
... Imagine a comic book in an EPUB, different panels
... Imagine a zoomed UI, where book author can say what panel regions are, and what order should be read
... Good feature, doesn't make sense to limit to books
... E.g. NYT homepage has regions of interest
... UA could zoom around on that in similar way

makoto: Two approaches for defining ROIs. One is use SVG content documents
... Regions are purely described by SVG elements
... Other is external region file. This is being heavily discussed. Haven't made final decision wrt that.
... Think this has overlap with SVG, plan to speak with them
... Maybe also overlap with CSSWG.

casey: Much overlap, or adoption, that we can do betst
... History of EPUB is taking in other existing standards that are already embraced and solid
... EPUB benefits by having something broadly adopted
... Important to have broadly adopted, to have something standard and not fractured

makoto: ... uses SVG elements, and introduces nothing new
... If we introduce new thing, will try to reuse that

casey: ... part of existing standards, vs only part of EPUB

makoto: We had concerns wrt limitations in SVG, but now know we are not limited wrt that. Already in contact with SVGWG wrt that.

mgylling: Setting up formal liaison between SVGWG and IDPF

glazou: Do you mind if I share the URL for your SVG-based regions for manga document?

makoto: Not a public work

glazou: Could access it without being logged.
... I'm not connected and I can view it; it's public

<glazou> https://docs.google.com/document/d/1WQ2lX-zVfJKFVimb7AZauDwJnqSzlv_0rbBq1jA8HFA/edit?usp=sharing

mgylling: What's your view on running headers and footers? Do you hear lots of request from publishers?

duga: Yeah
... 10-15 years now
... But we've had a mechanism in EPUB, arguably rather poor. Not very well adopted. Few implemented in past, nobody now afaik
... Being able to carry info across pages would be very useful

glazou: This is something I started working on.
... There is a mechanism, rough one, in CSS3 Paged media
... Started something more powerful called something future, proposals for CSS4 Paged Media
... My main goal is to be able to import a docx document and preserve all the headers/footers, and running ones
... Currently when you convert, we are not able to preserve all the headers and footers
... Given fact that publishers receive lot of documents in docx format, and main offering format for authors, it's a big hole in our publishing chain
... The document is mostly a skeleton; will send as soon as there is content to read

casey: I'm surprised you've had lots of request for headers/footers. Not one I normally get. Only got one request for that.

mgylling: I was surprised also. Had a property for it in EPUB, but nobody complained it's not working

Luc: We did complain
... We tried in 2010 to build line guide in EPUB2 and not successful. One reason was lack of headers.
... When you go from index to page, like travel guide or whatever
... don't know from the name of the hotel or restaurant, where you are
... Could be any name in any city
... Location is in header at beginning of chapter

glazou: I guess that many of you are interested in Paged Media, that it is top request
... Side question, where do you take the @page rule in EPUB right now? 2.1 or 3?

[some confusion wrt this question]

http://www.w3.org/TR/css3-page/

fantasai explains what @page rule is

fantasai: I think when I asked about css3-page headers, EPUB said they had their own mechanism and didn't need css3-page stuff

mgylling: Was reading Bert's document that he sent out
... Think many publishers would sign up for things in there.

http://www.w3.org/Style/2013/paged-media-tasks.html

mgylling: Publishing industry, High Design Layout

<mgylling> http://idpf.org/epub/pgt/

mgylling: IDPF published an informational document last autumn called EPUB-adapted Layouts
... Alan Stearns can talk more about this
... Originated in InDesign, ships today in InDesign 6
... Adobe offered to make a spec of it for IDPF
... This is around page templates, and surrounding technology such as regions/exclusions
... Applies to magazine-type publications, less so to books
... Future document talking wrt page templtaes
... Publishers are very hopeful
... In absence of this kind of technology, must go back to fixed-layout publication, which is not fantastic choice to make
... Page-template mechanisms priority

takeshi: Publisher use page-template mechanism, high quality layout
... On other hand, most ebook reading systems don't support it
... Also to create high-quality layouts, also need to think about how to display this image efficiently
... In different screen types
... Not only page templates, but also CSS mechanism like CSS device adaptation and CSS image values and replaced content module
... Also need that to complete high-level layout publications

http://www.w3.org/TR/css-device-adapt/

http://www.w3.org/TR/css3-images/

Luc: Page appearing in reading system in EPUB
... iBooks you have spread on left, and margin at top, and author of book and the top to the right page, title of book
... If you have taken into account the number of page in paper, you will have in the margins, external margins, the number of the page
... There is a page template, but should have better hand of it than having reading system design for us

mgylling: Interesting comparison of ebook reading system and web browser

Luc: There is in any reading system a layout that shows pages
... Even if the EPUB is a reflowable EPUB
... Chapters are in unique HTML file
... Displayed by the reading system, displayed in something that looks like a page
... This appearance mimic paper page
... Even sometimes have turning-page animation
... But it's not the paper page as it was
... Not page as HTML pages can be
... It's a template that designs some margins and this design is completely in the hands of the reading system developer
... It's not in our hands as publisher
... as we have on paper
... We design the margins, the page, etc. as publisher
... I agree that we should be able to have the possibility to design the page templtes
... As we can do in paper
... So that we can play the marigns, and say what we want at the bottom and the top

Luc: Engine that displays the HTML in the 2D of the screen, this is a composition

Luc: It takes fonts, calculates size characters, hyphenation, line breaks, etc.
... It puts the text inside the rectangle of the screen, calls it a page
... But it is not very sophisticated

stearns: Interesting point that it's the readers that have these templates, and useful to move that to control of authors
... But there are different levels of templates that can be authored
... First is, here is template for margin area vs. content
... Single template for all of your document's content
... Next is have multiple templates, different template for first page of chapter

stearns: Then more complicated, adaptive layout, template selection based on content flowing through the page, so if you have a page with a image, it will use a different template than a page without an image

r12a: curious, earlier on, Japanese people mentioned things like bopomofo that are required and need better support
... Can think of many other things needed in japanese layout, and wondering if we have an exhaustive list of features that are needed at the moment, or whether those were just examples.
... Also interested to know whether guys on this call recognize that there are different requirements for other languages
... e.g. working on Korean requirements document. Hoping to get Chinese requirements doc sometime as well
... Also in i18n work on things like Arabic
... fantasai works on things like numbering, text decoration
... Lots of things of interest
... line composition, avoiding spaces
... Am I right to think that there is a lot more stuff?
... 2nd question, have you been requirements from other languages/scripts that have particular needs?

takeshi: Working with Japanese publishers, and they have requests for high-quality text layout
... Now Koji is fielding those requests, implement into CSS Text Level 4 or those levels, but most of Japanese publishers are agreed to go with this level of CSS support
... level 3
... ...

makoto: A group of Japanese publishers [... some document not available in English ... ]
... I contacted that organization
... One person said to me, if IDPF sends formal request to translate, it might happen
... Thinking to ask someone to do so

<glazou> we have to wrap up

fantasai: Even submitting in Japanese would be helpful, because Koji at least can read it

<ivan> tell us where to write and what!

glazou: Thank you for joining call, for giving your input.
... Next few days, Thierry, Markus and I will browse the minutes and make a proposal
... Then see if we need another conference call
... In the meantime, if you want to share URLs, documents, etc. We have our mailing list and all addresses of participants of this call are in agenda from Thierry
... Anything to add?

Luc: Will minutes be accessible?

glazou: We will send minutes to recipients of agenda
... Anything else?

<r12a> http://www.w3.org/TR/2012/NOTE-jlreq-20120403/

jdovey: Link to Japanese document, be very very interested to look at that

http://www.w3.org/TR/jlreq/

glazou: Thank you everyone, will keep you posted.

Meeting closed.

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.137 (CVS log)
$Date: 2013/04/06 08:02:46 $