On 17/03/2025 11:49, Ikumi Keita wrote:
[ I added auctex-devel to Cc:]
> Thank you for your kind reply. To tell the truth, none of us AUCTeX
> developers, except David Kastrup, understands the detail of the usage of
> Ghostscript and PDF2DSC, and David isn't willing to maintain the
> interaction between Ghostscript (including PDF2DSC) and preview-latex
> anymore.
OK that's unfortunate, but it's what we have, so lets look forward.
> I am very sorry to tell that all I can do is to provide
> (1) sample pdf file
> (2) the command line with which we invoke pdf2dsc
> (3) the command line with which we invoke gs and the contents we inject
> as standard input to the invoked gs process, in order to generate
> pieces of png files from the pdf file.
> , if we are to follow your suggestion. Is that acceptable? I admit that
> such process will be very awkward and much tedious for your side because
> of my lack of understanding.
Well its certainly going to be hindered by my own lack of understanding :-)
What I had hoped was to do what David had said in the comment you
quoted; rework the whole interaction with Ghostscript. Obviously that's
not going to happen, so we'll have to try and work with what we have.
I definitely don't want to simply re-instate pdf2dsc.ps; that PostScript
program basically uses chunks of the old PDF interpreter, so it relies
pretty much on that interpreter being present. We replaced it with a new
implementation (in C instead of PostScript) in the 10.x series of
Ghostscript, and removed the old code entirely in (IIRC) 10.01. I'm
frankly astonished that the old pdf2dsc.ps program continues to work at
all, and I suspect it doesn't work properly, but the bits that don't
work haven't been noticed because they probably aren't used.
So I don't want to just reuse it; at the very least we'll need a new
PostScript program to produce the 'dsc' files. I can do that for you if
nothing else. I'd also want to rename the program because 'DSC' implies
Document Structure Convention and I've already had at least one person
confused because pdf2dsc didn't do what they expected it would from the
name. I'd suggest something like pdf2prvw.ps and call the output files
*.prvw or pdf2auctex or some such thing. Obviously that would mean some
changes at the AUCTeX end, but from what I've heard so far that doesn't
sound insurmountable. I think the biggest problem would be knowing
whether to use the old or new program, might have to think about that.
I can produce output from the old program, not least by going back to
the old 9.55.0 version of Ghostscript if necessary, so I don't need
that, but it might indeed help matters if you were to provide a sample
PDF file. Simply because we would be able to discuss it with confidence
that we are talking about the same thing.
I would very much appreciate any insight you can give me on point (3),
how the 'dsc' file is actually used. I had assumed that you were using
Ghostscript to do the preview, so generating PNG files surprises me, but
it might offer a means to improve/simplify the situation.
> Here is a quote from what David wrote:
> ,----[ https://lists.gnu.org/r/bug-auctex/2025-03/msg00017.html ]
> | It is comparatively easy to trigger Ghostscript to render
individual PDF
> | pages, so technologically there is no justification for what
> | preview-latex does here.
> |
> | The problem is that it would need to go back under the operating table
> | and get a separate communication module for talking with Ghostscript
> | about PDF files: right now it just talks about the pseudo PostScript
> | wrapper produced by pdf2dsc.
> |
> | Exacerbating this is that last time I looked there really was no
> | dependable API or documentation for this feat which is obviously not a
> | part of the PDF document standard itself (which details nothing about
> | _how_ to trigger rendering of PDF with a particular engine, let alone
> | interactively and out of order).
> |
> | In comparison, pdf2dsc has been remarkably stable and reliable as an
> | interface into page-wise rendering, and part of the reason is that the
> | Ghostscript maintainers themselves were responsible for keeping it
> | working for its limited purposes.
> `----
Well there's the problem, we aren't really prepared to keep doing that.
The code that is there works with the old PDF interpreter, but I'm not
sure it will work properly with the new interpreter, and looking forward
it's unlikely to continue working at all without effort from somebody
which we simply don't have the resources to do; it's not like there is
any real benefit for us to do so. The best we can reasonably do is give
you a new program which works with the new interpreter.
Ken
