-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove example 8 figure 3 to avoid canonicalising a not-yet-established approach #22
Comments
Discussed at today's JLReq TF meeting. JLReq explains that jukugo-ruby will be rendered just like group ruby when the whole base text fits within a line. In its Appendix F, it explains a more sophisticated method, illustrated in the first example as well as Figures 1 and 2 in the link. The main author of the JLReq feels that explaining the sophisticated method as something that is expected is a bit too much. This is because the method is far more complicated. The TF members agreed. Additionally, we feel that the example used is not optimal because it allows multiple interpretations. For instance, you can treat 京都 as one jukugo and handle 市 separately, or you can treat 京都市 as a whole as one jukugo. Bin-sensei suggested using an example like the ones below. These are three-character jukugo and contain a Kanji that has a three-character furigana. Of course you can come up with similar examples. 表沙汰 おもて-ざ-た |
This is not a layout spec, so we're not requiring any particular rendering, just illustrating that "Whether—and how much—the annotations are merged can vary". CSS may constrain it in various ways, but that's not the point here. The point is to show that for CSS to even have the ability to informatively decide what the rendering will look like, it needs sufficient structure and information in the markup. So, I think that the various types of renderings displayed are fine. On the other hand, I think @kidayasuo's suggestion to switch to a word that unambiguously has 3 base characters, rather than 京都市 which can be seen as that or as two words, is a good idea. |
Understood. Thank you for the clarification. |
That said, I wonder: are the words provided by @kidayasuo that different? While they are 3-kanji based words, it seems to me that all of them could also be seen as a 2+1 compound, in a way that's not so different from 京都市
Maybe 浄瑠璃 is the only one that cannot be broken down in that way (or maybe you can with 浄+瑠璃?), but it's a pretty obscure term for non-Japanese speakers. |
In many documents or filling-in forms '京都市' may be written in separated way, like form has '市' and add '京都' or listing multiple names of cities. So, for Japanese, it may be more natural to separate this word, than any other examples. |
I agree many of them still can be seen as 2+1 compounds. 表沙汰 or 浄瑠璃 will be better examples. As for 表沙汰, however 沙汰 can be an independent word probably nobody thinks 表沙汰 as 表になった沙汰. It might be similar to English words dead+line or key+board. |
2.1. The ruby element > Example 8 > Figure 3
https://www.w3.org/TR/html-ruby-extensions/#jukugo-ruby
Understood: All 3 examples are jukugo ruby, meaning that the bases and annotations are individually linked, and the ruby element can be split across a line, taking all necessary annotations with the wrapped base(s). This comment is about the arrangement of the hiragana characters above the kanji when all sit on the same line.
Example 2 shows an arrangement that is described in JLReq, where at least one of the hiragana in an annotation must appear above its related base. (If 都 was annotated by 3 hiragana a gap would open between the base characters.
Example 3 shows an arrangement that looks the same as group ruby would look, and where the と annotation doesn't appear (or barely appears) over the 都 base, because all characters are justified across all the bases (which is what you'd expect for group ruby). I think there was some throwing up of hands at some point by people who feared that jukugo might be a little complicated to implement, "so let's just say that it should look like group ruby", but i don't think that that is yet formalised. Having example 3 in the spec makes it appear to be a valid option.
I suggest that we remove example 3 until such time as a decision is taken by the jlreq group about whether jukugo ruby could actually appear like this. And if that does turn out to be a valid option, i think we should make it very clear that the arrangement of hiragana over kanji in jukugo ruby can follow different rules, rather than giving the impression that the arrangement in fig 3 is the one canonical way to approach the arrangement when the ruby text is set to 60%.
typo: Correct “jukugo ruby” is not be possible
The text was updated successfully, but these errors were encountered: