X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["7690" "Tue" "4" "June" "1996" "22:41:43" "+0200" "Frank Mittelbach" "Frank.Mittelbach@UNI-MAINZ.DE" nil "183" "Re: latex/2071: Latex fuer Vietnamesisch" "^Date:" nil nil "6" nil nil nil nil] nil) Received: from listserv.gmd.de (listserv.gmd.de [192.88.97.1]) by trudi.zdv.Uni-Mainz.DE (8.7.5/8.7.3) with ESMTP id AAA17794 for ; Wed, 5 Jun 1996 00:23:19 +0200 (MET DST) Received: from listserv.gmd.de by listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <12.A7B52DAC@listserv.gmd.de>; Wed, 5 Jun 1996 0:23:17 +0200 Received: from URZINFO.URZ.UNI-HEIDELBERG.DE by URZINFO.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 85260 for LATEX-L@URZINFO.URZ.UNI-HEIDELBERG.DE; Tue, 4 Jun 1996 23:12:03 +0200 Received: from ix.urz.uni-heidelberg.de (root@aixterm1.urz.uni-heidelberg.de [129.206.119.41]) by relay.urz.uni-heidelberg.de (8.7.5/8.7.4) with SMTP id XAA04990 for ; Tue, 4 Jun 1996 23:11:44 +0200 (MET DST) Received: from kralle.zdv.Uni-Mainz.DE by ix.urz.uni-heidelberg.de (AIX 3.2/UCB 5.64/4.03aixterm1) id AA47578; Tue, 4 Jun 1996 23:11:27 +0200 Received: from frank.zdv.uni-mainz.de (Ufrank@localhost) by kralle.zdv.Uni-Mainz.DE (8.7.5/8.6.12) with UUCP id WAA01290; Tue, 4 Jun 1996 22:53:01 +0200 (MET DST) X-Authentication-Warning: kralle.zdv.Uni-Mainz.DE: Ufrank set sender to frank.zdv.uni-mainz.de!latex3 using -f Received: (from latex3@localhost) by frank.zdv.uni-mainz.de (8.6.9/8.6.9) id WAA19172; Tue, 4 Jun 1996 22:41:43 +0200 References: <199606031858.UAA17920@frank.zdv.uni-mainz.de> <199606041337.PAA06972@c210.edvz.uni-linz.ac.at> Message-ID: <199606042041.WAA19172@frank.zdv.uni-mainz.de> Reply-To: Mailing list for the LaTeX3 project In-Reply-To: <199606041337.PAA06972@c210.edvz.uni-linz.ac.at> Date: Tue, 4 Jun 1996 22:41:43 +0200 From: Frank Mittelbach Sender: Mailing list for the LaTeX3 project To: Multiple recipients of list LATEX-L Subject: Re: latex/2071: Latex fuer Vietnamesisch Status: R X-Status: X-Keywords: X-UID: 1753 Werner, > > this is not the ltx3 mailing list. this list was created to help > > people dealing with daytoday issues of latex(2e) but not necessarily > > to spawn discussions on extensions to 2e or issues that involve > > latex3. In other words this list is normally not actively monitored by > > the project team. > > Sorry, it was a mistake. it even states: Mailing list for the LaTeX2e Betatest :-) in fact i'm only on it because David forwarded me your earlier mail on that topic with the comment that this is something I probably want to discuss. (and indeed it was still on my TODO folder (which is the one i try to empty after the ANSWER one (which is the one i deal with after the THIS-WEEK one (which is ... > > as for producing an official encoding for Vietnamese fonts: there has > > been already some attempt (see LaTeX bug data base pr/2071) but we > > felt it needs some more work. I suggest that you contact these people > > as well, to join forces or at least to look at their suggestions. > > I've contacted the author, but his fonts are something like T5 and not OT5. okay, here comes the first catch. I really think that there need to be a standard naming convention for the glyphs when they go into what i call official. in other words i hope that you could come to some conclusion that fits the general principles we tried to implement and that then later documents written originally for OT5 could be processed without change at sites that use T5. > Please check my proposal in ftp.tex.ac.uk/incoming. I'll ask Robin to > install the fonts and the LaTeX macros (marked as `draft') so we have a > common basis to talk about. could we deal with that after the upcoming latex release? I'm tied up to my ears with work > > from a pragmatical point of view diacritical marks (as individual > > glyphs) actually don't need to be in the same physical font (they > > could be fetched from a companion font such as an TS1 encoded font)it > > is only for convenience to have them in the same font---NFSS will > > handle that correctly. I'm not suggesting that this is necessarily the > > best choice, but it might be better than throwing out chars that would > > be able to participate in hyphenation etc. > > Vietnamese can't be hyphenated :-) good for it so my argument is nil in this respect (but that doesn't change the argument on uc/lc unfortunately) > `A circumflex' can have five tone-marks. Another combination is > > A breve with tilde > > but this tilde is not necessarily centered; i.e. combination for e.g. French > would produce funny results. In VISCII encoding, there are _only_ composed > letters, not a single Vietnamese tone mark. Thus I decided to use names like > \vntilde etc. for fake accents. This works very well. can i understand that as roughly \~{\v a} or vice versa (not that this would work and given the the marks might not be placed on top of each other)? > A better solution? well, if we stipulate that `a' is a major part of the letter a possible naming convention could be something like \textfoobar{a} where foobar would denote the combination of "breve with tilde" that could work if sensible names for such combinations exist and there aren't too many of them. but it might be in fact that one would like something like \textfoo{\textbar{a}} (with \textbar perhaps being \v or \~) At the moment DeclareComposite assumes a single char or a single command in its third argument, eg \DeclareTextCompositeCommand{\foo}{T1}{a}{bar} but perhaps that is not general enough. It might be that it is better to say that this argument must accept a general encoding-specific command and since \"a and so one denote glyphs they must be accepted there. (in fact they are if we leave out the inner brace, i think, eg, \textfoo{\~a} but this isn't a stable implementation as such usage was not forseen.) A third alternative would be to accept that the Composite support is not general enough and that it needs extension in the sense that one can specify more than one diacritical mark somehow. ==== all that basically should say that a) i have no idea what i'm talking about as far as vietnamese fonts are concerned, b) that nevertheless there are important questions that need to be addressed in its entirety, otherwise you end up with a situation comparable to babel (which started from different principles and concepts and although Johannes did some heroic work to cut through all those historic code from german.sty french.sty you name it it more or less is just one level of patches on top of others and still many aspects don't and can't function together.) anyway, any such internal presentation would resolve the lc/uc problem as the uppercasing would happen via a -> A. just as it works for for \" and friends. I can only repeat that an encoding is more than just the name so please let's think about those issues while we have a chance. (that is could we move that dicussion to latex-l ?) === from your other reply to David > > Please do not allocate new encoding names beginning T or OT in this > > way. The names end up being part of the file names of the LaTeX system > > and so it is very important that a central registry of these encoding > > names is kept to ensure document portability. encoding names L... can > > be used for `local' encodings until a new encoding is registered. > > Well, how long will such a registration last? Who will decide? last? I hope that once it is made official including all the internal names of the text-specific commands it lasts as long as LaTeX, and that's why i don't like to rush it and making non-reversible mistakes. but perhaps you meant how long will it take to decide? until we feel satisfied that fits into the framework. who will decide? some arrogant bastards calling themselves the LaTeX3 project team and maintaining LaTeX (in case case somebody feels insulted from that team, then say I decide and also take the blame). don't misunderstand what i'm saying this is horribly difficult with email. as the maintainers and the authors of the input/output encoding concept we kindly ask the world in the interest of a stable and maintainable LaTeX not to rush forward and privatly design and or announce encodings with certain names. we can't force you to obey this wish but we really hope everybody does. as i said I'm also be prepared to take the blame for what works or doesn't so give me a chance my experience with working on LaTeX is that it is an enormous complex architecture so that in most cases in the interest of the general community one has to be very careful in the interface design and that often people do see just their private needs. What we try is to mediate between all these interests and that can be quite painful. as long as a new encoding is in a test phase it is better to give it some other name, eg EO5 (experimental may become OT5 or whatever) it doesn't really matter. that allows easier experimentation and the final release will then at most mean changing a single line in the document (or more if command names would change) but in any case we are not back to the days where official LaTeX 19xx can't understand \foo 19xy does and 19xz has a different opinion what it means does that sounds sensible? > Binh did not create the font encoding files correctly. After finishing it agreed it does need further work and that is why i suggested to him to get in contact with other people working on those issues. frank ps i have copied this to latex-l (the original discussion appeared on the latex2e list) and i would prefer to see any continuation happen there.