[Simh] Simh Digest, Vol 145, Issue 124

[Larry Baker]

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, <simh-request at trailing-edge.com> <simh-request at trailing-edge.com> wrote:

> Date: Mon, 29 Feb 2016 14:04:09 -0500
> From: Timothe Litt <litt at ieee.org>
> To: Paul Koning <paulkoning at comcast.net>
> Cc: simh at trailing-edge.com
> Subject: Re: [Simh] KS10 IMP documentation
> Message-ID: <56D49629.6050004 at ieee.org>
> 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 <litt at ieee.org> 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
baker at usgs.gov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20160229/84e2d7cd/attachment.html>