Re: [css-ruby] ruby-position: inter-character

On 19/09/2014 11:01, Koji Ishii wrote:
>> Who is 'we’?
>
> It was a few years ago when fantasai, me, and some EPUB folks gathered in Taiwan EPUB conference.
>
>> I would think that this is a non-starter unless the necessary OpenType features are already present in most Chinese fonts. I don't know whether that's the case, or what proportion of fonts have it, but I'm rather dubious that you'd find that available, and extremely doubtfull that it's available in the majority of Chinese fonts, so I'm inclined to think that handling in layout is likely to provide greater interoperability.
>>
>> I have seen fonts that include bopomofo ruby, but I believe that these are rather special fonts, and I'm not even sure whether you can hide the ruby when using them.
>
> No fonts as far as I know implemented the GPOS/GSUB, as Bobby confirmed. Also most of vertical flow implementations do not support GPOS/GSUB either as of today, so I agree that if we want one implementation, doing it in layout code is quicker.
>
> But spec’ing and making it interoperable will take quite long anyway,

For more years than I care to remember the assumption has been that CSS 
would indicate that right-sided ruby needs to be used, but that the 
browser implementations would take care of the details. I don't think 
that will take long to spec.

It's also what the current ruby layout spec says.

> and I’m not so sure doing Bopomofo rendering in layout code is the right way to go.

Koji, please come up with clear reasons for your doubts. We can't delay 
progress on bopomofo yet again because of vague fears.

> It’s actually great to know that there’s one experimental font that does the layout using GSUB. If it’s technically feasible, making such fonts, along with supporting GPOS/GSUB rendering engine still looks win to me.
>
> Fonts are not necessarily widely installed today, if there is one public font, authors can use web fonts or embed it to EPUB.


I'd like to step back and check what it is we are talking about here.

We could be talking about the positioning of all elements of bopomofo 
ruby to the right side of a base character being handled by opentype 
(once some indication is given that right-sided ruby is actually 
required, rather than above), or we could be talking just about the 
positioning of tone marks relative to the 'base' bopomofo characters 
(which is the context in which I had previously heard that 'oh, the font 
should take care of that').

The opentype font Bobby pointed to looks to me inappropriate for what we 
need, since you need to type the annotations as pinyin.

In addition, I also think that it's incongruous to expect to do bopomofo 
ruby using opentype features, but not, say, Japanese mono ruby, other 
than for the specific case of aligning the tone mark with the bopomofo 
letters.

We have been looking for bopomofo support for many years with basically 
no progress. For more than the 12 years I've been at the W3C various 
folks have been working on CSS and wondering how to handle bopomofo but 
never coming up with any concrete plans.  I strongly disagree with the 
idea of stopping the progress that Dave is now making in favour of 
something that may possibly happen some time in the undefined future, if 
we're lucky.  And by the way, that would be a solution that would only 
work for a handful of new fonts where opentype is supported - people 
won't be able to produce bopomofo for the fonts they currently have or 
prefer.

I think Dave is on the right track. I think the CSS spec doesn't need to 
specify in detail how to arrange the bopomofo letters and tones relative 
to themselves - I think however the Chinese layout requirements document 
which is in preparation probably should.

I propose we carry on.

ri


> /koji
>
> On Sep 19, 2014, at 3:24 PM, Bobby Tung <bobbytung@wanderer.tw> wrote:
>
>> Hi Richard
>>
>> I've asked with a font expert, But Ko. Reply below
>>
>>> Bobby, Yijun, do you know whether OpenType features are widely implemented in Chinese fonts that would automatically handle bopomofo as vertical ruby if CSS provided the right trigger (bearing in mind that in some circumstances (rare) vertical alignment is not wanted, but rather horizontal ruby or, in occasional educational or modern informal text just plain bopomofo)?
>>
>> In experimental implementation, handling bopomofo as vertical ruby automatically is possible:
>> http://but.tw/font/bpmfpy.html
>>
>> However, it's based on GSUB, and containing many glyphs which is not defined in Adobe-CNS1-x.
>>
>> I think it's possible to implement by GPOS without additional glyph.
>> However, there is no any implementation exists due to GPOS is not supported very well currently.
>>
>>> I have seen fonts that include bopomofo ruby, but I believe that these are rather special fonts, and I'm not even sure whether you can hide the ruby when using them.
>>
>> It's the tradition way, from movable types to digital fonts.
>> Since tone mark cannot be styled easily,
>> and reading of Chinese word is relatively fixed.
>> Pre-merged glyphs are easy to use.
>> However, this way can not show rare readings, and without any standard.
>> (some character has more than one reading,
>> however, all readings may be listed in different order in fonts of different font vendors.
>>
>> Conclusion:
>> No any font support format bopomofo ruby automatically currently.
>> I think implement by CSS is more feasible solution.
>>
>> But Ko (font@but.tw)
>>
>>
>>> Richard Ishida <ishida@w3.org> 於 2014年9月19日 下午1:26 寫道：
>>>
>>> Hi Koji,
>>>
>>> On 19/09/2014 04:46, Koji Ishii wrote:
>>>> Last time when we discussed on the exact positioning of tone marks, we were not very sure
>>>
>>> Who is 'we'?
>>>
>>>> whether this should be handled in layout or in font with support from GPOS and other OpenType features built into the fonts. I think most leaned towards to
>>>
>>> Again, most of who?
>>>
>>>>
>>> the font approach, but nobody actually looked into it and existing OpenType features provides all the necessary layout for the tone mark positioning.
>>>
>>> I would think that this is a non-starter unless the necessary OpenType features are already present in most Chinese fonts. I don't know whether that's the case, or what proportion of fonts have it, but I'm rather dubious that you'd find that available, and extremely doubtfull that it's available in the majority of Chinese fonts, so I'm inclined to think that handling in layout is likely to provide greater interoperability.
>>>
>>> I have seen fonts that include bopomofo ruby, but I believe that these are rather special fonts, and I'm not even sure whether you can hide the ruby when using them.
>>>
>>>
>>>
>>> ri
>>>
>>>>
>>>> The benefits of using OpenType features is that then you'll get all the features free in TextEdit and other applications. The downside is probably a layer issue, we'd need some fonts expert.
>>>
>>
>

Received on Friday, 19 September 2014 11:24:11 UTC