From: Leo <sdl.web@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Chong Yidong <cyd@stupidchicken.com>,
dak@gnu.org, 1524@emacsbugs.donarmstrong.com,
emacs-devel@gnu.org
Subject: Re: 23.0.60; gs.el - This code is experimental. Don't use it.
Date: Wed, 04 Feb 2009 16:16:51 +0000 [thread overview]
Message-ID: <xbai1vuetbws.fsf@cam.ac.uk> (raw)
In-Reply-To: <jwvhc45c2m8.fsf-monnier+emacsbugreports@gnu.org> (Stefan Monnier's message of "Sun, 11 Jan 2009 09:57:39 -0500")
On 2009-01-11 14:57 +0000, Stefan Monnier wrote:
[...]
> IIRC David Kastrup would know how broken it is.
Here is David's response.
------------------------------------------------
Leo <sdl.web@googlemail.com> writes:
> 2009/1/11 Stefan Monnier <monnier@iro.umontreal.ca>:
>>>>> I think it is safe to remove (info "(elisp)PostScript Images") and
>>>>> gs.el now that over a month has passed.
>>>> It's used in image.c. We should probably try to fix it if it
>doesn't
>>>> work properly.
>>> I don't use it so I don't know whether it has bugs. I suspect it
>>> has. But I'm mostly concerned by the comment in the source which
>advise
>>> users not to use it.
>>
>> IIRC David Kastrup would know how broken it is.
>
> Stefan's email sent an email address of yours which is no longer in
> use. Could you comment this in emacs-devel mailing list?
Pass it on if you want to. There are a lot of problems due to
Ghostscript rendering directly to Pixmaps. Every image is rendered with
its own Ghostscript process, but the parameter passing requires X
properties as a global resource. This is done once per Ghostscript
session and includes the display dimensions, so it can't really be
extended to multiple image rendering without further Ghostscript API
changes.
The display code triggering the display is rather asynchronous: I've not
been able figuring out how it is rooted in the bowels of the display
engine.
In practice, it worked more or less for a single image rendering per
Emacs session. It doesn't scale at all. Serious work both in
Ghostscript as well as in Emacs would be required to make this a smooth
working feature, and I see no candidate for either.
------------------------------------------------
next prev parent reply other threads:[~2009-02-04 16:16 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-09 23:51 23.0.60; gs.el - This code is experimental. Don't use it Chong Yidong
2009-01-10 5:10 ` bug#1524: " Leo
2009-01-10 5:10 ` Leo
2009-01-10 13:22 ` bug#1524: " Chong Yidong
2009-01-10 13:22 ` Chong Yidong
2009-01-11 3:51 ` bug#1524: " Leo
2009-01-11 3:51 ` Leo
2009-01-11 14:57 ` bug#1524: " Stefan Monnier
2009-01-11 14:57 ` Stefan Monnier
2009-02-04 15:56 ` bug#1524: " Leo
2009-02-04 15:56 ` Leo
2009-02-04 16:16 ` Leo [this message]
2016-12-12 22:20 ` bug#1524: " Glenn Morris
2009-02-04 16:16 ` Leo
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xbai1vuetbws.fsf@cam.ac.uk \
--to=sdl.web@gmail.com \
--cc=1524@emacsbugs.donarmstrong.com \
--cc=cyd@stupidchicken.com \
--cc=dak@gnu.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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.