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/035 | |
parent | 8982c52e00ffb3fb5a913fc60913ebd9070f091a (diff) |
CTAN sync 202105270301
Diffstat (limited to 'info/digests/tex-implementors/035')
-rw-r--r-- | info/digests/tex-implementors/035 | 384 |
1 files changed, 0 insertions, 384 deletions
diff --git a/info/digests/tex-implementors/035 b/info/digests/tex-implementors/035 deleted file mode 100644 index d4412eba65..0000000000 --- a/info/digests/tex-implementors/035 +++ /dev/null @@ -1,384 +0,0 @@ -Date: 5 November 91 Message No: 035 - -To: TeX implementors and distributors - -From: Barbara Beeton - -Subject: Messages from DEK, part 4 - - -Fourth and last installment of DEK's September comments. - -Also included in DEK's package were some general comments to Peter -Breitenlohner, who is, with DEK's encouragement, updating PATGEN to -accommodate the new features of TeX 3. This is still a work in -progress; however, anyone else who has examined PATGEN with this -extension in mind might want to get in touch with Peter directly. -(Sorry, Peter, for not warning you ahead of time.) - - -######################################################################## - -TeX -- incompatibilities between \input and \openin - -This report is my own. When updating our user documentation for -AMS-TeX, AMS-LaTeX, et al., I try to keep the files that will be -distributed together in one directory, and run (La)TeX from another, -to segregate the files that are created by the run from the originals. -There is no problem with files based on Plain, but LaTeX first checks -for the existence of some files with \openin and, if they are there, -then applies \input . - -The problem is that (at least in the VMS and some PC implementations) -\openin checks only the connected directory, not the path specified -by TeXinputs: . Discussions with other users and implementors have -uncovered the fact that some implementors have added the logical path -to the \openin procedure, while others have not. (The DEC-20 -implementation did check TeXinputs: for both \input and \openin, so -I had rashly assumed that was what was supposed to happen.) - -I understand that the WEB code for the two procedures is different, but -I believe it's not clear whether or why \openin should *not* check the -same input path as \input , and that means the implementors are free to -make their own interpretation. A clear statement of what the behavior -should be would be very helpful. - - [ dek: - I had some correspondence about this a few months ago, but I - forgot what I said. - The difference in code between \input and \openin is actually - to allow reading files from a system area under \read without - requiring a full path name, but not under \openin. - However, lots of operating systems make it nicer to define - environmental variables for sequences of places to try, and - such implementations naturally make use of the more general - paths on \openin as well as \read. - Clearly LaTeX is important enough that the implementors should - make LaTeX as easy to use as possible. I need the feature also - with my use of Plain TeX: I have put ".." on my standard input - path list, so that I can go to a subdirectory to make a DVI file - and partial cross reference files that won't disturb anything - on the parent directory. - I recommend therefore that implementors use environmental - variables for directory path lists (or a default one if the - programmer hasn't set it up) whenever the operating system - allows it. - My favored conventions on implementation questions in general - are expressed by the change files I have contributed to the - distribution [under `local' directory] ... these are for - Pascal, _not_ C, versions of TeX and MF but I do use them heavily. - Incidentally I dislike several aspects of WEB-to-C versions on - Stanford computers, especially the treatment of command lines -- - they don't check .fmt files for garbage but I guess that hasn't - been a problem. - ] - -************************************************************************ - -WEB system -- dealing with repeating code in .WEB files - -Date: Tue 26 Mar 91 20:09:38-EST -From: bbeeton <BNB@MATH.AMS.COM> -To: cet1%phx.cam.ac.uk@nsfnet-relay.ac.uk -Subject: possible bugs, requesting verification - -[ this was in response to my saying that any large .web file - is likely to have repeating blocks of code, and thus a line - number is advisable when listing differences. where he says - "web" he clearly means "tangle". ] - -Date: Sat, 23 Mar 1991 20:22 PST -From: Don Hosek <DHOSEK@HMCVAX.CLAREMONT.EDU> -Subject: Re: Updates to TeX.WEB, MF.WEB, GFtoDVI, et al. - -Incidentally, the repeating code problem is particularly nasty -when writing change files. WEB only checks to see if the first -line matches rather than the whole of the text in the @x..@y -block which caused me a great deal of grief when I wrote the CMS -change file for MFT; there are a lot of repeating first lines of -a block of text. - - -dh - ------- -Date: Wed, 27 Mar 91 18:33:18 GMT -From: Chris Thompson <CET1@phoenix.cambridge.ac.uk> -Subject: Re: [possible bugs, requesting verification] - -... - - As regards Don Hosek's complaint about Web (and it applies to both -TANGLE and WEAVE, of course, which is presumably why he confusingly says -"Web"): I agree, it's a right pain. I understand why it got like that, -though: it means that the programs never have to buffer more than one -line from each input file at a time. I am still paranoid about storage -consumption as well, in an age where there is little sympathy for this! - -The worst cases are when one *removes* a change (maybe one had an ahead- -of-base-source bug fix, for example) and suddenly later changes start -failing to match (or even worse, succeed in matching) the wrong part -of the file. One has to increase the context, often into the TeX parts -of the modules, to ensure uniqueness. I would certainly suggest that you -send Don Hosek's remarks to Don Knuth, but I fear he probably won't want -to change anything in this area now. - -Chris Thompson - ------- -Date: Thu, 28 Mar 91 17:03:50 GMT -From: Chris Thompson <CET1@phoenix.cambridge.ac.uk> -Subject: Re: [possible bugs, requesting verification] - -... - -It is all documented: WEBMAN.DVI page 10, section 11 says: "Whenever the -first ``old line'' of a change is found to match a line in the web_file, -all other lines in that change must match too." There is no bug; it is -just a rather painful spec to live with, as Don Hosek says. It is a bit -painful, as well, that it just reflects the @y, and doesn't tell you -*which* lines mismatched! - -Chris - ------- - - [ dek: - WEB was never intended to be the "last word"; I expect second - generation systems to do all kinds of things with much greater - generality. I stopped when I had something good enough to - get on with what needed to be done. There is something painful - about every system, but really I have lots more problems with - all the other software I have to live with! - ] - - -######################################################################## - -Date: Tue, 30 APR 91 21:31:17 BST -Reply-to: Brian {Hamilton Kelly} <TeX@rmcs.cranfield.ac.uk> -From: TEX@rmcs.cranfield.ac.uk -To: BNB <@nsfnet-relay.ac.uk:BNB@MATH.AMS.com> -Subject: Possible bug in TeX V3.1 ??? - -Dear barbara, - -I'm loth to say this, because I know how rarely anything is genuinely a -bug, but I'm a bit suspicious about TeX's unpacking and repacking of -ligatures before and after hyphenation. - -I have a font that, like DEK's example in the New TeX and MF -announcement, has a variant of "s" for the ends of words (it's actually -an updating of my Greek fonts). - -So the ligature program reads as follows: - -% -% Ligatures for sigma at end of "word" -% -boundarychar := 255; - -ligtable "s": 255 =:| "c", "." =:| "c", "," =:| "c", - ":" =:| "c", ";" =:| "c", "!" =:| "c", - "?" =:| "c", ")" =:| "c", "/" =:| "c", - "]" =:| "c", "*" =:| "c"; -% -% Note that s is not ligatured with apostrophe, so that one can write things -% like s''ena sp'iti ('' in this font produces an apostrophe, since ' -% on its own is an acute accent.) -% - -Now this works beautifully, most of the time. However, if TeX decides -that it should attempt hyphenation, and if the word being hyphenated -ends in punctuation, such as ".", then \S898 of TeX.web gives up on -taking apart the ligatures when it meets the period, since it's a -non-letter (has lc_code=0) --- so the word "xomol'ogysys." (where 'o is -a ligature defined in the font, and for which "'" has a non-zero lccode) -gets passed to the hyphenation procedure as the 12 characters "x o m o l -' o g y s y s" in hc[1:hn]. After hyphenation has been considered, the -period is no longer hanging around for reconstitute to put back -together. (Incidentally, when I read the code, I'd convinced myself that -the final "s" wasn't going to be present in hc[hn] for hyphenate to -consider, but the VAX-Pascal debugger shows that it _is_ there!) - -I've managed to effect a workaround, by setting the \lccodes for all the -punctuation that enters into the ligature program for sigma; but then -the hyphenation algorithm is given the _13_ characters "x o m o l ' o g -y s y s .", which I'm sure it's unlikely to be completely happy with -(although it does seem to find the same breaks); surely, it will no -longer recognize any explicit end-of-word marks in the \patterns? - [ dek: - that is true but perhaps there areen't so many patterns in - Greek. (Of course I am not happy with this workaround either) - ] -Perhaps, instead of setting \lccode`\.=`\., I should perhaps set it as -\lccode`\.=256, so that it's non-zero, but doesn't pass the character -{\it per se\/} into the hyphenation algorithm. - -Perhaps you could ask Don what he advises, or whether perhaps \S898 -should _complete_ its dismantling of the ligature, and only afterwards -exclude the non-letter characters, noting the whole sequence for -reconstitute's benefit. - -Brian -------- -Date: Thu, 02 May 91 00:49:54 BST -From: Chris Thompson <CET1@phoenix.cambridge.ac.uk> -To: bbeeton <BNB@MATH.AMS.com> -Cc: Brian {Hamilton Kelly} <TeX@rmcs.cranfield.ac.uk> -Subject: Re: [[TEX@rmcs.cranfield.ac.uk: Possible bug in TeX V3.1 ???]] - -Barbara, - -There does indeed appear to be something murky going on. I am not at all -familiar with the code for reconstituting new-style ligatures, so a full -report will take a little while... - -Setting the \lccode's for punctuation to pretend that they are letters -is a terrible way to have to work round the problem, and B{HK} is of -course right that -> it will no -> longer recognize any explicit end-of-word marks in the \patterns - -On the other hand -> I should perhaps set it as -> \lccode`\.=256 -certainly won't work: \lccode values are restricted to 0..255. I am not -sure what he is trying to say here. - -Chris Thompson -JANET: cet1@uk.ac.cam.phx -Internet: cet1%phx.cam.ac.uk@nsfnet-relay.ac.uk -------- -Date: Thu, 2 MAY 91 22:11:57 BST -Reply-to: Brian {Hamilton Kelly} <TeX@rmcs.cranfield.ac.uk> -From: TEX@rmcs.cranfield.ac.uk -To: BNB <@nsfnet-relay.ac.uk:BNB@MATH.AMS.com> -Subject: Re: [[TEX@rmcs.cranfield.ac.uk: Possible bug in TeX V3.1 ???]] - -Chris, - -In message <A3D492887571AC90@UK.AC.CAMBRIDGE.PHOENIX> of Thu, 02 May 91 -00:49:54 BST, Chris Thompson <CET1@UK.AC.CAMBRIDGE.PHOENIX> wrote: - -> There does indeed appear to be something murky going on. I am not at all -> familiar with the code for reconstituting new-style ligatures, so a full -> report will take a little while... - -Thanks! I thought I was going nuts at first! - -> Setting the \lccode's for punctuation to pretend that they are letters -> is a terrible way to have to work round the problem, and B{HK} is of -> course right that -> > it will no -> > longer recognize any explicit end-of-word marks in the \patterns -> -> On the other hand -> > I should perhaps set it as -> > \lccode`\.=256 -> certainly won't work: \lccode values are restricted to 0..255. I am not -> sure what he is trying to say here. - -Sorry, I hadn't tried this; in fact, only thought of it when composing -the message. By analogy with \hyphenchar, I was hoping that I could set -an \lccode to a non-character value, and thus ensure (perhaps?) that the -hyphenation algorithm wouldn't consider the punctuation characters, -since they'd be excluded in |hc|; but I see now that |lc_code| is a -|equiv| and thus in a |quarter_word|, so cannot be set outside range -0..255 (as TeX tells me when I try!) - -One thought: - Perhaps when unravelling ligature nodes in the pre-hyphenation phase, - TeX should take cognizance of whether the ligature program was one - that used =:| or |=:| (I'm not sure of |=:) and still stop at the - [ dek: ^^ is this a smily face? ] - punctuation character, corresponding to the "retained" character, but - remember that it "belonged" and thus still be able to reconstitute it - correctly afterwards. - -Best regards, - Brian -------- -Date: Fri, 03 May 91 17:17:13 BST -From: Chris Thompson <CET1@phoenix.cambridge.ac.uk> -To: Barbara Beeton <BNB@MATH.AMS.com> -Cc: Brian {Hamilton Kelly} <TeX@rmcs.cranfield.ac.uk> -Subject: Re: [[TEX@rmcs.cranfield.ac.uk: Possible bug in TeX V3.1 ???]] - -Barbara, & Brian, - - I have been looking at the pre- and post- hyphenation code, and I have -come to the conclusion that Brian's problem is probably a bug, rather -than a feature. - - The horizontal list for either "...ogysys " or "...ogysys. " contains -a ligature node with |lig_char| = "c" and component character list -containing just "s"; the "." is a separate character node in the second -case. The difference is that in the first case the ligature node's -|sub_type| is 1 ("formed from a right boundary character") while in the -second it is 0. - - If automatic hyphenation is invoked, section 898 reconstructs the -original character list up to "s", and this is what is intended. The -difference in the cases is that section 903 sets |bchar:=255| in the -first case (|hb| is the ligature node described above) but not in the -second case. This allows |reconstitute| to rebuild the ligature node, -but only in the first case. - - The reason I think this is probably a bug is the asymmetry of -treatment of the left-hand and right-hand edges of the word in section -903. There |ha| is examined in great detail in order to decide what -to put into |hu[0]| and |init_lig|, in particular if the word is -preceded by punctuation characters that alter the first letter of the -word (e.g. by |=:> ligatures) then such effects will be recreated by -by |reconstitute|. On the other hand, |bchar| is set only to |non_char| -|font_bchar[hf]|; any following punctuation characters (at |q=link(hb)|) -are never examined. - - Certainly I think this ought to be brought to Don's attention, if -he has any to spare for TeX at the moment. I think it may actually be -a matter of some urgency, in that otherwise people like Brian trying -to use right-boundary effects in fonts may be forced into using -inappropriate work-rounds; maybe even ones that would not survive -a proper fix. - -Chris Thompson -JANET: cet1@uk.ac.cam.phx -Internet: cet1%phx.cam.ac.uk@nsfnet-relay.ac.uk -------- - - [ dek: - Chris is absolutely right; I should have provided better right - context to the reconstitution algorithm. - [Why did I get into this?!] - Draft changes are being put into version 3.14$\alpha$ - In the new version the effect of \noboundary between a word and - punctuation will be lost (for example ...ogysys\noboundary. _will_ - now convert the s to a c ) - but that minor problem is much worse than the present alternative. - An explicit kern - ...ogysys\noboundary\kern0pt. - will preserve such noboundary status if necessary. - The going rate for bugs in the 1989 code is $10.24, so Brian - gets credit for this one! - ] - - -######################################################################## - -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -% 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 035 ] -------- - |