Re: [AUCTeX-devel] [gs-devel] Asking help for preview-latex

[Chris Liddell]

On 26/06/2019 18:01, Ikumi Keita wrote:
> Hi Chris,
> 
>>>>>> Chris Liddell <address@hidden> writes:
>> We think we have a way to achieve what you need, but it relies on the
>> DELAYBIND feature which, unfortunately, was inadvertently broken in 9.27
>> (possibly, in truth, earlier than that).
> 
>> I thought this (DELAYBIND) was going to be a fairly easy issue to , but
>> it turns out to be decidedly not the case, and it's taking longer than
>> expected.
> 
>> NOTE: it's not a simple replacement of your current GS_PDF_ProcSet based
>> solution: it will mean a small change to how gs in invoked, and changes
>> to the Postcript you send to gs. We'll do our best to help you get the
>> changes done.
> 
>> The advantage is, this should be more secure and more stable for the
>> future (hopefully!).
> 
> Thank you very much!  We'll wait good news fairly hopefully :).

Right, sorry for the delay, as I said, that ended up being a much more
involved task than I'd anticipated!

First and foremost (and apologies for this), we can't do anything to get
this working in the 9.27 release. Your options are to use 9.26, use the
"in-development" code from our repo, or (on Linux systems) convince the
package maintainer to pick up the commits listed below.


So, I had the idea that you could replace your existing code with a
solution using a feature called DELAYBIND, and trying that out meant I
discovered that DELAYBIND was broken, and that's where most of my time
went on this.

This commit fixes DELAYBIND as best as I can test:
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=94cc50cf64

A second issue with my idea was to do with an internal detail of how the
PDF interpreter sets up initial conditions for a page, and that is
addressed with these commits:
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=47b1b7f971
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=5ef3a531d0

(the second because I forgot about a side effect of setcolorspace).

So, in essence, the idea is that you'll remove the stuff using
GS_PDF_ProcSet entirely. Add the option -dDELAYBIND to your gs command
line, include a suitable redefinition of initgraphics, then call
.bindnow, and continue as before.

The redefinition of initgraphics would look something like:

/initgraphics {
  //initgraphics
  /RG where {
    pop <R value> <B value> <G value> 3 copy rg RG
  } if
} bind def

So, that first calls the original initgraphics operator. It then checks
if the name "RG" is known to any dictionary on the dictionary stack
(which will only be the case when being called from the PDF
interpreter), and if that is the case, then set fill and stroke colors
as you require ("R/G/B value" being place holders for the "real" numbers).

After that, and before running any more Postscript or PDF, you'd call
the .bindnow operator.

I can't test all this in the context of your workflow, but I've tested
it with the example PDF you supplied, and I can change the color of the
objects.

I don't doubt you'll have follow up questions....


Chris