HancomOffice: A Disruptive Disappointment

By: Dennis E. Powell
Monday, January 15, 2001 10:42:59 AM EST
URL: http://www.linuxplanet.com/linuxplanet/reviews/2901/1/

First, Do No Harm

Many years ago, probably during the Reagan administration, I purchased a little sailboat racing game at a computer show. I brought it home and ran its install routine. And I was horrified to discover that the install program copied the lone executable to the root directory of my boot drive and then rewrote my autoexec.bat file such that it now contained only the name of the game's executable file. Before I got the sailboat program, my autoexec.bat was a thing of beauty, running maybe three pages and tuned to squeeze the most out of my four-meg 80386-16 -- running command.com from a ramdisk, running a big disk cache, all kinds of good stuff, to say nothing of a high memory manager and a host of memory-resident applications that wouldn't work unless they were configured just so. The only thing I thought of as executable at that point was the author of the install routine for the sailboat program.

There is, or ought to be, a rule for application developers: Don't break other stuff on the computer or, if you must break some things, make it clear ahead of time that you're going to do this, so that prospective users can reconsider. Physicians are bound by the rule that it's better to do nothing than to do harm. Developers ought to embrace that notion.

The developers of HamcomOffice, a suite of applications from Korea, haven't.

Another Hybrid

On its face, HancomOffice seems promising: It's a fairly small (well, a 70-meg download, but at least you can run the apps one at a time, unlike StarOffice), seemingly well-designed collection of the usual suspects: word processor, spreadsheet, paint program, and presentation graphics program. Its version 1.0 was recently released. It comes as a compiled binary for $99, but a 60-day evaluation version is available.

One of its claims to fame is that it offers two-byte characters, meaning that it accommodates far-Eastern languages that a lot of programs do not.

It also does something vaguely troubling, introduced by Corel in its office suite for Linux last year: some of the applications are truly Linux-native, while some are ported via WINE. (One expects this from Corel, who released a Corel DRAW! for OS/2 a few years ago that was part OS/2-native and part Windows-native, and completely a mess.) With HancomOffice, everything except the word processor is written to some version of the QT libraries. The word processor, HamcomWord, is a WINE port. I do not know why they did this, but there are serious downsides in both cases.

The spreadsheet seems perfectly typical in just about every way and in fact resembles KSpread in the KOffice suite. The paint program could not be induced here to produce any workplace for doing the painting. The presentation program is a presentation program.

The word processor -- my real interest in any office suite, because I am still eager to find that someone, somewhere, has produced a competent word processor for Linux -- has a full set of features. It even allows page numbering beginning with "2" on page 2 (though customization is limited to the location of the number and whether or not it is surrounded by hyphens). As mentioned, it supports the two-byte characters. It is reasonably quick, has filters for Microsoft products, and brings, too, yet another proprietary file format to the table, in case we didn't have enough of those already to keep the filter industry in business.

Sadly, I don't think anybody is going to be developing filters to import HancomWord files, because I don't think anybody is going to stick with HancomWord long enough to produce any files. The reason is, the thing is monstrously ugly. By that I mean it actually hurts the eyes to look at it. Because it is a WINE port (or perhaps because of the way it was ported), the thing's furniture -- titlebar, toolbar icons, menu items -- shrink to tininess at 1024x768 or above. Okay, so do many of the same elements in, say, StarOffice. But with HamcomWord there's more: the screen fonts are the worst I've ever seen, and in Linux that's saying something. (The late, largely forgotten Maxwell somehow mastered putting letters and numbers on the screen, but its developers didn't master much else, including survival of their application. I do wish that someone would look at their code and see how they did it, though.)

Still, if one stayed at 800x600 and had no other choice, HancomWord would probably do. It doesn't seem to devour enormous resources and it is neither breathtakingly fast nor terribly slow. It works, it has a decent feature set, and one wishes it were Linux native from the get-go. But I'm really beginning to wish that people would forget WINE as an expedient toward porting Windows applications to Linux. In the OS/2 world there used to be Micrografx Mirrors which served much the same purpose with exactly the same effect: the production of bad semi-native applications. (Weirdly, it also brings along a qt-1.x library.)

I had hoped to delight you with screenshots of this case study in what an application should not look like, but before I really had the opportunity I discovered the utterly disqualifying feature of HancomOffice: it violates the prime directive. It breaks stuff. KDE, for instance.

The Sorry Saga

When one visits the Hancom web page, there is the opportunity to download the entire suite or any application from it or combination thereof. I selected the whole shebang. In due course it had arrived, a tarball that when opened rendered several directories -- one containing rpms for each of the applications, of the files common to the applications, and of TrueType typefaces; one containing libraries, one containing internationalization stuff, one ominously labeled /lib.bak, and one containing the bitmap graphics used in the splash screens and so on, all of which were .bmp format. In the toplevel directory there are an install script that points to an install binary also there and a readme file that deals mostly with the installation of additional typefaces.

The install binary, which at a little under a meg chiefly allows the user to select the destination directory, but also allows one to select which applications are to be installed, must be run as root. So I sued root and ran it, to learn that I needed to go back and add localhost to the xhost list. Which I did, went back to root, and tried again.

The installation was quick and trouble-free and even added a KMenu item that when clicked opened a little bar of icons, reminiscent of the one that Applixware puts on the desktop. And the installation also generated an uninstall script (has UnWise been WINE ported to Linux, too?) in the directory containing the opened archive.

I took a little look around the apps, noting the problem with the paint program, yawning at the spreadsheet and presentation program, and sighing at the word processor. I imported a few files into it -- HTML and Winword -- and they came through okay, but they were uncomplicated. I typed a little in it, changed typefaces and sizes, stretched the window unsuccessfully hoping to find a way to make the screen fonts palatable.

Thinking that I would return to it later, I closed it after an hour or so. I was overdue in my weekly build of the KDE2 CVS tree, to see what new and amazing things had come to pass in the preceding week. Imagine my chagrin when the very first package, kdesupport, would not make it through configure because, it told me, I did not have qt-2.2.2 or better installed. In that I've been using qt-2.2.3 since the day it was released, this surprised me.

I wish that I could say that I responded with cool scientific calm and conducted a thorough autopsy before undertaking what turned out to be 24 hours of system rebuilding. And I might have but for the second thing that happened.

When I build a new KDE, I build kdesupport, the first package, in a Konsole window, dumping out of X for make install and for construction of the other packages. So I was still in X, and one of the XScreenSaver kicked in. I had only days before somehow managed to get GL to work really quickly there, with the smoothest animation I'd ever seen. It was now back to about four frames per second in the GL gears screensaver module. Ugh.

That would have to be tended to later. I dumped out of X, went to my qt-2.2.3 directory, typed make clean, and started a rebuild. I build openGL support into qt; I know it's not necessary, but I have heard no good reason not to. The build blew up because the GL libs were looking for glibc-2.0. I have glibc-2.2. Now what?

I looked at the Hancom lib directory. It had brought its own libGL along with it, as well as its own libqt.so.2. (At this point I should have looked at /etc/ld.so.conf to see what atrocities had been committed there, but I didn't. The installation shell script tells me that it dumped new GL libs into /lib and ran /sbin/ldconfig with the output to /dev/null. The GL situation is already bad enough without new players joining the game. So I nuked everything GL or Mesa from the entire machine and then rebuilt XFree86-4.02 and installed it. Now qt-2.2.3 would build. But I got the same error from kdesupport.

Having just about had it, I ran the Hancom uninstall script which uninstalled, among other things, itself, so I cannot look back now to see whether it was its qt-so.1 or its qt-so.2 that it threw in front of my qt. (Had HancomOffice been worth the trouble, free, or both, it would probably have been easy to change some things in ld.so.conf so as to produce peaceful coexistence. But it met none of those criteria in my estimation, and didn't meet two of the three in anybody's estimation.)

Now kdesupport, and the rest of the KDE CVS tree, built. My beloved GL screensavers were faster than even their designers could have imagined they'd be.

Before I rip into the Hancom people for acting as if they're the designers of cheap sailboat simulators for 1980s DOS (which I plan to get around to doing), it's to be noted that this isn't the first time we've encountered this kind of problem. Does anyone here remember glibc-2.07 and StarOffice 4.0? For those who don't, there was a period about three years ago when there were a dozen different glibc-2.07s out there, all incompatible, there being no official glibc-2.07. Red Hat shipped one with its distribution 5.1, and StarOffice built 4.0 against another one. When the two collided, there was trouble. Some distributions built elaborate and sometimes but not always successful wrappers around StarOffice and its glibc, insulating it from the rest of Linux and vice versa. But it was a messy time, though the only think I know of that StarOffice broke was StarOffice.

Commercial applications (and some freeware that employs libraries not likely to be used by anything else) often statically compile their binaries. To oversimplify, this means that the libraries are compiled right into the applications themselves -- no need to go to dynamically loaded libraries, often called shared libraries (and in Windows called dlls). Shared libraries are often used by multiple applications, which matters on a multitasking operating system in that they only have to be stored once and often only have to be loaded once into memory. If you are using libraries that are shared by your desktop, say, then both loading and execution will be faster. Apparently the Hancom people decided to share libraries among their respective, freestanding applications. But this is at best only a half-fast solution. Here's why: like the developers of that miserable little sailboat program, they failed to take into account the possibility that potential users are doing anything else with their computers; in the Hancom case, that those users have KDE as their desktops. This is a very foolish assumption when you're building Linux applications.

It would have been a simple thing to have their little install application look first to see if qt-2.2.x was already installed (likewise the GL libraries; it's beyond me why an office suite needs 3-D rendering anyway), and if the needed libs were found, to forget overwriting them or dumping something else in front of them in the pecking order. Nor in the case of QT is this breaking new ground: it's already well documented that KDE-1.x applications, that require qt-1.x, can be made to work with KDE2, which uses qt-2.2 or better. At this very moment I have qt-1.44 installed along with qt-2.2.3, and nothing complains. A programmer who cannot pull off this simple task does not inspire confidence in more complicated areas.

I'm in no way philosophically opposed to commercial software. I have bought-and-paid-for WordPerfect and Applix on my machine, and when it's released I expect to pay for Opera. But I'm very much opposed to lousy software, commercial or free, and I'm sad to say that HancomOffice 1.0 at present falls into that category. I certainly would not pay $100 for it, though there was a time I would have paid $100 to have my machine restored to its pre-Hancom condition.