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

[Maciej Stachowiak]

On Nov 12, 2008, at 1:06 PM, Maciej Stachowiak wrote:

>
> 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.

I asked Hyatt and he thinks it sounds sensible too.

  - Maciej

>
>>
>>
>> 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
>
> _______________________________________________
> 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/449e23a4/attachment.html>