[webkit-dev] WebKit compatibility in India

[Maciej Stachowiak]

On Oct 23, 2008, at 12:07 PM, Jungshik Shin (신정식, 申政湜)  
wrote:

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

Cool, glad you like it. 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. Hyatt might have a different opinion though - he knows the CSS  
stuff better.

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

It might make sense to have then 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).

We do our best to hide the distinction between mapped attribute styles  
like that and real styles.

Regards,
Maciej


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