From: "Jan Djärv" <jan.h.d@swipnet.se>
To: Ted Phelps <phelps@mantara.com>
Cc: 5848@debbugs.gnu.org
Subject: bug#5848: 23.1.95; bands of background after font change if --with-x-toolkit=no
Date: Wed, 07 Apr 2010 10:23:54 +0200 [thread overview]
Message-ID: <4BBC411A.6030900@swipnet.se> (raw)
In-Reply-To: <546.1270623160@orpheus.gnusto.com>
Ted Phelps skrev 2010-04-07 08.52:
> =?ISO-8859-1?Q?Jan_Dj=E4rv?= writes:
>> YAMAMOTO Mitsuharu skrev 2010-04-07 02.16:
>>> FRAME_COL_TO_PIXEL_X and FRAME_LINE_TO_PIXEL_Y include the left and
>>> top side internal border width, respectively. So, the internal border
>>> is already counted twice in FRAME_TEXT_COLS_TO_PIXEL_WIDTH and
>>> FRAME_TEXT_LINES_TO_PIXEL_HEIGHT above.
>>
>> Thanks for the clarification. One pixel is still missing though, I'll
>> keep looking.
>
> I've had a closer look and that last pixel is still there when:
>
> pixelwidth = FRAME_TEXT_COLS_TO_PIXEL_WIDTH (f, cols);
> pixelheight = FRAME_TEXT_LINES_TO_PIXEL_HEIGHT (f, rows);
>
> In this case, there's a one pixel border around the left, bottom and
> right edges of the frame. Hopefully this helps you with your search?
> Or maybe this is the intended behavior? I'll see if I can upload a
> screenshot...
>
Does this pixel disappear if you set internal border width to 0?
I.e:
(set-frame-parameter nil 'internal-border-width 0)
Anyway, when toolkit-x is no, the wm size hints are off by one pixel, so there
is actually (font height)-1 extra pixels.
Jan D.
next prev parent reply other threads:[~2010-04-07 8:23 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-06 14:25 bug#5848: 23.1.95; bands of background after font change if --with-x-toolkit=no Ted Phelps
2010-04-06 16:20 ` Chong Yidong
2010-04-06 17:49 ` Jan Djärv
2010-04-07 1:43 ` Ted Phelps
2010-04-07 1:46 ` Ted Phelps
2010-04-06 17:57 ` Jan Djärv
2010-04-07 1:44 ` Ted Phelps
2010-04-06 18:54 ` Jan Djärv
2010-04-07 0:16 ` YAMAMOTO Mitsuharu
2010-04-07 6:35 ` Jan Djärv
2010-04-07 6:52 ` Ted Phelps
2010-04-07 8:23 ` Jan Djärv [this message]
2010-04-07 9:42 ` Jan Djärv
2010-04-07 9:54 ` Ted Phelps
2010-04-07 10:08 ` Jan Djärv
2010-04-07 11:56 ` Jan Djärv
2010-04-07 9:18 ` Jan Djärv
2010-04-07 9:48 ` YAMAMOTO Mitsuharu
2010-04-07 10:03 ` Jan Djärv
2010-04-07 10:25 ` YAMAMOTO Mitsuharu
[not found] ` <handler.5848.D5848.12706414007122.ackdone@debbugs.gnu.org>
2010-04-07 12:06 ` Jan Djärv
2010-04-07 15:21 ` Chong Yidong
2010-04-07 16:35 ` Jan Djärv
[not found] ` <handler.5848.D5848.12706414007122.notifdone@debbugs.gnu.org>
2010-04-08 0:26 ` bug#5848: closed by Jan Djärv <jan.h.d@swipnet.se> (Re: bug#5848: 23.1.95; bands of background after font change if --with-x-toolkit=no) Ted Phelps
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=4BBC411A.6030900@swipnet.se \
--to=jan.h.d@swipnet.se \
--cc=5848@debbugs.gnu.org \
--cc=phelps@mantara.com \
/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).