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 <[EMAIL PROTECTED]
> 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
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
