On 17/03/2025 13:16, David Kastrup wrote:
> The interaction with GhostScript involves "please render now page xxx
> into a PNG file". This interaction is done in a pipe, the order is not
> known in advance but depends on the viewing behavior of the user.
OK but....
> pdf2dsc solves the task of splitting the PDF processing into one
> per-document block of resources that are loaded in advance and into
> per-page rendering instructions.
>
> Th bulk of this is essentially guaranteed to be stable by how DSC is
> defined as an interoperability standard.
So if I understand this correctly, you start up Ghostscript and leave it
running. You then split up the 'dsc' file into 'setup', 'trailer' and
'per page' sections. You then send the 'setup' to Ghostscript via stdin,
to initialise the PDF interpreter with the specific PDF file.
You then run each 'page' section, as required, in the same way.
Finally you run the 'trailer' section. Presumably you also send a 'quit'
to Ghostscript to close it.
> Last time I looked (admittedly quite some time ago), I have not found
> anything in GhostScript that provides similar (and documented!)
> stability for PDF processing of individual pages efficiently and in
> dynamically determined order.
The scripting of the PDF interpreter from PostScript is documented:
https://ghostscript.readthedocs.io/en/latest/Language.html#postscript-operators-interfacing-to-the-pdf-interpreter
The old code was neither documented nor stable. As you said previously
(quoted by Ikumi), you basically relied on the Ghostscript maintainers
to do that job for you. I'm afraid we can't maintain that for you any
longer, we simply don't have the resources to do so.
I see several approaches:
1) Simplest of all; bundle the old pdf2dsc.ps program with AUCTeX
instead of with Ghostscript and continue to use it.
2) Someone at AUCTeX modifies the preview program so that it runs a new
Ghostscript instance to produce a PNG file every time the user demands a
page.
3) Somebody at AUCTeX learns enough about scripting the Ghostsscript PDF
interpreter, and the preview application of AUCTeX, to modify the
preview program to generate the required PostScript to control the PDF
interpreter.
4) I can produce a new PostScript program to produce a 'dsc' file which
is broadly the same as the one you are currently using, but contains the
correct scripting code as opposed to the old code in the current 'dsc'
file. There is much more likelihood of this remaining stable, and
supported, than the old code, which was never stable and is now not
supported.
Of these:
1) Is probably not going to be popular since it will shift maintenance
of that old program to AUCTeX rather than Ghostscript. Without David I
doubt anyone else will be able to maintain this, and I very strongly
suspect it would bit-rot.
2) is likely to be somewhat slower than the current implementation. On
the other hand it is robust and very stable.
3) Doesn't seem likely, no volunteers to take on the rewrite.
4) If I do this then there will have to be some changes.
The entire pdf2dsc program will need to be rewritten because what's
there right now isn't sustainable (the reliance on the old PDF
interpreter isn't likely to keep working). In order to do that I'm going
to need to know what parts of the 'dsc' output AUCTeX actually needs;
comments as well as functional PostScript, because I see some slightly
odd comments in there which look important (the media names). I presume
the %%Pages comment is used, what about the %%PageBoundingBox and
%%Orientation comments ? What about the use of DELAYSAFER ? I'm not keen
on keeping that unless there's an awfully good reason for it.
I would also want to rename the pdf2dsc.ps program because I really
don't like the fact that it can be confused with prodicing a real DSC
PostScript program, such as ps2write would do. I'd be happy to talk
about what to rename it to, I've only got some loose ideas; as long as
it doesn't look like it will produce something useful generally I don't
mind what it is called.
In a similar vein I'd want to add comments to the 'dsc' file
describing (briefly) the purpose of the file so that it can easily be
distinguished from a real DSC PostScript program.
The 'preview' program is also going to need to call Ghostscript with
the relevant permissions flags for each program (the 'dsc'
file-producing program and the relevant 'dsc' program portion; the
'setup') because these will both need to be able to open the relevant
files. But I assume this must be done already, somehow, or it is using
-dNOSAFER which is really not a great idea.
A lot of point 4 would probably be covered by Ikumi's offer to tell me
how the preview program currently communicates with Ghostscript, but
perhaps David could short-circuit it if he happens to already be aware
of how this works and what the preview program requires to be present in
the 'dsc' file ?
Ken
