[-- Attachment #1: Type: text/plain, Size: 211 bytes --] Apologies if this has already been linked here. "The UNIX Command Languageis the first-ever paper published on the Unix shell. It was written by Ken Thompson in 1976." https://github.com/susam/tucl Joachim [-- Attachment #2: Type: text/html, Size: 2072 bytes --]
Thank you very much! I've been looking for where Ken used the "much needed gap" phrase.
Brantley
> On Nov 29, 2020, at 10:10 PM, Joachim via TUHS <tuhs@minnie.tuhs.org> wrote:
>
> Apologies if this has already been linked here.
>
> "The UNIX Command Language is the first-ever paper published on the Unix shell. It was written by Ken Thompson in 1976."
>
> https://github.com/susam/tucl
>
>
> Joachim
Brantley Coile <brantley@coraid.com> writes:
> Thank you very much! I've been looking for where Ken used the "much
> needed gap" phrase.
That formulation is funny - but I just got into a discussion with
someone about whether ken was being intentionally funny or not. To me,
it seems rather obvious that he chose that wording for the humourous
effect of the double-take the reader experiences. A couple of friends
of mine, though, insist that that paragraph is just clumsily written.
Is he on record anywhere saying which it is?
-tih
--
Most people who graduate with CS degrees don't understand the significance
of Lisp. Lisp is the most important idea in computer science. --Alan Kay
[-- Attachment #1: Type: text/plain, Size: 578 bytes --] Too bad, they did not use the UNIX tool kit like troff and eqn which are described in the paper itself, to restore it. If you were going to the trouble to make the 'md' file - it would have been just as easy to create troff source. Sigh ... get off my lawn ... Clem On Sun, Nov 29, 2020 at 10:17 PM Joachim via TUHS <tuhs@minnie.tuhs.org> wrote: > Apologies if this has already been linked here. > > "The UNIX Command Language is the first-ever paper published on the Unix > shell. It was written by Ken Thompson in 1976." > > https://github.com/susam/tucl > > > Joachim > [-- Attachment #2: Type: text/html, Size: 2722 bytes --]
[-- Attachment #1: Type: text/plain, Size: 975 bytes --] On Mon, Nov 30, 2020 at 10:54 AM Clem Cole <clemc@ccc.com> wrote: > Too bad, they did not use the UNIX tool kit like troff and eqn which are > described in the paper itself, to restore it. If you were going to the > trouble to make the 'md' file - it would have been just as easy to create > troff source. > In fairness, the Markdown renders directly from the github web UI, but I agree that using troff/eqn would have been nice. Surely it wouldn't be that hard to massage the markdown into troff markdown. Sigh ... get off my lawn ... > I don't even have a lawn and I'm similarly distressed at the lack of homage to the past. - Dan C. On Sun, Nov 29, 2020 at 10:17 PM Joachim via TUHS <tuhs@minnie.tuhs.org> > wrote: > >> Apologies if this has already been linked here. >> >> "The UNIX Command Language is the first-ever paper published on the Unix >> shell. It was written by Ken Thompson in 1976." >> >> https://github.com/susam/tucl >> >> >> Joachim >> > [-- Attachment #2: Type: text/html, Size: 3503 bytes --]
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: > Too bad, they did not use the UNIX tool kit like troff and eqn which are > described in the paper itself, to restore it. If you were going to the > trouble to make the 'md' file - it would have been just as easy to create > troff source. > > Sigh ... get off my lawn ... > > Clem > > On Sun, Nov 29, 2020 at 10:17 PM Joachim via TUHS <tuhs@minnie.tuhs.org> > wrote: > > > Apologies if this has already been linked here. > > > > "The UNIX Command Language is the first-ever paper published on the Unix > > shell. It was written by Ken Thompson in 1976." > > > > https://github.com/susam/tucl > > > > > > Joachim > > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
[-- Attachment #1: Type: text/plain, Size: 983 bytes --] On Mon, Nov 30, 2020 at 9:27 AM Dan Cross <crossd@gmail.com> wrote: > On Mon, Nov 30, 2020 at 10:54 AM Clem Cole <clemc@ccc.com> wrote: > >> Too bad, they did not use the UNIX tool kit like troff and eqn which are >> described in the paper itself, to restore it. If you were going to the >> trouble to make the 'md' file - it would have been just as easy to create >> troff source. >> > > In fairness, the Markdown renders directly from the github web UI, but I > agree that using troff/eqn would have been nice. Surely it wouldn't be that > hard to massage the markdown into troff markdown. > 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 [-- Attachment #2: Type: text/html, Size: 1693 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1272 bytes --] On Mon, Nov 30, 2020 at 11:38 AM Warner Losh <imp@bsdimp.com> wrote: > On Mon, Nov 30, 2020 at 9:27 AM Dan Cross <crossd@gmail.com> wrote: > >> On Mon, Nov 30, 2020 at 10:54 AM Clem Cole <clemc@ccc.com> wrote: >> >>> Too bad, they did not use the UNIX tool kit like troff and eqn which are >>> described in the paper itself, to restore it. If you were going to the >>> trouble to make the 'md' file - it would have been just as easy to create >>> troff source. >>> >> >> In fairness, the Markdown renders directly from the github web UI, but I >> agree that using troff/eqn would have been nice. Surely it wouldn't be that >> hard to massage the markdown into troff markdown. >> > > 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... > Sure, but this is a fairly short paper...I bet one could do a fairly faithful reproduction of the original in a couple of hours. I may take a stab at it and send a pull request. - Dan C. [-- Attachment #2: Type: text/html, Size: 2227 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1665 bytes --] On Mon, Nov 30, 2020 at 11:37 AM Larry McVoy <lm@mcvoy.com> wrote: > 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. Indeed > Unless you had a Unix license, no troff for you! yes ... but ... even UNIX binary folks had troff licenses and many/most at ditroff licenses. I know Masscomp just ate $5 per CPU and included it because we did not want to mess with the older version. If you were an academic, it was free so most research academics had either the source or at least a binary on their workstations. This did not become an issue until the 386, but by that time Clark had written what would be groff. I think your observation is correct, but in practice, I don't think that was what it was. I think the academics went LaTex and that had more to do with it. LaTex was closer to Scribe for the PDP-10s and Vaxen, which had a short head lead on all them until it went walled garden when CMU sold the rights (and even its author - Brian Ried) could not use it at a Stanford. So your are right, Wall Garden certainly impacted the result, but I think it was more preference in this case. > 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). Ditto to both. > I wish we lived in a troff world but we don't > Yep > and that is a direct result of haves (license holders) and have nots > (the other 99.999999% of the world). > Maybe -- I think the PC and Word was the real kiss of death, which I find even more troubling. > > It's not the result we would like but it is what it is. > +1 [-- Attachment #2: Type: text/html, Size: 4454 bytes --]
On Mon, Nov 30, 2020 at 11:54:37AM -0500, Clem Cole wrote:
>
> I think the academics went LaTex and that had more to do with it. LaTex
> was closer to Scribe for the PDP-10s and Vaxen, which had a short head lead
> on all them until it went walled garden when CMU sold the rights (and even
> its author - Brian Ried) could not use it at a Stanford.
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
[-- Attachment #1: Type: text/plain, Size: 880 bytes --] On Mon, Nov 30, 2020 at 11:55 AM Clem Cole <clemc@ccc.com> wrote: > I wish we lived in a troff world but we don't >> > Yep > I think O'Reilly was the last commercial publisher with a troff toolchain. Nowadays they accept HTMLBook (their own static subset of HTML5), DocBook, ASCIIDoc (analogous to Markdown but plain-text DocBook as opposed to plain-text HTML), Word, and in some cases InDesign or PDF. John Cowan http://vrici.lojban.org/~cowan cowan@ccil.org And through this revolting graveyard of the universe the muffled, maddening beating of drums, and thin, monotonous whine of blasphemous flutes from inconceivable, unlighted chambers beyond Time; the detestable pounding and piping whereunto dance slowly, awkwardly, and absurdly the gigantic tenebrous ultimate gods --the blind, voiceless, mindless gargoyles whose soul is Nyarlathotep. (Lovecraft) [-- Attachment #2: Type: text/html, Size: 2432 bytes --]
[-- Attachment #1: Type: text/plain, Size: 466 bytes --] On Mon, Nov 30, 2020 at 1:25 PM John Cowan <cowan@ccil.org> wrote: > > > On Mon, Nov 30, 2020 at 11:55 AM Clem Cole <clemc@ccc.com> wrote: > > >> I wish we lived in a troff world but we don't >>> >> Yep >> > > I think O'Reilly was the last commercial publisher with a troff toolchain. > 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. [-- Attachment #2: Type: text/html, Size: 1766 bytes --]
We seem to be straying into COFF-land. However... On 11/30/20 13:25, John Cowan wrote: > On Mon, Nov 30, 2020 at 11:55 AM Clem Cole <clemc@ccc.com > <mailto:clemc@ccc.com>> wrote: > > I wish we lived in a troff world but we don't > > Yep > > > I think O'Reilly was the last commercial publisher with a troff > toolchain. Nowadays they accept HTMLBook (their own static subset of > HTML5), DocBook, ASCIIDoc (analogous to Markdown but plain-text > DocBook as opposed to plain-text HTML), Word, and in some cases > InDesign or PDF. 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. > John Cowan http://vrici.lojban.org/~cowan > <http://vrici.lojban.org/%7Ecowan> cowan@ccil.org <mailto:cowan@ccil.org>
Clem Cole <clemc@ccc.com> wrote: > > I think O'Reilly was the last commercial publisher with a troff toolchain. They stopped using troff directly well over 20 years ago. These days if you're using a markup language and their toolset it's either Asciidoc or docbook. > I think it depends on who you are and your editor is at the said firm. Tim > will still take troff I assume you mean Tim O'Reilly? He hasn't been involved in the book side of his business in decades, and as I said, troff isn't in the picture there. > as will John Waite at Pearson. They farm such things out, they don't accept it in house. Or the author can provide "camera ready copy", which these days just means PDF. > That said, as Jon can tell you, Bill will not. No idea who Bill is. Arnold
[-- Attachment #1: Type: text/plain, Size: 1159 bytes --] 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@skeeve.com wrote: > Clem Cole <clemc@ccc.com> wrote: > >>> I think O'Reilly was the last commercial publisher with a troff toolchain. > They stopped using troff directly well over 20 years ago. > These days if you're using a markup language and their toolset it's > either Asciidoc or docbook. > >> I think it depends on who you are and your editor is at the said firm. Tim >> will still take troff > I assume you mean Tim O'Reilly? He hasn't been involved in the book > side of his business in decades, and as I said, troff isn't in the picture > there. > >> as will John Waite at Pearson. > They farm such things out, they don't accept it in house. > Or the author can provide "camera ready copy", which these days > just means PDF. > >> That said, as Jon can tell you, Bill will not. > No idea who Bill is. > > Arnold -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF [-- Attachment #2: Type: text/html, Size: 2509 bytes --]
arnold@skeeve.com writes:
>
> > That said, as Jon can tell you, Bill will not.
>
> No idea who Bill is.
Bill Pollack, No Starch Press.
[-- Attachment #1: Type: text/plain, Size: 626 bytes --] > "The UNIX Command Language is the first-ever paper published on the Unix > shell. It was written by Ken Thompson in 1976." > > https://github.com/susam/tucl Thanks for that. This reminded me that the Thompson shell used goto for flow control, which I had forgotten. Bourne commented on the omission of goto from the Bourne shell, "I eliminated goto in favour of flow control primitives like if and for. This was also considered rather radical departure from the existing practice." Was this decision contentious at all? Was there a specific reason for goto's exclusion in the Bourne shell? Thanks. -Jason
jason-tuhs@shalott.net writes:
>
> Bourne commented on the omission of goto from the Bourne shell, "I
> eliminated goto in favour of flow control primitives like if and for.
> This was also considered rather radical departure from the existing
> practice."
>
> Was this decision contentious at all? Was there a specific reason for
> goto's exclusion in the Bourne shell?
I don't remember if this story has been told here before or not but I got
it from Steve a few months ago. Ever wonder by the shell was symmetrical
with if and fi, case and esac, but then had do and done? Reason was that
by the time Steve wrote the shell, Ken had written the od command and dug
in his heels and wouldn't change the name.
Jon
[-- Attachment #1: Type: text/plain, Size: 987 bytes --] On Mon, 30 Nov 2020, jason-tuhs@shalott.net wrote: > >> "The UNIX Command Language is the first-ever paper published on the Unix >> shell. It was written by Ken Thompson in 1976." >> >> https://github.com/susam/tucl > > Thanks for that. > > This reminded me that the Thompson shell used goto for flow control, which I > had forgotten. > > Bourne commented on the omission of goto from the Bourne shell, "I eliminated > goto in favour of flow control primitives like if and for. This was also > considered rather radical departure from the existing practice." > > Was this decision contentious at all? Was there a specific reason for goto's > exclusion in the Bourne shell? > > > Thanks. > > > -Jason 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.
[-- Attachment #1: Type: text/plain, Size: 1007 bytes --] Is it possible the elimination of the GOTO statement in the Bourne Shell was related to a Letter to the Editor in Communications of the ACM, March 1968: "Go To Statement Considered Harmful," by E. Dijkstra. Jim From: jason-tuhs@shalott.net To: tuhs@minnie.tuhs.org Sent: Monday, November 30, 2020 10:59:18 PM Subject: Re: [TUHS] The UNIX Command Language (1976) > "The UNIX Command Language is the first-ever paper published on the Unix > shell. It was written by Ken Thompson in 1976." > > https://github.com/susam/tucl Thanks for that. This reminded me that the Thompson shell used goto for flow control, which I had forgotten. Bourne commented on the omission of goto from the Bourne shell, "I eliminated goto in favour of flow control primitives like if and for. This was also considered rather radical departure from the existing practice." Was this decision contentious at all? Was there a specific reason for goto's exclusion in the Bourne shell? Thanks. -Jason [-- Attachment #2: Type: text/html, Size: 1502 bytes --]
On 2020-12-01 10:09 a.m., Jim Capp wrote: > Is it possible the elimination of the GOTO statement in the Bourne Shell > was related to a Letter to the Editor in Communications of the ACM, > March 1968: > "Go To Statement Considered Harmful," by E. Dijkstra. > 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 > Jim > > > ------------------------------------------------------------------------ > *From: *jason-tuhs@shalott.net > *To: *tuhs@minnie.tuhs.org > *Sent: *Monday, November 30, 2020 10:59:18 PM > *Subject: *Re: [TUHS] The UNIX Command Language (1976) > > >> "The UNIX Command Language is the first-ever paper published on the Unix >> shell. It was written by Ken Thompson in 1976." >> >> https://github.com/susam/tucl > > Thanks for that. > > This reminded me that the Thompson shell used goto for flow control, which > I had forgotten. > > Bourne commented on the omission of goto from the Bourne shell, "I > eliminated goto in favour of flow control primitives like if and for. > This was also considered rather radical departure from the existing > practice." > > Was this decision contentious at all? Was there a specific reason for > goto's exclusion in the Bourne shell? > > > Thanks. > > > -Jason
In the late 70s and early 80s, structured programming was on the
ascension, but had not completely captured the minds of all computer
scientists and programmers. (cf. Knuth's "Structure Programming with
Goto Statements" article.)
It was recognized that goto was not necessary if one had proper control
structures in a language (if/else, while), and that code with no (or
minimal) gotos was easier to read and understand.
So this kind of thing was "in the air" when Bourne wrote the V7 shell.
If he's on this list, it'd be nice to hear directly from the source. :-)
HTH,
Arnold
Jim Capp <jcapp@anteil.com> wrote:
> Is it possible the elimination of the GOTO statement in the Bourne Shell
> was related to a Letter to the Editor in Communications of the ACM, March 1968:
>
> "Go To Statement Considered Harmful," by E. Dijkstra.
>
> Jim
>
>
> From: jason-tuhs@shalott.net
> To: tuhs@minnie.tuhs.org
> Sent: Monday, November 30, 2020 10:59:18 PM
> Subject: Re: [TUHS] The UNIX Command Language (1976)
>
> > "The UNIX Command Language is the first-ever paper published on the Unix
> > shell. It was written by Ken Thompson in 1976."
> >
> > https://github.com/susam/tucl
>
> Thanks for that.
>
> This reminded me that the Thompson shell used goto for flow control, which
> I had forgotten.
>
> Bourne commented on the omission of goto from the Bourne shell, "I
> eliminated goto in favour of flow control primitives like if and for.
> This was also considered rather radical departure from the existing
> practice."
>
> Was this decision contentious at all? Was there a specific reason for
> goto's exclusion in the Bourne shell?
>
> Thanks.
>
> -Jason
[-- Attachment #1: Type: text/plain, Size: 747 bytes --] "The most exotic feature of the Shell is its ability to connect the standard output of one command directly to the standard input of another. *Again, neither program is aware that such things are going on.* In the example" So sad that many shell programs today break this abstraction barrier :/ Was there a watershed moment when people started doing this, or people just always couldn't resist the "convenience" of typing less? Tyler On Mon, Nov 30, 2020 at 5:18 AM Joachim via TUHS <tuhs@minnie.tuhs.org> wrote: > Apologies if this has already been linked here. > > "The UNIX Command Language is the first-ever paper published on the Unix > shell. It was written by Ken Thompson in 1976." > > https://github.com/susam/tucl > > > Joachim > [-- Attachment #2: Type: text/html, Size: 2626 bytes --]
[-- Attachment #1: Type: text/plain, Size: 774 bytes --] On Tue, Dec 1, 2020 at 8:39 AM <arnold@skeeve.com> wrote: > It was recognized that goto was not necessary if one had proper control > structures in a language (if/else, while), and that code with no (or > minimal) gotos was easier to read and understand. > 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 [-- Attachment #2: Type: text/html, Size: 1144 bytes --]
> On Tue, Dec 1, 2020 at 8:39 AM <arnold@skeeve.com> wrote: > > It was recognized that goto was not necessary if one had proper control > > structures in a language (if/else, while), and that code with no (or > > minimal) gotos was easier to read and understand. Warner Losh <imp@bsdimp.com> 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.... Quite true. Modern Bourne shells let you supply a number to break and continue to specify how many loops to break. Ada, or maybe it was one of the Modula-X languages, let you put a label on a loop so that you could say `continue outer' or `break outer' and not need the booleans. This is something that newer languages (C#, Java, Go, ...) could have picked up but didn't, which I think is too bad. Arnold
On Tue, Dec 01, 2020 at 09:24:17AM -0700, Warner Losh wrote:
> On Tue, Dec 1, 2020 at 8:39 AM <arnold@skeeve.com> wrote:
>
> > It was recognized that goto was not necessary if one had proper control
> > structures in a language (if/else, while), and that code with no (or
> > minimal) gotos was easier to read and understand.
> >
>
> 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....
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()?
[-- Attachment #1: Type: text/plain, Size: 1402 bytes --] Go lets you say "Loop: for ..." and then "break Loop". -rob On Wed, Dec 2, 2020 at 3:40 AM <arnold@skeeve.com> wrote: > > On Tue, Dec 1, 2020 at 8:39 AM <arnold@skeeve.com> wrote: > > > It was recognized that goto was not necessary if one had proper control > > > structures in a language (if/else, while), and that code with no (or > > > minimal) gotos was easier to read and understand. > > Warner Losh <imp@bsdimp.com> 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.... > > Quite true. Modern Bourne shells let you supply a number to break and > continue to specify how many loops to break. Ada, or maybe it was one of > the Modula-X languages, let you put a label on a loop so that you could > say `continue outer' or `break outer' and not need the booleans. > > This is something that newer languages (C#, Java, Go, ...) could have > picked > up but didn't, which I think is too bad. > > Arnold > [-- Attachment #2: Type: text/html, Size: 1988 bytes --]
On Tue, 1 Dec 2020, Jim Capp wrote:
> Is it possible the elimination of the GOTO statement in the Bourne
> Shellwas related to a Letter to the Editor in Communications of the ACM,
> March 1968: "Go To Statement Considered Harmful," by E. Dijkstra.
And then there was the story of Professor Goto (a Japanese citizen and
computer bod) who complained that everyone was trying to eliminate him :-)
-- Dave
arnold@skeeve.com wrote in <202012011639.0B1GdjcD031722@freefriends.org>: |> On Tue, Dec 1, 2020 at 8:39 AM <arnold@skeeve.com> wrote: |>> It was recognized that goto was not necessary if one had proper control |>> structures in a language (if/else, while), and that code with no (or |>> minimal) gotos was easier to read and understand. | |Warner Losh <imp@bsdimp.com> 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.... | |Quite true. Modern Bourne shells let you supply a number to break and |continue to specify how many loops to break. Ada, or maybe it was one of |the Modula-X languages, let you put a label on a loop so that you could |say `continue outer' or `break outer' and not need the booleans. Bah, and perl could and obsoleted it, or at least jumping into blocks (not crossing initializers)! You now write code like my $ogoditisanewperl = 0; if(defined($nl = $self->begin_line)){ $self->begin_line(undef); $self->seen_endl(1); $ogoditisanewperl = 1 #goto jumpin; } while($ogoditisanewperl || ($nl = readline $self->infh)){ if(!$ogoditisanewperl){ ++${$self->__lineno}; $self->seen_endl($nl =~ s/(.*?)\s+$/$1/) } $ogoditisanewperl = 0; #jumpin: or even have to work with closures or whatever, or the worst, code duplication. |This is something that newer languages (C#, Java, Go, ...) could have \ |picked |up but didn't, which I think is too bad. Never without my goto:, and if it is only to break to error handling and/or staged destruction of local variables after initialization failures. Traumatic school impression, finding yourself locked in some PASCAL if condition, and no way to go to. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
On Dec 1, 2020, at 12:20 PM, Steffen Nurpmeso <steffen@sdaoden.eu> wrote:
>
> Never without my goto:, and if it is only to break to error
> handling and/or staged destruction of local variables after
> initialization failures. Traumatic school impression, finding
> yourself locked in some PASCAL if condition, and no way to go to.
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.
[-- Attachment #1: Type: text/plain, Size: 1705 bytes --] On Tue, Dec 1, 2020 at 3:14 PM Dave Horsfall <dave@horsfall.org> wrote: > And then there was the story of Professor Goto (a Japanese citizen and > computer bod) who complained that everyone was trying to eliminate him :-) > 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 <bakul@iitbombay.org> wrote: > But I have mixed feelings about goto vs continue/break. A nested > loop with multiple continue/break can be as obscure. 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@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_ [-- Attachment #2: Type: text/html, Size: 3317 bytes --]
[-- Attachment #1: Type: text/plain, Size: 3344 bytes --] On Tue, Dec 1, 2020 at 3:40 PM Bakul Shah <bakul@iitbombay.org> wrote: > On Dec 1, 2020, at 12:20 PM, Steffen Nurpmeso <steffen@sdaoden.eu> wrote: > > Never without my goto:, and if it is only to break to error > > handling and/or staged destruction of local variables after > > initialization failures. Traumatic school impression, finding > > yourself locked in some PASCAL if condition, and no way to go to. > > Pascal had goto. Pascal also had to go. (Thanks...I'm here all week.) 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. > C++ has had something analogous for some time: destructors that run when an object goes out of scope. Scope guards to do things like close files and auto-release locks on exiting a critical section are pretty common in that world, and in general, preferable to many of the alternatives (either deeply nested conditionals or banks of labels and `goto fail1;` `goto fail2;` etc, that successively release resources on return; the latter is basically hand-rolling what the language does automatically for you, and has been the cause of at least security-related bug: apple's "goto fail" bug in their SSL implementation). There's still no easy way to break out of nested loops, though. But I have mixed feelings about goto vs continue/break. A nested > loop with multiple continue/break can be as obscure. > I submit that it's in how you write it: if the set of conditions on which one would break/continue are explicit and early in the loop body, it can be a very expressive way to write something. But like any tool, it can be abused. Along those lines, it's always been interesting to me the way that Dijkstra's statement about goto must have influenced language design. The original "GOTO Statement Considered Harmful" note was quite damning, but I wonder if it meant to be: it strikes me that the really dangerous thing about "goto" isn't its mere existence or even its use, but rather, it's unconstrained use when better alternatives exist in the language. As one can observe in well-written C code, judicious use of `goto` can be quite elegant in comparison to the alternative. I've often wondered whether language designers, mindful of the pitfalls of `goto`, eventually took the most useful patterns of its usage and extracted them to stand on their own. Early returns from functions are an obvious example, but so are `break` and `continue` and one might argue exceptions fall into the same category. It strikes me that as we gain ever greater experience with languages, we find more and more examples of things one routinely does using a blunt instrument like goto, and we refine those to first-class features of the language. I think it's also illustrative of how social pressure can influence one to avoid "dangerous" patterns in favor of these language features. C isn't inherently more dangerous because it has a goto statement and labels; most of the time, one doesn't bother to use goto because alternatives exist that are more natural and fill the same role (continue, break, return, etc). - Dan C. [-- Attachment #2: Type: text/html, Size: 4361 bytes --]
[-- Attachment #1: Type: text/plain, Size: 886 bytes --] On Tue, Dec 1, 2020 at 3:40 PM Bakul Shah <bakul@iitbombay.org> wrote: Along those lines, it's always been interesting to me the way that > Dijkstra's statement about goto must have influenced language design. The > original "GOTO Statement Considered Harmful" note was quite damning, but I > wonder if it meant to be: it strikes me that the really dangerous thing > about "goto" isn't its mere existence or even its use, but rather, it's > unconstrained use when better alternatives exist in the language. As one > can observe in well-written C code, judicious use of `goto` can be quite > elegant in comparison to the alternative. > 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. [-- Attachment #2: Type: text/html, Size: 1942 bytes --]
If I knew that I forgot it (obviously). Thanks for letting me know.
Yet another reason to move to Go.
Has it been there since Day 1? Just wondering.
Thanks,
Arnold
Rob Pike <robpike@gmail.com> wrote:
> Go lets you say "Loop: for ..." and then "break Loop".
>
> -rob
[-- Attachment #1: Type: text/plain, Size: 372 bytes --] Yes. -rob On Wed, Dec 2, 2020 at 6:08 PM <arnold@skeeve.com> wrote: > If I knew that I forgot it (obviously). Thanks for letting me know. > Yet another reason to move to Go. > > Has it been there since Day 1? Just wondering. > > Thanks, > > Arnold > > Rob Pike <robpike@gmail.com> wrote: > > > Go lets you say "Loop: for ..." and then "break Loop". > > > > -rob > > [-- Attachment #2: Type: text/html, Size: 828 bytes --]
When I wrote yacc, my first thought was to use goto's when implementing
the finite state machine that is the heart of the parser. That's how
FSM's work! I got the code written, but the C compiler complained and
wouldn't compile. It turned out that, while goto was implemented in C,
you could only have 10 of them! So I had to use a switch statement.
I also recently came upon one of my first C programs -- I wrote a "go
fish" game for my son as a practice in using the language. Reading the
code was most instructive:
1. I had used FOUR gotos! I can't remember the last time I wrote a
goto...
2. The program had a bug -- char being used as an int. Gave an
advantage to the player.
3. The game was surprisingly hard to beat. I had to add a "dumb me
down" flag because my kids never won.
I think the game was distributed in some of the early releases. At one
point, at a conference, the speaker accused the game of cheating! The
game was just very good at remembering that if the player had asked it
for a 6, and then it drew a 6 later, it would ask the player for 6
again.
On 2020-12-01 08:39, arnold@skeeve.com wrote:
>> On Tue, Dec 1, 2020 at 8:39 AM <arnold@skeeve.com> wrote:
>> > It was recognized that goto was not necessary if one had proper control
>> > structures in a language (if/else, while), and that code with no (or
>> > minimal) gotos was easier to read and understand.
[-- Attachment #1: Type: text/plain, Size: 3430 bytes --] At Mon, 30 Nov 2020 11:54:37 -0500, Clem Cole <clemc@ccc.com> wrote: Subject: Re: [TUHS] The UNIX Command Language (1976) > > yes ... but ... even UNIX binary folks had troff licenses and many/most at > ditroff licenses. I would like to try once again to dispell the apparent myth that troff was readily available to Unix users in wider circles. True, old troff might have been there in the distribution, but not necessarily as many vendors didn't include it even though they had the license since they knew most users didn't care about it, and of course the users didn't care about troff because _nobody_ had a C/A/T, (and hardly anyone cared to use nroff to format things for line printers). People would install Wordstar long before they even thought about using nroff. Ditroff (or sqtroff) was also incredibly rare to non-existent for 99% of the Unix sites I worked at and visited; even some time after it became available. Even sites running native AT&T Unix, e.g. on 3B2s, and thus could easily obtain it, often didn't want the added expense of installing it. So, old troff was basically a total useless waste of disk space until psroff came along. Psroff made troff useful, but IF And Only IF you had a C compiler _and_ the skill to install it. That combination was still incredibly rare. A C compiler was often the biggest impediment to many sites I worked at -- they didn't have programmers and they didn't want to shell out even cash more for any programming tools (even though they had often hired me as a consulting programmer to "fix their Unix system"!). Then, as you said, Groff arrived, though still that required a C compiler and (effectively for some time) a PostScript printer (while psroff would drive the far more common laserjet and similar without gyrations through DVI!). In circles I travelled through if one wanted true computer typesetting support it was _far_ easier and better (even after Groff came along) to install TeX, even if it meant hiring a consultant to do it, since that meant having far wider printer support (though realistically PostScript printers were the only viable solution at some point, e.g. especially after laser printers became available, i.e. outside Xerox and IBM shops). > I think the academics went LaTex and that had more to do with it. LaTex > was closer to Scribe for the PDP-10s and Vaxen, which had a short head lead > on all them until it went walled garden when CMU sold the rights (and even > its author - Brian Ried) could not use it at a Stanford. I worked with a group of guys who were extreme fans of the PlainTeX macros (and who absolutely hated LaTeX). They came from academic circles and commercial research groups. But I agree it was those other factors that have lead to an ongoing prevalence for TeX, and in particular its LaTeX macros; over and above troff and anything else like either in the computer typesetting world. I was never a fan of anything TeX (nor of anything SGML-like). I was quite a fan of, and an extreme expert in using, troff and tbl. However once I discovered Lout I dropped troff like a hot potato. I continue to use Lout exclusively to this day for "fine" typesetting work (anything that needs/prefers physical printing or a PDF). -- Greg A. Woods <gwoods@acm.org> Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca> Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca> [-- Attachment #2: OpenPGP Digital Signature --] [-- Type: application/pgp-signature, Size: 195 bytes --]
On Wed, Feb 10, 2021 at 12:48:49PM -0800, Greg A. Woods wrote:
> At Mon, 30 Nov 2020 11:54:37 -0500, Clem Cole <clemc@ccc.com> wrote:
> Subject: Re: [TUHS] The UNIX Command Language (1976)
> >
> > yes ... but ... even UNIX binary folks had troff licenses and many/most at
> > ditroff licenses.
>
> I would like to try once again to dispell the apparent myth that troff
> was readily available to Unix users in wider circles.
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.
[-- Attachment #1: Type: text/plain, Size: 6625 bytes --] ᐧ On Wed, Feb 10, 2021 at 3:49 PM Greg A. Woods <woods@robohack.ca> wrote: > At Mon, 30 Nov 2020 11:54:37 -0500, Clem Cole <clemc@ccc.com> wrote: > Subject: Re: [TUHS] The UNIX Command Language (1976) > > > > yes ... but ... even UNIX binary folks had troff licenses and many/most > at > > ditroff licenses. > > I would like to try once again to dispell the apparent myth that troff > was readily available to Unix users in wider circles. > Hard to call it a myth - it was quite available. In fact, I never used a single mainstream UNIX system from DEC, IBM, HP later Sun, Masscomp, Apollo that did not have it, and many if not all small systems did also. > > True, old troff might have been there in the distribution, but not > necessarily as many vendors didn't include it even though they had the > license since they knew most users didn't care about it, and of course > the users didn't care about troff because _nobody_ had a C/A/T, Yes, but after Tom Ferrin created vcat(1) in the late 1970s ('77 I think, but I've forgotten). Many people did have access to a plotter which cost about $1k in the late 1970s, or even later a 'wet' laser printer like the Imagen which cost about $5K a few years later. (and hardly anyone cared to use nroff to format things for line printers). > No offense, but that's just not true. Line printers and nroff were used a great deal to prep things, and often UNIX folks had access to a daisy shell printer for higher quality nroff output, much less using the line printer. > People would install Wordstar long before they even thought about using > nroff. > I did not know anyone that did that. But I'll take your word for it. Wordstar as I recall ran on 8-bit PCs. The only two people I knew that had larger CP/M systems back in the day that might have supported that were Phil Karn (*a.k.a.* KA9Q of TCP/IP for CP/M fame) and Guy Soytomayer - both were sometimes lab partners. But all three of us had access to the XGP in CMU CS dept, using Scribe on the PDP-10s, but we all used nroff most of the time because we had more cycles available on the UNIX boxes and the 10s required going to the terminal room. FWIW: my non-techie CMU course professors used to let you turning papers printed off the line printer and people used anything they had - which was Scribe on the 20s and nroff on the Unix, boxes and I've forgotten the name of the program that ran on the TSS, which the business majors like my roommate tended to use. > > Ditroff (or sqtroff) was also incredibly rare to non-existent for 99% of > the Unix sites I worked at and visited; even some time after it became > available. Even sites running native AT&T Unix, e.g. on 3B2s, and thus > could easily obtain it, often didn't want the added expense of > installing it. > The only time I had a deal with pure AT&T systems was occasionally at the AT&T, but even there most of them that I worked, had BSD or Research, based systems. The only 3B2 I ever saw was the one we were forced to buy by AT&T to get a System V source license at Stellar as the reference system, when PDP-11 and Vaxen stopped being the default. We did get ditroff from the toolchest for it, since we were including it in the base Stellar system. The Apple Laserwriter was fully in the wild with transcript by then, so vcat was not needed. > > So, old troff was basically a total useless waste of disk space until > psroff came along. > Sounds like you never had access to a plotter. > > Psroff made troff useful, psroff was very, very late in the UNIX development. vcat was nearly 10 years earlier, and psroff only showed up after the Apple Laserwriter which is what - early 1985 I think. But Versatec and the like plotter were all over the place, much less daisy wheel printers. True, the Hersey fonts were not nearly as nice as PostScript and the resolution was only 200 dpi (and it was a wet process) but most UNIX sites, particularly if you had invested in Vaxen had them. > but IF And Only IF you had a C compiler _and_ > the skill to install it. That combination was still incredibly rare. Excuse me... most end-users sites had them. Sun was the only one of the majors that did not ship a C compiler with the system by default. And as Larry has pointed out, even that was fixed by rms fairly soon afterward. But all of the suppliers of the majors UNIX implementations knew that you got the C compiler with UNIX. Jacks to open -- just include it. It sounds like your early UNIX experiences were in a limited version, which is a little sad and I can see that might color your thinking. > A C compiler was often the biggest impediment to many sites I worked at > -- > they didn't have programmers and they didn't want to shell out even cash > more for any programming tools (even though they had often hired me as a > consulting programmer to "fix their Unix system"!). > Yeech... sorry to hear that. > In circles I travelled through if one wanted true computer typesetting > support it was _far_ easier and better (even after Groff came along) Hmmm ... you were complaining you need a C compiler for ditroff, yet groff needs C++ IIRC.? > to install TeX, even if it meant hiring a consultant to do it, since that > Which means you need a Pascal compiler BTW .... and Tex was written using the PDP-10 Pascal extensions, so you had to have a Pascal that understood that. Which was often not easy, particularly on UNIX boxes. The UCB Pascal != PDP-10 Pascal. > meant having far wider printer support (though realistically PostScript > printers were the only viable solution at some point, e.g. especially > after laser printers became available, i.e. outside Xerox and IBM shops). > My guess this observation is because HP was late to the Postscript world and there while the eventual hpcat(1) was done for the vaxen and made it the USENET, it was fairly late in time, and I'm not sure if anyone at HP or anyone else ever wrote a ditroff backend for HP's PCL. The key is that Apple Laserwriters were pretty cheap and since they already did PS, most sites I knew just bought PS based ones and did not go HP until later when PS was built-in. > I was quite a fan of, and an extreme expert in using, troff and tbl. > Good to hear. > However once I discovered Lout I dropped troff like a hot potato. > Never used it, but I'll take your word for it. I believe it is very Scribe like and looking at it you can see in the influence. ᐧ [-- Attachment #2: Type: text/html, Size: 12186 bytes --]
Greg A. Woods writes:
>
> Ditroff (or sqtroff) was also incredibly rare to non-existent for 99% of
> the Unix sites I worked at and visited; even some time after it became
> available. Even sites running native AT&T Unix, e.g. on 3B2s, and thus
> could easily obtain it, often didn't want the added expense of
> installing it.
Maybe for you; I had it everywhere that I worked.
I wonder if this was a university BSD/Bell licence vs "everyone else"
thing. I know we had ubiquitous use of nroff, troff and ditroff, in
succession at Leeds and York across 82-84 and onward. That was with a
benson-varian wet process printer from roll paper, cut marks thrown in
free.
because I'd used Tops-10 Runoff at uni, nroff made sense. The guys who
walked in other doors wound up tooled in TeX which I didn't {relax}
get.
On Thu, Feb 11, 2021 at 8:37 AM Jon Steinhart <jon@fourwinds.com> wrote:
>
> Greg A. Woods writes:
> >
> > Ditroff (or sqtroff) was also incredibly rare to non-existent for 99% of
> > the Unix sites I worked at and visited; even some time after it became
> > available. Even sites running native AT&T Unix, e.g. on 3B2s, and thus
> > could easily obtain it, often didn't want the added expense of
> > installing it.
>
> 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.
On Thu, Feb 11, 2021 at 12:27:17AM +0000, Ron Natalie wrote:
> 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.
That's dedication, what else did George do?
[-- Attachment #1: Type: text/plain, Size: 2190 bytes --] 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@ronnatalie.com> wrote: > 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. > > > > -- Sent from a handheld expect more typos than usual [-- Attachment #2: Type: text/html, Size: 2658 bytes --]
[-- Attachment #1: Type: text/plain, Size: 169 bytes --] There used to be a great memo all about stealing fonts. Joel might remember it, as it circulated among CMU MIT Stanford etc. in the days of the XGP and Dover printers. [-- Attachment #2: Type: text/html, Size: 218 bytes --]
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@gmail.com> wrote:
>
> There used to be a great memo all about stealing fonts. Joel might remember it, as it circulated among CMU MIT Stanford etc. in the days of the XGP and Dover printers.
>
[-- Attachment #1: Type: text/plain, Size: 3318 bytes --] 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: > 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@ronnatalie.com > <mailto:ron@ronnatalie.com>> wrote: > > 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. > > > > -- > Sent from a handheld expect more typos than usual [-- Attachment #2: Type: text/html, Size: 4962 bytes --]
[-- Attachment #1: Type: text/plain, Size: 315 bytes --] On Wed, Feb 10, 2021, 9:04 PM George Michaelson <ggm@algebras.org> wrote: > As long as you do it in the USA, it isn't stealing. > Not sure of that, but there are other techniques to protect it, like patent, trademark, and trade secret. Just like unpublished proprietary source code of AT&T, to coin a phrase. > [-- Attachment #2: Type: text/html, Size: 811 bytes --]
The Hershey fonts were what we had, they kinda sucked but you worked with them. I think is a passage, you know those fonts, you were there, it was not great. People who haven't been there have no idea how lucky they are. On Wed, Feb 10, 2021 at 06:30:31PM -0800, Mary Ann Horton wrote: > 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: > >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@ronnatalie.com > ><mailto:ron@ronnatalie.com>> wrote: > > > > 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. > > > > > > > >-- > >Sent from a handheld expect more typos than usual -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
On Wed, 10 Feb 2021, Richard Salz wrote:
> On Wed, Feb 10, 2021, 9:04 PM George Michaelson <ggm@algebras.org> wrote:
>
> Not sure of that, but there are other techniques to protect it, like
> patent, trademark, and trade secret. Just like unpublished proprietary
> source code of AT&T, to coin a phrase.
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.
On 2021-02-10 10:02 p.m., Steve Nickolas wrote: > On Wed, 10 Feb 2021, Richard Salz wrote: > >> On Wed, Feb 10, 2021, 9:04 PM George Michaelson <ggm@algebras.org> wrote: >> >> Not sure of that, but there are other techniques to protect it, like >> patent, trademark, and trade secret. Just like unpublished proprietary >> source code of AT&T, to coin a phrase. > > 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. Added irony and lesson: Bitstream's digitisations and originals were markedly better and more complete than Adobe's, who were able to use the licensed names. --T > > -uso.
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
[-- Attachment #1: Type: text/plain, Size: 1021 bytes --] https://www.cs.princeton.edu/~bwk/202/index.html On Thu, Feb 11, 2021 at 6:05 PM Andrew Hume <andrew@humeweb.com> 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 [-- Attachment #2: Type: text/html, Size: 1371 bytes --]
Recent discussions on this list are about the problem getting fonts for typesetting before there was an industry to provide them. Noted font designer Chuck Bigelow has written about the subject here: Notes on typeface protection TUGboat 7(3) 146--151 October 1986 https://tug.org/TUGboat/tb07-3/tb16bigelow.pdf Other TUGboat papers by him and his design partner, Kris Holmes, might be of reader interest: Lucida and {\TeX}: lessons of logic and history https://tug.org/TUGboat/tb15-3/tb44bigelow.pdf About the DK versions of Lucida https://tug.org/TUGboat/tb36-3/tb114bigelow.pdf A short history of the Lucida math fonts https://tug.org/TUGboat/tb37-2/tb116bigelow-lucidamath.pdf Science and history behind the design of Lucida https://tug.org/TUGboat/tb39-3/tb123bigelow-lucida.pdf ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu - - 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------
Andrew Hume <andrew@humeweb.com> wrote:
> 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"...
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.
[-- Attachment #1: Type: text/plain, Size: 1676 bytes --] 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 [-- Attachment #2: Type: text/html, Size: 2932 bytes --]
On 2/11/2021 5:06 AM, John Gilmore wrote: > 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. > > 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. I always thought the Prof. Michael Harrison and his group in the CS Dept. at UC Berkeley were the first to do this. I found a reference to this in https://books.google.com/books?id=IToEAAAAMBAJ&pg=PT7&lpg=PT7&dq=michael++harrison+berkeley+postscript+fonts#v=onepage&q=michael%20%20harrison%20berkeley%20postscript%20fonts&f=false Plus, Mike told me personally that this is what happened. Jon
[-- Attachment #1: Type: text/plain, Size: 676 bytes --] On Thu, Feb 11, 2021 at 12:34 PM Jon Forrest <nobozo@gmail.com> wrote: > I always thought the Prof. Michael Harrison and his group in the > CS Dept. at UC Berkeley were the first to do this. I found a reference > to this in > > > https://books.google.com/books?id=IToEAAAAMBAJ&pg=PT7&lpg=PT7&dq=michael++harrison+berkeley+postscript+fonts#v=onepage&q=michael%20%20harrison%20berkeley%20postscript%20fonts&f=false "It steam-engines when it comes steam-engine time." John Cowan http://vrici.lojban.org/~cowan cowan@ccil.org How they ever reached any conclusion at all is starkly unknowable to the human mind. --"Backstage Lensman", Randall Garrett [-- Attachment #2: Type: text/html, Size: 2019 bytes --]
I've heard stories about a very high speed dot matrix printer used (IIRC) at Lawrence Berkeley Laboratory. Apparently, it used a bank of Hydrogen Thyratrons to multiplex high voltage onto a set of metal needles. The resulting sparks burned tiny black holes into the paper at 24K LPM. It occurs to me that it could probably have been used for graphics, typesetting, and such, but I dunno. Might anyone here be able to talk about (or provide links about) this beast? -r
[-- Attachment #1: Type: text/plain, Size: 3517 bytes --] On Thu, Feb 11, 2021 at 11:56 AM Ron Natalie <ron@ronnatalie.com> wrote: > 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. > Or to make use of bitmap fonts, which are exact representations of the typeface, at least in the U.S. (In Europe there are design patents that make typefaces protectable.) See section 1.12 of < http://www.faqs.org/faqs/fonts-faq/part2/> for the relevant quotations from the Code of Federal Regulations. Some time ago, I was hacking on the program FIGlet, which is a bells-and-whistles banner program: you write FIGfonts as plain text files with N lines per big character, where N is the font height measured in small characters. It is capable of kerning big characters nicely by using a chosen small character to represent a "squishable space". My main two improvements were to extend the font format to represent up to 2^31 big characters and to accept mapping tables to convert input from a specific encoding to font indices. (I ended up writing a comprehensive decoder for arbitrary ISO 2022 text, possibly the only one that has ever existed.) In addition, I wrote a program to convert X BDS (bitmap) fonts to FIGfonts, and packaged the standard BDS fonts with the standard FIGlet library. That served me well later when I was working for the Associated Press. My boss told me that the New York Daily News, which was downstairs in the same building, was tired of paying Reuters for a program running on a PC that fetched the current headlines from Reuters and displayed them on a huge news ticker mounted on several sides of the newsroom, which was the size of a NY city block. Because the AP is a not-for-profit collective, once you buy in, all the services are free. The Reuters program was a Windows binary, and the manual they had for the ticker turned out to be for a different model altogether. I called the manufacturer and got the correct manual (it took several days). I wrote a program in Perl that would fetch an AP headline feed (in RSS) which I was responsible for, load up the X FIGfont specified as a command-line argument, and send the text to the ticker, a matter of writing a single column of bits and then the next and then the next, as the hardware took care of the actual horizontal scrolling for me. Once I had it running, I walked around to various people in the newsroom who didn't look too busy, and asked them what they thought? The general response was a weak "LGTM", until I got to one guy who said, "No, it doesn't look quite right." "If you'll follow me," I said, "I'll see what I can do." He and the guy in the next cube followed me to the desk where the PC sat. I killed the program and started it up with the name of a different font. "Mmm, not quite." We went through a number of fonts until I got "Yes! Now _that_ looks like a real newsroom font!" He asked the other guy, "Do you agree?" "Yes, that's great!" So they were happy and I was happy and when I got back to AP my boss was happy. Only later did I find out that my two guys were the city editor and the managing editor of the Daily News! 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. > See "The Telnet Song" at <https://www.glaver.org/ftp/humor/telnet-song.txt>. [-- Attachment #2: Type: text/html, Size: 6684 bytes --]
[-- Attachment #1: Type: text/plain, Size: 6901 bytes --] At Wed, 10 Feb 2021 17:05:57 -0500, Clem Cole <clemc@ccc.com> wrote: Subject: Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976)) > > On Wed, Feb 10, 2021 at 3:49 PM Greg A. Woods <woods@robohack.ca> wrote: > > > I would like to try once again to dispell the apparent myth that troff > > was readily available to Unix users in wider circles. > > > Hard to call it a myth - it was quite available. In fact, I never used a > single mainstream UNIX system from DEC, IBM, HP later Sun, Masscomp, Apollo > that did not have it, and many if not all small systems did also. 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. > Yes, but after Tom Ferrin created vcat(1) in the late 1970s ('77 I think, > but I've forgotten). Many people did have access to a plotter which cost > about $1k in the late 1970s, or even later a 'wet' laser printer like the > Imagen which cost about $5K a few years later. 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. > No offense, but that's just not true. Line printers and nroff were used a > great deal to prep things, and often UNIX folks had access to a daisy shell > printer for higher quality nroff output, much less using the line printer. 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.... > > People would install Wordstar long before they even thought about using > > nroff. > > > I did not know anyone that did that. But I'll take your word for it. > Wordstar as I recall ran on 8-bit PCs. 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. > FWIW: my non-techie CMU course > professors used to let you turning papers printed off the line printer and > people used anything they had - which was Scribe on the 20s and nroff on > the Unix, boxes and I've forgotten the name of the program that ran on the > TSS, which the business majors like my roommate tended to use. 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. :-) > > but IF And Only IF you had a C compiler _and_ > > the skill to install it. That combination was still incredibly rare. > > Excuse me... most end-users sites had them. > > It sounds like your early UNIX experiences were in a limited version, which > is a little sad and I can see that might color your thinking. 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. > Hmmm ... you were complaining you need a C compiler for ditroff, yet groff > needs C++ IIRC.? Plain C for "psroff", but yes, indeed, C++ for groff. > My guess this observation is because HP was late to the Postscript world > and there while the eventual hpcat(1) was done for the vaxen and made it > the USENET, it was fairly late in time, and 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). > I'm not sure if anyone at HP or > anyone else ever wrote a ditroff backend for HP's PCL. 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 > The key is that Apple Laserwriters were pretty cheap and since they already > did PS, most sites I knew just bought PS based ones and did not go HP until > later when PS was built-in. 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@acm.org> Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca> Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca> [-- Attachment #2: OpenPGP Digital Signature --] [-- Type: application/pgp-signature, Size: 195 bytes --]
the transition from wet to dry was amazing. we had the wet, and it
worked but was fussy. I think it was some odd DPI like 120. Lowish
res. Jaggies on the fonts. I printed a poem Dave Barron wrote about
the birth of the ICL 2900 hundred in old english font, you can see the
jaggies on it. When it first comes out, it is shiny like its just been
given birth to (sorry) and some horrendous solvent I don't want to
think about evaporated, and it was done. Sort-of shiny surface. Not
very nice.
The first decent dry laser we got was a canon unit, which IIRC was in
that olivetti "we know how do do design" space-age orange shade. It
was a giant brick on its end, about the height of a bar-fridge, and it
was 200dpi I think, and we loved it. Insanely good to get things that
clean, and not have to slice a roll of paper. I mean, for the entire
time we've been talking about Xerox machines were coming down in size
although a campus printer at the bindery for PhDs is an assembly line
of giant car sized units, but even the small ones the engineers have a
black diver case of wierd tools, gizmos to reach behind the
thingamajig and tickle the whatsit with a hairy brush.. they are
seriously complex machines (or were). Getting one of these
russian-tanks in a jet-age orange italian designer bar-fridge was ..
cool.
But then.. we realised all the s/w tools we were using were designed
for US letter. Inches. Not A4 friendly. I mean, the BSD licence I've
referred to several times, It was printed on legal, it even had the
honest-to-god crimped red seal of the regents of the university of
california on it, we didn't have envelopes which fitted this stuff. We
didn't have ring binders with holes in the right places for the
printed manuals, and when we printed our own, if we didn't check and
check and check, the US-Legal / A4 thing went bananas. People hoarded
magic init sequences to make things have margins and page sizes which
worked for them. I still remember trying to co-erce 2up printing to
work nicely.
We were so desperate for decent output there was a market for a sort
of 'player piano' box which sat on an IBM golfball printer, and
hammered the keys for you. Daisy wheel was good, but you can't beat an
IBM selectric if you want to cut a roneostat for some agitprop (they
were the invention of the devil too. the ink goes everywhere)
Nowadays, a good photocopier from fuji has a 48MP camera with a giant
lens, there is none of this scanning nonsense, its one photo and done.
The smarts are in MIPS chips and do things like hide 'you leaked it'
codes in the printed output. I used one to copy my passport for a
re-issuance recently, I swear you could pass money from them (I am
told they have image recognition for money and won't print it. Damn
skynet. they're taking over already)
On Fri, Feb 12, 2021 at 7:59 AM Greg A. Woods <woods@robohack.ca> wrote:
>
> At Wed, 10 Feb 2021 17:05:57 -0500, Clem Cole <clemc@ccc.com> wrote:
> Subject: Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976))
> >
> > On Wed, Feb 10, 2021 at 3:49 PM Greg A. Woods <woods@robohack.ca> wrote:
> >
> > > I would like to try once again to dispell the apparent myth that troff
> > > was readily available to Unix users in wider circles.
> > >
> > Hard to call it a myth - it was quite available. In fact, I never used a
> > single mainstream UNIX system from DEC, IBM, HP later Sun, Masscomp, Apollo
> > that did not have it, and many if not all small systems did also.
>
> 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.
>
> > Yes, but after Tom Ferrin created vcat(1) in the late 1970s ('77 I think,
> > but I've forgotten). Many people did have access to a plotter which cost
> > about $1k in the late 1970s, or even later a 'wet' laser printer like the
> > Imagen which cost about $5K a few years later.
>
> 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.
>
> > No offense, but that's just not true. Line printers and nroff were used a
> > great deal to prep things, and often UNIX folks had access to a daisy shell
> > printer for higher quality nroff output, much less using the line printer.
>
> 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....
>
> > > People would install Wordstar long before they even thought about using
> > > nroff.
> > >
> > I did not know anyone that did that. But I'll take your word for it.
> > Wordstar as I recall ran on 8-bit PCs.
>
> 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.
>
> > FWIW: my non-techie CMU course
> > professors used to let you turning papers printed off the line printer and
> > people used anything they had - which was Scribe on the 20s and nroff on
> > the Unix, boxes and I've forgotten the name of the program that ran on the
> > TSS, which the business majors like my roommate tended to use.
>
> 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. :-)
>
>
> > > but IF And Only IF you had a C compiler _and_
> > > the skill to install it. That combination was still incredibly rare.
> >
> > Excuse me... most end-users sites had them.
> >
> > It sounds like your early UNIX experiences were in a limited version, which
> > is a little sad and I can see that might color your thinking.
>
> 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.
>
> > Hmmm ... you were complaining you need a C compiler for ditroff, yet groff
> > needs C++ IIRC.?
>
> Plain C for "psroff", but yes, indeed, C++ for groff.
>
> > My guess this observation is because HP was late to the Postscript world
> > and there while the eventual hpcat(1) was done for the vaxen and made it
> > the USENET, it was fairly late in time, and
>
> 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).
>
> > I'm not sure if anyone at HP or
> > anyone else ever wrote a ditroff backend for HP's PCL.
>
> 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
>
> > The key is that Apple Laserwriters were pretty cheap and since they already
> > did PS, most sites I knew just bought PS based ones and did not go HP until
> > later when PS was built-in.
>
> 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@acm.org>
>
> Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca>
> Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca>
On Thu, 11 Feb 2021, Greg A. Woods wrote:
> I don't know if I've ever seen a Versatec plotter, though perhaps at a
> trade show.
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
I hated those things. They were what we used for regular listings at
BRL and the chemicals made my skin break out. The chemicals also
reacted with the ink in the standard government issue felt tip pens
(which ironically were made by blind people) and caused your notes to
fade quickly (and the pens to stop working).
------ Original Message ------
From: "Dave Horsfall" <dave@horsfall.org>
To: "The Eunuchs Hysterical Society" <tuhs@tuhs.org>
Sent: 2/12/2021 5:13:22 PM
Subject: Re: [TUHS] troff was not so widely usable (was: The UNIX
Command Language (1976))
>On Thu, 11 Feb 2021, Greg A. Woods wrote:
>
>>I don't know if I've ever seen a Versatec plotter, though perhaps at a trade show.
>
>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