Hi folks.

A while back the WebKit project made use of ICU directly. There were some port 
maintainers who instead wanted to make WebKit work without ICU. At the time, 
the strategy we pursued was to make a Unicode layer in WTF that layered on top 
of ICU. We then created multiple implementations of that layer on top of other 
back ends.

But this Unicode layer is simply an awkward renamed subset of ICU. I find it 
inconvenient when doing work that requires ICU features and it has held back my 
work in the past.

At this point we are down to only two back ends: The one for ICU, and one that 
is implemented on top of Windows functions, UnicodeWchar.h/cpp. I believe 
UnicodeWchar is currently used only by the WinCE port. A number of the 
UnicodeWchar implementations are not complete. For example, the toLower 
function does not handle the “ß” character.

I suggest we remove the Unicode.h abstraction and use ICU directly. I suggest 
we continue to use the ICU C API, by the way, not the C++ API.

For the WinCE port, I suggest we do one of these two things:

A) Change the port to require the ICU library.

B) Implement a subset of ICU that is enough to compile WebKit, using 
implementations quite like the ones in UnicodeW.h/cpp today, but using the ICU 
function names and constants, rathe than an abstraction layer invented for WTF.

Thus, code in WebKit can make use of ICU directly in a way that’s easier to 
understand. Any port that wants to work without ICU can implement an ICU subset 
compatibility layer in a way that does not require changes to the WebKit code.

I am not in a good position to test this ICU subset compatibility layer, but I 
think it would be a quick easy job to refactor UnicodeWchar.h/cpp into that 

Any thoughts on this? I am not sure what the status of the WinCE port is, but 
I’d like to hear from the maintainers of that port on the port status and their 
view on this strategy.

— Darin
webkit-dev mailing list

Reply via email to