Hi Lennart,
At 2024-01-18T15:45:55+0000, Lennart Jablonka wrote:
> Quoth John Gardner:
> > Thanks for reminding me, Branden. :) I've yet to get V7 Unix working with
> > the latest release of SimH, so that's kind of stalled my ability to develop
> > something in K&R-friendly C.
>
> I went ahead and write a little C/A/T-to-later-troff-output converter in
> v7-friendly and C89-conforming C:
>
> https://git.sr.ht/~humm/catdit
This is an exciting prospect but I can't actually see anything there.
I get an error.
"401 Unauthorized
You don't have the necessary permissions to access this page. Index"
> I’m not confident in having got the details of spacing right (Is that
> 55-unit offset when switching font sizes correct?)
I've never heard of this C/A/T feature/wart before. Huh.
> and the character codes emitted are still those of the C/A/T,
> resulting in the wrong glyphs being used.
The codes should probably be remapped by default, with a command-line
option to restore the original ones. I would of course recommend
writing out 'C' commands with groff special character names.
> I created the attached document like this:
>
> v7$ troff -t /usr/man/man0/title >title.cat
> host$ catdit <title.cat | dpost -F. -Tcat >title.ps
>
> (Where do the two blank pages at the end come from?)
Good question; we may need to rouse a C/A/T expert.
> PS: Branden, for rougher results, if you happen to have a Tektronix
> 4014 at hand (like the one emulated by XTerm), you can use that to
> look at v7 troff’s output. Tell your SIMH to pass control bytes
> through and run troff -t | tc.
I'd love to, just please make your repo available to the public. :)
Regards,
Branden
John Gardner wrote:
> I'm a professional graphic designer with access to commercial typeface
> authoring software. Send me the highest-quality and most comprehensive
> scans of a C/A/T-printed document, and I'll get to work.
Are you offering to donate your labor in terms of typeface design, or
will it be a type of deal where the community will need to collectively
pitch in money to cover the cost of you doing it professionally?
In either case, the "C/A/T-printed document" of most value to this
project would be the same one G. Branden Robinson is referring to:
> If you don't have my scan of CSTR #54 (1976), which helpfully dumps all
> of the glyphs in the faces used by the Bell Labs CSRC C/A/T-4, let me
> know and I'll send it along. I won't vouch for its high quality but it
> should be comprehensive with respect to coverage.
The paper in question is Nroff/Troff User's Manual by Joseph F. Ossanna,
dated 1976-10-11, which was indeed also CSTR #54. The document is 33
pages long in its original form, and page 31 out of the 33 is the most
interesting one for the purpose of font recreation: it is the page that
exhibits all 4 fonts of 102 characters each. Here are the few published
scans I am aware of:
1) Page 245 of:
http://bitsavers.org/pdf/att/unix/7th_Edition/UNIX_Programmers_Manual_Seven…
2) Page 235 of:
http://bitsavers.org/pdf/att/unix/7th_Edition/UNIX_Programmers_Manual_Seven…
3) Page 239 of:
http://bitsavers.org/pdf/att/unix/7th_Edition/VA-004A_UNIX_Programmers_Manu…
4) Page 499 of:
https://archive.org/details/uum-supplement-4.2bsd
Question to Branden: the scan you are referring to as "my scan", how
does it compare to the 4 I just linked above? If your scan has better
quality than all 4 versions I linked above, can you please make it
public?
M~
> All, I got this e-mail from Holger a while back. Somehow it went into
> a folder and has lurked unseen for way too long.
>
> Does anybody know any more about PCS Unix and, if so, where should
> I place the code that Holger has donated into the Unix Archive?
I don’t know much about PCS Unix, but I did come across many references to Newcastle Connection (and Unix United) when researching early networking and the various approaches to giving early Unix a networking API. I think there is no other set of surviving sources for this. Maybe Holger disagrees, but I would say that PCS Unix is best placed in the “Early networking” section.
By the way, for those interested, here is a start to read up on Unix United: https://en.wikipedia.org/wiki/Newcastle_Connection
To some extent, it is similar to the “RIDE” software developed at Bell Labs Naperville by Priscilla Lu and to S/F Unix developed by GWR Luderer at Murray Hill. As far as I know the sources for both of those have been lost to time, afaik.
Hi again John,
> I only meant "professional" insofar as aptitude with graphics is concerned.
> I won't accept money; I'm offering my labour out of love for typography,
> computer history and its preservation, and of course, the technology that
> got Unix the funding it needed to revolutionise computing. In any case,
> there's no actual "design" work involved: it's literally just tracing
> existing shapes to recreate an existing design. I do stuff like this
> <https://github.com/file-icons/icons#why-request-an-icon-cant-i-submit-a-pr>
> for *fun*, for crying out loud.
Sounds great! If you are indeed serious about trying to recreate the
ancient C/A/T character set in PostScript fonts (or some other font
format that can be converted into a form that can be downloaded into a
genuine PostScript printer), I'll try to find some time to produce the
following:
1) A set of C/A/T binary files corresponding to that CSTR #54 manual,
as well as BWK's troff tutorial which usually follows right after in
book compilations. This step is simply a matter of running the original
troff executable (with -t option) on the original source files for
these docs - but since I actually run an OS that still includes that
original version of troff and you said you don't, it would probably be
easier for me to produce and publish these files.
2) A converter tool from C/A/T binary codes to PostScript, using
whatever fonts you give it. I'll test it initially using the set of
fonts which I developed for my 4.3BSD-Quasijarus pstroff - all
characters will be there, all positioning will come from original
troff, but it won't look pretty because most PS native font characters
don't match those of C/A/T. Then as you progress with your font
drawing project, you should be able to substitute your fonts instead
of mine, and see how the output improves.
> Nice! The more material I have, the merrier. As for the scan that Branden
> and I were referring to, I've uploaded a copy to Dropbox
Using pdfimages utility with -list option, I compared the image format
and resolution in various scans I described in my previous mail, plus
this new one you just shared, and concluded that the best quality is
contained in these two:
http://bitsavers.org/pdf/att/unix/7th_Edition/UNIX_Programmers_Manual_Seven…http://bitsavers.org/pdf/att/unix/7th_Edition/VA-004A_UNIX_Programmers_Manu…
Here are extracted PNG images of just the relevant page from both PDFs:
https://www.freecalypso.org/members/falcon/troff/cstr54-fontpage-sri.pnghttps://www.freecalypso.org/members/falcon/troff/cstr54-fontpage-ucb.png
Each PNG is a lossless extract from the corresponding PDF, made with
pdfimages utility. Each image is described as being 600x600 DPI in
PDF metadata, and the print is said to be in 12 point - numbers for
converting from pixels to .001m units in font reconstruction...
M~
Hi John,
At 2024-01-18T00:43:41+1100, John Gardner wrote:
> I'm a professional graphic designer with access to commercial typeface
> authoring software. Send me the highest-quality and most comprehensive
> scans of a C/A/T-printed document, and I'll get to work.
If you don't have my scan of CSTR #54 (1976), which helpfully dumps all
of the glyphs in the faces used by the Bell Labs CSRC C/A/T-4, let me
know and I'll send it along. I won't vouch for its high quality but it
should be comprehensive with respect to coverage.
> Thanks for reminding me, Branden. :) I've yet to get V7 Unix working
> with the latest release of SimH,
Let me know in private mail where you got stuck. Maybe I can help.
> I'm still up for this, assuming you've not already started.
No, I haven't--perhaps because I am an Ada fanboy, the prospect of
coding in pre-standard C and its mission to turn anything that can be
lexically analyzed into _some_ sequence of machine instructions has not
stoked my excitement.
(Which isn't to say that one _can't_ write safe code using K&R C; my
fear is that having to remember all of the things the compiler won't do
for you would overwhelm the task at hand. Too bad Unix V7 didn't have
Perl, since this is basically a text transformation problem.)
Regards,
Branden
All, I got this e-mail from Holger a while back. Somehow it went into
a folder and has lurked unseen for way too long.
Does anybody know any more about PCS Unix and, if so, where should
I place the code that Holger has donated into the Unix Archive?
Many thanks, Warren
----- Forwarded message from hveit01(a)web.de -----
From: hveit01(a)web.de
To: wkt(a)tuhs.org
Subject: PCS kernel sources
Hi Warren,
Some time ago I subscribed to the tuhs mailing list because of my
interests in Unix.
I have been working on regenerating the ancient PCS unix (see more
details in the README file in the attached archive).
Now it is in a state to publish the results. You may decide to put this
up on the TUHS website for reference.
PCS UNIX (dubbed MINUX) is special in the way that it is derived from
an SVR3.2 UNIX with the Newcastle connection integrated.
The Newcastle connection is an early attempt for multicomputer
networking; it provides a shared file system over the network, similar
to the later NFS.
To my knowledge, it is the first time that source for it are described
(beyond some publicly availablereasearch paper); I haven't yet managed
to find the original sources of this.
Regards
Holger Veit
----- End forwarded message -----
No idea what COFF is, but in the early 1980s, two non-troff options on
the software side were -
1) TeX. From Donald Knuth, which means tau epsilon chi, pronounced tech
not tex. The urban legend was upon seeing an inital copy of one of his
books sometime in the 1970s, he yelled "blech!" and decided that if you
wanted your documents to look right, you need to do be able to it
yourself, and TeX rhymes with blech.
2) Scribe. From Brian Reid, of Carnegie-Mellon
See http://www.columbia.edu/cu/computinghistory/scribe.pdf
-Brian
Clem Cole clemc at ccc.com wrtoe:
> Not really UNIX -- so I'm BCC TUHS and moving to COFF
>
> On Tue, Jan 9, 2024 at 12:19b/PM segaloco via TUHS <tuhs at tuhs.org> wrote:
>
> > On the subject of troff origins, in a world where troff didn't exist, and
> > one purchases a C/A/T, what was the general approach to actually using the
> > thing? Was there some sort of datasheet the vendor supplied that the end
> > user would have to program a driver around, or was there any sort of
> > example code or other materials provided to give folks a leg up on using
> > their new, expensive instrument? Did they have any "packaged bundles" for
> > users of prominent systems such as 360/370 OSs or say one of the DEC OSs?
> >
> Basically, the phototypesetter part was turnkey with a built-in
> minicomputer with a paper tape unit, later a micro and a floppy disk as a
> cost reduction. The preparation for the typesetter was often done
> independently, but often the vendor offered some system to prepare the PPT
> or Floppy. Different typesetter vendors targeted different parts of the
> market, from small local independent newspapers (such as the one my sister
> and her husband owned and ran in North Andover MA for many years), to
> systems that Globe or the Times might. Similarly, books and magazines
> might have different systems (IIRC the APS-5 was originally targeted for
> large book publishers). This was all referred to as the 'pre-press'
> industry and there were lots of players in different parts.
>
> Large firms that produced documentation, such as DEC, AT&T *et al*., and
> even some universities, might own their own gear, or they might send it out
> to be set.
>
> The software varied greatly, depending on the target customer. For
> instance, by the early 80s, the Boston Globe's input system was still
> terrible - even though the computers had gotten better. I had a couple of
> friends working there, and they used to b*tch about it. But big newspapers
> (and I expect many other large publishers) were often heavy union shops on
> the back end (layout and presses), so the editors just wanted to set strips
> of "column wide" text as the layout was manual. I've forgotten the name of
> the vendor of the typesetter they used, but it was one of the larger firms
> -- IIRC, it had a DG Nova in it. My sister used CompuGraphic Gear, which
> was based on 8085's. She had two custom editing stations and the
> typesetter itself (it sucked). The whole system was under $35K in
> late-1970s money - but targeted to small newspapers like hers. In the
> mid-1908s, I got her a Masscomp at a reduced price and put 6 Wyse-75
> terminals on it, so she could have her folks edit their stories with vi,
> run spell, and some of the other UNIX tools. I then reverse-engineered the
> floppy enough to split out the format she wanted for her stories -- she
> used a manual layout scheme. She still has to use the custom stuff for
> headlines and some other parts, but it was a load faster and more parallel
> (for instance, we wrote an awk script to generate the School Lunch menus,
> which they published each week).
>
Hi All.
V10 had a program called "monk" which was a "document compiler".
It produced troff and know how to run eqn, tbl, and pic and I'm
guessing also refer. It seems to have been inspired by Scribe.
The V10 files from Dan Cross have the device independent troff output
for the paper that describes monk.
G. Branden Robinson was kind enough to turn it into PostScript for me;
his story is below, forwarded by permission. I'm also attaching
the PostScript file.
I'm curious, did this see a lot of use inside Research or outside of it?
At first glance, it looks like the kind of thing that might have
caught on, especially for people who weren't already used to troff.
Thanks,
Arnold
> Date: Wed, 10 Jan 2024 12:25:53 -0600
> From: "G. Branden Robinson" <g.branden.robinson(a)gmail.com>
> To: Aharon Robbins <arnold(a)skeeve.com>
> Subject: Re: v10 ditroff output file
>
> Hi Arnold,
>
> At 2024-01-09T08:50:28+0200, Aharon Robbins wrote:
> > Hi.
> >
> > The file of interest is attached. It's from vol2/monk in Dan Cross's
> > V10 sources in the Distributions/Research directory from TUHS.
> >
> > If you can get postscript out of it somehow,
>
> Bad news and good news.
>
> ...unfortunately there was too much impedance mismatch with groff/grops.
>
> Some font names differ but that's not a big deal. (Also, today I
> learned: the troff that generated this reloaded all the fonts at each
> new page.) The troff(1) that generated this also attempted vertical
> motion before starting the first page. That also wasn't a big deal. I
> thought I was going to be able to text-edit my way to a solution...but
> then...
>
> grops really wants the device resolution to be 72,000 dpi, not 720, and
> we'd have to write a rescaling feature to support that. Just editing
> the output file won't do because the file uses Kernighan's optimized,
> anonymous output command pervasively.
>
> groff_out(5):
> ddc Move right dd (exactly two decimal digits) basic units u,
> then print glyph with single‐letter name c.
>
> In groff, arbitrary syntactical space around and within this
> command is allowed to be added. Only when a preceding
> command on the same line ends with an argument of variable
> length a separating space is obligatory. In classical
> troff, large clusters of these and other commands were used,
> mostly without spaces; this made such output almost
> unreadable.
>
> So all these two-digit motions would need to become five-digit motions
> or all the glyphs would pile up on each other. (And that's exactly what
> I happened after doing a couple of fixups and throwing gxditview(1) at
> it.)
>
> Out of curiosity, I tried DWB 3.3 troff.
>
> It did well, until the fourth page, when it fell over and produced
> PostScript that made Ghostscript very angry.
>
> So I tried Heirloom Doctools troff.
>
> 20 pages of goodness.
>
> But be advised: some sort of extension was used to embed other
> PostScript files:
>
> ./bin/dpost: can't open picture file samples/tailor.ps (line 1493) (page 2)
> ./bin/dpost: can't open picture file samples/memo.ps (line 1749) (page 3)
> ./bin/dpost: can't open picture file samples/tmbody.ps (line 2151) (page 4)
> ./bin/dpost: can't open picture file samples/tmcs.ps (line 2694) (page 5)
>
> So I went to minnie.tuhs.org to see if they were there...
>
> ...and they were.
>
> So here you go. Renders without errors (though Heirloom is nowhere near
> as validation-happy as groff), and the output seems plausible.
>
> > I'll really appreciate it. :-)
>
> Enjoy!
>
> Regards,
> Branden
> The <C>omputerphile Youtube channel did a video about 10 years ago about
> "The Great 202 jailbreak:"
https://www.youtube.com/watch?v=CVxeuwlvf8w
It may be superfluous in this forum, but one should note that the video's
characterization of Brian Kernighan as the father of typesetting at Bell
Labs does great disservice to Joe Ossanna, who single-handedly
brought the first phototypesetter to the labs, subjected it to computer
control, and wrote troff (which lives on 50 years later) to drive it.
In passing, the video denigrates the C/A/T because it had a fixed font
repertoire and no general graphic capability. But without the antecedent
of C/A/T and troff, the famous Linotron summer-vacation project would
never have been undertaken.
Doug
SunRPC, among other protocols, needs transaction IDs (XIDs) to distinguish
RPCs.For SunRPC, it's important that XIDs not be reused (not for all
protocols; 9p has no such requirement). Stateless protocols like NFS and
reused XIDs can get messy.
There is a vague, 30 year old memory, I have, that at some point SPARC got
a time register, or some other register, that always provided a different
answer each time it was read, even if read back to back, in part to enable
creation of non-reused XIDs. Note that things like the TSC or RISC-V MTIME
register make no such guarantee.
I am pretty sure someone here can fill me in, or tell me I'm wrong, about
my SPARC memory.
thanks