[tex-live] Technical showstoppers for TL2003

[Hans Hagen]

At 03:13 14/09/2003 +0400, Vladimir Volovich wrote

>exactly - verbatim environments are a special case compared to
>"regular" writes which are supposed to be read back by TeX and by
>writes supposed to be read by third-party applications.
>
>in the above example, the portable way to write to file would be:
>
>abcd\textbackslash eacute \'e \textasciicircum \textasciicircum ef
>
>where \textbackslash typesets the `\' character and \textasciicircum
>typesets the `^' character. when this is read back by TeX, it will
>typeset verbatim what was between the \startbuffer and \stopbuffer.
>and it is not hard to do that at the macro level...
>(yes, here we use one escape character - `\').

i'm not going to explain that to authors -) when they (someplace) in their 
document define their input encoding, it should be enough for them to work 
according to that;

actually, the whole tcx thing can be pretty unportable: when i implemented 
support for some languages, and ended up in constant misundertandings about 
what code to attach to what character it proved to be that those that i 
communicated with were using --translate things (so, not in the doc, but at 
the command line) without even knowing what it did and so without telling 
me about it; even when i asked if some translation took place (which was 
what i suspected) they didn't tell/notice, so for me the main thing is 
"let's make live comfortable for users" (how many users know about 
locales's? esp now that linux is going gui in quite fuzzy ways);

(either we aim at programmers and low level code hackers, or we aim at 
users, and it's my impression that tex live aims at users)

>writing files which are intended to be read by "3-rd party programs"
>(not by TeX) is another case which could also be programmed at the
>macro level - it's possible to make all characters expand "as is" for
>such applications (then it will depend on cp8bit TCX to be able to
>output raw 8-bit chars)... i.e., there are two kinds of writes - the
>ones which are supposed to be read back by TeX (which should use
>"portable" representation), and ones for "3-rd party programs" which
>may/should use the 1-to-1 representation.

hm, this would be ok if tex has a flexible mechanism for changing the 
mappings on the fly (i've played with these things a lot so ...) and 
whenever discussions about such mechanisms / extensions pop up, they slowly 
fade aways due to all kind of objections; so, i wanna stick to 8-in 8-out -)

>  HH> or think of
>
>  HH> \startMPcode draw btex whatever kind of french accented text you
>  HH> want etex ; \stopMPcode
>
>well, btex ... etex is supposed to be processed by TeX, so the
>"portable" encoding as in the first example should work just fine.

sure, but it happens that there is no way to feed back the --translate into 
the mp subsystem, so one depends on 8 bit plus macro based input encoding 
directives; also, the --translate does not work well for documents with 
mixed encodings (think of a german - french - chinese document where the 8 
bit char may depends on the language as well, i would not like to see utf 
codes to be translated into ^^'s)

>thus us again something for 3rd party apps; actually, hyperref package
>for LaTeX contains very good code which converts any string from LICR
>to pdfdoc encoding.

hm, i probably had that kind of support (and beyond) in context before 
hyperref did -)

Hans
-------------------------------------------------------------------------
                                   Hans Hagen | PRAGMA ADE | pragma at wxs.nl
                       Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
  tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com
-------------------------------------------------------------------------
                        information: http://www.pragma-ade.com/roadmap.pdf
                     documentation: http://www.pragma-ade.com/showcase.pdf
-------------------------------------------------------------------------