Re: [tlug] epcEditor

["Stephen J. Turnbull" <stephen@example.com>]

>>>>> "Charles" == Charles Muller <acmuller@example.com> writes:

    Charles> which is working directly on the XML files themselves,
    Charles> where no style sheets are involved. It is rendering all
    Charles> of the fonts through its own system--whatever that is.

OK, so does it distinguish between Chinese and Japanese versions of a
given character (when they share a Unicode code point, I mean)?  Do
they get different fonts, or is it the same font in a style that
doesn't look too bad when Japanese and Chinese are mixed?

    Charles> So again, it is not the case that the program itself does
    Charles> not handle CJK input.

It almost certainly the case that the program itself does _not_ handle
CJK input.  That's the whole point of Unicode and input methods:
programs handle characters, they don't care where they come from, and
typically don't have much idea what they mean.

Once again, this fine distinction is important because it means that
we can predict with fair confidence that the developers of the program
you are advocating are simply going to drop the hard problems on the
floor.  In particular, the very problem (multilingual editing) that
you are most interested in.

    Charles> But it was precisely my inability figure out how to get
    Charles> Emacs set up to do the things I wanted (most fundamental
    Charles> of which was to properly handle CJK in UTF-8) that pushed
    Charles> me to search for a more user-friendly option.

At that time (assuming it was more than about 3 months ago), it was
not easy.  When I packaged Hisashi Miyashita's Mule-UCS for XEmacs at
that time, it became point-and-click.  N.B. I don't know exactly what
you mean by "properly handle"; at that point getting Unicode support
for files became trivial.  If you already know how to use input
methods in Emacs, you use the same ones in exactly the same way.

There is a single remaining problem, which is lack of support for
Unicode fonts in native X windows (although you can run XEmacs in an
xterm -u and output UTF-8 to the terminal).  However, this is merely
ugly; I spent a bunch of time two weeks ago helping a vi guy from a
VeryBigCompany supporting a project for a VeryImportantAsianMarket set
XEmacs up for CJK/UTF-8.  Almost all of the effort was translating
from en_VI to en_EMACS and back.  :-)  Anyway, I told it would be
ugly, and he said "don't worry about it---just make it work!"

But some of these problems are hard.  Don't get fooled by the
flash---putting a lot of effort into getting the installer right and
the editor right does not mean they're going to put 5 minutes into
multilingual Asian input.

    Charles> I've heard again and again from my more technically-
    Charles> capable colleagues about the wonders of Emacs.

Yeah, and they're right.  ;-)  You're also right to be skeptical.
Closing that gap is a lot of what current XEmacs development is about.

    Charles> Linux will continue to remain a platform limited in its
    Charles> usage to a small coterie of IT professionals and skilled
    Charles> hackers, forever being off-limits to the more average
    Charles> end-user like myself, who would have to stay with locked
    Charles> in the Redmond prison.  And the more time I spend on
    Charles> Linux lists, the more I believe that this is precisely
    Charles> the way that most veteran Linuxers would prefer it.

I think that's unfair to Linux users, and even most developers.  As
long as we mostly don't get paid for what we do, though, it's going to
look like we mostly don't much care about the "average end-users".


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
              Don't ask how you can "do" free software business;
              ask what your business can "do for" free software.