Subject: Re: bug#39927: 12.2; preview-latex gs treatment off by one

From: David Kastrup <[email-masked]>
Date: Thu, 05 Mar 2020 16:42:02 +0100

[email-masked] 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