Hardcopy, Press, printing, and plot output on CADR and Genera

What System 46 actually preserves

The public archive inventory dates the latest preserved source generations as follows:

The pinned archive inventory and its Press, Versatec, and XGP entries establish source/media presence and dates. They do not establish that every QFASL was compiled from the latest adjacent source.

System 46 has no source counterpart to the later generic hardcopy.lisp in this snapshot. The four named packages are therefore documented first on their own terms; the dispatcher is a later integration layer visible in the LM-3 source.

The LM-3 generic Hardcopy contract

The maintained source defines four public operations:

A printer value is either a printer-type keyword or a list whose first element is the type and whose remaining elements are backend arguments. A site table can also map human-readable strings to those values. Dispatch repeatedly checks the required property; if the selected printer cannot perform that operation, the error protocol can request another printer instead of embedding a global case statement in every client.

HARDCOPY-FILE recognizes these defaults from the pathname type:

Its declared options are font, font list, heading font, page headings, vertical spacing in micas, copies, and optional spooling. The dispatcher also has a per-printer-type defaults layer. The maintained list of defaultable options is font, font list, heading font, page headings, vertical spacing, copies, and spool. An explicitly supplied option wins over a printer-type default.

The built-in :LPT method is deliberately narrow. It accepts only text, selects an ITS/Unix/other pathname according to the associated host's system type, and copies the character stream. It does not simulate fonts or accept Press, XGP, or plot input.

Terminal-Q screen hardcopy

In System 303 source, Terminal-Q is the generic screen-hardcopy key. Its Help text is conditional: the binding advertises itself only when the selected printer type has a PRINT-BIT-ARRAY method.

The implementation snapshots the selected region into a reusable one-bit pixel array while interrupts are inhibited, beeps after capture, and then calls HARDCOPY-BIT-ARRAY. This separation matters: the screen is stable only long enough to take the snapshot; slow encoding or network transmission can happen afterward without requiring the visible raster to remain unchanged.

The older XGP package also has foreground and background screen/window helpers. The background path explicitly snapshots first and launches an XGP Hardcopy process to encode and queue the private copy. Its own source says these helpers are mostly superseded by the generic escape-key mechanism.

PRESS: page description and Dover transport

CADR PRESS is both a page-description writer and a delivery client. It is not just a filename extension.

The generator builds a Press file from parts, pages, entities, a data list, and an entity list. Its primitive operations include:

• open and close a file, page, and entity;
• set the current cursor in micas;
• define and select a Dover font;
• emit characters and strings;
• draw vector lines and rectangles;
• embed a bitmap from a window or pixel array; and
• finish a multi-copy document with title, date, and requestor metadata.

The entity command vocabulary covers short and long character runs, skips, absolute position, horizontal and vertical spacing, font selection, brightness, hue, saturation, object display, opaque or transparent dot display, and rectangles. The corresponding data-list vocabulary includes line movement and drawing plus raster sampling/window/mode controls. These are Press-format capabilities, not evidence that the CADR user had a retained drawing editor in this package.

XGP scan files and queue requests

The XGP package's raster path takes a one-bit array and writes a scan file rather than Press. Its complete callable surface is:

Each output scan line first attempts run-length encoding into a bounded buffer. If that representation overflows, the encoder falls back to literal image bits for that line. It writes a pair of line records and finishes with a page-cut record. The default scan file is temporary and the queue request can instruct the service to delete it after printing.

The queue request is a small textual control file containing status, user/group, time, page count, optional deletion, a SCAN directive, and the scan-file pathname. Thus the scan file and the queue request are separate artifacts. A recovered scan file alone does not say whether it was ever queued.

The source leaves three explicit maintenance problems: pathname canonicalization for queue requests, a separate file connection for background operation, and a dependency on the Hacks QFASL for one setup path. They are contemporary source limitations, not failures discovered by the emulator.

DPLT: SUDS plots to Press

DPLT is a format converter for SUDS PLT engineering drawings, not a general interactive plotter. It reads PDP-10-oriented 36-bit records as pairs of 18-bit values, prescans each drawing to find its coordinate bounds, rotates and scales the result into Dover coordinates, and then emits Press pages.

The public entry point is DPLT-PRINT-FILE. Filenames and keyword/value pairs may be interspersed:

Unadorned names default to type PLT. Multiple files normally become pages in one Press request. PRINT-TXT-FILE is a separate convenience path for WLR/text material using an LPT-style font and the Press formatter.

The record processor handles vectors, text, diamond symbols, frame/title data, and file/logo metadata. It maps SUDS font number, style, and character size to candidate SAIL/Math/Helvetica Dover fonts, using nearest-width and fallback rules when the exact face is absent. It makes two passes because the plot is not assumed centered.

The source explicitly does not support rotated characters or PAD-related PC features. Those omissions should remain visible in any reconstruction rather than silently approximated.

Versatec: direct hardware, not a file formatter

VERSAT operates at the opposite end of the abstraction spectrum. It contains literal UNIBUS control, data, byte-count, buffer-address, and extended-address register locations. Its operations are:

The optimized copies temporarily wire Lisp pages and program fixed UNIBUS map locations. Running them without the corresponding interface is unsafe and has no museum value; source inspection is the correct current evidence. QWOPY is the function's literal historical spelling, not an expansion established by the source.

Editor and Dired integration

The maintained editor command Print File prompts for a pathname and calls the generic HARDCOPY-FILE. Dired uses P-marked files and a configurable list of hardcopy options. These are thin clients: neither implements a printer backend.

This is the earliest preserved form of the later Genera pattern in which file, mail, documentation, and graphics applications delegate output through a shared hardcopy service.

Registry and stream architecture

Genera formalizes two registries:

• a hardcopy format records its name, documentation, input formatter, input options, output stream flavor, output options, canonical file type, and binary byte size; and
• a hardcopy device records the printer/device flavor, optional hardcopy-file object flavor, accepted input formats, generated output format, display-device type for character-style mapping, defaults, and serial/interface behavior.

The format layer converts stored input into a device stream or creates an output stream that generates a stored printer format. The device layer decides what the printer can consume and how to reach it. Because registration records source identity and updates a central list, separately loaded support can extend the system without changing Hardcopy File.

The base basic-hardcopy-stream is a character output stream with page state, cursor, bounding box, margins, page number, orientation, title/date metadata, character metrics, and required device operations. Graphics-capable subclasses add the drawing protocol. Device-independent callers can therefore use the same drawing vocabulary for a window and a hardcopy stream while respecting their different coordinate systems: screen Y grows downward from the upper left; hardcopy Y grows upward from the lower left.

Formats established by the inspected source

The public user's guide additionally offers LaserWriter and XGP choices in the Hardcopy File file-type presentation. The inspected Hardcopy source defines the six registrations above; the pathname layer still defines an XGP canonical type. A fresh Genera 8.5 runtime census returned exactly the same six registered names and the live form rendered exactly those six choices. Thus XGP and LaserWriter are not active format entries in this base-world load. They may still come from optional compatibility support or reflect a documentation/release difference; this article does not invent a missing registration.

Complete Hardcopy File command

Hardcopy File accepts a sequence of pathnames and a printer. Wild pathnames expand before a background process is started. When Use canonical type is selected, files are grouped by detected hardcopy format so a mixed request can be dispatched correctly.

The source does not open every file in the background blindly. It first forces needed file-server logins and probes/expands names in the foreground, then starts a named process. On success that process can notify the user and delete requested inputs; file and network failures become notifications. This ordering is a source-only operational detail that reduces delayed authentication errors.

Hardcopy System is a second command in the Printer area. It selects a system, version and optional version-control branch, query policy, silent mode, component inclusion, title, character styles, copies, orientation, and running head, then delegates to the system-construction facility. It is source-tree output, not a world-image dump.

The System menu's Hardcopy item calls Hardcopy File through an Accepting Values window. Pathname presentations also translate directly to the command when the object is a sequentially accessible non-directory file and either is not binary or has a registered hardcopy format.

Runtime observation: the fresh Genera 8.5 world rendered the complete Hardcopy File form with PRESS, DMP1, LGP2, POSTSCRIPT, TEXT, and ASCII as its explicit format choices. No printer was entered, Done was not selected, and the form was aborted. The image is cropped to the form because the underlying Listener was irrelevant. Underlying software and display material remain the property of their respective rightsholders; reproduced here for criticism, scholarship, and historical documentation under 17 U.S.C. section 107. No affiliation or endorsement is implied.

Application entry points

The commands belong to their client applications but share the Hardcopy backend. For complete Zmacs and Zmail editing/mail behavior, see the editor dossier and Genera Zmail.

Function-Q screen capture

Function-Q without an argument uses the saved defaults. Function-Q with any numeric argument opens an Accepting Values form and stores the resulting choices for subsequent captures.

Printer defaults

Genera keeps separate defaults for text and bitmap output. This prevents a screen-image-capable device requirement from constraining ordinary text output.

Programmatic setters support init-file customization. Host namespace attributes can override site defaults at local-name initialization. If a command reaches a missing default, it asks for a printer rather than fabricating one.

Complete user queue commands

The Printer command area contains output and queue-request operations:

The request presentations produced by Show Printer Status are direct inputs to Delete and Restart. This is semantic interaction, not text scraping: the printed queue row retains the printer/request object needed by the next command.

Complete maintenance commands

Printer Maintenance is a subset of Site Administration, not a separate window program:

The implementations recheck that a request is still printing after interactive confirmation. A stale mouse-selected row cannot silently reset a different job that became current while the user was deciding.

These operations can address a remote spooled printer over the printer-control service. They are not restricted to the spooler host's console.

Print Spooler program and persistent queues

The optional Print system's pretty name is Print Spooler; its visible frame is Printer Spooler Log. Select S selects it when installed. The frame has a scrollable log pane, command menu, and listener whose prompt is Print Spooler command:.

It has exactly two direct program commands:

Each locally managed printer has a manager process and persistent directory under the configured Print-Spooler home. Requests have separately saved data and properties; queues, policies, and printer characteristics also have stable and temporary representations. Manager states are uninitialized, booting, crashed, suspended, idle, and printing. The manager's state is distinct from the physical device's operational/intervention state.

The queue protocol supports query, add/modify/delete entry, query/modify policy, query/modify printer characteristics, restart, suspend, resume, reset, and shutdown operations. Not all of those protocol methods have direct user commands; the documented command surface above is the bounded public UI.

The spooler starts automatically only when the host configuration identifies locally spooled printers and advertises the appropriate service. It also requires a usable Internet domain name for completion notifications. Loading the Print system into a world is therefore not sufficient to create a functioning queue.

The deeper lifecycle, state, and log analysis is shared with Background services and operations dashboards.

Delivery paths and site configuration

The namespace Printer object supplies type and interface information; host attributes identify default printers and spooler hosts; service triples describe protocol reachability. A printer name alone is therefore insufficient reconstruction metadata.

PostScript-family output

Genera 8 separates generic PostScript behavior from LaserWriter-specific LGP behavior.

The printer-type definer controls display-device/font mapping, accepted formats, output format, XON/XOFF and DTR assumptions, serial defaults, page order, printer-name commands, Adobe patch/error-handler loading, font-memory threshold, resolution, completion timeout, cover-page placement, and native color support. Color capability affects whether image output is reduced to grayscale.

This is not merely passthrough. The hardcopy stream maps character styles to printer fonts, can download bitmap fonts, emits graphics operations, and may partition font downloads by page to fit device memory. A generated .ps file is therefore a meaningful preservation artifact, but it may contain device-oriented font/image data whose redistribution rights must be reviewed independently.

The separate PostScript interpreter

The PostScript system declares a lexer, interpreter, operators, Zmacs integration, and restricted tests. Its Display PostScript File utility opens a file and interprets it into a Genera graphics output stream. The same interpreter is used to:

• produce a binary graphics encoding for picture integration;
• register PostScript as an image input format;
• extract raster images encountered in a PostScript program; and
• write image sequences as EPS-compatible output through the images system.

The inspected operator file implements a broad Level-1-style core: stacks, dictionaries, procedures, arithmetic, comparisons, control flow, files/strings, transforms, paths, clipping, strokes/fills, images, fonts, and show operations. That source census does not prove conformance to every PostScript language version or arbitrary modern EPS/PDF producer. Runtime compatibility with a representative corpus remains a TODO.

The interpreter and the printer generator meet at Genera's graphics/image protocols, but their direction is opposite:

Genera text/graphics -> Hardcopy formatter -> PS/LGP2 bytes -> printer/spooler/file
PostScript bytes      -> PostScript interpreter -> Genera graphics/image objects

CADR

The public source fully establishes interfaces and algorithms, but a meaningful physical-output test would require at least one of the historical service paths: an AI XGP queue, MC Dover spooler or reachable Dover protocol endpoint, or the Versatec UNIBUS interface. The maintained System 303 environment has none of those configured. Invoking a direct device routine would test failure handling, not printing.

A future safe CADR runtime audit should first provide an inert sink that records bytes without claiming device equivalence. It can then verify:

1. Terminal-Q argument-to-rectangle selection;
2. XGP scan-line fallback and queue-file pairing;
3. text-to-Press page, heading, font, and copy metadata;
4. DPLT bounds/rotation against a public sample PLT; and
5. exact output hashes from repeated deterministic requests.

The Versatec routines should be tested only in a hardware emulator that models the documented UNIBUS registers and DMA map. A file sink is not a faithful test of that path.

Genera

The dedicated d35-hardcopy-20260718 generation-1 session started from a fresh private copy of the identified Genera 8.5 world. It made these read-only observations:

• both HARDCOPY:*default-text-printer* and HARDCOPY:*default-bitmap-printer* were NIL;
• the hardcopy-format registry, in registry order, was exactly PRESS, DMP1, LGP2, POSTSCRIPT, TEXT, and ASCII;
• HARDCOPY reported released version 446.0;
• PRESS and GPRINT were present as loaded subsystems whose version query selected :NEWEST; and
• Print and PostScript returned no loaded system version.

The session then opened Hardcopy File and the numeric-argument Screen hardcopy form shown above. Both were aborted through their printed Abort presentations. It did not choose Done, capture a screen, open an output file, load Print or PostScript, contact a printer, or submit a hardcopy request.

One exploratory attempt to apply CAR to the screen-option registry's template helper objects entered the Debugger because those objects are not conses. It was aborted to the Listener before either selected form was opened. That failure is not application behavior, so its screen remains ignored; retaining it in the ordered action log prevents the published images from implying a cleaner interaction than occurred.

The full-frame raw captures and sidecars remain in ignored session storage. The two reviewed public crops and their exact transformations are recorded in the Genera screenshot catalog and receive individual conclusions in the screenshot rights review.

Public CADR material

The public source is sufficient to reconstruct the Press writer, XGP scan encoder, DPLT parser, and Versatec register protocol. Preserve these separately:

• source revision and exact file generation;
• generated output bytes;
• queue/control metadata;
• font-equivalence and metric inputs;
• printer/site defaults; and
• the endpoint or hardware model used in testing.

Do not replace the original output bytes with a rendered PNG and call the recovery complete. A specimen rendering is useful, but the page-description or scan artifact retains transform, font, page, and queue semantics that a bitmap loses.

Licensed Genera material

Keep generated Genera printer streams and any downloaded proprietary font data under ignored build storage until their rights are reviewed. A tracked tool may describe or extract format metadata without publishing the payload. Public documentation may state commands, architecture, observed behavior, sizes, and checksums in original words.

For a future output harness, prefer a deliberately configured file destination over a fake network printer. Record the live hardcopy-format registry before the request, select a public synthetic input, disable deletion, and capture both the command action log and output hash. Test PostScript interpretation separately with openly licensed fixtures.

Public CADR and LM-3 source

The System 46 source is pinned at Git commit 8e978d7d1704096a63edd4386a3b8326a2e584af. The maintained LM-3 source is pinned at Fossil check-in 4df393c68d7f083ce42d5c377039d26043cc18a9031ace28258dc97f4137eb91. Both were verified locally on 18 July 2026.

Licensed Genera research inputs

The logical paths are media-relative and deliberately omit the machine-specific licensed archive location.

Public manuals

The PDFs were verified locally on 18 July 2026.