github.com/PDP-10.its
1
0
Fork 0
mirror of https://github.com/PDP-10/its.git synced 2026-01-11 23:53:12 +00:00
Code Issues Releases Wiki Activity
PDP-10.its/doc/fonts/dover.log
Lars Brinkhoff 9ddb2db796 Fonts.
2018-05-09 07:05:12 -07:00

495 lines
22 KiB
Plaintext
Executable File
Raw Permalink Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Date: 21 JUL 1980 1926-EDT
From: MOON at MIT-MC (David A. Moon)
To: DOVER-FONT-CHANGES at MIT-MC
This mailing list (DOVER-FONT-CHANGES @ MC) now exists and if you got this
message you are on it. Mail is logged in the file MC:FONTS;DOVER LOG.
Please send a brief note to this address if you install a new font or
otherwise change the Spruce.Fonts on the dover or the Fonts.Widths on
IFS, ITS, or XX. (XX:<FONTS>FONTS.WIDTHS and AI:ML:DM:MC:FONTS;FONTS WIDTHS
are the same file; the one on [IFS]<PRINTING>FONTS.WIDTHS (or wherever
it is) is not the same currently and only has a few fonts in it.)
Also note in your message whether you backed-up the Spruce.Fonts onto
the IFS or not; it wants to be backed up in case the Dover's Trident
disk goes down, as it does periodically.
It would be reasonable to discuss proposed changes to the fonts in this
list also, although it doesn't go to all of the people who would want
to be involved in anything major.
The Xerox "font cataclysm" is finally about to happen; Dave Reed should
have documents tomorrow describing what is going to happen, and hopefully
we will bring the new fonts over this week.

Date: Wednesday, 23 July 1980 10:08-EDT
From: DPR at MIT-XX
To: DOVER-FONT-CHANGES at MIT-MC
Subject: font cataclysm files.
The upcoming cataclysm in dover fonts is described in the files
mc:dpr;* prs. Those of you who care about these things will
find it useful to read this.
Yesterday, MOON and I discussed the mechanics of future font
changes and coordination. The master copies of both the
font rasters and the width files will be kept on the IFS.
Distribution to ITS's and XX will occur as now. Distribution to alto's
will occur by requiring thatalto users get new versions themselves.
Distribution to other machines will be worked out. THere will be several
versions of widths files, progressively more all-inclusive, eventually.
The current font width files will be updated to include more fonts,
such as the new TEX fonts, when we get them.
We will try to make a font catalog happen sometime in the fall. Rather
than showing each size of each face, this catalog will contain one
page for each face showing the character mapping and shape of one size,
and samples of each size that exists (perhaps only one character).
There are a couple of unanswered questions.
1) RZ will help resolve the question of what TEX fonts we maintain,
once we see what Knuth and Xerox finally come up with.
2) We now have several other Dover-like devices with incompatible font
sets -- the Canon machine on the 4th floor, the Varian on the 4th floor,
and the XGP. At the very least, we ought to have some compatibility
among these. Even with its problems, if we could standardize on a compatible
font set among these, with compatible widths in micas, we'd be a whole
lot better off. If software existed to process press files for each of
these devices (at least theoretically possible), then we'd be even better
off. I'd like reactions to these ideas, if you have any.
3) We don't really have a good set of font creation tools. I'd really
like to know what we do have.
peace,
David

Date: 23 JUL 1980 1125-EDT
From: RZ at MIT-MC (Richard E. Zippel)
Subject: font cataclysm
To: DOVER-FONT-CHANGES at MIT-MC
2) We now have several other Dover-like devices with incompatible font
sets -- the Canon machine on the 4th floor, the Varian on the 4th floor,
and the XGP. At the very least, we ought to have some compatibility
among these. Even with its problems, if we could standardize on a compatible
font set among these, with compatible widths in micas, we'd be a whole
lot better off. If software existed to process press files for each of
these devices (at least theoretically possible), then we'd be even better
off. I'd like reactions to these ideas, if you have any.
3) We don't really have a good set of font creation tools. I'd really
like to know what we do have.
[ Since all the TEX fonts are generated by Metafont, after the set of fonts for
the Dover has been created we can produce a compatible family of fonts for
the XGP, Varian and Canon quite easily. The only problem is that some
people don't like DEK's fonts. ]

Date: 4 Aug 1980 1203-EDT
From: LICK at MIT-DMS (J. C. R. Licklider)
To: DOVER-FONT-CHANGES at MIT-MC, LICK at MIT-DMS
Subject: REQUEST FOR HELP RE LARGE FIXED-WIDTH DOVER FONT
Message-id: <[MIT-DMS].156623>
For making vu-graphs on the DOVER, I am looking for a font similar to
FIXED 24PT or 40FG on the XGP. Ideally, I would like about 50 characters
across the page plus the ability to retain the indentation format obtained
with PRETTYPRINT and with EMACS/RMODE editors. Any pointers would be
greatly appreciated. Of special interest is the rumor that someone
(Dave Reed) has 'migrated' fixed-width fonts from XGP to DOVER (if they
include large typeface).
Regards/thanks
Lick

Moon@MIT-AI 08/20/80 21:20:13 Re: New font installed
To: dover-font-changes at MIT-MC
CC: rz at MIT-MC
FIG5 installed. It is a special purpose font and does not contain standard characters.

Date: 6 OCT 1980 2101-EDT
From: MOON at MIT-MC (David A. Moon)
Subject: Forwarded message
To: DOVER-FONT-CHANGES at MIT-MC
Date: 6 Oct 1980 13:50 PDT
From: Ramshaw at PARC-MAXC
Subject: Re: Fonts.Widths
In-reply-to: DCP's message of 6 OCT 1980 1332-EDT
To: DCP at MIT-MC (David C. Plummer)
cc: RZ at MIT-MC, MOON at MIT-MC, DPR at MIT-MC
cc: CPR at MIT-MC, CSD.BKR at SU-SCORE, Sproull at CMU-10A, Ramshaw
David, the Fonts.Widths files that I have prepared for release to the
universities give, so far as I am aware, correct and complete width
information for all of the fonts in the Dover dictionary that I also
prepared for release. Neither of the Dover dictionaries that I have
released included any of Don Knuth's TEX fonts (in the Computer
Modern family). A very old version of those fonts exists at PARC,
and I have heard rumors that some version of unknown vintage
exists at MIT. I have just finished hacking on Metafont so that it will
produce PARC-style rasters and width information directly. I am
now trying to get people to agree on a scalable format for TEX font
metric files (.tfx'x); once that is decided, I will hack Metafont to
write them, and the PARC version of TEX will be hacked to read and
use them. When all this is done, I will release new fonts and widths
dictionaries to the universities that will include Knuth's second-edition-
of-Volume-II versions of the Computer Modern fonts.
Lyle

Date: Monday, 20 October 1980 20:50-EDT
From: DPR at MIT-XX
To: DOVER-FONT-CHANGES at MIT-MC
Subject: Font cataclysm today.
Well, the cataclysm happened today. There are two or three
remaining problems to be solved.
1. The fonts.widths has not been distributed to EE, SPEECH,
or other such places (the PDP-11's of RTS, ...).
This should be no problem since the date mechanism in press
files should ensure that the Dover uses the old widths
for files produced from old fonts.widths. In case you didn't
know, the date field should be initialized from the file
creation date of fonts.widths.
2. We dont have a font catalog for all faces. I have a catalog
of all faces that Xerox sent us, since they sent us such
a catalog with the cataclysm. If anyone has a way to make a better
one (basically, a masp that shows the graphic for each of
the 256 chars (yes, some fonts are that big) of a face, and
a list of the point sizes we have of that face), please let me know.
3. There is a minor bug in the Spruce we got as part of the cataclysm.
This results in funny "Font XXXNNN substituted for HELVE589" messages
that have no effect on the text.
4. I don't know if it is useful to make a fonts.widths that includes
our current TEX fonts.
5. Does anyone know if the bug in the bounding box for Helvetica MIR
was fixed by the new fonts.widths I distributed?
6. The preceding point raises a more serious problem...different formatters
have been using conflicting ways to determine inter-line spacing for
fonts. I believe that Bravo separates the baselines by the "point size"
of the font, plus the leading. Scribe seems to use the bounding box.
Xerox does not really have a standard way to do this, and the problem
is clear when you consider how to define the line spacing between two
line s of different fonts. Typesetters have a concept of "opening up
the lines" in a document that is somewhat subtle...they try not to vary
interline spacing unless forced (so a line of smaller font than usual
is not squished tightly in between two lines of usual height).
Anyone have any thoughts on this?
Please let me know of any problems. Also please check that your
press files are getting the new widths (check the date, in other words).
David

Date: Tuesday, 21 October 1980 10:06-EDT
From: DPR at MIT-XX
To: DOVER-FONT-CHANGES at MIT-MC
Subject: EBM's comments on installation and interline spacing.
Date: Tuesday, 21 October 1980 08:47-EDT
From: EBM
To: DPR
Re: Font cataclysm today.
The new FONTS.WIDTHS IS installed on EE and SPEECH. Also, all seven
PDP/10's, 20's have <FONTS>FONTS.INFO, which is a program generated
summary of FONT.WIDTHS. We still need an online list of what sizes of
every font are provided by the Dover, though. No big rush on that I
don't think.
About interline spacing: R determines the interline spacing from the
height of the PRINCIPAL font (usually the main text font). That height
is taken from the bounding box, and then leading is added in. (Leading
is actually expressed as a percent of the bounding box height.) All
that is then multiplied by the line spacing factor. So, the normal
spacing is:
BB * ((100 + LEADING) / 100) * LS
However, if this would cause a new line to overlap with an old one, then
the new one is forced down just enough to avoid overlap. The above
calculation is used in trying to place the baseline of the line. In
computing overlap, we have available to us the amount by which the
previous line extends below the baseline, and the amount by which the
current line extends above it. The calculations here are a little
crude, because we have height information only for each font as a whole,
not on a per-character basis. So, sometimes lines will be forced apart
needlessly, because the formatter cannot tell that some characters of a
given font are not as tall as others. Anyway, this method seems to work
well, provided LEADING and/or LS are big enough for what you are doing.
However, there is no easy way to convince R NOT to force tall lines
apart.
I have noticed that Spruce is giving many more "page too complex" or
"band too big" errors than before. I suspect that the new Spruce has
some table sizes reduced. Is that something that you could investigate?
Did Xerox give us the sources so that somebody can try to fix bugs?
[DPR-- I don't know whether there are more page-too-complex messages;
if anyone else discovers this problem I will make it a high priority]

Date: Tuesday, 21 October 1980 20:46-EDT
From: DPR at MIT-XX
To: DOVER-FONT-CHANGES at MIT-MC
Subject: Ramshaw's comments on font spacing, timesroman change.
All: The following is a response from Ramshaw regarding a user's
complaint that his interline spacing changed with the new release
of fonts. I don't know the offending formatter, but this seems
to be Xerox's position on vertical spacing.
"The new TimesRoman fonts do indeed have a taller font
bounding box than the old ones. The offending character is probably
the vertical bar, which has been made tall enough and deep enough so
that aligned vertical bars in adjacent "normally spaced" lines of
TimesRoman will overlap to form a solid vertical rule. The solution to
your user's problem is not to let anyone use the height of the font
bounding box to decide how much vertical space to put between lines
of text. The bounding box height is really the wrong notion for this,
since it includes all of the exotic characters in the font as well as the
alphabetic ones. Instead, formatters should take the nominal size of the
font (10 points for TimesRoman10, say), and adjust it to allow for the
amount of interline spacing that is desired.
[Note: The families TimesRoman and Helvetica are about 10% bigger on
paper than they really should be, for historical reasons. Keep this in
mind if and when you start measuring interline spacing and trying to
adjust it... Life is hard.]"
David

Date: Tuesday, 21 October 1980 21:10-EDT
From: DPR at MIT-XX
To: DOVER-FONT-CHANGES at MIT-MC
Subject: Comments by EBM on fonts.
I forward these for your comments. My comments are in brackets.
David
-------
Date: Tuesday, 21 October 1980 14:31-EDT
From: EBM
To: dpr
Re: Fonts
Having compared the various pieces of information (namely a list of the
fonts on the Dover, and a print-out of FONTS.WIDTHS), I have the
following proposal to suggest:
1) That these width entries be deleted from FONTS.WIDTHS, because there
are no corresponding fonts on the Dover:
DANABOOKB, DANATEN, DANATESTORBIT, DANATWELVE, HYTYPE, NEWFONT,
RJP, SYMBOLS
[I agree --DPR]
2) That width information for these fonts be added to FONTS.WIDTHS,
because they might be useful to people using formatters other than TEX:
HELVETICASC, TIMESROMANSC
[I have never seen these, so I don't know. Advice anyone? --DPR]
3) Do we need TIMESROMANMIT and HELVETICAMIT? I think they should
probably go away.
[These are RMS's fonts and I believe are nearly the same as the "nonMIT" ones,
so with some warning they could probably go away. --DPR]
4) It is not clear how useful width information for the TEX fonts
(CMxxx, SLIDESCMxxx, and TGxxx) would be to other people. Do we want to
provide it? I know that R could do all right with it, EXCEPT (and this
is a big except) that the space character is not really present, but is
a special character, so it might be hard to convince R to do the right
thing about spacing, etc.
[I await opinions from other knowledgable people --DPR]
5) Unless I hear otherwise from you, it would appear that the only fonts
for which we do not have samples that we might need samples (for non-TEX
users) are: BOX, HELVETICMIT, LPT, TIMESROMANMIT, and also HELVETICASC
and TIMEROMANSC if you add them. Assuming that the 2 xxxMIT fonts go
away, that leaves BOX and LPT, and the 2 xxxSC fonts. Those are easy.
It might be worthwhile to punt LPT, too, if SAIL does the right thing.
On the other hand, that change should be done only after consulting more
people. However, there is very little difference between SAIL and LPT
so far as I know, and if SAIL has been fixed up from before, then maybe
we should go with it alone.
[SAIL only comes in 8 point, I believe. --DPR]

Date: Wednesday, 22 October 1980 19:59-EDT
From: DPR at MIT-XX
To: PSZ at ML, DOVER-FONT-CHANGES at MC
Subject: suggestions from PARC
The following excerpt of my conversation with Dan Swinehart may be relevant
to TEX users in coping with "file too complex" bugs.
"2. Our Spruce also goes into Swat on rare occassions, several times
recently on Press files produced by TEX. Rumor has it that one
reason why TEX Press files tickle this bug is that they request a
huge number of fonts, even though they don't use very many. Changing
the "basic.tex" to ask for fewer fonts may help you avoid being hassled
by this bug for the moment. Maybe the Spruce wizards will find time
to fix the bug some day soon....."
David

Date: 23 OCT 1980 2240-EDT
From: MOON at MIT-MC (David A. Moon)
Subject: Comments by EBM on fonts.
To: DOVER-FONT-CHANGES at MIT-MC, DPR at MIT-XX, ebm at MIT-XX
The LPT font family is **NOT** the same as SAIL and **MUST NOT** be deleted.
Many people use it heavily. And conversely the SAIL family is not redundant
and may not be deleted either.
I believe the xxxMIT fonts are required for RMS' (and probably other peoples')
use of SCRIBE.
The Fonts.Widths entries for fonts that don't exist should be deleted. The
SYMBOLS font has probably been replaced by SYMBOL (which people use; it
was installed because someone asked for it.)
You should either maintain the file FONTS;DOVER FONTS or delete it. It seems
to have been superseded by FONTS INFO, **EXCEPT** that the DOVER FONTS file
reflects what is actually on the Dover while FONTS INFO appears to have been
generated from Fonts.Widths. Also FONTS INFO is in a less concise and readable
format. (In the past when I changed the fonts I have generated DOVER FONTS
from the output of a Spruce List command by editing out the superfluous
information in a straightforward fashion then sorting it alphabetically.)

Date: 24 Oct 1980 0839-EDT
From: EBM at MIT-XX
Subject: Moon's comments
To: dover-font-changes at MIT-MC
I agree with Moon, but thought I would fill you in on exactly what
FONTS;DOVER FONTS and FONTS;FONTS INFO are, and why they are both
useful. DOVER FONTS is a list of what is actually on the Dover,
including point sizes, etc., as generated by PREPRESS (slightly edited
by a human to make it more readable). FONTS INFO is a list of what is
in FONTS WIDTHS, and for many families says the size is "fractional".
This information is what a formatter will see, and fractional means that
your formatter will believe in any point size for the font, whether or
not it is actually on the Dover. FONTS INFO is generated by the program
<FONTS>PRINTFONTS.EXE on XX (the source is <CLU.SUBSYS>PRINTFONTS.CLU).
To users of formatters other than TEX, both are important. FONTS INFO
tells you what your formatter will believe in, and DOVER FONTS tells you
what Spruce believes in. Clearly you can use only the intersection.
Naturally the files are a bit out of sync right now -- because we had
not settled all the details, I did not try to make them consistent yet.
When we have cleaned things up (i.e., deleted extra entries from FONTS
WIDTHS -- the LPT and xxxMIT fonts will stick around, but we might be
able to offer TIMESROMANSC and HELEVETICASC (SC = small caps)), I intend
to constuct a combination listing by editing the two files together,
which will show for each family and face and indication of:
whether it is fractional
the point sizes actually available
whether it is a fixed width font
I propose that this information, a condensed form of the most relevant
information of both files, be stored in a file called FONTS;FONTS LIST.
Further, I will make sure that each of FONTS INFO, FONTS LIST, and DOVER
FONTS has a creation date in it, and that FONTS INFO and DOVER FONTS
mention the existence of FONTS LIST, so that people will be directed to
the best information. If that is the case, then I may improve
PRINTFONTS to generate a readable form of ALL the information in FONTS
WIDTHS. This would make FONTS INFO somewhat bigger, but it could be
useful to people writing program that hack PRESS format. I don't think
it would be useful to the general public. Anybody have any different ot
better ideas?
-------

Date: 6 JAN 1981 2203-EST
From: Moon at MIT-MC (David A. Moon)
Subject: Vandalism to fonts
To: DOVER-FONT-CHANGES at MIT-MC
Someone has vandalized the LPT font family, by taking out characters 11, 12, 14, and 177
and changing some of the others to blanks. This could have been a human or a program.
If anyone has any information about this, please let me know. When the IFS comes up
I will retrieve the original LPT fonts and reinstall them. I use those characters.

Date: 13 MAR 1981 1617-EST
From: MOON at MIT-MC (David A. Moon)
Subject: Problems with TEX vs SPRUCE
To: DOVER-FONT-CHANGES at MIT-MC, (BUG TEX) at MIT-MC
MEM points out that DPRESS can be an enormous help in tracking these down.
So if any other TEX users run into problems, let them know about this.

Moon@MIT-AI 04/07/81 02:11:25 Re: FONTS; FONTS WIDTHS
To: DOVER-FONT-CHANGES at MIT-MC
Who installed a new file FONTS; FONTS WIDTHS on 1 April? It is much larger than the
previous version and either contains garbage or the format has been changed. Offhand
I don't know of any text justifiers that this didn't break.

Date: 1 June 1981 04:32-EDT
From: David A. Moon <Moon at MIT-MC>
To: OAF at MIT-MC, JNC at MIT-MC, DPR at MIT-MC
cc: DOVER-FONT-CHANGES at MIT-MC
Could we please have back the old version of Spruce that works?

Date: Friday, 31 July 1981 11:20-EDT
From: DPR at MIT-XX
To: dover-font-changes at MIT-MC, cel at MIT-XX
Subject: CMU fonts
We now have on our dover all of the fonts CMU has added to its
dover font catalog. I have not yet, but will, merge the width
information into fonts.widths and distribute it soon. But now
we can print press files generated at CMU. New fonts include
math symbols oriented to the new scribe (if we should ever get
it) and several pictorial fonts (creatures, othello, backgammon).
Also, several language-oriented fonts are available.
I am in the process of determining the set of MIT-generated fonts
so we can maintain them more effectively. I believe the following
list includes all of the MIT-made fonts. Any that you know to be obsolete
should be reported to me. I have commented on the obsolescence of some of the
following, feel free to send me any comments you have.
BOX 10
HELVETICAMIT 10 (only one size, made by RMS for EMACS manual. Probably would
not be needed if SCRIBE handled fonts better. Face same as
helvetica 10)
HELVETICASC (9,10) (used by TEX hackers -- has caps of a smaller point size
where lowercase should be)
LPT our lineprinter font (I think Xerox has picked this up).
TGATHX,
TGB,
TGI,
TGR,
TGS,
TGSY,
TGTT,
TUATHX,
TUB,
TUI,
TUR,
TUS,
TUSY,
TUTT (all fonts for HAL's Turtle Geometry book, probably deleteable after
a while)
TIMESROMANMIT 10 (another RMS thing)
TIMESROMANSC (...) small caps like helveticasc.
Also, we are now maintaining a lot of old TEX fonts. Some are replaced by
a new set that have lots of magnifications. When we flush the old TEX,
we can flush these, but I am concerned about fonts called SLIDES... and
a couple of others that are not available in the new TEX world. Comments
from TEX wizards are invited. I would like to delete the old tex fonts
(the ones that are of face MRR, and have only a single magnifaction) ASAP.
David

Reference in New Issue View Git Blame Copy Permalink