Hi, Some thoughts on this bug from a typography hobbyist: from a typographic point of view, good line spacing is not a fixed quantity but depends on things like line length and the properties of the font, sometimes even the text itself.
So I think ideally the line spacing should be user-configurable, perhaps as an additional fontconfig property. I actually looked for such a property completely unrelated to this bug: I would have liked to use slightly larger line spacing than is the default in Emacs and xterm in Debian squeeze. I just now found out that Emacs actually has support for customizing line spacing (see below); but xterm nor other terminal programs do not (as far as I know). In typographic circles, the unit of line spacing is points (i.e., the same as the size of the font); for instance, a 12-point font with 14-point line spacing (a less common way to state the same is to say that there are 2 points of leading between lines). (Pixels are also okay for a display, but not "single-spaced" or "one and a half" or "double-spaced" as in some word processing programs - these three values are much too coarse.) More to the point, could this bug be related to the minspace-property (the only thing about line spacing that appears to be configurable in fontconfig): http://www.xfree86.org/current/fontconfig.3.html and http://www.freedesktop.org/software/fontconfig/fontconfig-user.html say that minspace is a boolean that "Eliminate[s] leading from line spacing". The default value does not seem to be mentioned - but I assume that a value of true _should_ create the "crammed lines" effect mentioned in the original bug report and false should give some additional space. I don't have an unstable system to test this on, but perhaps you could try altering the minspace property and seeing if it fixes things: add ":minspace=true" or ":minspace=false" to the end of the font face name. For instance: emacs -fn 'DejaVu Sans Mono-12:minspace=false' & emacs -fn 'DejaVu Sans Mono-12:minspace=true' & (actually, on my Debian squeeze system, both produce the same result, which I guess is a bug... other properties do work, such as emacs -fn 'DejaVu Sans Mono-12:dpi=200' &) So maybe this bug could be transformed into a feature request for an additional fontconfig property that allows user-defined line spacing (with a reasonable default value)? Or should it be the responsibility of every application that uses fontconfig to display multiline text to have an ability to control its line spacing (I don't think this viewpoint is unreasonable, but it does make font-using programs more complex a bit unnecessarily)? Actually, while writing this bug report I found out that Emacs does have internal support for changing line spacing: (setq-default line-spacing 2) adds two pixels of line spacing to the frame. (Or of course M-x customize-variable RET line-spacing RET.) At least on Debian squeeze, Emacs's default is "nil" which means that it does not add additional space. Since Emacs does not support negative values for line-spacing, the original bug actually makes line spacing more configurable (i.e., it can be tightened to smaller values than the previous default). So, as sort of a summary, changing the line-spacing variable should work as a workaround for Emacs. But for actually fixing the bug, we should find out a) if the minspace property works and whether its default was and/or should be changed, b) what should applications expect the default behavior to be (probably a reasonable default spacing instead of minimal spacing as seems to be introduced by this bug), and c) should user-configurable line spacing be the responsibility of every application or a fontconfig property. -- -=- Rjs -=- [email protected] -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
