* Re: [TUHS] troff was not so widely usable @ 2021-02-11 12:52 Nelson H. F. Beebe 0 siblings, 0 replies; 9+ messages in thread From: Nelson H. F. Beebe @ 2021-02-11 12:52 UTC (permalink / raw) To: tuhs 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/ - ------------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 9+ messages in thread
* [TUHS] The UNIX Command Language (1976) @ 2020-11-30 3:10 Joachim via TUHS 2020-11-30 15:52 ` Clem Cole 0 siblings, 1 reply; 9+ messages in thread From: Joachim via TUHS @ 2020-11-30 3:10 UTC (permalink / raw) To: TUHS main list [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [TUHS] The UNIX Command Language (1976) 2020-11-30 3:10 [TUHS] The UNIX Command Language (1976) Joachim via TUHS @ 2020-11-30 15:52 ` Clem Cole 2020-11-30 16:37 ` Larry McVoy 0 siblings, 1 reply; 9+ messages in thread From: Clem Cole @ 2020-11-30 15:52 UTC (permalink / raw) To: Joachim; +Cc: TUHS main list [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [TUHS] The UNIX Command Language (1976) 2020-11-30 15:52 ` Clem Cole @ 2020-11-30 16:37 ` Larry McVoy 2020-11-30 16:54 ` Clem Cole 0 siblings, 1 reply; 9+ messages in thread From: Larry McVoy @ 2020-11-30 16:37 UTC (permalink / raw) To: Clem Cole; +Cc: TUHS main list 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [TUHS] The UNIX Command Language (1976) 2020-11-30 16:37 ` Larry McVoy @ 2020-11-30 16:54 ` Clem Cole 2021-02-10 20:48 ` [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976)) Greg A. Woods 0 siblings, 1 reply; 9+ messages in thread From: Clem Cole @ 2020-11-30 16:54 UTC (permalink / raw) To: Larry McVoy; +Cc: TUHS main list [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976)) 2020-11-30 16:54 ` Clem Cole @ 2021-02-10 20:48 ` Greg A. Woods 2021-02-10 22:36 ` Jon Steinhart 0 siblings, 1 reply; 9+ messages in thread From: Greg A. Woods @ 2021-02-10 20:48 UTC (permalink / raw) To: The Unix Heritage Society mailing list [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976)) 2021-02-10 20:48 ` [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976)) Greg A. Woods @ 2021-02-10 22:36 ` Jon Steinhart 2021-02-10 23:05 ` George Michaelson 0 siblings, 1 reply; 9+ messages in thread From: Jon Steinhart @ 2021-02-10 22:36 UTC (permalink / raw) To: The Unix Heritage Society mailing list 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976)) 2021-02-10 22:36 ` Jon Steinhart @ 2021-02-10 23:05 ` George Michaelson 2021-02-11 0:27 ` Ron Natalie 0 siblings, 1 reply; 9+ messages in thread From: George Michaelson @ 2021-02-10 23:05 UTC (permalink / raw) To: Jon Steinhart; +Cc: The Unix Heritage Society mailing list 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976)) 2021-02-10 23:05 ` George Michaelson @ 2021-02-11 0:27 ` Ron Natalie 2021-02-11 1:53 ` Clem Cole 0 siblings, 1 reply; 9+ messages in thread From: Ron Natalie @ 2021-02-11 0:27 UTC (permalink / raw) To: The Unix Heritage Society mailing list 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976)) 2021-02-11 0:27 ` Ron Natalie @ 2021-02-11 1:53 ` Clem Cole 2021-02-11 2:30 ` [TUHS] troff was not so widely usable Mary Ann Horton 0 siblings, 1 reply; 9+ messages in thread From: Clem Cole @ 2021-02-11 1:53 UTC (permalink / raw) To: Ron Natalie; +Cc: The Unix Heritage Society mailing list [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [TUHS] troff was not so widely usable 2021-02-11 1:53 ` Clem Cole @ 2021-02-11 2:30 ` Mary Ann Horton 2021-02-11 2:52 ` Larry McVoy 0 siblings, 1 reply; 9+ messages in thread From: Mary Ann Horton @ 2021-02-11 2:30 UTC (permalink / raw) To: tuhs [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [TUHS] troff was not so widely usable 2021-02-11 2:30 ` [TUHS] troff was not so widely usable Mary Ann Horton @ 2021-02-11 2:52 ` Larry McVoy 2021-02-11 6:42 ` Andrew Hume 0 siblings, 1 reply; 9+ messages in thread From: Larry McVoy @ 2021-02-11 2:52 UTC (permalink / raw) To: Mary Ann Horton; +Cc: tuhs 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [TUHS] troff was not so widely usable 2021-02-11 2:52 ` Larry McVoy @ 2021-02-11 6:42 ` Andrew Hume 2021-02-11 7:12 ` Rob Pike 0 siblings, 1 reply; 9+ messages in thread From: Andrew Hume @ 2021-02-11 6:42 UTC (permalink / raw) To: Larry McVoy; +Cc: TUHS main list 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [TUHS] troff was not so widely usable 2021-02-11 6:42 ` Andrew Hume @ 2021-02-11 7:12 ` Rob Pike 2021-02-11 13:06 ` John Gilmore 0 siblings, 1 reply; 9+ messages in thread From: Rob Pike @ 2021-02-11 7:12 UTC (permalink / raw) To: Andrew Hume; +Cc: TUHS main list [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [TUHS] troff was not so widely usable 2021-02-11 7:12 ` Rob Pike @ 2021-02-11 13:06 ` John Gilmore 2021-02-11 17:34 ` Jon Forrest 0 siblings, 1 reply; 9+ messages in thread From: John Gilmore @ 2021-02-11 13:06 UTC (permalink / raw) To: Andrew Hume, TUHS main list 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [TUHS] troff was not so widely usable 2021-02-11 13:06 ` John Gilmore @ 2021-02-11 17:34 ` Jon Forrest 2021-02-11 18:09 ` John Cowan 0 siblings, 1 reply; 9+ messages in thread From: Jon Forrest @ 2021-02-11 17:34 UTC (permalink / raw) To: tuhs 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [TUHS] troff was not so widely usable 2021-02-11 17:34 ` Jon Forrest @ 2021-02-11 18:09 ` John Cowan 2021-02-11 18:43 ` Rich Morin 0 siblings, 1 reply; 9+ messages in thread From: John Cowan @ 2021-02-11 18:09 UTC (permalink / raw) To: Jon Forrest; +Cc: TUHS main list [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [TUHS] troff was not so widely usable 2021-02-11 18:09 ` John Cowan @ 2021-02-11 18:43 ` Rich Morin 0 siblings, 0 replies; 9+ messages in thread From: Rich Morin @ 2021-02-11 18:43 UTC (permalink / raw) To: TUHS main list 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2021-02-11 18:44 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-02-11 12:52 [TUHS] troff was not so widely usable Nelson H. F. Beebe -- strict thread matches above, loose matches on Subject: below -- 2020-11-30 3:10 [TUHS] The UNIX Command Language (1976) Joachim via TUHS 2020-11-30 15:52 ` Clem Cole 2020-11-30 16:37 ` Larry McVoy 2020-11-30 16:54 ` Clem Cole 2021-02-10 20:48 ` [TUHS] troff was not so widely usable (was: The UNIX Command Language (1976)) Greg A. Woods 2021-02-10 22:36 ` Jon Steinhart 2021-02-10 23:05 ` George Michaelson 2021-02-11 0:27 ` Ron Natalie 2021-02-11 1:53 ` Clem Cole 2021-02-11 2:30 ` [TUHS] troff was not so widely usable Mary Ann Horton 2021-02-11 2:52 ` Larry McVoy 2021-02-11 6:42 ` Andrew Hume 2021-02-11 7:12 ` Rob Pike 2021-02-11 13:06 ` John Gilmore 2021-02-11 17:34 ` Jon Forrest 2021-02-11 18:09 ` John Cowan 2021-02-11 18:43 ` Rich Morin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).