Seriously, I think PostScript's predecessor Interpress and its successor PDF were more focused on "the rigid constraints of paper" and printed page and document structures than PostScript was.

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.

[...]