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

[David Kastrup]

Ikumi Keita <address@hidden> writes:

> Hi Chris,
>
>>>>>> Chris Liddell <address@hidden> writes:
>> Right, sorry for the delay, as I said, that ended up being a much more
>> involved task than I'd anticipated!
>
> Thanks, the proposed fix works well on my side!  The generated image
> turns its color as expected.
>
>> 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.
>
> I tested the ghostscript source of 9.27 release with the three patches
> associated with the listed commits, on FreeBSD 12.0.  Though there was
> one rejection when applying the patches at gs_fonts.ps, I could manually
> recover the fail it since it was just straightforward.
>
>> 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.
>
> Attached is the change I used for preview-latex, for those who are
> interested.
>
> Chris, there is a possibility that we ask you (or the Ghostscript
> development team) to agree to transfer the copyright of the above
> PostScript code of several lines to Free Software Foundation.  Are you
> fine to agree if that really happens?
>
> To project admin of AUCTeX (especially David Kastrup): Could you please
> judge whether the PostScript code Chris provided above needs copyright
> assignment in order to incorporate into AUCTeX, and if so, provide
> instruction for him if he is fine to do so?
>
> (Ah, but now the message from David arrived.  Maybe he writes relevant
> PS codes by himself.)

Purely straightforward functional code without any significant degree of
creativity (so it will end up looking the same whoever writes it, given
the same information) does not have copyrightable elements anyway.  Of
course, that is the best kind of code you could be writing, so bad
programmers enjoy more copyright protection for their output than good
programmers do.

At any rate, I don't see that we need a copyright assignment for that
code scrap.  It would not have ended up any differently if I had written
it.  I actually have a hard time imagining how you could write it more
complicated than that.

With regard to dealing with the non-working -dDELAYBIND: that could end
up differently.  The knowledge about how -dDELAYBIND fails is not
copyrightable, but if the path from that knowledge to code avoiding the
failure is not as straightforward as the above suggestion was, the
situation could end up differently.

All the best

-- 
David Kastrup