Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail From: Kragen Javier Sitaker Newsgroups: alt.sys.pdp10 Subject: Re: reprints of old AI memos (was Re: boxing all integers)f Date: Wed, 02 Sep 2026 15:23:55 -0300 Organization: Primarily biological and memetic Lines: 38 Message-ID: <87bjaf7br8.fsf@debian> References: <874inbqdz7.fsf@mariorosell.es> <110l0v9$3av52$1@dont-email.me> <110nf0q$3vra6$3@dont-email.me> <87y0gg62cx.fsf@nightsong.com> <110rfqf$142ot$1@dont-email.me> <111ne5o$vsm3$3@dont-email.me> <111pbk6$36pi7$1@dont-email.me> <87qzlqgiyx.fsf@gmail.com> <111t96n$6sqq$1@dont-email.me> <111tev9$8hea$1@dont-email.me> <875x2zzres.fsf@nightsong.com> <86se5zr6ez.fsf@williamsburg.bawden.org> <87mru47iou.fsf_-_@debian> <7wecfgrtuh.fsf@junk.nocrew.org> <874igb7fmv.fsf_-_@debian> <7wwlt6rhw6.fsf@junk.nocrew.org> <874iga5jgr.fsf@debian> <87zey244ak.fsf@debian> <7wh5k95x5u.fsf@junk.nocrew.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Date: Wed, 02 Sep 2026 18:26:14 +0000 (UTC) Injection-Info: dont-email.me; logging-data="3206424"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+pwr1zYbY+FqbcmIxihmh7"; posting-host="de81ddf0846fce2f7070364d1569cfb9" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) Cancel-Lock: sha1:NfoP8RlRpYYs6Ae7c0lNoVZMHys= sha1:kM1kAHta+poQQZC3huB/Rtg6ZDs= sha256:U5HtF4VKxzHfTi3OINOdbQTd4a9zvIm16sCjqjgO7ag= sha1:fKtJCzFyeBv39E08NzYSjuyfzVk= sha256:N403XEpiz3cYVPa17k4YL1YfHIj7xUseK6uFwVAl/po= Xref: csiph.com alt.sys.pdp10:9987 Lars Brinkhoff 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