[webkit-dev] Webkit compatibility in India - Transcoding Indic fonts

[Maciej Stachowiak]

On Nov 12, 2008, at 4:56 AM, Prunthaban Kanthakumar wrote:

> Hi All,
>
> I would like to go ahead with implementing the below mentioned logic  
> in Webkit. Can anyone (mjs or hyatt?) comment on this approach?

It sounds ok to me, but I am not a rendering expert.

>
>
> Thanks.
>
> Regards,
> Prunthaban
>
> On Fri, Nov 7, 2008 at 10:58 AM, Prunthaban Kanthakumar <prunthaban at google.com 
> > wrote:
> Hi All,
>
> This is a continuation of the mail thread https://lists.webkit.org/pipermail/webkit-dev/2008-October/005495.html
>
> I am interested in discussing about some of the ways to implement  
> mjs' ideas.
>
> As mjs says in the above mail,
>
> In case you look into implementing this, what I'd suggest is an  
> extra CSS property that can be set based the font property at style  
> resolution time. (since I think the computed font list will strip  
> EOT fonts, so it might be too late to look at it once you are on the  
> rendering side). Something like -webkit-indic-text-decode.
>
> When the code reaches RenderText::styleDidChange method, the font  
> information will still remain in the RenderStyle object associated  
> with the RenderText (because this happens at the time of parsing the  
> html file, well before font resolution happens).  Now in this  
> method, there is check to see if there are text-transformations as  
> part of the style and if there is one, then the method setText is  
> called, forcing it to modify the 'internal text' if needed.
>
> Now we can do the following,
> 1. Add an additional condition in styleDidChange method to check if  
> the font-family is supported by our transcoder (At present a fast  
> look-up table should do because we plan to support only limited set  
> of fonts)  - This condition will be #ifdefed on  
> ENABLE(TRANSCODER_SUPPORT).
> 2. Now in the setTextInternal method, based on the font-family, we  
> get the corresponding transcoder (probably from a map) and perform  
> the transcoding.
>
> Later when font-resolution happens, since the particular font is  
> eot, it will be ignored and based on the code point of glyphs a  
> default font will be choosen by Webkit and hence the correct  
> characters will appear on the screen.
> Also after setTextInternal method there is a layout & width  
> recalculation done which is important for us because we modify the  
> characters. So RenderText::setTextInternal method seems to be the  
> ideal place to plug-in the transcoder.
>
> On a related note, I would like to mention here that, we cannot go  
> with the approach of 'one look-up table' per font-face and a single  
> transcoder to do the look-up for all fonts. The problem is that many  
> indic languages use multiple code-points to represent one character  
> and different fonts use different standards! For example there are  
> situations where one glyph in EOT needs to be transcoded to 5+  
> Unicode code points. A reverse situation is also possible. Due to  
> these issues, we cannot go with a simple look-up table for all  
> fonts. This forces us to write some specialized code to handle each  
> font (there might also be some fonts where a one-to-one look-up  
> table will be enough).
>
> I would like to hear from you about this. Is this approach fine or  
> do you have any issues or suggestions?
>
> Regards,
> Prunthaban
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20081112/d81bc28f/attachment.html>