W3C home > Mailing lists > Public > www-style@w3.org > June 2011

[CSSWG] Minutes: Kyoto Forum on the Future of CSS for Asian Text Layout

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 15 Jun 2011 17:19:03 -0400
Message-ID: <4DF921C7.6070600@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
<RRSAgent> logging to http://www.w3.org/2011/06/01-css-irc

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
   Nat: In 1998, most fonts don't have this. Each product had to do
        calculations for it.
   Nat: ...
   Nat: Once you have ideographic embox built into line layout engine,
        you can support other concepts
   Nat: e.g. leading direction -- whether leading is forwards or backwards
        wrt line
   Nat: If you have two lines and you set leading, which one will move?
   Nat: Leading measurement points, or baselines, is from where in the line
        do you measure from
   Nat: When you have multiple font sizes in a line, changing this reference
        point changes the spacing between lines
   Nat: Lastly, if we have time I can talk about Mojikumi spacing. Refers
        to adjustment of space around punctuation to achieve good full

   Nat: So, when laying text out on the screen, you generally have margins,
        and in both CSS layout and InDesign you decide the LTRB margins first
   Nat: within which you want to layout a text line.
   Nat: 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
   Nat: Within the line box, we have a calculated line height
   Nat: In CSS this is equal to the leading.
   Nat: For example, if you have this text (shows some text in English)
   Nat: You get the ascent and descent from the font metrics to calculate
        the text height
   Nat: And you place it somewhere within that line height

   Nat: So, let's depart a bit from CSS and talk about InDesign Roman
   Nat: 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
   Nat: Second line uses 100% of the leading *of the second line*.
   Nat: So the line leading direciton is upwards in this case.
   Nat: Notice that each line's y position in the frame is equal to the
        Roman baseline.
   Nat: You can see that the descender of the second line is hanging outside
        the linebox.

   Nat: So, how did I change this for Japanese?
   Nat: In Japanese composition, you need to do some different hings.
   Nat: You have your line box.
   Nat: And you have text placed within that line box
   Nat: And then you have your second line with its line box, and then
        text inside that one
   Nat: The first line offset is set to the embox height
   Nat: OpenType fonts have an 'ideo' baseline.
   Nat: This was added so that the font designer can tell us where the
        Roman baseline is wrt the embox
   Nat: The second line offset is the embox height of the second line
        plus the previous line gap.
   Nat: 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
   Nat: when setting leading
   Nat: So in developing the EPUB layout engine, I've been working with
        experts at adobe to tell me how conventions are followed in CSS.
   Nat: And so when placing text within the line, we first get the metrics
        from the font
   Nat: 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.
   Nat: When I first saw this, I thought, what a problematic way to do
        text layout
   Nat: because you cannot predict where the text will be within the line box
   Nat: This is especially true when you have different font sizes
   Nat: 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
   Nat: So, suppose we have some different-sized text within the line
   Nat: 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.
   Nat: The line height increases as you add text.
   Nat: The baseline moves down, but the calculation is not straightforward
        if you want to get an exact pixel position on the screen.
   Nat: In InDesign, when you have different point sizes, such as in this
        Japanese run
   Nat: We get the text metrics as before
   Nat: ...
   Nat: The Japanese text has a particular relation to the roman baseline
   Nat: 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 Japanese 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.
   Nat: The main problem I have right now is leading being added above and below
   Nat: I have a proposal to solve it, but it has some drawbacks.
   Nat: In Japanese two major baslines used are embox center baseline
        and embox bottom baseline
   Nat: 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?
   Nat: In InDesign we have two different grids.
   Nat: First is the Roman baseline grid.
   Nat: This grid is in both Japanese and Roman InDesign.
   Nat: In Japanese InDesign we added a different grid.
   Nat: 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
   Nat: The first run is bottom-aligned to the centered text. The second
        small run is top-aligned wrt the centered (bold) text.
   Nat: When the text is placed wrt the grid, it makes for a more pleasant
        reading experience.

   Nat: So to summarize, the Japanese grid has several purposes
     1) Sets the frame size to fit the grid
     2) Positions lines in the frame regardless of font size to fit the grid
        (snaps like baselines e.g. embox centers)

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

Koji Ishii

   Koji: I will talk about the Tokyo session and ideas and opinions presented
   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
   Koji: City of Hiratsukashi has been distributing PR brochure in EPUB since
   Koji: In Hiratsuka in order to reduce file size, they are using CSS3
         properties such as border-radius
   Koji: And also they are hoping to be able to change the layout depending
         on the device/orientation
   Koji: They're not using Ruby because it was unstable on some terminals,
         so they are using brackets

   Koji: Next panelist we had was person from Toppan printing company.
   Koji: One of the first requests that Toppan person made was that they
         wanted to define box sizing by number of characters and number of
   Koji: Also, in terms of line-breaking rules in CSS3 Text, they want to
         specifically designate certain characters for line breaking rules
         (by codepoint)
   Koji: We also discussed line notes (warichu)
   Koji: The comment they raised is how are we going to treat these in Web
         and ePublishing
   Koji: The request comes from the fact that some people would like to
         publish things like this in electronic formats
   Koji: Question is whether something like this can be done in electronic format

   Koji: Also, Toppan Printing made comments about so-caled private characters.
   Koji: Unicode is so well-spread today. They found 1200 chars in Ko-jien
         dictionary that are not in Unicode.
   Koji: They searched 800 books, 1400 chars (0.6%) are not in Unicode
   Koji: So they also said that in archaeologists excavate, every year discover
         about 30 new characters.
   Koji: For EPUB we use WOFF/OpenType, but according to Toppan SVG fonts
         are easier to create. They suggest supporting SVG, too.
   Koji: Discussions about font and private characters will be covered deeper
         in session 4.

   Koji: A person from company Voyager was a panelist
   Koji: As you probably aware, they developed ebook reader and marketing it
         since 1993
   Koji: Voyager person made a point that in general Japanese literature you
         can often see mixed writing modes.
   Koji: This is a cover page.
   Koji: Then the table of contents follows
   Koji: And next is section heading, typically vertical writing to
   Koji: Main text is normally all vertical
   Koji: And back matter is normally horizontal.
   (cover page was also horizontal)
   Koji: They raised some questions.
   Koji: One was whether mixed mode can be used in EPUB
   Koji: Whether change in progresion is possible for section heading

   Koji: Other point the Voyager person made was that we may need to review
         some line-breaking rules
   Koji: 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.
   Koji: In fact, Voyager person said they implemented different line-breaking
         rules than the ones in JIS, wrt inseparable characters and also some
         other elements such as grouping (?)

   Koji: And some comments were made about possibly user-switchable text-flow.
   Koji: Voyager's readers have always supported vertical/horizontal switching
         by the user.
   Koji: concern that this will increase cost of content development.
   Koji: 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.
   Koji: 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.

   Koji: The other request that Voyager made was about old chinese writing
   Koji: Their understanding is that kanbun writings are often included in
         textbooks, so they should be supported.
   Koji: In terms of how to support this in CSS/EPUB, needs further discussion.

   Koji: Next panelist we heard from was from Impress R&D
   Koji: They publish a magazine called [??]
   Koji: They're publishing on Web, printing, and ebook.
   Koji: They're separate in production, on an experimental basis
   Koji: Basically the question is, when they have one set of contents, how
         can they change the style and layout for different formats.
   Koji: They also made a point that in carrying out such experiments, they
         discovered that some implementations are behind.
   Koji: In terms of logic, it sounds correct, but in reality did not work.
   Koji: One particular example was that SVG and MathML and fonts in vertical
         writing did not work well

   Koji: Mainichi Communications spoke too.
   Koji: In their company they're publishing in PDF.
   Koji: One of the benefits of using PDF is that they can use the content
         with paper printing, so the production cost will be low
   Koji: But it is hard to read, especially on small devices.
   Koji: 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.
   Koji: Their two requests that they made in terms of publishing future and
         for the web
   Koji: 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)
   Koji: They're particularly concerned about color
   Koji: Especially when the publish things like photo albums.

   Koji: Asahi Newspaper
   Koji: They started browsers/iPad/Android services in May
   Koji: Technically speaking, such services are based on HTML5/CSS3
   Koji: One of the greatest reasons for using HTML5/CSS3 is that they are
         compatible with video and multi-column layout
   Koji: Because there are some old PC browsers that aren't using HTML5,
         they aren't using HTML5 for PC
   Koji: In terms of design, they are using totally different design than
         non-prepaying Asahi.com
   Koji: One thing that they hope to do is make this fee-paying service much
         more like real newspapers
   Koji: using boxes and multi-column layout
   Koji: Also if we look at conventional news websites, because the text is
         so small, they are very hard to tap with fingers
   Koji: 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

   Koji: What they also hope to do in the future, they attach particular
         importance to their own fonts.
   Koji: But the file sizes are too large for users to download
   Koji: In terms of Gaiji or private characters, what purposes do we need
         private characters?
   Koji: Obviously proper nouns such as people and place names
   Koji: Also the other great source of need is political parties, making
         iconic-square ligature (kumimoji)

   Koji: that's it for reports from Tokyo session.
   Koji: 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
   Ashimura: Asahi said that validation is very difficult. Validation itself
             is not difficult, but fixing errors is difficult.
   Ashimura: Do others have a need to make these functions easier?
   Ashimura: Comments from audience?
   Koji: How many are creating content in EPUB?
   several raise their hands
   Koji: How many use EPUB validation tool?
   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
   Mitsubishi: For EPUB, it's just started now. We don't need anything right
               now, but in the future there will be many more validation tools.
   Koji: Any more questions?

   Hagimura: 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 electronic publishing.
   Koji: But as Asahi and ?machi person said, the current standards of CSS
         publishing is not good enough for fee-charging services.
   Koji: I'd like to hear your opinion, too, if you'd like
   Hagimura: As someone working on Web, I'm fed up with discussion that we
             have to be same as the paper.
   Hagimura: 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 ? person said, if we are going to publish some
         kind of graphic services we need better color calibration. Also
         in terms 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.
   Nat: We have PDF for that.

   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.
   Nat: One of the problems we keep hearing over and over is that ruby
        increases the line height.
   Nat: The consensus was to add a boolean to choose which behavior you wanted.
   Nat: 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
   Nat: The conventions existed for a reasons, they existed because legibility
        and beauty of design has become refined on paper.
   Nat: We can take that refinement and adapt it to the Web.
   Nat: 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.
   jdaggett: I guess it seems like a counter to some o the stuff you're saying.
   jdaggett: Fixed line heights are great, but gives the author opportunity
             to shoot themselves in the foot and make line heights that collide
   jdaggett: 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.
   Nat: So this problem is I think extremely important for the Web, and less
        so for print.
   Nat: Although in print we had similar problems in the early days
   Nat: Layout was unpredictable depending on fonts.
   Nat: 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.
   Nat: 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.
   Nat: 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.
   Nat: CSS3 Text leaves too much up to the UA.
   Nat: But your question makes me feel very positive about the outlook and
        I think we can definitely work on it.
   Koji closes, everybody claps.

Masaki Yamabe (Alliance Port)

   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.
   Yamabe: Let me introduce what we do at our company. In addition to web
           designing we do .. DTP /logo
   Yamabe: We work with both analog and digital.
   Yamabe: As we discussed in first session, one of our challenges is how
           we make beauty of Japanese layout into web site.
   Yamabe: Now I'm going to share with you what we have done.

   Yamabe: 5 years ago in 2006, here is an example of vertical typesetting
           for Japanese layout.
   Yamabe: If you look back 5 years ago, there's almost no existing vertical
           typesetting implementation.
   Yamabe: We went through trial and error process, finally implemented
           vertical typesetting.
   Yamabe: What we did in 2006 was website for traditional Japanese inn.
   Yamabe: And please look at the screen on your left. On the top to the
           right is the vertical Flash.
   Yamabe: Flash is used on the top to the right.
   Yamabe: What we did for vertical typesetting you can see on the bottom.
   Yamabe: Simply describing the website, this a blog for Japanese and
           traditional inn
   Yamabe: First the managers or owners of the inn write the blog contents
           using the CMS Moveable Type
   Yamabe: The CMS text is converted to XML, which is set vertically with
   Yamabe: 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 the subject, we implemented the typeface to make
           some expression.
   Yamabe: If you look at XML version and the JavaScript version, you can
           see that the numerals are converted to Chinese numbers
   (date is converted and formatted: started out as iso, now in CJK)

   Yamabe: As I explained before, the CMS Moveable Type is used.
   Yamabe: The horizontal text from the CMS is rearranged vertically with
   Yamabe: Let me explain how we rearrange.
     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
   Yamabe: Need to replace characters e.g. for vertical brackets
   Yamabe: Also need to adjust punctuation mark position using position: relative
   Yamabe: For the numbers we developed source code that converted the numerals
           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.
   Yamabe: This is where the vertical script islaid out
   Yamabe: Here we have markup in HTML.
   Yamabe: We classified text into different categories, e.g. heading, main
           body, etc.
   Yamabe: We assigned an ID when we want to convert from horizontal to vertical
   Yamabe: Let me show you how we make this website
   Yamabe shows JS
   Yamabe: First you specify id of what you want to convert
   Yamabe: Then we assign parameters, using selectors
   Yamabe: For example if I delete an ID, then it's going to go back to
           horizontal layout like this
   Yamabe: These are the parameters that we can set
   Yamabe: First font-size by pixel
   Yamabe: glyphs per line
   Yamabe: line margin
   Yamabe: space between letters (glyphMargin)
   Yamabe: Also block Margin, will explain in detail later
   Yamabe: And you assign either true or false whether you want to activate
           or deactivate kinsoku (line breaking rules)
   Yamabe: So by setting these parameters, you change expressions in the
           vertical layout
   Yamabe: For example, if I change from 16 to 20
   Yamabe: you can really change the font size
   Yamabe: Here is an example, between first line and second line the
           line-breaking rules are applied.
   Yamabe: But if you set it to false, they will lay out without the line
           breaking rules (period can start a line)
   Yamabe: Here is just one line-breaking rules.
   Yamabe: You can specify which letters are subject to the line-breaking rules.

   Yamabe: Here I will copy a large amount of text into honmon area.
   Yamabe: It will make columns (that progress right to left across the screen
           and stack top to bottom down the page)
   Yamabe: Readers can simply scroll down.
   Yamabe: Margin between different columns are set here.
   Yamabe: Here we have 100px blockMargin, which will be applied between columns.
   Yamabe: Regarding font type and sizes, you can set them using the style sheet.
   Yamabe: This script is available in github
   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
   Yamabe: not using Flash
   Yamabe: 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.
   Yamabe: For example in 2008, we developed a script that enabled multi-columns.
           At that time CSS multicol was not available
   Yamabe: 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.
   Yamabe: We're using our automatic layout to develop a newspaper block,
           where we implemented vertical layout as well as the multi-column
   Yamabe: In this website once they write their text, the XML is then laid
           out as for a newspaper
   Yamabe: You have a vertical text heading, and multi-columns for the text.
   Yamabe: Regarding pictures, once the users upload the pictures
   Yamabe: The text flows around the pictures
   Yamabe: 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 2nd column is taken by picture.
         It is floated; the sentence from the bottom of the first column
         continues after the picture in the second column.
   (the picture is exactly the width of the column)

   Yamabe: Users can choose the size of the papers -- A4 or A3
   Yamabe: They can print them out into A4 papars
   Yamabe: Columns are common in DTP, but it was very difficult ot implement
           in JavaScript
   Yamabe: If you're interested in this newspaper blog
   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
   Yamabe: You are given a number of characters which you can enter into
           the newspaper.
   Yamabe: When the overflow happens, we have a magnifying glass so you can
           read the overflowing contents (???)
   Yamabe: 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
   Yamabe: It is then presented like a newspaper
   Yamabe: What we wanted to provide with this newspaper blog, we didn't
           want the users to write in a special language
   Yamabe: We just want users to make a blog, like a regular blog. The
           automatic engine converts their input
   Yamabe: We follow the progress on CSS development, but also enhance
           our own layout engine.
   Yamabe: Even though CSS3 is there, some browsers do not support.
   Yamabe: We will continue using both our own engine as well as CSS.
   Yamabe: Our objective is to make something enjoyable, like the layouts
           we showed you.
   Yamabe: ...

   Yamabe: Random typography, Fractal typography
   Yamabe: Here I'd like to share with you ...
   Yamabe: One of them is random typography. It was used for Design Language 2.0
   Yamabe: 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
   Yamabe: 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.
   Yamabe: This design on the cover is done by Yasuhito Magahara. He used our

   Yamabe: Before closing I would like to share with you another one, which
           is Fractal Typography
   Yamabe: This is artwork, which we exhibited at ? Newspaper Building
   Yamabe: I will show you a tape
   Yamabe: 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
   Yamabe: We tried to mimic that technology by using our own technology
   Yamabe: Each letter is sandwiched with <div>s
   Yamabe: From (a)esthetic(?) perspective, it's not so good. But the program
           runs very smoothly
   Yamabe: They are not necessarily readable, but we accept that.
   Yamabe: Japanese language is unique in that you can write both horizontally
           and vertically.
   Yamabe: When we created this work, it is enjoyable even if it's not readable.
   Yamabe: This is actually accepted by the audience as well.
   Yamabe: We used the ? newspaper typeface since we exhibited at the ?
           newspaper building.
   Yamabe: As for fractal typography, we expose the script, so if you're
           interested please ask me.
   Yamabe: Thank you very much.
   Yamabe: 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.
   Nat: This argument goes back and forth.
   Nat: As you can see, this layout is very nicely representing what normally
        we can see on a newspaper.
   Nat: 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 pixels
   Nat: And the top of the text does not align on the top of the picture.
   Nat: These types of details, it looks ok.
   Nat: If you can support putting this on the character grid
   Nat: And have the pictures be put relative to the character face.
   Nat: Even if the users can't tell you what they're looking at, they can
        appreciate the quality.
   Nat: The comments we get is that they won't pay for this.
   Nat: It's revolutionary technology to make this Shinbun blog. But wouldn't
        it be nice to go a little bit 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.
   Yamabe: ...
   Yamabe: Users that can't use InDesign can enjoy a newspaper-like blog.
   Yamabe: Let me share with use use case for this blog.
   Yamabe: In their class, they divided into smaller groups in one class.
   Yamabe: And they made investigation of ? products
   Yamabe: The Ministry of Agriculture and Forestry
   Yamabe: ... based on this campaign by the ministry, the schoolkids were
           sent out to make investigation of their local foods
   Yamabe: They went out to the field and looked for local products, like
           fish or crops
   Yamabe: They put those information into blog
   Yamabe: They are laid out like newspapers.

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

   Question on how to render vertical glyphs
   Yamabe shows source code, which converts to vertical presentation 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.
   <br type="lunch"/>

Keitaro Hanada (Sharp Corporation)

   <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

   Hanada: First, an introduction of our company shop
   Hanada: Sharp entered ebook business in 2001. Actually we had been working
           in ebook business before, but not started publishing yet
   Hanada: Our company originally has nothing to do with books or publishing.
           We develop electronic devices and mobiles
   Hanada: In that way, as the mobile phone terminals evolved, our ebook
           business has evolved accordingly.
   Hanada: When we started to provide services, we had PDA and also notebook PCs
   Hanada: First we started to deal with text, books and other literature
   Hanada: Around 2006, XMDF 2.* we started targetting mobile phones, too
   Hanada: PDA is mainly aimed at business customers. As you know, mobile
           phones are targetted at many more people, particularly young people.
   Hanada: As a result our targetted publications change from regular text
           to more comic books
   Hanada: initially, people wondered whether it would be possible to read
           manga on mobile phones.
   Hanada: of course not possible to display the whole page, but can show
           frame by frame and young people did not mind
   Hanada: Much of what we publish today is comics
   Hanada: Also, the tablets' function and performance have advanced, and
           we've started to see emergence of tablets
   Hanada: So our business started to focus on more high-perf terminals that
           can display e.g. magazine media
   Hanada: In 2010 we started to develop terminals specifically for book formats

   Hanada: One of the main pillars of our technology is XMDF -- ever-eXtending
           Mobile Document Format
   Hanada: XMDF technology is based on XML
   Hanada: 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
   Hanada: As for XMDF, there's a distribution format and execution format
   Hanada: Description format is standardized by IEC
   Hanada: One of the features of XMDF format, it has support for
           Japanese-specific features such as vertical writing, line breaking
           rules, and ruby
   Hanada: JP language support functions are not very special, not going to
           cover all of them

   Hanada: One thing I will talk about is float graphics.
   Hanada: We became compatible with horizontal/vertical switching from an
           early point in time.
   Hanada: So users are able to choose vertical or horizontal mode, and
           either way it provides a decent view.
   Hanada: Some functions presented here, e.g. bg image, bg music, conrol
           over page advance
   Hanada: Also has a jump function, used in e.g. dictionary or
           choose-your-own-adventure story

   Hanada: Next is a comic function
   Hanada: As I said, you can't see the entire page at once on a mobile
           device, so how we show the frames is important
   Hanada: For example, here we have a vertically-long frame so you can't
           display the whole frame in one screen.
   Hanada: It shows the top first, and then automatically scrolls to show
           the whole frame.
   Hanada: 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.
   Hanada: Also we have functions implemented in our terminals
   Hanada: When you change from one frame to next frame, we can set some
           special effects such as vibration.
   Hanada: We have also been involved in electronic dictionary. XMDF can
           be used for this kind of e-dictionary
   Hanada: Dictionaries are one of the electronic contents that can be marketed

   Hanada: Functions I have been explaining here were realized even before
           2-3 years ago
   Hanada: Last year we extended our format to accommodate other content such
           as newspapers and magazines
   Hanada: So we moved from the conventional format such as text media or
           comics to magazines
   Hanada: 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.
   Hanada: Also we wanted to enable dynamic format that's only possible
           in electronic media

   Hanada: We've added 3 different type of formats
   Hanada: First one is image format. This is straight scanning and copy
           of paper media into a bitmap format
   Hanada: Benefit of this format is that users can access layout image
           that they are accustomed to in printed media
   Hanada: You can drag around the image to see parts of it and also zoom
           in and out
   Hanada: 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.

   Hanada: That's why we added the next format, that we call the hybrid format.
   Hanada: It's still an image format, but there is text inserted into the format.
   Hanada: 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.

   Hanada: The third one, multi-layout format. This is specifically an
           electronic format and the text does reflow.
   Hanada: 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
   Hanada: It changes layout depending on screen sizes as well.
   Hanada: This is an example of multi-layout
   Hanada: As you can see on the screen, you can increase the text size
           without changing the layout or the pictures.

   Hanada: This table shows different patterns of multi-layout that this
           format can do.
   Hanada: For example you can have 10in screen or 5.5in screen
   Hanada: You can select vertical flow or horizontal flow, portrait or
   Hanada: 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.
   Hanada: We have these different settings to meet the demands of the
   Hanada: Some publishers want to have completely different layout for
           10in vs 5in, etc.
   Hanada: We create a format and sell terminals that provide a viewer.

   Hanada: We also make content-creation tools as well.
   Hanada: These are the 3 patterns we have
   Hanada: ...
   Hanada: There's actually one layout format not included in this slide.
   Hanada: That's what we call HTML View. It imports HTML as-is and displays
   Hanada: This is actually one of the formats that we strongly recommend.
   Hanada: Many customers will tell us that XMDF is complicated, and we
           already have a lot of content in HTML.
   Hanada: You might wonder why we didn't put that format in this slide,
           will touch on that later.

   Hanada: In our first format, image and hybrid
   Hanada: Publishers already have the contents in paper, so such images
           and text can be automatically converted to this format.
   Hanada: The third format, multi-layout format, we're talking about
           publishers using a creation tool to make the layout.
   Hanada: This is the overview of the workflow.
     Input Material
     Edit the Body Text
     Edit the Page Layout
     Confirm the output
   Input formats:
     Adobe InDesign IDML format
     plain text
     XMDF Description Format

   Hanada: One challege for e-publishing is that e-publishing alone is not
           going to make financial support
   Hanada: They're still a paper-based business, and e-publishing is on the side.
   Hanada: I think that will change soon, but right now there is a need to
           reduce the cost of e-publishing for such publishers.
   Hanada: The key challenge that we face is how to minimize specific
           processes that are only required for e-publishing.
   Hanada: Basically we don't want to add many complex processes just for
           electronic format.
   Hanada: One of the most important things is of course to be compatible
           with various content data formats, for example InDesign's format.
   Hanada: 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 multiple terminal types.
   Hanada: The other thing that publishers .. is the proofreading of the
   Hanada: Of course this proof-reading process is time consuming
   Hanada: especially if you have to proof read for various terminals
   Hanada: The proof-reading is a lot of work, and costs a lot.
   Hanada: It will be impossible for publisher to buy all the terminals to test.
   Hanada: So tools that emulate terminals can be used to check.
   Hanada: The other challenge is related to the private characters.
   Hanada: PC environment has the same problem, but moreso in mobile fonts
           due to limited fonts they can carry.
   Hanada: Usually such devices are only compatible with JIS level 1 and
           level 2
   Hanada: In our creation tool, we are compatible with Adobe 1.6 fonts
   Hanada: As long as fonts are within this collection, it creates a bitmap
           graphic and inserts within text
   Hanada: Some people wonder why not insert and use real fonts.
   Hanada: But due to limitations of mobile devices, we think at this point
           this is the best option.
   Hanada: Now I have been talking mainly about XMDF format that is our ebook

   Hanada: Now I'd like to switch subject.
   Hanada: These slides are from the Tokyo forum and panel discussion
   Hanada: Going to talk about challenges we see in the future of CSS.
   Hanada: 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.
   Hanada: We recognize that and try to change our 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.

   Hanada: Specifically, the first challenge as we see is display layout setting.
   Hanada: So content builders can configure the settings, and users can
           change the settings. How are we going to balance these two?
   Hanada: 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.
   Hanada: But recently we are starting to see that users are wanting to
           choose how they see the screen.
   Hanada: 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
   Hanada: So rather than the layout, ...

   Hanada: In terms of our implementation, we make it possible to choose
           vertical reading and horizontal reading.
   Hanada: So there are 3 possible types of settings for character direciton.
   Hanada: First one is not specified, which means user can choose whether
           to read vertically or horizontally.
   Hanada: Second choice is a set value, the author sets the preferred
           value but the user can change it.
   Hanada: The third one is enforced.
   Hanada: The publisher says "this is for vertical only", then the user
           cannot change it.
   Hanada: So basically in terms of our hardware we're making all possible
           to set these different types of settings
   Hanada: Which one is chosen depends on the character and nature of the
   Hanada: In the case of JP people, they tend to like reading things vertically.
   Hanada: So they tend to choose reading vertically.
   Hanada: Also we have notification functions, on the content-builder functions.
   Hanada: They can say there'll be maintenance outage tomorrow, etc.
   Hanada: 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.

   Hanada: Second is foreground / background color.
   Hanada: Basically in terms of color spettings, if publisher doesn't set
            anything, then the user can choose the colors.
   Hanada: If the publisher sets colors, then the user cannot change anything.
   Hanada: 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.
   Hanada: So in most cases either the publisher will dictate, or the user
           will chose the colors at their own responsibility.

   Hanada: 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
   Hanada: ... difficult decision to make.
   Hanada: We can also specify line break rules, which characters are in
           scope, character spacing, and hanging punctuation
   Hanada: 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 elements.

   Hanada: As for Ruby, there are two types of issues
   Hanada: One usage is when Kanji is very difficult to read.
   Hanada: So the publisher might put Ruby in because they think the kanji
           is difficult.
   Hanada: But we allow the user to turn that off, if they can read every kanji.
   Hanada: But there are some other special cases where publishers put ruby
           to force the pronunciation of characters in an unusual way.
   Hanada: In those cases we don't allow the user to turn the ruby off.

   Hanada: Here are examples of some control settings. I'm sure there are
           other things publishers want to control and users want to control.
   Hanada: Theoretically-speaking we could enable all controls on both sides,
           but by doing so usability will decrease rather than increase.
   Hanada: If the user understands what they are changing, then it's ok. But
           if not then usability is reduced.
   Hanada: 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.
   Hanada: Users are kinder than you think. They gave us lot of advice.
   Hanada: They continue to give us lots of advice, or, complain to us.
   Hanada: It's difficult for us to turn around and say it's your settings,
           it's your fault.
   Hanada: So we try to make it safer.
   Hanada: 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.

   Hanada: There's another major issue that is display by different viewers.
   Hanada: As I've been explaining, we create the format and distribute the
           format and manufacture terminals as well.
   Hanada: It's an old business model.
   Hanada: In our business if the customer complains, then we take responsibility.
   Hanada: Now, as a result of standardization format, the format became free.
   Hanada: Anyone can create content and distribution, and I think that's a
           very welcome change.
   Hanada: I think there'll be some challenge as we discussed in the morning
   Hanada: Ok, we have standardized format, but there'll be variations in
   Hanada: because of differing interpretation of the format by different
   Hanada: The classic example is the different viewing experience problem
           with the web browsers, which is not entirely resolved.
   Hanada: People create contents based on the standard, but when displayed
           in one web browser looks ok but displayed in another browser
           doesn't work
   Hanada: We are starting to see similar problems again with different terminals.
   Hanada: As for mobile phones, especially for Android, we already have
           WebKit and that's a de-facto standard.
   Hanada: So we have expectations that this WebKit will create standards
           for e-publishing.
   Hanada: I actually spoke about HTML input function, and we are faced with
           problem that if we use this function, even on the same smartphone
           terminal category the view looks slightly different.
   Hanada: This is due to sometimes different versions of webKit, and sometimes
           vendors have altered WebKit
   Hanada: 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
   Hanada: when these different versions exist we will continually face the
           problem of making things look the same in different terminals.
   Hanada: This is one of the reasons why we cannot advertise more the HTML
           input function.
   Hanada: This function is mostly ok, but for ebooks where exact reproduction
           is important, it's not adequate.
   Hanada: That's why we aren't marketing this, we want to market it in a
           more controllable size and scale.
   Hanada: .. exactly reproduce what we were doing in paper, .. electronic is
           electronic so it can be different
   Hanada: So about this point I would like to hear your opinions too.
   Hanada: This brings me to the end of this presentation.

   jdaggett: My name is John Daggett from Mozilla.
   jdaggett: 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.
   Hanada: 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 limitations of the mobile phone we haven't
           arrived at that yet.

   Ashimura: My question not directly related to layout, my question is related
             to copyright issues.
   Ashimura: When we deal with comics, also can be text materials, but
             particularly comics.
   Ashimura: Your technology can change dynamically the presentation of the
             content, setting vibrations, turning ruby on and off.
   Ashimura: 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.
   Hanada: We ask the publisher and display per their instructions. We never
           change anything.
   Hanada: this isn't a quesiton of what is good or bad, and environment will
           change in the future.
   Hanada: Google started audio reading of the text, and it was very
           controversial and they had to stop it
   Hanada: ...
   Hanada: 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
   <br duration="10m"/>

Taichi KAWABATA (川幡 太一), NTT Corp

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

   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 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.
   Kawabata: 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
   Kawabata: However if you look at dictionaries or some scientific papers,
             there are still more that are not yet encoded.
   Kawabata: 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.
   Kawabata: Here is a book from late 19th century. The government in Japan
             issued a dictionary with vocabulary of new introduced legal
   Kawabata: They introduced several hundred new kanji for those vocabulary
   Kawabata: However those new introduced characters have never been used.
   Kawabata: In other cases we have other characters not in use
   Kawabata: Regarding private characters, there have been discussions of
             how to render those characters in HTML.

   Kawabata: Based on discussions we have this week, there are five issues.
   Kawabata: These are the classifications of those five methods to render
             private characters. Each has different profiles, whether they
             have ? or not, whether they are searchable or not, how many
             available, etc.
   Kawabata: In order to utilize private character, must think about font
             format for private characters.
   Kawabata: With HTML and CSS3 you can include the font files
   Kawabata: There are three formats which can be implemented or embedded
             into HTML.
   Kawabata: OpenType, WOFF, SVG
   Kawabata: Each font format has pros and cons.
   Kawabata: OpenType is most popular, but has large size.
   Kawabata: WOFF has smaller size, tailored for Web use
   Kawabata: The SVG is different to other types. You can convert SVG into
             a font.
   Kawabata: SVG is different in that it's possible to use gradation, color,
   Kawabata: Also SVG font can be embedded into HTML and can also inherit CSS
   Kawabata: However the SVG is not supported by all browsers
   Kawabata: And EPUB ??

   Kawabata: 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.
   Kawabata: Everyone can register his or her own characters.
   Kawabata: Once you create a new page and put that glyph, then the font
             will be automatically created from the glyph
   Kawabata: Nearly 100,000 characters are registered
   Kawabata: And based on this, about 1 month ago Hanazono-Mincho, a new
             font became available
   Kawabata: This is only one free font that can .. all UCS/AJ1 ideographs
   Kawabata: This one on the right is the glyph created for UCS

   Kawabata: With private characters there is a challenge of how to deal
             with vertical layout
   Kawabata: When it comes to vertical layout, whether you rotate the
             charater or you rearrange vertically based on ... gsub
   Kawabata: When text-orientation is vertical-right, set characters
             upright (using vertical font settings ) unless otherwise
             specified above.
   Kawabata: In OpenType (quoting from spec here) ...
   Kawabata: Now go over IVS and font selection
   Kawabata: IVS stands for Ideographic Variation Selector
   Kawabata: IVS enables to display ideographic variance by ...
   Kawabata: In the past Unicode only specifies the abstract character,
             however IVS can specify concrete glyphs
   Kawabata: In order to use IVS you need to register IVS into IVD
   Kawabata: Regarding the way to register IVD, that is specified UTS 37
   Kawabata: If a registrant wants to register a variant into a registrar,
             which is currently the Unicode Consortium, first you need to
             register your collection
   Kawabata: Once you register collection, then you can register glyphs ...
             as many times as you wish
   Kawabata: ...
   Kawabata: In the IVD_Collections.txt, ... register into IVD_Sequences.txt

   Kawabata: Currently two colections are registered: Adobe-Japan1 and Hanyo-Denshi
   Kawabata: These two collections are implemented in some fonts
   Kawabata: 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
   Kawabata: I've taken this information from ?'s website
   Kawabata: Blue boxes are from AJ1 and red one are from Hanyo-Denshi
   Kawabata: This is one specific chinese character. As you see, some of
             them match, but they don't always match
   Kawabata: How are people using an IVS? There are two main usages
   Kawabata: One usage could to show a archaic style
   Kawabata: Another purpose for IVS is to correctly display proper names
   Kawabata: Let me explain using an example.

   Kawabata: For example if you have this kind of older text
   Kawabata: And if you apply an IVS, you can make a little bit more traditional
   Kawabata: So if you compare the characters you can see differences
   Kawabata: If you have a font that supports the IVSes, you can convert the
             document into a classical look

   Kawabata: Here's an example where IVS is used for proper names
   Kawabata: These for example are all different names using Chinese
             characters that can be pronounced the same
   Kawabata: But if you look at the chinese characters, they are a little
             bit different.
   Kawabata: ... small differences in a person's name
   Kawabata: Another case for example, Katsudaku City and Katsudaku Ward (sp?)
   Kawabata: Although pronounced the same, their Chinese characters are
   Kawabata: If you press delete key to delete the IVS (in emacs) then you
             see the character convert

   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
   Kawabata: Here there are two different text decorations.
   Kawabata: One decoration is done by CSS, for example converting this
             character into bold face
   Kawabata: Other time if you use IVS you can convert same characters into
             its variant.
   Kawabata: If you want to show the character that is not supported by IVS,
             you have to go through font fallback
   Kawabata: By combining CSS and IVS can you make it boldface for variant,
             or does it change the character?
   Kawabata: IVS and font-selections, there are various arguments.

   Kawabata: Now I'm going to go into a technical deep discussion.
     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?
   Kawabata: Option A is to render all those characters using the base
   Kawabata: Option B is to prioritize characters which are specified in
             the IVSx or IVSy
   Kawabata: These two options have pros and cons
   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 each IVS
   Kawabata: Under option B, it is easy for user to display only base
             character -- just remove VS characters

   <dbaron> Topic: Normalization
   Kawabata: [explains NFD/NFC/NFKC/NFKD normalization]
   Kawabata: Once you have normalization, then you can compare character strings
   Kawabata: Especially for CSS and HTML, the name of class ...
   Kawabata: And actually normalization has some challenges
   Kawabata: For example, implementation is very combersome, especially NFC
   Kawabata: Actually tried to implement NFC, but I have difficult time to
             do that.

   Kawabata: Another issue for normalization is the singleton decomposition
   Kawabata: This means different characters sometimes folded to the same
   Kawabata: For example, Angstrom (U+212B / JIS X 0208) normalizes to A with
             ring above (U+00C5 / ISO8859-1 )
   Kawabata: Another issue with normalization is compatibility ideographs
   Kawabata: All compatibility ideographs will be transformed to corresponding
             unified ideographs
   Kawabata: Apple in HFS file, they do not normalize compability ideographs
   Kawabata: 10 years ago Apple proposed to Unicode to exclude the
             compatibility characters
   Kawabata: However this proposal was not accepted
   Kawabata: Ideographs are unified by unification rules specified in
             ISO/IEC 10646 Annex S
   Kawabata: However there are some exceptions.
   Kawabata: 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
   Kawabata: ...
   Kawabata: Japanese Compatibility ideographs include name ideographs,
             shown in the bottom of the slide
   Kawabata's slide shows characters that are variants of each other --
     one is a compatibility ideograph
   Kawabata: Another issue is when and where normalization should be implemented.
   Kawabata: In 2005 draft version of charmod 1.0
   Kawabata: Early Unicode Normalization was suggested
   Kawabata: It was suggested to put this in HTML
   Kawabata: But if you implement this, we might lose the specific Chinese
             characters, e.g. for a person's name.
   Kawabata: 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
   Kawabata: But I'm not against all normalization for HTML
   Kawabata: I suggest normalization for ID, class, and URL for example
   Kawabata: But this is an example from XML appendix J
   Kawabata: Many types of values can be normalized
   Kawabata: Given difficulty of implementation, e.g. NFC, it's not a good
             idea to normalize those values like ? attribute

   Kawabata: My personal opinion is that for web browsers, NFKC is more useful
   Kawabata: By having this normalization, you can search single-byte
             katakana by using double-byte katakana
   Kawabata: Or even you can search .. characters by separating characters
   (example of searching Liter ligature with Liter ascii)
   Kawabata: ... for example you can't search old Kanji charaters by using
             newer Chinese characters
   Kawabata: So we need a new method to make searching for old and new characters
   Kawabata: Ok, that is my end of presentation.
   Kawabata: Thank you very much.

   jdaggett: You showed a slide that was very complicaed
   jdaggett: That used IVSx IVSy
   jdaggett: This is not a problem that any author should ever have to deal with.
   jdaggett: This is a problem because of the way the Hanyo-Denshi was registered.
   jdaggett: You have two selectors that specify the same glyph
   jdaggett: And you have fonts that support only the Hanyo-Denshi selectors
             and not the AJ1 selectors.
   jdaggett: There is *no reason* the author should *ever* have to insert
             two selectors because there's a problem in the font.
   jdaggett: 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
   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.
   Nat: It's not easy for me to have knowledge of your database.
   Nat: my renderer should have no need to understand you rdatabase
   Nat: And content creators should need to have even less understanding of
        your database
   Nat: If you don't do this, then font fallback will fail, and you run into
        all kinds of problems.
   Nat: 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.

   Nat: I'm very confused by the normalization discussion, because
        normalization is by nature something that is a lossy converion.
   Nat: Why do they think that they're losing something?
   Nat: 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.
   Yamamoto: For this reason, compatibility characters should only be used
             for guaranteeing round-tripping with a particular national
             standard. Other usage is strongly discouraged.

   Yamamoto: Two points that Nat mentioned: wrt compatibility characters,
             he told the history and value
   Yamamoto: On the other hand the standard 10646 for this reason
             compatibility characters should only be used for guaranteeing
   Yamamoto: ... 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.
   Yamamoto: Similarly he is trying to keep this closed world where
             compatibility ideographs are perpetually represented by ? systems
   Yamamoto: 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
   Kawabata: 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.
   Kawabata: Well I myself, Unicode is one big platform where text
             communication is conducted
   Kawabata: Therefore within this big platform that's also contain the
             regional standard, therefore text communication is possible
             based on regional standard as well
   Kawabata: And therefore by using Unicode as a ? ppl communicated by using
             regional standard or subset by agreeing each other themselves (?)
   Kawabata: 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.

   Kawabata: Another point wrt IVD , it's been pointed that characters
             registered in different collections that would be costly.
   Kawabata: Now we only two collections, but looking ahead there might be
             various people who want to register their collecitons for specific
   Kawabata: Of course there's an argument that if you have the same words
             registered in different collection they must be unified
   Kawabata: Our concern is that .. people who want to register a new collection
             must search all the existing collections
   Yamamoto: There are IVD collections by national Japanese, others for local
             governments.. similar situations.
   Yamamoto: 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
   [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.
<br duration="7m"/>

   fantasai has changed the topic to: logged at http://krijnhoetmer.nl/irc-logs/ (fantasai)

Ashimura of W3C

   <kojiishi> Ashimura san's slides available at

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

   Ashimura: Feedback from Tokyo Forum
   Ashimura: e-standards is complicated and controversial
   Ashimura: We need to start with actual use cases, I think
   Ashimura: In Tokyo we asked e-Publishing stakeholders for requirements
             and use cases
   Ashimura: The theme of the session in Tokyo was, What is needed for Japanese
             text layout on Web browsers and e-Books
   Ashimura: Each panelist introduced their own products and services. The
             process of their products and services were discussed.
   Ashimura: Discussed what was needed, what do we want to do using Web

   Ashimura: Feedback from browser vendors, for example Access, the Japanese
   Ashimura: EPUB(HTMl+CSS) is a platform for publishing
   Ashimura: Current latest specs already let us use a certain level of epub
             documents with Japanese layout.
   Ashimura: However there is no free stable implementation for the latest specs
   Ashimura: So they are making an implementation based on WebKit and Google
             Chrome source code
   Ashimura: But it has some issues, especially wrt Ruby and so on

   Ashimura: Next, from signage viewpoint, this viewpoint was provided by
             [Kata?]san, Newphoria
   Ashimura: Very big fonts are needed for advertizing etc.
   Ashimura: Restriction based on hardware: number of characters, resolution,
             display size, etc.
   Ashimura: Difficulty of Japanese text layout on big display is difficult,
   Ashimura: e.g. 12 displays concatenated as a huge display
   Ashimura: That kind of concatenation or linkage between displays is important

   Ashimura: Sankei Digital
   Ashimura: From Web designing viewpoint, including various text provided
             by customers
   Ashimura: It's very difficult to justify the start/end point of characters
   Ashimura: Actual style depends on device resolution

   Ashimura: Toppan generates magazines, novels, picture books, dictionaries
   Ashimura: They have issues with quality of text layout and fonts.
   Ashimura: They said they would like even more beautify layout

   Ashimura: Feedback from Audience
     * 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:
   Ashimura: Next steps should be bringing these requirements and the JLREQ
             requirements into working groups, including CSSWG
   Ashimura: They will discuss how to implement (or not implement) those
   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
   Tada: 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 .
   Tada: We are creating engines, can we use them for other effects.
   Tada: For CSS, can we set up standards in a way that are extendable so that
         it can be used for various purposes
   Tada: 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..]
   <Bert> (I think that "someone" from above introduced himself as Yamamoto
          (sp?) from Alliance.)

   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
   Ashimura: So I think this question covers the issue of fonts, and also
             issues wrt spacing
   Ashimura: 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
   Ashimura: From native English speaker's POV, can't tell if English looks
             better than the Japanese
   Nat: Neither is good.
   Nat: In the case of Roman composition, unless it's a very fine composition..
        in this resolution it looks ok.
   Nat: For example, the end ... are not using proper ellipsis
   Nat: 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.
   Ashimura: Sounds like English native-speaker's POV this doesn't look good
   Ashimura: 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
   fantasai: 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.
   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
   Nat: If you use a frame grid, which is what we call the Japanese grid,
        to create the frame for the text
   Nat: Then you will have an even number of ems
   Nat: However inside the text, there will be times when you have text
        that doesn't exactly fit inside the grid.
   Nat: And then you need to adjust the spacing.
   Nat: When we did research early-on in InDesign's development cycle
   Nat: 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.
   Nat: 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.
   Nat: 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
   Nat: However, most of the users thought that that made it look like
        very old 1960s-style publication
   Nat: However, my personal opinion was, I was very excited to hear this
        and wanted to make this happen in InDesign
   Nat: But I'm the only one. :)
   Nat: 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
   Nat: And it should be the same whether or not there was a grid.
   Nat: 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 length of the line
             and also the inter-line space

   Yamamoto: What happens within the line is a separate discussion.
   Yamamoto: For example if we have 32 characters per line
   Yamamoto: We might have Japanese proportional setting to set the alignment
   Yamamoto: But you can still revert to no spacing.
   Yamamoto: As long as you revert the proportional setting, you can go back
             to solid setting
   Yamamoto: When you specify proportional, each character has its own width.
             Uses font's alternate metrics
   Yamamoto: So Japanese characters look like Roman characters. But even in
             that case we should use em-based grid to define the line length
             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
   jdaggett: In conventional Web browser technologies, we don't really use
             OpenType data.
   jdaggett: We use WebKit because we like to display things quickly.
   jdaggett: 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.
   szilles: But there are also use cases, particularly in advertising, where
            the quality of the image being projected is important
   szilles: So the average user is not required to specify in great detail
            the typographic constraints
   szilles: But the controls are there that someone looking for higher quality
            typography can get that by specifying additional properties

   Ikusei: 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
   Nat: For example we have quite a nice text engine in Flash Player
   Nat: Flash Player uses something totally different from CSS and HTML.
   Nat: You can tell it to render text and animate it with ActionScript
   Nat: The mojikumi in that string can be controlled much more precisely
        than with HTML and CSS
   Nat: 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.
   Nat: 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.

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

<r12a> how many people in the room ?
<fantasai> About 100?
<r12a> wow

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

<RRSAgent> http://www.w3.org/2011/06/01-css-minutes.html
Received on Wednesday, 15 June 2011 21:19:32 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:01 UTC