On Vietnamese Character Encoding

A collection of my posts from 30+ years ago (!) that I found on soc.culture.vietnamese. Reproduced here for old times’ sake. I’m not sure how best to organize these yet.

Date: Oct 29, 1992, 8:11:44 AM
From: Cuong T. Nguyen
Subject: [TECH] On VISCII and VSCII

\V
Dear James:

Your criticism of VISCII centers on the C0 encoding, which I must
again note has been very carefully laid out to minimize conflicts
on various platforms.

Let's be specific. You cited existing Windows applications where
C0 cannot be used, which necessitates the use of capital fonts.
What is done in VSCII to solve this problem? Think about this
carefully, and in real-world, not theoretical terms.

(a) Clearly one cannot use VSCII-1, -2, or -3 in Word for Windows.
VSCII-1 and -3 are both floating marks (unusable), and VSCII-2
has been arranged with total disregard for integration (for
one thing, it uses C0 in very unfortunate locations).

(b) If one were to develop a new application (i\.e, not attempt
the integration route), then all bets are off. All criticisms
that any code cannot work are meaningless, for I can write
an application to support C0 codes as well as the next guy\.
In this sense VISCII is perfectly capable of representing all
Vietnamese letters in untagged data streams. We should stop
criticizing each other in this context, with regards to how
the 134 characters are laid out.

The difference between VISCII and VSCII (and previous precomposed
tables) is that the arrangement of characters in VISCII has been
done with careful thought of conflicts with existing software
on multiple platforms, in order to minimize the frequency of
conflict. Criticizing Viet-Std's VISCII for its imperfections
is like criticizing democracy---it's easy to do when one doesn't
have to offer a better alternative\.

To follow this point further, did you know that even if we
Vietnamese didn't have to deal with the 6 "extra" letters, there
would still be the _same_ integration problems with many C1 and G1
codes? This is another thing VSCII does not ad\dress. The
catchword "C0" is just a theoretical red herring.

> VSCII aims to do what its name stands for -- a Vietnamese Standard Code
> for Information Interchange, repeat *Information Interchange*. Maybe
> someday it can improve enough, with contributions from people
> everywhere, to become a processing code as well.

You are saying here very clearly that the present VSCII proposal
is intended only for information interchange, and not processing.
Please correct me if I am taking this out of context. To me this
means VSCII has no intention of being used as the basis for internal
coding, for example, the WM_CHAR codes used while one types into
Word for Windows (and therefore VSCII does not try to ad\dress the
concomitant conflicts). It is only intended for a user giving or
sending a data file to another user, i\.e\., for interchange purposes.
If this is the case, we are all barking up different trees.
With that I note for Viet-Std VISCII:

(a) VISCII is a processing code that works with minimal conflicts
in existing environments, as evidenced by the VISCII-compliant
software base on various platforms.

(b) VISCII is indeed intended for information interchange as
well. As I have noted on numerous occasions, bits are bits
are bits, and VISCII data can be easily interchanged using any
of the available transfer protocols.

(c) VIQR is only a representation specification, intended to
bridge the gap between 7-bit ASCII and 8-bit VISCII, which is
necessary in the context of 7-bit mail gateways and keyboarding.
It has the advantage of being readable, e\.g., "Vie^.t Nam."

> I share your thoughts. And I\'m doubly glad that you have finally agreed
> with me that the tone and focus of this discussion should be and are on
> technical issues, leaving politics aside\.

Please don't "pull a Bill Clinton" on me [with humorous apologies
to the Clinton crowd, or maybe the Quayle crowd :-)]. If we are
to focus on technical issues, we can do without this double talk.

Thanks,

Cu+o+`ng
\L