On 26/06/2019 18:01, Ikumi Keita wrote: > Hi Chris, > >>>>>> Chris Liddell <chris.lidd...@artifex.com> 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 _______________________________________________ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel