Kyoto Forum on the Future of CSS for Asian Text Layout -- 01 Jun 2011

Nat McCully (Adobe)

Nat talks about line layout, and how the model in CSS differs from that in InDesign

Nat: Core concept of ideographic embox
... In 1998, most fonts don't have this. Each product had to do calculations for it.
... ...
... Once you have ideographic embox built into line layout engine, you can support other concepts
... e.g. leading direction -- whether leading is forwards or backwards wrt line
... If you have two lines and you set leading, which one will move?
... Leading measurement points, or baselines, is from where in the line do you measure from
... When you have multiple font sizes in a line, changing this reference point changes the spacing between lines
... Lastly, if we have time I can talk about Mojikumi spacing. Refers to adjustment of space around punctuation to achieve good full justification.
... So, when laying text out on the screen, you generally have margins, that you decide, and in both CSS layout and InDesign you decide the LTRB margins
... within which you want to layout a text line.
... So each line box gets laid out within the margin area

Nat's screen shows a white box with purple rectangles representing line boxes

Nat: Vertical layout is similar

Nat's screen shows the same, but with the line boxes oriented vertically

Nat: But there are some differences between CSS and traditional line layout
... Within the line box, we have a calculated line height
... In CSS this is equal to the leading.
... For example, if you have this text (shows some text in English)
... You get the ascent and descent from the font metrics to calculate the text height
... And you place it somewhere within that line height
... So, let's depart a bit from CSs and talk about InDesign Roman Composition.
... Within the first line's line height, we place the text like this

Nat shows a purple box covering the ascent.

Nat: The second line box looks like this, and the text is placed thus

Nat shows the second line box extending from alphabetic baseline of first line to alphabetic baseline of second line

Nat: So the first line has the same height as the ascent
... Second line uses 100% of the leading *of the second line*.
... So the line leading direciton is upwards in this case.
... Notice that each line's y position in the frame is equal to the Roman baseline.
... You can see that the descender of the second line is hanging outside the linebox.
... So, how did I change this for Japanese?
... In Japanese composition, you need to do some different hings.
... You have your line box.
... And you have text placed within that line box
... And then you have your second line with its line box, and then text inside that one
... The first line offset is set to the embox height
... OpenType fonts have an 'ideo' baseline.
... This was added so that the font designer can tell us where the Roman baseline is wrt the embox
... The second line offset is the embox height of the second line plus the previous line gap.
... The line gap is placed downward

Nat's screen shows a purple box the height of the Japanese text, a gap, and then the next purple box

Nat: The default behavior in InDesign is to measure from the embox top to the next embox top
... when setting leading
... So in developing the EPUB layout engine, I've been working with experts at adobe to tell me how conventions are followed in CSS.
... And so when placing text within the line, we first get the metrics fo the font
... and then we divide the line gap in half, and place half above the text and half below

Nat's screen shows a diagram of this

Nat: I'm told this is in order to make it easier for browsers to avoid text lines writing on top of each other, and ot give enough space above and below the text for ascenders and descenders.
... When I first saw this, I thought, what a problematic way to do text layout
... because you cannot predict where the text will be within the line box
... This is especially true when you have different font sizes
... So the line y position for the layout engine is at the baseline, because when you're drawing text you need to place the pen at the roman baseline
... So, suppose we have some different-sized text within the line
... We have our line box, and each line's metrics

Nat's screen shows two text boxes aligned by baseline

Nat: Then you add the line gap.
... The line height increases as you add text.
... The baseline moves down, but the calculation is not straightforward if you want to get an exact pixel position on the screen.
... In InDesign, when you have different point sizes, such as in this Japanese run
... We get the text metrics as before
... ...
... The Japanese text has a particular relation to the roman baseline
... As far as the user is concerned, they don't have to worry about the calculations. Their text is centered within the line box

Nat's screen shows large Japanes text next to small Japanese text within the purple line box

The roman baselines are not aligned -- the ideographic emboxes are centered within the purple line box

Nat: In CSS, there have been controls added for choosing baselines.
... The main problem I have right now is leading being added above and below
... I have a proposal to solve it, but it has some drawbacks.
... In Japanese two major baslines used are embox center baseline and embox bottom baseline
... When measuring leading, you measure from top of embox to top of next embox

Nat shows a diagram. Gap between lines is labeld as aki -- line gap

Nat: Why do we need grids?
... In InDesign we have two different grids.
... First is the Roman baseline grid.
... This grid is in both Japanese and Roman InDesign.
... In Japanese InDesign we added a different grid.
... This is what a Japanese grid looks like.

Nat shows example with long rectangles representing the lines, separated by gaps

Most lines are that size, and fit within that grid

Three lines are in a bigger font size: they are centered within the bounding box of four line grid boxes.

Nat: In the Japanese grid, we can center wrt the grid

Nat shows an example where there is small text, then large text, then small text in one line

Nat: The big bold text is centered within the two grid boxes
... The first run is bottom-aligned to the centered text. The second small run is top-aligned wrt the centered (bold) text.
... When the text is placed wrt the grid, it makes for a more pleasant reading experience.
... So to summarize, the Japanese grid has seeral purposes

1) Sets the frame size to fit the grid

2) Positions lines in the frame rgardless of font size to fit the grid (snaps like bsaelines e.g. embox centers)

The baseline grid:

1) Allows lines in the paragrpah to "snap" to the grid, aligning to "snapped" line sin any other frame on the page

2) Supports any single baseline (embox or Roman) per paragraph

Nat: The baseline grid is drawn over the whole page.
... When you place frames on that page, the text within those frames is moved to snap to the grid.
... what that accomplishes is that across different frames
... The text matches position
... For example in multiple paragraphs, depending on whether you have titles or pictures or something embedded within those columns,
... The body text in the left column will be snapped to the same lines as the body text in the right coumn
... so that overall the layout on the page will be very clean.
... The snapping behavior to the grid is a paragraph setting
... When you set that, you can have a choice of snapping the first line of the paragraph to the grid, or all lines of the paragraph to the grid.
... Within that, you choose which baseline to snap to
... You can choose embox bottom, embox top
... It snaps to the grid
... So I see that we're almost out of time
... So I will leave it at that and hope we have fruitful discussion about grids and any other thing.

RRSAgent: make logs public

Koji: I will talk about the Tokyo session and ideas and opinions presented there.

Koji (via translater): We had 5 sessions in Tokyo, and today I will present the results of each of the sessions.

Koji: Firstly, an EPUB session, we had presentation Hiratsukashi
... City of Hiratsukashi has been distributing PR brochure in EPUB since March
... In Hiratsuka in order to reduce file size, they are using CSS3 properties such as border-radius
... And also they are hoping to be able to change the layout depending on the device/orientation
... They're not using Ruby because it was unstable on some terminals, so they are using brackets
... Next panelist we had was person from Toppan printing company.
... One of the first requests that Toppan person made was that they wanted to define box sizing by number of characters and number of lines
... Also, in terms of line-breaking rules in CSS3 Text, they want to specifically designate certain characters for line breaking rules (by codepoint)
... We also discussed line notes (warichu)
... The comment they raised is how are we going to treat these in Web and ePublishing
... The request comes from the fact that some people would like to publish things like this in electronic formats
... Question is whether something like this can be done in electronic format
... Also, Toppan Printing made comments about so-caled private characters.
... Unicode is so well-spread today. They found 1200 chars in Ko-jien dictionary that are not in Unicode.
... They searched 800 books, 1400 chars (0.6%) are not in Unicode
... So they also said that in archaeologists excavate, every year discover about 30 new characters.
... For EPUB we use WOFF/OpenType, but according to Toppan SVG fonts are easier to create. They suggest supporting SVG, too.
... Discussions about font and private characters will be covered deeper in session 4.
... A person from company Voyager was a panelist
... As you probably aware, they developed ebook reader and marketing it since 1993
... Voyager person made a point that in general Japanese literature you can often see mixed writing modes.
... This is a cover page.
... Then the table of contents follows
... And next is section heading, typically vertical writing to
... Main text is normally all vertical
... And back matter is normally horizontal.

(cover page was also horizontal)

Koji: They raised some questions.
... One was whether mixed mode can be used in EPUB
... Whether change in progresion is possible for section heading
... Other point the Voyager person made was that we may need to review some line-breaking rules
... One of the resons for this is because we are going to enable reflow, or differences in resolution, we may need different line-breaking rules than rules in the paper world.
... In fact, Voyager person said they implemented different line-breaking rules than the one sin JIS, wrt inseparable characters and also some other elements such as grouping (?)
... And some comments were made about possibly user-switchable text-flow.
... Voyager's readers have always supported vertical/horizontal switching by the user.
... concern that this will increase cost of content development.
... In Tokyo discussion, general consensus was that depending on the content we may enable this kind of switching for the user, although it may increase production cost.

<murakami> Voyager readers can break group ruby.

Koji: But we may also implement some mechanism that allows the creator to prevent users from switching.
... Also the other point was made that we may need to allow this kind of switching from accessibility point of view. But this is a different discussion.
... The other request that Voyager made was about old chinese writing (kanbun)
... Their understanding is that kanbun writings are often included in textbooks, so they should be supported.
... In terms of how to support this in CSS/EPUB, needs further discussion.
... Next panelist we heard from was from Impress R&D
... They publish a magazine called [??]
... They're publishing on Web, printing, and ebook.
... They're separate in production, on an experimental basis
... Basically the question is, when they have one set of contents, how can they change the style and layout for different formats.
... They also made a point that in carrying out such experiments, they discovered that some implementations are behind.
... In terms of logic, it sounds correct, but in reality did not work.
... One particular example was that SVG and MathML and fonts in vertical writing did not work well
... Mainichi Communications spoke too.
... In their company they're publishing in PDF.
... One of the benefits of using PDF is that they can use the content with paper printing, so the production cost will be low
... But it is hard to read, especially on small devices.
... Their understanding is that if we really want a full-scale launch of ebook, we have to break down components of paper publishing and redesign for ebook publishing.
... Their two requests that they made in terms of publishing future and for the web
... One point they made is was that, especially in fee-pay services, we need high quality layout, fonts, use of private characters, etc. (Although may not be as good quality as paper)
... They're particularly concerned about color
... Especially when the publish things like photo albums.
... Asahi Newspaper
... They started browsers/iPad/Android services in May
... Technically speaking, such services are based on HTML5/CSS3
... One of the greatest reasons for using HTML5/CSS3 is that they are compatible with video and multi-column layout
... Because there are some old PC browsers that aren't using HTMl5, they aren't using HTML5 for PC
... In terms of design, they are using totally different design tha tnon-prepaying Asahi.com
... One thing that they hope to do is make this fee-paying service much more like real newspapers
... using boxes and multi-column layout
... Also if we look at conventional news websites, because the text is so small, they are very hard to tap with fingers
... These are actual screenshots

Koj: Right hand side is fee-paying service; left hand side is web page

Koji: Asahi Newspaper said they gave up using Ruby because some browsers cannot maintain vertical rhythms
... What they also hope to do in the future, they attach particular importance to their own fonts.
... But the file sizes are too large for users to download
... In terms of Gaiji or private characters, what purposes do we need private characters?
... Obviously proper nounds such as people and place names
... Also the other great source of need is political parties, making iconic-square ligature (kumimoji)
... that's it for reports from Tokyo session.
... Do you have any questions or comments?

Ashimura of W3C: I asked same question day before,

Ashimura: EPUB is combination of CSS and HTML as a package
... Asahi said that validation is very difficult. Validation itself is not difficult, but fixing errors is difficult.
... Do others have a need to make these functions easier?
... Comments from audience?

Koji: How many are creating content in EPUB?

several raise their hands

Koji: How many use EPUB validation tool?

<dbaron> 2 raise their hands

Mitsubishi, involved in JAGAT

Mitsubishi: I don't see any problems with validation. I also work on PDF, and for PDF2 we need validation to check compatibility with printing
... For EPUB, it's just started now. We don't need anything right now, but in the future there will be many mroe validation tools.

Koji: Any more questions?

?: My name is Hagimura, and I work in Web Publishing.

Hagimura: Printing and Newspaper companies are trying to achieve same quality as paper printing?

Koji: My understanding is that they don't necessarily require same quality standards for epublishign and paper. We need to establish different standards for elctronic publishing.
... But as Asahi and ?machi person said, the current standards of CSS publishing is not good enough for fee-charging services.
... I'd like to hear your opinion, too, ifyou'd like

Hagimura: As someone working on Web, I'm fed up with discussion that we have to be same as the paper.
... In terms of what you said, wrt quality are they requiring better quality wrt layout or general general ? or content wrt fee-charging services

Koji: As I recall, what ? perosn aid, if we are going to publish some kind of graphic services we need better color calibration. Also in temrs of general view, fonts and line-breaking etc, will need to optimize to the new environment.

Nat: I don't think anyone thinks that we need to reproduce the same layout that we get on paper on the Web.
... We have PDF for that.

Nat++ :)

Nat: We need the UA to be able to control where things go on the screen, so that the author can place content predictably on the screen.
... One of the problems we keep hearing over and over is that ruby increases the line height.
... The consensus was to add a boolean to choose which behavior you wanted.
... What this does is that it adds compexity to the API and the markup. But I think that it's possible to honor the conventions that existed in print
... The conventions existed for a reasons, they existed because legibility and beauty of design has become refined on paper.
... We can take that refinement and adapt it to the Web.
... That's why we're requesting these kinds of controls, so that the UA can give these controls to the user.

jdaggett: I think there's a tension in CSS between giving the designer control over the design, and assuring that the user actually sees a result that's visible.
... I guess it seems like a counter to some o the stuff you're saying.
... Fixed line heights are great, but gives the author opportunity to shoot themselves in the foot and make line heights that collide
... I'd like to hear if you think that's something to consider.

Nat: I think that many of these topics that we're going to talk about, font fallback, the beginnings of the rendering side of the Internet technology had different browsers giving completely different layout for the same markup.
... So this problem is I think extremely important for the Web, and less so for print.
... Although in print we had similar problems in the early days
... Layout was unpredictable depending on fonts.
... So I think that right now CSS errs in the direction of providing layout with the lowest common denominator, and as a result we get really ugly layout.
... And unfortunately, there is no way for the so-called correct browser to display the correct layout because the controls don't exit yet, just starting to come together now.
... I think things will improve greatly when more and more platforms support a single browser technology, or at least the browser technologies agree on exactly what is supposed to happen.
... CSS3 Text leaves too much up to the UA.
... But your quesiton makes me feel very positive about the outlook and I think we can definitely work on it.

Koji closes, everybody claps.

Masaki Yamabe CTO/Designer ??

Yamabe: I'm from Alliance Port. We design and produce websites. I'm invited by ? from W3C. Today I'm going to share with you what we have done so far in Japanese typesetting.
... Let me introduce what we do at our company. In addition to web designing we do .. DTP /logo
... We work with both analog and digital.
... As we discussed in first session, one of our challenges is how we make beauty of Japanese layout into web site.
... Now I'm going to share with you wnat we have done.
... 5 years ago in 2006, here is an example of vertical typesetting for Japanese layout.
... If you look back 5 years ago, there's almost no existing vertical typesetting implementation.
... We went through trial and error process, finally implemented vertical typesetting.
... What we did in 2006 was website for traditional Japanese inn.
... And please look at the screen on your left. On the top to the right is the vertical Flash.
... Flash is used on the top to the right.
... What we did for vertical typesetting you can se eon the bottom.
... Simply describing the website, this a blog for Japanese and traditional inn
... First the managers or owners of the inn write the blog contents using the CMS Moveable Type
... The CMS text is converted to XML, which is set vertically with JavaScript
... This is how it looks like

slide shows horizontal text in the text box

converted to XML format <item>, <published>, <description>, etc.

Yamabe: After that it's arranged vertically with Javascript

bottom of slide shows vertical text.

Yamabe: If you look at hte subject, we impelmented the typeface to make some expression.
... I fyou look at XML version and the JavaScript version, you can see that the numerals are converted to Chinese numerals

(date is converted

)

(and formatted, started out as iso, now in CJK)

Yamabe: As I explained before, the CMS Moveable Type is used.
... The horizontal text from the CMS is rearranged vertically with JavaScript
... Let me explain how we rearrange.

slide:

Not using CSS rotation but using <div> for each character

slide shows tons of divs with style attributes, classes, one per character

letterspacing done with margin-top

each line of text is inside a <div class="lb">

Lines are arranged vertically using float

Typeset processing

* applying line break not only lining up characters vertically

* adjusting punctuation marks to correct position

*replacing to vertical characters

*replacing Arabic numbers ot Chinese numerals automatically

Yamabe: Implementing line-breaking rules
... Need to replace characters e.g. for vertical brackets
... Also need to adjust punctuation mark position using position: relative
... For the numerals we developed source code that converted the numbers

e.g. 11 -> 十一

Yamabe: Let me do some demonstration.

Yamabe shows slide with demo of tategumi.js

Yamabe: We disclosed the information on how we implemented this, if you're interested ask me.
... This is where the vertical script islaid out
... Here we have markup in HTML.
... We classified text into different categories, e.g. heading, main body, etc.
... We assigned an ID when we want to convert from horizontal to vertical
... Let me show you how we make this website

Yamabe shows JS

Yamabe: First you specify id of what you wnat to convert
... Then we assign parameters, using selectors
... For example if I delete an ID, then it's going to go back to horizontal layout like this
... These are the parameters that we can set
... First font-size by pixel
... glyphs per line
... line margin
... space between letters (glyphMargin)
... Also block Margin, will explain in detail later
... And you assign either true or falso whether you wnat to activate or deactivate kinsoku
... So by setting these parameters, you change expressions in the vertical layout
... For example, if I change from 16 to 20
... you can really change the font size
... Here is an example, between first line and second line the line-breaking rules are applied.
... But if you set it to false, they will lay out without the line breaking rules (period can start a line)
... Here is just one line-breaking rules.
... You can specify which letters are subject to the line-breaking rules.
... Here I will copy a large amount of text into honmon area.
... It will make columns.
... Readers can simply scroll down.
... Margin between different columns are set here.
... Here we have 100px blockMargin, which will be applied between columns.
... Regarding font type and sizes, you can set them using the style sheet.
... This script is available in github

http://github.com/allianceport/tategumi.js

Yamabe: MIT license

Yamabe returns to presentation slides

Yamabe: Our objective for this project was to do in browsers what we do in the editors
... not using Flash
... Through this project, we felt that we were able to do a lot of things in parameters using a combination of XML, HTML, JavaScript, and CSS.
... For example in 2008, we developed a script that enabled multi-columns. At that time CSS multicol was not available
... If you look at the source code, it's just one block, but once it goes thorugh the JS, it is separated into two columns like this.
... We're using our automatic layout to develop a newspaper block, where we implemented vertical layout as well as the multi-column layout
... In this website once they write their text, the XML is then laid out as for a newspaper
... You have a vertical text heading, and multi-columns for the text.
... Regarding pictures, once the users upload the pictures
... The text flows around the pictures
... User can choose whether they want to place the picture on the right or the left

Slide shows box of text in 2 columns. Top of 2ncd column is taken by picture. It is floated; the sentence from the bottom of the column continues after the picture.

(the picture is exactly the width of the column)

Yamabe: Users can choose the size of the papers -- A4 or A3
... They can print them out into A4 papars
... Columns are common in DTP, but it was very difficult ot implement in JavaScript
... If you're interested in this newspaper blog

http://www.allianceport.jp/shinbunblog/demo/

Typeset Engine for Newspaper Blog slide:

* In case of Japanese, character area is calculated by numbers of characters and number of characters are calculated by character area

* Wrapping around automatically

* Making newspaper name vertically

Yamabe: When it comes to the newspaper blog, you have defined areas you can put text into
... You are given a number of characters which you can enter into the newspaper.
... When the overflow happens, we have a magnifying glass so you can read the overflowing contents (issue)
... We didn't want users to write a special language, therefore we try to do almost everything by this automatic layout engine so that users can simply input what they want to say, like writing a blog
... It is then presented like a newspaper
... What we wanted to provide with this newspaper blog, we didn't want the users to write in a special language
... We just want users to make a blog, like a regular blog. The automatic engine converts their input
... We follow the progress on CSS development, but only enhance our own layout engine.
... Even though CSS3 is there, some browsers do not support.
... We will continue using both our own engine as well as CSS.
... Our objective is to make something enjoyable, like the layouts we showed you.
... ...
... Random typography, Fractal typography
... Here I'd like to share with you ...
... One of them is random typography. It was used for Design Language 2.0
... The cover of this book is done with random typography

Yamabe shows photo of a book cover where a block of text is set in random font sizes and styles (per character)

Yamabe: This cover contains the names of the authors as well as a summary of the book. This is randomly laid out using JavaScript

Yamabe shows an example of this in the browser.

Clicking reload changes the typography

Yamabe: You see random type sizes, styles, and margins
... This is possible because we use the Web tehcnology, with paper-based design we couldn't do this. People liked this idea, that's why they took this idea.
... This design on the cover is done by Yasuhito Magahara. He used our technology
... Before closing I would like to share with you anothe rone, which is Fractal Typography
... This is artwork, which we exhibited at ? Newspaper Building
... I will show you a tape
... So we have this using plasma display with Google Chrome fullscreen

Showas an exmaple

on the screen

the characters are placed one-by-one, large, small, filling in gaps etc.

minute-taker can't tell how one is supposed to read any of it

as the placement seems pretty random

and in some cases overlapping

Yamabe: We are inspired by typography works where they laid out .. metal
... We tried to mimic that technology by using our own technology
... Each letter is sandwiched with <div>s
... From aesthetic perspective, it's not so good. But the program runs very smoothly
... They are not necessarily readable, but we accept that.
... Japanese language is unique in that you can write both horizontally and vertically.
... When we created this work, it is enjoyable even if it's not readable.
... This is actually accepted by the audience as well.
... We used the ? newspaper typeface since we exhibited at the ? newspaper building.
... As for fractal typography, we expose the script, so if you're interested please ask me.
... Thank you very much.
... Any questions?

Nat asks to see the newspaper blog again.

Nat: My comment is about last quesiton in the session, do we need to recreate what's on paper.
... This argument goes back and forth.
... As you can see, this layout is very nicely representing what normally we can see on a newspaper.
... But when I see this, as someone who is rather detail-oriented, I see that the picture has caused the text in the second column to move up a couple pictures
... And the top of the text does not align on the top of the picture.
... These types of details, it looks ok.
... If you can support puting this on the character grid
... And have the pictures be put relative to the character face.
... Even if the users can't tell you what they're looking at, they can appreciate the quality.
... The comments we get is that they won't pay for this.
... It's revolutionary technology to make this Shinbun blog. But wouldn't it be nice to go a little bit futher.

s/futher/further/

<dbaron> the example is http://www.allianceport.jp/shinbunblog/demo/portal/cat4/05/post_1.html

<dbaron> discussing in particular alignment of text in the columns under the heading "新人が入社しました" due to the image

Yamabe: We don't believe it's necessary to reproduce what's on paper, but it's necessary to recreate paper.
... ...
... Users that can't use InDesign can enjoy a newspaper-like blog.
...
... Let me share with use use case for this blog.
... In their class, they divided into smaller groups in one class.
... And they made investigation of ? products
... The Ministry of ?and Forestry
... ... based on this campaign by the ministry, the schoolkids were sent out to make investigation of their local foods
... They went out to the field and looked for local products, like fish or crops
... They put tohse information into blog
... They are laid out like newspapers.

<dbaron> s/?and Forestry/Agriculture and Forestry/

Yamabe: Question was dealing with fonts sizes and window sizes etc. for multicol
... We don't actually convert XML to HTML, we use regular markup
... And using scripts convert the horizontal layout to vertical layout.
... So once you access the information I provided to you, the source code and demonstration

http://www.kumihan.org/

Question on how to render vertical glyphs

Yamabe shows source code, which converts to vertical presentaiton forms

Question was about the katakana prolongation mark

For vertical text they use a vertical line

Question was about use of the script. Answer is, it's under MIT license, and you can use it within scope of that license.

Yamabe: I will stay in this program to the end, so if you have further questions please ask later.

<dbaron> The next session is session 3. Approach to the e-book Business. Keitaro Hanada, Sharp Corporation.

Hanada: First I'd like to cover our company history. Over past 10 years we've been involved in e-expressions. Also review what kind of contents we have been dealing with
... First, an introduction of our company shop
... Sharp entered ebook business in 2001. Actually we had been working in ebook business before, but not stated publishing yet
... Our company originally has nothing to do with books or publishing. We develop electronic devices and mobiles
... In that way, as the mobile phone tterminals evolved, our ebook business has evolved accordingly.
... When we started to provide services, we had PDA and also notebook PCs
... First we started to deal with text, books and other literature
... Around 2006, XMDF 2.* we started targetting mobile phones, too
... PDA is mainly aimed at business customers. As you know, mobile phones are targetted at many more people, particularly young people.
... As a result our targetted publications change from regular text to more comic books
... initially, people wondered whether it would be possible to read manga on mobile phones.
... of course not possible to display the whole page, but can show frame by frame and young people did not mind
... Much of what we publish today is comics
... Also, the tablets' function and performance have advanced, and we've started to see emergence of tablets
... So our business started to focus on more high-perf terminals that can display e.g. magazine media
... In 2010 we started to develop terminals specifically for book formats
... One of the main pillars of our technology is XMDF -- ever-eXtending Mobile Document Format
... XMDF technology is based on XML
... As I said before, it's focused on mobile so we needed technology that functions well in an environment with smaller resources, but still has high speed, high-performance with small amount of memory
... As for XMDF, there's a distribution format and execution format
... Description format is standardized by IEC
... One of the features of XMDF format, it has support for Japanese-specifi features such as vertical writing, line breaking rules, and ruby
... JP language support functions are not very special, not going to cover all of them
... One thing I will talk about is float graphics.
... We became compatible with horizontal/vertical switching from an early point in time.
... So users are able to choose vertical or horizontal mode, and either way it provides a decent view.
... Some functions presented here, e.g. bg image, bg music, conrol over page advance
... Also has a jump function, used in e.g. dictionary or choose-your-own-adventure story
... Next is a comic function
... As I said, you can't see the entire page at once on a mobile device, so how we show the frames is important
... For example, here we have a vertically-long frame so you can't display the whole frame in one screen.
... It shows the top first, and then automatically scrolls to show the whole frame.
... Also, cartoon creators tend to use various expression. For example, the example on the right shows starting on the right, scrolling to the left, then coming back to the middle.
... Also we have functions implemented in our terminals
... When you change from one frame to next frame, we can set some special effects such as vibration.
... We have also been involved in electronic dictionary. XMDF can be used for this kind of e-dictionary
... Dictionaries are one of the electronic contents that can be marketed
... Functions I have been explaining here were realized even before 2-3 years ago
... Last year we extended our format to accommodate other content suhc as newspapers and magazines
... So we moved from the conventional format such as text media or comics to magazines
... There's a wider range of formats in magazine layouts, so we needed a format that can almost copy roughly what we can do in paper format.
... Also we wanted to enable dynamic format that's also possible in electronic media
... We've added 3 different type of formats
... First one is image format. This is straight scanning and copy of paper media into a bitmap format
... Benefit of this format is that users can access layout image that they are accustomed to in printed media
... You can drag around the image to see parts of it and also zoom in and out
... Magazine format is relatively free, but for user it's hard to read the text because you constantly have to scroll up and down, left and right to read the text.
... That's why we added the next format, that we call the hybrid format.
... It's still an image format, but there is text inserted into the format.
... Basically what the user can do is first they look at the entire image and layout and photos. If they want to read parts of the text, they can go to text-only mode and read the text.
... The third one, multi-layout format. This is specifically an electronic format and the text does reflow.
... Because we are assuming this format will be viewed by different kinds of terminals, it's compatible with multi-layout, such as portrait vs. layout, vertical writing, horizontal
... It changes layout depending on screen sizes as well.
... This is an example of multi-layout
... As you can see on the screen, you can increas the text size without changing the layout.

or the pictures.

Hanada: This table shows different patterns of multi-layout that this format can do.
... For example you can have 10in screen or 5.5in screen
... You can select vertical flow or horizontal flow, portrait or landscape.
... Of course you don't have to create content to fit all these different patterns. You can create content for one format, and somehow the terminal will cope with it and display the contents.
... We have these different settings to meet the demands of the publishers.
... Some publishers want to have completely different layout for 10in vs 5in, etc.
... We create a format and sell terminals that provide a viewer.
... We also make content-creation tools as well.
... These are the 3 patterns we have
... ...
... There's actually one layout format not included in this slide.
... That's what we call HTML View. It imports HTML as-is and displays as-is.
... This is actually one of the formats that we strongly recommend.
... Many customers will tell us that XMDF is complicated, and we already have a lot of content in HTML.
... You might wonder why we didn't put that format in this slide, will touch on that later.
... In our first format, image and hybrid
... Publishers already have the contents in paper, so such images and text can be automatically converted to this format.
... The third format, multi-layout format, we're talking about publishers using a creation tool to make the layout.
... This is the overview of the workflow.

Slide:

Input Material

Edit the Body Text

Edit the Page Layout

Confirm the output

Publish

Input formats: Adobe InDesign IDML format

plan text

HTML

TTX

XMDF Description Format

Hanada: One challege for e-publishing is that e-publishing alone is not going to make financial support
... They're still a paper-based business, and e-publishing is on the side.
... I think that will change soon, but right now there is a need to reduce the cost of e-publishing for such publishers.
... The key challenge that we face is how to minimize specific processes that are only required for e-publishing.
... Basically we don't want to add many complex processes just for electronic format.
... One of the most important things is of course to be compatible with various content data formats, for example InDesign's format.
... And one work that it's speficially required for electronic publishing is the page layout, or multipe-page layout assuming it will be published to multipel terminal types.
... The other thing that publishers .. is the proofreading of the contents.
... Of course this proof-reading process is time consuming
... especially if you have to proof read for various terminals
... The proof-reading is a lot of work, and costs a lot.
... It will be impossible for publisher to buy all the terminal sto test.
... So tools that emulate terminals can be used to check.
... The other challenge is related to the private characters.
... PC environment has the same problem, but moreso in mobile fonts due to limited fonts they can carry.
... Usually such devices are only compatible with JIS level 1 and level 2
... In our creation tool, we compatible with Adobe 1.6 fonts
... As long as fonts are within this collection, it creates a bitmap graphic and inserts within text
... Some people wonder why not insert and use real fonts.
... But due to limitations of mobile devices, we think at this point this is the best option.
... Now I have been talking mainly about XMDF format that is our ebook
... Now I'd like to switch subject.
... These slides are from the Tokyo forum and panel discussion
... Going to talk about challenges we see in the future of CSS.
... As we enter this ebook business, in the past we have taken care of large portion of this value chain of ebook business.

Slide: Production, Deliver, View

Hanada: This is an old business model. In new model, there are standards and different players play different roles.
... We recognize that and try to change our role.

s/role/business model/

Hanada: What we feel is that in order to tackle challenges in ebook business, we have to keep in mind entire picture of this value chain.
... Specifically, the first challenge as we see is display layout setting.
... So content builders can configure the settings, and users can change the settings. How are we going to balance these two?
... In the past, mostly the publisher or creator side dictated the layout. They had certain views or layouts in mind that they wanted the user to see and created that.
... But recently we are starting to see that users are wanting to choose how they see the screen.
... Also in terms of contents there is more .. type of content that high quality and layout really matter, and other where it's just information really
... So rather than the layout, ...
... In terms of our implementation, we make it possible to choose vertical reading and horizontal reading.
... So there are 3 possible types of settings for character direciton.
... First one is not specified, which means user can choose whether to read vertically or horizontally.
... Second choice is a set value, the author sets the preferred value but the user can change it.
... The third one is enforced.
... The publisher says "this is for vertical only", then the user cannot change it.
... So basically in terms of our hardware we're making all possible to set these different types of settings
... Which one is chosen depends on the character and nature of the contents.
... In the case of JP people, they tend to like reading things vertically.
... So they tend to choose reading vertically.
... Also we have notification functions, on the content-builder functions.
... They can say there'll be maintenance outage tomorrow, etc.
... As you can imagine the speed and timing is key for such messages, so usually composed in horizontal format. If displayed in vertical will look strange.
... Second is foreground / background color.
... Basically in terms of color spettings, if publisher doesn't set anything, then the user can choose the colors.
... If the publisher sets colors, then the user cannot change anything.
... Because as you'd image in font color and bg color are too similar, in some cases it will be hard to set the color of the text.
... So in most cases either the publisher will dictate, or the user will chose the colors at their own responsibility.
... There's a fine line in terms of how much we allow users to change. There's question of accessibility, and also some users have strong preferences.
... ... difficult decision to make.
... We can also specify line break rules, which characters are in scope, character spacing, and hanging punctuation
... For this implementation, we only allow content builder to change these settings because some publishers really want to control these, but users hardly wnat to control these elemtns.

s/mtns/ments/

Hanada: As for Ruby, there are two types of ???
... One usage is when Kanji is very difficult to read.
... So the publisher might put Ruby in because they think the kanji is difficult.
... But we allow the user to turn that off, if they can read every kanji.
... But there are some other special cases where publishers put ruby to force the pronunciation of characters in an unusual way.
... In those cases we don't allow the user to turn the ruby off.
... Here are examples of some control settings. I'm sure there are other things publishers want to control and users want to control.
... Theoretically-speaking we could enable all controls on both sides, but by doing so usability will decrease rather than increase.
... If the user understands what they are changing, then it's ok. But if not then usability is reduced.
... There are some cases where contents are intended for vertical layout, and the user changed to horizontal layout, and didn't like the way it looked and complained.
... Users are kinder than you think. They gave us lot of advice.
... They continue to give us lots of advice, or, complain to us.
... It's difficult for us to turn around and say it's your settings, it's your fault.
... So we try to make it safer.
... As a result, we create terminals and we tend to get opinions that say our terminals are very boring. We cannot set anything, we cannot customize, they are very boring machines.
... There's another major issue that is display by different viewers.
... As I've been explaining, we create the format and distribute the format and manufacture terminals as well.
... It's an old business model.
... In our business if the customer complains, then we take responsibility.
... Now, as a result of standardization format, the format became free.
... Anyone can create content and distribution, and I think that's a very welcome change.
... I think there'll be some challeng eas we discussed in the morning session.
... Ok, we have standardized format, but there'll be variations in implementation.
... because of differing interpretation of the format by different vendors.
... The classic example is the different viewing experience problem with the web browsers, which is not entirely resolved.
... People create contents base don the stnadard, but when displayed in one web browser looks ok but displayed in another browser doesn't work
... We are starting to see similar problems again with different terminals.
... As for mobile phones, especially for Android, we already have WebKit and that's a de-facto standard.
... So we have expectations that this WebKit will create standards for e-publishing.
... I actually spoke about HTML input function, and we are faced with problem that if we use this function, even on the same smartphone terminals the view looks slightly different.

s/terminals/terminals category/

Hanada: This is due to sometimes different versions of webKit, and sometimes vendors have altered WebKit
... Technology advancing is a good thing, but at the same time we always continue to have terminals that are old and cannot be updated anymore
... when these different versions exist we will continually face the problem of making things look the same in different terminals.
... This is one of the reasons why we cannot advertise more the HTML input function.
... This function is mostly ok, but for ebooks where exact reproduction is important, it's not adequate.
... That's why we aren't marketing this, we want to market it in a more controllable size and scale.
... .. exaclty reproduce wha twe were doing in paper, .. electronic is electronic so it can be different
... SO about this point I would like to hear your opinions too.
... This brings me to the end of this presentation.

s/SO/So/

jdaggett: My name is John Daggett from Mozilla.
... You said there were some issues with the display of fonts, what exactly were the issues.

Hanada: I think you're probably talking about when I mentioned there is only limited numbers of fonts that can be installed in mobile phones.
... I say this is a problem because every time a private character comes in it creates a bitmap. It would be best to use a real font, but because of the limitaitons of the mobile phone we haven't arrived at that yet.

Ashimura: My quesiton not directly related to layout, my question is related to copyright issues.
... When we deal with comics, also can be text materials, but particularly comics.
... Youre technology can change dynamically the presentation of the content, setting vibrations, turning ruby on and off.
... I'm wondering if changing such things is a problem for copyright.

Hanada: Apart from the legal issues, I'm not sure of the legal issues, but frankly if we had such effects as we explain, the publishers will tell us off.
... We ask the publisher and display per their instructions. We never change anything.
... this isn't a quesiton of what is good or bad, and environment will change in the future.
... Google started audio reading of the text, and it was very controversial and they had to stop it
... ...
... Thank you very much. We are out of time. If you have further questions, come to the secreteriat and ask the question through the secretariat

<glazou> hello !

RRSAgent: pointer

<glazou> everything ok in Kyoto ?

glazou: afaict, yep
... minutes up there *points*
... we're on break for 10m

<glazou> ok

<glazou> beginning of day here

^_^

<r12a> wow! how do you do that ?

<glazou> do what ?

<glazou> not here

<glazou> yep

<glazou> what's your irc client ?

<r12a> colloquy

<glazou> hmm

<glazou> me too but I get the usual smiley

<r12a> hmm, interesting

<glazou> could depend on the theme you use

<glazou> Preferences > Appearance

<glazou> aaah wait I don't have last version

<glazou> you have probably 2.3

<glazou> let me upgrade right now :-)

<glazou> back in 2.3

<glazou> test :-)

<glazou> nothing :-)

<r12a> nothing for ^_^ either ?

<glazou> hmmm

<glazou> retest

<glazou> :)

<glazou> sigh

<glazou> aaaaah

<glazou> it's the emoticons "standard" style

<glazou> I was in iChat style

<r12a> yep, standard

<glazou> yeah I see a girl's face

<r12a> heh

<glazou> ;-)

<r12a> ;-)

<glazou> so emoticons in Colloquy have gender ? :-D

</br>

<dbaron> Taichi Kawabata (川幡太一), NTT Corp.

<dbaron> s/Kawabata/KAWABATA/

Kawabata: Because of my involvement in standardization process for IVD, I've been invited to speak here.
... I'm going to explain character and font-related topics that may affect standardization of CSS3.
... Let me apologize because I prepared my presentation for 1 hour, but since we have simult translation I might run out of time.
... Let me explain current status of private characters in fonts.

Private Characters and Font Formats

Slide: Unicode does not encode idiosyncratic, personal, novel, or private-use characters nor logos nor graphics.

Unicode reserves 6400 codepoints in BMP for private-use, and also another 130000 are available outside BMP

Slide: Private Characters

Logos, emoticons, etc.

<dbaron> "Note, however, that the Unicode Standard does not encode idiosyncratic, personal, novel, or private-use characters, nor does it encode logos or graphics. Graphologies unrelated to text, such as dance notations, are likewise outside the scope of the Unicode Standard. Font variants are explicitly not encoded. The Unicode Standard reserves 6,400 code points in the BMP for private use, which may be used to assign codes to characters not included in the repertoire

<dbaron> of the Unicode Standard. Another 131,068 private-use code points are available outside the BMP, should 6,400 prove insufficient for particular applications." (Unicode, 1.1)

Kawabata: In books, special symbols are sometimes used to convey the complex or abstract idea in a simpler manner.
... Also emoticons used in Japanese mobile phones are not encoded yet.

<dbaron> [image of book of john in Greek, with lots of annotations]

Kawabata: Regarding Kanji characters, already 75,000+ are encoded under the Unification rules
... However if you look at dictionaries or some scientific papers, there are still more that are not yet encoded.
... There are reasons for those characters not to be encoded, e.g.

* misdescribed

* invented

* (very) local

* historic/short-lived

Kawabata: Kanji characters are often invented. If invented by a famous author they might be encoded, but are otherwise not encoded.
... Here is a book from late 19th century. The government in Japan issued a dictionary with vocabulary of new introduced legal terminology
... They introduced several hundred new kanji for those vocabulary
... However those new introduced characters have never been used.
... In other cases we have other characters not in use
... Regarding private characters, there have been discussions of how to render those characters in HTML.
... Based on discussions we have this week, there are five issues.
... These are the classifications of those five emthods to render private characters. Each has different profiles, whether they have ? or not, whether they are searchable or not, how many available, etc.
... In order to utilize private character, must think about font format for private characters.
... With HTML and CSS3 you can include the font files
... There are three formats which can be implemented or embedded into HTML.
... OpenType, WOFF, SVG
... Each font format has pros and cons.
... OpenType is most popular, but has large size.
... WOFF has smaller size, tailored for Web use
... The SVG is different to other types. You can convert SVG into a font.
... SVG is different in that it's possible to use gradation, color, animation.
... Also SVG font can be embedded into HTML and can also inherit CSS
... However the SVG is not supported by all browsers
... And EPUB ??
... When it comes to how to render those private characters, I'm going to show you a solution.

<dbaron> slide shows http://glyphwiki.org/wiki/u26f97

Kawabata: What I'd like to show you is the glyphwiki project.
... Everyone can register his or her own characters.
... Once you create a new page and put that glyph, then the font will be automatically created from the glyph
... Nearly 100,000 characters are registered
... And base don this, about 1 month ago Hanazon-Mincho, a new font became available
... This is only one free font that can .. all UCS/AJ1 ideographs

<dbaron> s/Hanazon-Mincho/Hanazono-Mincho/

Kawabata: This one on the right is the glyph created for UCS
... With private characters ther eis a challenge of how to deal with vertical layout
... When it comes to vertical layout, whether you rotate the charater or you rearrange vertically based on ... gsub
... When text-orientation is vertical-right, set characters upright (using vertical font settings ) unles sotherwise specified above.
... In OpenType (quoting from spec here) ...
... Now go over IVS and font selection
... IVS stands for Ideographic Variation Selector

<r12a> s/Selector/Sequence/

Kawabata: IVS enables to display ideographic variance by ...

<r12a> s/Sequence/Selector/

Kawabata: In the past Unicode only specifies the abstract character, however IVS can specify concrete glyphs
... In order to use IVS you need to register IVS into IVD
... Regarding the way to register IVD, that is specified UTS 37
... If a registrant wants to register a variant into a registrar, which is currently the Unicode Consortium, first you need to register your collection
... Once you register collection, then you can register glyphs ... as many times as you wish
... ...
... In the IVD_Collections.txt, ... register into IVD_Sequences.txt
... Currently two colections are registered: Adobe-Japan1 and Hanyo-Denshi

<r12a> s/Selector/Sequence/

Kawabata: These tow collections are implemented in some fonts
... However these two collections do not match always necessarily

<dbaron> shows image from http://d.hatena.ne.jp/NAOI/20100406/1270550459

Kawabata: This is one example where the collections don't match
... I've taken this information from ?'s website
... Blue boxes are from AJ1 and red one are from Hanyo-Denshi
... This is one specific chinese character. As you see, some of them match, but they don't always match
... How are people using an IVS? There are two main usages
... One usage could to show a archaic style
... Another purpose for IVS is to correctly display proper names
... Let me explain using an example.
... For example if you have this kind of older text
... And if you apply an IVS, you can make a little bit more traditional
... So if you compare the characters you can see differences
... If you have a font that supports the IVSes, you can convert the document into a classical look
... Here's an example where IVS is used for proper names
... These for example are all different names using Chinese characters that can be pronounced the same
... But if you look at the chinese characters, they are a little bit different.
... ... small differences in a person's name
... Another case for example, Katsudaku City and Katsudaku Ward (sp?)
... Although pronounced the same, their Chinese characters are different.
... If you press delete key to delete the IVS (in emacs) then you see the character conert

Kawabat: Now a different topic, CSS has the font-matching algorithm.

Kawabata: For example if you specify 3 fonts in font-family value

Side: font-family: font-A, font-B, font-C

Kawabata: And you have a sequence like this

Slide: C1 C2 C3 C4 C55

Kawabata: The best font will be picked in the font-family in thes order
... Here there are two different text decorations.
... One decoration is done by CSS, for example converting this character into bold face
... Other time if you use IVS you can convert same characters into it svariant.

s/it sv/its v/

Kawabata: If you want to show the character that is not supported by IVS, you have to go through font fallback
... By combining CSS and IVS can you make it boldface for variant, or does it change the character?
... IVS and font-selections, there are various arguments.
... Now I'm going to go into a technical deep discussion.

Slide:

font-family: font-A, font-B, font-C;

font-A supports only base characters

font-B supports IVCx

font-C supports IVCy

Consider sequence

C1 IVSx (∈IVCx) IVSy (∈IVCy) Cy

Kawabata: In which font family should the ... render in the web browser?
... Option A is to render all those characters using the base characters
... Option 2 is to prioritize characters which are specified in the IVSx or IVSy
... These two options have pros and cons

s/2/B/

Option A:

Pro - whole text has a consistent font-fmaily

Con - multiple IVC fonts can not be supported

Option B

Pro - each IVS will be rendered with a supporting font

Con - Text may be displayed in inconsistent font

Kawabata: If you choose option 1, it is difficult for user to display each IVS , font family must be specified in eac IVS

<r12a> s/C1 IVSx (3IVCx) IVSy (3IVCy) Cy/C1 IVSx (∈IVCx) IVSy (∈IVCy) Cy/

Kawabata: Under option B, it is easy for user to dsiplay only base character -- just remove VS characters

Normalization

<Bert> Kawabata: [explains NFD/NFC/NFKC/NFKD normalization]

Kawabata: Once you have normalization, then you can compare character strings
... Especially for CSS and HTML, the name of class ...
... And actually normalization has some challenges
... For example, implementation is very combersome, especially NFC
... Actually tried to implement NFC, but I have difficult time to do that.
... Another issue for normalization is the singleton decomposition
... This means different characters sometimes folded to the same character
... For example, Angstrom (U+212B / JIS X 0208) normalizes to A with ring above (U+00C5 / ISO8859-1 )
... Another issue with normalization is compatibility ideographs
... All compatibility ideographs will be transforme dto corresponding unified ideographs
... Apple in HFS file, they do not normalize compability ideographs
... 10 years ago Apple proposed to Unicode to exclude the compatibility characters
... However this proposal was not accepted
... Ideographs are unified by unification rules specified in ISO/IEC 10646 Annex S
... However there are some exceptions.
... Before 1992, there were some separately encoded

e.g. U+98F2 and U+98EE

Kawabata: These two are different characters meaning the same thing. But they were encoded before 1992, that's why they are separated
... ...
... Japanese Compatibility ideographs include name ideographs, shown in the bottom of the slide

Kawabata's slide shows characters that are variants of each other -- on is a compatibility ideograph

Kawabata: Another issue is when and where normalization should be implemented.
... In 2005 draft version of charmod 1.0
... Early Unicode Normalization was suggested
... It was suggested to put this in HTML
... But if you implement this, we might lose the specific Chinese characters, e.g. for a person's name.
... Such an issue understood by many people

<r12a> http://rishida.net/scripts/uniview/?charlist=%E9%A3%B2%E9%A3%AE click on characters to see large

Kawabata: I personally hope that EUN will not be adopted for HTML
... But I'm not against all normalization for HTML
... I suggest normalization for ID, class, and URL for example
... But this is an example from XML appendix J
... Many types of values can be normalized
... Given difficulty of implementation, e.g. NFC, it's not a good idea to normalize those values like ? attribute
... My personal opinion is that for web browsers, NFKC is more useful
... By having this normalization, you can search single-byte katakan by using double-byte katakana
... Or even you can search .. characters by separating characters

(example of searching Liter ligature with Liter)

Kawabata: ... for example you can't search old Kanji charaters by using newer Chinese characters
... So we need a new method to make searching for old and new characters
... Ok, that is my end of presentation.
... Thank you very much.

jdaggett: You showed a slide that was very complicaed
... That used IVSx IVSy
... This is not a problem that any author should ever have to deal with.
... This is a problem because of the way the Hanyo-Denshi was registered.
... You have two selectors that specify the same glyph
... And you have fonts that support only the Hanyo-Denshi selectors and not the AJ1 selectors.
... There is *no reason* the author should *ever* have to insert two selectors because there's a problem in the font.
... Also a problem for implementers. I just want to ask the font if it has the right glyph and get the right answer.

<dbaron> (AJ1 == Adobe-Japan1)

Kawabata: Idea of 37 was that different groups want their own collection, their own set of variatns. So there's a concept of collections.

jdaggett: For the same glyph, why do you need two selectors.

Kawabata: It's very difficult to see if the glyphs are really the same or different

jdaggett: But it's very hard for authors, too.

Kawabata argues that it's a lot of work to check if the glyphs are the same or different

Nat: I would never support all these different collections. As a developer I will only pick one, and I'll pick the one that's easiest to support.
... It's not easy for me to have knowledge of your database.
... my renderer should have no need to understand you rdatabase
... And content creators should need to have even less understanding of your database
... If you don't do this, then font fallback will fail, and you run into all kinds of problems.
... And it ties to the politics of the font vendor and the registrant, and all of those issues are being foisted on the content creators.

jdaggett: This feels a lot like going back to encoding problems of the 80s in Japan, where Hitachi has their own vendor codes and Fujitsu has their own vendor codes, where if Fujitsu made it then Hitachi can't support it.

Nat: The compatibility characters are an obsolete way of handling the same problem that IVS solves much more elegantly.
... I'm very confused by the normalization discussion, because normalization is by nature something that is a lossy converion.
... Why do they think that they're losing something?
... If you're destroying data by normalizing, then that's a bug.

Kawabata: Normalized data should be used only for comparison, not for circulation. That makes for data loss.

Yamamoto from Adobe: I agree with the last part of what ? said, normalization itself has no bad thing, but how to use it needs careful attention. If there is misuse or abuse of normalization it's wrong.

Yamamoto: I agree that IVS is a better approach and we should use it.
... For this reason, compatibility characters should only be used for guaranteeing round-tripping with a particular national standard. Other usage is strongly discouraged.
... Two points that Nat mentioned: wrt compatibility characters, he told the history and value
... On the other hand the stnadard 10646 for this reason compatibility characters should only be used for guaranteeing rount-tripping
... ... multiple IVSes from multiple IVCs, tries to keep .. where one single IVD collection completely works, but even if there are other collections he doesn't seme to care about the interoperability of multiple IVSes from multiple IVD collections.
... Similarly he is trying to keep this closed world where compatibility ideographs are perpetually represented by ? systems
... There is always the other world of Unicode where we have attached importance to keep the interoperability of text communication worldwide.

Kawabata: let me share my thoughts on those issues
... One comment wrt compat characters, he said that I am focusing on the round trip and that's only in closed word, not open to outside world, that's his comment.
... Well I myself, Unicode is one big platform where text communication is conducted
... Therefore within this big platform that's also contain the regional standard, therefore text communication is possible based on regional standard as well
... And therefore by using Unicode as a ? ppl communicated by using regional standard or subset by agreeing each other themselves (?)
... So well what I'm thinking is that we should not do something .. of those ppl who already have text communication based on regional standard subset.
... Another point wrt IVD , it's been pointed that characters registered in different collections that would be costly.
... Now we only two collections, but looking ahead there might be various people who want to register their collecitons for specific usage.
... Of course ther's an argumen that if you have the same wrods registered in different colleciton they must be unified
... Our concern is that .. people who want to register a new colleciton must search all the existing collections

Yamamoto: There are IVD collections by national Japanese, others for local governments.. similar situations.
... The registrant's intention doesn't matter. look at the glyphs. If they look shareable, after some research, maybe we can agree that a pair of glyphs can be shared, then those glyphs should be shared.

[bunch of discussion in Japanese]

?: I've received requests from Buddhist texts for example, so I can't say that we should unify the whole collections.

i/Nat McCully (Adobe)/ScribeNicK: fantasai/

RRSAgent: make minutes

<r12a> ok, i'll dial in

RRSAgent: make logs public

Ashimura: ...
... W3C is an industry consortium created by Tim Berners-Lee
... W3C has 3 hosts: MIT, ERCIM, Keio University
... One Web! That means global, accessible, implementable.

nmccully: Natasha Indik <tindik@Princeton.EDU>

Natasha Indik <tindik@Princeton.EDU>

http://www.w3.org/2011/06/01-css-minutes.html

THere we go

s/Natasha Indik <tindik@Princeton.EDU>//g;

Ashimura gives an intro to W3C

Ashimura: Feedback from Tokyo Forum
... e-standards is complicated and controversial
... We need to start with actual use cases, I think
... In Tokyo we asked e-Publishing stakeholders for requirements and use cases
... The theme of the session in Tokyo was, What is needed for Japanese text layout on Web browsers and e-Books
... Each panelist introduced their own products and services. The process of their products and services were discussed.
... Discussed what was needed, what do we want to do using Web technology?
... Feedback from browser vendors, for example Access, the Japanese vendor,
... EPUB(HTMl+CSS) is a platform for publishing
... Current latest specs already let us use a certain level of epub documents with Japanese layout.
... However there is no free stable implementation for the latest specs
... So they are making an implementation based on WebKit and Google Chrome source code
... But it has some issues, especially wrt Ruby and so on
... Next, from signage viewpoint, this viewpoint was provided by [Kata?]san, Newphoria
... Very big fonts are needed for advertizing etc.
... Restriction based on hardware: number of characters, resolution, display size, etc.
... Difficulty of Japanese text layout on big display is difficult,
... e.g. 12 displays concatenated as a huge display
... That kind of concatenation or linkage between displays is important
... From Web designing viewpoint, including various text provided by customers
... It's very difficult to justify the start/end point of characters nicely
... Sankei Digital ^
... Actual style depends on device resolution
... Toppan generates magazines, novels, picture books, dictionaries
... They have issues with quality of text layout and fonts.
... They said they would like even more beautify layout

<kojiishi> Ashimura san's slides available at http://www.w3.org/2011/Talks/0601-web-and-japanese-layout-ka/

Ashimura: Feedback from Audience

Slide:

* Important to consider spacing, inter-character/inter-line

* Ruby for pairs of kanji (jukugo) is important

* Dealing with text layout space is important

* stronger collaboration with SVG would be useful, e.g. SVG fonts and animation

Ashimura: Today we're holding a dedicated forum on CSS

Ashimura shows a flowchart

Start box is JP, China, Korea, Taiwan, etc. Points with 'Use Cases & Requirements" to box labelled "This Forum"

"This Forum" branches into CSSWG, SVGWG, HTMLWG, I18NWG

"Japanese Layout Task Force" stretches across all of them and generates "Requirements for Japanese Text Layout", which feeds back into those WGs

The WG's each generate specs

CSSWG -> CSS specs, etc.

<r12a> diagram is here: http://www.w3.org/2011/Talks/0601-web-and-japanese-layout-ka/#[15]

Ashimura: Next steps should be bringing these requirements and the JLREQ requirements into working groups, including CSSWG
... They will discuss how to implement (or not implement) those requirements.

Ashimura shows slide "Please join W3C!"

and encourages participation

Ashimura: I'd like to ask you all about this main theme: what is needed for Japanese Text Layout for the Web and e-Books?

[Commenting on slides in Japanese]

Tada: I haven't organized my thoughts yet, but looking at morning sessions especially Access's presentation
... I thought some of those layouts would be useful for signage
... Tada: ... larger fonts and display could be used for other purposes, and wondeirng if CSS can be used .
... We are creating engines, can we use them for other effects.
... For CSS, can we set up standards in a way that are extendable so that it can be used for various purposes
... We were showing that presentation wondering if that could be used for other purposes

actually, I'm not sure who that was that was being translated

Maybe it was someone else..

Ashimura: Question for the audience: We received an opinion from Ichijo of Sankei that it's very difficult to display Japanese fonts in a ? way
... So I think this question covers the issue of fonts, and also issues wrt spacing
... And I have English on the side, maybe this because I'm not English speaker, but for some reason this English looks better to me
... From native English speaker's POV, can't tell if English looks better than the Japanese

Nat: Neither is good.

<Bert> (I think that "someone" from above introduced himself as Yamamoto (sp?) from Alliance.)

Nat: In the case of Roman composition, unless it's a very fine composition.. in this resolution it looks ok.
... For example, the end ... are not using proper ellipsis
... On the Japanese, the brackets and dots are not good at all.

Ashimura: The reason I ask this question to Nat-san, is Ichijo-san says Japanese layout does not look good.
... Sounds like English native-speaker's POV this doesn't look good either.
... It's an issue of making things look good on the Web.

Yamamoto says a lot of stuff.

Yamamoto: Even in Japanese, large headers or and advertisement, you usually use hand-kerning or proportional spacing (OpenType)

fantasai: Japanese needs measures that are a multiple of an em, otherwise justification results in very loose lines
... For CSS, that might mean being able to make the the width snap to a multiple of some length.

Nat: That reminds me of something I said in the Tokyo forum.
... [Something] is not as important as [something else]

<dbaron> Nat: the placement of ... is not as important as the placement of the lines within the frame

Nat: In InDesign, the Japanese grid helps with the width of the line
... If you use a frame grid, which is what we call the Japanese grid, to create the frame for the text
... Then you will have an even number of ems
... However inside the text, there will be times when you have text that doesn't exactly fit inside the grid.
... And then you need to adjust the spacing.
... When we did research early-on in InDesign's development cycle
... We found that in Chinese text, there was a desire to return the grid as soon as possible as soon as you had got off the grid.
... For example, if there was Chinese text then roman text then Chinese text, you would make spacing decisions to return to the grid as soon as possible.
... We found that in the early phototypesetting systems in Japan, we found that there were some house rules or conventions whereby they would have within the last few characters they would be on the grid
... However, most of the users thought that that made it look like very old 1960s-style publication
... However, my personal opinion was, I was very excited to hear this and wanted to make this happen in InDesign
... But I'm the only one. :)
... Instead what we did was, we decided the adjustment in the line between the two edges of the line would follow a more sophisticated spacing rule
... And it should be the same whether or not there was a grid.
... Therefore the grid in InDesign is used mostly to position the y-position of the line

<r12a> s/defined in CSS/defined in CSS3/

Yamamoto: The role of the gird is to specify the lenght of the line and also the inter-line space
... What happens within the line is a separate discussion.
... For example if we have 32 characters per line
... We might have Japanese proportional setting to set the alignment
... But you can still revert to no spacing.
... As long as you revert the proportional setting, you can go back to solid setting
... When you specify proportional, each character has its own width. Uses font's alternate metrics
... So Japanese characters look like Roman characters. But even in that case we should use em-based grid to define the line lenght so that we can restore the original solid, non-proportional setting of the type group.

Ashimura: Now I'd like to ask your opinion. Nat discussed this from Adobe point of view. Now I'd like to ask web browser point of view

jdaggett: I'm not as knowledgeable as Nat, so I can't answer your question in a very knowledgeable way. But one thing
... In conventional Web browser technologies, we don't really use OpenType data.
... We use WebKit because we like to display things quickly.
... But not good for quality

szilles: There's a number of cases where the quality of typography we see on the screen is perfectly adequate for that use case.
... But there are also use cases, particularly in advertising, where the quality of the image being projected is important
... So the average user is not required to specify in great detail the typographic constraints
... But the controls are there that someone looking for higher quality typography can get that by specifying additional properties

Iksei: I've been involved in Web and printing for many years

Ikusei: Is it possible to have shashoku and shaken apart from CSS or in addition to CSS?

<r12a> what are shaken and sashoku ?

some discussion that doesn't really make sense without any context

Ashimura: There are activities that use XML and ? to use things that are similar quality as paper printing

Nat: In talking about something other than CSS, it's useful to make the distinction between the rendering technology and the market that technology consumes
... For example we have quite a nice text engine in Flash Player
... Flash Player uses something totally different from CSS and HTML.
... You can tell it to render text and animate it with ActionScript
... The mojikumi in that string can be controlled much more precisely than with HTML and CSS
... However, the point of evolving the standard, CSS and HTML, to improve their support for this kind of high-end typography is so that everyone can make use of it in more open technologies like the various browsers.
... So, as to your question, I assume that you're talking about the rendering side rather than the markup side.

Ashimura: Unfortunately we have to close the session. I recommend that you come and join W3C directly to continue the conversation.

<r12a> elika, how many people in the room ?

4*7*3+~7

About 110?

<r12a> wow

Closing remarks.

<myakura> r12a, iirc shashoku means phototypesetting and Shaken is a shashoku system vendor

3 per table, 28 tables

plus some standing

<r12a> doumo arigatou, myakura-san

or in the front

<dbaron> but a bunch of empty seats too

oh, they're all behind *you*

yeah, about 100

Koji: Using this forum as a starting point, we would like ot have more opportunities to learn from you

Forum closed.

<r12a> thanks for the panorama

<r12a> hello to all

<r12a> wishing i was there !

<r12a> dbaron, i just turned my video on

<dbaron> r12a, ah

<dbaron> anyway, 'later

RRSAgent: make minutes

- DRAFT -

Kyoto Forum on the Future of CSS for Asian Text Layout

01 Jun 2011

Attendees

Contents

Private Characters and Font Formats

Normalization

Summary of Action Items

Scribe.perl diagnostic output