Re: Comments on "Requirements for Japanese Text Layout" (1)

Eric, guys,

So sorry for such a late response.
Now the first part of the comment disposition from JLTF Japanese Team.
The latter part will be disposed in next Japanese team meeting.
Again, thanks for such detailed and useful comments.

2010/8/27 Eric Muller <emuller@adobe.com>:

> $B!x(B 3.3.1, note 1 on Figure 107, add at the end of the first sentence:
> "(because nakastuki alignment has been adopted for single ruby characters,
> and the first approach has been adopted for the case where 3 or more ruby
> characters are attached to a single base character)"
Disposition: Noted but not accepted.
Rationale: Actually, the example of Fig.107 looks like
"Nakatsuki-Ruby". How ever, it is not the issue of this figure, and
the explanation of "Nakatsuki-Ruby" will appear later part. So it may
make needless misunderstanding or confusion about "Nakatsuki-Ruby". As
mentioned in 3.3.5, the word "Nakatsuki-Ruby" is only used for one
base character with only one Ruby letter.


> $B!x(B 3.3.5, case "attaching three or more hiragana ruby characters to a single
> base character", option a (nakatsuki alignment for single ruby). I would
> suggest to add examples to figure 121, to show what happens the ruby text
> cannot overhang the character either before of after the base. In other
> words, four cases just like in figure 122.
Disposition: Noted but not accepted.
Rationale: Actually, in the case when the character before and after
are Kanji characters, there happened to appear slight space before and
after the base Kanji character. However, the relative positioning
among the base charecter and ruby letters are not affected by the
character class of the characters before and after. In this figure the
issue should be focused to the rule that relative positions of ruby
letters are aligned to the center of the base character.


> $B!x(B 3.3.6. "When the length of the ruby text is longer than ... as specified
> in JIS X 4051". I think that "the method of JIS X 4051" needs to be
> explained a bit more. For example, it is my understanding that this method,
> in the case of fig 127, with the character preceding the group-ruby being a
> kana, would allow that kana to "consume" the 1/4 em space on the left of the
> ruby base, but no more. This is somewhat dissimilar to the mono-ruby case,
> which allows to take into account the presence of the kana in the first
> place. In fact, it seems that there are two methods: one that prefers
> "centered-ness" of the ruby over its base and is the one explained here for
> group ruby, and one that prefers "avoid expansion in the base" and is the
> one explained here for mono ruby. But I think that either method can be
> applied to either case.
Disposition: Noted but not accepted.
Rationale: Same reason as $B!x(B3.3.5. In JIS$B!!(BX 4051, in the case of group
ruby, the relative position among base characters and ruby letters are
not affected by the character class of the character before and after.
In this figure the explanation should focus to this issue.

> $B!x(B 3.3.7, paragraph below figure 129: "If there is any kanji character in a
> given kanji compound word which needs more than three ruby characters" ->
> "... three or more ruby characters". That one is not in the errata.
Disposition: Accepted and the text will be modified accordingly.


> $B!x(B 3.3.7 There needs to be a mention of Appendix F in this section.
> Furthermore, the relationship between what 3.3.7 describes and what appendix
> F describes needs to be clarified.
Disposition: Accepted, and the text will be amended accordingly.


> $B!x(B 3.3.8, "When the length of the ruby text is longer...": the case of
> iteration marks (cl-09) is not listed at all in the list above figure 135. I
> suppose that they should go under b. along with hiragana, katakana, etc.
Disposition: Accepted, and the following text will be inserted as follows:
After
"When the length of the ruby text is longer than that of the base
characters, . . . . general rules (see Fig.137 and Fig.138). They were
established especially in order to avoid misreading and to maintain
the beauty of the layout."
Insert
"Noted that when the ruby letters are overflowed from the realm of the
base character, the detailed handling is mentioned in Annex B as table
of spaces, in accordance with the explanation in 3.9 "About Character
Classes".
Rationale:It is seldom that the iteration marks(cl-09) accompanies
Kanji characters with ruby before and after, however it might happen.
So the note will be added.


> $B!x(B A. It would be very helpful to have the lists as machine readable data
> files. It would also be very helpful to have a full coverage of Unicode,
> rather than just a subset (
Disposition: Noted but not accepted.
Rationale: There is a mentioning in Appendix A Character Classes as follows:
"The following are lists of (non-ideographic) characters from a subset
of ISO/IEC 10646 (collection number 285 "BASIC JAPANESE" and 286
"JAPANESE NON IDEOGRAPHICS EXTENSION") grouped by character class
according to the classification explained in 3.9.2 Grouping of
Characters and Symbols depending on their Positioning. "
It means that the members of character classes are limited to the
(non-ideographic) characters in JIS X 0213. This requirements is
focused to ordinary social use of Japanese language, so to cover full
Unicode characters is far over from our capability :-)


> $B!x(B A.19. There is probably no need to list U+4EDD $B!8(B explicitly in this table.
Disposition: Noted but not accepted.
Rationale: This character(U+4EDD) is in CJK Unified Ideographics block
in UCS/Unicode, however, in JIS X 0213, it is classified as non
ideographic character, so this code position will stay as is.


> $B!x(B A.19. It seems to me that U+2116 $B-b(B NUMERO SIGN should not be in cl-19 but
> should be in cl-27.
Disposition:Accepted and the font of the character will be changed to
Japanese style one.

Motivation: ignoring classes 20-25, 28-30 (since those
> are all obviously characterizing a very specific context), and looking at
> the characters which occur in multiple classes, they all fall neatly in
> being in both one of classes 1-8, 12-13, 17-19 ("Japanese" context) and in
> class 27 ("western" context). In other words, it seems that there is a
> layered decomposition:
>
> - japanese vs. western (27) vs. western word space (26)
> - inside japanese: 20-25, 28-30 for specific contexts vs. non specific
> japanese context
> - inside non specific japanese context: 1-19 based on the character
Disposition: Noted for consideration in future version.
Rationale: It is very controversial issue. The bottom line is that
character class of some code position may differ between Western and
Japanese context. Implementers and users shall aware this issue.


> U+2116 $B-b(B NUMERO SIGN is the odd man out: it is listed in 19 and in 12. I
> think it was meant to be listed in 27 (where it can certainly occur) and in
> 12.
>
> $B!x(B F.2, b. "When a base character is accompanied by more than three ruby
> characters" -> "... three or more ruby characters"
Disposition: Accepted and the text will be modified accordingly.


> $B!x(B F.2., b.2. "consisting of two ideographic characters, each of which is
> accompanied by three and two ruby characters respectively."  delete "each of
> which is"
Disposition: Accepted and the text will be modified accordingly.

>
> "[Fig.197] are examples with the same jukugo-ruby as in [Fig.195] and
> [Fig.195] except" -> "...[Fig 195] and [Fig 19*6*]"
Disposition: Accepted and the text will be modified accordingly.

> Is Table 1 missing, or it  just does not exist?
>
> Tables 2, 3, 4, 5, 6, 7: "cl-25 unit symboles" -> "symbols" (no e)
Disposition: Accepted and the text will be modified accordingly.
Excuse:-) Appendix A was considered as Table 1


> I don't have a good suggestion, but it would be helpful to arrange for the
> tables to be printable in black and white. The entries on a darker
> background (e.g. in table 4) are hard to read, and the entries with lighter
> background are hard to distinguish.
Disposition: Noted for further consideration, but may be difficult.

> Also in the tables, there should probably be some mention that the handling
> of classes 17 & 18 is described in $B!x(B 3.7.4.
Disposition: Noted but not accepted. Considered in future versions.
Rationale: Mathematical notation is not described in JIS X 4051 and
mentioned as further discssion issue. Also, the handling of
mathematical notation in line and independent block are different from
each other. so to describe all the behavior of the character class is
very difficult and complicated.




-- 
KOBAYASHI Tatsuo$B!J>.NSN6@8!K(B
Scholex Co., Ltd. Yokohama
ISO/IEC JTC 1/SC 2 Chair
homepage) http://www.kobysh.com/tlk/

Received on Friday, 22 October 2010 01:03:20 UTC