From: MAILER-DAEMON@haydn.Stanford.EDU (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Originator: daemon@media-lab.media.mit.edu
Reply-To: root@haydn.Stanford.EDU
Organization: SCV Relay
Date: Wed, 11 Nov 1992 00:54:40 GMT

   ----- Transcript of session follows -----
>>> RCPT To:<rnews@ucbvax.berkeley.edu>
<<< 550 <rnews@ucbvax.berkeley.edu>... User unknown
550 rnews@ucbvax.berkeley.edu... User unknown

   ----- Unsent message follows -----
Received: by haydn.Stanford.EDU (5.57/Ultrix3.0-C)
	id AA17076; Thu, 29 Oct 92 21:28:01 -0800
Date: Thu, 29 Oct 92 21:28:01 -0800
From: daemon (Cuong T. Nguyen)
Precedence: special-delivery
Apparently-To: rnews@ucbvax.berkeley.edu

NPath: haydn!cuong
NFrom: cuong (Cuong T. Nguyen)@haydn
NNewsgroups: soc.culture.vietnamese
NSubject: Re: [tech] VISCII and VSCII
NDate: Thu, 29 Oct 92 21:09:53 -0800
NMessage-Id: <17075.212800@haydn>
NSender: cuong@haydn (Cuong T. Nguyen)
NReply-To: cuong
NDistribution: world
NOrganization: Center for Integrated Systems, Stanford University
N
N\V
NDear James:
N
N> 1/ Graphic characters allowed in C0-space: VISCII works fine\. Examples
N>    include such "lenient" applications as Microsoft Word for Windows
N>    (and Macintosh) or Aldus FreeHand;
N
NThis sounds very authoritative, but it is also incorrect in
Nthe reference to Microsoft Word for Windows.  It is among the
Nleast "lenient" Windows applications I have tested, with conflicts
Nin C0, C1, and G1.  I won't pretend that I am myself a Mac expert
Nso will only comment on what I know for certain.
N
N>>   Let's be specific.  You cited existing Windows applications where
N>>   C0 cannot be used, which necessitates the use of capital fonts.
N>>   What is done in VSCII to solve this problem?
N> 
N> The VSCII documents specify the use of the precomposed character where
N> possible, or the use of its equivalent composite character -- ie, the
N> base form followed by the combining tone mark -- where the precomposed
N> character cannot be used. Just design VSCII fonts so that the glyphs
N> for the combining tone marks are of zero width with negative x-overhang.
N
NI should have feared we would come full circle to this.  Besides
Nhaving problems with existing applications, this also corners the
Nthe user into using ugly glyphs.  The thing users care most about
Nis not any of this "nonsense" with standards (I hope this will not
Ntaken out of context), but how nice their documents look, e\.g.,
Nwhether the marks are correctly placed and proportionally sized.
NThere is no way to encode all of the nuances of diacritical mark
Nsizing and placement with the simplistic negative-space technique\.
NUnless, of course, (a) one reserves multiple codepoints for all
Nthe possible placements, or (b) one writes a Vietnamese-aware
Napplication.  Option (a) is silly [1], and with option (b) I would
Nrather be dealing with a precomposed code to begin with.
N
NWhy am I talking about glyph rendering when we are discussing
Ncharacter encoding?  Because that's what the user cares about,
Nand the user is the one we are trying to satisfy\.
N
NWe have consulted with Vietnamese software vendors very early on
Nwho have all considered and rejected this approach.  After all,
Nthey are all intelligent people who make a living doing this---they
Nmust know something.  Our experience gives similar conclusions.
NThis discussion is deja` vu, and I fear some netter will soon
Ncomplain about bandwidth.
N 
NIn any case, could you reply to the point of greatest interest
Nand relevance:
N
N>> --------James wrote:--------
N>> VSCII aims to do what its name stands for -- a Vietnamese Standard Code
N>> for Information Interchange, repeat *Information Interchange*. Maybe
N>> someday it can improve enough, with contributions from people
N>> everywhere, to become a processing code as well.
N 
N> --------Cu+o+`ng wrote:--------
N> You are saying here very clearly that the present VSCII proposal
N> is intended only for information interchange, and not processing.
N> Please correct me if I am taking this out of context.  To me this
N> means VSCII has no intention of being used as the basis for internal
N> coding, for example, the WM_CHAR codes used while one types into
N> Word for Windows (and therefore VSCII does not try to ad\dress the
N> concomitant conflicts).  It is only intended for a user giving or
N> sending a data file to another user, i\.e\., for interchange purposes.
N
NAre you (a) backing away from your earlier statement, or (b) standing
Nby it?  We both know very well it is a very important distinction.
NIf (b) is the case, can this language be written into the VSCII
Ndocumentation so that there is no confusion, as there was a while
Nago between a glyph table and a character encoding table (used for
Ninternal processing)?
N
NThanks,
N
NCu+o+`ng
N--------
N[1] One might try to get away with two sets of marks, one for
N    upper- and one for lower-case letters, but even that still
N    doesn't live up to typography standards.
N\L

Newsgroups: soc.culture.vietnamese