Ikumi Keita <ik...@ikumi.que.jp> writes: > Hi Jean, > >>>>>> jfbu <j...@free.fr> writes: >>> 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 > Author: David Kastrup <d...@gnu.org> > 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 > loading color.sty does not interfere with the initial colors set > 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 _______________________________________________ auctex-devel mailing list auctex-devel@gnu.org https://lists.gnu.org/mailman/listinfo/auctex-devel