diff options
author | Norbert Preining <norbert@preining.info> | 2021-05-27 03:01:40 +0000 |
---|---|---|
committer | Norbert Preining <norbert@preining.info> | 2021-05-27 03:01:40 +0000 |
commit | 5f1cfa686748068fedb95d8dafda3dc7f999c948 (patch) | |
tree | 874fa8430be12fe4633924f3b707428170316a46 /info/digests/tex-implementors/message.39 | |
parent | 8982c52e00ffb3fb5a913fc60913ebd9070f091a (diff) |
CTAN sync 202105270301
Diffstat (limited to 'info/digests/tex-implementors/message.39')
-rw-r--r-- | info/digests/tex-implementors/message.39 | 684 |
1 files changed, 684 insertions, 0 deletions
diff --git a/info/digests/tex-implementors/message.39 b/info/digests/tex-implementors/message.39 new file mode 100644 index 0000000000..8dd5efb829 --- /dev/null +++ b/info/digests/tex-implementors/message.39 @@ -0,0 +1,684 @@ +Date: 14 March 91 Message No: 039 + +To: TeX implementors and distributors + +From: Barbara Beeton + +Subject: Messages from DEK, part 4 + + +************************************************************************ + +>>> \TeX logo; some problems with \loop + +i accidentally misfiled this with another problem that had already +been solved; it should have been sent to you months ago. + ------- +Date: Mon 24 Jun 91 14:39:46-EST +From: Michael Downes <MJD@MATH.AMS.COM> +Subject: \TeX + +% These %'s are so that you can move this file out of mail +% and \TeX{} it as is to run the tests given below. +% +% What version of plain.tex were you using when you checked the +% spacefactor after \TeX? The one running on the TeXserver is +% presumably quite recent since the version of TeX is 3.1, from +% the standard Unix distribution. The following test demonstrates +% that the spacefactor after \TeX{} has to be manually adjusted +% to get proper spacing when punctuation follows (if \nonfrenchspacing +% is in effect). This can be corrected so easily by adding +% \spacefactor\@m at the end of \TeX's definition that I +% don't know why it hasn't been done already. Perhaps there's +% some reason not to do so that Knuth can explain. + [ dek: + That would have been better but I think it's too late now to + make such a change + ] + +% The space after the first period differs from the space after +% the second period, as demonstrated by the \showlists command. +\tracingonline=1 \showboxbreadth=\maxdimen +\TeX{}. Next. Third.\showlists + +% If Knuth changes plain.tex to fix \multispan perhaps he'll be +% willing to consider another obvious improvement: +% +% Redefine \loop, as described in TUGboat vol 8 no 2 July 1987 +% by Alois Kabelschacht. +% +% This allows an \else branch on the repeat condition to be used, +% which seems rather important in light of the fact that TeX \ifnum +% and \ifdim tests only allow <, =, and > comparisons, with no +% "not" operator or <= or >= combinations. Knuth might be unwilling +% to do this, however, since it would require corresponding changes +% in the TeXbook in the description of plain.tex; and it might be + [ dek: + All the macros in Plain TeX are merely simple examples that can + be improved ad infinitum ... I cannot keep doing it + ] +% only 99.8% backward compatible. [However, no existing TeX file +% will fail to run under the following redefinition unless it +% refers to the internal pieces of \loop (\body and \next), and +% perhaps the most likely reason someone might have done so would +% be to compensate for the lack of an \else possibility!!] + +\def\loop#1\repeat{\def\iterate{#1\expandafter\iterate\fi}% + \iterate \let\iterate\relax} + +% The following example illustrates an \else condition in +% the internal loop. It takes an even number and keeps +% dividing it until the result is odd. Try a large +% power of 2, e.g., 65536. +\newcount\n +\newlinechar=`\& +\loop +\message{&Enter a large even number (RETURN to stop): }% +\read-1 to\answer \n=0\answer\relax + [ dek: ^^^^^^ + wow, a trick I didn't know + ] +\ifnum\n>0 +% Braces to localize \iterate +{\loop +\divide \n by 2 +\message{&N divided by 2 = \number\n}% +\ifodd\n +\else\repeat}% +\repeat + +\bye + ------- +comment by bb: +i thought the definition of \TeX had been changed, because the +following definition accompanied DEK's article of October '90 +on "The future of TeX and METAFONT": + \def\TeX{T\hbox{\hskip-.1667em\lower.424ex\hbox{E}\hskip-.125em X}} +i'm pretty sure if that had been my addition, i would have marked it as +such, or would have made the change at a more general level. but i +could very well be misremembering. + ------- + +Date: Fri, 3 JAN 92 22:14:36 GMT +Originally-from: TEX "Brian {Hamilton Kelly} <TeX@Uk.Ac.Cranfield.RMCS>" +From: TEX@rmcs.cranfield.ac.uk +Subject: RE: flash!!! notice that tex update is about to happen + +[ ... ] +Brian +PS I'd love to see some way of using \loop... within an \halign; at +present it falls over because each & cancels a level of grouping, and so +the definition of \body (or is it \repeat) keels over. But I guess this +is too big a change. + [ dek: + Well \dosplits on page 397 does iterate within \valign + (which is similar) + ] +------- + +<<< end \TeX logo; some problems with \loop + +************************************************************************ + +>>> cedilla accent macro in plain.tex + +Date: Mon, 23 Sep 91 11:56:15 +0200 +From: Bernd Raichle <raichle@azu.informatik.uni-stuttgart.de> +Subject: TeX Bug Report -- plain.tex, cedilla accent macro + +Dear Ms. Beeton, + +I've found a small bug in `plain.tex' (and a missing index entry in +the TeXbook). Perhaps someone has reported it before, but I have seen +no fix for it... + +1. There's a missing index entry for "ligatures" in the TeXbook. + Page 306 contains the answer of exercise 5.1. This answer explains + how to supress unwanted ligatures. + [ dek: + No ... p 19 (ex 5.1, about suppressing unwanted ligs) is indexed. + see p 457 "an answer page is not indexed unless ..." + ] + +2a. The \c macro in `plain.tex' produces a box with the wrong dimensions + (height = depth = 0pt) for arguments with height != 1ex. + + Fix 1: exchange the \unhbox\z@ and \hidewidth\char24\hidewidth in + the macro definition + [ dek: + good + $2.56 + \ooops + ] + +\def\c#1{\setbox\z@\hbox{#1}\ifdim\ht\z@=1ex\accent24 #1% + \else{\ooalign{\unhbox\z@\crcr\hidewidth\char24\hidewidth}}\fi} + +2b. For characters with depth != 0pt, the "cedilla" character is not + lowered. I don't know of any use for this, because there's only the + c-cedille accent. But the idea used in the proposed fix can be + used for the under-dot and under-bar accent (and \AA) too. The + accent characters of these macros are misplaced if used within a + slanted font. + + Fix 2: use the \accent primitive and a changed ex-value to shift + the accent character to the correct place + +\def\c#1{{\dimen@ 1ex% + % Compute new ex value: + % The cedilla accent should not be shifted for uppercase characters, + % => new-ex := height(#1). + {\setbox\z@\hbox{#1}\dimen@\ht\z@ + % but we have to shift it down, if the character has depth. + % => new-ex := new-ex + depth(#1) + \advance\dimen@\dp\z@ + % Set the `ex' value (fontdimen change is always global), + \fontdimen5\font\dimen@}% + % ... set the accent char, reset `ex' to the old value + % and do the rest. + \accent24\fontdimen5\font\dimen@ #1}} + + +Yours, + Bernd Raichle (raichle@azu.informatik.uni-stuttgart.de) + +PS: Please can you add me to the `tex-implementors' list? + Thanks in advance. + ------- +Date: Sun, 29 Sep 91 15:37:10 BST +From: Chris Thompson <CET1@phoenix.cambridge.ac.uk> +Subject: Re: [[Bernd Raichle <raichle@azu.informatik.uni-stuttgart.de>: + TeX BugReport -- plain.tex, cedi]] + +Dear Barbara, + +> 1. There's a missing index entry for "ligatures" in the TeXbook. +> Page 306 contains the answer of exercise 5.1. This answer explains +> how to supress unwanted ligatures. + +Yes, I think it plausible that 306 should appear in the list. It doesn't +in the most recent 'texbook.tex' I have access to. + +> 2a. The \c macro in `plain.tex' produces a box with the wrong dimensions +> (height = depth = 0pt) for arguments with height != 1ex. +> +> Fix 1: exchange the \unhbox\z@ and \hidewidth\char24\hidewidth in +> the macro definition +> +> \def\c#1{\setbox\z@\hbox{#1}\ifdim\ht\z@=1ex\accent24 #1% +> \else{\ooalign{\unhbox\z@\crcr\hidewidth\char24\hidewidth}}\fi} + +Amazing that this hasn't come to light earlier: \hbox{\c C} has zero +height and depth as stated! Bernd's fix would appear to be the right +one: but maybe there is some subtle reason why the alignment is written +that way round at the moment---it's such a counterintuitive thing to do! + +> 2b. For characters with depth != 0pt, the "cedilla" character is not +> lowered. I don't know of any use for this, because there's only the +> c-cedille accent. But the idea used in the proposed fix can be +> used for the under-dot and under-bar accent (and \AA) too. The +> accent characters of these macros are misplaced if used within a +> slanted font. +> +> Fix 2: use the \accent primitive and a changed ex-value to shift +> the accent character to the correct place +> +> \def\c#1{{\dimen@ 1ex% +> % Compute new ex value: +> % The cedilla accent should not be shifted for uppercase characters, +> % => new-ex := height(#1). +> {\setbox\z@\hbox{#1}\dimen@\ht\z@ +> % but we have to shift it down, if the character has depth. +> % => new-ex := new-ex + depth(#1) +> \advance\dimen@\dp\z@ +> % Set the `ex' value (fontdimen change is always global), +> \fontdimen5\font\dimen@}% +> % ... set the accent char, reset `ex' to the old value +> % and do the rest. +> \accent24\fontdimen5\font\dimen@ #1}} + +This is a much more ambitious change, and I have doubts about its +having sufficient backwards compatibility, and its robustness. An +interesting technique, though, which relies on the x-height of the +current font being recorded before the |do_assignments| call in +|make_accent|. I think you should show it to Don together with +the rest. + +Chris Thompson + +<<< end cedilla accent macro in plain.tex + +************************************************************************ + +>>> missing \mathsurround in plain.tex + +Date: Mon, 4 Nov 91 13:35:11 +0100 +From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf) +Organization: Konrad-Zuse-Zentrum fuer Informationstechnik Berlin +Subject: Glitches in plain.tex + +Barbara, + +while revamping the LaTeX files I found that some macros from +plain.tex lack the \m@th (i.e. \mathsurround=0pt) assignment. The +macros in question are: + +\overrightarrow +\underrightarrow + [ dek: (scratched out \underrightarrow) + \overleftarrow + ] +\overbrace +\underbrace +\notin/\c@ncel +\rightleftharpoons/\rlh@ + [ dek: + $2.56 x 3 + A359, A360, A361 + ] + +What do you think? I append a demo file. + +Rainer + + ------------------demo for plain tex-------------------- + +text$\overrightarrow{abcdef}$text + +text$a \notin b$text + +\mathsurround =10pt + +text$\overrightarrow{abcdef}$text + +text$a \notin b$text + +text$a \rightleftharpoons b$text + +\bye + +<<< end missing \mathsurround in plain.tex + +************************************************************************ + +>>> \arrowvert code, plain.tex + +comment by bb: +there are several symbols in cmex* that are meant as midsections of +arrows, brackets, etc., but which are also given \cs names. these +include + \arrowvert + \Arrowvert + \bracevert +it seems that as long as these are referenced indirectly, through +\uparrow, \downarrow, etc., they are well behaved, but when they are +referenced by the \cs name, the wrong symbol is produced. i'm not the +only one who finds the \delimiter values assigned in plain somewhat +mysterious. if these really are errors, there's a different claimant +for each one: \arrowvert -- Phil Taylor, \Arrowvert -- me, \bracevert -- +Chris Thompson. if the values are correct though, we'd really +appreciate a good explanation of how this works. + +re the comments by michael barr regarding how much memory is required for +rules vs. characters, i know that's been explained before, but perhaps +it's time to do it again. i shall ask chris thompson or brian {hk}. + ------- +Date: Mon, 11 NOV 91 17:43:28 BST +Reply-to: Philip Taylor <P.Taylor@vax.rhbnc.ac.uk> (RHBNC) +From: CHAA006@vax.rhbnc.ac.uk +Subject: [Surely not another] bug in Plain.TeX ? + +For a book on French linguistics, I need up/down arrows which span rows +in an \halign; I use \uparrow, \downarrow and \arrowvert. In both the +MS/DOS (emTeX) and VAX/VMS versions of Plain.TeX, \arrowvert translates +to \delimiter"33C000. Character "3C in family 3 (cmex10) is the centre +part of a brace, not a vertical arrow ... + [ dek: + right, as stated on page 150. I admit these names are not the + best, but you are supposed to regard them as _verts_ (with + differing weights) derived from arrows/braces _not_ as + arrows/braces + ] + + ** Phil. + +P.S. Plain version 3.0 (can't find a date). + ------- +Date: Mon, 18 NOV 91 10:57:30 BST +Reply-to: Philip Taylor <P.Taylor@vax.rhbnc.ac.uk> (RHBNC) +From: CHAA006@vax.rhbnc.ac.uk +Subject: Re: [Surely not another] bug in Plain.TeX ? + +>>> however, now that i look at this, i'm wondering why you haven't just +>>> used \uparrow, \downarrow, and \updownarrow, forcing them to whatever +>>> size you want with phantoms. or have you? if so, and you're really +>>> getting the wrong pieces, then there's a problem in the .tfm file too. + +I did, in the end; here's the current version: + +% +\newbox \arrowbox +\setbox \arrowbox = \hbox + {\let|=\strut\smash{$\left\updownarrow\matrix{|\cr|\cr|\cr|\cr}\right.$}} +\def \arrow {\copy \arrowbox} +% +\Begin {columns} \options = {\listindent = 0.25 \listindent} +% + \+&&Il&&&&effondr{\'e}&&&&&&&&une chaise.&\cr + \+&&Pierre&&s'est&&assis&&sur&&&&&&un si{\`e}ge.&\cr + \omit&\arrow&&&&\arrow&&&&&&&&\arrow&&\cr + \+&&L'{\'e}tudiant&&&&install{\'e}&&&&&&&&un tabouret.&\cr + \+&&&&&&&&&&&&&&un canap{\'e}.&\cr + \+&&\multispan 4{\qquad \leftarrowfill\rlap {$\joinrel \rightarrow$}}&& + \multispan 2{\llap {$\leftarrow$}$\joinrel$\rightarrowfill}&&&&& + \multispan 2{\llap {$\leftarrow$}$\joinrel$\rightarrowfill}&\cr +% +\End {columns} + +[ ... ] + ------- +Date: Wed 20 Nov 91 07:02:41-EST +From: bbeeton <BNB@MATH.AMS.COM> +To: CET1@phx.cam.ac.uk + +by the way, phil taylor has found another plain bug -- the character +referenced by \arrowvert is wrong; following his lead, i discovered +that \Arrowvert also looks bad. (these are rarely used, but even so, +it's surprising they haven't been found before; i think they've +been this way since versions >1.) phil is concocting a routine to +print out all the plain math characters for checking. + -- bb + ------- +Date: Thu, 21 Nov 91 16:39:06 GMT +From: Chris Thompson <CET1@phoenix.cambridge.ac.uk> + +[ ... ] + + I met Phil Taylor at the UKTeX meeting in Oxford yesterday, and he +told me about the \arrowvert..\Arrowvert problem. I was surprised that +such a bug had gone unnoticed so long. Are you both sure about this? +I get the appearance described on page 150 of the TeXbook in test +programs. (All this complicated by the variable-character codes in +cmex10, by which a character rarely means itself! "3C as varchar is +actually repeating bits of "3F, and "3D as a varchar is repeating bits +of "77.) There was a change in plain \fmtversion 2.92 (I think) in which +the definitions of \arrowvert, \Arrowvert and \bracevert were changed +from "33C, "33D & "33E to "33C000, "33D000 & "33E000: I never understood +in what circumstances this could make a difference! + [ dek: + Yes, see the bottom of page 156 + ] + +Chris Thompson + ------- +Date: Fri, 22 NOV 91 11:02:27 BST +Reply-to: Philip Taylor <P.Taylor@vax.rhbnc.ac.uk> (RHBNC) +From: CHAA006@vax.rhbnc.ac.uk +Subject: Arrowvert (forgot to cc you) + +Dear Chris --- + +>>> I was using tests like + +>>> $$\left\arrowvert X\sp h \over J_y \right\Arrowvert$$ + +>>> and they seem to work. Have you got an example which fails? + +Yes ! $ \arrowvert $ ! [I suppose this means I must be abusing \arrowvert, + [ dek: ^^ + \bigg would produce a particular size + I will pay Phil $2.56 + ] +but I can't for the life of me see why ...] + + ** Phil. + ------- +Date: Fri, 22 Nov 91 15:37:37 GMT +From: Chris Thompson <CET1@phoenix.cambridge.ac.uk> +To: Philip Taylor <P.Taylor@vax.rhbnc.ac.uk> (RHBNC) +Subject: RE: \arrowvert..\Arrowvert + +Phil, + +Ah, I see! Although $\left\arrowvert...$ works, $\arrowvert$ doesn't. +The trouble is, I don't see how it can be made to... + +When \arrowvert is used in the context of a <math character>, only +the top 15 bits of the 27-bit number following \delimiter are used. +Before the change in plain 2.92 (if that is in fact when it was) this +would have produced \mathchar"0000 (clearly wrong); now it produces +\mathchar"033C (unfortunately, still wrong). cmex10 character "3C as +a math character is the middle piece of a large \lbrace as shown on +p.432, but when used as a <delim> (after \left, or the macros \bigl, +\Biggl, etc.) its varchar definition is used, and that says that it +should be made up of a lot of copies of character "3F (no top, middle +or bottom piece used). If the definition of \arrowvert was changed to +"033F000, then the <math character> context would work, but the <delim> +one wouldn't: instead it would be like \updownarrow. + + [ dek: + Next version of plain has a good compromise: + \lmoustache "437A340 \arrowvert "026A33C + \rmoustache "437B341 \Arrowvert "026B33D + \lgroup "462833A \bracevert "077C33E + \rgroup "462933B + ] + +Chris Thompson + ------- +Date: Thu, 21 Nov 91 11:31:24 EST +X-ListName: TeX-Related Network Discussion List <INFO-TeX@SHSU.edu> +From: barr@triples.Math.McGill.CA +Subject: Optimizing TeX? + +Let me begin by mentioning a misprint in the Book. On page 358, line +-8 (17th printing, Jan. 1990), it says +\mathchardef\mapstochar="322F \def\mapsto{\mapstochar\rightarrow} +and the "322F should be (and is, in plain.tex) "3237. + [ dek: + $2.56 was paid to Karl Berry for this on 19 Sep 91. Labrea + sources haven't changed yet but my texbook.tex had this + correct as of 18 Sep 91 acc. to errata.tex + ] + +The reason I noticed this was that a colleague had tried to make a +\mapsfrom macro and discovered a curious fact. The \mapstochar is not +just a vertical line, but has a blip in the middle on the right hand +side that effectively ruins it for any other purpose. I told my +colleague to use a rule and he did. + +I know from something that appeared in UKTeX a ffew weeks ago that rules +are expensive in space. There is a reason for this. It requires 4 real +numbers to specify a rule (the space of rules is a 4-manifold and fewer +numbers will not do, no matter how you describe them). + [ dek: + not true; 3 numbers (height, width, depth) suffice in context + ] + Possibly 4 16 +bit numbers would have given sufficient precision, but Knuth coded all +dimensions as 32 bit numbers. So, it presumably takes 16 bytes to +specify a rule and it is going to be much more wasteful of space to use +a rule than it would have been to use the \mapstochar. Is this correct? +More to the point, how can one find out about coding TeX to optimize for +space? For time? Knuth drops a few clues in the discussion on pp. +373-374, but that is almost the only place this is done. For instance, +can anyone tell me the relative cost of factoring macros into smaller +ones, assuming you never reuse the pieces? + +Michael Barr + ------- +Date: Fri, 22 Nov 91 17:07:28 GMT +From: Chris Thompson <CET1@phoenix.cambridge.ac.uk> +Subject: This and that + +Barbara, + +You write +> there was another in that category reported just +> today by michael barr -- the \mapstochar. if you read comp.text.tex, +> look for his report, because it's asking a couple more basic questions, +> namely how much memory space do certain techniques require, and what's +> the most efficient way to do certain things. + +I follow comp.text.tex only intermittently, as its volume is really +rather high. I took a look at Michael Barr's posting, and have posted +a reply. He is certainly right about \mapstochar: the TeXbook said +"322F in 1984, and the latest texbook.tex from labrea still says it; +on the other hand plain.tex has always (correctly) had "3237 since 1.0 +(I am fairly sure of this: despite the absence of a plain.tex.history +file, I do do compares of old with new each time I upgrade and note +down the salient changes). + +Chris Thompson + +<<< end \arrowvert code, plain.tex + +************************************************************************ + +>>> MF -- bugs or features? (also, some ACP errata) + +Date: Tue, 22 Oct 91 12:04:23 +0100 +From: schoepf@sc.ZIB-Berlin.DE (Rainer Schoepf) +Organization: Konrad-Zuse-Zentrum fuer Informationstechnik Berlin +Subject: Questionable features of Metafont + +Barbara, + +here is the report about two features of Metafont that I find +questionable. I hesitate to call them bugs as it is said nowhere in +the book that Metafont should not behave that way. + +Number 1: +--------- + +The book says that + +addto V also P; + +is "essentially the same as" + +V := V + P; + +But this is only true if the evaluation of the picture expression P +does *not* change the value of the picture variable V as a side +effect. The second expression is correctly evaluated left to right. +The first one, however, uses the value of V *after* P has been +evaluated. Looking into the program one sees that "addto" reads the +token list for V, evaluates the expression P, and converts the token +list for P into an edge structure afterwards. + +I assume that the same behaviour happens with "cull". + [ dek: + I suppose so -- just as you would expect in C when comparing + x=x+f(x) to x+=f(x) when f has side effects + ] + + +Number 2: +--------- + +Define the following macro: + +def xxx = + begingroup + save x; + newinternal x; + .... + endgroup +enddef; + +After a hundred expansions Metafont gives you an "capacity exceeded" +error since every call to newinternal statically allocates a slot in +an internal array, which is not freed again at the end of the group. +However, in this case, it is very easy to free the slot again. + [ dek: ^^^^^^^^^ + STRONGLY DISAGREE that _any_ change can be described as + ``very easy''! + + +Bugs or features? + +At least, this behaviour should be documented! + [ dek: + Maybe in TUGboat. Certainly the ``capacity exceeded'' error + tells you that you've exceeded the number of internals. + ] + + +[ ... ] + + +Rainer + +<<< end MF -- bugs or features? (also, some ACP errata) + +************************************************************************ + +>>> MFbook errata + +Date: Tue, 5 Nov 1991 05:48:03 +0100 +From: Lutz Birkhahn <lutz@bisun.nbg.sub.org> +Subject: Errors in METAFONTbook (C&T Vol. C) + +Barbara, +just for the record, here are some minor bugs in the METAFONTbook (C & T +vol. C) index: + + "openwindow", "or", and "string" + +each are METAFONT primitives, so they deserve to get a starred entry (preceded +with an asterisk `*') in the index on pages 353, 354, and 356, respectively. + +This error shows up in my edition from 1986 (first printing, I think) as well +as in the source code I have, stating "Fifth printing, revised, March 1990" +(although the C & T Publication info table you posted recently said that +the 4th printing of Volume C, Sept 1991, is the latest...). + + [ dek: + 3 x $2.56 many thanks C354^2 C356 + ] + +Bye, +Lutz + +Lutz Birkhahn (Germany) email: lutz@bisun.nbg.sub.org (don't use another!) +F"urther Str. 6 +-------------------------------------------------- +D-W-8501 Cadolzburg 2 | "It is an error to not have enough arguments" +Voice: 09103 / 2886 | (Hype Programmer's Guide) + +<<< end MFbook errata + + [ dek: + notes to myself + only boolean was done as I had intended + 353 numeric 356 string 357 transform + 354 openwindow + or + pair + path + pen + picture + ] + + +######################################################################## + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% 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 039 ] + |