Hello, Werner Lemberg wrote: > > Because of this, it is possible, for example, to `combine' one > > of european languages (most offten English) and Russian language > > as a *one* `combined' language. > > `Combined' may be a solution for Russian but not for, say, Georgian. Yes, of course. It is one of possible configurations which can be used for e.g. russian+english documents (the case which is used very often). I meant the following: if somebody uses _only_ russian as a language with letters with codes > 0x80, then _why_ should he have in mind some `default' lccode+uccode settings for charactets > 0x80, especially if these settings conflict with the common russian encodings? IMHO in this case it is not too bad to allow to change lccodes+uccodes. At least, I think that LCY encoding which is currently used in LH fonts should be defined in Babel (among other cyrillic encodings encluding T2). And in this LCY encoding it is very useful to have russian letters to stay _real_ letters (not active chars). And therefore one needs to change lccode and uccode before switching to LCY (and restore the defaults before switching to another language). I'm finishing this work now. Moreover, do the _one_ default lccode+uccode settings conform to _all_ languages (which are already TeXized)? > > Next, when somebody uses Russian language in his TeX document, > > very offten the other language(s) used in the same document > > will have the codes of it's letters below 128. So, > > why not to allow Babel to change lccodes for Russian > > in this case? > > Why not define a proper font encoding and using vf fonts if people are too > lazy to recompile the LH fonts with a proper font encoding? Ok, probably this will be the `final' solution, but here are also some problems. If we will have the TeX's internal encoding for _letters_ of some language different from the _native_ encoding(s) used in this language (i.e. encoding, which is used to typeset the documents in text editors, and which is built into screen fonts, etc.), then we will have to perform a translation from the language-native encoding into TeX's internal encoding. This can be done in different ways: 1) do this transliteration `on the fly' by means of external tools before sending text to TeX (and also before examiming TeX's logs). This approach is not ideal, but it can be used. 2) use TeX Code Pages (TCP). This has advantage because it is universal, and lets us preserve catcodes of translated characters. But TCP are not supported by all TeX implementations. 3) declare all _letters_ of this language to be non-letters (!) from the TeX's point of view -- i.e. declare them active characters. But this approach has some disadvattages: * letters are now `not letters' -- so it becomes impossible to define and use macroses with names consisting of letters of this language. * TeX log files become unreadable (because our fonts have encoding different from TeX's internal encoding). So it becobes very tricky to work with TeX. This, again, can be avoided by translating TeX log files `manually', but this approach is not applicable to all users... * there probably will be problems with aux, toc files and index files. May be, I'm wrong? BTW, how one can make virtex (I use NTeX under Linux) or teTeX to show characters with codes above 0x80 as normal characters? In the case of emtex, it is possible to use options like `-o' and `-8'. But I didn't find the way to do this with virtex. > this third language must of course also follow the default \lccode and > \uccode values in the ASCII range. As long you don't have more than 256 > characters in your alphabet (including punctuation marks) this IS > POSSIBLE! I did not catch what you meant. Do you mean that all cyrillic characters will not fit into T2 table, so there will be two tables? > [BTW, there is no `high half' of ASCII! ASCII is a 7bit encoding...] Yes, of course. :-) I did not find the proper word to say about the whole 256-character table. > I've complete font encoding support for LH encoding with the `fil' option > at home. But I have decided not to publish them because of the problems > with other Cyrillic languages. IMHO it is better to publish them because unfortunately babel is currently not commonly used in Russia because of it's incopleteness (for russian language). And some other not very good hacks (for russification) are becoming a de facto standard. :-( > I want to change my own code to T2. BTW, do you have the new alpha version of LH fonts (with T2 encoding)? -- With best regards, Vladimir.