I’ve tested OOHanzi in Open Office 3 and have good news to report:
- OOHanzi will work with Open Office 3 without modification.
- There was a bug in Open Office 2.x which affected only people using compiz. If compiz was running, all dialog boxes which were created by the Java virtual machine running in Open Office would be displayed smaller than they should have been. This bug crippled OOHanzi pretty badly. After testing Open Office 3, I found the bug has been fixed.
For instance, the texts at asianclassics.org are encoded in the TibetanMachineWeb font. This font relies on some arcane encoding to produce the proper stacks of consonants, etc. Because of this, the texts offered by that site cannot be used as-is if any kind of sensible information processing is going to be performed on them. It is possible however, to convert those files to Unicode or Wylie. Here’s the process. Unfortunately, it requires Microsoft software. I tried to find a procedure in Linux but my efforts were thwarted. (Also, I was not inclined to test every html2rtf tool available under the sun.) You probably need to have the TibetanMachineWeb fonts installed for this to work.
I’ve just started using VirtualBox. I quickly ran into a problem though. I quickly found that scim prevents VirtualBox from registering the “Host Key” (the right control key by default) which is used to prompt VirtualBox to stop grabbing the keyboard input. I’ve googled for solutions but all of them were either ineffective or unacceptable. Some people suggest to exit scim before starting VirtualBox!!
I’ve found a better solution: start VirtualBox with the environment variables which control input methods cleared out:
$ unset QT_IM_MODULE
$ unset XMODIFIERS
$ unset GTK_IM_MODULE
$ virtualbox [...]
Executing the above prevents VirtualBox from communicating with scim or any other IM. How to convert this to a script is left as an exercise for the reader. It is probably not necessary to clear out all three variables but I’m not going to investigate which exactly VirtualBox uses.
Edit: I should preface this by first saying that I think there are plenty of backup solutions for Linux. It is just that the set of features I want does not seem to be widely available yet. If a piece of software is great at encryption, then it does not have continuous backups or if it has continuous backups, then it is not good at encryption, etc.
I’m currently researching and testing backup solutions for Linux. I stumbled upon this post, in which the author comments:
In the last years several projects were started to provide user friendly solutions for the backup of Linux desktop machines. A year ago I already reported about SBackup. Also, the Ubuntu team developed the solution TimeVault and last but not least there is flyback which I used for several months to keep a backup of my thesis. But despite their advantages they all suffer from stalled development: all mentioned projects are effectively dead at the moment.
This is distressing. I was looking forward to TimeVault and Flyback becoming mature solutions but it seems that this won’t happen any time soon. What I’m looking for is:
- end to end encryption: with ID theft, I’m not comfortable with leaving unencrypted copies of my files around.
- client-initiated backups: I need to backup laptops which are not always on so the client must initiate the backup.
- continuous backup (similar to what TimeVault and Flyback provide).
- support for a backup store located on a network.
- user friendly: desirable but not essential.
I realize that neither Flyback nor TimeVault offered all of this but it looked like they were going to really tackle the continuous backup problem head-on. Right now, I’m testing boxbackup and I’m also keeping an eye on duplicity. I’m not sure yet which one I want. I know that duplicity does not (yet?) support continuous backups but it has other advantages that may make up for it.
I’ve started using Hardy Heron in its beta incarnation. Right now, it is not possible to use my repository to install OOHanzi on Hardy. The interface to install Open Office extensions has changed very slightly but that causes installation of my extensions to fail. A few notes:
- If you upgrade to Hardy form Gutsy, all the OOHanzi packages will be uninstalled.
- The packaging system will not prevent you from reinstalling OOHanzi on Hardy after you upgrade from Gutsy but the installation will get stuck. So do not install OOHanzi on Hardy by using the automatic method yet.
- It is possible to do a manual installation as documented here.
- It is possible to do a semi-manual installation by installing java-unihan-oosupport from the repository and then installing the oounihan and oohanzi extensions manually. The actual steps to perform this are left as an exercise for the reader.
I’m planning to fix this problem before Hardy goes gold but I have a lot of other things to do so I may delay the release for later. If you use OOHanzi and are just burning to move to Hardy, please leave a comment. It will incite me to do this faster.
Today I’ve reviewed again the advantages and disadvantages of DjVu and PDF for scanning and archiving old books. I’ve decided to abandon DjVu. While googling, I’ve found a post which confirmed that the situation with DjVu is bad (the post is from Feb 2007 but I have no reason to believe that the situation is better today).
When I started using it several years ago (my oldest DjVu files date from late 2004) support was sparse but I understood that it was still relatively new. I started using it with the hope that it would catch on. It seems however, that the situation has not improved much since then. Yes, there is more software available for it but most of it is not free (in any sense of the word free) and there does not seem to be any kind of end-to-end support for all features that the format allows. For instance, I have no tool in Ubuntu which allows me to add comments to a DjVu file like I do with PDF files. So I’ve given up on DjVu. It used to be that the size advantages more than made up for all the other disadvantages but PDF has evolved and gotten better at compressing images (by using more advanced compression algorithms), disk space is not the issue it used to be years ago and PDF is just better supported.
That’s very unfortunate because I think if the creators of DjVu had opened it fully, it would most likely have displaced PDF.
I’ve been working on some Chinese extensions for OO but at every step of the way I have to fight with obscure documentation and really strange design decisions. Here’s the latest example. Want to display an image in a dialog? We’re not talking about anything fancy here but just one single image which remains static. There’s nothing dynamic about this. So can you just put in the relative path in the dlg:src parameter which indicates where the image lives (e.g. dlg:src=”../image.jpg”)? No way! That would be way too simple and would violate the spirit of OO which is “why make things simple when you can make them complicated”. Instead you have to create two additional XML files to tell Open Office where to find the image in your extension and then at run time you have to query Open Office to find where the image really lives and load it into your dialog. Yay! The reason for this is that you do not know ahead of time where your extension is going to reside on disk. You’d think a relative path would be rock solid because it is relative to where your extension is located, but no: that does not work. You have to file extra paperwork with Open Office to declare the existence of the images.
(I searched through the dialog files bundled with Open Office to see if I could find something useful in there but what I found were paths like “file://D:/…”. Ooops, I guess even the Open Office developers are having a hard time keeping their paths portable.)
And this is just the latest in a loooooooooooooooooooong series of grievances. Here’s a new motto: “you don’t know the meaning of bondage-and-discipline programing until you’ve tried to write extensions for Open Office.” Open Office is like a bureaucrat: you can’t do anything without filing multiple forms to announce what you want to do and justify it.
References: here, here and here.
I’ve packaged all of OOHanzi for Ubuntu. I’m using Launchpad to host them. Follow the link for information about the sources that must be added to your /etc/apt/sources.list to use my repository. It is also possible to just use the web interface to download all 3 packages individually and install them one by one. If you add the repository to your configuration, just installing oohanzi (e.g. apt-get install oohanzi) should pull everything needed. If you install individually you need to install, in order:
Or you can issue a single dpkg -i command with all 3 listed. If the installation system complains that it cannot complete the installation, issue “apt-get -f install” after the installation.
People who have already downloaded the files individually and who would like to switch to the Ubuntu packages should first uninstall the old OOHanzi extensions and the unihan java library.
People who want to keep abreast of developments can subscribe to an RSS feed that contains only OOHanzi announcements.
Note for people who want to edit OOHanzi’s OOBasic code in OpenOffice’s IDE: If you use the Ubuntu packages, there is no way to edit the OOBasic code. If you want to install the extension so that you can modify the code as needed, you can install the java-unihan-lib and oounihan Ubuntu packages but you must install the .oxt for oohanzi manually as described in the previous release notes.