John Warnock has died

That is provably false, lots of businesses have gone paperless, and all (at least for the US) government agencies, courts, etc all fully accept erecords, many preferring it.

What I've found over going on three years using a large-format (13.3") e-ink tablet, however, is that PDFs oriented toward documents from roughly octavo to A4 / US Letter formats is what I strongly prefer to free-flowing formats, most especially HTML, but also ePub, so long as the PDFs are sensibly formatted.

Free-flowing formats end up requiring scolling, critical elements (tables, graphics, and images) frequently span viewport boundaries requiring repositioning, and font choices and rendering are often poorer than for PDFs.

It turns out that book and standard paper formats evolved toward the sizes we're accustomed to because they suit the ergonomics of reading and handling well. Mobile phones' core constraint is to fit into a pocket or purse, which tends to be smaller than a full-form book or magazine. It's not so much that PDFs are ill-suited to them as that mobile phones are poor formats for reading full stop.

Yes, PDFs can be poorly formatted and all that jazz, but so can HTML docs (and far more frequently), or ePubs. My principle remaining complaint is that tools for organising and managing a substantial electronic document library are ... exceedingly poor, in most cases. Though that's independent of the document format used.

With NeWS, instead of paper, we drew on overlapping arbitrarily shaped nested scaled clipped canvases, and never used the "showpage" operator or DSC (Document Structuring Conventions) or EPS (Encapsulated PostScript) comments when using PostScript to draw trees of user interfaces components (like Open Look and PSIBER) and interactive zooming applications and visualizations (like the drawing editor in HyperLook, and the zooming scrolling animated SimCity maps and sprite overlays and graphs).

PDF is more constrained and document/page structure focused that free form PostScript even with DSC/EPS, as were Interpress and JaM.

https://en.wikipedia.org/wiki/Document_Structuring_Conventio...

https://en.wikipedia.org/wiki/Encapsulated_PostScript

I always thought it was a bold move to name a page description language for laser printers "JaM" (the predecessor to Interpress).

Brian Reid touched on (or rather dove deep into) it when he described the different approaches JaM and Interpress and PostScript had to structure and semantics. The whole article is fascinating, but I'll quote the relevant parts:

https://www.tech-insider.org/unix/research/1985/0301.html

>From: Brian Reid <reid@Glacier>

>Posted: Fri Mar 1 19:08:05 1985

>Subject: PostScript and Interpress: a comparison

[...]

>There is, however, a crucial difference between the PostScript and Interpress naming schemes that makes them very different, and makes impossible the above-mentioned imagined compiler to translate PostScript into Interpress. That difference is best understood as a semantic difference, and will be explained in the next section.

>Returning to syntactic issues, an Interpress file has what is called "static structure" or "lexical structure". This means that you can look at an Interpress file and make structural assumptions about what you find there. For example, an Interpress file is defined to be a sequence of "bodies"; each body is a sequence of operators and operands. The first body is the "preamble", or setup code; all following bodies correspond to printed pages. If an Interpress file has 11 bodies, then it will print as 10 pages.

>By contrast, a PostScript file has no fixed lexical structure; it is just a stream of tokens to be processed by the interpreter. PostScript prints a page whenever the SHOWPAGE operator is executed. If a PostScript file contains a loop from 1 to 10, with a SHOWPAGE operator inside the loop, then it will print 10 pages even though there is only one actual call to SHOWPAGE in the file. However, since PostScript is a textual language, and since it has a "comment" facility like the C /..../ or Pascal {...}, it is possible for the creator of a PostScript file to represent whatever additional information is desired. It is a slight misnomer to call this a comment facility, because the normal use of the word "comment" in programming languages implies that the contents of the comment are irrelevant. PostScript comments are irrelevant in the sense that they do not affect the image produced by a PostScript file, but they do convey machine-readable information about the structure of the document.

>A PostScript client is free to choose any structuring scheme that he wants, and the tool that he has available to implement this structuring scheme is the PostScript comment. There is a particular "standard" structuring convention documented along with PostScript by which page boundaries and other lexical information can be marked. A PostScript file that follows that convention is called a "conforming" file, but it is a convention and not a rule; the printed image produced by a nonconforming PostScript file will be identical to that produced by the equivalent conforming PostScript file. Conversely, the structure of a PostScript file, as represented by the structuring convention, is completely independent of the appearance of the page images--the actual PostScript text appears to be a series of comments as far as the structuring systems are concerned.

>The technique of mixing two different languages in one file, so that a processor for one language sees the text of the other language as comments, is not new. Perhaps the most widely-known instance of this scheme is Don Knuth's "WEB" system, in which Pascal and TEX are woven together in such a way that the Pascal program looks like a comment to the TEX interpreter and the TEX source looks like a comment to the Pascal compiler.

>This absence of fixed lexical structure in PostScript is a two-edged sword. On the one hand, it offers more flexibility in creating page images, especially repetitive ones; on the other hand, it provides more opportunities to make mistakes.

[...]

>An Interpress file consists of a series of bodies. Each body is executed completely independently of each other body. In particular, at the beginning of each page body, the execution environment is restored to the state that it had at the end of execution of the preamble, so that each page body is executed as if it were the only page in the document. There is absolutely nothing that the code in one Interpress page can do that will have any effect on the execution of the code in any other Interpress page, and the Interpress language guarantees that independence. This permits, for example, the pages to be executed or printed in any order, front to back or back to front, or in folios of 16 pages at a time, with complete confidence that the appearance of the pages will not change.

>By contrast, a PostScript file has no static structure, so there is no convenient place to build automatic firewalls. PostScript provides, instead, two pairs of operators by which a PostScript user can build his own firewalls wherever he wants them. There is an operator called SAVE, and another operator called RESTORE. The RESTORE operator restores the execution state of the machine back to what it was when the last SAVE operator was executed. Thus, if a PostScript user wants to have pages that are firewalled against each other, then he puts a SAVE operator at the beginning of the page and a RESTORE operator at the end of the page. If the PostScript user wants to play tricks, and build PostScript files that do bizarre things with the execution state between pages, he is free to do so by leaving out the SAVE and RESTORE.

>By now you can probably see the fundamental philosophical difference between PostScript and Interpress. Interpress takes the stance that the language system must guarantee certain useful properties, while PostScript takes the stance that the language system must provide the user with the means to achieve those properties if he wants them. With very few exceptions, both languages provide the same facilities, but in Interpress the protection mechanisms are mandatory and in PostScript they are optional. Debates over the relative merits of mandatory and optional protection systems have raged for years not only in the programming language community but also among owners of motorcycle helmets. While the Interpress language mandates a particular organization, the PostScript language provides the tools (structuring conventions and SAVE/RESTORE) to duplicate that organization exactly, with all of the attendant benefits. However, the PostScript user need not employ those tools.

>Before taking a stand on this issue, you must remember that neither Interpress nor PostScript is engineered to be a general-purpose programming language, but rather to be a scheme for the description of page images, so it is not necessarily valid to apply programming language lore to these two systems.

[...]