From: David De La Harpe Golden <david@harpegolden.net>
To: Stephen Berman <Stephen.Berman@gmx.net>
Cc: handa@m17n.org, emacs-devel@gnu.org
Subject: Re: (re)display problems after font backend merge
Date: Sun, 18 May 2008 04:30:54 +0100 [thread overview]
Message-ID: <482FA2EE.7010900@harpegolden.net> (raw)
In-Reply-To: <87ve1cn5dz.fsf@escher.local.home>
Stephen Berman wrote:
> the underlining is still broken and
> too close to the bottom of the characters.
Re the vertical position:
Have you played with customize-variables
x-use-underline-position-properties and x-underline-at-descent-line ?
They may make a difference.
AFAIK truetype fonts as used in xft/freetype typically provide a real
underline positioning metric, so maybe there's a bug lurking there (or
just a todo)... and of course maybe there are fonts that just actively
say to put the underline in a bad position.
x-underline-at-descent-line seems to cause underline to outright
disappear on my current emacs build though - presumably not right.
Other underline rendering issues:
Not-bad-as-such-but-close underline positions needing a bodge offset
to account for the pixel grid for display clarity for small onscreen
sizes. That one might be immediately relevant - e.g. if you examine
rendering of some fonts at, say, 30pt, you can see the font-specified
underline is not simply at the baseline, but if you're using the font at
more usual 8-10pt sizes on usual screen-type displays (with vertical res
of < 100 dpi), it might as well be.
Appropriate underline position for multi-font spans/lines (taking the
max offset across the line is probably adequately aesthetic in many cases).
Breaking the underline for clarity when descenders intersect it -
somewhat computationally costly (though that matters less these days)
even with the old rendering cheat of drawing the underline first, then
drawing a directionally filled variant (to avoid "bits" in the loopy
descenders of e.g. g,j...) of letters in background colour, h-stretched
or offset left+right a bit, and then overlaying the letters in real
size+position in the foreground colour. (note that the higher
resolution of printed material means the issue is a bit less severe in
print than on-screen, though high-quality print typesetting will also
break underline for descenders).
... High-quality font rendering => hard work!
Re broken underlining:
Not too sure about this - there are certainly issues with underlining
being used for different purposes in emacs, where underlining being
visible for various amounts of inter-word and trailing whitespace may or
may not be appropriate*. Though it looks like you may have odd
underlining beyond whitespace vs. non-whitespace.
(* textual emphasis vs. poor-man's separator bars, for example, as in
bug #26)
> This image shows split windows, with the Gnus Summary buffer on top and
> the Article buffer below. The mode line of the Summary buffer has my
> customized mode-line face (Helvetica font as in variable-pitch face,
> plus over- and underlining). The mode line of the Article buffer has
> mode-line-inactive face, which inherits from mode-line but overrides the
> weight attribute, making it light.
One of the modelines sure doesn't *look* like helvetica ?
next prev parent reply other threads:[~2008-05-18 3:30 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-15 18:45 (re)display problems after font backend merge Stephen Berman
2008-05-16 0:57 ` Kenichi Handa
2008-05-16 10:22 ` Stephen Berman
2008-05-17 3:19 ` David De La Harpe Golden
2008-05-17 12:30 ` Stephen Berman
2008-05-17 14:02 ` David De La Harpe Golden
2008-05-17 18:37 ` Stephen Berman
2008-05-18 3:30 ` David De La Harpe Golden [this message]
2008-05-18 18:19 ` Stephen Berman
2008-05-22 20:36 ` Stephen Berman
2008-05-23 4:16 ` David De La Harpe Golden
2008-05-23 12:28 ` Stephen Berman
2008-05-23 16:10 ` David De La Harpe Golden
2008-05-23 17:03 ` Stephen Berman
2008-05-23 17:37 ` David De La Harpe Golden
2008-05-23 19:42 ` James Cloos
2008-05-23 20:41 ` Stephen Berman
2008-05-23 21:57 ` David De La Harpe Golden
2008-05-24 1:16 ` James Cloos
2008-05-24 23:01 ` Stephen Berman
2008-05-27 13:17 ` Stephen Berman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=482FA2EE.7010900@harpegolden.net \
--to=david@harpegolden.net \
--cc=Stephen.Berman@gmx.net \
--cc=emacs-devel@gnu.org \
--cc=handa@m17n.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).