Received: by nummer-3.proteosys id <01C19443.4B59AC4C@nummer-3.proteosys>; Thu, 3 Jan 2002 11:42:09 +0100 Return-Path: <@vm.gmd.de:LATEX-L@DHDURZ1.BITNET> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19443.4B59AC4C" x-vm-v5-data: ([nil nil nil nil nil nil nil nil nil][nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil]) X-MimeOLE: Produced By Microsoft Exchange V6.5 x-to: LATEX-L%DHDURZ1.BITNET@uga.cc.uga.edu Content-class: urn:content-classes:message Subject: Re: LaTeX 2.09 beta-test Date: Tue, 29 Oct 1991 21:37:00 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Don Hosek" Sender: "LaTeX-L Mailing list" To: "Rainer M. Schoepf" Reply-To: "LaTeX-L Mailing list" Status: R X-Status: X-Keywords: X-UID: 427 This is a multi-part message in MIME format. ------_=_NextPart_001_01C19443.4B59AC4C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable - from \emtex\doc\english\texware.doc: - - |The /c option - |------------- - - |Currently, only one tcp file is available: 850_tex.tcp. This file = converts - |some characters of code page 850 into TeX commands: - %%%%%%%%%%%% - - |^^80 -> \c{C} ^^81 -> \"u ^^82 -> \'e - |^^83 -> \^a ^^84 -> \"a ^^85 -> \`a - - [many lines of expansion deleted, underpercenting mine] - - This sort of conversion is not possible by changing the - xchar/xord array which assumes a 1-1 mapping of external code - byte to internal code byte. - -Wrong again, Don! Even the original tex.web has a mapping that is -one-one only on the set of printable ASCII chars. qed. Sorry, I'm not a mathematician so I misuse terms all the time. I didn't mean that the mapping was mathematically 1-to-1, but that a single byte must map to a single byte. Check it out. - Yes, but you're still stuck in the PC combatible word with your - TeX file. And you're assuming that your TeX can change its - mapping to the Cork-based internal codes from whatever codepage - you have externally. So chances are that your colleague's emTeX - file won't run with your copy of PCTeX or $\mu$-TeX or TurboTeX - or AzTeX. Let alone when you try to send the file to an ASCII - system like, say, a Mac or VAX or Unix box... If you're going to - use the excuse that you can't reliably send an 8-bit ASCII file - to an EBCDIC system to justify incorporating unnecessary - incompatibilities between TeX implementations, I kind of wonder - what the point of worrying about any sort of TeX consistency is. -So, what's the difference to the previous situation. That means *only* -that you have to go back to the ^^xx convention when you exchange -files BETWEEN DIFFERENT SYSTEMS (not even when you go from a PC to an -IBM RISC). Nothing wrong with that. Rainer, I'm not sure what you're getting at. Let me, however, provide a scenario for you. This is what is happening on one of my contracts: The end goal of all our efforts is to produce a variety of documents for chemical products: bottle labels, boxes, safety inserts, etc. These documents generally have six languages appearing on them (English, French, German, Italian, Japanese and Spanish). The text which appears in the documents is typed in on PCs by the translators and then transferred to a VMS system to be stored in a large database. Database queries produce files which when given to TeX can print the various documents involved. Now, in the production environment, the file output by the database is stored in a directory on the VAX which is accessible both as a VMS directory and =7F{through PCSA as a DOS directory. This allows the user to either run the TeX process on the VAX to produce a final printed label or locally on his PC to print draft output on a local laser printer. The same identical file containing 8-bit ASCII must run under both systems without modification. Am I to write a program which goes through and changes every occurence of C-cedilla to ^^80 before doing this? There seems to be a strong feeling among those involved in this discussion that e-mail is the only transfer mechanism possible for moving files between systems. I'm doing my best to point out that it just isn't so, and there is a real need for being able to deal with the same 8-bit ASCII system across platforms and across TeX implementations. By the way, you qdidn't address the issue of why making chars 128-255 active is so horrible. -dh ------_=_NextPart_001_01C19443.4B59AC4C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: LaTeX 2.09 <Oct 91> beta-test

-   from = \emtex\doc\english\texware.doc:
-
-   |The /c option
-   |-------------
-
-   |Currently, only one tcp file is = available: 850_tex.tcp. This file converts
-   |some characters of code page 850 into = TeX commands:
-       =         =         =         =           %%%%%%%%%%%%
-
-   |^^80 -> = \c{C}           &n= bsp;   ^^81 -> = \"u           = ;      ^^82 -> \'e
-   |^^83 -> = \^a           &nbs= p;     ^^84 -> = \"a           = ;      ^^85 -> \`a
-
-   [many lines of expansion deleted, = underpercenting mine]
-
-   This sort of conversion is not possible = by changing the
-   xchar/xord array which assumes a 1-1 = mapping of external code
-   byte to internal code byte.
-
-Wrong again, Don! Even the original tex.web has a = mapping that is
-one-one only on the set of printable ASCII chars. = qed.

Sorry, I'm not a mathematician so I misuse terms all = the time. I
didn't mean that the mapping was mathematically = 1-to-1, but that
a single byte must map to a single byte. Check it = out.

-   Yes, but you're still stuck in the PC = combatible word with your
-   TeX file. And you're assuming that your = TeX can change its
-   mapping to the Cork-based internal = codes from whatever codepage
-   you have externally. So chances are = that your colleague's emTeX
-   file won't run with your copy of PCTeX = or $\mu$-TeX or TurboTeX
-   or AzTeX. Let alone when you try to = send the file to an ASCII
-   system like, say, a Mac or VAX or Unix = box... If you're going to
-   use the excuse that you can't reliably = send an 8-bit ASCII file
-   to an EBCDIC system to justify = incorporating unnecessary
-   incompatibilities between TeX = implementations, I kind of wonder
-   what the point of worrying about any = sort of TeX consistency is.

-So, what's the difference to the previous situation. = That means *only*
-that you have to go back to the ^^xx convention when = you exchange
-files BETWEEN DIFFERENT SYSTEMS (not even when you = go from a PC to an
-IBM RISC). Nothing wrong with that.

Rainer, I'm not sure what you're getting at. Let me, = however,
 provide a scenario for you. This is what is = happening on one of
 my contracts:

 The end goal of all our efforts is to produce a = variety of
 documents for chemical products: bottle labels, = boxes, safety
 inserts, etc. These documents generally have = six languages
 appearing on them (English, French, German, = Italian, Japanese
 and Spanish). The text which appears in the = documents is typed
 in on PCs by the translators and then = transferred to a VMS
 system to be stored in a large database. = Database queries
 produce files which when given to TeX can print = the various
 documents involved. Now, in the production = environment, the file
 output by the database is stored in a directory = on the VAX which
 is accessible both as a VMS directory and = =7F{through PCSA as a
 DOS directory. This allows the user to either = run the TeX
 process on the VAX to produce a final printed = label or locally
 on his PC to print draft output on a local = laser printer. The
 same identical file containing 8-bit ASCII must = run under both
 systems without modification. Am I to write a = program which goes
 through and changes every occurence of = C-cedilla to ^^80 before
 doing this?

There seems to be a strong feeling among those = involved in this
discussion that e-mail is the only transfer mechanism = possible
for moving files between systems. I'm doing my best = to point out
that it just isn't so, and there is a real need for = being able to
deal with the same 8-bit ASCII system across = platforms and across
TeX implementations.

By the way, you qdidn't address the issue of why = making chars
128-255 active is so horrible.

-dh

------_=_NextPart_001_01C19443.4B59AC4C--