In a previous entry I wrote about how the bone radical is written differently in some Chinese cases. Well, thanks to John H. Jenkins of Apple I found out that the People’s Republic of China made a switch from the traditional character to the one that has the corner on the left side. This way the strokecount is reduced by one. But for font designers it offers a small problem, since it means that you have to know your target audience quite well.
To sum it up: PRC uses the newer character, most likely Singapore does so too being another simplified Chinese user. Hong Kong, Japan, Korea, Macao, and Taiwan use the older character.
In the radical classification system called Kang Xi after the Chinese emperor Kang Xi we find 214 radicals. At position 188 we have the radical nicknamed ‘bone’ (骨 – hone). It is part of the group of radicals consisting out of 10 strokes (部首 – bushu).
The above image shows the character ‘bone’ in four fonts for the three languages of Chinese, Japanese, and Korean. The fonts used are STSong (Chinese), MingLiu (Chinese), MS Mincho (Japanese) and Batang (Korean). As can be seen the Chinese font is the only one that squares off the top image’s corner on the left-hand side. The other Chinese font and the Japanese and Korean font do so on the right-hand side.
I raised this issue on the Unicode list since the Unicode character charts have three points where ‘bone’ is encoded, to note: CJK Radicals Supplement 0x2ee3 (left-hand side), Kangxi Radicals 0x2fbb (right-hand side), and CJK Unified Ideographs 0x9aa8 (left-hand side).
I wonder if the discrepancy is a wrongly written letter during buddhist studies which was taken from China to Japan and subsequently later exported to Korea.
I recently had the pleasure to have Matteo Muratori of Mazatech s.r.l. ask me to test their OpenVG implementation called AmanithVG. On my FreeBSD 6.2-STABLE machine running X.Org 6.9 with NVIDIA binary drivers I proceeded to test their 1.0 candidate implementation. I had to install the graphics/libglut port to satisfy a dependency, but after that every thing worked quite well. The speed was quite impressive, especially given that my current work PC is not exactly state of the art.
The possibilities that it, and OpenVG, presents are impressive. It seems to be reasonably easy to create blurring filters that apply in real-time, overlapping images that allow colours to blend, zooming in and out of images, and so on. This opens a lot of possibilities for normal desktop environments as well, I think. If you look at what, say, Beryl is doing on the Unix desktops I think it can benefit from what OpenVG does. Of course, the real goal for OpenVG is more aimed at mobile phones or other handhelds, but I think we can easily look beyond just those platforms.