[webkit-dev] WebKit compatibility in India

Thu Oct 23 12:07:56 PDT 2008

2008/10/23 Brett Wilson <brettw at chromium.org>

> On Wed, Oct 22, 2008 at 7:25 PM, Maciej Stachowiak <mjs at apple.com> wrote:
> >
> > I think the general approach you outline makes sense. I think the best
> way
> > to avoid transcoding content that shouldn't be is to key it off of both
> font
> > and site, assuming that a relatively limited list of fonts and sites
> would
> > provide enough compatibility.
> >
> > That means the transcoding would have to be done late, once styles are
> > resolved. This is entirely feasible; CSS text-transform already does late
> > transformation of text based on styles, and it works right with
> copy/paste
> > and everything:
> >
> > <div style="text-transform: uppercase">this is a test</div>
>
> That's very interesting, I had not thought about this ability and
> figured it would have to be added. I was leaning toward not doing
> anything because of the complexity I saw in this project, but now it
> seems like this could be practical.

Wow, that's brilliant !  Thanks, Maciej !  No more worry about EOT ! For
Indian users, webkit browsers would be better than IE because font-encoded
Indian pages are not just rendered 'correctly on the surface' but also they
can be searched  and copy'n'pasted  if we implement it.

Quite a while ago,  I briefly thought about this approach and immediately
dismissed it because it seems to require too 'invasive' changes deep in
Webkit. (I should have known better).  Then, a few weeks ago, the idea was
proposed again to me by my colleague and he told me that  there's a firefox
extension that does that ( http://padma.mozdev.org ) So, I mentioned it at
https://bugs.webkit.org/show_bug.cgi?id=20542#c21 (while being still
skeptical) to test the water. Contrary to my expectation, Maciej liked it
and now he came up with a practical way of implementing that ! I'm grateful
for him and my colleague.

As for adding converters, I can think of two ways. One is to add them to ICU
(ICU supports m to n conversion).  Browsers shipped with their own copies of
ICU data file can just update their copies of ICU. Then, webkit does not
need to implement them
However,  those new converters need to be added to the ICU on Mac OS X as
well (for Safari on Mac OS X). I'm not sure whether that's possible or not.
And, it seems that there are webkit ports that do not use ICU.

The other is to implement those converters in Webkit. This is a bit more
work, but benefits every port. There are 40 or so converters to add (there
may be more, but the number should not matter much except for size.) and I
think there are some people who're willing to contribute converters to
webkit as well as implementing the idea above in webkit.

 Jungshik

P.S. (font, site) pairs as triggers should be pretty reliable. A small worry
is that a site may switch to Unicode without changing the font name. If my
limited experience can be any guide, when a font with 'hacked-encoding' for
an Indic script is converted to a Unicode OTF, 'Unicode' (or 'U' or
something similar)  is added to the original name.  We might consider
further restricting the invocation of the conversion to 'font face="foo"'
cases (if that distinction can be easily made in Webkit) (I'm assuming that
in virtually all cases, a font is specified like '<font face="foo">Indic
text</font>', but I may be wrong).

>
> Brett
> _______________________________________________
> 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/20081023/b4c053db/attachment.html>