Ikumi Keita <[email protected]> writes:
>>>>>> Ikumi Keita <[email protected]> writes:
>> I was just thinking to immigrate to the new code using DELAYBIND, and
>> announce the user to install patched gs-9.27 if in hurry. But it might
>> be a good idea to introduce a new user option to choose between
>> (1) No color transfer, "black on white" appearance
>> (2) New code
>> for the case preview-latex uses PDF backend. Both have own
>> disadvantage, but at least they can avoid errors with customized
>> foreground color of emacs.
>
> How about the attached patch?
>
> I'm not sure whether I'm doing right with respect to suppressing fg/bg
> colors in `preview-gs-color-string', in the above case (1). I don't
> understand what role "mask" and "border" play here, so I suppressed only
> "fg" and "bg" parameters. Maybe I should disable
> `preview-gs-color-string' altogether in the case (1).
>
> This patch brings a drawback for users who customize the background
> color of Emacs and use default foreground color, with unmodified
> gs-9.27. In that case, the background color of the generated images
> will just be white and no longer match with Emacs.
I don't think that the drawback is necessary: in contrast to a working
DELAYBIND, it is easy to test for existence of the PDF dictionary at
runtime and use it if available.
The test would be something like
/GS_PDF_ProcSet where { pop [put old code here] } if
--
David Kastrup
_______________________________________________
auctex-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/auctex-devel
