From: Andy Tai <atai@atai.org>
Cc: Andy Tai <atai@atai.org>, monnier@iro.umontreal.ca, emacs-devel@gnu.org
Subject: Re: Possible problem with Gnus
Date: Sat, 22 May 2004 20:46:58 -0700 (PDT) [thread overview]
Message-ID: <20040523034658.74396.qmail@web50908.mail.yahoo.com> (raw)
In-Reply-To: <E1BP3yb-0007nO-Vt@fencepost.gnu.org>
Hi, I would be glad to develop such an interfce; I
believe ghostscript should have most infrasturcture in
place already. I cannot promise on a time fr
Thanks,
Andy
--- Richard Stallman <rms@gnu.org> wrote:
> Andy, we have been talking about problems in Emacs
> code
> to display postscript in the middle of a document.
>
> > 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.
>
> I think the solution for this is to make a new
> interface
> to allow Emacs to specify the pixmap to an existing
> GhostScript
> process when reusing it for another image.
>
> Andy, can you implement such an interface for Emacs
> to use?
>
> > 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.
>
> That makes sense. Can that be done easily with
> reuse of a
> single GhostScript process, with the existing
> GhostScript features?
> If not, what new feature do we need?
=====
Andy Tai, atai@atai.org
Free Software: the software by the people, of the people and for the people! Develop! Share! Enhance! Enjoy!
next prev parent reply other threads:[~2004-05-23 3:46 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-09 23:07 Gnus for next release Miles Bader
2004-05-09 23:19 ` John Wiegley
2004-05-09 23:29 ` Stefan Monnier
2004-05-09 23:54 ` Miles Bader
2004-05-10 7:34 ` Frank Schmitt
2004-05-10 8:31 ` David Kastrup
2004-05-10 10:04 ` Reiner Steib
2004-05-11 12:22 ` Possible problem with Gnus Richard Stallman
2004-05-11 12:40 ` David Kastrup
2004-05-12 19:40 ` Richard Stallman
2004-05-11 13:48 ` Stefan Monnier
2004-05-11 16:07 ` Reiner Steib
2004-05-11 16:31 ` Paul Jarc
2004-05-12 9:59 ` Reiner Steib
2004-05-12 14:15 ` Paul Jarc
2004-05-12 15:48 ` Jesper Harder
2004-05-12 16:39 ` Reiner Steib
2004-05-12 15:36 ` Jesper Harder
2004-05-11 17:51 ` Stefan Monnier
2004-05-12 9:59 ` Reiner Steib
2004-05-12 10:34 ` David Kastrup
2004-05-13 15:45 ` Richard Stallman
2004-05-13 17:25 ` David Kastrup
2004-05-13 17:59 ` Stefan Monnier
2004-05-13 19:07 ` David Kastrup
2004-05-14 21:01 ` Richard Stallman
2004-05-14 21:18 ` David Kastrup
2004-05-15 18:33 ` Richard Stallman
2004-05-23 3:46 ` Andy Tai [this message]
2004-05-23 3:48 ` Andy Tai
2004-05-10 17:54 ` Gnus for next release Richard Stallman
2004-05-10 18:23 ` David Kastrup
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040523034658.74396.qmail@web50908.mail.yahoo.com \
--to=atai@atai.org \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).