On Oct 23, 2008, at 12:07 PM, Jungshik Shin (신정식, 申政湜)
wrote:
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.
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
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
