W3C home > Mailing lists > Public > www-style@w3.org > January 2012

Re: [css3-writing-modes] A report from a meeting w/Japanese publishing group

From: MURATA Makoto <eb2m-mrt@asahi-net.or.jp>
Date: Sat, 14 Jan 2012 15:14:47 +0900
Message-ID: <CALvn5ED0bP8x5OqqfSPkdAFG1EWZZVgMzJGeJOtaVB3JNjK+RA@mail.gmail.com>
To: koba@antenna.co.jp
Cc: "www-style@w3.org" <www-style@w3.org>

I agree that "how to select a proper glyph shape and glyph metrics for
each character in vertical writing mode"  is an important issue and I
did not mention it in my mail.   This is about the property value
"T" in "Property Values for the East Asian Orientation Property"
in Unicode TR#50.  I just mentioned "U" and "S" in the same property.

In your blog, you argue against font-independent determination.
I am interested in further discussions about this topic.


2012年1月14日13:50  <koba@antenna.co.jp>:
> Murata-san
> It seems to me this is different issue from the default choice of a) and
> b) shown in "3.2.3 Mixed Text Composition in Vertical Writing Mode".
> The choice a) is set by text-orientation: upright, b)is text-orientation:
> upright-right. This specification is no problem.
> But the issue is how to select a proper glyph shape and glyph metrics for
> each character in vertical writing mode.  CSS WG rejects modern
> font-technology, and trying to make a original mapping table. This may
> cause a serious issue in Japanese typesetting, may become a show stopper
> of EPUB in Japan.
> I am now carefully reviewing the issue. Please refer to:
> http://blog.cas-ub.com/?p=614 (sorry this is in Japanese).
> Regards,
> Tokushige Kobayashi
>> Brady,
>> This is about the default choice of a) and b) shown in
>> "3.2.3 Mixed Text Composition in Vertical Writing Mode" in
>> the W3C Note "Requirements for Japanese Text Layout".
>> Which of the two is default for which character?  UTR#50
>> is intended to make this point clear, but different opinions
>> certaily exist even in Japan.
>> http://www.w3.org/TR/jlreq/#en-subheading2_2_2
>> Regards,
>> Makoto
>> 2012/1/14 Brady Duga <duga@ljug.com>:
>>> Hi Koji,
>>> This all sounds great - always nice to see someone working on
>>> interoperability tests! I am little confused by the problem they have
>>> with
>>> glyph orientation. Is this just a failure of some UAs to properly apply
>>> glyph substitutions when rendering vertical text, or is it more complex
>>> then
>>> that?
>>> --Brady
>>> On Fri, Jan 13, 2012 at 9:10 AM, Koji Ishii <kojiishi@gluesoft.co.jp>
>>> wrote:
>>>> I had a meeting with Kadokawa, one of the biggest publishing company
>>>> group
>>>> in Japan. Guys working on EPUB in Japan had setup a meeting with them
>>>> and
>>>> kindly invited me, so I'm writing this to share what I heard at the
>>>> meeting
>>>> with whom interested in digital publishing situations in Japan.
>>>> About a month ago, the EBPAJ (The Electronic Book Publishers
>>>> Association
>>>> of Japan)[1] made an announcement[2] that they have started a project
>>>> to
>>>> test interoperability of EPUB readers. As EPUB3 became REC last
>>>> October, and
>>>> readers started appearing in the market, they soon realized that
>>>> interoperability is one of the issues they need to resolve. The EBPAJ
>>>> is
>>>> primarily focused on magazines, and Kadokawa is one of the central
>>>> member of
>>>> the activity within the EBPAJ.
>>>> They believe in future of EPUB and W3C technologies so much that they
>>>> want
>>>> to solve problems they can, and this project is one of such efforts.
>>>> They're
>>>> planning to do the followings in this project:
>>>> 1. Listen to the member publishers to create a list of features and
>>>> test
>>>> cases they would care.
>>>> 2. Create a test suite and ask which features vendors support. The
>>>> group
>>>> will also run tests for major readers and browsers by themselves.
>>>> 3. Publish the result so that content holders can decide which
>>>> platforms
>>>> to support. They expect the result also helps creating in-house rules
>>>> to
>>>> author interoperable HTML/CSS/EPUB for readers/browsers they want to
>>>> support. They target to publish the result on March 2012.
>>>> They also mentioned that the glyph orientation in vertical text flow is
>>>> one of the issues they are looking into, which is one of the hottest
>>>> topic
>>>> in writing-modes[3] and UTR#50[4]. It used to happen in the past that
>>>> digital publishing platforms rendering different glyph orientation by
>>>> OS/fonts, so they were not surprised much, but they recognized that
>>>> EPUB has
>>>> the issue and that they need to investigate further. They're welcoming
>>>> our
>>>> efforts to define orientations in the spec, although, no promise on
>>>> dates is
>>>> one of the biggest concern. How they would test it hasn't finalized
>>>> yet,
>>>> I'll keep in touch with them.
>>>> It looked to me that they were a bit surprised that many symbol and
>>>> punctuation glyphs used in their contents appear in sideways in today's
>>>> implementations, more than in other existing digital publishing
>>>> platforms.
>>>> But they're professional content holders that, once spec was finalized
>>>> and
>>>> implemented (or they have figured out behavior if spec didn't meet
>>>> their
>>>> timeframe,) they could create internal rules or system to wrap every
>>>> symbol
>>>> and punctuation character in <span>s and set the text-orientation
>>>> property[5] on them. They said they can live with any rules as long as
>>>> the
>>>> rules are clear, there's a workaround (i.e., span + text-orientation
>>>> property,) and it won't change, but it still holds true that the less
>>>> <span>s they need to use, the better.
>>>> [1] http://www.ebpaj.jp/ (Japanese)
>>>> [2] http://www.ebpaj.jp/images/epub_20111216.pdf (Japanese)
>>>> [3] http://dev.w3.org/csswg/css3-writing-modes/
>>>> [4] http://www.unicode.org/reports/tr50/
>>>> [5] http://dev.w3.org/csswg/css3-writing-modes/#text-orientation
>>>> Regards,
>>>> Koji
>> --
>> Praying for the victims of the Japan Tohoku earthquake
>> Makoto


Praying for the victims of the Japan Tohoku earthquake

Received on Saturday, 14 January 2012 06:15:39 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:54 UTC