2008/10/23 Brett Wilson <[EMAIL PROTECTED]> > On Wed, Oct 22, 2008 at 7:25 PM, Maciej Stachowiak <[EMAIL PROTECTED]> 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 > [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
