GNU bug report logs - #39927
12.2; preview-latex gs treatment off by one

Previous Next

Package: auctex;

Reported by: candeb <at> free.fr

Date: Thu, 5 Mar 2020 15:23:02 UTC

Severity: normal

Tags: fixed

Found in version 12.2

Done: Ikumi Keita <ikumi <at> ikumi.que.jp>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: candeb <at> free.fr
Cc: 39927 <at> debbugs.gnu.org
Subject: bug#39927: 12.2; preview-latex gs treatment off by one
Date: Thu, 12 Mar 2020 15:50:27 +0900
[Message part 1 (text/plain, inline)]
Hi Itaï,

>>>>> candeb <at> free.fr writes:
> Whenever generating previews, I get error messages for essentially all preview images, such as:
> « Cannot find image file ‘.../_region_.prv/.../pr1-1.png’ » 

> Then, one preview image (first one in document order, last one to be treated, if I understood things correctly) fails to load, just get a big blank square.
> Move the cursor a bit, and it loads as well.  Particularly annoying if you are just refreshing a single preview image and it fails to load.

I often (always?) have simiar experiences.  It seems that the attached
patch works as a workaround.  It is just a workaround, not a solution
because it does not suppress errors like
Cannot find image file ‘.../_region_.prv/.../pr1-1.png’
in *Messages* buffer at all.

Another workaround is to type C-l after you get blank rectangle.

> My diagnosis : in parsing the GS output, preview-gs-transact just
> assumes that some prompts from GS mean that an image has been treated.
> I **guess** the introduction of -dDELAYBIND could have added an extra
> such prompt, so now it assumes the image is ready before it actually
> is.  emacs complains it cannot be found.  Then when adding the next
> image to its overlay, emacs realises that the previous image is there
> now, and loads it, so in the end, it is only the last image to be
> loaded that is missing, but error messages are displayed for all.

I'm not sure whether -dDELAYBIND is relevant or not, but my guess is
similar with you.  This off-by-one behavior reminds me of a topic in
https://lists.gnu.org/archive/html/bug-auctex/2019-10/msg00015.html :
> Secondly, the file name on your command line is
> "bbb.prv/tmp821SQO/pr1-2.png" but the one in the error is
> "bbb.prv/tmp821SQO/pr1-1.png". So, clearly not the same file.
It seems that there is a discrepancy between the sequence numbers which
preview-latex expects and ghostscript actually produces.  I.e.,
when preview-latex expects that gs has produced pr1-1.png, gs acutually
produced nothing, when preview-latex expects that gs has produced
pr1-2.png, gs acutually produced pr1-1.png, and so on.

Unfortunately I don't understand the core of preview-latex, so I cannot
solve this problem completely.

Regards,
Ikumi Keita

[workaround (text/x-diff, attachment)]

This bug report was last modified 4 years and 156 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.