diff options
author | Norbert Preining <norbert@preining.info> | 2019-09-02 13:46:59 +0900 |
---|---|---|
committer | Norbert Preining <norbert@preining.info> | 2019-09-02 13:46:59 +0900 |
commit | e0c6872cf40896c7be36b11dcc744620f10adf1d (patch) | |
tree | 60335e10d2f4354b0674ec22d7b53f0f8abee672 /info/digests/tex-implementors/037 |
Initial commit
Diffstat (limited to 'info/digests/tex-implementors/037')
-rw-r--r-- | info/digests/tex-implementors/037 | 716 |
1 files changed, 716 insertions, 0 deletions
diff --git a/info/digests/tex-implementors/037 b/info/digests/tex-implementors/037 new file mode 100644 index 0000000000..f19a3018a3 --- /dev/null +++ b/info/digests/tex-implementors/037 @@ -0,0 +1,716 @@ +Date: 14 March 91 Message No: 037 + +To: TeX implementors and distributors + +From: Barbara Beeton + +Subject: Messages from DEK, part 2 + + +************************************************************************ + +>>> inconsistent expansion of \string, etc.; \newlinechar + + [ dek: + Here he has come across exactly what I think I fixed in the + _other_ change made to 3.14a. I am contacting him directly + about this. + ] + +Date: Mon, 4 Nov 91 10:42:40 +0100 +From: Bernd Raichle <raichle@azu.informatik.uni-stuttgart.de> +Subject: TeX.web 3.14: Bug Report #1 (+ Fix Proposal): \string, + \special, ... + +Dear Ms. Beeton, + +I have found two bugs in TeX.Web 3.14: +Bug #1: Incorrect "expansion" of unprintable chars for |selector=new_string| +Bug #2: Incorrect handling of \newlinechar + (I'll send a second mail with the report of bug #2.) + + +The first bug looks like an inconsistent behaviour of \string (and +\meaning, \fontname, \jobname, \special) in all TeX versions. + +Example: +1. \catcode`\^^Y=12 \string^^Y +2. \catcode`\^^Y=13 \string^^Y + +TeX 3.14 prints line 1 always as character "19 of the current font. +Line 2 is printed either as char"19 or as three characters ^^Y, +dependent on the TeX implementation! + + +Other examples: +3. If ^^Y has one of the catcodes 1-4, 6-8, 11 or 12 + |\string ^^Y| is printed like |\char"19|. +4. With \escapechar="19, the output of |\string\relax| is + either like |^^Yrelax| or |\char"19 relax|. +5. The same is true for \catcode`\^^Y=11 \string\test^^Ytest +6. \newlinechar=`\^^Y \message{^^Y \string ^^Y} outputs two newlines + only, if ^^Y is a printable character. + (Remark: I have discovered the second bug with a variation of + this example.) +7. The same is true for things like \special{^^Y}. +8. etc. for other characters (e.g. national characters)! + + +An TeX implementor can (and should) change section 21 and 22 +(character set translations) and section 49 (unprintable characters) +to make TeX more user friendly. The predicate in section 49 specifies +if a characters is printable or unprintable. +Example: \ss (= char "19 in CM fonts) should be output as a single +character instead of ^^Y. An implementor will change section 49 to +exclude this character (i.e., to make this character printable). + +[With TeX 3 this is done for more and more characters on more and more +machines with extended character set (especially if the new DC/EC +fonts with national characters are available).] + + +This implementation dependency is no problem (*), if the output is +printed on a terminal or written in a file (log file or output +stream). [(*) see the second bug report for some problems] + +But it can be a problem, if it is "printed" for further `internal' +use (i.e., with |selector:=new_string|). + +Example: + \def\a{\expandafter\b\string} + \def\b#1{{\tt #1}} + +The output (in the dvi file) is implementation dependent, if \a is +called with national characters, control sequence names with national +characters, etc. +The dvi file will also be different, if someone uses \special commands +with national characters. E.g. \special{^^Y} should put one byte +with value "19 into the dvi file, but for most TeX versions the three +characters "^^Y" are written. + +Fix proposal: + +|print| and |slow_print| (\S 59,60) should print a single character +without using |str_pool| if |selector = new_string|. (I.e., the +`expansion' of unprintable characters to ^^X or ^^xx is inhibited.) + + procedure print(s : integer); + label exit; + var j : poolpointer; + begin if s >= str_ptr then s:="???" + else if s < 256 then + if s < 0 then s:="???" ++ else if selector = new_string then ++ begin print_char(s); return ++ end; + else if (s = new_line_char) then + if selector < pseudo then + begin print_ln; return + end; + j:=str_start[s]; + while j < str_start[s+1] do + begin print_char(so(str_pool[j])); incr(j); + end; + exit: end; + +... and the same for |slow_print|. + + +Additional changes: + + |issue_message| (used by \message and \errmessage) calls |print| +and |print_err|. Because the string argument can contain unprintable +character with the fix above, it has to be replaced by |slow_print|. +Additionally the |print_err| call has to be replaced by a call to a +new procedure |slow_print_err|, which calls |slow_print| instead of +|print|. + I don't know, if it's better to print strings like |job_name|, +|log_name|, |font_name()|... with |slow_print| (This could be a third +bug?). If this is true, the string |formatident| has to be printed +with |slow_print|, because it incorporates |job_name|. + All other strings `printed' with |selector:=new_string| are either +made out of internal strings and integers or they are used only +temporary (|special_out|, |ship_out|) or printed with |print_esc| +(|font_id_text()|), so they do not need further changes. + + +Possible problems: + +- Perhaps some macro writers assume the current behaviour of \string et.al. + I.e., they assume that \string expands to a fixed set of "printable" + characters only (e.g. for verbatim text like {\tt \string\foo}), + but this set of printable characters changes if section 49 is changed. +- The behaviour of \message and \errmessage will change: \newlinechar + has an effect to these primitives (the TeXbook describes only the + effect for \write). +- I have made and tested the changes above... and this changed TeX + passes the Trip-Test without problems. Perhaps it would be a good + idea to add checks for \special and \string with arguments containing + unprintable characters to `trip.tex'. + Additionally there should be a short note, that the Trip-Test can + produce a different output, if section 49 is changed. The output + is different if one of the characters ^^@, ..., ^^82, ... is + printable. + + +Yours, + Bernd Raichle + __________________________________________________________________________ + Bernd Raichle, Student der Universit"at Stuttgart | "Le langage est source + home: Stettener Str. 73, D-W-7300 Esslingen, FRG | de malentendus" + email: raichle@azu.informatik.uni-stuttgart.de | (A. de Saint-Exupery) + ------- + +Date: Mon, 4 Nov 91 10:43:42 +0100 +From: Bernd Raichle <raichle@azu.informatik.uni-stuttgart.de> +Subject: TeX.web 3.14: Bug Report #2 (+ Fix Proposal): \newlinechar + +Dear Ms. Beeton, + +here is the report of the second bug. I have found this bug when +experimenting with examples (to test the behaviour of \message and +\write) and possible fixes for the first bug. + +The second bug deals with \newlinechar and the inconsistent behaviour +of \message and \write when it is set to some "exotic" values. + +Example: + + \catcode`\^^Y=11 \edef\test{\string\t^^Yt} + % (1) + \newlinechar=`\^ + \message{^^Y ^ \string\^^Y ^ \test} + \immediate\write0{^^Y ^ \string\^^Y ^ \test} + % (2) + \newlinechar=`\^^Y \escapechar=`\^^Y + \message{^^Y \string ^^Y \relax} + \immediate\write0{^^Y \string ^^Y \relax} + % (3) + \newlinechar=`\o + + +The output of this example is implementation dependent! The output +differs, if section 49 of TeX.web is changed to make the character ^^Y +printable. + +1. In part (1) of the example, the character ^^Y is printed as two + newlines followed by a `Y' (if ^^Y is unprintable). The same + aplies for all other ^^Y characters, even for ^^Y characters + inside control sequences. +2. The same ^^Y character is printed as character |xchr["19]|, if + section 49 is changed to make it printable. +3. The output of \write and \message in part (2) differs, if ^^Y is + unprintable. \message produces three |^^Y|, \write prints + three newlines. +4. There is no difference between \write and \message in part (1) and + (2), if character ^^Y is made printable. + +(Remark: the TeXbook doesn't mention \newlinechar w.r.t. \message, so +one could assume that changing \newlinechar will not change the output +of \message (and \errmessage).) + + +What behaviour should be correct for |print|, |slow_print|, ... +w.r.t. \newlinechar, if something is printed to a file or the +terminal? + +Here are my wishes: + +1) if one of these functions is called with the current \newlinechar, + it should output a newline. +2) if a tokenlist printed with \write, \message, \errmessage contains + a \newlinechar, it should be printed as a newline. +3) _all_ other characters should never produce a newline character + (even if there are unprintable characters and \newlinechar = `\^ !) +4) control sequence names containing a character equal to the current + \newlinechar should not produce a newline (a user should use \string, + if the newline character in the csname should produce a newline) +5) all fixed strings printed to the log file should never produce a + newline. I think error messages in the log file should be readable + for all values of \newlinechar! I have added part (3) in my example + to show the current (mis-)behaviour. + + + [ dek: + Here we have a disagreement ... + I don't believe it is necessary to support every possible + \newlinechar in an optimum way; here the simpler rule without + exceptions wins + ] + +Fix proposal: + +The changes below needs the changes in |issue_message|, I have +described in my first bug report (replace call of |print| in this +function with |slow_print|, introduce new function |slow_print_err| +and replace |print_err| in |issue_message| with a call of this +funtion). Otherwise \message and \errmessage produce incorrect +output for unprintable characters. + +I have made the following changes to |print_char|, |print| and +|slow_print|: + + (* the old |print_char| procedure: *) + procedure print_the_char ( s : ASCII_code ) + (* special handling of current new_line_char deleted *) + case selector of + ... etc, etc. old code of |print_char|... + end; + + procedure print_char ( s : ASCII_code ) + label exit; + begin if <Character s is the current new-line character> then + if selector < pseudo then + begin print_ln; return; + end; + print_the_char(s); + exit: end; + + procedure print ( s : integer ); + label exit; + var j : poolpointer; + begin if s >= str_ptr then s:="???" + else if s < 256 then + if s < 0 then s:="???" + (* bug fix from bug report #1: *) ++ else if selector = new_string then ++ begin print_the_char(s); return ++ end; + else if (s = new_line_char) then + if selector < pseudo then + begin print_ln; return + end; + j:=str_start[s]; + while j < str_start[s+1] do + (* to fulfill wish #4: *) +! begin print_the_char(so(str_pool[j])); incr(j); + end; + exit: end; + + procedure slow_print ( s : integer ); + label exit; + var j : poolpointer; + begin if s >= str_ptr then s:="???" + else if s < 256 then + (* for wish #3: *) +! begin print(s); return + end; + j:=str_start[s]; + while j < str_start[s+1] do + begin print(so(str_pool[j])); incr(j); + end; + exit: end; + + +I was very astonished that (after I had applied the changes) the +resulted "TeX" passes the Trip-Test! + + +Possible Problems(?): + +- \newlinechar handling is done in \write, \message or \errmessage. + \write uses |token_show| to output the tokenlist and this is done + by calls of |print_char| or |print| with single characters or by + calls of |print_cs|. + \message and \errmessage uses |slow_print| or |slow_err_print|, + which handles newline characters at the `toplevel' of the string. + +- There should be additional changes to satisfy my wish #5 + (I don't know, if it is enough to change the |print_char| calls + in the procedure |show_token_list| to call a |print_char| procedure + with \newlinechar handling. And the calls of |print_char| in all + other places are calls to a |print_char| version without \newlinechar + handling (e.g. the |print_the_char| above).) + + +Yours, + Bernd Raichle + +<<< end inconsistent expansion of \string, etc.; \newlinechar + +************************************************************************ + +>>> \halign + box assignment within displays + +Date: Thu, 21 Nov 91 16:55:55 GMT +From: Chris Thompson <CET1@phoenix.cambridge.ac.uk> +Cc: Robert Hunt <REH10@phoenix.cambridge.ac.uk> +Subject: TeX bug in math alignments (Robert Hunt) + +Barbara, + + I received the following bug report from Robert Hunt + +> Accepted: 12:02:31 21 Nov 91 +> Submitted: 23:36:12 19 Nov 91 +> IPMessageId: A4D2794E8E47F040 +> From: Robert Hunt <REH10> +> To: cet1 +> Subject: Bug (sigh) in TeX +> +> Here's a bug in TeX: or possibly in the TeXbook, though I'd much +> prefer it to be considered the former! The input +> +> $$\halign{#\cr x\cr}\global\setbox1=\hbox{y}$$ +> +> generates a "Missing $$ inserted" error just before the "y" token. +> (Pressing RETURN then generates an "I can't go on meeting you like +> this" error, and TeX bombs out.) This appears to be because TeX +> objects to having horizontal mode material to process after an +> alignment in displayed maths mode. However, page 291 of the TeXbook +> clearly states that optional <assignments> may follow the closing +> brace of an \halign in display maths mode, and \setbox certainly +> counts as an <assignment>! + +It is definitely a bug in TeX: here's a log file (duplicated on Unix +TeX, by the way) + + --------------------start log file +This is TeX, Phoenix Version 3.14:0.75 (preloaded format=plain 90.7.18) + 21 NOV 1991 14:17 +**sysin +(&TEXR +! Missing $$ inserted. +<to be read again> + y +l.1 $$\halign{#\cr x\cr}\global\setbox1=\hbox{y + }$$ +? h +Displays can use special alignments (like \eqalignno) +only if nothing but the alignment itself is between $$'s. + +? +! I can't go on meeting you like this. +<to be read again> + y +l.1 $$\halign{#\cr x\cr}\global\setbox1=\hbox{y + }$$ +One of your faux pas seems to have wounded me deeply... + [ dek: ^^^^^^^^^^^^^^^^^ how true ] +in fact, I'm barely conscious. Please fix it and try again. + +No pages of output. + --------------------end log file + +The problem is that the state of the world when |do_assignments| in +module 1206 returns can be quite different from when it is called, +in respect of the mode nest and the save stack in particular. It +occurred to me that one should be able to create a simlar effect +with the call in |make_accent| (module 1123), and indeed, one can: + + --------------------start log file +This is TeX, Phoenix Version 3.14:0.75 (preloaded format=plain 90.7.18) + 21 NOV 1991 15:05 +**sysin +(&TEXS +! This can't happen (vpack). +<recently read> } + +l.1 \accent"7F\global\setbox1=\vbox{\vskip1in} + z +I'm broken. Please show this to someone who can fix can fix + +No pages of output. + --------------------end log file + + [ dek: $327.68 made out to Hunt ] + +Can you add this to Don's input queue, please? + + [ dek: + As Chris undoubtedly knows, this is not at all easy to fix. + I think it would be far too risky trying to allow arbitrary + boxes to be assigned after \halign in display or between \accent + and the accentee ... making _fin_align_ and _accent_ recursive + would open up a huge can of worms and would make \afterassignment + even murkier than it is now. Therefore I am modifying the + TeXbook to disallow such things [which nobody has ever used + because they never have worked] and modifying TeX to detect + this prohibited activity + ] + +Chris Thompson +Cambridge University Computing Service +JANET: cet1@uk.ac.cam.phx +Internet: cet1@phx.cam.ac.uk + +<<< end \halign + box assignment within displays + +************************************************************************ + +>>> positive/negative xn_over_d, tex.web section 107 + +Date: Thu, 21 Nov 91 18:38:51 GMT +From: CET1@phoenix.cambridge.ac.uk +Cc: Wayne Sullivan <WSULLIVAN@IRLEARN.UCD.ie> +Subject: Wayne Sullivan's new TeX bug + +Barbara, + + Here is the promised bug report from Wayne Sullivan. I don't think +I have anything useful to add to the messages below. I can produce +backtraces very like Wayne's. The calls can come from |math_kern| as +well as from |math_glue|. + +> Accepted: 16:47:07 15 Nov 91 +> Submitted: 14:42:13 15 Nov 91 +> From: "Wayne G. Sullivan" <WSULIVAN@IE.UCD.IRLEARN> +> To: Chris Thompson <CET1@UK.AC.CAMBRIDGE.PHOENIX> +> Subject: possible bug in TeX + +In TeX WEB section 107, Knuth claims that for use of the procedure xn_over_d, +n and d are always nonnegative. Whether the actual code makes use of this +in section 107, I am not sure. However, some implementations utilize the +assumed positivity in optimizing this section. In sections 716 and 717 +xn_over_d is used in context with cur_mu. Though one would expect cur_mu +to be nonnegative, I see no place where this is assured: I think one could +simply change the corresponding font parameter to a negative value. + + Wayne Sullivan + + [ dek: + $327.68 + \S716-7 + ] + +> Submitted: 17:18:39 15 Nov 91 +> IPMessageId: A4CD1EF77B402240 +> From: Chris Thompson <CET1> +> To: "Wayne G. Sullivan" <WSULIVAN@IE.UCD.IRLEARN> +> Subject: Re: [possible bug in TeX] + +I think you are right. |cur_mu| is set in section 703 and there is +no reason why it has to be positive. Hence |f| in both sections 716 +and 717 can be negative (as |x_over_n| gives a negative remainder +when x and n have opposite signs). |xn_over_d| is *not* robust against +negative n, quite apart from the promises in sections 107 and 99, +because it causes u to be negative, and so (a) you can't assume +u=d*(u div d)+(u mod d) in ANSI Pascal any longer, & (b) the test +for (u div d) being too large would need to be supplemented by one +for it being too small. + +I would like to construct a hard example of obvious bad results +before passing this to Barbara & Don, though. + +Chris Thompson + +> Accepted: 14:57:26 18 Nov 91 +> Submitted: 09:55:30 18 Nov 91 +> From: "Wayne G. Sullivan" <WSULIVAN@IE.UCD.IRLEARN> +> To: Chris Thompson <CET1@UK.AC.CAMBRIDGE.PHOENIX> +> Subject: xn_over_d + +I grabbed the pascal code for xn_over_d out of my change file to compare +the result with an optimized version. On tangling I discovered that the +intermediate values t,u,v are declared as nonnegative_integer. Hence a +range checking compiler will choke on a negative cur_mu: Can DEK escape +from that? + +> Accepted: 15:38:21 18 Nov 91 +> Submitted: 09:32:41 18 Nov 91 +> From: "Wayne G. Sullivan" <WSULIVAN@IE.UCD.IRLEARN> +> To: Chris Thompson <CET1@UK.AC.CAMBRIDGE.PHOENIX> +> Subject: xn_over_d + +The use of xn_over_d with the possibly negative cur_mu only affects the +the lower precision term in a `split' precision calculation so that +the problem of overflow arises only if the input values are beyond the +allowed values, i.e., with valid input values no overflow arises. Thus +the algorithm will give the correct answer even though cur_mu is negative. +However, this does depend on the div procedure satisfying negation symmetry: +(-n) div d =-(n div d) when n,d>0. At any rate the documentation needs to +be corrected so that optimized versions of the code will also give the +correct result. + +> Accepted: 17:40:28 18 Nov 91 +> Submitted: 11:05:39 18 Nov 91 +> From: "Wayne G. Sullivan" <WSULIVAN@IE.UCD.IRLEARN> +> To: Chris Thompson <CET1@UK.AC.CAMBRIDGE.PHOENIX> +> Subject: xnod + +Here is an example of the xn_over_d problem. Sorry about the antique version +of TeX currently on our VM/CMS: I use it only to illustrate the problem. + The TeX file: +\showboxdepth100 +\showboxbreadth100 +\scrollmode +\showthe\fontdimen6 \tensy +\fontdimen6 \tensy=-10pt +\showthe\fontdimen6 \tensy +$$a\;a$$ +\showlists +\end + + The LOG file (errors were reported on the terminal). Look for negative glue. + +This is TeX, VM/CMS Version 2.1 (preloaded format=PLAIN 87.5.19) 18 NOV 1991 11 +**xnod +(xnod.tex.* +> 10.00002pt. +l.4 \showthe\fontdimen6 \tensy + + +> -10.0pt. +l.6 \showthe\fontdimen6 \tensy + + + +### horizontal mode entered at line 7 +spacefactor 1000 +### vertical mode entered at line 0 +### current page: +\glue(\topskip) 10.0 +\hbox(0.0+0.0)x469.75499, glue set 449.75488fil +.\hbox(0.0+0.0)x20.0 +.\penalty 10000 +.\glue(\parfillskip) 0.0 plus 1.0fil +.\glue(\rightskip) 0.0 +\penalty 10000 +\glue(\abovedisplayshortskip) 0.0 plus 3.0 +\glue(\baselineskip) 7.69446 +\hbox(4.30554+0.0)x7.79407, shifted 230.98047 +.\teni a +.\glue -2.77771 plus -2.77771 +.\teni a +\penalty 0 +\glue(\belowdisplayshortskip) 7.0 plus 3.0 minus 4.0 +total height 29.0 plus 6.0 minus 4.0 + goal height 643.20255 +prevdepth 0.0, prevgraf 4 lines + +! OK. +l.8 \showlists + + +[1] +Output written on xnod.dvi (1 page, 264 bytes). + +> Submitted: 17:48:09 18 Nov 91 +> IPMessageId: A4D0EAFE6C983690 +> From: Chris Thompson <CET1> +> To: "Wayne G. Sullivan" <WSULIVAN@IE.UCD.IRLEARN> +> Subject: Re: [xnod] + +Wayne, + + Thanks for the messages. There is no doubt that there is a bug: the +declaration of t,u,v as |nonnegative_integer|, which I had missed, makes +it definite. I have traced through |xn_over_d| using a debugger, and +found it storing negative values, as expected. + + I'll put all this together and send it off to Barbara Beeton, if you +are agreeable. + +Chris Thompson + +> Accepted: 12:02:21 21 Nov 91 +> Submitted: 09:54:31 19 Nov 91 +> From: "Wayne G. Sullivan" <WSULIVAN@IE.UCD.IRLEARN> +> To: Chris Thompson <CET1@UK.AC.CAMBRIDGE.PHOENIX> +> Subject: xn_over_d + +Thanks in advance for passing the problem on to BNB/DEK. Enclosed below +are screen messages which appear when xnod.tex is processed on our ancient +VM/CMS version of TeX. Other things happen with the PC version I use, but +that uses an assembly language equivalent of the old xn_over_d which will +have to be upgraded to whatever Knuth decides to the procedure. It is unlikely +that he will employ the obvious modification. + [ dek: ^^^^^^^^^^^^^^^^^^^^ which is? ] + +Ready; T=0.05/0.11 09:49:43 +tex xnod +This is TeX, VM/CMS Version 2.1 (no format preloaded) +** +(xnod.tex.* +> 10.00002pt. +l.4 \showthe\fontdimen6 \tensy + +> -10.0pt. +l.6 \showthe\fontdimen6 \tensy + + + AMPX031E Low bound checking error + TRACE BACK OF CALLED ROUTINES + ROUTINE STMT AT ADDRESS IN MODULE + XNOVERD 6 024014 TEX + MATHGLUE 4 03E1B8 TEX + MLISTTOHLIST 73 041F54 TEX + AFTERMATH 68 052EBE TEX + MAINCONTROL 128 058098 TEX + <MAIN-PROGRAM> 110 05B86C TEX + PASCAL/VS 05BDAE + + + AMPX031E Low bound checking error + TRACE BACK OF CALLED ROUTINES + ROUTINE STMT AT ADDRESS IN MODULE + XNOVERD 10 024074 TEX + MATHGLUE 4 03E1B8 TEX + MLISTTOHLIST 73 041F54 TEX + AFTERMATH 68 052EBE TEX + MAINCONTROL 128 058098 TEX + <MAIN-PROGRAM> 110 05B86C TEX + PASCAL/VS 05BDAE + + + AMPX031E Low bound checking error + TRACE BACK OF CALLED ROUTINES + ROUTINE STMT AT ADDRESS IN MODULE + XNOVERD 6 024014 TEX + MATHGLUE 7 03E236 TEX + MLISTTOHLIST 73 041F54 TEX + AFTERMATH 68 052EBE TEX + MAINCONTROL 128 058098 TEX + <MAIN-PROGRAM> 110 05B86C TEX + PASCAL/VS 05BDAE + + + AMPX031E Low bound checking error + TRACE BACK OF CALLED ROUTINES + ROUTINE STMT AT ADDRESS IN MODULE + XNOVERD 10 024074 TEX + MATHGLUE 7 03E236 TEX + MLISTTOHLIST 73 041F54 TEX + AFTERMATH 68 052EBE TEX + MAINCONTROL 128 058098 TEX + <MAIN-PROGRAM> 110 05B86C TEX + PASCAL/VS 05BDAE + +! OK (see the transcript file). +l.8 \showlists + +[1] +(see the transcript file for additional information) +Output written on xnod.dvi (1 page, 264 bytes). +Transcript written on xnod.texlog. + + ----- End of Included messages ----- + +Chris Thompson +JANET: cet1@uk.ac.cam.phx +Internet: cet1@phx.cam.ac.uk + +<<< end positive/negative xn_over_d, tex.web section 107 + + +######################################################################## + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% Character code reference +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% +% Upper case letters: ABCDEFGHIJKLMNOPQRSTUVWXYZ +% Lower case letters: abcdefghijklmnopqrstuvwxyz +% Digits: 0123456789 +% Square, curly, angle braces, parentheses: [] {} <> () +% Backslash, slash, vertical bar: \ / | +% Punctuation: . ? ! , : ; +% Underscore, hyphen, equals sign: _ - = +% Quotes--right left double: ' ` " +%"at", "number" "dollar", "percent", "and": @ # $ % & +% "hat", "star", "plus", "tilde": ^ * + ~ +% +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +[ end of message 037 ] + |