bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

(no subject)


From: Joseph Patterson
Subject: (no subject)
Date: Mon, 7 Jan 2002 10:30:04 -0500

Subject: font kerning
To: address@hidden
Reply-to: address@hidden
CC: joseph
FCC: ~/rmail
--text follows this line--
This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

Your bug report will be posted to the address@hidden mailing list,
and to the gnu.emacs.bug news group.

In GNU Emacs 21.1.1 (sparc-sun-solaris2.7, X toolkit)
 of 2001-12-22 on earth
configured using `configure  sparc-sun-solaris2.7 
--x-libraries=/usr/openwin/lib:/usr/openwin/lib:/lib:/usr/lib 
--prefix=/lfs/joseph/gnu/emacs-21.1 
--exec-prefix=/lfs/joseph/gnu/emacs-21.1/sun57 --with-x-toolkit=athena'
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: C
  locale-coding-system: nil
  default-enable-multibyte-characters: t

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:


In etc/PROBLEMS you openly claim a newly arisen need in the unicode 
font implementation of emacs to ensure there is non-zero font kerning.
To that end you arbitrarily add height to a font at your discretion.
See the quoted entry below.

This need stikes me as purely fictitous.  If I am dumb enough to want
a font with zero kerning, it is incumbent on you as a tool provider to
give it to me.  For over a decade, I have used a personally designed
custom font that gives very bold presentation with minimum height per
line (i.e., zero kerning).  I get the boldness of an 18 point bold font 
with the number of lines per screen in a 12 point font.  The difference
between 49 lines and 38 lines is huge!!  Loosing even one line because
of your discretion is a problem.

If a font fills the defined area in some characters, let it be!!!
Emacs does not need to make sure that lines do not overlap.
That is just a fiction perpetuated by font purists for elegance.
It is not essential to be able to surround a character with shading.
I find that even though my font has some characters that can touch 
each other on sequential lines, in practice, that event almost
never happens (i.e., forget the font purists, zero kerning is
fine for a developer environment even if not for an advertising
environment).


etc/PROBLEMS:

* Certain fonts make each line take one pixel more than it "should".

This is because these fonts contain characters a little taller
than the font's nominal height.  Emacs needs to make sure that
lines do not overlap.


Recent input:
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <menu-bar> <files> <make-frame> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <menu-bar> 
<files> <make-frame-on-display> C-g <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <menu-bar> <help-menu> <report-emacs-b
ug>

Recent messages:
Loading regexp-opt...done
Loading zimmextra (source)...done
Loading jtpsrcmode...done
Loading time...done
Loading vhdl-mode...
Loading mule-util...done
Loading vhdl-mode...done
For information about the GNU Project and its goals, type M-? C-p.
Quit
Loading emacsbug...done



reply via email to

[Prev in Thread] Current Thread [Next in Thread]