Re: [AUCTeX] Problem with preview-latex and ghostscript in suse 10

[David Kastrup]

[Another copy since the last one was to a private message]

MrJ Man <address@hidden> writes:

> On Tuesday 10 October 2006 14:53, you wrote:
>
>> It is _definitely_ a bug in the Omega fonts.  I recommend that you do
>> the following: use
>> M-x set-variable RET preview-fast-conversion RET nil RET
>> This will make all graphics be created in their own, single EPS file.
>> Then run C-c C-p C-d as this will make only those graphics fail that
>> contain the font(s) in question.  It will be the conveniently the case
>> that all other EPS files will get deleted from the temporary
>> directory.  Try tracking down the fonts in question as good as
>> possible, then send a bug report to the author of the fonts.
>>
>> The next release of preview-latex will ignore such errors.  This is
>> actually not a good thing to do, but AUCTeX central is not the
>> right institution to do the debugging and take the blame for other
>> people's bad PostScript code.
>>
>> You will be glad to hear that your example works perfectly at my
>> site now (I actually had to do another fix for the parsing of error
>> messages).
>
> It took a while to respond as internet access was
> unavailable for about a week. Before that I tried all
> the suggestions you give and even learned some 
> postscript in order to pinpoint the cause of the
> problem. While the problem may be with the fonts as
> you describe, there are some facts that make me think
> otherwise. I turned the call from preview-do (whose
> function I do not understand) into an exec call, and
> now about half the equations appear normally while the
> gs process is hung in the background and all temporary
> files have been deleted! (The other half of the
> equations is stuck with the working man icon). I doubt
> that the problem is with the fonts, as I can input all
> the postscript commands individually into the
> ghostscript command prompt and the showpage output is
> the correct one (i.e."{DELAYSAFER{.setsafe}if}stopped
> pop/.preview-BP currentpagedevice/BeginPage get dup
> null eq {pop{pop}bind}if
> def<</BeginPage{currentpagedevice/PageSize get dup 0
> get 1 ne exch 1 get 1 ne or{.preview-BP gsave 0.184314
> 0.309804 0.309804 setrgbcolor clippath fill 0.333333
> 0.419608 0.184314 setrgbcolor false setstrokeadjust 3
> setlinewidth clippath strokepath matrix setmatrix true
> {2 index{newpath}if round exch round exch moveto pop
> false}{round exch round exch
> lineto}{curveto}{closepath}pathforall pop fill
> grestore 0.960784 0.870588 0.701961
> setrgbcolor}{pop}ifelse}bind/PageSize[1
> 1]>>setpagedevice
> (_region_.prv/tmp3087Cmw/preview.005)(r)file cvx exec"
> shows the correct output correctly coloured).

That is not the problem.  I never claimed that the input did not
produce proper output.  What I said is that it messes up the
PostScript stack.  That means that your next prompt will be
GS<1>
instead of
GS>
and it also means that
pstack
will produce output.

preview-latex previously interpreted this as things gone awry since it
could not guarantee that its own data on the stack was in a useful
state when it was messed up like that.  However, its own data is now
preserved using the .runandhide operator (available since Ghostscript
6.54), so it is possible to continue usefully even in the presence of
junk on the stack.

> one more thing that may support your opinion is that
> dvips has problems with Fontographer created fonts
> (http://www.radicaleye.com/dvips.html), which is the
> case here.
> Note: All the above were done in "slow" mode
> (preview-fast-conversion is set to nil), "fast" mode
> fails completely.
>
> What do you think?

Since loading the PostScript preamble data is already sufficient for
leaving the stack in a non-empty state, I think that the fonts are
buggy.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum