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

[David Kastrup]

address@hidden 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