On 17/03/2025 15:20, David Kastrup wrote:
>> 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
>
> And how long is that going to be working in the same manner? In
> contrast to interfaces decreed by Adobe, there has been considerable
> fluidity in the operators defined by Ghostscript.
Well yes, we feel free to make undocumented non-standard operators work
the way we want them to.
>> The old code was neither documented nor stable.
>
> The code not. The DSC format very much so in effect.
Can I make it clear that I have at no point been talking about the DSC
specification. DSC is nothing more than a set of conventions describing
how a file is structured, and some comments it must provide, in order to
allow some re-ordering.
The point I keep trying to make is that the code in the file is utterly
non-standard, it won't work on anything except Ghostscript. Which makes
calling it a DSC-conformant file misleading. I have had people who have
been misled into thinking what they have produced is a DSC PostScript
program they can use elsewhere.
So I want to get away from calling it DSC, I don't particularly care
what it is called, provided it isn't misleading, and the content isn't
really important.
> We had a number
> of headaches over the years as Ghostscript changed file file access
> safety, various operators and stuff, all of that related to PostScript
> interpreter operation. We never had any additional problem with PDF as
> far as I remember: DSC stayed workable as the PDF-specific access
> method.
Well I guess I'm sad that our obligation to add security to a language
which was designed without any security at all have resulted in problems
for you. If it's any consolation, they were considerable headaches for us.
>> 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.
>
> How often would that have to be amended in future?
My crystal ball is out for repair right now, but I would suggest not
often, for the simple reason that these are basic to the functioning of
the PDF interpreter when called from Ghostscript.
>> 3) Doesn't seem likely, no volunteers to take on the rewrite.
>
> The problem is that judging from previous experience with Ghostscript
> development, this would not be a one-time task.
Well nothing ever is, is it ? On-going maintenance is part of the deal.
The problem here is that you want us to take on that task.
> This is then employed in the following manner:
I don't see from this how the initial header is set up, this appears
only to access individual pages.
> (defun preview-gs-dsc-cvx (page dsc)
> "Generate PostScript code accessing PAGE in the DSC object.
> The returned PostScript code will need the file on
> top of the stack, and will replace it with an executable
> object corresponding to the wanted page."
> (let ((curpage (aref dsc page)))
> (format "dup %d setfileposition %d()/SubFileDecode filter cvx"
> (1- (car curpage)) (nth 1 curpage))))
>
> This works the same whether or not the "PostScript" file is generated
> with dvips or with pdf2dsc .
Well, I would want to get away from DELAYSAFER, so I'd prefer to have
the permissions sent as part of the 'dsc' file creation, and when
setting up the initial Prolog from the 'dsc' file.
> The safety management has been a moving target for a number of years but
> has been comparatively stable for decades now. Essentially everything
> is setup and opened in advance, then safety is switched on.
Yeah, I don't like that, presuming that's what DELAYSAFER is all about.
I suppose we could live with it.
Ken
