W3C home > Mailing lists > Public > www-style@w3.org > January 2015

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

From: Xidorn Quan <quanxunzhen@gmail.com>
Date: Sat, 24 Jan 2015 23:50:42 +1100
Message-ID: <CAMdq69_8sSNgntee2KcanuYiePLvbmwTzKPfC8ZFd_yeu3=Z-w@mail.gmail.com>
To: Koji Ishii <kojiishi@gmail.com>
Cc: Bobby Tung <bobbytung@wanderer.tw>, www-style list <www-style@w3.org>, CJK discussion <public-i18n-cjk@w3.org>
I made a better version of the polyfill. You can check it in the
attachment. It looks perfect on Trident, WebKit, and Blink. (Some problems
with Gecko again, because of, I guess, incomplete impl of vertical text and
ruby...)

- Xidorn

On Sat, Jan 24, 2015 at 7:03 PM, Koji Ishii <kojiishi@gmail.com> wrote:

> I had an impression that someone has solved somehow and Bobby knows
> that, because WebKit has implemented inter-character already. It's a
> bit unfortunate to know that this wasn't solved yet.
>
> I agree with Xidorn that this should be solved outside of the ruby spec.
>
> So, both of you know the spec/algorithm to layout Bopomofo tonemarks?
> I suspect still-in-work CLREQ might cover that, but if there was a
> polyfill on github, that'd be a great first step. It helps authors,
> and it may help possible contributors with font knowledge to
> understand the necessary spec/algorithm.
>
> /koji
>
> On Fri, Jan 16, 2015 at 10:11 AM, Bobby Tung <bobbytung@wanderer.tw>
> wrote:
> > Hi Xidorn,
> >
> > I remember this issue is discussed in TPAC 2014 ruby session. Layout
> Engine
> > and fonts' GPOS are ok for the tone marks.
> >
> > But fonts vary and may take longer for penetration. I'd like to hear more
> > comments from implement side for the issue.
> >
> > WANDERER Bobby Tung
> > Sent from my iPhone.
> >
> > Xidorn Quan <quanxunzhen@gmail.com> 於 2015年1月16日 上午8:38 寫道:
> >
> > Hi,
> >
> > The current CSS Ruby spec requires UAs to position the tone marks in ruby
> > annotation properly in the note below "ruby-position: inter-character;"
> [1]
> > and I was trying to implement this during the last few days. But it then
> > makes me wonder whether it is worth to implement this in layout engine.
> >
> > The first reason made me think about this was the fact told by Bobby that
> > the tone marks are always positioned in a separate column for vertical
> > bopomofo in all contexts, not only when they are inside ruby annotation.
> > Which means, the tone mark positioning is not limited to inter-character
> > ruby; it also covers ruby and non-ruby text in vertical text. It is
> > definitely what fonts should handle.
> >
> > The other potential problem for this is that, it will never be
> interoperable
> > until all UAs implement this in the same way. There are a lot of details
> > need to be considered, for example, what tone marks should be
> repositioned?
> > Only trailing ones, or every one? What exactly position the tone mark
> should
> > be placed when font or font size vary? It would be hard for author to
> detect
> > whether a UA support the tone mark positioning, and how it is
> implemented.
> >
> > In conclusion, I don't think it is a good idea to implement tone mark
> > positioning in layout engine. It would affect interoperability and
> > complicate the impls. The positioning should be handled by fonts.
> >
> > However, we know that no fonts seem to support this currently. They even
> > display a rotated tone mark in vertical text. For this, I suggest we use
> > polyfiller to do the positioning. It would be easier to implement this in
> > JavaScript and DOM, a polyfiller also provides more flexiblilty for
> authors
> > to control over the behavior. Once the fonts start supporting this,
> authors
> > can simply remove the polyfiller.
> >
> > The attachment is a simple polyfill demo for tone mark positioning. It
> seems
> > to work almost fine with Trident and WebKit (with a little problem with
> > Gecko, though, because of the incomplete ruby impl)
> >
> > - Xidorn
> >
> > [1]:
> http://dev.w3.org/csswg/css-ruby/#valdef-ruby-position-inter-character
> >
> > <tone-mark-positioning.html>
>

Received on Saturday, 24 January 2015 12:51:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:51:56 UTC