Category Archives: General

Accessing Casio EX-WORD 電子辞書 from Linux

I’m a (happy!) owner of a Casio EX-WORD Dataplus 5 XD-A4700, a Japanese electronic dictionary. Recently I looked into updating the Japanese-English dictionary (currently the Shogakukan PROGRESSIVE dictionary) installed, because it’s not good enough: too often when looking up odd sentences (like the ones in Fate/Extra CCC) I do not find any matches.

EDICT is adequate, and while I can use it on my phone and tablet, I like the fact that the EX-WORD has a physical keyboard along with the stylus, and a very nice kanji handwriting recognition. After a bit of looking, I found the 5th Edition of the New Kenkyusha dictionary, offered as microSD card,  to be what I needed (but a bit pricey, 10,500 yen on Amazon, and that’s heavily discounted!).

There’s of course one little problem. Although these products have accompanying software, it is in Windows format only.And I’m using Linux. Of course I could just plug in the microSD, but what if I wanted to to move the dictionaries to the main internal memory?  What to do? Although there’s an USB port, the EX-WORD does not operate like a USB mass storage device: communicaation is done through OBEX and specific commands to load, view and install dictionaries (along with listing, download and upload files to the SD card and the internal memory).

Looking through the Internet led me to the libexword project, a library which provides a way to access these electronic dictionaries and a command-line application, and this post deals on how I made it work for me (but notice, it may not work for you).

First of all we needed a checkout of the sources:

git clone https://github.com/brijohn/libexword.git

Then we need to switch branches, because most of the ongoing work is not in the master branch, but instead in the 2.0-dev branch.

cd libexword
git checkout -b 2.0-dev origin/2.0-dev

To this point onwards you’ll need autotools (autoconf, automake) and the libusb development headers installed, along with Python and SWIG (a bindings generator). Run then

./autogen.sh
./configure --prefix=<prefix> # I used /usr for system wide install

If you don’t specify a prefix, the library and the application will be installed to /usr/local. autogen.sh may complain about a missing AM_PROG_AR (it did on my openSUSE system), so edit configure.ac and add AM_PROG_AR around line 15, then rerun autogen.sh.

After this, issue

make
sudo make install

Or become root and issue make install (assuming you’re installing to a system prefix).

Next, you need to get your 電子辞書 and connect it via USB. The kernel will not seem to find it, but it’s normal. Hit the お気に入り/ライブラリー key twice on the dictionary, then move with the arrows until you highlight 通信 (aka “transmission”). After that, push the translate button (訳) and you’ll see the Linux kernel identifying our dictionary (strings may change depending on the model):

usb 2-1.6.1: USB disconnect, device number 8
usb 2-1.6.1: new high-speed USB device number 9 using ehci-pci
usb 2-1.6.1: New USB device found, idVendor=07cf, idProduct=6101
usb 2-1.6.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 2-1.6.1: Product: CESG502
usb 2-1.6.1: Manufacturer: CESG502

Now we need to access the dictionary. However, unless you set up specific rules in udev, only root will be able to access the device. You can create a file in /etc/udev/rules.d called 99-exword.rules with the following:

SUBSYSTEM=="usb", ATTR{idVendor}=="07cf",ATTR{idProduct}=="6101",  MODE="0666"

and then refresh the rules with

udevadm control --reload-rules

After all of this is done, run exword and connect to the device:

$ exword
Exword dictionary tool.
Type 'help' for a list of commands.
>> connect
connecting to device...done
\_INTERNAL_00\ >>

“connect” takes different options: check with “help connect” for what you need specifically.

We can change between paths using the setpath command:

setpath drv0:/// # Root of internal memory
setpath crd0:/// # Root of SD
setpath drv0:///CASIOTXT # Move to the CASIOTXT directory in the internal memory

Notice however that some directories can’t be accessed.

You can list files with the list command (a truncated output shown below):

\_INTERNAL_00\ >> list
<sys_bak>
maintch.wrk
fav.inf
line3.inf
linecd.inf
<SOUND>
<CASIOTXT>
drvvewer.inf
lngfile.inf
<data>

There are also other commands: use “help” to see them all. Issue “disconnect” when you are done, and “exit” to exit the program.

There’s also a Python binding made using SWIG: I’ve yet to play with it.

The libexword developer has also created some GUI tools to mimic the Windows EX-WORD tools (which, it must be noted, work only with the Japanese dictionaries). You can get them at the exword-tools git repo. The procedure for installing them is the same as above (including the modification to configure.ac). You’ll need the development headers of wxWidgets, however, as this is a GUI application.

After installing, you can launch ExwordLibrary, ExwordTextLoader and ExwordLibraryInstaller. The latter is required to install new dictionaries, and unfortunately involves getting a Windows executable and placing it under PREFIX/share/exword, where PREFIX is the path you gave to the libexword configure script. This also means you need wine to run it.

Once that is done, you can use the library application:
exwordlib

 

or the installer to install dictionaries:

exword-dict

And that’s all. I hope this has been useful for using your electronic dictionary with Linux!

Test the upcoming openSUSE 12.3 and KDE Workspace, Applications and Platform 4.10 RC2

Following up on my previous post, a different type of image has been made by the openSUSE KDE community members. In particular, alin has created images sporting the same software from KDE (4.10 RC2) but using the upcoming openSUSE 12.3 as base. 

Download links:

These images are provided not only to test 4.10 in openSUSE, but also to test part of the distribution itself, without touching existing systems. Should you encounter a bug, please report it as follows:

Don’t forget that those images are not persistent, i.e. the settings will not be saved between sessions.

With that said, let the testing commence (or continue)!

Making KDE applications Python 3 friendly

When I’m not on forum duty or handling openSUSE-related contributions, I try to improve my code contributions to KDE, even though I’m by no means an experienced programmer (I program all day long in Python, but I’m still a biologist after all). For the upcoming 4.10 release I’ve been polishing up Python 3 support.

As you may know, Python 3 isn’t the standard in many distributions (Arch Linux excluded), but despite the slow start, it is slowly gaining steam. PyKDE4 was built keeping in mind Python 3 support, so theoretically we supported it right from the start.

When I wanted to package PyKDE4 for Python 3 in openSUSE, I stumbled upon some quirks: the CMake build system was not finding Python 3 properly. After some investigation, I noticed that the Python macros responsible for finding the Python library had some assumptions that worked fine for Python 2, but not for Python 3 (a lot of distributions name libypthon3 with a suffix, like mu). Since 4.10 was bumping the minimum required CMake version to 2.8.8, I moved in and rewrote the macros making use of the new functionality offered by upstream CMake (with a big help from Rolf Eike Beer).

As I worked more on PyKDE4, I hit a second snag: i18n() calls were chocking on Unicode. As QString is Unicode-aware, that was really difficult to debug. The root cause was actually a SNAFU of my own caused by swapping lines, and will be fixed in 4.9.4 and 4.10.

Lastly, I got word that Kate’s Pate was not building on Python 3. This caused a huge back and forth of mails and IRC conversations between me and Pate’s developer, Shaheed Haque. I initially fixed building with a very crude patch, which Shaheed improved afterwards. Then the product built under Python 3.3, but kept on crashing. After some debugging, two different issues were found (module not found when imported, and string conversions). With those fixed, Pate would load in Kate but crash when any plugin documentation was loaded. A few more rounds of discussion and commits, and I’m happy to report that everything works as intended!

In short, 4.10 should be a good release for Python 3 users. I have some ideas for 4.11 as well: time will tell if I get around to doing them.