* Unfortunate pixel width of one TAB
@ 2004-12-05 16:04 Markus Gritsch
2004-12-27 4:10 ` Richard Stallman
0 siblings, 1 reply; 12+ messages in thread
From: Markus Gritsch @ 2004-12-05 16:04 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 351 bytes --]
Hi!
When using a proportional font the pixel width of one TAB is "tab-width
times average_char_pixel_width". When editing files which contain tabs
and spaces for indenting, this leads to some bad alignment.
If would be nice if the pixel width of one TAB could be set to something
like "tab-width times space_pixel_width".
Kind regards,
Markus
[-- Attachment #2: shot.png --]
[-- Type: image/png, Size: 4422 bytes --]
[-- Attachment #3: Type: text/plain, Size: 142 bytes --]
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Unfortunate pixel width of one TAB
2004-12-05 16:04 Unfortunate pixel width of one TAB Markus Gritsch
@ 2004-12-27 4:10 ` Richard Stallman
2004-12-27 9:37 ` Markus Gritsch
2004-12-27 13:26 ` Kenichi Handa
0 siblings, 2 replies; 12+ messages in thread
From: Richard Stallman @ 2004-12-27 4:10 UTC (permalink / raw)
Cc: emacs-devel
When using a proportional font the pixel width of one TAB is "tab-width
times average_char_pixel_width". When editing files which contain tabs
and spaces for indenting, this leads to some bad alignment.
If would be nice if the pixel width of one TAB could be set to something
like "tab-width times space_pixel_width".
Do you mean, the width of a space in the current font?
That seems like the right behavior for it.
This ought to be an easy change, but I would have to spend half an
hour learning the background knowledge to make it.
Does anyone know enough about accessing fonts
to be able to do this change quickly? Handa, can you do
it quickly?
Please respond if you take care of this.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Unfortunate pixel width of one TAB
2004-12-27 4:10 ` Richard Stallman
@ 2004-12-27 9:37 ` Markus Gritsch
2004-12-27 11:54 ` Florian Weimer
2004-12-27 22:35 ` Richard Stallman
2004-12-27 13:26 ` Kenichi Handa
1 sibling, 2 replies; 12+ messages in thread
From: Markus Gritsch @ 2004-12-27 9:37 UTC (permalink / raw)
Cc: emacs-devel
Richard Stallman wrote:
> When using a proportional font the pixel width of one TAB is "tab-width
> times average_char_pixel_width". When editing files which contain tabs
> and spaces for indenting, this leads to some bad alignment.
>
> If would be nice if the pixel width of one TAB could be set to something
> like "tab-width times space_pixel_width".
>
> Do you mean, the width of a space in the current font?
> That seems like the right behavior for it.
Yes, exactly. The pixel width of a space of the currently used font
should be taken into account. As a workaround, I am currently lying to
Emacs about the font I use. Normally I would specify
"-*-Bitstream Vera Sans-normal-r-*-*-12-*-*-*-*-*-iso8859-*"
but to get the pixel width of a tab right I have to use
"-*-Bitstream Vera Sans-normal-r-*-*-12-*-*-*-*-40-iso8859-*".
Without explicitly specifying a pixel with of 40 for this font, Emacs
chooses the following font which has a pixel spacing of 60 (spaces in
the font name replaced by underscores to prevent line wrapping in the email)
-outline-Bitstream_Vera_Sans-normal-r-normal-normal-12-90-96-96-p-60-iso8859-*
This fixes the indentation problem, but since lying is never a good idea
it leads to several problems in other cases.
Kind regards,
Markus
P.S.: I found a quite old email where the same problem was discussed for
XEmacs: http://list-archive.xemacs.org/xemacs/199805/msg00176.html
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Unfortunate pixel width of one TAB
2004-12-27 9:37 ` Markus Gritsch
@ 2004-12-27 11:54 ` Florian Weimer
2004-12-27 22:35 ` Richard Stallman
2004-12-27 22:35 ` Richard Stallman
1 sibling, 1 reply; 12+ messages in thread
From: Florian Weimer @ 2004-12-27 11:54 UTC (permalink / raw)
Cc: emacs-devel
* Markus Gritsch:
> Richard Stallman wrote:
>> When using a proportional font the pixel width of one TAB is
>> "tab-width times average_char_pixel_width". When editing files
>> which contain tabs and spaces for indenting, this leads to some
>> bad alignment.
>> If would be nice if the pixel width of one TAB could be set to
>> something like "tab-width times space_pixel_width".
>> Do you mean, the width of a space in the current font?
>> That seems like the right behavior for it.
>
> Yes, exactly. The pixel width of a space of the currently used font
> should be taken into account. As a workaround, I am currently lying to
> Emacs about the font I use. Normally I would specify
> "-*-Bitstream Vera Sans-normal-r-*-*-12-*-*-*-*-*-iso8859-*"
> but to get the pixel width of a tab right I have to use
> "-*-Bitstream Vera Sans-normal-r-*-*-12-*-*-*-*-40-iso8859-*".
This seems to happen in my case with the monospaced version:
-bitstream-bitstream vera sans mono-medium-r-normal--12-116-74-75-m-70-iso8859-1
I'm still using the Emacs release version:
GNU Emacs 21.3.1 (i386-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2004-10-16 on raven, modified by Debian
Is this a bug in Emacs or in the font metrics?
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Unfortunate pixel width of one TAB
2004-12-27 4:10 ` Richard Stallman
2004-12-27 9:37 ` Markus Gritsch
@ 2004-12-27 13:26 ` Kenichi Handa
2004-12-27 14:07 ` Markus Gritsch
2004-12-28 4:57 ` Richard Stallman
1 sibling, 2 replies; 12+ messages in thread
From: Kenichi Handa @ 2004-12-27 13:26 UTC (permalink / raw)
Cc: gritsch, emacs-devel
In article <E1CimCx-0003Nf-Fl@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes:
> When using a proportional font the pixel width of one TAB is "tab-width
> times average_char_pixel_width". When editing files which contain tabs
> and spaces for indenting, this leads to some bad alignment.
> If would be nice if the pixel width of one TAB could be set to something
> like "tab-width times space_pixel_width".
> Do you mean, the width of a space in the current font?
> That seems like the right behavior for it.
I don't think that solves the problem. See this example
lines (the first line has three spaces after "wwwww", and
the next line has one TAB after "wwwww", the last line is
just TAB and "a"):
wwwww a
wwwww a
a
Provided that space width is 5 pixels and "w" width is 10
pixels, the "a" of the first line is at 65 pixels from the
left, but the "a" of the second line is at 80 pixels from
the left, and the "a" of third lines is at 40 pixels from
the left.
> This ought to be an easy change, but I would have to spend half an
> hour learning the background knowledge to make it.
> Does anyone know enough about accessing fonts
> to be able to do this change quickly? Handa, can you do
> it quickly?
> Please respond if you take care of this.
Even if that method doesn't solve the alignment problem, I
agree that current way of tab-width calculation is not
good.
Tab width is calculated as this (x_produce_glyphs):
int tab_width = it->tab_width * FRAME_COLUMN_WIDTH (it->f);
and, x_new_font sets the column width (i.e. the
canonical character width) of a frame as this:
FRAME_COLUMN_WIDTH (f) = FONT_WIDTH (FRAME_FONT (f));
and FONT_WIDTH is defined as this:
#define FONT_WIDTH(f) ((f)->max_bounds.width)
That's why when we change the default font to a proportional
font, the frame gets too wide.
When we change FONT_WIDTH to return the width of space
glyph, the current tab width problem will be solved. But,
as FRAME_COLUMN_WIDTH is also a base of calculating the
frame width, such a change leads to too narrow frame width.
Perhaps, the following modification will do:
(1) Make FONT_WIDTH return the average width of a font.
This will result in the more adequate frame width.
(2) Make a new macro FONT_SPACE_WIDTH that returns the width
of space glyph of the font of the frame. We can make a new
member `space_width' in the struct frame and make x_new_font
sets it value.
(3) Calculate tab width based on FONT_SPACE_WIDTH.
This change will result in not perfect but more adequate tab
width for proportional fonts.
But, shouldn't we postpone such a change until the next
release?
---
Ken'ichi HANDA
handa@m17n.org
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Unfortunate pixel width of one TAB
2004-12-27 13:26 ` Kenichi Handa
@ 2004-12-27 14:07 ` Markus Gritsch
2004-12-28 4:57 ` Richard Stallman
1 sibling, 0 replies; 12+ messages in thread
From: Markus Gritsch @ 2004-12-27 14:07 UTC (permalink / raw)
Cc: rms, emacs-devel
Kenichi Handa wrote:
>
> I don't think that solves the problem. See this example
> lines (the first line has three spaces after "wwwww", and
> the next line has one TAB after "wwwww", the last line is
> just TAB and "a"):
> wwwww a
> wwwww a
> a
>
> Provided that space width is 5 pixels and "w" width is 10
> pixels, the "a" of the first line is at 65 pixels from the
> left, but the "a" of the second line is at 80 pixels from
> the left, and the "a" of third lines is at 40 pixels from
> the left.
I agree, that there is no canonical solution to the problem which
behaves for all users like they expect. However using the space pixel
width to calculate the tab pixel width at least solves the problem of
indentation in source code where only tabs and spaces (but no other
glyphs) are used for indentation at the beginning of the line.
> When we change FONT_WIDTH to return the width of space
> glyph, the current tab width problem will be solved. But,
> as FRAME_COLUMN_WIDTH is also a base of calculating the
> frame width, such a change leads to too narrow frame width.
That's exactly what I have to fight with when lying to Emacs in the font
definition string. Decoupling FONT_WIDTH and FONT_SPACE_WIDTH as
suggested by you will probably solve the problem.
King regards,
Markus
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Unfortunate pixel width of one TAB
2004-12-27 9:37 ` Markus Gritsch
2004-12-27 11:54 ` Florian Weimer
@ 2004-12-27 22:35 ` Richard Stallman
1 sibling, 0 replies; 12+ messages in thread
From: Richard Stallman @ 2004-12-27 22:35 UTC (permalink / raw)
Cc: emacs-devel
> Do you mean, the width of a space in the current font?
> That seems like the right behavior for it.
Is there someone who knows about font data structures enough
to do make this change efficiently?
Please respond to this message only if you can offer to do the
job.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Unfortunate pixel width of one TAB
2004-12-27 11:54 ` Florian Weimer
@ 2004-12-27 22:35 ` Richard Stallman
0 siblings, 0 replies; 12+ messages in thread
From: Richard Stallman @ 2004-12-27 22:35 UTC (permalink / raw)
Cc: gritsch, emacs-devel
Is this a bug in Emacs or in the font metrics?
I don't know whether there is a bug in the font metrics, but we don't
need to answer that question. We definitely should fix Emacs to
use the width of space to compute the width of tab.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Unfortunate pixel width of one TAB
2004-12-27 13:26 ` Kenichi Handa
2004-12-27 14:07 ` Markus Gritsch
@ 2004-12-28 4:57 ` Richard Stallman
2004-12-29 1:32 ` Kenichi Handa
1 sibling, 1 reply; 12+ messages in thread
From: Richard Stallman @ 2004-12-28 4:57 UTC (permalink / raw)
Cc: gritsch, emacs-devel
> Do you mean, the width of a space in the current font?
> That seems like the right behavior for it.
I don't think that solves the problem.
You're talking about a different problem, which is more difficult.
It deals with a broader range of cases.
You're right that adjusting the space with correctly
won't solve the problem you have in mind.
But it will solve a smaller problem, and it is correct to do.
When we change FONT_WIDTH to return the width of space
glyph, the current tab width problem will be solved. But,
as FRAME_COLUMN_WIDTH is also a base of calculating the
frame width, such a change leads to too narrow frame width.
So let's not change FONT_WIDTH.
We can change the computation for tabs
without changing FONT_WIDTH.
Or we can change FONT_WIDTH, but also change FRAME_COLUMN_WIDTH
so that it no longer uses FONT_WIDTH, so that FRAME_COLUMN_WIDTH
will behave the same as now.
Perhaps, the following modification will do:
(1) Make FONT_WIDTH return the average width of a font.
This will result in the more adequate frame width.
(2) Make a new macro FONT_SPACE_WIDTH that returns the width
of space glyph of the font of the frame. We can make a new
member `space_width' in the struct frame and make x_new_font
sets it value.
(3) Calculate tab width based on FONT_SPACE_WIDTH.
That might be good. Or we could do this without changing FONT_WIDTH.
That means do just 2 and 3, not 1.
But, shouldn't we postpone such a change until the next
release?
This is a bug fix. We should do it now.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Unfortunate pixel width of one TAB
2004-12-28 4:57 ` Richard Stallman
@ 2004-12-29 1:32 ` Kenichi Handa
[not found] ` <E1Cjkic-0004kO-AN@fencepost.gnu.org>
0 siblings, 1 reply; 12+ messages in thread
From: Kenichi Handa @ 2004-12-29 1:32 UTC (permalink / raw)
Cc: gritsch, emacs-devel
In article <E1Cj9QX-0004ro-6T@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes:
> Perhaps, the following modification will do:
> (1) Make FONT_WIDTH return the average width of a font.
> This will result in the more adequate frame width.
> (2) Make a new macro FONT_SPACE_WIDTH that returns the width
> of space glyph of the font of the frame. We can make a new
> member `space_width' in the struct frame and make x_new_font
> sets it value.
> (3) Calculate tab width based on FONT_SPACE_WIDTH.
> That might be good. Or we could do this without changing FONT_WIDTH.
> That means do just 2 and 3, not 1.
> But, shouldn't we postpone such a change until the next
> release?
> This is a bug fix. We should do it now.
Ok, I'll work on it. Please wait for a while.
---
Ken'ichi HANDA
handa@m17n.org
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Unfortunate pixel width of one TAB
[not found] ` <E1Cjkic-0004kO-AN@fencepost.gnu.org>
@ 2004-12-30 12:35 ` Kenichi Handa
2004-12-30 20:59 ` Richard Stallman
0 siblings, 1 reply; 12+ messages in thread
From: Kenichi Handa @ 2004-12-30 12:35 UTC (permalink / raw)
Cc: emacs-devel
Richard Stallman <rms@gnu.org> writes:
>> (2) Make a new macro FONT_SPACE_WIDTH that returns the width
>> of space glyph of the font of the frame. We can make a new
>> member `space_width' in the struct frame and make x_new_font
>> sets it value.
>> (3) Calculate tab width based on FONT_SPACE_WIDTH.
>> That might be good. Or we could do this without changing FONT_WIDTH.
>> That means do just 2 and 3, not 1.
>> But, shouldn't we postpone such a change until the next
>> release?
>> This is a bug fix. We should do it now.
> Ok, I'll work on it. Please wait for a while.
> Please reply to this when it is done.
I've just installed these changes for X:
(1) Set FRAME_COLUMN_WIDTH to the average with of a font.
average width is got from AVERAGE_WIDTH font property. If
the property doesn't exist, calculate the average of SPC
to TILDA (perhaps there exists a better method).
(2) Set FRAME_SPACE_WIDTH (new macro) to the space width of
the frame's font, and use it for calculating tab width.
Similar change will be necessary for the other platforms.
---
Ken'ichi HANDA
handa@m17n.org
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Unfortunate pixel width of one TAB
2004-12-30 12:35 ` Kenichi Handa
@ 2004-12-30 20:59 ` Richard Stallman
0 siblings, 0 replies; 12+ messages in thread
From: Richard Stallman @ 2004-12-30 20:59 UTC (permalink / raw)
Cc: emacs-devel
Thanks.
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2004-12-30 20:59 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-12-05 16:04 Unfortunate pixel width of one TAB Markus Gritsch
2004-12-27 4:10 ` Richard Stallman
2004-12-27 9:37 ` Markus Gritsch
2004-12-27 11:54 ` Florian Weimer
2004-12-27 22:35 ` Richard Stallman
2004-12-27 22:35 ` Richard Stallman
2004-12-27 13:26 ` Kenichi Handa
2004-12-27 14:07 ` Markus Gritsch
2004-12-28 4:57 ` Richard Stallman
2004-12-29 1:32 ` Kenichi Handa
[not found] ` <E1Cjkic-0004kO-AN@fencepost.gnu.org>
2004-12-30 12:35 ` Kenichi Handa
2004-12-30 20:59 ` Richard Stallman
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.