Re: Several suggestions for image support

[David Kastrup <dak@gnu.org>]

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