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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 39927 in the body.
You can then email your comments to 39927 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: candeb <at> free.fr
To: bug-auctex <at> gnu.org
Subject: 12.2; preview-latex gs treatment off by one
Date: Thu, 5 Mar 2020 13:47:42 +0100 (CET)

Hello,

Funny bug with preview-latex.  I use gs 9.50 with preview-pdf-color-adjust-method = t.

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.

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.

Possible solution : it **seems** that GS outputs GS<1> when it has treated an image, and GS> when it has, well, done I am not sure what.  So instead of just counting all prompts and just skip one as current code seems to do, I would suggest to ignore the GS> prompts.
The following code does this, and solves the problem (for me).
Cheers,

Itaï.


(defun preview-gs-transact (process answer)
  "Work off Ghostscript transaction.
This routine is the action routine called via the process filter.
The Ghostscript process buffer of PROCESS will already be selected, and
and the standard output of Ghostscript up to the next prompt will be
given as ANSWER."
  (while (and (< (length preview-gs-outstanding)
		 preview-gs-outstanding-limit)
	      (setq ov (pop preview-gs-queue)))
    (let ((queued (overlay-get ov 'queued)))
      (when (and queued
		 (not (memq ov preview-gs-outstanding))
		 (overlay-buffer ov))
	(let* ((filenames (overlay-get ov 'filenames))
	       (oldfile (car (nth 0
				  (nconc filenames
					 (list
					  (preview-make-filename
					   (format "pr%d-%d.%s"
						   (car preview-gs-sequence)
						   (cdr preview-gs-sequence)
						   preview-gs-image-type)
					   TeX-active-tempdir))))))
	       (bbox (aset queued 0
			   (or (and preview-prefer-TeX-bb
				    (aref queued 0))
			       (and (stringp oldfile)
				    (preview-extract-bb
				     oldfile))
			       (aref queued 0)
			       (error "No bounding box"))))
	       (snippet (aref queued 2))
	       (gs-line
		(format
		 "%s<<%s>>preview-do\n"
		 (if preview-ps-file
		     (concat "dup "
			     (preview-gs-dsc-cvx
			      snippet
			      preview-gs-dsc))
		   (format "%s(r)file cvx"
			   (preview-ps-quote-filename
			    (if (listp oldfile)
				(car (last oldfile))
			      oldfile))))
		 (if preview-parsed-tightpage
		     ""
		   (format "/PageSize[%g %g]/PageOffset[%g \
%g[1 1 dtransform exch]{0 ge{neg}if exch}forall]"
			   (- (aref bbox 2) (aref bbox 0))
			   (- (aref bbox 3) (aref bbox 1))
			   (aref bbox 0) (aref bbox 1))))))
	  (setcdr preview-gs-sequence (1+ (cdr preview-gs-sequence)))
	  (setq preview-gs-outstanding
		(nconc preview-gs-outstanding
		       (list ov)))
	  (aset queued 1 gs-line)
	  ;; ignore errors because of dying processes: they will get
	  ;; caught by the sentinel, anyway.
	  (condition-case nil
	      (process-send-string
	       process
	       gs-line)
	    (error nil))))))
  (when (not (string-match "\\`GS>\\'" answer))
    (let ((ov (pop preview-gs-outstanding))
	  (have-error (not
		       (string-match "\\`GS\\(<[0-9]+\\)?>\\'" answer))))
      (when (and ov (overlay-buffer ov))
	(let ((queued (overlay-get ov 'queued)))
	  (when queued
	    (let* ((bbox (aref queued 0))
		   (filenames (overlay-get ov 'filenames))
		   (oldfile (nth 0 filenames))
		   (newfile (nth 1 filenames)))
	      (if have-error
		  (preview-gs-flag-error ov answer)
		(condition-case nil
		    (preview-delete-file oldfile)
		  (file-error nil))
		(overlay-put ov 'filenames (cdr filenames))
		(preview-replace-active-icon
		 ov
		 (preview-create-icon (car newfile)
				      preview-gs-image-type
				      (preview-ascent-from-bb
				       bbox)
				      (aref preview-colors 2))))
	      (overlay-put ov 'queued nil))))))
    (unless preview-gs-outstanding
      (condition-case nil
	  (process-send-eof process)
	(error nil)))))






Emacs  : GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.11)
 of 2019-09-22, modified by Debian
Package: 12.2

current state:
==============
(setq
 AUCTeX-date "2019-10-30"
 window-system 'x
 LaTeX-version "2e"
 TeX-style-path '("/var/lib/auctex/emacs/"
		  "/usr/share/emacs/site-lisp/auctex/style"
		  "/home/begnac/.emacs.d/auctex/auto"
		  "/home/begnac/.emacs.d/auctex/style" "auto" "style")
 TeX-auto-save nil
 TeX-parse-self nil
 TeX-master t
 TeX-command-list '(("LaTeX" "%`%l%(mode)%' %t" TeX-run-TeX nil
		     (latex-mode doctex-mode) :help "Run LaTeX")
		    ("BibTeX" "bibtex %s" TeX-run-BibTeX nil t :help
		     "Run BibTeX")
		    ("View" "%V" TeX-run-discard-or-function nil t :help
		     "Run Viewer")
		    ("Index" "makeindex %s" TeX-run-index nil
		     (plain-tex-mode latex-mode doctex-mode ams-tex-mode
		      texinfo-mode)
		     :help "Run makeindex to create index file")
		    ("Clean" "TeX-clean" TeX-run-function nil t :help
		     "Delete generated intermediate files")
		    ("Clean All" "(TeX-clean t)" TeX-run-function nil t :help
		     "Delete generated intermediate and output files")
		    )
 )

Message #8 received at 39927 <at> debbugs.gnu.org (full text, mbox):

From: David Kastrup <dak <at> gnu.org>
To: candeb <at> free.fr
Cc: 39927 <at> debbugs.gnu.org
Subject: Re: bug#39927: 12.2; preview-latex gs treatment off by one
Date: Thu, 05 Mar 2020 16:42:02 +0100

candeb <at> free.fr writes:

> Hello,
>
> Funny bug with preview-latex.  I use gs 9.50 with preview-pdf-color-adjust-method = t.
>
> 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.
>
> 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.
>
> Possible solution : it **seems** that GS outputs GS<1> when it has treated an image, and GS> when it has, well, done I am not sure what.  So instead of just counting all prompts and just skip one as current code seems to do, I would suggest to ignore the GS> prompts.
> The following code does this, and solves the problem (for me).
> Cheers,

That doesn't seem right.  GS> means that Ghostscript is waiting for
input.  GS<1> means that Ghostscript is waiting for input and there is
one item left on its stack (which is where PostScript passes data
around).  I don't think that this should regularly be the case.

-- 
David Kastrup

Message #11 received at 39927 <at> debbugs.gnu.org (full text, mbox):

From: candeb <at> free.fr
To: David Kastrup <dak <at> gnu.org>
Cc: 39927 <at> debbugs.gnu.org
Subject: Re: bug#39927: 12.2; preview-latex gs treatment off by one
Date: Mon, 9 Mar 2020 13:11:58 +0100 (CET)

That doesn't seem right.  GS> means that Ghostscript is waiting for
input.  GS<1> means that Ghostscript is waiting for input and there is
one item left on its stack (which is where PostScript passes data
around).  I don't think that this should regularly be the case.

-- 
David Kastrup


[[[     Not sure if it is important, but I am using Debian, which sets preview-image-type to 'dvipng   ]]]


Well, I never pretended to understand the first thing about how gs operates, I am just making observations...
Here is the output of some debugging messages : printing the gs prompt and a directory listing for the preview dir.

Type ‘C-c C-l’ to display results of compilation.
locating previews...
Type ‘C-c C-l’ to display results of compilation.
GS>
("." ".." "preview.dsc")
GS>
("." ".." "preview.dsc")
GS<1>
("." ".." "pr1-1.png" "preview.dsc")
GS<1>
("." ".." "pr1-1.png" "pr1-2.png" "preview.dsc")
GS<1>
("." ".." "pr1-1.png" "pr1-2.png" "pr1-3.png" "preview.dsc")
GS<1>
("." ".." "pr1-1.png" "pr1-2.png" "pr1-3.png" "pr1-4.png" "preview.dsc")
GS<1>
("." ".." "pr1-1.png" "pr1-2.png" "pr1-3.png" "pr1-4.png" "pr1-5.png" "preview.dsc")
GS<1>
("." ".." "pr1-1.png" "pr1-2.png" "pr1-3.png" "pr1-4.png" "pr1-5.png" "pr1-6.png" "preview.dsc")
GS<1>
("." ".." "pr1-1.png" "pr1-2.png" "pr1-3.png" "pr1-4.png" "pr1-5.png" "pr1-6.png" "pr1-7.png" "preview.dsc")
GS<1>
("." ".." "pr1-1.png" "pr1-2.png" "pr1-3.png" "pr1-4.png" "pr1-5.png" "pr1-6.png" "pr1-7.png" "pr1-8.png" "preview.dsc")
GS<1>
("." ".." "pr1-1.png" "pr1-2.png" "pr1-3.png" "pr1-4.png" "pr1-5.png" "pr1-6.png" "pr1-7.png" "pr1-8.png" "pr1-9.png" "preview.dsc")

This was with preview-gs-outstanding-limit = 2.  With 5 and preview-image-type set to 'png I get the same general behaviour :
Type ‘C-c C-l’ to display results of compilation.
locating previews...
Type ‘C-c C-l’ to display results of compilation.
GS>
("." ".." "preview.dsc")
GS>
("." ".." "preview.dsc")
GS<1>
("." ".." "pr1-1.png" "preview.dsc")
GS<1>
("." ".." "pr1-1.png" "pr1-2.png" "pr1-3.png" "pr1-4.png" "pr1-5.png" "preview.dsc")
GS<1>
("." ".." "pr1-1.png" "pr1-2.png" "pr1-3.png" "pr1-4.png" "pr1-5.png" "preview.dsc")
GS<1>
("." ".." "pr1-1.png" "pr1-2.png" "pr1-3.png" "pr1-4.png" "pr1-5.png" "preview.dsc")
GS<1>
("." ".." "pr1-1.png" "pr1-2.png" "pr1-3.png" "pr1-4.png" "pr1-5.png" "preview.dsc")
GS<1>
("." ".." "pr1-1.png" "pr1-2.png" "pr1-3.png" "pr1-4.png" "pr1-5.png" "pr1-6.png" "preview.dsc")
GS<1>
("." ".." "pr1-1.png" "pr1-2.png" "pr1-3.png" "pr1-4.png" "pr1-5.png" "pr1-6.png" "pr1-7.png" "pr1-8.png" "pr1-9.png" "preview.dsc")
GS<1>
("." ".." "pr1-1.png" "pr1-2.png" "pr1-3.png" "pr1-4.png" "pr1-5.png" "pr1-6.png" "pr1-7.png" "pr1-8.png" "pr1-9.png" "preview.dsc")
GS<1>
("." ".." "pr1-1.png" "pr1-2.png" "pr1-3.png" "pr1-4.png" "pr1-5.png" "pr1-6.png" "pr1-7.png" "pr1-8.png" "pr1-9.png" "preview.dsc")
Mark set

So notwithstanding what GS thinks its prompts mean, it looks from where I am that I can take GS<1> for "image is ready".

Of course if you have a better solution / understanding of what is happening I am eager to learn.  In any case the bug I reported is real and this looks like a solution.

All the best,
Itaï.

Message #14 received at 39927 <at> debbugs.gnu.org (full text, mbox):

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: candeb <at> free.fr
Cc: 39927 <at> debbugs.gnu.org
Subject: Re: 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)]

Message #17 received at 39927 <at> debbugs.gnu.org (full text, mbox):

From: candeb <at> free.fr
To: Ikumi Keita <ikumi <at> ikumi.que.jp>
Cc: 39927 <at> debbugs.gnu.org
Subject: Re: bug#39927: 12.2; preview-latex gs treatment off by one
Date: Thu, 12 Mar 2020 09:51:14 +0100 (CET)

[Message part 1 (text/plain, inline)]

Hi Ikumi

I spent some time digging into the internals of preview-latex, even though I do not speak elisp wery well...

The crucial part happens inside preview-gs-transact, which gets called each time GS has written something to the standard output (usually  GS>  or  GS<1>)

As I wrote in a previous message, adding some debug prints to the beginning of preview-gs-transact shows that you need to count the number of GS<1> prompts in order to guess when a new file is ready.
Current code just counts all prompts, skipping one, so with two GS> prompts at the beginning it is off by one.

The attached patch, based on that observation, solves the problem entirely.

Again, as I said in all my previous messages, I DO NOT UNDERSTAND ghostscript, I am just making empiric observations regarding the correlation between what GS writes to stdout and what seems to happen.
These observations seem to be consistent regardless of the color compatibility option you choose or the number of files you feed into GS at a time (but only tested with 9.50)

Cheers,
Itaï

[0103-Improve-preview-gs-transact.patch (text/x-patch, attachment)]

Message #20 received at 39927 <at> debbugs.gnu.org (full text, mbox):

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: candeb <at> free.fr
Cc: Luke Lau <luke_lau <at> icloud.com>, "Braun, Michael" <braunm <at> mail.smu.edu>,
 39927 <at> debbugs.gnu.org
Subject: Re: bug#39927: 12.2; preview-latex gs treatment off by one
Date: Thu, 07 Jan 2021 21:17:10 +0900

[Message part 1 (text/plain, inline)]

Hi Itaï, Luke, Braun,

Sorry for late response. It seems that I managed to fix the bug of
preview-latex you reported before. I don't speak Postscript and the fix
is totally heuristic, but it simply works, at least for me.

The attached patch removes a newline in the middle of initial string
sent to ghostscript. This newline was interpreted as a delimeter as
ghostscript, thus ghostscript responded twice to the initial string, if
my speculation is right, which led to a spurious prompt from
ghostscript.

Could you please test whether this patch fixes the problem on your side
if possible?

Best regards,
Ikumi Keita

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

Message #23 received at 39927 <at> debbugs.gnu.org (full text, mbox):

From: "Braun, Michael" <braunm <at> mail.smu.edu>
To: Ikumi Keita <ikumi <at> ikumi.que.jp>
Cc: Luke Lau <luke_lau <at> icloud.com>, "candeb <at> free.fr" <candeb <at> free.fr>,
 "39927 <at> debbugs.gnu.org" <39927 <at> debbugs.gnu.org>
Subject: Re: bug#39927: 12.2; preview-latex gs treatment off by one
Date: Sat, 9 Jan 2021 19:46:40 +0000

Ikumi:

It does appear to have fixed the problem.  I am no longer getting the warnings.

Thanks for the patch.

Michael

> On Jan 7, 2021, at 6:17 AM, Ikumi Keita <ikumi <at> ikumi.que.jp> wrote:
> 
> Hi Itaï, Luke, Braun,
> 
> Sorry for late response. It seems that I managed to fix the bug of
> preview-latex you reported before. I don't speak Postscript and the fix
> is totally heuristic, but it simply works, at least for me.
> 
> The attached patch removes a newline in the middle of initial string
> sent to ghostscript. This newline was interpreted as a delimeter as
> ghostscript, thus ghostscript responded twice to the initial string, if
> my speculation is right, which led to a spurious prompt from
> ghostscript.
> 
> Could you please test whether this patch fixes the problem on your side
> if possible?
> 
> Best regards,
> Ikumi Keita
> 
> <patch>

--------------------------
Michael Braun, Ph.D.
Associate Professor of Marketing, and
  Corrigan Research Professor
Cox School of Business
Southern Methodist University
Dallas, TX 75275
braunm <at> smu.edu

Message #26 received at 39927 <at> debbugs.gnu.org (full text, mbox):

From: Ikumi Keita <ikumi <at> ikumi.que.jp>
To: "Braun, Michael" <braunm <at> mail.smu.edu>
Cc: Luke Lau <luke_lau <at> icloud.com>, "candeb <at> free.fr" <candeb <at> free.fr>,
 "39927 <at> debbugs.gnu.org" <39927 <at> debbugs.gnu.org>
Subject: Re: bug#39927: 12.2; preview-latex gs treatment off by one
Date: Sun, 10 Jan 2021 17:18:48 +0900

>>>>> "Braun, Michael" <braunm <at> mail.smu.edu> writes:
> Ikumi:
> It does appear to have fixed the problem.  I am no longer getting the warnings.

> Thanks for the patch.

> Michael

Thanks a lot!  I pushed the change into the git repository.

Regards,
Ikumi Keita

Previous Next

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