[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Several suggestions for image support

From: David Kastrup
Subject: Re: Several suggestions for image support
Date: 16 Apr 2004 12:06:27 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

address@hidden (Kim F. Storm) writes:

> David Kastrup <address@hidden> writes:
> > PNG images support transparency.  Emacs can't make use of it.  You can
> > only have Emacs declare a particular color as transparent.  This is
> > dissatisfactory.  It should tell the PNG decoding routines Emacs'
> > background color for the purpose of transparency.
> Using `:mask heuristic' should make the image background transparent.
> The tool-bar code uses this.
> I suppose you know that, so what's the problem with this approach?

That it does not work.  It only works when the majority of corner
pixels has the transparent color.  Also it is impossible for an image
to have, say, both white and transparent color.

Since transparency is a feature of PNG files, is there any particular
reason not to just use the information, preferring some heuristic
hack to it that does not work in all circumstances?

> > I would find it important if an image specifier could restrict the
> > displayed portion of an image.
> This might be useful for other reasons, e.g. image panning.
> Zoom (scaling) would be useful too.
> > The reason is that large images always appear as a single big
> > character to Emacs.  If I could split such an image into a bunch of
> > smaller images, I could walk through it with the cursor.  But it
> > should only be necessary to instantiate the complete image itself once
> > for this purpose.  Of course, one should find a way that does not
> > cause all of the subimages to be entered separately into the image
> > cache.
> Something like this is already on my to-do list.
> However, I have other ideas to make image scrolling work, and it
> is at the top of my to-do list.

This is not mainly for making image scrolling work (it would be quite
overkill for that).  This is to split an image into addressable
items.  For example, preview-latex will turn a tabular into one large
graphic.  If I click on that graphic at a particular point, the whole
graphic dissolves into text and the cursor is positioned at the start
of the tabular.  This is pretty useless if the table is large because
you still have to find your point.

If instead just the table cell opened and the cursor would be
positioned there, one could use this for serious table editing.
Since the whole table is available as one graphic, loading hundreds
of separate images would be inconvenient.  It is conceivable to split
the image within TeX and load it as separate graphics.  However, the
involved complexity is far greater if I want to keep the alignment

It would also mean that I could walk the cursor through _rows_ of the
preview-latex image instead of having to walk through it all at
once.  Image scrolling is a different problem: it does not involve
actually changing the value of point.

Of course, a different possibility would be to just display one image,
but have a way of walking the cursor display across it.  This would
have the advantage that the table would have its optical integrity
preserved (no line spacing between rows of the table), and the
disadvantage that you could only open the whole table at once into
text, not just a cell in between.

It would probably be nice to have a way of tiling an image into areas
with individual property lists (posn-point, keymap,
mouse-highlighting...).  But that's just phantasizing for the future.

David Kastrup, Kriemhildstr. 15, 44793 Bochum

reply via email to

[Prev in Thread] Current Thread [Next in Thread]