What a data source procedure allocates stays counted: only the sample planes,
the decoder's copies of the strings a procedure returns, and the split buffers
of an interleaved masked image stop counting once the image is decoded.
An image over the pixel cap was left out without reading its data, so
the program went on to read that data as PostScript and the file failed
to open (Ghostscript's eps2write writes a page with a large inline image
this way). The data is now skipped: the filters that find their own end
(ASCIIHexDecode, ASCII85Decode, SubFileDecode) read the file up to it,
without decoding what they pass.
The count of a SubFileDecode filter bounds what it passes through, not
what it allocates, but the reader refused counts over 4 MiB as a
rangecheck. Ghostscript's eps2write files read each content stream with
currentfile Length () /SubFileDecode filter, so a page whose stream is
longer than 4 MiB failed to open.
The sample planes an image is decoded from, and the strings a procedure
data source hands back to fill them, are freed once the image is
decoded, so they stop counting against the 1 GiB budget then; the pixels
kept still count. A file of many images whose procedure returns one
large buffer each time no longer runs out of budget.
`eexec` dropped its file operand and skipped the encrypted part of a
font program to `cleartomark` in the program's own file. With
`currentfile eexec` inside a file run with `cvx exec`, the program goes
on in that file, so the skip searched the outer file instead and failed
or skipped the wrong text. Ghostscript's eps2write runs each embedded
Type 1 font program that way, so an EPS with one did not open.
`eexec` now skips in its operand, through the same file reading as the
other data operators: the program's own file or the file being run. A
string operand skips in the file being read, as before.
A filter over `currentfile` waits until it is first read, and it took
its data from whichever file was running by then. One made over the
program's own file and first read inside a file run with `cvx exec`
read that file instead, and one made over a file being run, first read
in a file that one runs, read the inner file. The pending stream now
records the file it was made over (a chained filter inherits it), and
`materialize` decodes from that file.
A file run with `cvx exec` was read whole and run as a separate
program, while `currentfile` stayed the outer EPS. The PLRM has
`currentfile` return the topmost file being run, positioned after the
last token read. Ghostscript's eps2write runs each page's content and
each Type 3 glyph from a SubFileDecode filter, and its `ID` reads the
inline image's samples through `currentfile`, so they were read from
the outer file and then ran as program.
A file being run is now read object by object from its own data, and
while it runs it is `currentfile`. A filter made over it waits to
read, as one over the program's own file does, so it starts where the
program is when the filter is first read.
Don Omondi