Re: [css-ruby] Tone mark of bopomofo in ruby

Bobby,

OS X seems to have hard-wired some of the layout behavior for particular characters, which may override what is specified in a font, and depending on the browser, keep in mind that some layout functionality may be deferred to the OS. This may explain the differences that you observed.

In some ways, you're in uncharted territory, so a broader range of environments, to include Windows and Android OSes, would be a prudent measure. For Android, be sure to use an environment that uses the latest HarfBuzz, which tends to be at the cutting edge.

Regards...

-- Ken

> On Mar 14, 2015, at 5:06 AM, Bobby Tung <bobbytung@wanderer.tw> wrote:
> 
> Hello, 
> 
> But Ko has contributed a new OpenType sample for Bopomofo tone mark position [1].
> 
> This font is in Adobe-CNS1-x standard without any new glyph added. And try to solve tone mark position in horizontal writing and vertical writing in one file. So he do not use 'mark' feature, instead by 'kern' for horizontal writing and 'vern' for vertical writing.
> 
> - On Chrome Mac 41/43
> 
> works on horizontal writing, but vertical writing. [2]
> 
> - On Safari 8.0.5
> 
> it works, but after position arranged by GPOS, there's still a space left. [3]
> 
> 
> Browsers should handle GPOS feature well, so it's possible to use OpenType feature for tone mark position.
> 
> 
> 
> But Ko provides more information to handle positions in horizontal and vertical writing.
> 
> for horizontal writing: use the 'mark' feature.
> 
> for vertical writing: add the 'vert' GSUB then use it's own 'mark' feature.
> 
> [1] https://www.dropbox.com/sh/oxumuuxx5blinc7/AABGJKRWDpAYHcfgQXtOpVbaa?dl=0

> [2] https://www.dropbox.com/s/c8g6u6opq9h9491/bpmfgpos_chrome_mac.png?dl=0

> [3] https://www.dropbox.com/s/9m4smdptx5rn4zg/bpmfgpos_safari_mac.png?dl=0

> 
> 
> --
> Bobby Tung
> 
> 
> 
>> Koji Ishii <kojiishi@gmail.com> 於 2015年2月11日 下午9:28 寫道：
>> 
>> On Thu, Feb 5, 2015 at 7:43 PM, "Martin J. Dürst"
>> <duerst@it.aoyama.ac.jp> wrote:
>>> On 2015/02/04 00:13, Koji Ishii wrote:
>>> 
>>>> 1. Do you want browsers to re-order the light tone marks, or do you
>>>> think it should be done in the source HTML files?
>>> 
>>> I personally think it should be done in a font. I'm sure it can be done in a
>>> font, similar to vowel reordering in South Asian scripts if there's no
>>> simpler solution. That would make it straightforward because all four tone
>>> marks would be handled the same.
>>> 
>>> But of course I'll leave it to the experts who are closer to the use cases.
>>> 
>>>> 2. I recommend you to initiate an open source font project that
>>>> handles positioning of second/third/forth tone marks. Fonts only with
>>>> Bopomofo characters should not be too hard.
>>> 
>>> As I say above, adding handling of the light tone mark should also be
>>> possible in a font.
>> 
>> It's a bit of technical details, but when you say a feature "can be
>> done in a font", there are two levels.
>> 
>> 1. Algorithm is generalized, and the font engine reads the table in
>> the font file and render accordingly. Ligatures, vertical alternate,
>> diacritic marks fall into this category.
>> 
>> 2. Algorithm is defined in OpenType spec, and the font engine handles
>> this without any data in the font file. Reordering in Devanagari is
>> one example of this category.
>> 
>> While the reordering could be handled in a font *system*, the
>> combination of font file and font engine, to do so, you will need to
>> update the font *engines* such as DirectWrite, CoreText, or HarfBuzz.
>> It's not something an open sourced OpenType font *file* can handle.
>> 
>> So my recommendations are:
>> 
>> 1. An open source font handles 2nd/3rd/4th tone marks to position them
>> correctly, possibly with fine tunes depends on previous characters
>> etc.
>> 
>> 2. If the reordering of the light tone marks is the right thing to do:
>>  2.1. Ask OpenType to add a spec (probably here[1]), and then expect
>> all font engines follow it someday.
>>  2.2. Since 2.1. will take really long, UA doing it automatically for
>> ruby text container looks reasonable approach to me. Even when 2.1. is
>> done, both UA and font engines doing it is no harm.
>> 
>> But I'm still unable to figure out whether the reordering is the right
>> thing to do or not. Bobby and Xidorn say it's not. Word does (thank
>> you Richard again for the investigation and updating the blog[2] as
>> always.) So, is Word doing what Taiwanese do not want? I have to admit
>> that it's quite possible ;) but I consider this question is still not
>> fully resolved yet.
>> 
>> [1] http://www.microsoft.com/en-us/Typography/SpecificationsOverview.aspx

>> [2] http://rishida.net/scripts/bopomofo/ontheweb#lighttoneposn

>> 
>> /koji
>

Received on Monday, 16 March 2015 02:34:45 UTC