auctex-devel
[Top][All Lists]

## Re: [AUCTeX-devel] Try to colorize preview (was Re: Asking help for prev

 From: David Kastrup Subject: Re: [AUCTeX-devel] Try to colorize preview (was Re: Asking help for preview-latex) Date: Mon, 24 Jun 2019 11:57:43 +0200 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Ikumi Keita <address@hidden> writes:

> Hi Jean,
>
>>> I have not looked up in detail (I am still with gs 9.26, and besides I
>>> do not use that much the preview functionality -- hope that is pardonable),
>>> but this small tex file
>>>
>>> \documentclass{article}
>>> \AtBeginDocument{\RequirePackage{color}\pagecolor{yellow}\color{red}}
>>> \begin{document}
>>> $E = mc^2$
>>> \end{document}
>>>
>>> works as expected, hence it seems it is quite feasible to alter the PDF
>>> production as suggested by Ken.
>
>> Ah sorry for noise. Problem with fuller example actually using
>
>> \PassOptionsToPackage{active,tightpage,auctex}{preview}\RequirePackage[displaymath,floats,graphics,textmath,sections,footnotes]{preview}[2004/11/05]
>
>> is as I should have expected that the ccolor ommands outside
>> the display math mode are not executed.
>
> Thanks, I was trying similar approach.  The attached patch #1 (just
> adding initial TeX codes at execution of pdflatex) works only partially.
> Though the background turns its color as expected, the foreground color
> isn't affected.
>
> The situation changes by further modification in preview.sty with the
> attached patch #2, which uncomments two lines.  Together with the above
> patch #1, my intent of setting both the foreground and background colors
> are reflected in the outcome of preview-latex.
>
> However, these two lines in preview.sty (actually in preview.dtx) were
> commmented out at this commit:
> ----------------------------------------------------------------------
> 5dc76f79d0fff44794262037b93f0533af78f805
> AuthorDate: Mon Jan 20 00:09:00 2003 +0000
>
> (subsection{The internals}): comment out color
> setup.  That means that one might not be able to use color.sty for
> setting up fore/background color, but it will also mean that
> up inside of GhostScript.  In the long run, we will have to solve
> this differently.
> ----------------------------------------------------------------------
> If the situation of Ghostscript mentioned in the above commit message
> hasn't changed during this 16 years, the patch #2 would lose at some
> complicated situation.
>
> I hope that David comments on this issue.  In particular, I'd like to
> know, or to know to how to judge, whether "the initial colors set up
> inside of Ghostscript" still interfere with color.sty or not.

It's been so long ago that I did this stuff that I don't really remember
the details.  What may be the case is

forcing the loading of color.sty is heavy-handed, may bind the output to
a particular backend (there is, for example, dvipdf for generating PDF
from DVI, a valid option of further DVI processing) and may be
incompatible with other color options like using xcolor.sty (or whatever
it was called).

Also color.sty produces additional special codes that may interact with
typesetting.

Doing this at the Ghostscript level instead did not mess with the LaTeX
processing.

I am not sure whether searching in the bug mailing list will turn up the
problems that triggered going via this path.

--
David Kastrup