- From: Koji Ishii <kojiishi@gmail.com>
- Date: Mon, 2 Feb 2015 10:54:28 +0900
- To: Xidorn Quan <quanxunzhen@gmail.com>
- Cc: Bobby Tung <bobbytung@wanderer.tw>, Richard Ishida <ishida@w3.org>, www-style list <www-style@w3.org>, CJK discussion <public-i18n-cjk@w3.org>
So, are we concluded that the reordering of the light tone marks is no longer an issue? For building fonts for other tone marks than the light tone marks, AFDKO might be a good choice, it can build a font with different tables using glyphs from other fonts. You could also consider forking Source Han Sans[1]. [1] https://github.com/adobe-fonts/source-han-sans On Sat, Jan 31, 2015 at 8:39 PM, Xidorn Quan <quanxunzhen@gmail.com> wrote: > On Sat, Jan 31, 2015 at 10:01 PM, Bobby Tung <bobbytung@wanderer.tw> wrote: >> >> >> >> Xidorn Quan <quanxunzhen@gmail.com> 於 2015年1月31日 上午6:30 寫道: >> >> On Sat, Jan 31, 2015 at 4:43 AM, Richard Ishida <ishida@w3.org> wrote: >>> >>> On 29/01/2015 23:30, Xidorn Quan wrote: >>>> >>>> On Fri, Jan 30, 2015 at 4:47 AM, Koji Ishii <kojiishi@gmail.com >>>> <mailto:kojiishi@gmail.com>> wrote: >>>> >>>> >>>> The first two points don't make sense to me. We don't hope characters to >>>> be marked with the whole annotation. We simply hope fonts have special >>>> values for positioning tone marks to be besides bopomofo. There are only >>>> less than 40 bopomofo characters, and 4 tone marks. Hence there are no >>>> more than 160 combinations (even less, because the 20+ consonants won't >>>> be combined with tone marks, and light tone is not combined besides >>>> bopomofo, hence actually only about 50). I'm not familiar with OpenType >>>> features, hence I don't know if it is feasible to handle this with >>>> features like GPOS (I suspect it is), but it doesn't seem to be harder >>>> than positioning requirements of scripts like Arabic. In addition, given >>>> the small number of combinations, I guess it could at least be handled >>>> with GSUB. >>> >>> >>> Thanks for this comment. I think you may be right. I had been coming at >>> the problem after thinking of the fonts out there that encode the actual >>> bopomofo needed for each character within the font. But I think you're right >>> that that's not what we need here. >>> >>> The bopomofo to be associated with a character is spelled out by the ruby >>> markup. I guess all that's needed is a way to render the tone marks in >>> relation to the bopomofo characters. >>> >>> In that case, actually, I suppose it would even be possible, as a stop >>> gap, to speed up the process of adoption by creating small fonts that just >>> do bopomofo and using font-family to apply those to the ruby annotations. >>> Such fonts may be relatively easy to produce and distribute, and especially >>> if they are free to use they could therefore allow people to start using >>> bopomofo ruby sooner rather than later. >> >> >> Yes, that's a great idea. And I guess it is also possible to develop a >> tool which extracts bopomofo characters and tone marks from a font, and >> generates the required bopomofo font automatically, so that authors can make >> their pages look more consistent? >> >> >> I think we can provide a subset only contains Bopomobo and tone marks with >> GPOS feature as a webfont. Authors add CSS font-family value and it's done. >> For EPUB, we can embedded the subset into the package. But we should find >> out what GPOS feature fit the usage, or need a new feature registered?[1] > > > It seems there is an existing feature named 'mark' [1], whose description > seems to match what we need here. Maybe we can use this one? > > [1] https://www.microsoft.com/typography/otspec/features_ko.htm#mark > > - Xidorn
Received on Monday, 2 February 2015 01:54:56 UTC