Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.sys.pdp10 > #9969 > unrolled thread

boxing all integers (was Re: Resources to learn common lisp?)

Back to article view | Back to alt.sys.pdp10

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  boxing all integers (was Re: Resources to learn common lisp?) Kragen Javier Sitaker <kragen@canonical.org> - 2026-08-29 17:52 -0300
    Re: boxing all integers (was Re: Resources to learn common lisp?) Lars Brinkhoff <lars.spam@nocrew.org> - 2026-08-30 06:43 +0000
      Re: reprints of old AI memos (was Re: boxing all integers)f Kragen Javier Sitaker <kragen@canonical.org> - 2026-08-30 13:11 -0300
        Re: reprints of old AI memos (was Re: boxing all integers)f Lars Brinkhoff <lars.spam@nocrew.org> - 2026-08-31 05:14 +0000
          Re: reprints of old AI memos (was Re: boxing all integers) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-31 06:54 +0000
          Re: reprints of old AI memos (was Re: boxing all integers)f Kragen Javier Sitaker <kragen@canonical.org> - 2026-08-31 13:43 -0300
            Re: reprints of old AI memos (was Re: boxing all integers)f Kragen Javier Sitaker <kragen@canonical.org> - 2026-08-31 13:56 -0300
              Re: reprints of old AI memos (was Re: boxing all integers)f Paul Rubin <no.email@nospam.invalid> - 2026-08-31 13:34 -0700
                Re: reprints of old AI memos (was Re: boxing all integers)f Rich Alderson <news@alderson.users.panix.com> - 2026-08-31 18:12 -0400
                  Re: reprints of old AI memos (was Re: boxing all integers)f scott@slp53.sl.home (Scott Lurndal) - 2026-09-01 15:12 +0000
              Re: reprints of old AI memos (was Re: boxing all integers)f Lars Brinkhoff <lars.spam@nocrew.org> - 2026-09-01 05:59 +0000
                Re: reprints of old AI memos (was Re: boxing all integers)f Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-02 15:23 -0300
            Re: reprints of old AI memos (was Re: boxing all integers) Lars Brinkhoff <lars.spam@nocrew.org> - 2026-09-01 05:45 +0000
              Re: reprints of old AI memos (was Re: boxing all integers) Lars Brinkhoff <lars.spam@nocrew.org> - 2026-09-01 07:07 +0000
              Re: reprints of old AI memos (was Re: boxing all integers) Rich Alderson <news@alderson.users.panix.com> - 2026-09-01 17:36 -0400
                the history of the Hershey fonts (was Re: reprints of old AI memos) Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-02 15:55 -0300
                  Re: the history of the Hershey fonts (was Re: reprints of old AI memos) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-02 21:31 +0000
                    Re: the history of the Hershey fonts (was Re: reprints of old AI memos) Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-03 09:59 -0300
              Re: reprints of old AI memos (was Re: boxing all integers) Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-02 16:35 -0300
                Re: reprints of old AI memos (was Re: boxing all integers) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-02 21:50 +0000
                  PDF file compactness (was Re: reprints of old AI memos) Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-03 12:06 -0300
                Re: reprints of old AI memos (was Re: boxing all integers) Lars Brinkhoff <lars.spam@nocrew.org> - 2026-09-03 05:42 +0000
                  Re: reprints of old AI memos (was Re: boxing all integers) Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-03 12:50 -0300
              origin of XGP fonts (was Re: reprints of old AI memos) Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-28 10:44 -0300
                Re: origin of XGP fonts (was Re: reprints of old AI memos) Peter Flass <Peter@Iron-Spring.com> - 2026-09-28 07:33 -0700
                  Re: origin of XGP fonts (was Re: reprints of old AI memos) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-09-28 22:53 +0800
        Re: reprints of old AI memos (was Re: boxing all integers)f Lars Brinkhoff <lars.spam@nocrew.org> - 2026-09-06 08:40 +0000

Page 1 of 2  [1] 2  Next page →

#9969 — boxing all integers (was Re: Resources to learn common lisp?)

Alan Bawden <alan@csail.mit.edu> writes:
> Paul Rubin <no.email@nospam.invalid> writes:
>> All CPython integers are boxed, but small ones (-5 through +250 or
>> something like that) are pre-allocated.  Sounds awful but I think some
>> Lisps also have done that.
>
> For example, PDP-10 MacLisp.  The PDP-10 is a word addressed machine,
> where addresses are 18 bits, and words are 36 bits.  PDP-10 integers are
> 36 bits long, so pretty much your only choice for representing fixnums
> is as an 18-bit pointer to a 36-bit signed integer, i.e. "boxed".

I had no idea!  Never having used it, I had always assumed that MACLISP
shared the behavior of things like SBCL, Smalltalk, and recent versions
of Python — transparently overflowing from fixnums to bignums.

One advantage of the transparent-overflow approach is that most of the
time users don’t care what the actual fixnum limit is — it’s “just” a
performance optimization, in that your arithmetic starts consing when
you exceed the limit.

This does mean, however, that by default, for example on SBCL, all of
your arithmetic is stuffed full of overflow checks, which has
performance costs of its own.

>  • If an intermediate fixnum needs to be allocated, say to pass as an
>    argument to another function, it can be allocated in a special area
>    of memory that has fixnum type, but that is managed as a stack -- the
>    GC doesn't touch it.  That temporary number is then popped out of
>    existence after the function call returns.  This does mean that the
>    compiler has to constantly worry that an object that it is about to
>    store someplace permanent might be a stack allocated "PDL number".
>    The utility that replaces a potential PDL number with a permanent
>    number is named "PDLNMK", and every serious MacLisp programmer knows
>    exactly what it does because it frequently appears in our compiled
>    code.

This is an interesting idea; I imagine it’s a pretty big performance
win, particularly since MACLISP predates generational garbage collection
(and, I imagine, never had it bolted on).  Consing *per se* is pretty
fast in a pointer-bumping allocator; what used to kill you was the GC,
and generational GC largely solved that problem.  Still, I'm pretty sure
that Java, LuaJIT, Chez Scheme, V8, and SpiderMonkey don’t box their
fixnums.

> There's a paper by Guy Steele titled "Fast Arithmetic in MacLisp" that
> describes all these techniques in detail: <hdl.handle.net/1721.1/6279>.

Thank you very much!  I’d never read it.  For the peanut gallery, that’s
AIM-421.pdf, MD5 158106732f63bf268ffe4c1728950710.

Kragen

[toc] | [next] | [standalone]

#9972

Kragen Javier Sitaker wrote:
> Alan Bawden wrote:
>> There's a paper by Guy Steele titled "Fast Arithmetic in MacLisp"
>> that describes all these techniques in detail:
>> <hdl.handle.net/1721.1/6279>.
>
> Thank you very much!  I’d never read it.  For the peanut gallery,
> that’s AIM-421.pdf

I'll gratefully seize this opportunity to brag about "printing" some of
these memos fresh from source.

https://github.com/larsbrinkhoff/ai-memo-reprints/tree/master/mit/aim-421

[toc] | [prev] | [next] | [standalone]

#9974 — Re: reprints of old AI memos (was Re: boxing all integers)f

Lars Brinkhoff <lars.spam@nocrew.org> writes:
> Kragen Javier Sitaker wrote:
>> Alan Bawden wrote:
>>> There's a paper by Guy Steele titled "Fast Arithmetic in MacLisp"
>>> that describes all these techniques in detail:
>>> <hdl.handle.net/1721.1/6279>.
>>
>> Thank you very much!  I’d never read it.  For the peanut gallery,
>> that’s AIM-421.pdf
>
> I'll gratefully seize this opportunity to brag about "printing" some of
> these memos fresh from source.
>
> https://github.com/larsbrinkhoff/ai-memo-reprints/tree/master/mit/aim-421

That’s wonderful!  I should have realized that they were prepared with
some kind of runoff-like computer typesetting system, but I didn’t know
what it was; I hadn’t heard of FASTAR before (it looks to be very much
in the spirit of RUNOFF) and I’m delighted that the source document has
been preserved.  The reprint is considerably more readable than MIT’s
scan.

Not to look a gift thoroughbred in the mouth, but the fonts look a bit
pixelated.  But presumably they were vector fonts of some sort, maybe
Hershey fonts, rather than raster scans or original pixel fonts?  I
wonder if the fonts could be rerendered as vector fonts?  That would
make the reprint PDFs both much smaller and more readable.

In case they do happen to be Hershey fonts, I wrote a small BSD-licensed
Hershey font library a couple of years ago in C
<http://canonical.org/~kragen/sw/dev3/smolhershey.md.html> which may be
of some use, at least as an inspiration or reference point.  (As an
aside, I also converted the IMLAC Scroll Saver font you had recovered
into a Hershey font.)

Here’s an excerpt from an XPM of the reprint (somewhat mangled by
repeated resampling, but still preserving some of the blockiness) so you
can see what I mean:

    "                                                                                                                                                                ",
    "                                                                                              . + @ @ @ @ @ @ @ @ @ @ @ @ @ + # #                               ",
    "                                                                                        # $ % & * = - - - - - - - - - - ; > * , ' )                             ",
    "                                                                                        # ! ~ { ] ^ / / / / / / / / / / ( _ : < [ }                             ",
    "  | 1 2 3 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 5 & 6 7 ) #                 # # 8 9 0 a b c d e / / / / / / / / / / f g h = i j 5 3 k 5 4 l m n o 7 .       ",
    "# $ > p q / / / / / / / / / / / / / / / / / / / / / r ^ s ~ % #                 # + t u v w / / / / / / / / / / / / / / / / / / / x y z d e / A B C D ~ |       ",
    "# E F G H / / / / / / / / / / / / / / / / / / / / / y H I J K .             # # o L M N O ( / / / / / / / / / / / / / / / / / / P Q w e R y / S _ T L t }       ",
    ". % c U x / / / / / / / / / / / / / / / / / / / / / V W p ' X +           # + + < Y Z V P / / / / / / / / / / / / / / / / / / / / / / / / / / / / z `  .8       ",
    "+ ..F +.@.#._ $.P / / / / / / / / / / / / / / / e H %.N s &.J .         # $ X *.=.%.q $./ / / / / / / / / $.-.R h U h d _ $.$./ / / / / / / / / / z n 1 8       ",
    "+ . J *.6 3 ;.g Q / / / / / / / / / / / / / / / >.* ,., '.+ .         . + ).!.~.{.f V / / / / / / / / / / ].^./.(._.:.<.[.x }.P / / / / / / / / / |._.1.K       ",
    "+ # ! 8 2.3.4.R 5./ / / / / / / / / / / / / f S F 6.7.8.9.#           @ 0.a.b.c.d./ / / / / / / / / / $.e.f.g.h.m i.m j.= k.f.e.A P / / / / / / / |._.1.K       ",
    "+   + + E l.m.m n.P / / / / / / / / / / / W o.p.a.q.! ) |             r.[.s.}.}.W / / / / / / / / / / T n.t.8.J K ! K ~ t u.v.w.> x./ / / / / / / |.m 6 K       ",
    "+           X 2.j.P / / / / / / / / / / / e.y.z.A.                    _.B.O / / / / / / / / / / / / P C.(.,.}           0.J ' D.E.F./ / / / / / / |.3 r.~       ",
    "+           E G.2 $./ / / / / / / / / / / g H.I.t                 } E a H e / / / / / / / / / / / : g.J.K.&.+           + 7 % K.L.M.x N./ / / / / |.3 r.~       ",
    "+             # ).$./ / / / / / / / / / / y O.n *.                % K J./ / / / / / / / / / / / / P.4 6 .                   # a.$ Q.e A / / / / / |.3 r.~       ",
    "+             # ).$./ / / / / / / / / / / ].a =.R.              . u.i.s / / / / / / / / / / / O C.H.S.A.#                   # i.a.T.U.N / / / / / |.k v.K       ",
    "+               ).$./ / / / / / / / / / / ].j M J               + V.C x./ / / / / / / / / / P W.g.6                         # A.X.` L I / / / / / z n Y.8       ",
    ".               ).$./ / / / / / / / / / / Z.`.M J             + 0.U.{.|./ / / / / / / / / / P >. +1                         # K.t .+7.;.S f / / / k.++@+l.      ",
    "#               ).$./ / / / / / / / / / / Z.4 #+G.          . l.o P.$.P / / / / / / / / / / $.$+i.A.                        # 0 %+@+# $+|.]./ / $.d u.' 7       ",
    "#               ).$./ / / / / / / / / / / Z.4 #+G.          + X '.s./ / / / / / / / / / / / $.&+r.*+                        # &.=+<   <.@.%.|.k.d.@.-+8.}       ",
    "                ).$./ / / / / / / / / / / Z.4 #+G.          8 ;+s.k./ / / / / / / / / / / / V l >+9.                                  9.*+,+0 i.).'+$ @ #       ",
    "                ).$./ / / / / / / / / / / Z.4 #+G.          K )+C Z./ / / / / / / / / / / P f 5 !+G.                                  ..~ *+1 u.=+t @           ",
    "                ).$./ / / / / / / / / / / Z.4 #+G.          o C r N./ / / / / / / / / / W c ~+S.E )                                   + | $ K l.7 7 #           ",
    "                ).$./ / / / / / / / / / / Z.4 #+G.          q.b./ / / / / / / / / / / / e.^.= {+                                                                ",
    "                ).$./ / / / / / / / / / / Z.4 #+G.          q.b./ / / / / / / / / / / / x  +O.t                                                                 ",
    "                ).$./ / / / / / / / / / / Z.4 #+G.          q.b./ / / / / / / / / / / / Z.D.0 9.                                                                ",
    "                ).$./ / / / / / / / / / / Z.4 #+G.          q.b./ / / / / / / / / / / / Z.a 3.9.                                                                ",
    "                ).$./ / / / / / / / / / / Z.4 #+G.          q.b./ / / / / / / / / / / / 5.(.M G.                                                                ",
    "                ).$./ / / / / / / / / / / Z.4 #+G.          q.b./ / / / / / / / / / / / 5.(.M G.                                                                ",
    "                ).$./ / / / / / / / / / / Z.4 #+G.          q.b./ / / / / / / / / / / / 5.`.#+G.                                                                ",
    "                ).$./ / / / / / / / / / / Z.4 #+G.          q.b./ / / / / / / / / / / / 5.j M G.                                                                ",
    "                ).$./ / / / / / / / / / / Z.4 #+G.          q.b./ / / / / / / / / / / / ]+{ j.&.                                                                ",
    "                ).$./ / / / / / / / / / / Z.4 #+G.          q.b./ / / / / / / / / / / / x i b t                                                                 ",
    "                ).$./ / / / / / / / / / / Z.4 #+G.          o ^+y f / / / / / / / / / / N.M./+2.l.}                                   # . (+(._+J.O.J $ +       ",
    "                ).$./ / / / / / / / / / / Z.4 #+G.          :+C.-.W / / / / / / / / / / P w Z.%+9.%                                   . + 1.<+~.U [+K.8 @       ",
    "                ).$./ / / / / / / / / / / Z.4 #+G.          !  +g.U / / / / / / / / / / / A w 3 D G.                                  (+}+6.|+b.|.1+).=+7       ",
    "                ).$./ / / / / / / / / / / Z.4 #+G.          | L.X.G / / / / / / / / / / / / V t.Y.=+                                  O.[+2+/ / / z ` 1 8       ",
    "                ).$./ / / / / / / / / / / Z.4 #+G.          @ K.>+3+N.$./ / / / / / / / / / $.T.#+{+                              + + .+|+d./ / / z n 1 8       ",
    "                ).$./ / / / / / / / / / / Z.4 #+G.            # | ;+4+}./ / / / / / / / / / $.U.I.S.                            # ! 8 = P P / / / z n Y.8       ",
    "                ).$./ / / / / / / / / / / Z.4 #+G.              @ /.%._ / / / / / / / / / / $.- .+2.+ .                       # + 9.5+g./ / / / / z ,.Y.8       ",
    "                ).$./ / / / / / / / / / / Z.4 #+G.              # -+r.; / / / / / / / / / / / k.#.6+*+5+#                   . ! J [.+.h / / / / / |.k v.K       ",
    "                ).$./ / / / / / / / / / / Z.4 7.J               # {+-+V./ / / / / / / / / / / e.x 7+8+=+. #             # + ) o 9+0+O r / / / / / |.k a+K       ",
    "            } K v.$./ / / / / / / / / / / x b+j &.                $ ! c+Z.w / / / / / / / / / V f d+e+f+8+{+| #     7 K '+ +f+I g+h+y S / / / / / |.m 6 ~       ",
    "            E J #+$./ / / / / / / / / / / g i b 8.                    `._ ]./ / / / / / / / / / / W x +.Y.).) #     % J 6 ] 1+f / / / / / / / / / |.3 r.~       ",
    "            ..*.M $./ / / / / / / / / / / g i+t.'.#                   4 |.r / / / / / / / / / / / W x j+1.u.$ | @ @ 8 *.#+C T f / / / / / / / / / |.3 r.~       ",
    "        7 % 2 s Q./ / / / / / / / / / / / V Y B.,.A.q.                D i.$+Q }.W / / / / / / / / $.f f.k+l+e+g+g+g+P.W.M.Z.]+P / / / / / / / / / |.3 r.~       ",
    "        ..K m+b.q / / / / / / / / / / / / P w ]+_+).5+                :+*+3 w x ( / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / |.3 r.~       ",
    "  ) 2 0 n+$+o+_ ]./ / / / / / / / / / / / / S W o.g.p+:.++E } #       } l.8+O.O.; e.A / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / |.& 1.K       ",
    "  $ > 0+q / / / / / / / / / / / / / / / / / / / / / r h F :+! #           % A.A.4 y w P / / / / / / / / / / / / / / / / / / / / / / / / / / / / / z n Y.8       ",
    "  E F G H / / / / / / / / / / / / / / / / / / / / / ]+z q+9.~ .           7 *.*.1.U.; 0+p u r+x.N.V / / / / / / / / / / / / Q ] s+)+p Z S V / / / H M ).!       ",
    "  % Q.%.y / / / / / / / / / / / / / / / / / / / / / V W p ' X +                 } G.9+1 v.j O.<+x ( / / / / / / / / / / / / B w.6+i.1.p.].Q / / P d X.' 7       ",
    "  E t+W.s+1+1+1+1+T T {.{.{.{.{.c.c.c.c.{.{.T T 1+1+N [+[.9+J .                 ) K 9.-+,+3._.;+r+B.1+1+T T {.{.{.{.T 1+Y C u O.j  .).f+u+[+1+Y v u m.9+}       ",
    "  . q.R.u.#+#+#+#+M M 9 ++3.=.=.0 0 0 =.++++i.M 7.#+u.!+t . #                     # # + + @ | J 8.[ #+7.i.i.9 9 9 9 i.7.}+[ (+} | + + o &.L.#+1.>+A.) .         ",
    "  # % l.v+a.a.a.<  .1 1.1.a+a+6 6 6 6 6 1.1.1  .< a.v+&.J #                                   l.G.{+< < 1 Y.}+}+}+}+1 < S.{+8..       % o K.a.).'.&.@           ",
    "    . + 0.7 7 7 $ $ $ $ $ E E E E E E E $ $ $ $ $ $ 0.| @                                     + @ ) $ $ $ $ $ $ $ $ $ $ } ) |         . + ) 7 7 | | #           ",
    "                                                                                                                                                                "};
Kragen

[toc] | [prev] | [next] | [standalone]

#9976 — Re: reprints of old AI memos (was Re: boxing all integers)f

Kragen Javier wrote:
>> https://github.com/larsbrinkhoff/ai-memo-reprints/tree/master/mit/aim-421
> I should have realized that they were prepared with some kind of
> runoff-like computer typesetting system, but I didn’t know what it
> was; I hadn’t heard of FASTAR before (it looks to be very much in the
> spirit of RUNOFF) and I’m delighted that the source document has been
> preserved.

FASTAR is short for "fast arithmetic" and is the original manuscript
file name, not the name of the typesetting software.  The software is
Greenblatt's TJ6, first written on the PDP-6 for preparing a paper on
his chess program MacHack VI.

> Not to look a gift thoroughbred in the mouth, but the fonts look a bit
> pixelated.  But presumably they were vector fonts of some sort, maybe
> Hershey fonts, rather than raster scans or original pixel fonts?

No, the fonts are pixelated at around 200 DPI.

> I wonder if the fonts could be rerendered as vector fonts?

I can send you the raster data, and then you could do the rerendering.

Here are some of the fonts converted to BDF raster fonts.

https://github.com/larsbrinkhoff/xgp-fonts
https://github.com/atsampson/its-tests/blob/master/tools/ksttobdf

I also did a conversion the other way, rendering Comic Sans as an XGP
font.  Here's a sample text.

https://mastodon.sdf.org/deck/@larsbrinkhoff/116891010619446769
https://github.com/larsbrinkhoff/pdp10-its-disassembler/blob/master/ast.c

[toc] | [prev] | [next] | [standalone]

#9977 — Re: reprints of old AI memos (was Re: boxing all integers)

On Mon, 31 Aug 2026 05:14:17 +0000, Lars Brinkhoff wrote:

> No, the fonts are pixelated at around 200 DPI.

It adds to the feeling of an authentic period look. ;)

[toc] | [prev] | [next] | [standalone]

#9978 — Re: reprints of old AI memos (was Re: boxing all integers)f

Lars Brinkhoff <lars.spam@nocrew.org> writes:
> FASTAR is short for "fast arithmetic" and is the original manuscript
> file name, not the name of the typesetting software.  The software is
> Greenblatt's TJ6, first written on the PDP-6 for preparing a paper on
> his chess program MacHack VI.

I see!  Thank you.  I should have realized that.

> No, the fonts are pixelated at around 200 DPI.

I wonder where they came from?  If there are other fonts out there with
compatible metrics, maybe they could be dropped in.

For the typewriter font the body of the paper is set in, that should be
pretty easy (its “m” and “i” are evidently the same width, and similarly
“M” and “-”, so it’s almost certainly fixed-pitch, even though the word
spaces and letter spaces vary for justification).  However, the serif
roman font used for the title and the letterhead, if that’s the term,
evidently has variable pitch.  If we’re lucky, it’s just the Hershey
version of Times New Roman, a question which seems likely to be obvious
to people who know fonts better than I do.

> I can send you the raster data, and then you could do the rerendering.
>
> Here are some of the fonts converted to BDF raster fonts.

Is the BDF conversion lossy?  Glancing at the Python, it doesn’t appear
to be thresholding grayscale or anything like that.

Reverse-engineering outline data from raster data with something like
potrace (or, since it’s 02026, running gradient descent on a
differentiable polygon filling program) might be an interesting
challenge, but I don’t think I’m up to it this week.

> I also did a conversion the other way, rendering Comic Sans as an XGP
> font.  Here's a sample text.
>
> https://mastodon.sdf.org/deck/@larsbrinkhoff/116891010619446769

Hilarious!

Kragen

[toc] | [prev] | [next] | [standalone]

#9979 — Re: reprints of old AI memos (was Re: boxing all integers)f

Kragen Javier Sitaker <kragen@canonical.org> writes:
> Is the BDF conversion lossy?  Glancing at the Python, it doesn’t appear
> to be thresholding grayscale or anything like that.

Upon taking what should have been the obvious step of looking at the
README file
<https://github.com/larsbrinkhoff/ai-memo-reprints/blob/master/README.md>
I see that XGP is the Xerox experimental XeroGraphic Printer — which
strongly implies that the fonts are bilevel, not grayscale, since
xerography is terrible at grayscale, even 50 years later.  But I am
pretty sure that the data in these PDF files is grayscale, having just
rendered it with pdf.js, mupdf, libpoppler, and GhostScript, and zoomed
way in in each one.

Perhaps this grayscale is a product of the “PDP-11 emulator running the
original XGP driver code” mentioned in the README, since presumably it
wasn’t controlling the original XGP hardware.  I wonder if TJ6 could be
hacked to output a .dvi-like list of (glyph, x, y) triples?  It would
probably make for PDF fies that were both more readable and more compact
(and therefore easier to archive).

Kragen

[toc] | [prev] | [next] | [standalone]

#9980 — Re: reprints of old AI memos (was Re: boxing all integers)f

Kragen Javier Sitaker <kragen@canonical.org> writes:
> I see that XGP is the Xerox experimental XeroGraphic Printer — which
> strongly implies that the fonts are bilevel, not grayscale,

I remember XGP output as being pretty low quality back in its day.  I
don't remember if dot matrix impact printers were a thing then.  The
early 300 dpi desktop laser printers that came afterwards had much
better output than the XGP, though the XGP was apparently quite fast.  I
never saw the XGP in operation but I read a fair amount of stuff that it
had printed.

[toc] | [prev] | [next] | [standalone]

#9981 — Re: reprints of old AI memos (was Re: boxing all integers)f

Paul Rubin <no.email@nospam.invalid> writes:

> Kragen Javier Sitaker <kragen@canonical.org> writes:

>> I see that XGP is the Xerox experimental XeroGraphic Printer--which strongly
>> implies that the fonts are bilevel, not grayscale,

> I remember XGP output as being pretty low quality back in its day.  I don't
> remember if dot matrix impact printers were a thing then.  The early 300 dpi
> desktop laser printers that came afterwards had much better output than the
> XGP, though the XGP was apparently quite fast.  I never saw the XGP in
> operation but I read a fair amount of stuff that it had printed.

The XGP was 200dpi; the third generation Dover printer (used, e.g., at SAIL)
was 384dpi, but the SAIL fonts were 200dpi.

My own first experience with laser printers was the Xerox 9700, based on a much
higher quality Xerox copier engine than the XGP/Dover.  It was 300dpi, had dual
print engines so that duplex was a fast as simplex, and altogether a beast.  We
attached it to an Amdahl 470/V7 running SVS (= OS/VS2 v1), then moved it to the
3031 running MVS when that came in.

I did my printing from the DEC-20s over an RJE link to those boxen.

-- 
Rich Alderson					  news@alderson.users.panix.com
      Audendum est, et veritas investiganda; quam etiamsi non assequamur,
	  omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
									--Galen

[toc] | [prev] | [next] | [standalone]

#9985 — Re: reprints of old AI memos (was Re: boxing all integers)f

Rich Alderson <news@alderson.users.panix.com> writes:
>Paul Rubin <no.email@nospam.invalid> writes:
>
>> Kragen Javier Sitaker <kragen@canonical.org> writes:
>
>>> I see that XGP is the Xerox experimental XeroGraphic Printer--which strongly
>>> implies that the fonts are bilevel, not grayscale,
>
>> I remember XGP output as being pretty low quality back in its day.  I don't
>> remember if dot matrix impact printers were a thing then.  The early 300 dpi
>> desktop laser printers that came afterwards had much better output than the
>> XGP, though the XGP was apparently quite fast.  I never saw the XGP in
>> operation but I read a fair amount of stuff that it had printed.
>
>The XGP was 200dpi; the third generation Dover printer (used, e.g., at SAIL)
>was 384dpi, but the SAIL fonts were 200dpi.
>
>My own first experience with laser printers was the Xerox 9700, based on a much
>higher quality Xerox copier engine than the XGP/Dover.  It was 300dpi, had dual
>print engines so that duplex was a fast as simplex, and altogether a beast.  We
>attached it to an Amdahl 470/V7 running SVS (= OS/VS2 v1), then moved it to the
>3031 running MVS when that came in.

We had one as well, attached to a Itel AS/6 running MVS circa 1980.

Later, at Burroughs, we qualified them on the large and medium systems
mainframes.

[toc] | [prev] | [next] | [standalone]

#9983 — Re: reprints of old AI memos (was Re: boxing all integers)f

Kragen Javier Sitaker wrote:
> I am pretty sure that the data in these PDF files is grayscale

Yes, that's right.

> Perhaps this grayscale is a product of the “PDP-11 emulator running the
> original XGP driver code” mentioned in the README

Yes.  Just printing the raw pixels to the output PDF doesn't look good,
and certainly nothing like the original XGP output.  Angelo Papenhoff
and I did the "print emulation" trying to match the originals.  There's
a metaball type model for dispersing and blending individual print dots.
You can see the code in the xgp files here: https://github.com/aap/pdp11

> I wonder if TJ6 could be hacked to output a .dvi-like list of (glyph,
> x, y) triples?

The output from TJ6 is an "XGP file", which is ASCII text interspersed
with control codes.  This is sent by the printer spooler to the PDP-11,
along with font data.  The PDP-11 does the rendering and sends it to the
XGP for output to continuous roll paper.  There's a knife to cut the
paper into pages.

[toc] | [prev] | [next] | [standalone]

#9987 — Re: reprints of old AI memos (was Re: boxing all integers)f

Lars Brinkhoff <lars.spam@nocrew.org> writes:
> Kragen Javier Sitaker wrote:
>> Perhaps this grayscale is a product of the “PDP-11 emulator running the
>> original XGP driver code” mentioned in the README
>
> Yes.  Just printing the raw pixels to the output PDF doesn't look good,
> and certainly nothing like the original XGP output.  Angelo Papenhoff
> and I did the "print emulation" trying to match the originals.  There's
> a metaball type model for dispersing and blending individual print dots.
> You can see the code in the xgp files here: https://github.com/aap/pdp11

That sounds pretty reasonable, and vectorizing bilevel font bitmaps
sounds a lot easier than vectorizing grayscale, which is what I thought
the task was.  Still more than I'm willing to commit to this week, but
substantially less overwhelming.

Under US law, font bitmaps are uncopyrightable.  But I’m in Argentina,
and I assume you’re in Norway.  What’s the legal situation in Norway?

Stimulated by my embarrassment over thinking TJ6 was called FASTAR, I
poked around the repo a bit, but couldn't find which code you meant that
might be rasterizing a metaball model.

>> I wonder if TJ6 could be hacked to output a .dvi-like list of (glyph,
>> x, y) triples?
>
> The output from TJ6 is an "XGP file", which is ASCII text interspersed
> with control codes.  This is sent by the printer spooler to the PDP-11,
> along with font data.  The PDP-11 does the rendering and sends it to the
> XGP for output to continuous roll paper.  There's a knife to cut the
> paper into pages.

I see.  Does that mean that the “XGP file” has glyph indices but not (x,
y) positions in it, because the PDP-11 has to produce some of those (x,
y) positions from the font metrics?  That might actually be a format
capable of producing superior PDF rendering.

Kragen

[toc] | [prev] | [next] | [standalone]

#9982 — Re: reprints of old AI memos (was Re: boxing all integers)

Kragen Javier Sitaker wrote:
>> No, the fonts are pixelated at around 200 DPI.
> I wonder where they came from?

I read a story somwhere, but I forgot the details and where I found it.
It was something like getting a font catalog from a major foundry and
digitizing it by hand.

People also made their own; the AST file format is just a text file with
pixel data, and on ITS there's FED (font "editor") to display a font on
the 340 or a Knight TV.  I think SAIL had something else, certaily so
when TeX and Metafont were developed.

"The Last Whole XGP Font Catalog" (play on "Last Whole Earth Catalog")
has a lot to say about the XGP.

> If there are other fonts out there with compatible metrics, maybe they
> could be dropped in.

Yes.  What is it you want to accomplish?

> Is the BDF conversion lossy?  Glancing at the Python, it doesn’t appear
> to be thresholding grayscale or anything like that.

It's not my script, and I haven't checked.  But I would guess it's a 1:1
pixel conversion.  What grayscale are you talking about?

[toc] | [prev] | [next] | [standalone]

#9984 — Re: reprints of old AI memos (was Re: boxing all integers)

Lars Brinkhoff writes:
> Kragen Javier Sitaker wrote:
>> Is the BDF conversion lossy?  Glancing at the Python, it doesn’t appear
>> to be thresholding grayscale or anything like that.
> It's not my script, and I haven't checked.  But I would guess it's a 1:1
> pixel conversion.  What grayscale are you talking about?

I now understand you are referring to the final PDF, which indeed is in
grayscale.  But that is not due to the fonts, which are plain bi-level
both in the original PDP-10 data and converted to BDF.  The BDF fonts
are not involved making the PDF anyway.

The "putting dots on paper" process making the PDF happens in the PDP-11
emulator running the XGP code.  The output is written to an oversampled
floating-point array representing the amount of ink across the page.
This is downsampled to 200 DPI with a plain box filter, which is how the
grayscales happen.

The number 200 is only an approximation.  It's something like the
average resolution across a horizontal line.  But actually the
resolution varies across that line; I forget whether it's higher or
lower at the edges.  And the vertical resolution is closer to 192 DPI,
which makes the text taller.  I suppose an argument could be made that
the emulator is an "ideal XGP" which is somewhat better than the
original machine.

[toc] | [prev] | [next] | [standalone]

#9986 — Re: reprints of old AI memos (was Re: boxing all integers)

Lars Brinkhoff <lars.spam@nocrew.org> writes:

> Kragen Javier Sitaker wrote:

>>> No, the fonts are pixelated at around 200 DPI.

>> I wonder where they came from?

The Hershey fonts were originally designed for computer output on microfilm
(COM) which entailed using a cathode ray tube to expose photographic
negatives.  Dr. Hershey designed them as an alternative to the use of the
entirely mechanical Varityper.  Since he was working in a US Navy lab, his work
was automatically in the public domain.

> I read a story somwhere, but I forgot the details and where I found it.
> It was something like getting a font catalog from a major foundry and
> digitizing it by hand.
> 
> People also made their own; the AST file format is just a text file with
> pixel data, and on ITS there's FED (font "editor") to display a font on
> the 340 or a Knight TV.  I think SAIL had something else, certaily so
> when TeX and Metafont were developed.

Knuth originally used the XGP to design his METAFONT program (version 1), then
moved on to an electrostatic printer and the Mergenthaler Linotron 202 for
version 2.

-- 
Rich Alderson					  news@alderson.users.panix.com
      Audendum est, et veritas investiganda; quam etiamsi non assequamur,
	  omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
									--Galen

[toc] | [prev] | [next] | [standalone]

#9988 — the history of the Hershey fonts (was Re: reprints of old AI memos)

Rich Alderson <news@alderson.users.panix.com> writes:
>> Kragen Javier Sitaker wrote:
>>> Lars Brinkhoff <lars.spam@nocrew.org> writes:
>>>> No, the fonts are pixelated at around 200 DPI.
>>> I wonder where they came from?
>
> The Hershey fonts were originally designed for computer output on
> microfilm (COM) which entailed using a cathode ray tube to expose
> photographic negatives.  Dr. Hershey designed them as an alternative
> to the use of the entirely mechanical Varityper.  Since he was working
> in a US Navy lab, his work was automatically in the public domain.

I see this was unclear, but what I meant to ask is whether the 200-dpi
XGP fonts Brinkhoff is using are derived from the Hershey fonts, or
whether they come from some other source, such as someone creating a new
font on ITS with FED.

The story of the Hershey fonts is indeed fascinating, and Dr. Hershey’s
achievements were remarkable.  I wrote a 4200-word article about Hershey
fonts that may be of interest to those who aren’t familiar with the
details.  It draws from my reading of the following sources:

- _Calligraphy for Computers_, by Hershey
- _A Contribution to Computer Typesetting Techniques_, by Wolcott and
  Hilsenrath
- Patrick Michael Doyle’s master’s thesis
- “A computer system for scientific typography”, by Hershey
- HERSHEY.DOC in GhostScript
- GNU plotutils
- Pete Holzmann’s original mod.sources posts containing the Hershey
  fonts in the James Hurt Format (JHF)
- “The Last Bit: Missionaries Lag No More”, about Pete Holzmann
- “Exploring Dr. Hershey’s Typography”, by David M. MacMillan and
  Rollande Kandall
- “Cartography and Typography with True BASIC”, by Hershey
- Frank Grießhammer’s TypeCon speech about Hershey fonts
- Kamal Mostafa’s hershey-fonts C library
- The hersheypy Python library by Usenet’s own Lawrence D’Oliveiro
- Paul Bourke’s exploration of the JHF format

If there are some of these you haven’t read, the article may be of
interest to you.  It is hershey-fonts.md in the pavnotes2
repository:

    git clone http://canonical.org/~kragen/sw/pavnotes2.git

Kragen

[toc] | [prev] | [next] | [standalone]

#9990 — Re: the history of the Hershey fonts (was Re: reprints of old AI memos)

On Wed, 02 Sep 2026 15:55:04 -0300, Kragen Javier Sitaker wrote:

> - The hersheypy Python library by Usenet’s own Lawrence D’Oliveiro

Source code is here <https://gitlab.com/ldo/hersheypy>, done as an
addon to my Python wrapper for the Cairo 2D graphics library
<https://gitlab.com/ldo/qahirah>, built on its “user font”
functionality.

Hershey fonts cannot be directly represented in common font formats
like TrueType or Type 1, because the former are defined in terms of
strokes (e.g. for rendering on a plotter), while the latter work in
terms of filled outlines.

On the other hand, you can get a lot of variations out of a single
Hershey font by varying the thickness and patterning of the strokes
used to render it.

Examples of use of the Hershey fonts are here
<https://www.deviantart.com/default-cube/gallery/54390594/hersheypy-examples>.

[toc] | [prev] | [next] | [standalone]

#9993 — Re: the history of the Hershey fonts (was Re: reprints of old AI memos)

Lawrence D’Oliveiro <ldo@nz.invalid> writes:
> On the other hand, you can get a lot of variations out of a single
> Hershey font by varying the thickness and patterning of the strokes
> used to render it.
>
> Examples of use of the Hershey fonts are here
> <https://www.deviantart.com/default-cube/gallery/54390594/hersheypy-examples>.

These are very nice!

I’ve been thinking about other variations as well; stroke fonts handle
variations in aspect ratio and obliquing much better than outline fonts
do, for example, and I suspect that some simple heuristics for replacing
some straight lines with curves ought to be able to produce high-quality
lettering from some Hershey fonts.

Kragen

[toc] | [prev] | [next] | [standalone]

#9989 — Re: reprints of old AI memos (was Re: boxing all integers)

Lars Brinkhoff <lars.spam@nocrew.org> writes:
> Kragen Javier Sitaker wrote:
>> If there are other fonts out there with compatible metrics, maybe they
>> could be dropped in.
>
> Yes.  What is it you want to accomplish?

Without detracting from your achievement, I think it may be possible to
build on it to get a 20× smaller file that is more readable, more
aesthetically appealing, easier to quote from and search for text in,
and more accessible to blind users.

Size
----

Contrary to popular belief, PDF is a relatively compact file format.
The file format overhead is typically only around a kilobyte, and it
supports Deflate for content streams and, in recent versions, even for
much of the file structure information.  It is also routine to subset
embedded fonts to only the glyphs actually used in the file.

AIM-421 is pure text, and it’s about 10 pages of about 50 lines of about
12 words of about 6 characters; (* 10 50 12 6) gives an estimate of
36000 characters, which would Deflate to about 14–18 kilobytes.  But the
reprint file is 1.5 megabytes, roughly an inflation factor of 100×.

A smaller PDF file would either have to use Courier (the only typewriter
font in the 14 core fonts of PDF, and a particularly ugly and unreadable
one) or bundle a font (subset) of its own.  But the ASCII subset of a
typewriter font used in the document in question is unlikely to be more
than another 50 kilobytes, giving a total target file size of 70K or
less.

Small size reduces the cost of archival preservation, making it more
likely to happen.

Readability and aesthetic appeal
--------------------------------

Although your reprint PDF is significantly better-looking than the
original print that MIT scanned, the typewriter font used is still
slower to read to many current typewriter fonts, such as Inconsolata,
Computer Modern Typewriter, Latin Modern Typewriter Light, DejaVu Sans
Mono, Consolas, and Noto Mono.  Arguably, it’s even inferior to Courier
(which I am looking at as Nimbus Mono PS Regular).

Although I am aware that preferences differ, it is my belief that these
more-readable fonts are also more *pleasant* to read, and that this
aesthetic preference is likely to be at least widely shared, if not
objectively correct.

I do not believe that the details of the original font represent a
significant aspect of the merits of AIM-421 or the other AI memos.

Quoting, searching, and blind-accessibility
-------------------------------------------

It’s very common to quote a sentence or two from a paper when commenting
on it, both because the reader may not have read the original paper (and
may not want to) and to clarify specifically what you’re commenting on.
Although current AI is probably good enough to do error-free real-time
OCR on demand from PDFs like your reprint, current PDF readers do not
yet do this, instead using the invisible text layer added by tools like
OCRmyPDF.  This is also what PDF viewers use for text search and, as I
understand it, what screen readers for the blind use for synthesizing
speech.

It is my contention that making the text contents of the page accessible
as text would make the reprints significantly more useful.

Kragen

[toc] | [prev] | [next] | [standalone]

#9991 — Re: reprints of old AI memos (was Re: boxing all integers)

On Wed, 02 Sep 2026 16:35:26 -0300, Kragen Javier Sitaker wrote:

> Contrary to popular belief, PDF is a relatively compact file format.

Only if you apply compression to it.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | alt.sys.pdp10

csiph-web