Unfortunate pixel width of one TAB

Unfortunate pixel width of one TAB

[Markus Gritsch]

[-- 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

Re: Unfortunate pixel width of one TAB

[Richard Stallman]

    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.

Re: Unfortunate pixel width of one TAB

[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-*".

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

Re: Unfortunate pixel width of one TAB

[Florian Weimer]

* 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?

Re: Unfortunate pixel width of one TAB

[Richard Stallman]

    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.

Re: Unfortunate pixel width of one TAB

[Richard Stallman]

    > 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.

Re: Unfortunate pixel width of one TAB

[Kenichi Handa]

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

Re: Unfortunate pixel width of one TAB

[Markus Gritsch]

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

Re: Unfortunate pixel width of one TAB

[Richard Stallman]

    > 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.

Re: Unfortunate pixel width of one TAB

[Kenichi Handa]

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

Re: Unfortunate pixel width of one TAB

[Kenichi Handa]

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

Re: Unfortunate pixel width of one TAB

[Richard Stallman]

Thanks.