Applications are one thing (e.g. the way they took away Quark's iron-handed grasp on DTP).
But, then there are the standards.
For example, PDF.
The modern world would barely operate without PDF.
Maybe. But maybe people would have simply adopted other standards, like djvu.
- Thank you for the meeting, oh and please send me the djvu of your reports
- Oh I'd swear we already had this conversation and I had already sent them?
Some people still insist on using non-PDF, for example the Swiss tax office insists on some weird proprietary format[1], QDF made by some obscure company called Snapform. All their forms are in QDF format.
It introduces completely un-necessary friction into the process. Everyone knows they should have just used PDF. Instead of forcing people to install some reader software they will never use for any other purpose.
[1] https://www.estv.admin.ch/estv/en/home/anticipatory-tax/clai...
Adobe PostScript, invented by Warnock, was _the_ standard. It was the means by which an application could describe to the computer in the printer the layout of the page. (And later the compute resources in the printer got separated first into Raster Image Processors (RIPs) and later just part of printer drivers in the computers).
The development of PDF was driven by the need to resolve incompatibilities in PostScript implementations that had become the nightmare of graphics pros in the early 90s. It was not uncommon to have to use random software to convert one PS file to another PS file which could be understood by the RIP owned by a given print shop.
Quark was built on the infrastructure enabled by PostScript in the first place.
Edit to add: possible confusion - RIPs were primarily used to generate super high res output on film used for lithographic plates, but they were enabled by the standardization around PostScript for driving laser printers.
PDF was great when most documents needed to be printed, so sending say an invoice to someone you could ensure their printed copy was the same as your printed copy.
PDF in "modern" world, where printing is less important and really should be sent to the dust bin if history. PDF has become a complex web of security problems, screen compatibility problems, and various other things including the complex web of converters to take PDF's and make them back into something editable / usable.
We need a replacement for PDF, and let PDF go away along with the printer
If you do any kind of business at all, especially the accounting side of things, printing is still a hard requirement and PDF makes all that practical.
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.
Actually PDF still rules the roost.
Any professionally printed thing you see, whether as small as a humble corporate business card, or as large as a billboard will have been provided to the print shop as a PDF.
In the past, you would have had to send the DTP file and all the accompanying assets, including the font if you were using a non-standard font.
Now you just send the print shop a PDF. Job done. Its a win-win for both parties.
What are these? Adobe provides a large amount of value to the graphics industry and charges a fee for that. People buy it if they want or don't if they don't. I fail to see any rent seeking (seeking to increase their own wealth without creating any benefits or wealth to the society).
But from the day it was announced I have always thought postscript is completely backwards.
It's not bad, it's just drawn that way.
The Shape of PSIBER Space: PostScript Interactive Bug Eradication Routines — October 1989:
https://donhopkins.medium.com/the-shape-of-psiber-space-octo...
This when receiving a link to a pdf on your phone the natural action is to ignore it and do something else.
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.
[...]
<https://en.wikipedia.org/wiki/Brian_Reid_(computer_scientist...>
https://freecomputerbooks.com/PostScript-Language-Program-De...
https://freecomputerbooks.com/Thinking-in-Postscript.html
https://news.ycombinator.com/item?id=28115946
>Glenn Reid wrote a PostScript partial evaluator in PostScript that optimized other PostScript drawning programs, called "The Distillery". You would send still.ps to your PostScript printer, and then send another PostScript file that drew something to the printer. The first PostScript Distillery program would then partially evaluate the second PostScript drawing program, and send back a third PostScript program, an optimized drawing program, with all the loops and conditionals unrolled, calculations and transformations pre-computed, all in the same coordinate system.
https://news.ycombinator.com/item?id=19751161
>Around 1990, Glenn Reid wrote a delightful original "Font Appreciation" app for NeXT called TouchType, which decades later only recently somehow found its way into Illustrator. Adobe even CALLED it the "Touch Type Tool", but didn't give him any credit or royalty. The only difference in Adobe's version of TouchType is that there's a space between "Touch" and "Type" (which TouchType made really easy to do), and that it came decades later!
https://news.ycombinator.com/item?id=19882301
>Brian's brother Glenn Reid was also very active in the PostScript world, he worked for Adobe (Illustrator), Apple (iMovie) and Fractal Design (Painter, Dabbler, Poser), and NeXT (Interpersonal Computing).
Brian Reid also published the Usenet Cookbook, maps of Usenet in PostScript, and wrote the story about "The Mother of All Grease Fires" that almost happened outside of where he worked at DECWRL (DEC Western Research Laboratories in Palo Alto).
https://milk.com/wall-o-shame/bucket.html
https://en.wikipedia.org/wiki/Brian_Reid_(computer_scientist...
I think I was vaguely aware of his work on Scribe though that had slunk off into dark recesses of my brain (which is to say, most of it). Given my interests in documents and their specification & management, Scribe's been something I've meant to look at more closely, so this is a handy reminder, and I appreciate the further context.
<https://archive.org/details/interpresssource0000harr/page/2/...>
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.