Re: Possible problem with Gnus

[David Kastrup <dak@gnu.org>]

Richard Stallman <rms@gnu.org> writes:

>     > If there are bugs in the Postscript support, please start
>     > reporting them one by one.  This is a feature that is supposed
>     > to work, and if it doesn't, we should fix it.
> 
>     It is not a feature that is supposed to work.  From the code in
>     lisp/gs.el:
> 
> This makes it somewhat less urgent.  But we still want this feature
> to work.  We should start fixing the problems in it, even if we do
> so one by one.
> 
> To set an example, I will add -dSAFER to gs-options.
> 
>       The only platform on which the postscript device works in the
>     first place is X11.
> 
> That platform is more important than all the rest.
> While we do support Windows and MacOS, they should never
> weigh more in our decisionmaking than the GNU operating system.
> 
>     The sane thing to do is to serialize the whole GhostScript
>     operation to have at most one GhostScript process running, and
>     to not restart this process as long as images remain to be
>     rendered.
> 
> That does sound desirable.  However,
> 
>       For this to work, one has to stop passing the information
>     through an XPixMap but has to go through a file or pipe.
> 
> Using a pixmap is preferable, in general.  Why do you think
> using a single Ghostscript process is incompatible with using
> a pixmap?

Because the interface to GhostScript that is used for passing the
XPixMap Id and the respective sizes is queried just at the start of
GhostScript.  You can't change the size after GhostScript has
started, so if you want to use one GhostScript process, it may only
connect to a single XPixMap of fixed size.

At least that's what I remember from last taking a look at the matter.

>       In contrast, preview-latex first deals with on-screen images.
>     Once they are dealt with, it reverts to rendering the rest
>     off-screen.
> 
> That would be a good optimization to add.

Rendering off-screen material is actually not as much an optimization,
but an interactivity feature.  It means that once GhostScript is
through, scrolling through the file is not computationally expensive.

However, if some document has thousands of images, it would be saner
to render them just to disk in case you'll need them, but not burden
Emacs' memory with them unless one actually moves there.

If one wanted to fold a sizable chunk of the preview-latex concept
into the display engine, then the display engine would need to

a) be able to deal with general PostScript (multi-page) instead of
isolated EPS files
b) know which images belong to the same PostScript file, so that it
will render them together, reading the PostScript resources of the
file only once, like a PS previewer.

The off-screen rendering/caching might be restricted to just images
from a single PostScript file: savings are largest in that case.

But investing serious work of that kind for the rather special case
here would probably not be worth it unless one expanded the mechanism
to be able to deal with more general conversion processes, like
dvi->ps->png or gnuplot->png or stuff like that.  If one would really
want to immerse oneself into stuff like that, one would probably want
some more general image rendering/embedding mechanism.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum