On Mon, Nov 30, 2020 at 9:27 AM Dan Cross <crossd(a)gmail.com> wrote: There are a few MD to troff converters, though I don't know how many will convert to -ms format that was likely used historically. And given that ms has a little more semantic info than MD does, there may be some manual steps afterwards. Even a perfect converter would likely have manual steps since it was also the custom back in the day to tweak this or that in the output... Warner

So Clem, the fact that troff lost and LaTex won is a direct result of that walled garden that was the early days of Unix. Unless you had a Unix license, no troff for you! Which is a huge bummer, I'm a huge troff fan (especially pic, but all of the preprocessors let you see the output in your head). I wish we lived in a troff world but we don't and that is a direct result of haves (license holders) and have nots (the other 99.999999% of the world). It's not the result we would like but it is what it is. On Mon, Nov 30, 2020 at 10:52:40AM -0500, Clem Cole wrote: -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm

On Mon, Nov 30, 2020 at 11:54:37AM -0500, Clem Cole wrote: The other issue to consider is how easily could you typeset a super-complex math expression (with integrals, sigmas, matricies, etc., etc.) using eqn vs Scribe vs LaTeX. For at least some of the stuff I needed to do when I was type-setting problem set results (there was an informal competition between some of the students regarding whose homework would get redistributed by the TA's as the official problem set answer to the rest of the class), I found LaTeX easier to use than Scribe, and I had access to all three as an MIT undergraduate. Granted, that could have been a matter of personal preference, and I never did try to use eqn for that purpose. - Ted

On Mon, Nov 30, 2020 at 1:25 PM John Cowan <cowan(a)ccil.org> wrote: I think it depends on who you are and your editor is at the said firm. Tim will still take troff as will John Waite at Pearson. That said, as Jon can tell you, Bill will not.

To show how current this topic is, there's an interesting and related discussion upcoming at NYC Bug, For the Love of Troff, on Wed @ 18:45 (I'm guessing Eastern), via Zoom: https://www.nycbug.org/index?action=view&id=10678 On 11/30/20 2:11 PM, arnold(a)skeeve.com wrote: -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF

We seem to be straying into COFF-land. However... On 11/30/20 13:25, John Cowan wrote: I wonder what Tanenbaum does these days? Prefaces of earlier versions of all his texts stated that they were written with troff. (And Springer accepts mostly LaTeX.) N.

On Wed, Feb 10, 2021 at 12:48:49PM -0800, Greg A. Woods wrote: I had n/troff on the BSD based vaxen that UW-Madison CS had. There was a standard binder of docs (that I still have 35+ years later) that had the troff, -ms, -man, -me, tbl, eqn, pic, refer docs (no grap, sadly, I wrote my own). The Masscomps I used had working roffs. I've been using troff since well before 1985 (I found that Masscomp restor.e doc, it was 1985 but I was well into troff by then, I started with -man and -ms but was experimenting with -me for that paper. I liked -me well enough but -ms just made more sense to me so I went back to that and have been there ever since). The 3B1 that my roommate and I shared had working roff. I don't remember how we got stuff printed, I was for sure using troff for years before the postscript one came about. So for once, I'm gonna side with Clem on this one. I've always had troff and been very happy with it. I know LaTex sort of won but I'm not a fan. --lm P.S. Groff is C++, not C. That made it dicey until g++ got stable.

At Wed, 10 Feb 2021 17:05:57 -0500, Clem Cole <clemc(a)ccc.com> wrote: Subject: Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976)) I was much deeper in the trenches! (and in Canada too) I'm talking about small old systems, usually at very small companies but sometimes at very small departments in larger companies. Things like early Motorola 68k, NCR-Tower, Convergent, Plexus, Spectrix (plus Tandy and Altos and other Xenix-based ports). Even with full licenses the available nroff/troff package was often not installed as all too often there wasn't enough spare disk space to install it. Also with newer AT&T Unix ports, i.e. Release 2 and newer, it depended very much on the vendor, and sometimes even the distributor, as to whether or not the Documenter's Workbench would be a separate purchase or not, but usually it was and most of the customers I worked with would never pay for software that they didn't have a pressing need for, even if it was just a few $100. I don't know if I've ever seen a Versatec plotter, though perhaps at a trade show. I seem to remember grad students at university getting typeset copy off some kind of "wet" process typesetter driven by troff -- maybe even a C/A/T, but that was so far out of reach of undergrads that it wasn't even funny -- we just had a dot-matrix line printer (for the Unix machine -- there were real line printers on the Multics machine). Later on most of the kinds of customers I worked with would have a daisy-wheel printer at best, or perhaps just a dot-matrix line printer. That is until the HP Laserjet came along, followed of course not much longer by the Apple LaserWriter. Yeah, sure, lots of us Unix fans used nroff, but I doubt I ever had any small-system customers who used it, or would even know how to use it, nor would they want to learn how to use it, especially if they already had paid for a "proper" word processor.... Sorry, probably it was WordPerfect or something work-alike. The most recent site I remember using such a word processor on Unix was on an NCR-Tower32, which by then would have been running a newer Unix System V, probably Release 2, though maybe I upgraded them to Release 3 or whatever was current from NCR in the day, but I don't remember the details. They printed to a laser, probably as PCL. That would have been in the very early 1990s. I remember learning the old "roff" on a PDP-11/60 (which was by then running V7) and submitting course work hand-cut from 132-column fan-fold paper. I also remember being disappointed when they "replaced" it with nroff (probably it had just been an old v6 binary) and I had to learn how to format everything all over again. :-) There were a great number of small sites running various different ports of Unix -- many of which were purpose-built to run some application such as an accounting system or word processing system. Often the owners didn't even really know they were running Unix or some derivative. If the compiler was an add-on they certainly didn't have it, even if it was a free add-on. I think Microsoft Xenix for example always had an add-on compiler (though perhaps some of its many sub-licensees would bundle it), and of course by the time AT&T Unix System V came out the compiler (i.e. SGS) and DWB were both add-ons that took up disk space and were usually added $$$ too. Plain C for "psroff", but yes, indeed, C++ for groff. I don't think I ever heard of hpcat, and I can only find one reference to it online with google (in an old 1985 Los Alamos newsletter). Rick Richardson wrote Jetroff. The second release became commercial software, but I briefly used the original 1.0 "shareware" release quite successfully: https://www.tuhs.org/Usenet/comp.sources.misc/1988-September/thread.html My best ever used equipment deal (where I paid actual $$$), was for an almost brand-new Apple LaserWriter 16/600 that had come off lease at a PC leasing agency in Toronto. They didn't know heads or tails about any kind of Apple gear and didn't know how to get the Ethernet adapter for it. I paid just $64.00. It was still on its first toner cartridge. I drove away like I'd robbed the place! Before that I had a cranky old monster of a PS printer of some kind -- it has a 10MB 5.25" hard drive in it that I think contained the fonts. -- Greg A. Woods <gwoods(a)acm.org> Kelowna, BC +1 250 762-7675 RoboHack <woods(a)robohack.ca> Planix, Inc. <woods(a)planix.com> Avoncote Farms <woods(a)avoncote.ca>

On Thu, 11 Feb 2021, Greg A. Woods wrote: The LV-11? We had one at Uni of NSW; it spent most of its time printing biorhythm charts which were all the rage back then. -- Dave

Greg A. Woods writes: Maybe for you; I had it everywhere that I worked.

We used nroff quite a bit with both the Model37 teletype (for which it wsa designed, ours even had the greek box on it) and with output filters for the lineprinter and the Diablos. Later on we drove troff into cat emulators that used Versatec printers. I don’t knwo wher Berkely’s vcat got their fonts, but the JHU verset had an amusing history on that. George Toth went down to the NRL which had a real CAT and printed out the fonts in large point size on film. In the basement of the biophysics bulding was a scanning transmission electron microscope which used a PDP-11/20 as its controller and an older (512x512 or so) framebuffer. George took the scanning wires off the microsope nad hooked them up to the X and Y of a tektronics oscilliscope. Then he put a photomutlipler tube in a scope camera housing and hoked the sense wire from the microscope to that. He now had the worlds most expensive flying spot scanner. He’d tape one letter at a time to the scope and then bring up the microscope sofware (DOS/BATCH I think) and tell it to run the microscope. Then without powering down the memory in the framebuffer, he’d boot up miniunix and copy the stuff from the framebuffer to an RX05 pack. After months of laboriously scanning he was able to write the CAT emulator. I had gone to work for Martin Marietta wirking on a classified project so I wrote hacks to the -mm macro package to handle security markings (automatically putting the highest on each page on thte top and bottom). Later when ditroff became available I continued to use it with various laserprinters. I even wrote macropackages to emulate IBM’s doc style when we were contracting with them. This was all to the chagrin of my boss who wanted us to switch to Framemaker.

Ron. That’s awesome. Ferrin used the Same set of Hersey Font that the XGP used. He got them from Stanford as I recall but they were publically (aka open source) On Wed, Feb 10, 2021 at 7:28 PM Ron Natalie <ron(a)ronnatalie.com> wrote: Sent from a handheld expect more typos than usual

As long as you do it in the USA, it isn't stealing. I was going to write about what a fantastic steal this was but recalled a quirk in US IPR around fonts, and their images. On Thu, Feb 11, 2021 at 12:00 PM Richard Salz <rich.salz(a)gmail.com> wrote:

On Wed, 10 Feb 2021, Richard Salz wrote: I think you can't copyright the shapes, but you can copyright the vectors that generate them because they're technically code. Something weird like that. But that's how you can have all those knockoff fonts Bitstream did, and why a font like Book Antiqua was possible under US law. -uso.

It's important to know the difference between a font and a typeface. A typeface isn't protectable. That's the representation of the actual letters on the printed page (or screen in our case). George was free to scan the output of the phototypesetter. The font is the process to make these (in modern days small programs that generate the letters). This is what can be protected by copyright. The name can be protected by trademark as well. HELVETICA is a trademark (now) of Mergenthaler Linotype. Arial is a similar typeface but that name is owned by Monotype. Straying a little from the topic, a real Linotype machine is a joy to behold. They have one at the Baltimore Museum of Science and Industry that they still fire up weekly. What it does is integrate a keyboard with the actual fonts (molds for molten lead) and casts a line of type (hence the name) at a time. After it does so, the molds go back into sorted hoppers for further use. To answer the other question about George Toth at JHU. He was our documetnation guy and went off to work for Airinc or something. I've not heard from him in a long time. We continued to use his verset and a versatec for a while with straight troff. I also hacked it to draw on the framebuffers in BRL's graphics labs. Later more fonts became available from the Berkeley vcat/vtroff. Ditroff allowed direct selection of mutliple fonts as opposed to having to hack on the "railmag" file (remember that guys?). Standard troff voodoo, just put a power of two backslashes in front of it until it works and if you still have problems add a \c. -Ron

We had vtroff at Berkeley around 1980, on the big Versatec wet plotter, 4 pages wide. We got really good at cutting up the pages on the output. It used the Hershey font. It was horrible. Mangled somehow, lots of parts of glyphs missing. I called it the "Horse Shit" font. I took it as my mission to clean it up. I wrote "fed" to edit it, dot by dot, on the graphical HP 2648 terminal at Berkeley. I got all the fonts reasonably cleaned up, but it was laborious. I still hated Hershey. It was my dream to get real C/A/T output at the largest 36 point size, and scan it in to create a decent set of Times fonts. I finally got the C/A/T output years later at Bell Labs, but there were no scanners available to me at the time. Then True Type came along and it was moot. I did stumble onto one nice rendition of Times Roman in one point size, from Stanford, I think. I used it to write banner(6). On 2/10/21 5:53 PM, Clem Cole wrote:

there was actually a weird fuss about the Merganthaler typesetter. Ken figured out how the fonts were encoded and so we had the raw outline data for all the fonts (they were gorgeous!). this enabled us to add in special characters like the peter weinberger face. ken wanted to do the right thing and tried to license the fonts from Merganthaler, but we had endless discussions where Ken would say “we know how the fonts are encoded, can we license them?” and the sales person would say “no you can’t; they’re secret”, and so on. we’d even show them the peter face but to no avail. so we kinda flew under the radar for that (but we tried!). the typesetter itself was entertaining; if i recall correctly, the software ran on a 8in floppy and Ken wrote a B compiler/run time system for the computer inside. andrew

Andrew Hume &lt;andrew(a)humeweb.com&gt; wrote: The 202 reconstruction paper also bemoans the bit-rot loss of the information about the Mergenthaler character representation. This reminded me of a project that I and a small team did in the 1980s. We were licensees of Sun's NeWS source code, and we wanted our software to be able to use the wide variety of fonts sold commercially by Adobe and font design companies. The problem was, they were encoded in Adobe Type 1 font definitions, which Adobe considered a proprietary trade secret. Due to the lack of copyright protection for fonts (whose whole raison d'etre is to be copied onto paper many thousands or millions of times by each user), font designers used security by obscurity to protect their work. Our team ended up pulling the ROMs out of an original LaserWriter, and writing and improving a 68000 disassembler. One of our team members read the code, figured out which parts handled these fonts, and how it decoded them. He wrote that down in his own words in a plain text document, not a program, following the prevailing court decisions about how to avoid copyright issues while reverse-engineering a trade secret. Ultimately, we released that document to some interested people, so that others could implement support for Type 1 fonts. Shortly afterward, Adobe magnanimously decided to "release the specification", as Wikipedia says. Later, I got a nice note from L. Peter Deutsch, maintainer of Ghostscript, who said: I just received my copy of the Adobe Type 1 Font Format book, and compared the contents against the message you sent me last July. You guys at Grasshopper really did a good job of cracking the format. I was amused to see that the book omits quite a few operators that you deciphered on your own. This wasn't too long after Adobe had also been threatening Sun and its NeWS licensees for re-implementing PostScript from its spec, rather than licensing it from them. I had noticed a paragraph in the prospectus for their IPO, which said something like, "Adobe has put PostScript into the public domain in order to encourage its wide use." Either the language was free for anyone to implement, or they were guilty of securities fraud. When hoist on that petard, so to speak, they backed down. John Appendix: The reverse-engineered font format. I was happy to be able to find a copy of this on my current machine -- it too could have bit-rotted in the last 30 years. File mod date is 1989. I am not the author. Description of Adobe PostScript FontType 1 PostScript FontType 1 is Adobe's proprietary font format. The internal fonts in Apple LaserWriters (the Times, Helvetica, and Courier families) are stored in this format, although the stroke descriptions are not normally available outside the LaserWriter. Other fonts from Adobe are also in this format, although an additional layer of encryption prevents the stroke descriptions from being directly visible. IMPORTANT NOTE: The shrink-wrap license agreement under which external Adobe fonts are distributed expressly forbids the decryption and decompilation of these fonts. It does not appear to forbid the using of a program to decrypt and display these fonts, (since this is what happens to them inside a PostScript printer) as long as they are not used on more than one PRINTER at a time. PostScript fonts are accessed through Font Dictionaries. See the Red Book, section 5.3, for a description of the standard entries in a Font Dictionary. The entries we will concern ourselves with here are the dictionaries CharStrings and Private. The character shape descriptions are stored in CharStrings in an encrypted format. The shape descriptions are reached via the Encoding vector, see section 5.4. When a character needs to be rendered, a pseudo-code interpreter is called, and handed the encrypted shape description, and the Font Dictionary. The pseudo-code interpreter checks that this is a valid Type 1 font. The Font Dictionary for a valid font must contain an entry called `Private', which is a dictionary. Private must contain the entry `password', an integer having the value 5839. The shape descriptions have the ability to call other encrypted routines, accessed by their index in the array `Subrs', defined in Private. The encrypted routines can also call PostScript code directly, executing an element from the array `OtherSubrs', defined in Private. Execution of the pseudo-code occurs in the same environment as the BuildChar routine for a user defined font (see section 5.7). A gsave precedes this execution, and the CTM is modified by the FontMatrix. Upon exiting, a grestore is performed, and the currentpoint is updated by the width of the character. Encrypted routines from CharStrings and Subrs can be decrypted with the following program. Routines in OtherSubrs are ordinary, unencrypted PostScript code. #include <stdio.h> int magic1, magic2, magic3, magic4, mask; main() { int c, d, skip4; #ifdef eexec magic1 = 0x9a36dda2 ; magic2 = 0x9a3704d3 ; #else magic1 = 0x3f8927b5 ; magic2 = 0x3fea375f ; #endif magic3 = 0x3fc5ce6d ; magic4 = 0x0d8658bf ; mask = magic1 ^ magic2 ; skip4 = 0 ; printf("<"); while ((c=getchar())!=EOF) { d = ((mask >> 8) ^ c) & 0xff ; if (++skip4 > 4) #ifdef eexec putchar(d); #else printf(" %02x", d); #endif mask = magic4 + magic3 * (mask + c) ; } printf(" >"); exit(0); } Note that this is the same decryption algorythm used for eexec, except that the initial mask value, as determined by magic1 and magic2, is different. The result of decrypting is a font rendering pseudo code. Strings are stored encrypted in memory, and decrypted on the fly by the interpreter as it executes the pseudo-code. Description of the pseudo-code. The pseudo-code interpreter obtains bytes in sequence from the decryption routine. These bytes are grouped into a sequence of instructions. Each instruction encodes either a number (which is pushed onto an internal stack), or an operation (which is performed). The initial byte of each pseudo-code instruction encodes its type and length. Initial bytes in the range 0x00-0x1f (inclusive) encode operations. Common operations are encoded completely by a single byte, and require no additional bytes. Less common operations are encoded in two bytes. The initial byte of a two byte operation is always 0x0c. The second byte has a value in the range 0x00-0x21 (inclusive), which specifies the operation. Initial bytes in the range 0x20-0xf6 (inclusive) encode small numbers. No additional bytes are required for a small number. The value pushed on the stack is the initial byte minus 0x8b. Initial bytes in the range 0xf7-0xfe (inclusive) encode medium numbers. Medium numbers are followed by one additional byte. Medium numbers come in two flavors: positive, and negative. Initial bytes in the range 0xf7-0xfa (inclusive) encode positive numbers, the remainder are negative. The magnitude of the number pushed is: (( ((initial_byte-0xf7)&3) << 8) | additional_byte) + 0x6c If the initial byte indicates that the number is negative, the number calculated above is negated before being pushed onto the stack. An initial byte of 0xff indicates a large number. A large number requires 4 additional bytes to specify its value. The large number's value is encoded directly in the additional bytes, most significant byte first, in decending order of significance. When a number is encountered, it is pushed onto an internal stack (seperate from the PostScript operand stack). Most operations take values from this stack, and a few return values on the stack. In general it is not important that this is not the real operand stack. The exceptions are OtherSubrs and StackShift. One of the arguments to OtherSubrs is an argument count. It transfers that many arguments from the internal stack to the operand stack before calling the PostScript procedure. After the procedure returns, StackShift may be used to transfer individual values from the operand stack to the internal stack. Another difference between the stacks is that some of the operations clear the stack after execution. These operations read their arguments from the bottom of the stack, not the top, so in this sence, it isn't really a stack, but it can still be thought of as behaving like one, at least locally. Operations which exhibit this behavior are marked below with an *. Many of the operations perform functions similar to certain PostScript operators. In these cases, only the name of the appropriate PostScript operator is given. Many of the path extension commands have additional versions which restrict the motion associated with them to being horizontal or vertical, thus one fewer argument is needed for them. These are identified by an `h' or `v', generally as the second character of the name. Thus rhlineto is equivalent to: { 0 exch rlineto } Additionally, the operators max and min are available, which are, for some reason, missing from PostScript. Codes labeled `(variable)' look up the given name in the Private dictionary and push the associated value onto the internal stack. Descriptions of short operations. 0x00 * VHintWidth ycenter ==> - 0x01 * VHint bottom vwidth ==> - 0x02 * HHintWidth xcenter ==> - 0x03 * HHint left hwidth ==> - These operations give information about the position of some of the features of a character to the non-linear scaling code. The dynamics of the non-linear scaling is not yet clear. The *Width operations take one argument, assuming StrokeWidth as the second arg (the first arg indicates the center of the line to be stroked). The other operations take 2 arguments, the first being a (horizontal or vertical) position of the (left or bottom) side of the feature, and the second being the width of the feature being described. These, and similar hint routines, are called before any path construction operators. 0x04 * rvmoveto ydelta ==> - 0x05 * rlineto xdelta ydelta ==> - 0x06 * rhlineto xdelta ==> - 0x07 * rvlineto ydelta ==> - 0x08 * rspline dx1 dy1 dx2 dy2 dx3 dy3 ==> - similar to rcurveto, but each control point is specified relative to the previous one, instead of relative to the currentpoint. 0x09 * closepath - ==> - 0x0a Subrs sub ==> - takes one argument, the number of the subroutine to execute in Private/Subrs. 0x0b Retn - ==> - return from subroutine. All elements of Subrs end with this operation. 0x0c LongOp followed by another operation code, as described below. 0x0d * Metrics lsb_x width_x ==> - takes two arguments: the left side bearing, and width. This information is used (with the y values of each assumed zero) if it is not overrided by an element in the font dictionary's Metrics entry. This is usually the first operation executed by a CharString routine. The internal currentpoint is set to the left side bearing. 0x0e Finish - ==> (stack no longer exists) clean up and either fill or stroke the path (depending on PaintType), grestore, and exit. Apparently, font cache information is determined here for all PaintTypes except 3. Fonts of PaintType 3 would call setcachedevice before executing any rendering operations, and would exit with QuickFinish. Some of the operations labeled here with ?'s are likely to be fill and stroke, for use only by PaintType 3 fonts. 0x0f * moveto x y ==> - 0x10 * lineto x y ==> - 0x11 * curveto x1 y1 x2 y2 x3 y3 ==> - 0x12 min a b ==> min(a, b) 0x13 * ? 26c8c6(3fe0000000000000) ? - ==> - 0x14 * newpath - ==> - 0x15 * rmoveto dx dy ==> - 0x16 * rhmoveto dx ==> - 0x17 * ? set two bits of something in gstate ? ferd ==> - 0x18 mul a b ==> a*b 0x19 strokewidth (variable) 0x1a baseline (variable) 0x1b capheight (variable) 0x1c bover (variable) 0x1e * htovrspline dx1 dx2 dy2 dy3 ==> - 0x1f * vtohrspline dy1 dx2 dy2 dx3 ==> - these take 4 args instead of six, set the remaining two to 0, and call rspline. The curves are constrained to start and end either vertically or horizontally. Long Operations 0x00 * ? toggle something and remember... strange. ? - ==> - this operation appears around some subrs. sometimes it is outside the call, and sometimes inside the subr itself. it always appears in pairs. the first call to it sets a value to zero. the second call sets it to some function of the currentpoint. the value is used to modify all of the coordinates somehow, apparently in conjunction with the non-linear scaling, but only when other conditions are met. 0x01 * HMHint x1 width1 x2 width2 x3 width3 ==> - 0x02 * VMHint y1 height1 y2 height2 y3 height3 ==> - These each take 6 args and appear to encode information for 3 position/value pairs. See HHint above. 0x03 * ? something about MinFeature ? 0x04 * arc x y r ang1 ang2 ==> - 0x05 * ? 1 arg to 26a9f4 ? ferd ==> - 0x06 * Accent ferd x y base accent ==> (no stack) Used to create composite characters. Executes the character routine corresponding to base, then adjusts the current position by x and y, and executes the character routine corresponding to accent. Base and accent are character codes (0-255). This terminates execution for this character. First arg is unclear, but modifies the x position of the accent character somehow. 0x07 * LongMetrics lsbx lsby widthx widthy ==> - same as Metrics, but specifies y values as well. 0x08 * setcachedevice llx lly urx ury ==> - character width is taken from the metric information, so only 4 args are required. the bounding box is expanded by strokewidth/2 on all sides before being passed to the actual routine. Presumably only used by PaintType 3 fonts. 0x09 * QuickFinish - ==> (no stack) exit without cleaning up or stroking or filling. just grestore. 0x0a add a b ==> a+b 0x0b sub a b ==> a-b 0x0c div a b ==> a/b 0x0d max a b ==> max(a, b) 0x0e neg a ==> -a 0x0f TestAdd a b c d ==> b > c ? a + d : a 0x10 OtherSubrs a1 a2 a3 ... an n index ==> - call directly to PostScript code. top of stack is index of code to call, next is number of args to transfer to operand stack, followed by the args to be transferred. 0x11 StackShift - ==> n move a number from the operand stack to the internal stack. 0x12 decend (variable) 0x13 ascend (variable) 0x14 overshoot (variable) 0x15 * ? set two bits of something in gstate ? ferd ==> - 0x16 xover (variable) 0x17 capover (variable) 0x18 aover (variable) 0x19 halfsw (variable) 0x1a PixelRound round a value to an even boundary in device space. this is just a guess, not verified. 0x1b * arcn x y r ang1 ang2 ==> - 0x1c exch a b ==> b a 0x1d index an ... a1 a0 n ==> an ... a1 a0 an 0x1e * VHintRound bottom vwidth ==> - 0x1f * HHintRound left hwidth ==> - Same as VHint and HHint, except the width is sent to the pixel round routine. Additionally, these will take negative widths and deal with them correctly, the others might not. 0x20 ** currentpoint - ==> x y after pushing the coordinates onto the top of the stack, the stack pointer is set to point at the bottom of the stack. presumably this should only be used when the stack is clear. in any case, no math can be performed on these values, as the stack is `empty' when they are there. this might be a bug, as I suspect these were meant to be passed to Qmoveto, but they can never get there. moveto, however will work correctly. 0x21 ** Qmoveto x y ==> - doesn't actually call moveto, just remembers new position internally. the arguments are poped from the top of the stack, and then the stack is cleared.

On Thu, Feb 11, 2021 at 12:34 PM Jon Forrest &lt;nobozo(a)gmail.com&gt; wrote: "It steam-engines when it comes steam-engine time." John Cowan http://vrici.lojban.org/~cowan cowan(a)ccil.org How they ever reached any conclusion at all is starkly unknowable to the human mind. --"Backstage Lensman", Randall Garrett

On Mon, 30 Nov 2020, jason-tuhs(a)shalott.net wrote: My personal opinion is that the way the Bourne shell handled flow control is a lot easier to code for (since I wrote a version of COMMAND.COM, and it has to have a "goto" command, and all the hairiness that goes with needing to be able to random-seek a shell script). -uso.

On 2020-12-01 10:09 a.m., Jim Capp wrote: Broadly connected to the rise of Structured Programming -- which we take fully for granted today. The same movement, and the popularity of Pascal, which was very competitive with C as an applications language, would have motivated the inclusion of what were at the time considered "high level" control structures, in C: do/while/for and block structuring. --Toby

On Tue, Dec 1, 2020 at 8:39 AM &lt;arnold(a)skeeve.com&gt; wrote: This is true for simple flow control. However, when you had to break out of multiple levels, or continue not the inner loop, but the middle loop, the use of extra booleans sure made the code less understandable than a 'goto' a label that stood in for that purpose... This was something that wasn't well understood by language designers, and even today C and C++ neither have good flow control beyond the basics. Even though both break and continue could take an optional count without breaking old code.... Warner

Go lets you say "Loop: for ..." and then "break Loop". -rob On Wed, Dec 2, 2020 at 3:40 AM &lt;arnold(a)skeeve.com&gt; wrote:

Yes. -rob On Wed, Dec 2, 2020 at 6:08 PM &lt;arnold(a)skeeve.com&gt; wrote:

On Dec 1, 2020, at 12:20 PM, Steffen Nurpmeso &lt;steffen(a)sdaoden.eu&gt; wrote: Pascal had goto. You can even do a non-local goto! In Go you don't need goto for the sort of thing you and McVoy talked about due to its defer statement and GC. Now granted GC may be too big of a hammer for C/C++ but a future C/C++ add defer gainfully as the defer pattern is pretty common. For example, mutex lock and unlock. But I have mixed feelings about goto vs continue/break. A nested loop with multiple continue/break can be as obscure.

On Tue, Dec 1, 2020 at 3:40 PM Bakul Shah &lt;bakul(a)iitbombay.org&gt; wrote: Along those lines, it's always been interesting to me the way that D-1stra originally sent "Go to [...]" to CACM as a paper entitled "A Case Against The Go To Statement". But the editor, who was Niklaus Wirth, thought it important to publish it quickly, so he turned it into a letter to the editor and retitled it.

On Tue, Dec 01, 2020 at 09:24:17AM -0700, Warner Losh wrote: Probably need to move this to COFF... but. Yeah, I've tons of examples of int somefunc() { char *a = 0; int *b = 0; flat *c = 0; int ret = 0; if (something) { a = malloc(something); } else { ret = NO_SOMETHING; goto error; } // same for b, c error: unless (ret) ret = GENERIC_ERROR; if (a) free(a); if (b) free(b); if (c) free(c); return (ret); } and you can handle a lot of simple cases that way. But sometimes the unraveling is more difficult than a simple free so I might have a goto unravel; instead of the generic goto out; I love goto *if* you figure out a pattern for using it and stick to that. For the people who don't like goto, what is your feeling on longjmp()?

On Tue, Dec 1, 2020 at 3:14 PM Dave Horsfall &lt;dave(a)horsfall.org&gt; wrote: But cheerfully so, according to Knuth. He is also known for the invention of hash consing. Knuth's article "Structured programming with goto statements" <http://www.clifford.at/cfun/cliffdev/p261-knuth.pdf> is a great discussion of all the reasons you'd want to use goto in languages with just conditionals and while loops: error exits, jumping out of nested tests, jumping out of a nest of conditionals and break/continue (both essentially kinds of static catch tags), loops iterated n-and-a-half-times (break will do this, but it's over-powered), tail recursion, "encoding boolean variables in the program counter", coroutines. There are also such things as fast linear search by putting the searched-for value at the end of the array being searched, and what boils down to Lisp macros ("allowing an optimizing compiler to express its optimizations in the source language"). On Tue, Dec 1, 2020 at 3:39 PM Bakul Shah &lt;bakul(a)iitbombay.org&gt; wrote: I think if the loops are labeled rather than the destinations, and you use "next foo" instead of "continue" and "last foo" instead of "break", it's all quite readable. John Cowan http://vrici.lojban.org/~cowan cowan(a)ccil.org Sir, I quite agree with you, but what are we two against so many? --George Bernard Shaw, to a man booing at the opening of _Arms and the Man_