Re: Several suggestions for image support

[David Kastrup]

address@hidden (Kim F. Storm) writes:

> David Kastrup <address@hidden> writes:
> 
> > 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.
> > > > 
> > > > I would find it important if an image specifier could restrict the
> > > > displayed portion of an image.
> > > 
> > > I have just implemented image slicing via a new slice property:
> > > 
> > >         display ((slice X Y WIDTH HEIGHT) (image ...))
> > 
> > Does that imply that slicing is not only applicable to images?
> 
> Currently it only applies to images.  It can be extended to other
> objects as well, but I don't plan to do that myself.

Ok, here is the next problem I see:  assume that I have the input in
preview-latex:


\begin{smallmatrix} 1&2\\ 3&4 \end{smallmatrix}

This will produce a single image split into 4 slices that I want to
have arranged

   12
   34

This stuff we will split into 4 overlays covering
\begin{smallmatrix} 1&
2\\ 
3&
4 \end{smallmatrix}

Now here come the somewhat ugly things: in order to have this
composition arranged properly, the first overlay will also have to
contain a before-string of "\n", and the second and fourth overlay
will contain an after-string of "\n".  Cursor up/down will not produce
any sensible results.

Ok, I mean with preview-latex the solution is not too bad: require the
source to be formatted appropriately, or the image does not get
sliced, period.  Namely, have a newline after every row and only a
constant non-printing fillprefix before each row (as a requirement for
slicing).  And better use align-current to align all & signs
(optionally, will make cursor movement nicer).  If we place those
requirements on source formatting, we won't be needing any
before-string and after-string, and things get slightly more sane.

So I think we might get along without more heavyweight support here
for now.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum