LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Hans Aberg <[log in to unmask]>
Sun, 13 May 2001 21:32:35 +0200
text/plain (32 lines)
At 15:18 +0200 2001/05/13, Lars Hellstršm wrote:
>>> This is why current LaTeX converts everything to
>>>LICR before it is written to the .aux file: the elements of the input
>>>encoding (as Frank called them above) do not have a single welldefined
>>>meaning. What has been discussed is that one might used some form of
>>>Unicode (most likely UTF-8) in these files instead.
>>Forget everything about variable sized characters as far as the extension
>>of TeX goes, and hook onto translators outside that recognize other
>>formats. Variable sized characters just complicates programming.
>Well, the \InputTranslation and \OutputTranslation primitives of Omega
>already provide that functionality, so there is no need to deal with
>variable-sized characters in the TeX programming. The problem is that one
>might want to employ additional sets of translations (which would then act
>on streams of equally-sized characters) between those extremes of the
>program, but Omega doesn't provide for this.

I am not sure what you mean here: UTF-8 is variable sized.

I suggested that for every file not using a 32-bit character type, one has
an additional file (in ASCII) identified by some kind of file name ending
with information about the encoding. (For example, if the file "<name>" is
not 32-bit, is there si also an ASCII file named "<name>.encoding".)

This way, one can provide as many IO code converters as one bothers to
write, without the extended TeX ever knows anything about it. (If Omega
uses C++ for IO, one can use something called a codecvt. Or use pipes,
where available.)

  Hans Aberg