Several suggestions for image support

Several suggestions for image support

[David Kastrup]

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.

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.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Several suggestions for image support

[Jason Rumney]

Kim F. Storm wrote:
> David Kastrup <dak@gnu.org> 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 don't think :mask heuristic has anything to do with PNG transparency. 
It is for heuristically determining the background color of a 
non-transparent image, in order to make it transparent.

That said, PNG transparency used to just work back when I was porting 
image support to Windows.

Re: Several suggestions for image support

[YAMAMOTO Mitsuharu]

>>>>> On 16 Apr 2004 02:21:11 +0200, David Kastrup <dak@gnu.org> said:

> 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.

As for PNG transparency, there was one thing that I noticed (and I've
been forgotten to tell about it) while I was porting image support to
Carbon Emacs.

In png_load (image.c):

	      user_bg.red = color.red >> PNG_BG_COLOR_SHIFT;
	      user_bg.green = color.green >> PNG_BG_COLOR_SHIFT;
	      user_bg.blue = color.blue >> PNG_BG_COLOR_SHIFT;

	      fn_png_set_background (png_ptr, &user_bg,
				     PNG_BACKGROUND_GAMMA_SCREEN, 0, 1.0);

I think the background color should be specified in 8-bit depth here
(thus PNG_BG_COLOR_SHIFT should be 8 for all the platforms) because
the 4th argument (aka need_expand) for fn_png_set_background is 0 and
the image data has been normalized in 8-bit depth at this stage.  You
can observe the difference using
http://www.w3.org/Graphics/PNG/alphatest.png.  The same thing is also
applied to the other place (in png_load) where fn_png_set_background
is called with its 4th argument 0.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Several suggestions for image support

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> David Kastrup <dak@gnu.org> 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
intact.

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

Re: Several suggestions for image support

[Kim F. Storm]

David Kastrup <dak@gnu.org> 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?

> 
> 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.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Several suggestions for image support

[Jason Rumney]

Kim F. Storm wrote:

> I understand now -- yes it is silly to try to guess something which
> is already there.
> 
> Would somebody want to work on fixing this?

What's to fix? There is already code there to create a mask from 
transparent parts of a PNG image with transparency.

And for images with an alpha channel, if no :background is specified, 
the frame background color is used.

In the alpha channel case, it might be better to do this at the time the 
image is displayed, in order to take faces into account, but that would 
probably mean a change in the way we cache and reuse images.

Re: Several suggestions for image support

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> Kim F. Storm wrote:
> 
> > I understand now -- yes it is silly to try to guess something which
> > is already there.
> > Would somebody want to work on fixing this?
> 
> What's to fix? There is already code there to create a mask from
> transparent parts of a PNG image with transparency.

Hmmm.  Do you have any evidence of it working?  I have stuff here
involving several complicated things, and it would appear to me that
the image stuff would be the most likely culprit.

Anyway: if :heuristic-mask is true, but the majority of corner pixels
is transparent, it would be nice if just transparency was used as the
mask criterion.  That way I get at least a heuristic mask if the image
creating process does not support transparency, but get the
transparence if it is available in the image.  It is not always easy
to know in advance.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Several suggestions for image support

[Jason Rumney]

David Kastrup wrote:

> Hmmm.  Do you have any evidence of it working?

When I wrote the image support for Windows, I tested a wide range of PNG 
test images. PNG support appears to be broken in the Windows port now 
though, as all images with transparency or alpha channels are appearing 
inverted. This may be something to do with the bug that YAMAMOTO 
Mitsuharu just pointed out.

> Anyway: if :heuristic-mask is true, but the majority of corner pixels
> is transparent, it would be nice if just transparency was used as the
> mask criterion.
 >
> That way I get at least a heuristic mask if the image
> creating process does not support transparency, but get the
> transparence if it is available in the image.  It is not always easy
> to know in advance.

I see the problem. You don't want to have to know in advance whether the 
image has transparency or not.

What about: if the image already has a mask (due to the fact it is a 
transparent image), any heuristic mask property should be ignored. Would 
that be better than relying on corner pixels being transparent?

Re: Several suggestions for image support

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> 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 understand now -- yes it is silly to try to guess something which
is already there.

Would somebody want to work on fixing this?

> 
> > > 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.
> > 
> 
> 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.

That is correct.

Another use of image splitting would be to allow positioning of
multi-line text on the sides of an image; today you can only have
one line of text on the side of an image, no matter how tall that
image is.

One issue I have been thinking about is how to automatically align
those tiling image slices to the position of the first slice (even
when that slice is not visible in the window).  This would be
a very handy way to support having multi-line proportional font
text on the left of a tiled image.

> 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.

If done properly, that should definitely be part of it.

Let me think some more about it; if it is trivial to do, I will add
it before feature freeze; otherwise it will have to wait for 22.1.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Several suggestions for image support

[Jason Rumney]

Kim F. Storm wrote:

> You are right.  Shifting 8 bits here as well on X fixes transparent bg.
> I will commit a fix for X shortly.
> 
> However, on W32, it seems that it explicitly scales things to 16 bits
> in both cases.  I cannot test this on W32, so I cannot say what's
> the right thing to do.

The W32 port scales to 16 bits in places because the native Windows 
COLORREF is 8 bits, while Emacs XColor is 16 bits. So in this case, 8 
bits is right, but alpha is currently coming out wrong. I suspect the 
use of COLOREF instead of XColor that you considered a bug when merging 
the image code (see comment around that location) was in fact not a bug.

> Here is an easy way to test it -- after downloading the image you
> mentioned:
> 
> (insert-image (create-image "alphatest.png"))
> 
> this should result in a light blue image with nice rounded
> edges; a darker blue with rough edges indicates a problem.

On Windows the image comes out with a black background and the image has 
rainbow colored stripes. Non-alpha PNGs look OK.

Re: Several suggestions for image support

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> David Kastrup wrote:
> 
> > Anyway: if :heuristic-mask is true, but the majority of corner pixels
> > is transparent, it would be nice if just transparency was used as the
> > mask criterion.
>  >
> > That way I get at least a heuristic mask if the image
> > creating process does not support transparency, but get the
> > transparence if it is available in the image.  It is not always easy
> > to know in advance.
> 
> I see the problem. You don't want to have to know in advance whether
> the image has transparency or not.

Right.

> What about: if the image already has a mask (due to the fact it is a
> transparent image), any heuristic mask property should be
> ignored. Would that be better than relying on corner pixels being
> transparent?

Yes.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Several suggestions for image support

[Stefan Monnier]

> 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
> intact.

Sounds great for preview-latex, except I'm wondering how you can make
it work.  I mean, how can you figure out what are the pixel positions
of the various cells in your image?


        Stefan

Re: Several suggestions for image support

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> > 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 intact.
> 
> Sounds great for preview-latex, except I'm wondering how you can
> make it work.  I mean, how can you figure out what are the pixel
> positions of the various cells in your image?

preview-latex talks with GhostScript via a bidirectional pipe.  The ==
PostScript operator will output things to stdout.  The \special{ps:
Some PostScript code} sequence will execute the given PostScript code
at the page position corresponding to its source code position.  An
\errmessage will inform preview-latex of the buffer position.
\everyhbox{...} will execute code at the start of every cell in a
table.  \everycr{...} will execute code at the end of each table
line.

The amount of dirty tricks involved here is moderate in comparison to
what is already there.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Several suggestions for image support

[Kim F. Storm]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> >>>>> On 16 Apr 2004 02:21:11 +0200, David Kastrup <dak@gnu.org> said:
>
> > 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.
>
> As for PNG transparency, there was one thing that I noticed (and I've
> been forgotten to tell about it) while I was porting image support to
> Carbon Emacs.
>
> In png_load (image.c):
>
> 	      user_bg.red = color.red >> PNG_BG_COLOR_SHIFT;
> 	      user_bg.green = color.green >> PNG_BG_COLOR_SHIFT;
> 	      user_bg.blue = color.blue >> PNG_BG_COLOR_SHIFT;
>
> 	      fn_png_set_background (png_ptr, &user_bg,
> 				     PNG_BACKGROUND_GAMMA_SCREEN, 0, 1.0);
>
> I think the background color should be specified in 8-bit depth here
> (thus PNG_BG_COLOR_SHIFT should be 8 for all the platforms) because
> the 4th argument (aka need_expand) for fn_png_set_background is 0 and
> the image data has been normalized in 8-bit depth at this stage.

I can indeed see that 8-bit shift is the right setting on X.

>                                                                   You
> can observe the difference using
> http://www.w3.org/Graphics/PNG/alphatest.png.  The same thing is also
> applied to the other place (in png_load) where fn_png_set_background
> is called with its 4th argument 0.

You are right.  Shifting 8 bits here as well on X fixes transparent bg.
I will commit a fix for X shortly.


However, on W32, it seems that it explicitly scales things to 16 bits
in both cases.  I cannot test this on W32, so I cannot say what's
the right thing to do.

Here is an easy way to test it -- after downloading the image you
mentioned:

(insert-image (create-image "alphatest.png"))

this should result in a light blue image with nice rounded
edges; a darker blue with rough edges indicates a problem.

--
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Several suggestions for image support

[Jason Rumney]

> Can you try to change in image.c around line 5454:
> 
> 	  frame_background.red = 256 * GetRValue (color);
> 	  frame_background.green = 256 * GetGValue (color);
> 	  frame_background.blue = 256 * GetBValue (color);
> 
> to
> 
> 	  frame_background.red = GetRValue (color);
> 	  frame_background.green = GetGValue (color);
> 	  frame_background.blue = GetBValue (color);

Yes, that (in combination with setting PNG_BG_COLOR_SHIFT to 8) fixed it.

Re: Several suggestions for image support

[Kim F. Storm]

Jason Rumney <jasonr@gnu.org> writes:

> Kim F. Storm wrote:
> 
> > You are right.  Shifting 8 bits here as well on X fixes transparent bg.
> > I will commit a fix for X shortly.
> > However, on W32, it seems that it explicitly scales things to 16
> > bits
> > in both cases.  I cannot test this on W32, so I cannot say what's
> > the right thing to do.
> 
> The W32 port scales to 16 bits in places because the native Windows
> COLORREF is 8 bits, while Emacs XColor is 16 bits. So in this case, 8
> bits is right, but alpha is currently coming out wrong. I suspect the
> use of COLOREF instead of XColor that you considered a bug when
> merging the image code (see comment around that location) was in fact
> not a bug.

But w32_defined_color has an XColor * as third arg, not COLORREF.
And w32_defined_color seems to return "properly scaled" values,
so it seems like it should be shifted >> 8 like the other ports.

> 
> > Here is an easy way to test it -- after downloading the image you
> > mentioned:
> > (insert-image (create-image "alphatest.png"))
> > this should result in a light blue image with nice rounded
> > edges; a darker blue with rough edges indicates a problem.
> 
> On Windows the image comes out with a black background and the image
> has rainbow colored stripes. Non-alpha PNGs look OK.
> 

That is more or less as I expected.

Can you try to change in image.c around line 5454:

	  frame_background.red = 256 * GetRValue (color);
	  frame_background.green = 256 * GetGValue (color);
	  frame_background.blue = 256 * GetBValue (color);

to

	  frame_background.red = GetRValue (color);
	  frame_background.green = GetGValue (color);
	  frame_background.blue = GetBValue (color);


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Several suggestions for image support

[Kim F. Storm]

Jason Rumney <jasonr@gnu.org> writes:

> Kim F. Storm wrote:
> 
> > I understand now -- yes it is silly to try to guess something which
> > is already there.
> > Would somebody want to work on fixing this?
> 
> What's to fix? There is already code there to create a mask from
> transparent parts of a PNG image with transparency.

Transparent backgrounds was broken on X -- and on W32.
I already have a fix for X (to be committed shortly).
It would be great to have W32 fixed as well.

> 
> And for images with an alpha channel, if no :background is specified,
> the frame background color is used.
> 
> In the alpha channel case, it might be better to do this at the time
> the image is displayed, in order to take faces into account, but that
> would probably mean a change in the way we cache and reuse images.

That's an idea...  for 22.1 :-)

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Several suggestions for image support

[Richard Stallman]

Emacs should have a way to scroll through an image,
so that C-v each time can advance one window-height
through the image.

It would be inelegant to handle this by treating the tall
image as several lines--but perhaps that might actually
work more easily than some other methods.

Re: Several suggestions for image support

[Werner LEMBERG]

> Emacs should have a way to scroll through an image, so that C-v each
> time can advance one window-height through the image.

I strongly support this!  Normally, I use a 24x12 bitmap font;
together with preview-latex this gives quite big images which are
really tedious to navigate within Emacs.


    Werner

Re: Several suggestions for image support

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> Emacs should have a way to scroll through an image,
> so that C-v each time can advance one window-height
> through the image.
> 
> It would be inelegant to handle this by treating the tall
> image as several lines--but perhaps that might actually
> work more easily than some other methods.

I don't think that splitting the image into lines by Emacs itself is
feasible: the cursor positions on the image would need to correspond
to actual cursor positions in the buffer, or things get inconsistent
(Emacs moves out of cursor positions in the image automatically).
While it would be a real boost of usability for my main application
(preview-latex) if I could walk the cursor across lines or other areas
of an image, the correlation between buffer positions and
corresponding location of the cursor display would need to get
explicitly established by the application: it would imply "stopping
points" when Emacs is trying to move the cursor out of visually
inaccessible areas.  And then Emacs would have to draw a cursor box or
other indicator according to the location in there.  Substructuring an
image like that would be a very nice feature.  But I don't see that
it is possible to make the decision of where to split an image
mechanically.

Of course, scrolling through large images should be possible, anyway,
and quite independent from that fanciful features.  Emacs already has
set-window-vscroll in its display engine in order to deal perfectly
well with that.

However, the only location where it is currently used is at the end of
the buffer.  Apart from C-v, scrollbars and mouse wheel currently
assume a constant line height, which leads to confusing results where
images or other tall lines are concerned.

Functions that work in terms of fractions of the window height should
try rounding the movement distance down to the next point-addressable
line and if that causes the distance to be quite less than asked for,
revert to using set-window-vscroll for moving to a partial line.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Several suggestions for image support

[David Kastrup]

Werner LEMBERG <wl@gnu.org> writes:

> > Emacs should have a way to scroll through an image, so that C-v each
> > time can advance one window-height through the image.
> 
> I strongly support this!  Normally, I use a 24x12 bitmap font;
> together with preview-latex this gives quite big images which are
> really tedious to navigate within Emacs.

Well, one solution would be to get preview-latex to shrink images
automatically to a maximum size.  However, it your preview indeed is
quite taller than wide, this renders it unreadable.  Also, having
larger equation blocks shrink to fit some small widown height will
make them not line up with other equations.

By the way: there are also large performance problems with
mouse-highlighting and cursor blinking on images: while they are most
visible with larger-than-window images, it is also apparent that
while the border line of the box cursor is blinking, the area of even
small images is intermittently in background color, so it would
appear that it is overdrawn in white and then replaced again.  On a
local display, this might be tolerable for small images.  Over a
low-bandwidth connection and/or with large images, this is a problem.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Several suggestions for image support

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> Richard Stallman <rms@gnu.org> writes:
>
> > Emacs should have a way to scroll through an image,
> > so that C-v each time can advance one window-height
> > through the image.
> >
> > It would be inelegant to handle this by treating the tall
> > image as several lines--but perhaps that might actually
> > work more easily than some other methods.
>
> I don't think that splitting the image into lines by Emacs itself is
> feasible: the cursor positions on the image would need to correspond
> to actual cursor positions in the buffer, or things get inconsistent
> (Emacs moves out of cursor positions in the image automatically).
> While it would be a real boost of usability for my main application
> (preview-latex) if I could walk the cursor across lines or other areas
> of an image, the correlation between buffer positions and
> corresponding location of the cursor display would need to get
> explicitly established by the application: it would imply "stopping
> points" when Emacs is trying to move the cursor out of visually
> inaccessible areas.  And then Emacs would have to draw a cursor box or
> other indicator according to the location in there.  Substructuring an
> image like that would be a very nice feature.  But I don't see that
> it is possible to make the decision of where to split an image
> mechanically.

I have written some code (not too complex) which can split an image
into individual row, and each of those rows into individual "slices"
on each row, e.g.

   +--------+--------------+--------------+
   |        |              |              |
   |        |              |              |   POSSIBLE
   +--------+-----+-----------------------+   SLICING
   |              |                       |
   |              |                       |
   |              |                       |
   |              |                       |
   +--------------+-----------------------+

The major limitation of this is that all "slices" in one row
is (and must be) of equal height - the height of the row.

This is because emacs display engine is still row based, meaning that
all "glyphs" on a row are padded with empty space in top and bottom
to make all glyphs on the row of the same height  (this is not entirely
true, but you get the picture.)

In principle, my implementation can take any slice of an image and
combine it with any other slice of the same image, but the display
engine does not allow those slices to be placed arbitrarily in the
window, i.e. overlap rows like this:

   +----------------+---------------------+
   |                |                     |
   |                |                     |
   |                +---------------------+   IMPOSSIBLE
   |                |                     |   SLICING
   |                |                     |
   +----------------|                     |
   |                |                     |
   |                |                     |
   +----------------+---------------------+


David, what are the requirements for preview-latex ?

>
> Of course, scrolling through large images should be possible, anyway,
> and quite independent from that fanciful features.  Emacs already has
> set-window-vscroll in its display engine in order to deal perfectly
> well with that.

Yes, and it could probably be done entirely in lisp !?

--
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Several suggestions for image support

[Stefan Monnier]

>> Of course, scrolling through large images should be possible, anyway,
>> and quite independent from that fanciful features.  Emacs already has
>> set-window-vscroll in its display engine in order to deal perfectly
>> well with that.
> Yes, and it could probably be done entirely in lisp !?

I already suggested to use two new primitives (that have incidentally
been requested for other purpose):

     point-to-pixel
and
     pixel-to-point

which turn a (displayed) buffer position into a display position and vice
versa.  All the rest should then be reasonably easy to do in Elisp.


        Stefan

Re: Several suggestions for image support

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> >> Of course, scrolling through large images should be possible, anyway,
> >> and quite independent from that fanciful features.  Emacs already has
> >> set-window-vscroll in its display engine in order to deal perfectly
> >> well with that.
> > Yes, and it could probably be done entirely in lisp !?
> 
> I already suggested to use two new primitives (that have incidentally
> been requested for other purpose):
> 
>      point-to-pixel
> and
>      pixel-to-point
> 
> which turn a (displayed) buffer position into a display position and vice
> versa.  All the rest should then be reasonably easy to do in Elisp.

I don't see how.  Absolutely not.  Emacs moves point out of images.
Without stopping points, point will not remain inside of the image
anywhere.  And I certainly can't draw a cursor box over a selected
area of an image.  Or have mouse highlighting over a selected area.

I am still thinking about Kim's proposal (horizontal slices with
vertical subslices) with regard to use under preview-latex.  It would
certainly cater for pretty much every important application I
currently have in mind.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Several suggestions for image support

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> > >> Of course, scrolling through large images should be possible, anyway,
> > >> and quite independent from that fanciful features.  Emacs already has
> > >> set-window-vscroll in its display engine in order to deal perfectly
> > >> well with that.
> > > Yes, and it could probably be done entirely in lisp !?
> > 
> > I already suggested to use two new primitives (that have incidentally
> > been requested for other purpose):
> > 
> >      point-to-pixel
> > and
> >      pixel-to-point
> > 
> > which turn a (displayed) buffer position into a display position and vice
> > versa.  All the rest should then be reasonably easy to do in Elisp.
> 
> I don't see how.  Absolutely not.  Emacs moves point out of images.
> Without stopping points, point will not remain inside of the image
> anywhere.  

At least it could deal sensible with vscrolling through a partially
visible image without moving point out of the image until there is
some other visible line to move it to.

Stefan, isn't it be necessary to have some indication of whether
vscrolling will have any effect, i.e. whether the cursor line is
currently fully visible, or if there are N pixels invisible at the top
and M pixels invisible at the bottom?  E.g. a current-row-visibility
function which returns nil if fully visible and a cons (N . M)
otherwise.

>            And I certainly can't draw a cursor box over a selected
> area of an image.  Or have mouse highlighting over a selected area.

My image slice changes allows you to do exactly that, as each slice of
the image is inserted as a separate display property.

Re. image maps, I decided that for an image slice, the code still
references the image map of the full image, but restricted to the
current slice. So if you want each image slice to have specific
properties, you must create an image map corresponding to the actual
slicing of the image.

Of course, you may also put properties on each slice, as each slice
corresponds to a separate buffer position.

I will try to complete my changes during this week.

> 
> I am still thinking about Kim's proposal (horizontal slices with
> vertical subslices) with regard to use under preview-latex.  It would
> certainly cater for pretty much every important application I
> currently have in mind.

Doing "free positioning (and rotation/orientation/scaling)" of images
and text is on my to-do list for 22.x.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Several suggestions for image support

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> > I already suggested to use two new primitives (that have incidentally
> > been requested for other purpose):
> >
> >      point-to-pixel
> > and
> >      pixel-to-point
> >
> > which turn a (displayed) buffer position into a display position
> > and vice versa.  All the rest should then be reasonably easy to do
> > in Elisp.
> 
> Actually, these are easy to implement, so I'll do that.
> 
> They will return a lispy position like the one returned by
> event-start for a mouse click at the given point/position.
> 
> In this context, the names posn-at-point and posn-at-x-y are better,
> as they directly relate to the corresponding posn- macros.
> 
> As a side bonus, pos-visible-in-window-p will be changed to return a
> list [when partially arg is non-nil]:
> 
>         (x y top bottom)
> 
> which specifies the x and y position of POS, and the number of pixels
> not visible at the top and bottom of the corresponding window line.

Is this really necessary?  I think that it should be sufficient if we
just returned x and y; if one wants to see which of the pixels are
actually off-screen, then checking x and y for negative coordinates
or coordinates that (if we add the object's x and y extent) pass
beyond the screen dimension.  I think that the situation where one
would check for partial visibility is rare enough that complicating
the data format is not warranted.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Several suggestions for image support

[Stefan Monnier]

>> > I already suggested to use two new primitives (that have incidentally
>> > been requested for other purpose):
>> > 
>> >      point-to-pixel
>> > and
>> >      pixel-to-point
>> > 
>> > which turn a (displayed) buffer position into a display position and vice
>> > versa.  All the rest should then be reasonably easy to do in Elisp.
>> 
>> I don't see how.  Absolutely not.  Emacs moves point out of images.
>> Without stopping points, point will not remain inside of the image
>> anywhere.  

OK, maybe we'd need window-start-to-pixel as well, or somesuch.
Note that "buffer position" would not be just an integer but an info
very much (or probably even exactly) like the one provided in
mouse-lick events.  I expect that the same C code can be used for it.


        Stefan

Re: Several suggestions for image support

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> >> > I already suggested to use two new primitives (that have incidentally
> >> > been requested for other purpose):
> >> > 
> >> >      point-to-pixel
> >> > and
> >> >      pixel-to-point
> >> > 
> >> > which turn a (displayed) buffer position into a display position and vice
> >> > versa.  All the rest should then be reasonably easy to do in Elisp.
> >> 
> >> I don't see how.  Absolutely not.  Emacs moves point out of images.
> >> Without stopping points, point will not remain inside of the image
> >> anywhere.  
> 
> OK, maybe we'd need window-start-to-pixel as well, or somesuch.

Which will not make Emacs' cursor stop in image parts AFAICS, nor
will it enable a cursor display covering only part of the image.

Conversion routines alone will not make Emacs place its cursor on
"sensible" parts of the image.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Several suggestions for image support

[Stefan Monnier]

> Which will not make Emacs' cursor stop in image parts AFAICS, nor
> will it enable a cursor display covering only part of the image.

There's a misunderstanding: I'm only concerned with scrolling of images at
this point.


        Stefan

Re: Several suggestions for image support

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> >> Of course, scrolling through large images should be possible, anyway,
> >> and quite independent from that fanciful features.  Emacs already has
> >> set-window-vscroll in its display engine in order to deal perfectly
> >> well with that.
> > Yes, and it could probably be done entirely in lisp !?
>
> I already suggested to use two new primitives (that have incidentally
> been requested for other purpose):
>
>      point-to-pixel
> and
>      pixel-to-point
>
> which turn a (displayed) buffer position into a display position and vice
> versa.  All the rest should then be reasonably easy to do in Elisp.

Actually, these are easy to implement, so I'll do that.

They will return a lispy position like the one returned by event-start
for a mouse click at the given point/position.

In this context, the names posn-at-point and posn-at-x-y are better, as
they directly relate to the corresponding posn- macros.

As a side bonus, pos-visible-in-window-p will be changed to return a
list [when partially arg is non-nil]:

        (x y top bottom)

which specifies the x and y position of POS, and the number of pixels
not visible at the top and bottom of the corresponding window line.

--
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Several suggestions for image support

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> storm@cua.dk (Kim F. Storm) writes:
> 
> > As a side bonus, pos-visible-in-window-p will be changed to return a
> > list [when partially arg is non-nil]:
> > 
> >         (x y top bottom)
> > 
> > which specifies the x and y position of POS, and the number of pixels
> > not visible at the top and bottom of the corresponding window line.
> 
> Is this really necessary?  

Not really -- but it eases image scrolling using window-vscroll.

>                            I think that it should be sufficient if we
> just returned x and y; 

Actually, the change I made returns (x y partial) where x and y
are pixel coordinates and partial means that the line is only
partially visible (so vscroll _may_ apply).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Several suggestions for image support

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> David Kastrup <dak@gnu.org> 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?
Anyway, I have been wondering about how to make slicing an image
property while being able to reuse the image for several slices.
Making this a separate property of course solves that concern.

The effect would presumably be that only the selected slice of the
image gets displayed, right?  And if the current line height exceeds
that of slices in consecutive rows, then there would be white space
between them, right?  Does anybody know offhand whether one can
_reduce_ the linespacing to "tight" for a given interval?

It probably will not be "crucial" though.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Several suggestions for image support

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> >> Of course, scrolling through large images should be possible, anyway,
> >> and quite independent from that fanciful features.  Emacs already has
> >> set-window-vscroll in its display engine in order to deal perfectly
> >> well with that.
> > Yes, and it could probably be done entirely in lisp !?
> 
> I already suggested to use two new primitives (that have incidentally
> been requested for other purpose):
> 
>      point-to-pixel
> and
>      pixel-to-point
> 
> which turn a (displayed) buffer position into a display position and vice
> versa.  All the rest should then be reasonably easy to do in Elisp.

I just installed changes to implement posn-at-point and posn-at-x-y.

I also fixed a recent bug that practically disabled vscrolling.

However, there is still one important limitation to when vscroll actually works:

- If image at top row of screen is fully visible and cursor is in top
  row, vscroll is reset.  This is because making the cursor row fully
  visible takes precedence over vscroll.

My new fix ensures that if the top line contains an image which is
taller than the window height, vscroll is allowed even when the cursor
is in that line.

So if someone would like to enhance line-move and scrolling to
deal with "tall" images, please do it.

I have also added an enhancement to pos-visible-in-window-p to return
pixel coordinates and partial visibility status of the row at the
given position if PARTIALLY arg is non-nil.

E.g. if (nth 2 (pos-visible-in-window-p (window-start))) is non-nil,
the first line is only partially visible, so vscrolling may be
considered.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Several suggestions for image support

[Kim F. Storm]

David Kastrup <dak@gnu.org> 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 ...))


I have installed changes for W32 and MAC ports also, but as usual I
have no way to test if they actually do something sensible.


> 
> 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.

Try this with http://www.w3.org/Graphics/PNG/alphatest.png :

(setq im (create-image "alphatest.png" nil nil))
(insert "\n")
(insert-sliced-image im nil nil 5 4)
(insert "\n")


Note on XPM images:

There are severe problems with sliced XPM images, at least on X.  

The clip mask for each slice is taken from top/leftmost part of the
image, rather than the actual slice of the image.  I have tried a
zillion things to setup the clip mask (and rewrite other parts of the
code) to make this work, but to no avail.

So I hereby ask for help from more skilled X people.  How do you setup
the clip mask of an image with an image mask so that XCopyArea will
use the corresponding part of the image mask when copying a slice from
the image ?

Here is some code to illustrate the bug:

(setq im2 (create-image "etc/gnus.png" nil nil))
(insert "\n")
(insert-sliced-image im2 nil nil 5 4)
(insert "\n")


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Several suggestions for image support

[Piet van Oostrum]

With the last change to image support I can't compile Carbon emacs on
MacOSX: (configured with  --enable-carbon-app --without-x)

gcc -I/sw/include -L/sw/lib -c -fpascal-strings -fno-common -DMAC_OSX -I../mac/src   -Demacs -DHAVE_CONFIG_H   -I. -I/Users/piet/Projects/cvs/emacs/src -fpascal-strings -fno-common -DMAC_OSX -I../mac/src -Dtemacs -g -O2 dispnew.c
In file included from dispnew.c:64:
macterm.h:579: error: conflicting types for `image_ascent'
dispextern.h:2682: error: previous declaration of `image_ascent'
make[1]: *** [dispnew.o] Error 1
make: *** [src] Error 2

-- 
Piet van Oostrum <piet@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP]
Private email: P.van.Oostrum@hccnet.nl

Re: Several suggestions for image support

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> David Kastrup <dak@gnu.org> writes:
> 
> > storm@cua.dk (Kim F. Storm) writes:
> > 
> > > David Kastrup <dak@gnu.org> 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

Re: Several suggestions for image support

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> storm@cua.dk (Kim F. Storm) writes:
> 
> > David Kastrup <dak@gnu.org> 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.


> Anyway, I have been wondering about how to make slicing an image
> property while being able to reuse the image for several slices.
> Making this a separate property of course solves that concern.
> 
> The effect would presumably be that only the selected slice of the
> image gets displayed, right?  

Exactly.

>                               And if the current line height exceeds
> that of slices in consecutive rows, then there would be white space
> between them, right?  

Unfortunately, yes.

However, I have fixed the treatment of newline characters
so that non-empty lines are no longer made a minimum
height equal to the frame default line height.

So you can use very small slices with good results.


>                       Does anybody know offhand whether one can
> _reduce_ the linespacing to "tight" for a given interval?

We can probably build on the existing "overlapping rows" code,
thus allowing a slice to be physically higher than its logical
height.  But it is a bit complicated, so I postponed that to
later -- and to see if something better could be found.

> 
> It probably will not be "crucial" though.

Good.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Several suggestions for image support

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> 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.

Sounds like a problem with cursor motion in the presense of newlines
in before and after string properties -- maybe something for our
"line-move" experts to look into.

> 
> 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).  

As in:

.. (newline)
\begin{smallmatrix} 1&2\\ (newline)
3&4 \end{smallmatrix} (newline)

I.e. if input is like this, image can be sliced; otherwise, image is
not sliced.  Sounds like a sensible approach to me -- if the
latex-mode (or whatever) can help you write in the proper format and
warn (different coloring like in makefile-mode) if there are things
which breaks that format.

>            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.

Good.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Several suggestions for image support

[Kim F. Storm]

Piet van Oostrum <piet@cs.uu.nl> writes:

> With the last change to image support I can't compile Carbon emacs on
> MacOSX: (configured with  --enable-carbon-app --without-x)
>
> gcc -I/sw/include -L/sw/lib -c -fpascal-strings -fno-common -DMAC_OSX -I../mac/src   -Demacs -DHAVE_CONFIG_H   -I. -I/Users/piet/Projects/cvs/emacs/src -fpascal-strings -fno-common -DMAC_OSX -I../mac/src -Dtemacs -g -O2 dispnew.c
> In file included from dispnew.c:64:
> macterm.h:579: error: conflicting types for `image_ascent'
> dispextern.h:2682: error: previous declaration of `image_ascent'
> make[1]: *** [dispnew.o] Error 1
> make: *** [src] Error 2

I'm sorry, but I cannot find a prototype for image_ascent in macterm.h.
Is your macterm.h up-to-date (rev 1.13)?

--
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Several suggestions for image support

[YAMAMOTO Mitsuharu]

>>>>> On 22 Apr 2004 02:43:46 +0200, storm@cua.dk (Kim F. Storm) said:

> Piet van Oostrum <piet@cs.uu.nl> writes:
>> With the last change to image support I can't compile Carbon emacs
>> on MacOSX: (configured with --enable-carbon-app --without-x)

> I'm sorry, but I cannot find a prototype for image_ascent in
> macterm.h.  Is your macterm.h up-to-date (rev 1.13)?

I guess the patch in the following post is applied.

  http://mail.gnu.org/archive/html/emacs-devel/2004-04/msg00002.html

In that case, please delete the line containing image_ascent in
macterm.h.

As far as I tested, image slicing works perfectly for the Mac port
including sliced XPM images (with the XPM support patch).

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Several suggestions for image support

[Richard Stallman]

    However, I have fixed the treatment of newline characters
    so that non-empty lines are no longer made a minimum
    height equal to the frame default line height.

That could have bad effects in many cases.  I don't think
it is ok, unless it is limited to special conditions.

Re: Several suggestions for image support

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     However, I have fixed the treatment of newline characters
>     so that non-empty lines are no longer made a minimum
>     height equal to the frame default line height.
> 
> That could have bad effects in many cases.
>
> I don't think it is ok, unless it is limited to special conditions.

Then let us limit it to special conditions.  Line spacing is usually
used for two conflicting purposes:

a) keep material from separate lines apart
b) provide a regular grid on which lines are placed.

I have no idea what the current semantics actually are, but I'd
propose the following:

Two adjacent lines have their baselines separated by the value of line
spacing corresponding to the face that is valid for the newline
character between them unless overriden by a special "line-spacing"
property or similar.  Unless this would cause overlap of the
descenders of the upper line and the ascenders of the lower line in
which case the line distance will be increased until no overlap
occurs.

This means that for the application I have in mind, I will have to
particularly mark the newline characters as "line spacing 0".  Since
it would probably be a nuisance to require installation of a special
face here, it would be nice if we had a special text property that
could be used for the purpose of fixing the minimal line spacing.

Does this sound like a reasonable scheme?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Several suggestions for image support

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> David Kastrup <dak@gnu.org> writes:
> 
> > Richard Stallman <rms@gnu.org> writes:
> > 
> > > I wonder if slicing images is really the right approach to take.
> > > It will make possible scrolling through an image, though the
> > > interline spacing will appear between the slices, which would be
> > > ugly.
> > 
> > Unless we provide a way to suppress the interline spacing in that
> > case.
> 
> I specifically reworked the interline spacing code to avoid adding
> extra spacing in this case.
> 
> This is generally useful to properly display "pre-sliced" images
> which are very common on web pages.

There is no question that we need a way to suppress interline spacing
in order to apply sliced images to full utility.  But it might be a
mistake to do this automatically.  For example, preview-latex can
replace simple inline math with images.  If we now happen to have two
rows that consists solely of such inline math images, the interline
spacing will vanish and the rows will get too tight.

Since the removal of interline spacing is mostly desirable in
connection with sliced images, and since there is no code in
existence yet that produces sliced images, we are still free to
define the semantics.  I think it would be a tolerable requirement if
one mounted a sliced image from pieces to cover the newline with a
text property removing the line spacing, as described in a separate
post.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Several suggestions for image support

[Piet van Oostrum]

>>>>> YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> (YM) wrote:

>>>>> On 22 Apr 2004 02:43:46 +0200, storm@cua.dk (Kim F. Storm) said:
>> Piet van Oostrum <piet@cs.uu.nl> writes:
>>> With the last change to image support I can't compile Carbon emacs
>>> on MacOSX: (configured with --enable-carbon-app --without-x)

>> I'm sorry, but I cannot find a prototype for image_ascent in
>> macterm.h.  Is your macterm.h up-to-date (rev 1.13)?

YM> I guess the patch in the following post is applied.

YM>   http://mail.gnu.org/archive/html/emacs-devel/2004-04/msg00002.html

Yes, I did. Is this patch still valid/relevant?

YM> In that case, please delete the line containing image_ascent in
YM> macterm.h.

OK, I'll try that.

YM> As far as I tested, image slicing works perfectly for the Mac port
YM> including sliced XPM images (with the XPM support patch).

Thanks.
-- 
Piet van Oostrum <piet@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP]
Private email: P.van.Oostrum@hccnet.nl

Re: Several suggestions for image support

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> Richard Stallman <rms@gnu.org> writes:
> 
> >     However, I have fixed the treatment of newline characters
> >     so that non-empty lines are no longer made a minimum
> >     height equal to the frame default line height.
> > 
> > That could have bad effects in many cases.  
> 
> I honestly don't understand why this is a problem.

For instance, preview-latex uses images as a substitute for
characters.  If I have a line that looks like
$x$
I still want to have it keep the full line distance to the previous
line in order to avoid inconsistent spacing.

This is existing usage of images.  In contrast, sliced images have no
existing usage.  For this reason alone, it would be more useful to
put the burden of removing the interline space on applications
wanting seamless joining of images rather than on applications that
want the normal spacing to be kept: we already _have_ applications
that assume they need to do nothing special in order to keep the
normal line spacing.

> Quite contrary, I always found it very odd (i.e. buggy) that emacs
> forces all lines to be at least as high as the default frame line
> height.  That means that you cannot have any "fine print".

That's why I proposed to take the line spacing corresponding to the
face valid on the new-line character (we'd need something like a
null-face with zero metrics) or have something like a line-distance
property we could tack onto it.  Instead of the line spacing for the
newline, one could also take the largest line spacing prevalent in the
line _including_ the newline (as I explained above, there are
existing applications of image-only lines which need to have a
non-zero line spacing).  That way we would still be able to do
properly spaced fine-print.

> Of course, I can change this, but my feeling is that the new
> behaviour is more in line with what people would expect,

Existing preview-latex code expects to be spaced like text by
default.  Your change would make some future special-case code
slightly easier, at the cost of complicating existing uses.

I think we can do this with less negative impact on existing usage, at
just a small cost for future uses: just make it easy to specify
explicitly when you want zero line spacing.

> If you really have an application where you want to force the old
> behaviour (I doubt there are currently any such uses),

preview-latex uses glyphs as a replacement for characters.  And it
allows a line to consist just of images.  So there are such uses
right now.

> there are ways to force the line to be shown with the default line
> height (e.g. use a 'display space property with a zero width and a
> height of 1 -- ok, that is currently not supported, but it could
> easily be added).

I think it would be less contrived to force the line spacing to zero
by putting a suitable property on the newline.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Several suggestions for image support

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> Richard Stallman <rms@gnu.org> writes:
> 
> > I wonder if slicing images is really the right approach to take.  It
> > will make possible scrolling through an image, though the interline
> > spacing will appear between the slices, which would be ugly.
> 
> Unless we provide a way to suppress the interline spacing in that
> case.

I specifically reworked the interline spacing code to avoid adding
extra spacing in this case.

This is generally useful to properly display "pre-sliced" images
which are very common on web pages.

> 
> > anyway, requiring programs that display images to slice them is
> > rather kludgy.
> 
> Yes, most certainly.  Scrolling through images should be possible
> without slicing.  I agree that it would be a really bad kludge if the
> only way to scroll through images would be to require a program to
> slice them.

I never intended slicing to be used for image scrolling -- it _can_
be used for that, but it was implemented for other purposes.

In any case, slicing of images is a general way to display one or more
individual sections of a bigger image -- aka "cropping".

E.g. with image slicing you can implement the good old 

        1 2 3 4
        5 6 7 8
        8 9 A B
        C D E X

puzzle in emacs (I'm not going to do that :-)

> 
> > Is there some other reason to prefer to handle images by slicing
> > them?
> 
> I would not recommend them as a general mechanism.  However, in the
> particular application for which I have asked for this feature, every
> slice is associated with a different piece of source code that is
> covered by it.  Splitting the image is not as much a tool for
> managing the display of the image than it is for managing control of
> the source code.
> 
> When the source code gets uncovered, it would be convenient to have
> the cursor at the location corresponding to where the mouse pointed.
> Slicing the image makes this possible.  If I use the mouse to mark a
> region on the images, this will copy and paste just the text
> corresponding to that pieces of the images which have been marked.  If
> I edit a table cell, only the image of the cell I am editing at the
> moment will be replaced by the actual text.  In short: I need the
> slicing for an application where it is the natural way of dealing
> with the image.
> 
> Whereas the proposal to demand applications to artificially slice
> their images or Emacs will scroll badly would be an unnatural way of
> dealing with it.
> 
> I agree with you that slicing is not a solution to the bad scrolling
> of Emacs with regard to images.

I just implemented some functions requested by Stefan to assist
implementing image scrolling in lisp.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Several suggestions for image support

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     However, I have fixed the treatment of newline characters
>     so that non-empty lines are no longer made a minimum
>     height equal to the frame default line height.
> 
> That could have bad effects in many cases.  

I honestly don't understand why this is a problem.   

Quite contrary, I always found it very odd (i.e. buggy) that emacs
forces all lines to be at least as high as the default frame line
height.  That means that you cannot have any "fine print".

With my change, if you have just ONE character in the frame default
font in the line, it will be shown exactly as before.  Also, if the
line is empty, ie. only contains the newline, it is also shown as
before.

The only time you will see my change in effect is if you have a line
where ALL glyphs are lower than the default frame line height; in that
case, the line is only as high as the tallest character on that line.

>                                             I don't think
> it is ok, unless it is limited to special conditions.

Of course, I can change this, but my feeling is that the new
behaviour is more in line with what people would expect, so we
should provide a way to force a specific height.

If you really have an application where you want to force the old
behaviour (I doubt there are currently any such uses), there are
ways to force the line to be shown with the default line height
(e.g. use a 'display space property with a zero width and a height of
1  -- ok, that is currently not supported, but it could easily
be added).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Several suggestions for image support

[Kenichi Handa]

[-- Attachment #1: Type: text/plain, Size: 1464 bytes --]

In article <m3isfrk1ry.fsf@kfs-l.imdomain.dk>, storm@cua.dk (Kim F. Storm) writes:
> With my change, if you have just ONE character in the frame default
> font in the line, it will be shown exactly as before.  Also, if the
> line is empty, ie. only contains the newline, it is also shown as
> before.

> The only time you will see my change in effect is if you have a line
> where ALL glyphs are lower than the default frame line height; in that
> case, the line is only as high as the tallest character on that line.

With the latest code, when I do this:

(make-face 'small)
(set-face-attribute 'small nil :height 0.5)
(insert (propertize "abc" 'face 'small) "\n")

the line height gets shorter even if the tailing newline
doesn't have the face `small'.  This result in that when I
type C-k at the beggining of that line, the line gets
taller, which is counter intuitive.

I think the height of the space glyph for the tailing
newline should be the default frame line height in the above
case, and the line height must be desided by all glyphs
including the tailing space.  Then, to have a short line, we
should do:

(insert (propertize "abc\n" 'face 'small))

In this case, C-k as above doesn't change the line height
because we still have a newline of `small' face.

By the way, it seems that the current code doesn't draw a
hollow cursor correctly.   The bottom line of the rectangle
is not drawn (see the attached image).

---
Ken'ichi HANDA
handa@m17n.org


[-- Attachment #2: temp.png --]
[-- Type: image/png, Size: 838 bytes --]

[-- Attachment #3: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Several suggestions for image support

[David Kastrup]

Kenichi Handa <handa@m17n.org> writes:

> I think the height of the space glyph for the tailing
> newline should be the default frame line height in the above
> case, and the line height must be desided by all glyphs
> including the tailing space.

You are confusing line spacing and line height, I think.  Line
spacing is the distance by which the _baselines_ of different lines
are to be set apart unless this could cause overlap.  So I think that
the space between two baselines should be

max(line space of newline, max(all glyph depths of upper line,0)
                          +max(all glyph heights of lower line,0))
where depth is the extent of a glyph below the baseline, and the
height is the extent above.

We could discuss whether it makes sense to use a maximum value of
more than the just the line spacing of the newline character (maybe
of the whole lower line?), but if we do, then the parameter "line
spacing" should be the same for a complete face (including newline
and spaces), whereas height and depth are specific to each glyph.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Several suggestions for image support

[YAMAMOTO Mitsuharu]

>>>>> On 23 Apr 2004 00:03:36 +0200, Piet van Oostrum <piet@cs.uu.nl> said:

>>>>> YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> (YM) wrote:

YM> I guess the patch in the following post is applied.

YM> http://mail.gnu.org/archive/html/emacs-devel/2004-04/msg00002.html

> Yes, I did. Is this patch still valid/relevant?

It's valid (if the line containing image_ascent in macterm.h is
removed and the declarations for Vx_resorce_{name,class} are enclosed
with #ifdef HAVE_WINDOW_SYSTEM in lisp.h), but not relevant to the
crash, I suppose.

Could you please try the patch I posted in the following message and
see similar crash still occurs?
http://mail.gnu.org/archive/html/emacs-devel/2004-04/msg00783.html

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Several suggestions for image support

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> storm@cua.dk (Kim F. Storm) writes:
> 
> > Richard Stallman <rms@gnu.org> writes:
> > 
> > >     However, I have fixed the treatment of newline characters
> > >     so that non-empty lines are no longer made a minimum
> > >     height equal to the frame default line height.
> > > 
> > > That could have bad effects in many cases.  
> > 
> > I honestly don't understand why this is a problem.
> 
> For instance, preview-latex uses images as a substitute for
> characters.  If I have a line that looks like
> $x$
> I still want to have it keep the full line distance to the previous
> line in order to avoid inconsistent spacing.
> 


Ok, I will undo my change and find another way to reduce default
line height.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Several suggestions for image support

[Kenichi Handa]

In article <x5oepj4iul.fsf@lola.goethe.zz>, David Kastrup <dak@gnu.org> writes:

> Kenichi Handa <handa@m17n.org> writes:
>>  I think the height of the space glyph for the tailing
>>  newline should be the default frame line height in the above
>>  case, and the line height must be desided by all glyphs
>>  including the tailing space.

> You are confusing line spacing and line height, I think.  Line
> spacing is the distance by which the _baselines_ of different lines
> are to be set apart unless this could cause overlap.

I don't think I'm confusing.  In my paragraph above, I
really meant line height.  But I should have written more
clearly that "line height must be the maxinum logical font
height (ascent + descent) of faces of all characters
(including the tailing newline)".  Here I think we should
not consider the physical ascent/descent of each glyph which
may be taller or shorter than the the logical ascent/descent
of a font.

> So I think that the space between two baselines should be

> max(line space of newline, max(all glyph depths of upper line,0)
>                           +max(all glyph heights of lower line,0))
> where depth is the extent of a glyph below the baseline, and the
> height is the extent above.

I don't understand what you mean by "line space of newline",
but anyway, I think it's not worth discussing about line
spacing (of your definition).

> We could discuss whether it makes sense to use a maximum value of
> more than the just the line spacing of the newline character (maybe
> of the whole lower line?), but if we do, then the parameter "line
> spacing" should be the same for a complete face (including newline
> and spaces), whereas height and depth are specific to each glyph.

Sorry, I don't understand the above paragraph.  What is "the
parameter line spacing"?  Do you mean the frame parameter
`line-spacing' or a buffer local variable `line-spacing'?
Then they are both a spacing between lines, not the baseline
distance.  Please see what happens by (setq line-spacing 1).

---
Ken'ichi HANDA
handa@m17n.org

Re: Several suggestions for image support

[David Kastrup]

Kenichi Handa <handa@m17n.org> writes:

> In article <x5oepj4iul.fsf@lola.goethe.zz>, David Kastrup
> <dak@gnu.org> writes:
> 
> > Kenichi Handa <handa@m17n.org> writes:
> >>  I think the height of the space glyph for the tailing
> >>  newline should be the default frame line height in the above
> >>  case, and the line height must be desided by all glyphs
> >>  including the tailing space.
> 
> > You are confusing line spacing and line height, I think.  Line
> > spacing is the distance by which the _baselines_ of different
> > lines are to be set apart unless this could cause overlap.
> 
> I don't think I'm confusing.  In my paragraph above, I really meant
> line height.  But I should have written more clearly that "line
> height must be the maxinum logical font height (ascent + descent) of
> faces of all characters (including the tailing newline)".

Ok, what I mean by "line spacing" is not what the variables in Emacs
call by that name, but the prescribed distance between baselines for
a font.  Actually, I wrote that definition down two paragraphs above.

> Here I think we should not consider the physical ascent/descent of
> each glyph which may be taller or shorter than the the logical
> ascent/descent of a font.

I don't know how X11 defines the line spacings.  In typesetting,
however, each font comes with an associated baseline distance.  It may
be what you call the sum of logical ascent/descent, I don't know.  It
is the distance that the baselines should be apart for the font to
look good.  This is usually quite more than the sum of the maximum
ascent and descent available in the font, since good discrimination of
the lines requires a streak of empty space between the lines.

So let us assume that these logical ascent/descent of fonts are what
constitute the "line spacing" as I called it.  Then the recipe would
be to use
max(logical descent of newline character at end of above line +
  logical ascent of newline character at end of below line, max(all
  physical decents of characters in above line,0)+max(all physical
  ascents of characters in below line,0))

Images will not have a logical ascent/descent differing from their
physical one.  The idea is to keep the grid spacing prescribed by the
font of the line endings, unless this could cause overlap (can happen
if we have a few larger characters, or images in between).  Only when
overlap may occur, is the basic distance between lines prescribed by
the font of the newlines increased, and only by that amount which
makes it possible to rule out overlap.  In that way, the basic grid
only gets disrupted where it is unavoidable or where we have font size
changes lasting across line endings.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Several suggestions for image support

[Stefan Monnier]

>> >     However, I have fixed the treatment of newline characters
>> >     so that non-empty lines are no longer made a minimum
>> >     height equal to the frame default line height.
>> > 
>> > That could have bad effects in many cases.  
>> 
>> I honestly don't understand why this is a problem.

> For instance, preview-latex uses images as a substitute for
> characters.  If I have a line that looks like
> $x$
> I still want to have it keep the full line distance to the previous
> line in order to avoid inconsistent spacing.

I don't see the relevance.  More specifically, I understand Kim's change to
only affect the computation of line height, not line spacing.
By its description Kim's change sounds right (although I guess Handa's
point about C-k increasing the line height is valid: so we should refine
the change, but not take it out).
But maybe I'm misunderstanding.


        Stefan

Re: Several suggestions for image support

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> >> >     However, I have fixed the treatment of newline characters
> >> >     so that non-empty lines are no longer made a minimum
> >> >     height equal to the frame default line height.
> >> > 
> >> > That could have bad effects in many cases.  
> >> 
> >> I honestly don't understand why this is a problem.
> 
> > For instance, preview-latex uses images as a substitute for
> > characters.  If I have a line that looks like
> > $x$
> > I still want to have it keep the full line distance to the previous
> > line in order to avoid inconsistent spacing.
> 
> I don't see the relevance.  More specifically, I understand Kim's
> change to only affect the computation of line height, not line
> spacing.

I tried to write what parameters I mean in a separate post.  It
appears we are all talking about different concepts.  Since I don't
know what you call in particular "line height" and "line spacing", I
can't make a meaningful comment or explanation.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Several suggestions for image support

[Richard Stallman]

    Two adjacent lines have their baselines separated by the value of line
    spacing corresponding to the face that is valid for the newline
    character between them unless overriden by a special "line-spacing"
    property or similar.

That is one good way to make it problem-free, I think.

Re: Several suggestions for image support

[Richard Stallman]

      So I think that
    the space between two baselines should be

    max(line space of newline, max(all glyph depths of upper line,0)
			      +max(all glyph heights of lower line,0))
    where depth is the extent of a glyph below the baseline, and the
    height is the extent above.

You may be right, but it occurs to me that we should see if text
formatters have any guidance to offer us on how to decide this.

Re: Several suggestions for image support

[Piet van Oostrum]

>>>>> YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> (YM) wrote:

>>>>> On 23 Apr 2004 00:03:36 +0200, Piet van Oostrum <piet@cs.uu.nl> said:
>>>>> YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> (YM) wrote:

YM> I guess the patch in the following post is applied.

YM> http://mail.gnu.org/archive/html/emacs-devel/2004-04/msg00002.html

>> Yes, I did. Is this patch still valid/relevant?

YM> It's valid (if the line containing image_ascent in macterm.h is
YM> removed and the declarations for Vx_resorce_{name,class} are enclosed
YM> with #ifdef HAVE_WINDOW_SYSTEM in lisp.h), but not relevant to the
YM> crash, I suppose.

YM> Could you please try the patch I posted in the following message and
YM> see similar crash still occurs?
YM> http://mail.gnu.org/archive/html/emacs-devel/2004-04/msg00783.html

The version that I am currently running is the checkout of
D2004.04.19.22.00.00
with amongst others the above patch applied. I have emacs now running
since Wed Apr 21 22:36:27 without a crash, while it used to crash several
times a day. So this seems promising.
-- 
Piet van Oostrum <piet@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP]
Private email: P.van.Oostrum@hccnet.nl

Re: Several suggestions for image support

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>       So I think that
>     the space between two baselines should be
> 
>     max(line space of newline, max(all glyph depths of upper line,0)
> 			      +max(all glyph heights of lower line,0))
>     where depth is the extent of a glyph below the baseline, and the
>     height is the extent above.
> 
> You may be right, but it occurs to me that we should see if text
> formatters have any guidance to offer us on how to decide this.

TeX is pretty quirky in this regard.  It has some design decisions
resulting from efficiency and memory considerations, and some that are
due to dealing best with pagination.  Since an editor window is
usually not intended to display paginated material but rather to
provide a view on part of a long scroll, we don't need to bother with
stuff like "flexible glue" that is used for fitting things better to a
page.

Basically, lines are governed by the three values \baselineskip,
\lineskiplimit and \lineskip.  TeX tries to arrange lines such that
their baselines are \baselineskip apart.  If the descenders of the
upper line come closer than \lineskiplimit to the ascenders of the
lower line, however, TeX instead separates those parts of the lines by
using \lineskip between them.

The plain TeX values are 12pt for \baselineskip, 0pt for
\lineskiplimit, and 1pt for \lineskip.  There is a discontinuity
involved in those standard settings: the separation jumps from 0pt to
1pt once overlap can't be avoided anymore with the standard settings.

In calculating ascent and descent of a line, TeX uses only the maximum
of any actually involved characters and does not distinguish where on
the line these occur.  For an editor, this is certainly appropriate,
as we use rectangular areas of differing background color for
highlighting things.

When typesetting running text, TeX uses the values of the line spacing
variables that are current at the end of the paragraph.  This causes a
whole paragraph to be typeset with consistent (though sometimes
surprising) baseline distances.  This consistency is what I am mostly
worried about: if we have a few words of small print in a paragraph,
and auto-fill-mode happens to break between them, the newline will
belong to a face with a smaller baseline distance.

So I am not sure whether we should making changes of the baseline
distance as easy as changing a face for a few words in running text.
I don't have a much better idea, though.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Several suggestions for image support

[Kim F. Storm]

I have now reworked my line height changes.  

Now, the height of a newline equals the current face height, unless an
explicit line-spacing property is present on the newline character.

If the value of the line-spacing property is t, you get the effect of
my previous change, i.e. the newline character does not add to the
height of the row by itself, but the newline glyph is re-positioned 
inside the available row height to make it fully visible (when the
cursor is above it).

If the value is an integer, it overrides the value of the frame
line-spacing parameter and the (buffer local) value of the line-spacing
variable.

If the value is a float, the number of extra pixels is calculated
as the current row height * value.

I think this covers all the objections raised.

Try this:

(make-face 'small)
(set-face-attribute 'small nil :height 0.5)
(insert (propertize "abc\ndef\nghi" 'face 'small)
        (propertize "\n" 'line-spacing t)
        (propertize "jkl" 'face 'small)        
        "\n")


Kenichi Handa <handa@m17n.org> writes:
 
> By the way, it seems that the current code doesn't draw a
> hollow cursor correctly.   The bottom line of the rectangle
> is not drawn (see the attached image).

That's an old bug which probably never got noticed because lines were
never less that the default face height.

I fixed that too.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Several suggestions for image support

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> I have now reworked my line height changes.  
> 
> Now, the height of a newline equals the current face height, unless an
> explicit line-spacing property is present on the newline character.
> 
> If the value of the line-spacing property is t, you get the effect of
> my previous change, i.e. the newline character does not add to the
> height of the row by itself, but the newline glyph is re-positioned 
> inside the available row height to make it fully visible (when the
> cursor is above it).
> 
> If the value is an integer, it overrides the value of the frame
> line-spacing parameter and the (buffer local) value of the line-spacing
> variable.

So presumably setting the value to 0 will make the newline have the
height of a normal space in the line?

One thing that one should try is to have no surprising changes if the
newline is turned into a space while keeping its properties:
re-filling a paragraph will do that.

I'll have to think this through and maybe play with a few things.

Thanks,

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Several suggestions for image support

[Richard Stallman]

    Quite contrary, I always found it very odd (i.e. buggy) that emacs
    forces all lines to be at least as high as the default frame line
    height.  That means that you cannot have any "fine print".

Paragraphs of "fine print" should have smaller line spacing.  However,
when text in a smaller font appears in the middle of a paragraph that
is mainly ordinary size, even if one whole line is in the smaller
font, that line's spacing should not be reduced.

So the right way to handle this is not really based on the size
of the text in the line.

Another idea is to make it depend on the height of the newlines.  That
would mean putting the newlines into the ordinary font even though the
text around them is in a smaller font.  That would work provided the
fill commands know how to keep the newlines in the ordinary font.

Re: Several suggestions for image support

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> storm@cua.dk (Kim F. Storm) writes:
> 
> > I have now reworked my line height changes.  
> > 
> > Now, the height of a newline equals the current face height, unless an
> > explicit line-spacing property is present on the newline character.
> > 
> > If the value of the line-spacing property is t, you get the effect of
> > my previous change, i.e. the newline character does not add to the
> > height of the row by itself, but the newline glyph is re-positioned 
> > inside the available row height to make it fully visible (when the
> > cursor is above it).
> > 
> > If the value is an integer, it overrides the value of the frame
> > line-spacing parameter and the (buffer local) value of the line-spacing
> > variable.
> 
> So presumably setting the value to 0 will make the newline have the
> height of a normal space in the line?

With the current code, it will have the height of a space in the
current face, not the default face.

Maybe the functionality should be that newlines are by default
always in the default face height, and the line-spacing property
should not change that.  

Instead, it would be better to have a separate line-height property
which can have values:

        nil -> use default face height (as minimum height)
        t   -> use height of current face
        0   -> use actual line height
        N (integer > 0)  -> use N pixels (as minimum height)
        F (float > 0.0)  -> use F * default face height

I think that would be a much cleaner interface.

> 
> One thing that one should try is to have no surprising changes if the
> newline is turned into a space while keeping its properties:
> re-filling a paragraph will do that.

You can just put the line-spacing (or line-height) property on
the whole paragraph and make it sticky.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Several suggestions for image support

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> I have just installed changes to revert to the 21.3 functionality for
> newline height calculation, that is, use the current face font height
> (by default).

Is that really the 21.3 default?  I am asking because I was of the
impression that the line arrangement usually was fixed to the
ascent/descent values of the default face, rather than the current
face: namely that merely switching to a smaller font would not
decrease the distance of lines unless you changed the frame's
_default_ face.

Or do we have different values for "height of newline" and "total
height of line"?  If so, how are they related?

> Then I added a new line-height property on the newline with the
> following values:
>  
>          nil -> use height of current face (the default)
>          t -> use default face height (as minimum height)
>          0   -> use (don't increase) actual line height
>          N (integer > 0)  -> use N pixels (as minimum height)
>          F (float > 0.0)  -> use F * current face font height

Is 0 a special case of N (use 0 pixels as minimum height)?  If so,
would it be the same as 0.0, too?

>From your pointing out the different cases, it would appear that they
differ.  I am trying to get a feel of things.

> The line-spacing property now just specifies additional line-spacing
> like the line-spacing variable and frame parameter.

All in all, this behavior sounds much more consistent and free from
unexpected sideeffects than the previous implementation.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Several suggestions for image support

[Kim F. Storm]

I have just installed changes to revert to the 21.3 functionality for
newline height calculation, that is, use the current face font height
(by default).

Then I added a new line-height property on the newline with the
following values:
 
         nil -> use height of current face (the default)
         t -> use default face height (as minimum height)
         0   -> use (don't increase) actual line height
         N (integer > 0)  -> use N pixels (as minimum height)
         F (float > 0.0)  -> use F * current face font height
 

The line-spacing property now just specifies additional line-spacing
like the line-spacing variable and frame parameter.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Several suggestions for image support

[Miles Bader]

David Kastrup <dak@gnu.org> writes:
> >          nil -> use height of current face (the default)
> >          t -> use default face height (as minimum height)
> >          0   -> use (don't increase) actual line height
> >          N (integer > 0)  -> use N pixels (as minimum height)
> >          F (float > 0.0)  -> use F * current face font height
> 
> Is 0 a special case of N (use 0 pixels as minimum height)?

Sounds like it.

Maybe the description would be more clear if phrased that way, e.g. --

         N (integer)     -> use N pixels (as minimum height); note that
                            0 will give you exactly the actual line height

> >         F (float > 0.0)  -> use F * current face font height
>
> If so, would it be the same as 0.0, too?

I assume that the F case is really a minimum too (really that that the
display engine can't _not_ do that), so that sounds like it's true for
the same reasons as the N case.

-Miles
-- 
`The suburb is an obsolete and contradictory form of human settlement'

Re: Several suggestions for image support

[Kim F. Storm]

Miles Bader <miles@lsi.nec.co.jp> writes:

> David Kastrup <dak@gnu.org> writes:
> > >          nil -> use height of current face (the default)
> > >          t -> use default face height (as minimum height)
> > >          0   -> use (don't increase) actual line height
> > >          N (integer > 0)  -> use N pixels (as minimum height)
> > >          F (float > 0.0)  -> use F * current face font height
> > 
> > Is 0 a special case of N (use 0 pixels as minimum height)?
> 
> Sounds like it.

Not exactly -- the 0 value is a little special in the sense that it
_also_ tries to reposition the ascent/descent of the space glyph
so that when the cursor is on that glyph, as much as possible of the
cursor is visible.

This is different from a value > 0, as that just gives a minimum
height -- and if the space glyph is taller than that, clipping occurs.
Maybe it should also try to reposition the cursor in this case; if so,
0 would indeed be just a special case of N > 0 and F > 0.0

> 
> Maybe the description would be more clear if phrased that way, e.g. --
> 
>          N (integer)     -> use N pixels (as minimum height); note that
>                             0 will give you exactly the actual line height
> 
> > >         F (float > 0.0)  -> use F * current face font height
> >
> > If so, would it be the same as 0.0, too?
> 
> I assume that the F case is really a minimum too (really that that the
> display engine can't _not_ do that), so that sounds like it's true for
> the same reasons as the N case.

Well, it's not really true for the reasons just explained.

Another issue is whether F should be relative the current face font or
the frame default font?  I chose current font, as it enables you to
use default font when necessary, while the opposite isn't true.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Several suggestions for image support

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> Miles Bader <miles@lsi.nec.co.jp> writes:
> 
> > David Kastrup <dak@gnu.org> writes:
> > > >          nil -> use height of current face (the default)
> > > >          t -> use default face height (as minimum height)
> > > >          0   -> use (don't increase) actual line height
> > > >          N (integer > 0)  -> use N pixels (as minimum height)
> > > >          F (float > 0.0)  -> use F * current face font height
> > > 
> > > Is 0 a special case of N (use 0 pixels as minimum height)?
> > 
> > Sounds like it.
> 
> Not exactly -- the 0 value is a little special in the sense that it
> _also_ tries to reposition the ascent/descent of the space glyph
> so that when the cursor is on that glyph, as much as possible of the
> cursor is visible.
> 
> This is different from a value > 0, as that just gives a minimum
> height -- and if the space glyph is taller than that, clipping occurs.
> Maybe it should also try to reposition the cursor in this case; if so,
> 0 would indeed be just a special case of N > 0 and F > 0.0

Ok, here is my take on it: the height of the newline glyph is more or
less relevant when we visibly mark a region or change the background
locally in any other manner or have the cursor box on it: then the
skyline of the top is given by the glyph height, right?  It would
appear to me that for this purpose it would be most consistent if we
used the same rules for spaces as for newline.  The rule I would
propose is the following: always use the height of the _current_ font
at the point of the space or newline, unless that would exceed the
actually available height (which normally will never fall behind the
ascent of the default font, unless we use text properties on the
newline character).

0 will be a special case, spaces will usually have the height of the
font that they are corresponding to, and the presence of one overtall
character or image will not cause all other spaces to look overtall.

> Another issue is whether F should be relative the current face font
> or the frame default font?  I chose current font, as it enables you
> to use default font when necessary, while the opposite isn't true.

Well, we already established that having a paragraph of small print
with line distance reduced to the natural size of the small print
would be nice.  Tacking an 1.0 value on the text will achieve that.
But in that case, having some smaller print within the small print
will again cause inconsistencies.  And it is somewhat contraintuitive
if a relative size of 1.0 causes a change.

So I think that the default of the relative size should refer to the
default face of the frame.  If you want to allow a different base face
for specifying relative sizes, you could allow specifications like

(1.0 . small-face)

That would allow to set a paragraph in small print by placing the
respective line distance property on it.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Several suggestions for image support

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> storm@cua.dk (Kim F. Storm) writes:
> 
> > Miles Bader <miles@lsi.nec.co.jp> writes:
> > 
> > > David Kastrup <dak@gnu.org> writes:
> > > > >          nil -> use height of current face (the default)
> > > > >          t -> use default face height (as minimum height)
> > > > >          0   -> use (don't increase) actual line height
> > > > >          N (integer > 0)  -> use N pixels (as minimum height)
> > > > >          F (float > 0.0)  -> use F * current face font height
> > > > 
> > > > Is 0 a special case of N (use 0 pixels as minimum height)?
> > > 
> > > Sounds like it.
> > 
> > Not exactly -- the 0 value is a little special in the sense that it
> > _also_ tries to reposition the ascent/descent of the space glyph
> > so that when the cursor is on that glyph, as much as possible of the
> > cursor is visible.
> 
> Ok, here is my take on it: the height of the newline glyph is more or
> less relevant when we visibly mark a region or change the background
> locally in any other manner or have the cursor box on it: then the
> skyline of the top is given by the glyph height, right?  It would
> appear to me that for this purpose it would be most consistent if we
> used the same rules for spaces as for newline.  The rule I would
> propose is the following: always use the height of the _current_ font
> at the point of the space or newline, unless that would exceed the
> actually available height (which normally will never fall behind the
> ascent of the default font, unless we use text properties on the
> newline character).
> 
> 0 will be a special case,

I mean, will _not_ be a special case.  Sorry.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Several suggestions for image support

[Richard Stallman]

      The rule I would
    > propose is the following: always use the height of the _current_ font
    > at the point of the space or newline, unless that would exceed the
    > actually available height (which normally will never fall behind the
    > ascent of the default font, unless we use text properties on the
    > newline character).

Treating spaces and newlines alike could be a good idea since
filling converts between them.

What is the "actually available height"?  I am not sure what
that phrase means.  However, the use of the current font for
either spaces or newlines seems to be a mistake, because of
the case I mentioned earlier (more than one line of small text
in a paragraph of larger text).

Re: Several suggestions for image support

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     > The rule I would propose is the following: always use the
>     > height of the _current_ font at the point of the space or
>     > newline, unless that would exceed the actually available
>     > height (which normally will never fall behind the ascent of
>     > the default font, unless we use text properties on the newline
>     > character).
> 
> Treating spaces and newlines alike could be a good idea since
> filling converts between them.
> 
> What is the "actually available height"?  I am not sure what that
> phrase means.  However, the use of the current font for either
> spaces or newlines seems to be a mistake, because of the case I
> mentioned earlier (more than one line of small text in a paragraph
> of larger text).

I was talking here about the visual appearance of the cursor and
probably the top line of highlighting boxes: for those I think it
appropriate to use the current font height (there is no sense in
having taller or smaller boxes than the characters around them).

The line distance is determined differently: it is constant for a
frame unless that would cause overlapping rows with the actual glyph
dimensions, or unless we change it with special properties on the
newline characters.  Those special properties can also be put on space
and other characters but have no effect there.

At least that's how I understood the last proposals.  It means that if
one wants to have a paragraph with smaller line distance, one can
explicitly cover it with an appropriate property.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Several suggestions for image support

[David Kastrup]

no-spam@cua.dk (Kim F. Storm) writes:

> David Kastrup <dak@gnu.org> writes:
> 
> > The line distance is determined differently: it is constant for a
> > frame unless that would cause overlapping rows with the actual glyph
> > dimensions, or unless we change it with special properties on the
> > newline characters.  Those special properties can also be put on space
> > and other characters but have no effect there.
> > 
> > At least that's how I understood the last proposals.  It means that if
> > one wants to have a paragraph with smaller line distance, one can
> > explicitly cover it with an appropriate property.
> 
> With my latest changes, emacs has two properties on newlines:
> 
> * line-height which gives the minimum line height;
>   default minimum line height is given by the height of the face
>   of the newline character.
> 
>   The actual line height is determined by the text on the line;
>   if some glyphs are taller than the minimum line height, the
>   actual line height is increased.

That's what I meant with "unless that would cause overlapping rows".

> * line-spacing which adds additional pixels between this line and the
>   next line.  Default is the value of the line-spacing variable
>   (usually 0).
> 
> So there is still no "fixed line-distance" concept in emacs, as
> lines can always be taller than the ordinary line-distance.
> 
> BTW, the line-height and line-spacing properties are currently only
> supported as text-properties; should this be extended to check for
> overlays too?

Yes.  I'll need this eventually in preview-latex for sliced images,
and preview-latex works exclusively with overlays (it never touches
the text itself).

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Several suggestions for image support

[David Kastrup]

no-spam@cua.dk (Kim F. Storm) writes:

> We could accomplish this by setting the line-height property to the
> pixel height of a specific face *) The effect of this would be that
> newlines would have the height of that face, rather than the current
> font.

Is there a particular reason to have the unit of the line-height be in
pixels?  We specify face dimensions in units of tenths of a point
elsewhere.  Not that I am convinced that is the best way, though.

Anyway, it would be nice if one could specify this relative to a
particular face.  Something like

'(line-height . (1.0 . small-face))

'(line-height . (1.2 . nil))  ;; means the current face
'(line-height . (1.2 . default)) ;; same as the following
'(line-height . 1.2) ;; relative to default

Something like that.  If somebody has a better idea to specify
"current face", that would be nice.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Several suggestions for image support

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     Quite contrary, I always found it very odd (i.e. buggy) that emacs
>     forces all lines to be at least as high as the default frame line
>     height.  That means that you cannot have any "fine print".
>
> Paragraphs of "fine print" should have smaller line spacing.  However,
> when text in a smaller font appears in the middle of a paragraph that
> is mainly ordinary size, even if one whole line is in the smaller
> font, that line's spacing should not be reduced.

But 21.2 did that, so I have tried to be compatible.

>
> So the right way to handle this is not really based on the size
> of the text in the line.
>
> Another idea is to make it depend on the height of the newlines.

That is what it does already -- the height of the newline is derived
from the face font of the newline, not the text in the line.

But if the text in the line is taller than the ordinary line height,
the text height "wins".

>                                                                   That
> would mean putting the newlines into the ordinary font even though the
> text around them is in a smaller font.  That would work provided the
> fill commands know how to keep the newlines in the ordinary font.
>

We could accomplish this by setting the line-height property to the
pixel height of a specific face *) The effect of this would be that
newlines would have the height of that face, rather than the current
font.

Code could then set the line-height from that face's height on a whole
paragraph to make it immune to filling changing the spaces & newlines
in the paragraph.

Of course, this requires that code explicitly specifies the face to
use for line spacing, but since any existing code will assume the
21.2 behaviour, this approach is backwards compatible.


*) I don't see any way to actually obtain the pixel height of a face
from lisp.  What about adding a face-char-height function
(corresponding to frame-char-height).

Args would be FACE &optional FRAME.


--
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Several suggestions for image support

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> The line distance is determined differently: it is constant for a
> frame unless that would cause overlapping rows with the actual glyph
> dimensions, or unless we change it with special properties on the
> newline characters.  Those special properties can also be put on space
> and other characters but have no effect there.
> 
> At least that's how I understood the last proposals.  It means that if
> one wants to have a paragraph with smaller line distance, one can
> explicitly cover it with an appropriate property.

With my latest changes, emacs has two properties on newlines:

* line-height which gives the minimum line height;
  default minimum line height is given by the height of the face
  of the newline character.

  The actual line height is determined by the text on the line;
  if some glyphs are taller than the minimum line height, the
  actual line height is increased.

* line-spacing which adds additional pixels between this line and the
  next line.  Default is the value of the line-spacing variable
  (usually 0).

So there is still no "fixed line-distance" concept in emacs, as lines can
always be taller than the ordinary line-distance.

BTW, the line-height and line-spacing properties are currently only
supported as text-properties; should this be extended to check for
overlays too?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Several suggestions for image support

[Kenichi Handa]

In article <m3u0z6ntqo.fsf@kfs-l.imdomain.dk>, storm@cua.dk (Kim F. Storm) writes:
> I have just installed changes to revert to the 21.3 functionality for
> newline height calculation, that is, use the current face font height
> (by default).

> Then I added a new line-height property on the newline with the
> following values:
 
>          nil -> use height of current face (the default)
>          t -> use default face height (as minimum height)
>          0   -> use (don't increase) actual line height
>          N (integer > 0)  -> use N pixels (as minimum height)
>          F (float > 0.0)  -> use F * current face font height
 
If there's no line-height property, a height of a space
glyph (for SPC, TAB, NL) is decided by the height of a SPACE
glyph of a font.  But, it seems that we can make their
height exactly what requested by a face.  Then I think we
don't have to introduce line-height property.  Each
line-height property value can be simulated as follows.

nil -- do nothing
t -- add `default' face
0 -- make a face of height 0 and add it
N -- make a face by :height N (but specifies it by 1/10 pt) and add it.
F -- make a face by :height F and add it

---
Ken'ichi HANDA
handa@m17n.org

Re: Several suggestions for image support

[Kenichi Handa]

In article <m33c6sakh4.fsf@kfs-l.imdomain.dk>, storm@cua.dk (Kim F. Storm) writes:
>>  By the way, it seems that the current code doesn't draw a
>>  hollow cursor correctly.   The bottom line of the rectangle
>>  is not drawn (see the attached image).

> That's an old bug which probably never got noticed because lines were
> never less that the default face height.

> I fixed that too.

Thank you, I confimed it's fixed.

---
Ken'ichi HANDA
handa@m17n.org

Re: Several suggestions for image support

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> David Kastrup <dak@gnu.org> writes:
> 
> > Anyway, it would be nice if one could specify this relative to a
> > particular face.  Something like
> 
> But except for the "dynamic vs. static" properties here, that's
> the same effect you get with my simpler proposal:
> 
> > 
> > '(line-height . (1.0 . small-face))
> 
>  `(line-height . ,(face-char-height 'small-face))

The problem is that I have to know the actual display that will get
used in order to convert this into pixels.  If I have the same buffer
on two different displays (like M-x talk-connect RET does), then the
same faces might have completely different pixel dimensions.

It also means that I can't set up the buffer independent of the
display that it is going to be shown on.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Several suggestions for image support

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> > We could accomplish this by setting the line-height property to the
> > pixel height of a specific face *) The effect of this would be that
> > newlines would have the height of that face, rather than the current
> > font.
> 
> Is there a particular reason to have the unit of the line-height be in
> pixels?  We specify face dimensions in units of tenths of a point
> elsewhere.  Not that I am convinced that is the best way, though.

The main reason is that the display engine counts in pixels -- so that's
the value that is "needed" there; of course, we could convert points to
pixels (somehow, I'm not a `face expert').

> 
> Anyway, it would be nice if one could specify this relative to a
> particular face.  Something like

But except for the "dynamic vs. static" properties here, that's
the same effect you get with my simpler proposal:

> 
> '(line-height . (1.0 . small-face))

 `(line-height . ,(face-char-height 'small-face))

> 
> '(line-height . (1.2 . nil))  ;; means the current face

 '(line-height . 1.2)

> '(line-height . (1.2 . default)) ;; same as the following
> '(line-height . 1.2) ;; relative to default

 `(line-height . ,(round (* 1.2 (face-char-height 'default))))

> 
> Something like that.  If somebody has a better idea to specify
> "current face", that would be nice.

Of course it can be done as you propose (I planned to do that myself),
but it makes the redisplay engine more complex -- and I doubt the
added flexibility/complexity is really needed.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Several suggestions for image support

[Kim F. Storm]

Kenichi Handa <handa@m17n.org> writes:

> In article <m3u0z6ntqo.fsf@kfs-l.imdomain.dk>, storm@cua.dk (Kim F. Storm) writes:
> > I have just installed changes to revert to the 21.3 functionality for
> > newline height calculation, that is, use the current face font height
> > (by default).
> 
> > Then I added a new line-height property on the newline with the
> > following values:
>  
> >          nil -> use height of current face (the default)
> >          t -> use default face height (as minimum height)
> >          0   -> use (don't increase) actual line height
> >          N (integer > 0)  -> use N pixels (as minimum height)
> >          F (float > 0.0)  -> use F * current face font height
>  
> If there's no line-height property, a height of a space
> glyph (for SPC, TAB, NL) is decided by the height of a SPACE
> glyph of a font.  But, it seems that we can make their
> height exactly what requested by a face.  Then I think we
> don't have to introduce line-height property.  Each
> line-height property value can be simulated as follows.
> 
> nil -- do nothing
> t -- add `default' face
> 0 -- make a face of height 0 and add it
> N -- make a face by :height N (but specifies it by 1/10 pt) and add it.
> F -- make a face by :height F and add it

This is possible, yes, but the main advantage of the line-height
property is that you can put it on an entire region -- independent of
the faces in that region -- and make the line spacing work independint
of filling, untabitying etc. which may add/delete newlines (which will
automatically inherit the line-height property).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Several suggestions for image support

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> The problem is that I have to know the actual display that will get
> used in order to convert this into pixels.  If I have the same buffer
> on two different displays (like M-x talk-connect RET does), then the
> same faces might have completely different pixel dimensions.
> 
> It also means that I can't set up the buffer independent of the
> display that it is going to be shown on.

That's a good point -- I'll see what I can do.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Several suggestions for image support

[Richard Stallman]

    The line distance is determined differently: it is constant for a
    frame unless that would cause overlapping rows with the actual glyph
    dimensions, or unless we change it with special properties on the
    newline characters.  Those special properties can also be put on space
    and other characters but have no effect there.

That sounds good.  Filling could propagate these properties.

Re: Several suggestions for image support

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> Anyway, it would be nice if one could specify this relative to a
> particular face.  Something like
>

I implemented this proposal, with a few changes:

 '(line-height . (1.0 . small-face))
 '(line-height . (1.2 . t))  ;; means the current face
 '(line-height . (1.2 . nil)) ;; same as the following
 '(line-height . 1.2) ;; relative to default

The same values can be specified for the line-spacing property.

In addition, the line-spacing property value may be negative, in which
case the abs value is used as a total line height (so extra pixels are
optionally inserted after the line to make its height the specified
value, e.g.  the following are equivalent when the default face is used:

        0.5  -1.5

But if the default line height is, say 12 pixels, and the current line
is 10 pixels, then the line-spacing value of 0.5 adds 6 pixels to the
height (resulting in a height of 16 pixels), while -1.5 adds 8 pixels
giving a total height of 18 pixels = 1.5 x 12.

Can we close this issue now ?

--
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Several suggestions for image support

[Kenichi Handa]

In article <m38ygf2je5.fsf@kfs-l.imdomain.dk>, storm@cua.dk (Kim F. Storm) writes:

> This is possible, yes, but the main advantage of the line-height
> property is that you can put it on an entire region -- independent of
> the faces in that region -- and make the line spacing work independint
> of filling, untabitying etc. which may add/delete newlines (which will
> automatically inherit the line-height property).

I see the point.

---
Ken'ichi HANDA
handa@m17n.org

Re: Several suggestions for image support

[Richard Stallman]

    But if the text in the line is taller than the ordinary line height,
    the text height "wins".

That's right when the text is taller.  Text that is shorter
is another case.

    >                                                                   That
    > would mean putting the newlines into the ordinary font even though the
    > text around them is in a smaller font.  That would work provided the
    > fill commands know how to keep the newlines in the ordinary font.
    >

    We could accomplish this by setting the line-height property to the
    pixel height of a specific face *) The effect of this would be that
    newlines would have the height of that face, rather than the current
    font.

That seems like an approach that could work.

    BTW, the line-height and line-spacing properties are currently only
    supported as text-properties; should this be extended to check for
    overlays too?

I don't see a use for them as overlays.

Re: Several suggestions for image support

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     BTW, the line-height and line-spacing properties are currently only
>     supported as text-properties; should this be extended to check for
>     overlays too?
> 
> I don't see a use for them as overlays.

I do.  I'll be using them in preview-latex for the spliced image
stuff, and everything preview-latex does is done by overlays:
copy&paste does not transfer the images, so it should not transfer
the line compression.

I could perhaps get by by using text-properties on a newline tacked
into the after-string of overlays.  Of course this would mean
exercising the display engine pretty heavily, pushing my luck.  But
better now than after a release.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Several suggestions for image support

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

[line spacing properties]

> Can we close this issue now ?

Sounds good.  Of course, documentation and bug fixing will have to
follow, but that will occur mostly after the feature freeze.  From
what I can see without actually using it, this looks good.  It
accomplishes a lot more than what I originally asked for, but in a
generally useful and upwards-compatible and sensible way, as far as I
can see.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Several suggestions for image support

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> David Kastrup <dak@gnu.org> writes:
>
> > what I can see without actually using it, this looks good.  It
> > accomplishes a lot more than what I originally asked for, but in a
> > generally useful and upwards-compatible and sensible way, as far
> > as I can see.
> 
> Now we just need to have preview-latex included with CVS emacs.

Not feasible at the moment: while preview-latex has a pretty limited
scope of developers that would all agree to signing over the
necessary stuff, its process system and a few other things pretty
much are tied into AUCTeX.

So unless somebody volunteers to come up with replacements for all of
the locations where preview-latex relies on AUCTeX, placing
preview-latex within Emacs would be useless.

AUCTeX can't be placed into CVS Emacs right now because the copyright,
though licenced under the GPL, is pretty much diluted over the course
of 12 years or so.  The principal copyright holders have partly agreed
to sign papers, partly already done so, but a lot of hunting will be
needed to round up every contributor, and the work is still being
done.  The aim is to have it acceptable into Emacs at some point of
time.

It is not going to happen before the next releasable Emacs state is
reached AFAICS.

Making preview-latex independent from AUCTeX might also be used to
boost the rendering facilities of Emacs, and maybe to add graphical
modes into calc and stuff.  But all of this is not something for which
any of the current preview-latex developers happens to have any
resources available.

The long-term plans are to fold preview-latex into AUCTeX some time
next year to make it more generally available.  Since there is nobody
having time into making preview-latex an independent component from
AUCTeX, this seems to be the best approach at the current point of
time.

So in short: getting preview-latex assigned to be placed into Emacs
would not be much of a problem, but it has a dependency on AUCTeX,
and assignments for that will take longer and are not guaranteed to
arrive.  If things come to worst, some rewriting might even be needed.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

preview-latex in Emacs (was: Several suggestions for image support)

[Stefan Monnier]

> Now we just need to have preview-latex included with CVS emacs.

Since it does not work with Emacs's tex-mode.el but only with AUCTeX, it
would only make sense if we either also include AUCTeX, or hack preview-latex
to the point where it works with tex-mode.el, or hack tex-mode.el to the
point where it works with preview-latex.


        Stefan

Re: Several suggestions for image support

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> I could perhaps get by by using text-properties on a newline tacked
> into the after-string of overlays.  Of course this would mean
> exercising the display engine pretty heavily, pushing my luck.  But
> better now than after a release.
> 
It should work with overlays now...


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Several suggestions for image support

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> storm@cua.dk (Kim F. Storm) writes:
> 
> [line spacing properties]
> 
> > Can we close this issue now ?
> 
> Sounds good.  Of course, documentation and bug fixing will have to
> follow, but that will occur mostly after the feature freeze.  

Sure.

>                                                               From
> what I can see without actually using it, this looks good.  It
> accomplishes a lot more than what I originally asked for, but in a
> generally useful and upwards-compatible and sensible way, as far as I
> can see.

Now we just need to have preview-latex included with CVS emacs.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Several suggestions for image support

[Richard Stallman]

    In addition, the line-spacing property value may be negative, in which
    case the abs value is used as a total line height (so extra pixels are
    optionally inserted after the line to make its height the specified
    value, e.g.  the following are equivalent when the default face is used:

Wouldn't it be cleaner to distinguish this particular kind of
specification by something other than sign of the number?

Re: Several suggestions for image support

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     In addition, the line-spacing property value may be negative, in which
>     case the abs value is used as a total line height (so extra pixels are
>     optionally inserted after the line to make its height the specified
>     value, e.g.  the following are equivalent when the default face is used:
> 
> Wouldn't it be cleaner to distinguish this particular kind of
> specification by something other than sign of the number?

Yes.

Current formats are:

        1.3 or (1.3 . face) => extra line spacing
        -1.3 or (-1.3 . face) => total line spacing

What about 

        (height . 1.3) or (height . (1.3 . face)) => total line spacing
or
        (equal . 1.3) or (equal . (1.3 . face)) => total line spacing
or
        ((1.3)) or ((1.3 . face))

Any other suggestions?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Several suggestions for image support

[Richard Stallman]

    What about 

	    (height . 1.3) or (height . (1.3 . face)) => total line spacing
    or
	    (equal . 1.3) or (equal . (1.3 . face)) => total line spacing

I think `total' would be clearer than `height' or `equal'.

    or
	    ((1.3)) or ((1.3 . face))

That is less clear than using a symbol.

Re: Several suggestions for image support

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     What about 
> 
> 	    (height . 1.3) or (height . (1.3 . face)) => total line spacing
>     or
> 	    (equal . 1.3) or (equal . (1.3 . face)) => total line spacing
> 
> I think `total' would be clearer than `height' or `equal'.

TeX uses the terminology width, height (ascent above baseline), depth
(descent below line) and totalheight (height+depth).

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum