[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Is this a bug? (was: line-height and line-spacing - behavior and doc
RE: Is this a bug? (was: line-height and line-spacing - behavior and doc)
Tue, 30 May 2006 10:42:04 -0700
> Drew says that specifying t gets rid of spacing between image slices,
> but doesn't get rid of spacing between lines of text. Is that a bug?
It is debateable...
If it is the design choice or there is no other possibility, then it is not
a bug. The doc just needs to be clarified to make the situation clear.
If you mean, however, that it is not desirable to be able to reduce the
interline space for text, then, yes, there can be a debate. Why wouldn't
that be something good to be able to do? I would even like to be able to
overlap lines. Ideally, I'd like to be able to do whatever I can do in a
word-processing system such as TeX.
Normally, the line height is the height of the tallest "character cell"
in the row. So if you use a small font, lines will be narrower than
the normal frame font line height.
I want to be able to reduce the interline space. If we can do that for
images (I didn't try, but the doc says we can "tile" them vertically), then
why not for text also?
However, in most fonts, the "character cell" include some extra pixels
at the top and bottom,
I tiled space characters to create a color palette. The characters are
rectangular. I wanted something square. I don't know a way to change the
aspect ratio of a font. So, I tried to use
"-*-ZapfDingbats-*-*-*-*-3-*-*-*-*-*-iso8859-1", to get a square box
character. I don't believe there are any extra vertical pixels in the
character itself, but I'm not sure how to tell. There are certainly no extra
horizontal pixels in the character.
Those square characters tile fine horizontally, but there is still visual
space between the lines. I assumed that this space was interline space, and
I tried to reduce it using line-height and line-spacing. No luck. I went
back to using space characters and accept a rectangular palette, instead of
so visually, there seems to be a non-zero
line spacing between lines, but it is not added by emacs itself; it
is part of the font metrics.
Perhaps my test with square-box characters isn't good enough. Perhaps you
could test with graphic characters (aka character graphics). I don't have
any installed here. I don't know much about them, but I would think that
using character graphics would be useful in Emacs in some contexts, to
produce simple graphics without images.
I don't know if there is some way to
get to that information (in general)--if there is, we could try to
take that into account,
Thanks for looking into it.
but now is not the time to think about it.
Agreed. But now can be the time to fix the doc to be clear about what
happens - i.e. you can only increase, not decrease interline spacing.
The issue about the "line-height" property on newline and tiled
simply a way to tell the redisplay engine that is shall NOT include the
height of the newline character in the calculation of the line height.
Normally, a newline has the same height as a space character in
That's how is has to be -- otherwise, empty lines would have zero height
(and there would be other issues as well).
That makes sense when you put it that way. Perhaps the line-height doc could
So it is true that line-height can only INCREASE the height of a line,
except when it is placed on the final newline, in which case it can
indicate not to include the height of the newline in the line height.
Again, doc clarification would be welcome.
Thx - Drew