W3C ebook Workshop - Tokyo, Japan - June 4, 2013

Welcome session

Masao Ishikawa: Workshop opening

masao: I am working for w3c keio, site manager

… very glad to see everybody here

… lots of people for Japan, European, Americans...

… Japan as a special spec specification for vertical writing

… many countries have many requirements

… i18n is very important for us

… a good opportonity for meet us all

… thank you!

(introducing the two co-chairs)

Markus Gylling: IDPF and W3C relationships

mgylling: I am CTO of IDPF, the organization that does the epub standard, current version 3

… have a background in accessibility, working also for the Daisy consortium

… as you know, this is one out of 3 workshops

… a lead-in to a digital pubishing ig, that will kick of early autumn

… it is a historic event

… for us it is

… w3c has not really engaged in vertical industries

… web and tv is an example for a change

… asking how the open platform works for them

… I would really like to encourage all of you who are part of this industry to join the ig

… it is really on the alignment of the opw and the digital publishing

… for example breaching the gap between online and offline publishing

<karen_> URL to Digital Publishing Interest Group Charter: http://www.w3.org/2013/02/digpub-charter-history/diff-digpub-6-7.html

… or the publ industry metadata (like onyx or marc) : to have ways to add those to the owp

… the topic of adaption, personalization: spending 2-300 hours with a textbook, to be able to adapt that is not only an extra feature, it is a requirement

… and of course accessibility

… we also have the layout features in publishing which is not exactly the same as we

… eg pagination and css have to be better in that, but there are other examples

… we have, potentially, api alignments, eg for social reading, annotation, discovery of content

… like for education

… those were just examples

<Sharad> will this group define a stabndard for metadata also?

… looking back of the idpf and ig: accessibility and i18n

… for idpf these are non negotiable

… reuse whatver there is to do what they need

… we have an idpf wild card to solve those solution

… idpf has therefore a css profile for idpf

…. we did this at a time when the the webkit prefixes spread around

… we are aware of th eproblems when you do such a thing

… however, we do not regret this; these were in a large a part those that enables the ebook industry to move away from the propr. format

<stearns_> Sharad: the draft charter mentions metadata: http://www.w3.org/2013/02/digpubig.html

… that said, we are not done

… there are things that has to be done

… eg, bopomofo ruby and tobira layout

… our hopes that we do not have to use epub prefixes again

… but that we can more effetively get to what we need

… I hope that you will help us identify a set of core issues

… thank you very much

<Sharad> thank you Carl

Markus: there is enough metadata, no need for a new one

<Zakim> karl, you wanted to ask will this group define a standard for metadata also? and to ask how about security for e-books. will this group deine security also (for Sharad)

… the problem is on how to use them, and some of them are too poor

… i hope we may develop good guidellines how to use

… we know that security and drm is required for this industry

… but we do not want the ig to be bogged down

… it is not decided yet, but it will not be given the first point on the agenda

… but an ig is an ig, the members also set the agenda

… depending on what the members want to do

Richard Ishida: i18n & W3C

r12n: i18n activity at tha w3c is composed from a number of groups

… i18n wg, mlw-lt group, an interest group a number of task forces

… we review specifications giving advice

… we seek out requirements for owp

… liaise to other communities

… we help people to use the i18n features for owp

… we have a home page www.w3.org/International/

r12n: some issues for today, not exhaustive

… html5: text direction, in particular arabic & co, where text flows in different directions, ruby, language declaration

… all these are markup

… time and date, charcter declarations

… a lot of i18n stuff happens in css

… that is where the styling and typographic work is donw

… eg, css-text text transform, full width characters for example, or white space processing

… people did not care so far

… in chinese or thai if you add <br/> that are not good

… line breaking and word boundaries

… breaking within words

… alignments and justification, different scripts do it differently

… word and letter separation

… first line indentation and hanging in different scripts

… in indic the firs syllable has to be used

… css text decoration spec looks an underline and strike through, etc

… emphasis mark

… text shadow

… css writing mode: direction and bidirection text

… you also have vertical and variant in other languages

… sometimes mixed directions

… base line alignments

… css3 ruby: how do you align the ruby according to your preference

… bopmofo ruby: has a vertical ruby with tone marks

… css font: font properties, vary according tot he scripts

… woff fonts

… fonts features properties

… those were just a few things

… then we have some of the things we have been doing

… additional requirements for bidi in html and css

…… bidi isolation, we have provied some requirements, those have been put into the html5 spec

… form submission improvements

… requirement for japanese text layout: we produced a separate document

… with different aspects of typography in japan and how those are requirements

… b.t.w., that was produced by a task force in japan

… we have been doing work on ruby: use cases and exploratory approaches for ruby

… that will produce a requirement to the html5 group

… another is a first draft for hangul text layout and typography

… on the same a model as the japanese but for korean

… we put together a task force for indic layout, we are just starting it up

… has published a first draft document

… that will be run by people in INdia

… putting a document together for counter styles for numbered lists

… we plan to make this available as a note

… the question is whether we would need a community group to maintain that list

… multilingual linked open data group has been set up

… This is your Web, this is not W3C's web!

… if you believe that w3c will just do is produce things to what you need, that is a mistake, we do it together

… w3c brings people together, in all those success stories we bring people together

… get involved!

… the web is about people an not about technologies

Bert Bos: Can you typeset a book with CSS?

Bert: assuming you want to make a book, you have xml or html, and you want to make a book with css, is it possible

… I did it:-) I could do it

… if you stick to waht is standard: then the answer is no

… css was meant to be simple

… easy to use for web pages (mostly)

… we expected somethign else for the complex stuff, which became xslt and xsl-fo

<Liam-jp> [Bert's slides: http://www.w3.org/Talks/2013/0604-CSS-Tokyo/ ]

… learning how to do all that would make time, so we decided to do the easy thing

… but time has changed

… we simplified the design, we assumed the layout was based on the document structure

… plus some few extension for first line, etc,

… but if you do magazines, we need more, we need to look at the regions on the page

… a number of requirements:

… running headers:

… we have simple positioning, page numebers, fixed text in them, proposal to copy text into the runing headers, special elements in the documents, ideas on how to position them on other places

(example on mathematics)

… a bunch of other topics, like footnotes, continued on, shapes, grid, ...

(grid example)

… copyfitting: ensure a book has neither too many nor too few pages

… for css: fitting on a smaller scale

scribe: eg by changing the font bigger or smaller

… styling a blank page, page size, printing marks, ...

… page size is important when you print,

… change bars are interesting, they do not follow the element structure

… for an ebook reader an annotation are important and their styling

… speech, lexicon and pronounciation is missing from there

… there is no standard for that

… vertical text: we have been working on that for a long time

… we found that the first attempt did not satisfy all cases

… we let it rest, did a 2nd attempt a few years later

… but it was not enough

… now we are making the 3rd attempt, used in the epub3 spec

<mgylling> Re standards for pronunciation, EPUB 3 references PLS as defined at http://www.w3.org/TR/pronunciation-lexicon/

… hoepfully we will get it right this time

… the japanese layout requirement helped a lot

…. this is a very large subject

… like rotating non ideographic letter or putting multiple narrow character together

… effect of vertical text many other modules, like alignments, floating

… we need aligntment to the top and bottom, or table caption side

… and other properties in a number of other modules

… alphabetic index:

… the question is whether we want to do it in css; we may have to do in formatting phase

… that may lead, eg, multiplication of the page numbers

… you may want to have formatting phase for this

… or make/collapse ranges

… we need to find out what is needed for that, looking at xsl, for example

… afaik nobody tried that yet

… mathml layout needs some css

… the math wg created a profile

… we want to do more

… as least as nice as TeX can do it

… conclusion: people want to use css, they have to rely extensions because the standard are not ready

… but this year looks like a good one, this workshop, the japanese (and later indic) IG helps a lot

<karen_> Liam: ruby in running headers?

<karen_> Richard: thank you to all the speakers in the first sessioin

<karen_> ...we now take a break and will meet back here to start next session at 10:30am

<karen_> ...Also, lunch will be here; food will be brought into this room at lunch time

[ BREAK ]

Session 2

Richard: Welcome back to the next session
... after presentations this morning we will have a brief discussion

Murata Makoto

Makoto-san: Let me explain who I am [reviews slide one roles]
... co-chair IDPF Advanced/Hybrid Layouts WG, i18N sub-group lead of the IDPF EPUB WG
... advanced/hybrid layouts is largely about comics and magazines
... I was an original member of XML WG
... Today I'm not going to talk about detaills because I'm not an expert

<glazou> interesting doc for the current talk https://docs.google.com/document/d/1WQ2lX-zVfJKFVimb7AZauDwJnqSzlv_0rbBq1jA8HFA

Makoto-san: don't know a lot about typography
... but rather point out differences or simillarities in these two wholds
... Web and eBook worlds
... this is my understanding of the World Wide Web

[slide with spider web and magician on top]

scribe: this is Tim Berners-Lee [laughs]
... Web has not been used to publish books and magazinees
... only recently we see eBooks, especially in US
... will become more popular in Europe and and Asia over next few years
... Things have changed a lot in Japan recently
... some synergy between two worlds
... eBooks are based on web technologies
... HTML, JPeg, etc.
... today's ebook tech based on web tech
... Today we are seeing a lot more self publishing
... blog first, then create ebooks from that content
... users don't see differences between the two worlds
... for them the world is one world
... historically there are some important differences
... in IDPF world, EPUB are distributable packes of web contents
... IETF and W3C, what do they do
... MHTML is mainly for email, believe it's widely used by email readers
... and w3C provides widget packaging
... I was in a working group on this but nothing was published
... three different technologies for packaging

<tmichel> 3 technologies for packaging

scribe: Some key players
... In W3C, browser vendors are key players
... and the IT guys
... For IDPF, Google, Apple, Barnes & Noble, Kobo, Sony and the traditional publishers are the key players
... So differences and priorities
...IDPF: longevity of publications is very important
... if book does not display, you would sue publisher
... publisher today can freely update their web page
... traiditonal typography also important; publishers and users say so
... vertical writing is a key factor that IDPF has considered, and also ruby
... at IDPF, Javascript is not well liked
... longevity is the issue; becomes dangerous
... that is why IDPF EPUB3 does not recommend the use of Javascript
... and in W3C web-based application programs are considered important
... these are other differences
... How should we go forward?
... Are these differences really important, going to exist forever, or just because there are traditions from publishers?
... I don't have an answer
... For example, how important is vertical writing?
... Some Japanese writers say yes, others say no
... extreme positions within Japan
... generation or individual differences; I don't have an answer
... but I believe certainly that the world is converging
... ebook and web world won't continue forever; young writers and new users don't care
... We need better exchanges between IDPF and W3C working groups
... historically there have been interactions with the CSS WG
... Advanced Hybrid Layuts WG and the SVG WG of W3C
... I am co-chair of this WG; about comics and magazines
... within EPUB container, it can take three renditions
... you can change font size; don't know number of pages in advanced
... second is for fixed layout and tablets
... this is image based
... which might contain @ text or comics
... Third one is another fixed layout rendition, smaller screen size for mobile
... incorporate one rendition in single diff file
... which one to choose
... Automatically or interactively choose one rendition?
... for example, based on natural language, screen size or resolution or fixed layout
... similar to content negotiation for HTTP
... An interesting possibility for using this
... is to capture sophisticated layout
... Bert mentioned CSS for advanced layout
... looking forward to more progress in that area
... another possibility is to use images
... scanned or PDF docs
... one rendition
... and have another reflowable rendition with simple HTML and CSS style sheets
... this combination allows sophisticated layout
... but no accessibility
... this is not @
... no text to speech
... only for sophisticated layout
... we have a reflowable rendition and we know which region corresponds to which section in the HTML document
... this is the point
... allows you to switch back and forth
... what ADH WG is doing right now
... we plan to put multi-directional links
... detached documents
... it contains multi-directional links detached from XHTML or images
... Last one is intra-rendition navigation
... this is about mobile phones or tablets where screen size is not big enough
... you may want to focus on one panel or page on screen
... this navigation is based on regions
... another possibility
... is magazines
... might contain table of contents
... image areas for text
... How do we capture regions?
... We have two possibilities
... one is to use media fragments from W3C
... other is to use SVG elements
... some other issues
... non-rectangular?
... Yesterday Markus, myself and two other guys attended the SVG F2F WG
... and we had a nice discussion
... and mentioned the idea of delinking non-rectangular views from spec
... they will send us a liaison statement and provide answers to our question
... This is a very good start of our joint work
... between SVG and AHL WG
... end of my talk

Kaz: I have a question about hybrid layout
... I brought this digital TV Guide
... content is Japanese text explaining this drama
... second part is completely text
... some of pages have this kind of big pictures
... some have manga
... wondering if it is possible for ebooks to implement this kind of layout?
... Murato-san, do you have an opinion for this layout for magazines?

Richard: we will discuss this during the discussion session

Koji Ishii

Ishii-san: I am from Rakuten, Kobo division
... I would like to talk about specs
... talked last week on issues list with publishers
... found some implementation issues to take to CSS WG
... found some issues hard to solve
... I changed my topic to talk about these things
... Why EPUB Interoperability is hard
... before talking about those issues
... here is the EPUB reading system architecture
... Most has three components
... Webkit, paging engine
... renders on Webkit
... it is not required in EPUB spec
... changing font size, colors
... Today W3C defines UA behavior
... and IDPF defines EPUB files format
... but neither defines paging behavior or when user changes font
... I know there are discussions in IDPF
... and concludd they be left undefined
... I am going to show some examples that publishers are facing today
... By not anyone defining paging behavior
... listed here
... there are multiple ways to implement reading systems
... Some use IFRAME, multicol, regions
... by using each of these different technologies, some CSS properties do not work properly in all browsers
... EPUB WG expects page media to extend further and define EPUB behavior
... Not able to follow that
... EPUB not using readng system as defined in CSS today...
... ICB does not work well
... reading systems has its own margin
... inside the UA they display the contents
... In CSS, ICB assumes it's a browser region
... there is a disconnect between what browser and EPUB see as pages
... Media query has same issue
... height often does not work

scribe: Root elements are not root elements in rem, EPUB contents
... background color is not interoperable
... These different types of implementations make image layout hard
... things publishers want to do
... flat in the page, show image in the new page
... make size of images to be specific percent of pages
... some defined as CSS media
... As mentioned before, most media systems not using CSS
... does not help at all
... Another thing making EPUB interoperability difficulty
... EPUB does not define behavior in change of font size or colors
... I understand it's natural from @ perspective
... Some ambiguity of communication between author and reading system
... when for instance also wants to put inline images
... works as character or image; not clear if an image should change its size
... whic font size to follow
... it's merely unwritten between author and reading system
... it's not written and it's not interoperable
... there is no definition today
... CSS does not take case where user changes font size
... see different behavior for line/charaacter spacing by reading systems
... Next one is image caption issue
... recently raised by publishers
... maybe because of font sizes or previous issues
... If author wants to put captions to image
... it's not clearly understood whether those captions should change font sizes according to user settings
... how and where those captions should be displayed is unclear
... We recommend in JPEG or SVG so font size does not change
... putting text into JPEG will make bad accessibility
... Last one is about colors
... not requirement for EPUB
... most have background color or night mode changes
... sometimes the text is unreadable
... black on black is unreadable
... publishers are asking how to resolve those issues

<stearns_> karl: it's a bit of both. paged media describes *printing*, not on-screen pagination. so we lack a spec for on-screen pagination. But there's also implementation differences that the hacks people use to accomplish on-screen pagination run into

scribe: Today they are unresolved
... I don't have any answers to solve them
... this is a workshop where we can disucss these topics
... I am just showing the issues and showing feedback

Karl Dubost: I wanted to know

scribe: when you talked about all the issues
... if lack of definitions, specifications
... or differences between implementations which is not the same thing
... we do not solve issues the same way

Ishii-san: not sure what it solves
... I see these are issues that W3C has been working on
... because browsers are not interoperable
... that is how W3C has been adding test suites and talking to vendors to make sure interoperable

Karl: so more a question of implementation?

Ishii-san: I think it is both
... W3C takes it as a spec issue
... any developer reading specs will conclude the same behavior
... goal is different

Kobayashi-san: presentation is important about defining the procedure
... let us talk about this during the discussion time

Shinya Takami

... from Book Walker Co., Ltd.
... I moved to Japanese publisher
... Book Walker is subsidiary of Kadokawa Group
... Let's start
... I am working in publishign industry
... in Japan since last year
... the second ebook industry
... ebook phrase has started with EPUB3
... we have some problems with eBook market in Japan
... I would like to introduce Annotation for sample content
... eBook stores has preview function
... It's good for sales and easy to make
... but some Automatic samples have some problems in Japan
... generation rules are different in each store
... and fixed criteria are not acceptable in some cases in Japan
... We have some traditional file formats in this area
... have to prepare separate files, which is not so cost effective
... We would like to use automatic generation for sample content, but we have problems
... One example is "light novel"
... example like Manga
... illustrations hav big impact for sales
... Some publishers want to remove such kinds of illustrations from sample content
... because it's a motivation to buy the content
... this is imporant for Japan market
... this content is original for movies in Japan
... Another case is "know-how" books
... for example, Michelin Guide is a know-how book
... Trading brands is hot in Japan
... has list of items
... is important for these books
... If readers can read list in sample file
... and body is already done
... many customers will not buy this content
... Some publishers want to shorten the TOC on sample for these kinds of books
... a proposal from Kadokawa is to standardize annotation for sample content
... to show which parts are available for ebooks stores
... Candidate solutoins on EPUB format
... fixed layout
... this is an example for the annotation
... in OPF

[slide with code]

scribe: we can include these kinds of metadata into OPF file
... if we want to partially prohibit
... show extra properties
... maybe detect and understand this instruction when generating some content
... Next example is in XHTML5
... this is good
... publishers can instruct more details
... more rules in HTML5
... Next one is interoperabilit of user's library
... Now in Japan many eBooks stores, over 20
... and over 3,000 publishers in Japan
... each store needs to contract with many, many publishers
... in each store the product lineup is different
... We think this a barrier to expand the market in Japan
... Due to DRM or other technologies
... each user has to buy in each store
... purchase books listed only in each store's library
... Libraries are distributed by each ebooks store
... We already started to share user's libary with some other ebooks stores
... You can read Kadokawa ebooks on other ereaders, even if purchased at other stores
... This interoperabilit brings advantages for users
... Users can avoid distributed ebook libraries
... improve flixibilty of using RS and astores
... Reduction of worry of extention
... This is a sample of library sharing with Booklive
... users can buy Kadokawa ebooks at BookLive
... and read at both BookLive and BookWalker
... We also want to propose to standarize library sharing
... by standardization, helps to expand interopability to other publishers and stores
... Two topics to define: authentication for users and identification
... this topic we think is more important topic; identification of content
... type of ID for sharing
... e.g. uuid, ISBN, e-code, etc.
... I would like to propose how to specify ID for sharing
... these are examples

[slide with code]

scribe: we can add some kind of identifyer or source or metadata
... or associate second ID for library sharing
... if we can standardize ID for library sharing, this can be extended to other stores
... Thank is all, thank you

Discussion

Murata-san: I want to point out that preview generation is an on-going activity
... really an on-going project
... please join the WG

Kobayashi-san: preview?
... library sharing

Jim: interested in your input

Kobayashi-san: thank you for these fascinating presentations
... hard to handle
... large issues in a short amount of time
... all three presentations should be included in our priority list
... when all the presentations are finished, we will have discussion time at end of workshop
... impossible to reach conclusion
... If we can continue discussion of last session
... let me split the three presenters' discussions evenly
... Let us talk about three issues

<Zakim> Sharad, you wanted to ask if the lack of interoperability is a lack of specifications OR implementation differences with regards to something which is already specified. and to ask

Kobayashi-san: briefly address previous questions

Ivan: the question was on plans for IG
... about metadata
... whether that IG deals with metadata and how
... the other part is whether the IG will deal with security issues
... May I answer?
... My name is Ivan Herman, W3C
... involved with this whole digital publishing activity
... Markus gave a partial answer
... Metadata on publishing world
... and end up with what libraries use
... it's incredibly complicated
... My personal reaction is that this is so complex that is may deserve a separate workshop
... and perhaps a separate Interest Group

scribe: Markus, Thierry and I are concerned about addressing the most urgent topics
... so we may go to another group

Kobayashi-san: May I ask you about the security issue?
... what is going on about security issue in the IG

Ivan: I was not sure I understood the question right

Sharad, Intel: First question was about metadata

scribe: why are there so many metadata standards
... isn't that going to cause some confusion
... many publishers using different approaches
... so you cannot search
... that will limit propogation and search
... and of course on security there are so many DRMs
... Reality is, used to have DRM
... correct me
... People can buy books from one store
... So if this group is working on internationalization and piracy is of concern to publishing
... maybe this group should work on this

Ivan: Important clarification
... this is an interest group that will collect requirements for other working groups
... we would not be allowed to come up with solution for DRM
... On DRM, Markus said it's a complex isssue
... and we could spend ten times as much times on this topic at this workshop
... for me, DRM is a business case issue not a technical issue
... as a business case, I cannot give an opinion
... I am a poor techie who does not understand business

@: security is not limited

Kobayashi-san: DRM is very complicated
... let us stop the DRM discussion

S: Security is not only DRM
... it is broader
... want to clarify for the record

Kobayashi-san: let us address ruby
... It is common
... can you answer question?

<r12a> is ruby common in running headers?

<plh> I would believe that the IG can and should list the use cases and requirements related to DRM

Koike-san: running headers are used because we cannot use ruby
... in a paper book running header contains ruby
... but other alternative ...what is more important
... in code, what cannot be described in Japanese cannot be developed in computers
... gaiji (un-coded character) should be more important than ruby

Koike-san: some images in line

Kobayashi-san: please raise hand and say name slowly
... in Makoto-san's presentation, it is important to draw difference between web documents and packed EPUB documents
... In Japanese market there are already two different types of ebooks
... traditional and newer
... Let's think about three types: web types, traditional and ebooks
... what are differences and similarities
... what should we focus on in W3C and EPUB IDPF?
... any questions or ideas, comments
... you experience both vendors and publishers

<kaz> i#Let me explain who I am#-> http://www.w3.org/2013/06/ebooks/slides/Murata.pptx Murata-san's slide#

Kobayashi-san: not so important for this industry...just scanning
... we have to focus on how to realize layout for the next generations
... bonded, simultaneous paper and digital books
... such kind of approaches is more important
... any other comments?

<kaz> i#I am from Rakuten, Kobo division#-> http://www.w3.org/2013/06/ebooks/slides/Ishii.pptx Ishii-san's slides#

Kobayashi-san: to traditional paper book sectors

@: Difficult

scribe: issue
... whether it is traditional book
... or digital
... the content...once we can clarify we can convert into HTML
... but it's difficult

Koike: any other comments on the three types

<kaz> i#Shinya Takami#-> http://www.w3.org/2013/06/ebooks/slides/Takami.pptx#

@: traditional web and ebook

scribe: differences are
... the images could be larger than one page and that can happen
... that is major difference I think

K: this discussion has long history
... as Tamsun mentioned, why not use PDF?

M: can use HTMurataL

Koike: I am not sure satisfied with Murata-san's answer

Kobayashi-san: let's come back in last session
... to Ishii-san's discussion
... his list is very detailed, long and fascinating
... let us not get into the detailed discussion
... but the positioning of his requirements
... his requirements are
... set between W3C's specifications and EPUB specifications
... he does not know where he should bring such requiremetns

Ivan: So there is one point that is important
... One of the jobs of the interest group
... is that the IG has to provide eBook player specific test cases
... you did refer to the testing on HTML5 and CSS
... True that currently those tests are dominated by the browser requiremetns
... One of aspects of IG will be provide additional tests from the publishing industry
... We will need help from you for those tests
... they are essential
... There is a partial answer on test cases that is important

K: One answer if we have difficult to handle issues, let's make test cases and bring them to the W3C IG
... any other comments on Ishii-san's requiremetns

Richard: I would like to talk about Murata-san's needs in Internationalization aspects

K: I believe Ashimuri-san's sample is good
... how to deal with it in Internationalization standard?

Kazuyiki Ashimura, W3C

Kobayashi-san: Ashimura-san is a hybrid of two different types of complicated pages
... and image layout

Murata: I simplified things too much
... entirely fixed or entirely reflowable
... possible to have mixture
... possible to have layouts combined
... if my WG provides a good solution to the rendition mapping problem
... it can capture your example without too many style problems to rely on images

Ashimura-san: that could be an option
... my point is how to inter-related different layout styles
... a bit strange to have merging from ebook viewpoint
... if this example [slide]
... is an ebook
... maybe part one is this vertical layout
... and part two is the horizontal layout including Manga image
... and this @ part
... another interesting example
... this is index for TV program titles
... interesting point is basically the content is horizontal layout
... it goes from top to the bottom
... and then it reaches end it goes to the left
... and we need to turn this page to this direction
... and next column starts here
... This magazine consists of three entirely different layouts
... So do you want to implement this in the ebooks context as well?

M: you can use in different renditions

Markus: it is traditionally reflowable
... valide to have pre-paginaged epubs
... so you can have different text directions in those pre-defined pages
... not a problem, nice challenges [laughs]

Kobayashi-san: Thank you Ashimura-san for this nice example
... better for us to separate the requiremetns
... this sampel is very good
... to extract the very complicated layout
... in vertical and horizontal and some database generated tables and photos with vertical writings
... but I believe this kind of magazines
... the volumes drastically reduced in Japanese market
... they are being rapidly replaced by web information
... I think our goal is
... how to make electronic book
... for the magazine as is
... what is the best solution to
... provide the informations
... included in this magazine
... Ashimura-san, please extract the requirements from this magazine, but not discuss how to make this magazine as is
... any comments?

Ashimura-san: yes, I compleely agree
... we should not concentrate how to solve the issues but the use case and what is required

K: We have eight minutes
... any comments on the three presentations

Murata: I would like to hear Bert's comments on Ishii-san's presentation on page model

Bert: I think I need to talk more about the long list of problems; so much to you
... base media
... we have something in CSS
... also working on new ideas
... that are only starting; Daniel Glazman has some ideas
... we will talk about this week at our meeting
... I know there are problems
... want to know what the requirements area
... some studies were based on print books
... need more on ebooks
... most of people in WG come from Western typography
... I know there are problems, so I'm interested in hearing more about requirements

Daniel: Rendering engine vendors
... focus on page loading and over the wire
... not so interested in batch processing and static documents
... why IDPF had to standardize things outside of @
... it was not relevant for the dynamic web
... browser vendors don't want a few technologies if not relevant for web
... other is Webkit monopoly as rendering engine for ebook readers
... almost all of you are using the same engine so there is no competition and incentive

Ishii-san: one question to ask Daniel
... rather than each requirement I listed, they are examples for you to understand the primary topic
... the EPUB pages are not
... paged media as defined in CSS
... most EPUB RS vendors, especially on one major mobile platform where we cannot modify Webkit
... we have to make it usable on known page media
... if future versions take level 3 and make available
... we cannot implement for tablets
... wonder if EPUB pages shoudl be separated from page media
... or another type of media where we can define a frame
... within a browser
... and that frame has each pages

Daniel: We discussed a little bit about a session
... with Bill McCoy
... People from Hachette said they had to implement pagination over Webkit
... because it was not available
... pagination EPUB uses is similar to slidereader
... take same pagination scheme, I don't see why it should be limited to an EPUB page model, it's more global than that

Ishii: I agree
... issue is that slide model is not available in CSS today or is it?

Richard: Can we move onto Internationalization examples?
... please let's keep on track
... So I have a question for Murata-san

I: a lot of issues come from image positioning and sizing
... not sure
... it's not Internationalization issues
... but I'm not hearing those issues in other countries other than Japan
... but it's more important for Japan

Richard: Ok, that is a good point
... Let me ask my question
... you would asking about restorized content

scribe: Manga translated from Japanese into Chinese
... the sound effects
... lots of sound effects in katakana
... so the Chinese people do not hear the sound effects

<karl> timely related - Layout analysis for National Geographic Web site http://www.html5rocks.com/en/tutorials/casestudies/natgeo/

scribe: if you rastorize the materials
... perhaps if you use SVG?
... is that a fair point?

Murata: multilingual example demonstrated yesterday
... accessibility is important
... we understand that existing Manga is completely rastorized
... difficult to provide nice text...to fit in baloon
... One solution is to provide real text and rastorized text
... provide SVG and specificy invisible element
... that is a possibility
... or provide an underlined XML document
... as another possibility
... we have not specified; rest is up to users or authors
... Yes, I understand your concern
... publishers only have rastorized Manga
... so provide some features but rest is up to the market

Markus: We saw a multilingual demo by Fujifilm
... how did they do it?

Murata: small rastorized file
... on top of Japanese text
... the baloon shows text
... can be done easily with SVG animation
... don't need Javascript and we are happy to hear that

Ivan: I have a short question
... come back to that
... I am intrigued by one of your remarks, Murato-san
... that there is no real agreement whether vertical writing is important or not
... For us outsiders, this is a difficulty
... I had heard that it is very important in Japan
... Dicussion with Chinese friends say they don't want vertical writing except for historical text
... So I was surprised by your remark
... there was this strong contrast
... May be a longer discussion

Murata: Japanese could spend ten hours on this topic

Richard: we don't have to talk only about the topics that the speakers brough forward

K: Let's have lunch break and have discussions offline

[LUNCH ]

Session 3

[Richard thanks the organizers]

[... and the sponsors]

r12a: Next workshop in Paris in September. Talk to Liam about that one.

Shinyu Murakami

<inserted> Murakami-san's slides

murakami: CSS3 page implementation in Antenna House. AH is Uusing several W3C specifications.
... Particiapted in JLREQ.
... We're making ebooks and print books simultaneously.
... Cloud-authoring service, single source
... Uses CSS for ebook
... Uses CSS and/or XSL for print.
... Used by O'Reilly.
... Important aspects of CSS layout specs:
... About CSS3 Page for books today:
... Draft, but used today.
... With proprietary extensions.
... JLREQ is also available as a printed book, formatted this way.
... Many O'Reilly book also made with CSS.
... An O'Reilly book by Nelly McKesson describes how.
... It is made with AH Formatter.
... Future:
... EPUB readers will have rich features.
... CSS3 Page for ebook layout issues.
... [shows examples of layout]
... Centered on page or in page corner.
... Positioning a picture.
... Page floats in draft spec.
... Image repeated in page margin area on all pages.
... This can be possible in future EPUB with CSS.
... JLREQ is also useful for page layout requirements,
... End notes, footnotes in vertical writing.
... Position of illustrations in vertical layout.
... I hope future CSS specs will standardize these requirements.
... [showing an example with Ruby]
... I made this example myself, it is not from a book.
... [another example, page floats]
... We can do this today, with CSS draft specs.

Bobby Tung

<inserted> Bobby's slides

Tung: What is bopomofo ruby?
... phonetic system, mainly in Taiwan.
... Used in education.
... 37 symbols + 4 tone marks.
... tone marks should be placed to the right of the other symbols.
... bopomofo of a character can be 1 to 4 symbols with or without a tone mark.
... Ministry of Education of Taiwan published composition rule for bopomofo in 2000.
... But almost impossible to do on the Web.
... Tone mark glyphs in Unicode since 1993. Glyphs do not satisfy MoE's requirements.
... [diagram of glyph size distributions]
... HTML mark-up needs nested ruby.
... CSS font size proportions.
... [screendump on Webkit]
... EPUB reflow.
... And in horizontal writing with CSS, should be displayed inline. Often looks terrible.
... Alignment is also an issue.
... Center baseline. Letter spacing issue needs investigation.
... Will need 'ruby-align: center'
... With relative font-size.
... Does this conflict with Japanese ruby requirements?
... I asked for alternative solutions.
... Some suggested web fonts.
... Lot of Chinese chars have alternative pronunciations.
... We're working on tools.
... Marking up every character (in educational books) is too hard without a tool.
... Government of Taiwan is willing to help implementers.

Yasuki Ikeuchi

<inserted> Ikeuchi-san's slides

Ikeuchi: ACCESS EPUB 3.0 engine, fed back into Readium.
... Two issues:
... 1st is long ruby line breaks, found no work-around.
... Ruby nakiwakare
... in light novels, for high school students.
... Reflow the ruby is difficult.
... Reflow the ruby over two uneven lines, or over two top-aligned lines, or split the base text?
... Kanbun is for classic Chinese text in translation.
... It is required in elementary school.
... Some features can be done with CSS Ruby.
... But not enough.
... JIS X4051 is the standard.
... [Kanbun examples]
... [shows some "normal" ruby and "kaeri ten" ruby]
... needs to reorder the characters.
... Kanbun sometimes has emphasis.
... Sometimes moved to left side of the vertical line.
... Conclusion: currently difficult to resolve with CSS Ruby spec,
... but we have to solve it.

Discussion

<Zakim> karl, you wanted to ask are there similar requirements for Cantonese (such as ruby but with more tones) or other languages?

Murata: Can you not use Unicode code points?

Ikeuchi: Yes, implementation issue.

murata: so only implementation?

ikeuchi: But is also missing in the CSS spec.

Kobayashi: Kanbun is difficult to implement. It is also a small market. JLTF decided not to describe it.
... Some inline text similar to bopomofo and ruby.
... Unicode has 10 kanbun characters, but that is not enough to correctly visualize.
... Usually the symbols are made from multiple chars, like ligatures.
... Glyphs can be huge. Costly for font vendors.
... other questions about last 3 talks?

Karl_dubost: Ruby is very specialized.

<Zakim> ddavis, you wanted to ask how common instances of bopomofo and ruby for running headers (Japanese) are.

Karl_dubost: Is there similar for other languages?
... Is it reusable? Other inline annotations? More generic?

bobbytung: ruby-align: center

kobayashi: About Karl's question:
... Ruby is made for Japanese, but can be used for other languages.
... Who has examples of other uses?
... Bopomofo is an example.

R12a: Used in Chinese. Bopomofo indeed has some issues.
... In HTML ruby spec we say is can be used generically.
... I've seen Arabic.
... But things like glosses are probably beter done with something that was designed to be generic.
... I think we should finsih ruby soon, use it for far-east. Then look at generic solutions.

Kobayshi: When we use ruby in HTML, we tend to use inline annotation characters.
... Suggested that to Unicode.
... Ruby is similar to inline annotation.
... We have possibilities to use such taggings.

r12a: But Unicode doesn't do double-sided Unicode and some other things

kobayashi: Yes, long discussion possible between using HTML and using Unicode.
... We made a Note, Unicode and W3C, about tagging and functionality.
... If there are 2 descriptions, the tags take priority and the text is ignored.

<stearns_> Arabic/Hebrew annotations are vowel marks with completely different layout considerations, AFAIK

<MikeSmith> stearns_, yeah, let's please resist the tendency to want to shoehorn that other stuff into ruby

kobayashi: Bobby Tung asked if Chinese bopomofo can live with ruby. Does it need more study?

murata: I'm interested in the answer. What mark-up structure is needed?

r12a: We have two or three ruby specs for mark-up, and one draft for style.
... 1st is the XHTML Ruby Annotation spec, 2nd is HTML5, 3rd is Ruby Extension Spec.
... Who heard about the 3rd?
... [not many]
... And then there is the CSS draft.
... That determines the positioning. It is back to Working Draft.
... Some mark-up was not taken into account, and some other issues. That has to be fixed.
... I hear all the time that ruby is important.
... We can have the extension spec for HTML5, but only if we find implementations.
... Issue is then that it is incompatbile with ruby in HTML5 itself.
... Ruby is not going to be taken out of HTML5.
... But maybe some parts of it can be replaced.
... But I think we want the implementers to impl the extensions spec, which will then replace HTML5.

murata: Does the extension spec satisfy the Taiwanese requirements?

r12a: Yes, the structure is actually quite simple (in contrast to layout).

murata: So not for accents?

<MikeSmith> before hoping that Mozilla and others implement the extension spec, let's please hope that they first implement ruby at all. Which they don't yet at all.

r12a: Yes, the actual placement is done by the style. Need to mark it up, but tone marks are positioned by style.
... The extension spec doesn't specify that. Mark-up has no issue.
... But we need implementations.

murata: Bobby, do you agree?

bobby_tung: I want to provide input to the CSS module.
... Because the style doens't look so well now, people don
... 't use it right now.
... Will try to impl in webkit this year.

r12a: I'm hoping something may happen today.
... We need browsers to implement. We need people to review the extension spec. And we need people to look at and help with the CSS spec.
... Who can help?

<stearns_> link to extension spec here?

Mike_Smith_(W3C): I'm based here in Tokyo.

scribe: I've spent lot of time on this.

<bobbytung> ruby extension : http://www.w3.org/International/notes/ruby-extension/

scribe: Before the extension spec, we need impl of ruby at all.

<stearns_> thanks, bobbytung

scribe: Make contacts with implementers. I can provide names at Mozilla.
... Ruby base element is missing from impl.
... Priority is to get basic ruby implemented.
... Let's not add new requirements, especially hypothetical ones.
... If we really need them, we can consider putting them somewhere.

r12a: What other requirements?

mike: E.g., using ruby in Arabic.

r12a: How do we make this happen?

mike: Knowing how the browser makers operate, they respond to business needs.
... E.g., Mozilla now wants to make a mobile OS, interested in getting device makers to use it.
... An e-book device could use it.
... So if you make a device, tell them what the requirements are.

Kobayashi: Mike's comments are important for us.
... How to implement the requirements.
... I have a question to Ikeuchi-san
... Problem is to generate e-books from legacy paper books?
... Sometimes we tend to only move the paper books as-is.
... But sometimes paper-books have some functionality, to realize, inform something.
... Ruby can be used as inline annotation.
... We may need to change the representation based on that,

Ishii: There could be different ways to present the ruby.
... But working with publishers, we haven't found better ways yet. Long ruby is an issue.

takami-san: Talking as a publisher in Japan, long ruby tends to be used in light novels.
... Light novel very important and thus ruby very important.

Kaz: Ruby not just for pronunciation, also for annotations. EPUB includes pronunciation.
... We imported phoneme elements into SSML 1.1 for Ruby when when internationalized SSML
... Maybe, as Kobayashi mentioned, we should now concentrate on annotation functions.

<Zakim> MikeSmith, you wanted to speak and to speak about ruby and need to focus on real requirements and not hypothetical ones and to get the current ruby spec implemented first and to

Mike: Many people probably do not know how W3C works. We broker between parties.
... Requirements and implementers. W3C staff can help.
... Get involved in WGs.
... Ruby discussions are in HTML WG.
... I can help, so can Daniel Davis.
... It helps to be member of W3C.
... Members get direct access to us.

Ivan: The Interest Group we are setting up is for this. If the WG is too scary, the IG may be better.
... The IG is to collect, synthesize requirements.
... Make it usable by HTML, WG, CSS WG, I18N WG, etc.

r12a: I18n WG is about to publish a Note about ruby use case requirements. Look out for it.

[break until 14:40]

Session 4

r12a: Let's start with the next session.
... Again, we're going to hear three people's ideas.
... Discussion will be afterwards.
... Norbert Lindenberg to start.

Norbert Lindenberg

Norbert: Will talk about JavaScript and ebooks.
... How we can take books and make them more interactive.
... First thing is an intro to the JavaScript platform.
... Firstly, the ECMA organisation based in Switzerland.
... They define the language and core API.
... and Internationalization API.
... W3C defines DOM, etc. with access to JavaScript
... and specifications such as XHR to communicate with service
... Then there are libraries such as jQuery, Dojo, YUI, Node.
... Core ECMAScript language started with Unicode
... Originally UTF-16
... Still some areas of Unicode using 16-bit encoding
... Sometimes difficult to work with these characters with JavaScript
... This is being address in ECMAscript 6
... Also adding normalization
... and the ability to understand unicode properties.
... We've been working on an i18n API
... This allows string comparison and sorting
... Support for numbers, currency, date and time formatting
... Number formatting can be Arabic, Indic
... The same thing for dates - Korean, Japanese, Thai, Roman-alphabet, etc.

<karl> http://norbertlindenberg.com/2012/12/ecmascript-internationalization-api/index.html ->The ECMAScript Internationalization API

Norbert: Note that the Thai year is not 2013 - in this case is 2556
... Now started work on version 2.0 of i18n API with target of completion by end of 2014
... This will include time zone supports, e.g. for meetings
... Also text segmentation (word breaking, sentence breaking)
... Enables search engine creation with JavaScript
... Also support for message formatting, e.g. gender and plural handling
... Useful for languages such as French, Arabic, etc.
... EPUB 3 now allows <script> tag
... Works with things outside HTML5 such as XHR (not officially part of HTML5)
... There are few implementations so far so cannot currently create a book containing this.
... How do people use this?
... Drawing and animations using HTML canvas.
... for example making textbooks with quizzes and other interactive components
... Can create multilingual books
... The user typically only needs one language - let them select the right one.
... The boundary blurs between a book and an application as interactivity increases.
... The big question is...
... What kind of requirements are there?
... What's needed for people to write books?

[Norbert shows a multilingual demo]

[Selecting language from select box modifies DOM and stylesheet to only show text for that language]

glazou: Want to mention a library created by Mozilla
... called webl10n
... using it to localize Firefox OS
... Can do gender, plural, "everything"
... JavaScript is still needed in EPUB if you want to take advantage of Web APIs, for example ambient light.

<Zakim> glazou, you wanted to ask if speaker knows about mozilla's webL10n javascript i18n / l10n library?

glazou: We don't have media queries in CSS 2 to handle that so you still need JS (unfortunately)

<glazou> URL for Mozilla's webL10n : https://github.com/fabi1cazenave/webL10n

Taichi Kawabata

kawabata: Like to talk about three topics: metadata, ruby, multilanguage
... Bit surprised so many ruby topics today
... Would like to introduce Ateji - refers to kanji (Japanese characters) used phonetically to represent native or borrowed words
... Used very often in Japanese novels, often used in ruby
... In this case, ruby is not used for pronunciation but for connotation and meaning
... Many "light novels" have ateji which should be displayed with ruby
... the ruby above the title shows pronunciation but it is different to regulary pronunciation
... Metadata of EPUB 3 encapsulates publication information

<karl> https://en.wikipedia.org/wiki/Light_novel → About Light Novel mentioned a few times during the workshop for reference.

kawabata: the problem is that current metadata does not provide ruby support
... Is it really needed?
... Many ebook shops & websites just use brackets instead of ruby
... If it's really needed, we have three possible solutions
... One is interlinear annotation characters, talked about by Kobayashi-san
... For example, we can used Unicode
... The second topic is unencoded characters in metadata.
... Problem is unencoded or non-JIS chars sometimes appear in book titles

<karl> Interlinear annotation Unicode character https://en.wikipedia.org/wiki/Ruby_character

kawabata: metadata may not provide the wayto display unencoded chars
... The reader may not be able to display foreign script
... Is it enough to just use = for metadata?
... A possible solution is a font for specific metadata
... May also use IDC (Ideographic Description Characters)
... Also IVS (Ideographic Variation ...)
... For the body, xml:lang is most popular way to specify language
... Four aspects to language specification
... Fonts, Text Layout Rules, Hyphenations, Pronunciations and Speech
... Problem is what if some language is not supported by the reading device?
... What if the layout requirement is complex such as Chinese font, Japanese layout
... This was a summary of three issues. Do they really need to be solved?
... If so, how?
... Low-end friendly or high-featured solution?

Kyoji Tahara

scribe: Topic: "I want to enrich more fonts in eBooks"
... Toppan is developing a font for reading ebooks
... Prototype is Toppan Mincho
... Mincho font is good for vertical writing Japanese text
... Also Gothic font
... Gothic is better for horizontal Japanese text
... 1. There are currently few fonts to choose from
... 2. Fonts can be changed by the system
... 3 There are still too few fonts
... For ebooks, less that 10 fonts compared to more than 1000 for books
... Devices have between 2 and 6 fonts and change what is specified in ebook
... Issues with East Asian fonts - very large (characters and file size)
... Expensive and time-consuming to produce
... We went from text communication to printing to digital communication
... We should provide reader with text that is 1. easy to read
... 2. Difficult to misread
... 3. Has nice appearance
... Three things are important for realization
... 1. Text layout specs
... 2. Rendering engine
... 3. Fonts
... With this, you can perform more natural textual representation to provide a better user experience
... We need better technical support for embedding fonts
... Implementation of embedding fonts is not difficult
... Biggest challenge is distributing free-of-charge fonts
... Problem is solved in PDF but not in EPUB. Need to consider why not.

Discussion

ivan: To Norbert - What is the implementation of i18n

<Zakim> ivan, you wanted to ask how wide is time implementations of the I18N API in browsers?

<karl> Myth? In Japan, typeface has been held not to be covered by copyright, on the ground that it functions primarily as a means of communicating information, rather than to appeal to aesthetic appreciation.[5]— ^ Yagi v. Kashiwa Shobo K.K., II-1 Chosakuken Hanreishu 8 (9 Mar. 1979, Tokyo District Court) (the Typeface Design Case), cited in Karjala, Dennis S.; Sugiyama, Keiji (Autumn, 1988). "Fundamental Concepts in Japanese and American Copyright Law". The A

<karl> merican Journal of Comparative Law 36 (4): 613, 625–26. JSTOR 840277.

<karl> https://en.wikipedia.org/wiki/Intellectual_property_protection_of_typefaces

Norbert: First implenetation came out in Chrome this year
... Firefox will release implementation soon. Microsoft to follow.
... Not heard from Opera or Apple

ivan: so at the moment it's a Google Chrome implementation?

Norbert: Google implementation is a Chrome add-on, so not in WebKit

ivan: Vast majorities of ebook readers at end of line using WebKit
... so it's not possible to know when they will get the i18n implementation

<Zakim> karl, you wanted to ask if there are copyrights on Japanese fonts

karl: I often heard that Japanese fonts were not covered by copyright
... so people can use them freely. Is this true?
... If so why don't ereaders have more fonts?

Tahara: ... In each font is the creator's name

Kobayashi: Let me clarify, there is no intellectual property?

Tahara: There is IP, but you can use it freely
... For example, you can re-use them as web fonts

Kobayashi: So we can copy a font to a server and anyone can freely download it?

Ishii: What Tahara-san is trying to say is fonts are protected by IP law

<Liam-jp> [I think there are two separate confusing issues, people can use the font in practice by they _are_ protected by copyright]

Ishii: Font technology doesn't have copy protection

<karl> "Fundamental Concepts in Japanese and American Copyright Law" http://www.jstor.org/stable/840277

Ishii: I looked at rumour - no idea where it came from

r12a: In PDF you get Japanese fonts but in ebooks you don't
... You (kyoji) suggested that embedding was solution
... Japanese font could be very large - is that an issue?

kyoji: It's a problem of size?

r12a: Yes. You might have a small page but the font's file size could be several MB

kyoji: The average font use is 3,000 characters

Kobayashi: If we try to implement the full set it would be around 20,000 characters
... But common titles have only around 3,000 chars in their text
... so it's easy to make a specific subset for a particular book
... and therefore embed in an ebook

<r12a> ack

jdovey: If you're downloading a book with 2MB subset font, with 200 books in your library that's a lot of data.
... Especially if you're downloading the same font each time

<karl> font subsetting https://hacks.mozilla.org/2013/03/fantastic-front-end-performance-part-3-big-performance-wins-by-optimizing-fonts-a-node-js-holiday-season-part-8/

jdovey: That's why reading system vendors like to stick to a few nice fonts

Liam-jp: To Norbert - you mentioned JavaScript API for doing line-breaking
... When it comes to downloadable/embedded fonts

<Zakim> Liam-jp, you wanted to ask norbert about js api for adding glyphs to fonts on the fly and adding to opentype tables

Liam-jp: let's suppose you have a form in an ebook
... if it says "enter your name" your name characters might not be in the embedded font
... but with JS you could download character fonts on-the-fly. Has this been considered?

Norbert: It has been considered but not defined yet.
... TC39 aims to be a very generic platform
... ECMAScript should be able to used on servers, DVD players, etc...
... W3C might be able to specify this

Bobby: In Taiwan, there are about 50,000 chars in traditional characters
... More that 25MB for one font so that same issue
... There are systems where if I upload my ebook it will generate a subset of the font
... Regarding JS-generated characters, this issue is more important for trad Chinese than Japanese
... We want to use the system fonts but in iOS or Android, even Mac OSX, they just have Gothic (sans-serif) but we want to read books in Mincho (serif)
... Font-face with unicode range could be good

Kobayashi: As a unicoder...
... Currently JavaScript/ECMAScript cannot describe all of commonly-used Japanese kanji characters, which are endorsed by Japanese government
... I'd like to ask Norbert to support UTF-16
... Let's wrap up the font issue - any questions?

r12a: You talked about unicode range but there are some characters that are shared between East Asian and Latin text.
... when you use unicode range, you can't distinguish which space turns up. You get wide or narrow spaces.
... I've written books containing both Japanese & Chinese. I use the unicode range to solve that problem.

Masakazu_Kitahara: We have a "book-in-browser" ebook reader
... When we try to use browser fonts, we also allow web fonts
... Changing to web font - we need to know whether it's allowed
... Whether it's OK to leave the web font on the server
... Is it OK if we convert the font?
... If we serve ebooks, is it OK to change the fonts to web fonts?

Kobayashi: That's very difficult to answer. A sort of political issue.
... let me try.
... Before we jump into discussion of specifications, we need to talk with font vendors
... In Japan, the situation is very vague for historical reasons
... Some font vendors went to a lower court
... but there was no conclusion
... so it was recommended to make a settlement
... However, in general, more than ten years ago, there was an example in American law
... between some font vendors.
... The conclusion was that there was no IP for the font design
... but the font name can be protected by law.
... So Japanese font vendors have been believing we can protect IP with font naming issues and product/software issues
... Font vendors do not speak up to protect their IP but they make a private contract with their user
... In that situation, it's very difficult to answer Masakazu_Kitahara's question
... but now is a good time to openly discuss this.
... with ebook vendors, font vendors, browser vendors.
... I'd like to call upon Masakazu_Kitahara to talk with stakeholders.

kaz: Question to Norbert
... Norbert mentioned fully interactive ebook. What kind of interactions are expected?
... Do you have some examples?

Norbert: It's open to imagination.
... There's a fine line between ebooks and web applications
... Like textbooks, such as iBooks

Murasaki: One interesting target is textbook
... People would like to use epub to distribute textbooks, and HTML5
... I don't know what will happen - in 2 years it will become clear.

kaz: HTML5 has started to move towards speech recognition
... which is interesting for ebooks

Norbert: This is possible for ebooks in general.
... For EPUB, not sure.
... EPUB only has references to HTML5 so at some point, maybe EPUB should be updated

<Zakim> kaz, you wanted to ask mainly Norbert about "interaction", also would like the other speakers about their opinions

Norbert: to indicate which parts of HTML5 should be supported.

Ivan: I have seen some ebook examples which show fancy features
... technically it's ePUB, customized by Apple
... In your (Norbert) presentation, you said we need to use a book in e.g. 20 years.
... In my experience, I would try to reduce JS as much as possible because I don't know what I can use in 20 years.
... We are always in a changing state with wonderful APIs but who implements it, who does not?
... I'm a bit cynical about it but that's the problem I have with JS in ebooks.

Norbert: Does the book have DRM (joke)?
... Let's not go there!
... For JavaScript, anything that works today also has to work in 5 or 10 years.

Ivan: My worry is not language, it's the set of APIs.

Markus: EPUB has a preference for declarative syntax but we understand JS is needed for "bling"
... and sometimes crucial e.g. for education.
... This is why we don'T specify which APIs.
... For EPUB 3, we knew we would regret it.
... THe industry is moving from EPUB 2 which didn't allow JS at all.
... But I doubt there'll be something set in stone in future.
... iBooks is just one of three EPUB implementations which is most liberal in allowing scripting.
... But other organisations continue to use EPUB 2 which is not interoperable.

glazou: To Markus - we need JS to localize ebooks
... If you want books to be interactive you have to localize the alerts, etc.
... You're not going to have separate readers for EPUB 2 / 3
... Therefore readers will have to support scripting eventually.
... WHat do you think?

Markus: I think it'S a good thing - desirable.
... Maybe we'll find ourselves where we'll need a subset of APIs for ebooks in particular
... Maybe in a year or two

glazou: So probably a revision of EPUB 2?

Markus: No, because a lot will have to be redone.
... Maybe look into EPUB 3

Kobayashi: We'll now have a short break before conclusion.
... One small question...
... about metadata raised by Kawabata-san
... Any additional comments?

Kawabata: Metadata has not enough functionality for describing publications
... I just mentioned a few problems.

Murasaki Recently had a chance to discuss with decision-making bodies.

scribe: THey agree this is a mess.

Ivan: A mess is an understatement
... Regarding not having enough functionality in metadata, if I use metadata using set vocabulary, I cannot put something that e.g. has ruby.
... Is this the problem?
... E.g. if I use Dublin Core in EPUB metadata.
... That's a pure string, so I can't use ruby. Is that the problem?

Kawabata: Not only that. Also ordering of surname/given name, etc.

Ivan: What you say is a real problem. The fact that the Japanese invert the name is the same in my native language.
... That's a vocab issue and the EPUB allows extended vocabularies, so that doesn't seem very complex.
... The other problem that you can't add markup in metadata is a bigger problem.

Kobayashi: I understand this metadata is a difficult issue

ddavis: Particularly important for author names

Markus: EPUB package file is raw XML which doesn't take styles and markup
... this also applies to onix
... The core issue is when you use raw XML which is not extended to allow HTML fragments, etc.

<fantasai> MikeSmith, Mozilla is holding off on implementing ruby partly due to there not being a CSS spec for it; there's problems with existing implementations we don't want to exacerbate.

Murasaki: Bidi, bidi, bidi (sigh)

Kobayashi: Sometimes plain text is not good enough so let us continue to think of this.
... but let's have 5 minutes break.
... Meet back at 16:05 by my Japanese watch.

[BREAK]

<MikeSmith> fantasai, that strikes me as a pretty lame reason. there's no dispute about the basic support. it's what's already been implemented in IE for ages now, and deployed in production by many sites, so it's not going to change. nothings preventing you from implementing that baseline support

Session 5

r12a: Let's start with the next session.
... Again, we're going to hear three people's ideas.
... Discussion will be afterwards.
... Norbert Lindenberg to start.

r12a: [thanks speakers]
... what we want to get out of the Workshop...

is a set of points to put to the i18n WG in particular.

This is when we do that.

So I need to hear from you what the concerns are related to [i18n]

The points specifically relating to Internationalization to put to the [Digital Publishing] Interest Group [at W3C].

[opens the floor]

r12a: are we done? is everything fine?

Marcus: starting from the end because that's all I remember now! Metadata values containing rich markup ...

ruby, directionality, maybe custom embedded fonts

e.g. use of the Unicode private use area

so maybe not a requirement for the open web platform, but in metadata that the industry has and in epub it's a problem

Ivan: It is a problem for the IG, in that if this is a documented requirement it comes back to the those WGs responsible

for the serialization of metadata and for metadata

Bert: I heard about ruby, that it was mentioned as specific to Japanese. Are there more examples, where we need to compare different systems together?

Maybe the IG can collect examples from multiple languages and compare requirements.

r12a: I'm not sure there's a language-specific requirement for annotation-like mechanisms in other script but there may be a general requirement for glosses ...

but the specific linguistic issue is the ruby we use in Japanese and Chinese.

Bert: I'm thinking about hyphenation - I know about french, german, english... is that enough to know about other languages? What about linebreaking rules?

footnote placement, is that universal?

Our CSS drafts, we only know about a few languages.

I'd like to know how generic these things are in different cultures.

glazou: Hebrew has another example: ...

books for young children often use a mechanism like ruby to show pronunciation, since Hebrew has no vowels

I'm thinking also of poetry, the way a line that overflows is formatted is different between languages.

We [CSS] can't collect examples, we need help.

r12a [asks if it's Hebrew cantillation]

glazou: also words printed over Hebrew letters sometimes.

Ivan: We had the discussion about fonts. I am not an expert on that. Whether it's necessary/possible to extend woff formats to be better prepared for this partial font specification/download

Bert: I think that's not for woff, but for opentype

r12a, others: subsetting is done.

aaa: [via translation] the essence of fonts, there are more than 1,000 fonts available on paper, but for ebooks only a very few.

Rights-holders of fonts have not given permission to make those fonts available for downloading.

Ivan: this is not a technical issue

r12a: [making a list, projecting, asks people to correct the list if needed]

Hoika: pagination of vertical writing mode issues

the position of images in the float

what are the positions of text

this relates to pagination

and also RUBY

if Rubies are more than one pages then can be related to vertical writing mode

r12a: how is that an i18n issue?

Koji: we have an issue in epub WG to centre text but in vertical flow, and we think this is international issue because ...

many Japanese are discussing why this only appears in Japan.

Usually you want to put things above centre, which makes good balance

from design perspective makes more sense to centre in page

CSS doesn't provide good way to centre in vertical dimension

glazou: is that related to ruby and page/line/column break, when the ruby box is supposed to be broken into pieces? and it's no longer readable?

<scribe> [unknown speaker] the lubeys are processed in relation ot the pagiantion

for example the ruby characters are on one page and the next have main text

and this can happen in pagination

<fantasai> That sounds like a bug

glazou: this relates to Japanese but also to CSS and breaking.

r12a: I think it relates to nakiwakare, the really long stuff we saw wrapping.

Alan: there was an issue from Bert about rich formatting in CSS generated content

[e.g. maths or ruby in running headers]

r12a: similar to the metadata problem right?

Bert: generated content is often derived from the document but reassembled by the stylesheet.

glazou: it can be in an attribute

Liam: an example would be ruby in a running header.

ddavis: requirement of fonts that are different, e.g. you have a form where you type in your name, you might need a font that's not embedded or in the device.

Norbert: there was a proposal for a JS API for fonts [to add glyphs on the fly]

Takami: annotations for sample preview conetnt

In Japan some contents are maybe has some important element like illustrations or TOC,

so how to make sample preview files is important for internationalization of ebooks i think.

[people discuss Japanese name of frontispiece illustration]

Alan: when we discussed translating manga caption it was mentioned it was hard to fit the translation in a balloon

so some sort of content-fitting for translations.

<kaz> [ Kuchi-e (direct translation is mouth figure) ]

glazou: if you have a vertical bubble in a Japanese manga it might be completely unsuited to Western text.

r12a: how do you translate the manga sound effects? [[ *BAM* *ZZZ* *THWAP*?! ]]

[[ AAAAAARRRRRGGHHHHHHGHGHGH!!! ]]

r12a: I'm going to write "sound effects" and not "onomatopoeia"!

Ivan: Japanese community has produced a very strong example with the document they produced on [layout]. It affected CSS. We have others happening now.

<plh> "Cocorico" in french, "cock-a-doodle-doo" in english, how does it translate in Japanese?

One q. is whether these docs were centered on the Web or did they look at requirements of [printed] books?

<glazou> plh, thanks for using the poultry example and not the duck one ;-)

The other question is what can we, and the book industry, do to extend that to other countries, for Arabig, Hebrew Mongolian, Russian

e.g. typesetting of mathematics in Arabic

r12a: first question - the JLREQ doc went beyond a Web page to page layout,

but was not only only focused on print documents.

Plans are the same for Korean.

Indic, unclear yet.

Japanese has particular requirements, the page layout is very Japanese for page layout. We didn't deal with mathematics.

Ivan: what can we do to get Arabic, [and Russian] mathematical layout?
... is vertical text important?

Murata: quite a few people think it's crucial.

r12a: what haven't we yet solved?

someone: I think we already discussed kanbun?

koboyashi: there's also horizontal, not only vertical.

r12a: [asks about priority of writing modes

<bert_> The Math WG wrote a W3C Note about math and bidi

takase: one comment from publisher in Japan: we will not deliver content in ebooks if it cannot handle vertical layout.

joe: kobo considers it a must-have.

r12a: I am going to conclude that it is important.

bobby: traditional chinese requires also vertical layout intermixed with Latin words.

extension is for white space before/after Latin words.

fantasai: a large part has been waiting for UTR50

[Elika/Fantasai interoduces herself]

also a few related issues open on writing modes

as far as autospace, we defer to CSS text level 4

r12a: is it important that text 4 is delayed?

Bobby: I think it's OK

it could be late.

Koji: I'm not sure what the IG will handle and what CSS WG will handle...

Customizeable glyph orientation, so tha tpulishers can define which glyph appear in which orientation for a particular book

instead of using css transforms to rotate individual characters

The other issue is that author wants to customise line-breaking

that's also in the queue for future css text.

[kinsoku rules]

glazou: someone came to me about the way we select the language in CSS, it's based on elements, no media queries for that.

So they'd like to have language-based media queries.

fantasai: I think that's related to people wanting to relate selectors together.

Bert: Ivan talked about these IGs or task forces, might refer to official governement docments

Can the IG help us get copies of official rules

like [JIS 4051]

glazou: in France you have a spec for government documents; some old-fashioned books use it, but modern books use only part of it.

So it's important but not enough.

Bert: Yes, we need the doc and its status.

<shie> -> [16:43] s/takase:/takami:/

Okamoto: ministry of affairs in Japan... vertical text layout:

Maybe you had the impression that vertical layout is not a priority issue in Japan.

Many Japanese only write in horizontal layout

Number of people writing vertically is decreasing, but many printed materials in vertical mode exist.

We usually talk to industry members and they are struggling about the vertical layout spec!

Also, there is a survey that the majority of jp Internet users are in favour of vertical layout.

So, we strongly suggest that the vertical layout is a priority issue in IG discussion.

This is why the government is involved, and why my colelague and I are here.

r12a: thank you.
... I'm hoping we can prioritize these next week.

What about ruby, is that important?

ruby and bopomofo ruby

bobby: I don't have an answer about ruby-align in Japan, I have asked publishers.

fantasai: one issue I'd like to distinguish is ruby as positioned in Taiwanese documents and zhuyin fuhao when used in vertical text, positioning issues, tone mark placement needs to be correct ...

it's a text layout issue, not a ruby issue.

[zhuyin fuhao is the Chinese name for bopomofo]

<fantasai> it applies equally to vertical text, not just to ruby text

person: one comment about ruby.

A Japanese newspaper publisher is using their news articles online, with ruby.

It's not vertical layout.

In Japan not only books or ebooks but also online articles.

Koji: I heard from publishers who want different styles in horizontal vs vertical

e.g. using Japanese digits in vertical flow

and arabic in horizontal

and wanting it to be automated.

Koboyashi: similar to date and times

kaz: I brought some Manga, Japanese and Chines from Taiwan, and here are some digits. ...

[shows how they are different]

Chinese uses Arabic digits 90 degrees rotated clockwise, not Japanese digits.

<shie> from [16:58] comment is Takami, sorry.

<karl> example of Web service adding Ruby for everything in the text.

<karl> http://yomoyomo.jp/?yyparam=00000101&l=&t=http://www.asahi.com/sports/update/0604/TKY201306040103.html

Bert: my lawyer friends always say we need footnotes; other people in specific disciplines have requirements, I'd like to hear about those too.

<karl> compare the layout in between webkit and firefox

r12a: I'll try and put this list into a survey form, will send you all a link to it, and ask you which are urgent, moderately or not urgent, and then we will summarise the results.

Ivan: I hope this is not the last time we discuss these things

I'd like to see at least some of you join the Interest Group.

r12a: thank you to our sponsors, to the logistics people, to the interpreters.

There's another Workshop in Paris in September - process flow and books

[technical session adjourned]