modernize printing

[masinter]

make PDFs? Postscript to a file and then ps2pdf?
What about Unicode PDF?

from #348 on POSTSCRIPTSTREAM

save PRESS and INTERPRESS for history.

[nbriggs]

It should either make a Postscript file and leave further conversion to other formats for the user/OS/Print system, or make PDF directly. I don't think we need to add another dependency on a particular external program that may have a varying name, options, etc. when the host based print system is highly likely to already have that set up. Plus, many printers print Postscript directly, and automatically doing a ps2pdf, and then having to reconvert PDF to PostScript for the printer is silly.

[Anzus]

The problem is wider if you’re not on a Mac, as then you have to have ghostscript installed to get pstopdf. Perhaps create a LispUsers package that advises the hardcopy function to call ps2pdf, that could be extended for the appropriate shims for other OS’s as the users feel the need?

…

On Jul 28, 2021, at 9:40 PM, Nick Briggs ***@***.***> wrote: It should either make a Postscript file and leave further conversion to other formats for the user/OS/Print system, or make PDF directly. I don't think we need to add another dependency on a particular external program that may have a varying name, options, etc. when the host based print system is highly likely to already have that set up. Plus, many printers print Postscript directly, and automatically doing a ps2pdf, and then having to reconvert PDF to PostScript for the printer is silly. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#363 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACBP2DEUBT6KURAGJCVDUZLT2C5QXANCNFSM5BFQPZRA>.

[nbriggs]

I don't know that I'd do it by advising -- though there's a certain Interlispiness to doing that. What do PC programs generate by default for print-to-file output these days?

[masinter]

Windows supports print-to-PDF. PDF viewers are built into all the browsers and OSes. Modern users don't print on paper, and "print" is as modern as "dial" for phone numbers -- i.e., not.
It looks like a lot of work went into POSTSCRIPTSTREAM; converting to PDFSTREAM might be difficult.

This issue is a Wish List item. I don't want postscript files -- they're useless except for printing.
I want PDF files with Unicode text and reasonable XMP metadata, as a way of capturing TEdit file output and Lisp pretty-printed sources.

That would be handy if people want to read the Lisp sources and TEdit files they find in the repo without having to fire up a Medley. Or a medley "convert to legible form" service.

[masinter]

this is coupled with the desire to have some way to look at Lisp source files without having to install and fire up medley. Did medley do anything when you selected "Hardcopy" on the file browser menu for a Lisp source file?

[orcmid]

I want PDF files with Unicode text and reasonable XMP metadata, as a way of capturing TEdit file output and Lisp pretty-printed sources.

I concur. PDF is also nicely searchable, there are often internal links and cross-referencing, ahd you can set forward and back navigation for browsing and chasing links. There is also fairly nice control over page viewing size and other features.

I'm a bit dubious on the claim about many printers accepting PostScript directly.

I am baffled in another respect. There are probably text editors that have extensions for pretty-printing (Common) LISP and some might even reformat. Is that not an useful option?

PS: I just checked on extensions for Visual Studio Code, which is available on practically everything, and it has 4 extensions that I found immediately, plus one for Lispy. So highlighting and also reformating. I haven't dug deeper.

[orcmid]

I suppose this is related to Issue #590 also. I looked at Medley source file CLEVAL and clipped out CL:DEFUN. It was detected as Common Lisp (after I installed one of the extensions). The result is peppered with ACK STX and ACK SOH pairs (interpreted as UTF8

There was nolittle colorizing and it may be that the extension is expecting lower case for its dictionary of CL primitives, etc. I fiddled with it, without any concern about accuracy, to see how much the Common Lisp plugin presented things.

Is this the kind of treatment of interest? Please ignore the errors I introduced by touching up the file to this form.

[masinter]

• When it was a "Lisp machine" there was no other text editor to run.
• when you have and use one, the "file manager" system doesn't do well
• the Interlisp way is incremental development: LOAD the file you're working on, edit some functions and assign variables and things
• then you MAKEFILES or CLEANUP
  SAVEVM or SYSOUT if you want to stop for a while but aren't ready

if you want just to look at the files in a linux shell, use the "lsee" command from medley/scripts/.

[orcmid]

this is coupled with the desire to have some way to look at Lisp source files without having to install and fire up medley.

I was exploring that angle and the remark at #590 about being able to print out files whether for newbies or some other purpose. That's when I noticed that the GitHub files have ASCII/UTF8 C0 control codes in them. I see from the lsee shell script what those are.

I was not exploring reading on a terminal. I was interested in opening in a text editor where there is pretty-printing and also the prospect of saving/editing the plaintext.

I don't know why that is a terrible option. I appreciate that live composing is a feature. Why does one exclude the other now that Interlisp can be an application, not the machine.

[masinter]

I was tempted to turn this into a GitHub "DIscussion", since it's getting at the reason why anyone would care.

My understanding is that there were some experiments to couple emacs with Interlisp so you'd edit code in emacs as text.

I don't know how far they got. In addition to CHAT(SHELL) you could chat to emacs? Not sure.
lispusers-CHATEMACS.PDF

and (as of yesterday) there's a MIGRATION Lispusers package that translates at least one way to make Interlisp-managed files into files you'd want to see if you were an ordinary common lisp user. So this can be done. It's what Symbolics and LMI did. The only problem is that medley doesn't add much if that's your mode. The advantage was the time of the debug cycle.

Another problem with editing text is that people get attached to the formatting and the keywords and don't pay attention to the structure.

In Interlisp, a 'function' will grow and grow. It's more like building a spreadsheet. You don't design it -- you assemble it.

I think most Devops works this way now but missing most of the tooling.

[orcmid]

@masinter I was tempted to turn this into a GitHub "DIscussion", since it's getting at the reason why anyone would care.

+1 on Discussion

I've seen emacs, notepad++, and Visual Studio (Code) used in ways that shorten the rinse-repeat cycle and don't whipsaw developer focus so much. I have no insight into prevalence or effectiveness. These all have "ground truth" in files; I have no insight into devops. There are numerous (Inter)Lisp files in the medley repo and of course maiko is implemented via C Language files.

Gregor taught a MOOC on systematic program design that promoted test-driven-design (TDD) growth of functions (in DrRacket in that instance). It is a disciplined method with structural induction behind it (without identifying it as such -- I only identified it later when working on proofs in a different project).

Many different ways of working, varied fitness for purpose.

[D-Van-Buer]

I just wrote a very small C program that works much of like lsee except it produces printable postscript that looks similar to what Interlisp prints, doing appropriate font changes. I could offer to commit if is there is interest.

[masinter]

I just wrote a very small C program that works much of like lsee except it produces printable postscript that looks similar to what Interlisp prints, doing appropriate font changes. I could offer to commit if is there is interest.

that would be great. Not sure if it should go into the medley repo or a separate one? Or in maiko?
Does it go in releases? @Interlisp/core ? The medley repo is all processor/OS independent code while maiko has all the infrastructure for building for multiple os/cpu types.

maybe a separate maiko/utilities folder?

[masinter]

also some things you might not be aware of -- most Interlisp code assumes the character of XNS (Xerox Network Systems) but there is support for writing out source and text as Uniicode UTF-8. The encodings are the same for ASCII text. The distinction should be in the DEFINE-FILE-INFO expression at the beginning of the file (or a Common Lisp "mode line" comment at the head of the file? Not sure).

Also I recently made an update to 'lsee' in PR #889 which adds translations for _ to left arrow and ^ to up-arrow, because that is how they appear in most of the fonts we use in Interlisp sources and documentation. I notice that the postscript we get seems to have made the same substitutions (at least in the Loops manuals printed from TEdit.)

[nbriggs]

We don't have a place to put things like this yet -- the medley repo has scripts but no programs that need compilation, and the maiko repo has its own peculiar construction of a makefile from pieces depending on what you're building for, but no place where it makes sense to do a top-level make.

[masinter]

how about a new repo "Interlisp/utilities" then? lsee, restore-versions, repo-independent build yamls might fit there too

[nbriggs]

A new repo is fine -- what's the proposal for how you build and use things in there? Top level make file that recurses into subdirectories? Each utility is in its own directory with its own Makefile? CMake? Something else? (but NOT GNU autotools!) Do you make/make install? where does it install (/usr/local/bin?)

[pamoroso]

We eventually implemented PDFSTREAM, HCFILES, and HTMLSTREAM which address the requests of this issue. Since it was suggested to convert the issue to a discussion, if there are no objections I'll proceed with that.

Also, #1096 is a duplicate of this issue and if there are no objections I'll close #1096.