The thing that makes PDF less attractive than plain Postscript is that it is a binary format. PDF is "object" oriented; Postscript is "stream" oriented. You have to construct a binary table-of-contents at the end of a PDF file with byte-offsets into the file referencing a tree of PDF objects. And, it still has to be converted to Postscript to send to a printer. Whereas, a Postscript file can simply be sent to a Postscript printer directly. I know of no native PDF printers. Postscript is a text file; you can edit it with a text editor and not mess it up.
On 29 Feb 2016, at 12:48 PM, <[email protected]> <[email protected]> wrote: > Date: Mon, 29 Feb 2016 14:04:09 -0500 > From: Timothe Litt <[email protected]> > To: Paul Koning <[email protected]> > Cc: [email protected] > Subject: Re: [Simh] KS10 IMP documentation > Message-ID: <[email protected]> > Content-Type: text/plain; charset="windows-1252" > > On 29-Feb-16 13:05, Paul Koning wrote: >>> On Feb 29, 2016, at 12:59 PM, Timothe Litt <[email protected]> wrote: >>> >>> ... >>> I created a printer class driver layer for simh when I did PDF output for >>> all the emulators, but that went into a black hole of "more is not enough" >>> and did not find its way into simh/master. >> I looked at PostScript output for a printer, which is fairly easy and makes >> it possible to do non-ASCII characters if the particular machine needs >> those. In the end, I did it as an external program (small Python script) >> instead, but in SimH would certainly not be hard. PS has the advantage that >> it's easy to generate and easy to see what's going on, and it can either be >> printed directly, or converted easily to PDF. >> >> > PDF is an ISO archival standard and these days, more accessible than > PS. To do anything with postscript, you need to get add-on software - > usually ghostscript. Pretty much every PC, Mac and Linux box has a PDF > reader out of the box. Several web browsers have built-in PDF > interpreters. PDF supports non-ASCII characters. And PDF supports > embedding other media types. You can (and I did) support compression > and embedded images. > > Anyhow, that's what I picked. > > I did the work of generating PDF with green (or blue or ..) bar paper, > tractor feed holes, background logos, form sizes, overstrike, queuing to > a spool directory, appending, checkpointing, etc. I had an escape > sequence interpreter so anything not in the PDF character set (a > superset of ASCII) could be generated fairly easily from a SimH driver. > I provided translations for 32 character sets, from ASCII to Greek to > Technical. > > I integrated it into all the simulators - not just DEC. It didn't > preclude .txt output. But it became controversial for reasons not fully > understood - and I was unwilling to keep implementing non-core features > for specific host platforms. > > I had a lot of other pressures on my time. I gave up. I still think it > was a nice piece of work, but clearly the community didn't. > > Anyhow, the point is that it's feasible to build a class driver layer & > FWIW, my strong opinion is that for LPD bridges and any output formats, > that's the way to go. Of course, given my experience, you might want to > collect other opinions. Larry Baker US Geological Survey 650-329-5608 [email protected]
_______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
