<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Nov 12, 2008, at 1:06 PM, Maciej Stachowiak wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Nov 12, 2008, at 4:56 AM, Prunthaban Kanthakumar wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi All,<br><br>I would like to go ahead with implementing the below mentioned logic in Webkit. Can anyone (mjs or hyatt?) comment on this approach?</blockquote><div><br></div><div>It sounds ok to me, but I am not a rendering expert.</div></div></div></blockquote><div><br></div><div>I asked Hyatt and he thinks it sounds sensible too.</div><div><br></div><div>&nbsp;- Maciej</div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br><blockquote type="cite"><br><br>Thanks.<br><br>Regards,<br>Prunthaban<br><br><div class="gmail_quote"> On Fri, Nov 7, 2008 at 10:58 AM, Prunthaban Kanthakumar <span dir="ltr">&lt;<a href="mailto:prunthaban@google.com">prunthaban@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Hi All,<br><br>This is a continuation of the mail thread <a href="https://lists.webkit.org/pipermail/webkit-dev/2008-October/005495.html" target="_blank">https://lists.webkit.org/pipermail/webkit-dev/2008-October/005495.html</a><br> <br>I am interested in discussing about some of the ways to implement mjs' ideas.<br> <br>As mjs says in the above mail, <br><br><i>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. </i><br> <br>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).&nbsp; 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.<br> <br>Now we can do the following,<br>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)&nbsp; - This condition will be #ifdefed on ENABLE(TRANSCODER_SUPPORT).<br> 2. Now in the setTextInternal method, based on the font-family, we get the corresponding transcoder (probably from a map) and perform the transcoding.<br><br>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. <br> Also after setTextInternal method there is a layout &amp; 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.<br> <br>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).<br> <br>I would like to hear from you about this. Is this approach fine or do you have any issues or suggestions?<br><br>Regards,<br><font color="#888888">Prunthaban<br><br> </font></blockquote></div><br> _______________________________________________<br>webkit-dev mailing list<br><a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br><a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br></blockquote></div><br></div>_______________________________________________<br>webkit-dev mailing list<br><a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev<br></blockquote></div><br></body></html>