Arash Esbati <arash <at>
https://www.google.com/url?q=http://gnu.org&source=gmail&ust=1788215723096000&sa=E>
writes:
> I think this is your call: Should we close this report since you can't
> reproduce the original issue?
Short summary: I could not reproduce either of the two originally
reported symptoms (the crash, or "always black-on-white" with the
default color method) -- but along the way I did reproduce a new,
distinct bug in the 'compatible color method, described in point 3
below. Details follow.
On the crash: I built a proper automated harness this time (real
interactive `emacs -Q`, not `--batch`, with `find-file` used exactly
once so `TeX-master` doesn't get renegotiated between runs) and ran
`preview-document` 8 times in a row on the minimal repro file in one
live session. No crash, and no error text in the Ghostscript output
across any of the 8 runs. So I still can't reproduce it under
controlled conditions, on the minimal file. Given that, and that I
also couldn't reproduce it originally on the ~30-page paper outside
of that one live session, I think closing is reasonable unless you'd
rather I try the ~30-page document through the same harness first --
that's the one variable I haven't controlled for yet, and it's the
only condition under which I actually saw it happen.
On the color adjustment, I have more concrete news, some good and
some new:
1. The default method (t / DELAYBIND) does work correctly for text.
I drove the real AUCTeX pipeline (not a hand-built gs invocation)
with a dark foreground/background matching my actual theme, and
checked the output pixels directly: the background comes out as
the exact requested dark color, with anti-aliased glyph text in
shades of the requested foreground. So the mechanism itself is
sound, at least in a single fresh session -- this matches what
your preview-dark.png showed. I still don't have an explanation
for why my original long-running session showed plain
black-on-white with this same (default) method; I could not
reproduce that failure in a fresh, minimal test. If it's
reproducible at all, it may need the same "long-running session"
or "real large document" condition as the crash, rather than
being a plain configuration issue.
2. Fraction bars (and presumably other rule-drawn marks -- sqrt
vinculum, \hline, over/underlines) do NOT get recolored, even
when the surrounding text does. I confirmed this at the pixel
level: the fraction bar's row stays essentially at the background
color while every other row in the same image is correctly
recolored. This lines up with what you already said ("the white
line color in the fractions... I think this is a won't fix"), and
I now have a concrete technical reason why: in the generated PDF,
the bar is drawn as a stroked line wrapped in its own q/Q
(graphics state save/restore) block, unlike the surrounding text,
which is not. My working theory is that gs's content interpreter
doesn't carry the patched default color through that particular
save/restore boundary the way it does for the un-wrapped text
draws, though I haven't traced that all the way into gs's own
source. I'm fine treating this as a won't-fix as you suggested,
just wanted to leave the concrete evidence here in case it's ever
worth revisiting.
3. New finding: the 'compatible method (the gs<9.27 fallback) is
worse than "doesn't recolor" -- with a non-default foreground
color it produces *no preview images at all*. pdflatex and
pdf2dsc both succeed, and Ghostscript itself reports finishing
with no visible error, but the temp directory ends up with just
the pdf2dsc-generated preview.dsc and zero PNGs. I confirmed this
against a control run with default (black-on-white) colors, which
produced all 4 images normally through the identical harness --
so it's specifically triggered by the color-patch path being
active. Since preview-pdf-color-adjust-method still documents
'compatible as the right choice for gs < 9.27, and nobody running
a gs that old would be hitting the newer PDF-interpreter issues
we've been discussing, this is probably low-impact in practice,
but it's a real, silent failure mode that seems worth its own bug
report rather than folding it into this one. Let me know if you'd
rather I file it separately.
So: I'd suggest closing the crash if you don't want me to try the
~30-page document through the fixed harness first, and I'm fine
treating the fraction-bar gap as a won't-fix given the mechanism now
has a plausible explanation. The 'compatible-method silent failure
seems like the one genuinely new, actionable item to come out of
this -- happy to file it separately if useful.
Best,
Mauricio
On Sun, Aug 30, 2026 04:48 PM, Arash Esbati <[email protected]> wrote:
> Mauricio Calvao <[email protected]> writes:
>
> > Thanks for looking into this, Arash.
>
> You're welcome.
>
> > I ran exactly the test you described:
> > [...]
> > then opened the same 8-equation repro.tex from my original report and
> > ran C-c C-p C-b.
> >
> > Result: I cannot reproduce the crash either, under these exact
> > conditions. All 8 equations previewed successfully -- Ghostscript
> > produced all 8 output images (pr1-1.png through pr1-8.png) with no
> > /typecheck or any other error, and the Ghostscript process exited
> > cleanly. I repeated this several times (fresh `emacs -Q` each time)
> > and got the same clean result every time.
> >
> > Versions are unchanged from my original report: AUCTeX 14.1.2, Emacs
> > 29.3, Ghostscript 10.02.1, Ubuntu 24.04.4.
>
> Ok, good news. And while we're at it: I have GS 10.07.1, can you update
> your installation?
>
> > I then also tried it in my actual day-to-day Emacs session instead of
> > a fresh `emacs -Q` -- long-running, dark theme (gruvbox-dark-soft),
> > AUCTeX/LSP/company etc. all already loaded -- to test the "warmed
> > session" hypothesis below. Same result: no crash there either, with
> > either 'compatible or the default t.
>
> I tried a dark-theme like this (I don't have gruvbox):
>
> (progn
> (package-initialize t)
> (package-activate 'auctex)
> (setq preview-pdf-color-adjust-method t)
> (setq preview-auto-cache-preamble nil)
> (package-activate 'doom-themes)
> (load-theme 'doom-one t) )
>
> What I see is again attached. I think this (mostly) the expected
> behavior. One thing missing is the white line color in the fractions.
> IIRC, this is a won't fix for various reasons.
>
> > Separately, while testing in my real dark-theme session I got a
> > concrete data point on the "Related observation" I mentioned in my
> > original report (previews being illegible against a non-default
> > theme). With `preview-pdf-color-adjust-method' set to t (the default,
> > and the documented correct choice for gs > 9.27), the generated PNGs
> > are still plain black text on a plain white background -- I checked
> > the raw pixel data (identify/convert histogram: dominant color
> > #FFFFFF, text #000000) and confirmed visually with a screenshot of the
> > buffer. This is despite Emacs correctly reporting my theme's colors
> > (foreground #ebdbb2, background #32302f via face-attribute on
> > `default').
>
> See above and the attachment. Again, I don't get the behavior above, or
> am I missing something?
>
> > So on Ghostscript 10.02.1, the DELAYBIND-based `/initgraphics' patch
> > in `preview-pdf-color-string' silently has no effect at all -- not
> > "wrong colors", just no color transfer whatsoever, for either t or
> > 'compatible. That lines up with the comment already in preview.el next
> > to that code, flagging DELAYBIND as a Ghostscript feature that might
> > get removed in future versions (associated with past security holes)
> > -- 10.02.1 looks like it may be past that point.
>
> I don't track GS development, but can you show a reference that
> DELAYBIND is about to get phased out? I see this[1]:
>
> 10.03.1) Almost all the "internal" PostScript procedures defined during
> the interpreter startup are now "executeonly", further reducing the
> attack surface of the interpreter.
>
> The nature of these procedures means there should be no impact for
> legitimate usage, but it is possible it will impact uses which abuse the
> previous accessibility (even for legitimate reasons). Such cases may now
> require "DELAYBIND", See DELAYBIND
>
> I read the above differently.
>
> > This is really a separate defect from the /typecheck crash this report
> > is about, so let me know if you'd rather I file it as its own bug
> > report instead of carrying it in this thread.
>
> I think this is your call: Should we close this report since you can't
> reproduce the original issue?
>
> > If it's useful, I can try to reproduce the crash again by (a)
> > previewing the same buffer multiple times in one session rather than
> > once from a fresh start, and/or (b) using the real ~30-page document
> > instead of the minimal repro, and report back. Let me know which you'd
> > find more useful, or if you'd like me to try something else specific.
>
> I think the best approach is to come up with something which can be
> reproduced by others as well, starting with 'emacs -Q'. So yes, please
> report back if can come up with a recipe for others as well.
>
> Best, Arash
>
> Footnotes:
> [1] https://ghostscript.readthedocs.io/en/gs10.07.1/News.html
>
>
_______________________________________________
bug-auctex mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-auctex
