Return-Path: Received: from [209.213.214.135] (account ) by vsu.ru (CommuniGate Pro WebUser 3.5.9) with HTTP id 930481 for ; Sun, 16 Jun 2002 23:41:53 +0400 From: "Vladimir Volovich" Subject: Re: Russian/Polish/German...without switching To: CyrTeX-en@vsu.ru X-Mailer: CommuniGate Pro Web Mailer v.3.5.9 Date: Sun, 16 Jun 2002 23:41:53 +0400 Message-ID: In-Reply-To: <200206160424.g5G4OqD09901@beryl.math.u-psud.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R" Content-Transfer-Encoding: 8bit On Sun, 16 Jun 2002 05:24:52 +0100 (WEST) Laurent Siebenmann wrote: > > first, i wonder, how you can make a distinction (say color) in your > > editor for German A and Polish A for text files?? text files do not > > have any additional structure besides characters. > > Knuth once threw a curveball in a TeX meeting by arguing that > font glyphs should include arbitrary default coloring; that ran > counter too all current work in TeX -- which imposed color by > external color-switch commands and (usually) a color stack. this is another issue (typesetting color), and i see no relation of this to the "color" in TeX's source text files. > Maybe I too am swimming against the current. But recently, most > operating systems have begun to invent new notions of font for > the coming era of 16 and 32 bit fonts. I am daring to imagine > that some of the screen fonts will be able have default color > for the characters. It is in such a world, that my notion of > the "stacked 16 bit multilingual" screenfont lives most > comfortably. the source files for TeX are plain text files, and whatever sophisticated features your editor will use (including double fork format on Mac to mark characters in different colors), you have to feed TeX with _plain text files_ which have no possibility to store anything but characters. > There would be no language switches in multilingual text. > Rather the parts of the big font for Russian, French and > English respectively would be disjoint and color coded. If > keyboards are to stay roughly as they are today, one might > switch language with one of the dozen or more function keys > always available (mostly unused it seems). but what encoding would these disjointed files use? it will not be unicode (neiter utf-8 nor utf-16 or whatever), because in unicode all latin letters are jointed. it must be some weird custom home-made encoding which will support only the fixed number of languages, and there must exist a specially-written text editor which will do all this color sepatarion stuff, and later translate it to that home-made encoding before feeding it to TeX (or Omega). i'd like to emphasize that the encoding where latin letters are separated for different languages (as well as cyrillic, e.g. for Russian and Ukrainian) has to be non-standard and custom (specific to the languages being used), because all existing character encodings do not support the disjoint latin alphabet for different languages. > There is a conceptual difference between the insertion of > switching commands and the use of "switched" type. Something > like the difference between a function and its derivative. > It makes a difference both to the typist/author and to the TeX > programmer-typographer. in your editor you have to use some keystrokes (or mouse clicks) to switch from one "color" (language) to another. i wonder why you think that having that is simpler than type a few characters of a macro to switch to another language. all this: home-made encoding, font coloring, special editor (so not everybody will be able to use the TeX source files written in that home-made encoding), special VF fonts, etc is IMHO only a big mess created for the only purpose of having good hyphenation in pseudo-transparent way (pseudo because you will use keystrokes/mouse/etc to "color" text, which is essentially the same as using explicit markup commands). Best, v.