Back to article

HancomOffice: A Disruptive Disappointment

First, Do No Harm

January 15, 2001

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.