Re: [css-ruby] What does it mean for "ruby-position: inter-character" to force writing-mode to be vertical?

>> (4) Does this "forcing" apply to descendants of the ruby annotation?
>> e.g. if a ruby annotation has a child with "display:inline-block", is
>> that child *also* forced to have a vertical writing-mode?  (If the child
>> isn't forced: does it still get a vertical writing mode by default,
>> somehow? Presumably not through inheritance, unless the answer to (1)
>> was "yes".)
> 
> Yes, IIUC. I'm not sure how rendering of Bopomofo is going to be
> implemented, but I've heard at least once before that <sup> may be
> used within <rt> for Bopomofo to position marks correctly, or <span>
> with additional styles. I hoped it's done in font features, but it may
> not have happened.
> 
> Bobby, any updates?

<sup> within <rt> is used for mark native Taiwanese (Min Nan[1]). Min Nan has eight tone so they used sup for number to indicate tone.[2]

But for now, I don't see any sample mark tone this way in vertical writing.

There are several ways to mark tone for Min Nan, suppered number is one, inline unicode combination is another[3]. And Bopomofo for Min Nan[4]. 

Bopomofo is mainly for Mandarin. 

[1] http://en.wikipedia.org/wiki/Min_Nan
[2] https://www.dropbox.com/s/db6nbkm7obxf6ph/taiwanese_pinyin.png
[3] https://www.dropbox.com/s/1z9q5c2eoqgj7tr/minromanji.png?dl=0
[4] https://www.dropbox.com/s/msi20s4fjabln83/minbopomofo.png?dl=0


> Koji Ishii <kojiishi@gmail.com> 於 2014年12月14日 下午11:29 寫道：
> 
> On Thu, Dec 11, 2014 at 7:36 AM, Daniel Holbert <dholbert@mozilla.com> wrote:
>> The CSS Ruby spec has the following text about ruby-position's
>> "inter-character" value:
>> 
>>  # "inter-character"
>>  #   [...] This value forces the 'writing-mode' of the
>>  #   ruby annotation to be vertical.
>> http://dev.w3.org/csswg/css-ruby/#valdef-ruby-position-inter-character
>> (Note: 'writing-mode' is a link to the definition of that CSS property.)
>> 
>> This spec text needs some clarification, I think. In particular, the
>> following things are unclear to me:
>> 
>> (1) Does this spec-text influence the *computed value* of the
>> 'writing-mode' property? (I hope not; there's added complexity when
>> properties influence other properties' computed values on the same element.)
> 
> Haven't thought about that, but I expect every layout characteristics
> to be the one in vertical flow IIUC. Is it easier to do that without
> influencing the computed value? I'm personally fine either way,
> including undefined if implementation difficulties vary by the
> platform, though not sure what WG would say.
> 
> Note that WebKit has recently implemented inter-character, and it
> looks like the nightly build computes to 'vertical-lr'.
> 
>> (2) If the answer to (1) is "yes" (I hope not): is this "writing-mode"
>> computed-value influence restricted to elements with "display:
>> ruby-text", or does this influence happen regardless of "display"?  e.g.
>> would <div style="display:block; ruby-position: inter-character"> be
>> forced to have a vertical writing-mode?
> 
> The ruby-position property only applies to ruby annotation containers,
> so display:block should not be affected.
> 
> On Thu, Dec 11, 2014 at 7:55 AM, Jonathan Kew <jfkthame@gmail.com> wrote:
>> On 10/12/14 22:36, Daniel Holbert wrote:
>> 
>>>  (3) Which 'writing-mode' value should we actually use?  There are two
>>> distinct vertical values for the "writing-mode" property: "vertical-rl"
>>> and "vertical-lr" -- which of those should we use here?  (In practice,
>>> maybe it doesn't matter, because elsewhere the spec says "There are no
>>> line breaking opportunities within inter-character annotations", and I
>>> think the "rl" vs. "lr" distinction would only matter if there are
>>> linebreaks. ...
>> 
>> IIRC, the distinction is significant even without linebreaks if the
>> 'text-orientation' property is 'sideways': in this case, glyphs are rotated
>> 90° CW in 'vertical-rl' mode, but 90° CCW in 'vertical-lr'.
> 
> 'sideways' always rotates CW regardless of 'vertical-rl' or
> 'vertical-lr', because 'over' direction of baseline is on the right
> side, so it doesn't matter either. I can't imagine any cases where it
> matters.
> 
>> 
> 
> /koji

Received on Sunday, 14 December 2014 18:25:32 UTC