On the side bar you’ll find a small form that accepts one chinese character, aka sinogram, and will return in the box below that the readings [Cantonese, Mandarin, Japanese, Korean and Viêtnamese] and meanings for this sinogram. This stuff was pulled from the UniHan database, as explained at the Tomabaem main page. Tomabaem Online is a derivate of the desktop app, and is built on indexes of the database that are made offline. Then, a little Python [thanks to 2.4’s unicode codecs, conversion from UTF-16 to UTF-8 is seamless] and grep later, and we have a winner! Which reminds me, I haven’t updated the indexes for a while, I shall do that now. I wrote an RB app that runs 11 threads [must. resist. temptation. to. rewrite. it. in. Erlang.] and the main routine reads the UniHan db and sends text to each thread depending on its content. Here’s a sample:

U+3400 kCantonese jau1
U+3400 kDefinition (same as U+4E18 丘) hillock or mound
U+3400 kHanYu 10015.030
U+3400 kIRGHanyuDaZidian 10015.030
U+3400 kIRGKangXi 0078.010
U+3400 kIRG_GSource KX
U+3400 kIRG_JSource A-2121
U+3400 kIRG_TSource 6-222C
U+3400 kMandarin QIU1
U+3400 kRSUnicode 1.4
U+3400 kSemanticVariant U+4E18
U+3400 kTotalStrokes 5

U+3400 gives me the sinogram’s codepoint, and depending on the kXXXXX tag, I pass each line to a thread storing the data in a separate file. The whole process takes two and a half minutes, and I guess I could do faster. But 160 seconds for 25MB of data is fast enough. So now the indexes are up to date I need to update Tomabaem’s own db, will do that later.

dda> time ./threadIndexer/threadIndexer
Thread kSimplifiedVariant starting...
Thread kTraditionalVariant starting...
Thread kCantonese starting...
Thread kJapaneseOn starting...
Thread kJapaneseKun starting...
Thread kKorean starting...
Thread kMandarin starting...
Thread kVietnamese starting...
Thread kRSKangXi starting...
Thread kTotalStrokes starting...
Thread kDefinition starting...
Done dispatching in 150,204,884µs
Saving kSimplifiedVariant.idx
Saving [...]
Thread kSimplifiedVariant finished...
Thread [...] finished...

real    2m39.733s
user    1m54.760s
sys     0m6.600s

So. Okay, most of the time is spent dispatching, I could improve that…

I have released a beta of fPic – on the RB-NUG and [unofficial] RB/FR lists and on RB Garage. Some feedback already from the French side of the programmosphere – despite the language barrier, as the docs are in English. We’ll see. I am to hand over an article – like three months late – that will tie in nicely, as it is the second part of Pictures and Dynamic Libraries: a poor man’s plugin, which introduces the basics of fPics. The second part will delve deeper in the mechanics of linking C code and RB code in an OOP fashion – hopefully.

From the docs:

fPic is a two-part project aiming at providing a replacement Picture class for command-line applications [which notoriously lack any graphic capabilities]. I say two-part because it is split into a dynamic library [manip.dylib] and an RB class, fPic. The dylib handles the heavy-lifting, while the fPic class provides a [more or less] seamless way for RB programmers to manipulate images in CLI applications. I hope to be able, in the end, to produce a library that will have zero dependencies, or at least zero exotic ones (like things usually installed via Fink), but for the moment, some things are necessary, as doing without them would either cripple fPic, or make it too hard to build from the get-go.

And of course, this is a Mac OS X only library. I am planning to make a Linux version, some day, when the Mac version is stabilized. The Linux version, however, would have fewer functionalities, as I can’t use the Accelerate [FreeRotate, ContrastStretch and Equalize] and CoreGraphics [PDF files] frameworks there.

I have provided a few sample programmes, which show some of the things that can be done:

* fPicTester
fPicTester showcases some of the capabilities of fPic. It requires the images included in the distribution folder. The resulting image, Result,jpg, is opened in Preview.

* jpeger
jpeger is a small utility that takes a file image, a destination folder or filename, and some options, and converts the source image to a JPEG image. On success, if only one page was converted [in the case of PDF files, you may request one or more pages], the converted JPEG is opened in Preview.

* OnDemandPDF
This is a combination of a command-line app and some PHP. Put this folder inside ~/Sites/ so that it is accessible from your localhost [you’ll need Apache and PHP up and running of course]. Put some PDFs inside the docs subfolder, and access it from your favourite browser:

http://localhost/~yourNick/OnDemandPDF/
Click on one of the links, to view a document, and read it “online”.

This is a very early beta version, although I do use it myself in a couple of projects, so far without major problems. There are issues yet to be solved, see the docs included in the distribution, and feedback would be appreciated.

You can get the current beta here

You’ll notice a My Reviews section in the sidebar. It’s produced by a small plugin I hacked today (instead of finishing an article, grrr, due tomorrow). I have to refine it, but it seems to work so far.