incomplete header-line with 3d boxes and prop fonts

incomplete header-line with 3d boxes and prop fonts

[Stefan Monnier]

Try the following command:

   src/emacs -Q --eval '(set-face-attribute (quote header-line) nil :family "helv")' ~/tmp/foo.ses

If you don't have a foo.ses file, you'll get an empty spreadsheet.
Now hit M-o a few times to add some columns.

Now two things:

1 - as already reported, the right hand side of the 3d boxes in the
    header-line are missing.

2 - the last few pixels of the header-line are missing.  Most likely you
    will not have noticed it yet because it's ben correctly drawn earlier
    and hasn't been overdrawn yet.  But try C-l to see what's really
    going on: for each 3d box in the header line a few pixels are lost at
    the right edge of the header-line.

The same thing happens with the mode-line (except that 3d boxes in the
mode-line are harder to come by, except for mouse-face highlights and those
don't seem to suffer from that problem).


        Stefan

Re: incomplete header-line with 3d boxes and prop fonts

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Try the following command:
>
>    src/emacs -Q --eval '(set-face-attribute (quote header-line) nil :family "helv")' ~/tmp/foo.ses
>
> If you don't have a foo.ses file, you'll get an empty spreadsheet.
> Now hit M-o a few times to add some columns.
>
> Now two things:
>
> 1 - as already reported, the right hand side of the 3d boxes in the
>     header-line are missing.
>
> 2 - the last few pixels of the header-line are missing.  Most likely you
>     will not have noticed it yet because it's ben correctly drawn earlier
>     and hasn't been overdrawn yet.  But try C-l to see what's really
>     going on: for each 3d box in the header line a few pixels are lost at
>     the right edge of the header-line.
>
> The same thing happens with the mode-line (except that 3d boxes in the
> mode-line are harder to come by, except for mouse-face highlights and those
> don't seem to suffer from that problem).

I installed a trivial fix for the missing right 3D border -- it seems
to only hit a boxed stretch glyph.


But the result (in ses-mode) isn't pleasing ... the cell contents gets
more and more misaligned with the header line.  I tracked this to a
problem with the calculation of the size of a :box'ed stretch glyph.

I'm not sure how the fix I've installed for this may break other code
using box'ed stretch glyphs.  

The fix is to simply assume that the specified :width, :height or :align-to
includes the face box width/height (which seems to be TRT, as the code
using this shouldn't have to take special actions for boxed faces (which
are often used in header (and mode) lines.

Please report any problems -- if any, there  probably is a trivial
fix at the Lisp level !!

--
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: incomplete header-line with 3d boxes and prop fonts

[Stefan Monnier]

>> Try the following command:
>> 
>> src/emacs -Q --eval '(set-face-attribute (quote header-line) nil :family "helv")' ~/tmp/foo.ses
>> 
>> If you don't have a foo.ses file, you'll get an empty spreadsheet.
>> Now hit M-o a few times to add some columns.
>> 
>> Now two things:
>> 
>> 1 - as already reported, the right hand side of the 3d boxes in the
>> header-line are missing.
>> 
>> 2 - the last few pixels of the header-line are missing.  Most likely you
>> will not have noticed it yet because it's ben correctly drawn earlier
>> and hasn't been overdrawn yet.  But try C-l to see what's really
>> going on: for each 3d box in the header line a few pixels are lost at
>> the right edge of the header-line.
>> 
>> The same thing happens with the mode-line (except that 3d boxes in the
>> mode-line are harder to come by, except for mouse-face highlights and those
>> don't seem to suffer from that problem).

> I installed a trivial fix for the missing right 3D border -- it seems
> to only hit a boxed stretch glyph.

Thanks, it seems both problems are fixed.


        Stefan

Re: incomplete header-line with 3d boxes and prop fonts

[Richard Stallman]

    But the result (in ses-mode) isn't pleasing ... the cell contents gets
    more and more misaligned with the header line.  I tracked this to a
    problem with the calculation of the size of a :box'ed stretch glyph.

If the bug in ses.el is obvious, can you fix it?  If not, would you
like the maintainer of ses.el to fix it?  I have cc'd him.

Re: incomplete header-line with 3d boxes and prop fonts

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     But the result (in ses-mode) isn't pleasing ... the cell contents gets
>     more and more misaligned with the header line.  I tracked this to a
>     problem with the calculation of the size of a :box'ed stretch glyph.
>
> If the bug in ses.el is obvious, can you fix it?  If not, would you
> like the maintainer of ses.el to fix it?  I have cc'd him.

I fixed the problem in the :align-to handling in C.  

That fixes the problem for ses.el too.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: incomplete header-line with 3d boxes and prop fonts

[Jonathan Yavner]

> >     But the result (in ses-mode) isn't pleasing ...
>
> I fixed the problem in the :align-to handling in C.
> That fixes the problem for ses.el too.

Excellent, thanks!  Hopefully I can find a way to get rid of the the 
defadvice in SES before pretest starts.

Re: incomplete header-line with 3d boxes and prop fonts

[Richard Stallman]

    Excellent, thanks!  Hopefully I can find a way to get rid of the the 
    defadvice in SES before pretest starts.

If you're going to try, please try soon!

Re: incomplete header-line with 3d boxes and prop fonts

[Sascha Wilde]

storm@cua.dk (Kim F. Storm) wrote:

> Richard Stallman <rms@gnu.org> writes:
>
>>     But the result (in ses-mode) isn't pleasing ... the cell contents gets
>>     more and more misaligned with the header line.  I tracked this to a
>>     problem with the calculation of the size of a :box'ed stretch glyph.
>>
>> If the bug in ses.el is obvious, can you fix it?  If not, would you
>> like the maintainer of ses.el to fix it?  I have cc'd him.
>
> I fixed the problem in the :align-to handling in C.  
>
> That fixes the problem for ses.el too.

I still do see a heavy misalignment of the header line in ses (with
X11), but only when using a font with an odd size
(-*-terminus-medium-r-*-*-17-*-*-*-*-*-iso8859-1 here).

In all other cases everything looks fine.

cheers
sascha
-- 
"Anyone who slaps a 'this page is best viewed with Browser X' label on a Web 
page appears to be yearning for the bad old days, before the Web, when you had 
very little chance of reading a document written on another computer, another 
word processor, or another network." -- Tim Berners-Lee, July 1996

Re: incomplete header-line with 3d boxes and prop fonts

[Kim F. Storm]

Sascha Wilde <wilde@sha-bang.de> writes:

> storm@cua.dk (Kim F. Storm) wrote:
>
>> Richard Stallman <rms@gnu.org> writes:
>>
>>>     But the result (in ses-mode) isn't pleasing ... the cell contents gets
>>>     more and more misaligned with the header line.  I tracked this to a
>>>     problem with the calculation of the size of a :box'ed stretch glyph.
>>>
>>> If the bug in ses.el is obvious, can you fix it?  If not, would you
>>> like the maintainer of ses.el to fix it?  I have cc'd him.
>>
>> I fixed the problem in the :align-to handling in C.  
>>
>> That fixes the problem for ses.el too.
>
> I still do see a heavy misalignment of the header line in ses (with
> X11), but only when using a font with an odd size
> (-*-terminus-medium-r-*-*-17-*-*-*-*-*-iso8859-1 here).

I don't have terminus, but I see it too if I use a proportial font
like helvetica.  This is a "Lisp" level bug.

I guess that ses could use :align-to to separate columns in the "text
area" too.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: incomplete header-line with 3d boxes and prop fonts

[Sascha Wilde]

storm@cua.dk (Kim F. Storm) wrote:

> Sascha Wilde <wilde@sha-bang.de> writes:
>
>> storm@cua.dk (Kim F. Storm) wrote:
>>
>>> Richard Stallman <rms@gnu.org> writes:
>>>
>>>>     But the result (in ses-mode) isn't pleasing ... the cell contents gets
>>>>     more and more misaligned with the header line.  I tracked this to a
>>>>     problem with the calculation of the size of a :box'ed stretch glyph.
>>>>
>>>> If the bug in ses.el is obvious, can you fix it?  If not, would you
>>>> like the maintainer of ses.el to fix it?  I have cc'd him.
>>>
>>> I fixed the problem in the :align-to handling in C.  
>>>
>>> That fixes the problem for ses.el too.
>>
>> I still do see a heavy misalignment of the header line in ses (with
>> X11), but only when using a font with an odd size
>> (-*-terminus-medium-r-*-*-17-*-*-*-*-*-iso8859-1 here).
>
> I don't have terminus, but I see it too if I use a proportial font
> like helvetica.  This is a "Lisp" level bug.

terminus is not a proportial font.

It's a free font by Dimitar Zhekov, optimized for long work with
computers, http://www.is-vn.bg/hamster/jimmy-en.html -- if you don't
know it, give it a try!  ;-)

sascha
-- 
Sascha Wilde
Nota bene: wenn Word für Längeres geeignet wäre, würde es schließlich
nicht Word, sondern Sentence, Page oder Article heißen
 	-- Matthias Mühlich in dctt

Re: incomplete header-line with 3d boxes and prop fonts

[Kim F. Storm]

Sascha Wilde <wilde@sha-bang.de> writes:

>>> I still do see a heavy misalignment of the header line in ses (with
>>> X11), but only when using a font with an odd size
>>> (-*-terminus-medium-r-*-*-17-*-*-*-*-*-iso8859-1 here).

I see it too.

If I customize the default face, and change the height from 99 to 100,
it works again.  I'll look into what's wrong.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Default face problem [was: Re: incomplete header-line with 3d boxes and prop fonts]

[Kim F. Storm]

storm@cua.dk (Kim F. Storm) writes:

> Sascha Wilde <wilde@sha-bang.de> writes:
>
>>>> I still do see a heavy misalignment of the header line in ses (with
>>>> X11), but only when using a font with an odd size
>>>> (-*-terminus-medium-r-*-*-17-*-*-*-*-*-iso8859-1 here).
>
> I see it too.
>
> If I customize the default face, and change the height from 99 to 100,
> it works again.  I'll look into what's wrong.


This goes beyond my capabilites :-/

I put a breakpoint in x_new_font, and got this result:

Breakpoint 6, x_new_font (f=0x86c1678, fontname=0x86af3a0 "-xos4-terminus-medium-r-normal--17-123-100-100-c-90-iso8859-1") at xterm.c:7848
(gdb) n
(gdb) p *fontp
$11 = {
  font = 0x86c1e28, 
  font_idx = 0, 
  name = 0x86c1d50 "-xos4-terminus-medium-r-normal--17-123-100-100-c-90-iso8859-1", 
  full_name = 0x86c1de0 "-xos4-terminus-medium-r-normal--17-123-100-100-c-90-iso8859-1", 
  charset = 0, 
  size = 9, 
  height = 16, 
  space_width = 9, 
  average_width = 9, 
  vertical_centering = 0, 
  encoding = "\000\377", '\0' <repeats 126 times>, '\001' <repeats 127 times>, 
  baseline_offset = 0, 
  relative_compose = 0, 
  default_ascent = 0, 
  font_encoder = 0x0
}

So the frame's default font width is 9 pixels.

But when I contine and get to the place where an "A" is inserted in the header line,
I get this font info for the "A" character:


(gdb) p *face
$13 = {
  id = 17, 
  gc = 0x0, 
  font = 0x85ea4a0, 
  stipple = 0, 
  foreground = 3355443, 
  background = 15066597, 
  underline_color = 0, 
  overline_color = 0, 
  strike_through_color = 0, 
  box_color = 3355443, 
  font_name = 0x85ea408 "-xos4-Terminus-Medium-R-Normal--16-160-72-72-C-80-ISO8859-1", 
  font_info_id = 1, 
  fontset = 20, 
  pixmap_w = 0, 
  pixmap_h = 0, 
  box_line_width = 2, 
  box = FACE_RAISED_BOX, 
  use_box_color_for_shadows_p = 0, 
  lface = {137881521, 141778755, 137913561, 792, 137913561, 137913561, 137881137, 137881137, 138504219, 138504203, 137881137, 137881137, 137881137, 139595989, 141300995, 137881137, 720}, 
  hash = 16929879, 
  charset = 0, 
  underline_p = 0, 
  overline_p = 0, 
  strike_through_p = 0, 
  foreground_defaulted_p = 0, 
  background_defaulted_p = 0, 
  underline_defaulted_p = 0, 
  overline_color_defaulted_p = 0, 
  strike_through_color_defaulted_p = 0, 
  box_color_defaulted_p = 1, 
  tty_bold_p = 0, 
  tty_dim_p = 0, 
  tty_underline_p = 0, 
  tty_alt_charset_p = 0, 
  tty_reverse_p = 0, 
  tty_blinking_p = 0, 
  colors_copied_bitwise_p = 0, 
  overstrike = 0, 
  next = 0x0, 
  prev = 0x87d33c0, 
  ascii_face = 0x8596d68
}
(gdb) n
(gdb) 
(gdb) 
(gdb) n
(gdb) 
(gdb) 
(gdb) 
(gdb) 
(gdb) p *font_info
$14 = {
  font = 0x85ea4a0, 
  font_idx = 1, 
  name = 0x85ea1f8 "-xos4-terminus-medium-r-normal--16-160-72-72-c-80-iso8859-1", 
  full_name = 0x85ea408 "-xos4-Terminus-Medium-R-Normal--16-160-72-72-C-80-ISO8859-1", 
  charset = 0, 
  size = 8, 
  height = 16, 
  space_width = 8, 
  average_width = 8, 
  vertical_centering = 0, 
  encoding = "\000\377", '\0' <repeats 126 times>, '\001' <repeats 127 times>, 
  baseline_offset = 0, 
  relative_compose = 0, 
  default_ascent = 0, 
  font_encoder = 0x0
}
(gdb) n
(gdb) 
(gdb) 
(gdb) 
(gdb) 
(gdb) p *pcm
$15 = {
  lbearing = 1, 
  rbearing = 7, 
  width = 8, 
  ascent = 10, 
  descent = 0, 
  attributes = 0
}
(gdb) 


So somewhere along the road, something has selected a different font (width 8)
for the characters in the header line -- and in the text area of the window,
but the align-to uses the default frame font of width 9 (that's what it has to do).

How can this happen?



To reproduce, get the above font installed, and put this in .Xdefaults:

Emacs.font: -*-terminus-medium-r-*-*-17-*-*-*-*-*-iso8859-1

Then run

emacs -Q ~/tmp/foo.ses

Now hit M-o a few times to add some columns.

and type 1 RET 2 RET 3 RET to insert some data in the sheet.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Default face problem [was: Re: incomplete header-line with 3d boxes and prop fonts]

[Kenichi Handa]

In article <m3aca6lyrz.fsf_-_@kfs-l.imdomain.dk>, storm@cua.dk (Kim F. Storm) writes:

> storm@cua.dk (Kim F. Storm) writes:
>> Sascha Wilde <wilde@sha-bang.de> writes:
>> 
>>>>> I still do see a heavy misalignment of the header line in ses (with
>>>>> X11), but only when using a font with an odd size
>>>>> (-*-terminus-medium-r-*-*-17-*-*-*-*-*-iso8859-1 here).
>> 
>> I see it too.
>> 
>> If I customize the default face, and change the height from 99 to 100,
>> it works again.  I'll look into what's wrong.

This is because the current Emacs refuses to use an
auto-scaled font because it's usually too agree to use for
the editing work.  It at first checks the availability of
the specified font (without checking it's auto-scaled or
not), but, later on deciding a font for a face, it lists
fonts matching with family-name and registry-name, then
selects the best one among them.  On this selection,
auto-scaled font is refused even if scalable-fonts-allowed
is non-nil.  So, in your case the 16-dots font (that is
surely included in terminus font package) is selected.

---
Kenichi Handa
handa@m17n.org

Re: Default face problem

[Stefan Monnier]

> On this selection, auto-scaled font is refused even if
> scalable-fonts-allowed is non-nil.

For what it's worth, "scalable-fonts-allowed" refers to vector-fonts (which
are inherently scalable).  Whereas you're talking about scaling
a bitmap font.


        Stefan

Re: Default face problem

[Kenichi Handa]

In article <87bquicu9k.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> On this selection, auto-scaled font is refused even if
>> scalable-fonts-allowed is non-nil.

> For what it's worth, "scalable-fonts-allowed" refers to vector-fonts (which
> are inherently scalable).  Whereas you're talking about scaling
> a bitmap font.

Here a excerpt from the document of XLFD.

------------------------------------------------------------
PIXEL_SIZE usually incorporates additional vertical spacing 
that is considered part of the font design.
(Note, however, that this value is not necessarily equivalent to the height 
of the font bounding box.)
Zero is used to indicate a scalable font (see section \n(sS)
...
------------------------------------------------------------

So, for X windows, I think this kind of font is also a kind
of scalabe font.
     -xos4-terminus-medium-r-normal--0-0-72-72-c-0-iso8859-1

---
Kenichi Handa
handa@m17n.org

Re: Default face problem

[Stefan Monnier]

>> For what it's worth, "scalable-fonts-allowed" refers to vector-fonts
>> (which are inherently scalable).  Whereas you're talking about scaling
>> a bitmap font.

> So, for X windows, I think this kind of font is also a kind
> of scalabe font.
>      -xos4-terminus-medium-r-normal--0-0-72-72-c-0-iso8859-1

Yes, it is.  But IIRC the font selection mechanism tries to distinguish
between bitmap-scaled and vector-scaled fonts by checking the presence of
another instance of the font, with a non-0 size (i.e. a bitmap font).
It's only a heuristic of course: you could very well have a TrueType font
together with some hand-tuned bitmap versions of it for some specific sizes.
But it avoids the otherwise almost systematic use of the truly hideous
bitmap-scaled fonts.


        Stefan

Re: Default face problem

[Kenichi Handa]

In article <87u08aapx5.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Yes, it is.  But IIRC the font selection mechanism tries to distinguish
> between bitmap-scaled and vector-scaled fonts by checking the presence of
> another instance of the font, with a non-0 size (i.e. a bitmap font).

Which font selection mechanism do you mean here?  At least,
Emacs doesn't do that.  Emacs determines a font is
auto-scaled if it's RESY is not zero and POINT_SIZE is zero.

Yes, it's surely a heuristic, but works for X servers of
XFree86, X.org, and Solaris.

---
Kenichi Handa
handa@m17n.org

Re: Default face problem

[Stefan Monnier]

>> Yes, it is.  But IIRC the font selection mechanism tries to distinguish
>> between bitmap-scaled and vector-scaled fonts by checking the presence of
>> another instance of the font, with a non-0 size (i.e. a bitmap font).

> Which font selection mechanism do you mean here?  At least,
> Emacs doesn't do that.  Emacs determines a font is
> auto-scaled if it's RESY is not zero and POINT_SIZE is zero.

Hmm... maybe I'm confusing things.  At least I remember that at some point,
there was a special case where a bitmap font of a slightly different size
than requested was preferred over a scaled (whether bitmap or vector) font.


        Stefan

Re: Default face problem

[Kenichi Handa]

In article <87vespalwf.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> Yes, it is.  But IIRC the font selection mechanism tries to distinguish
>>> between bitmap-scaled and vector-scaled fonts by checking the presence of
>>> another instance of the font, with a non-0 size (i.e. a bitmap font).

>> Which font selection mechanism do you mean here?  At least,
>> Emacs doesn't do that.  Emacs determines a font is
>> auto-scaled if it's RESY is not zero and POINT_SIZE is zero.

> Hmm... maybe I'm confusing things.  At least I remember that at some point,
> there was a special case where a bitmap font of a slightly different size
> than requested was preferred over a scaled (whether bitmap or vector) font.

Yes.  At least that is true.  The macro
FONT_POINT_SIZE_QUANTUM (defined as 5 in xfaces.c) plays a
role here.  After getting a list of fonts,
best_matching_font () at first checks all bitmap fonts to
find a font matching exactly with the face request.  At that
time, the difference of point sizes less than
FONT_POINT_SIZE_QUANTUM is ignored.  And if a exactly
matching (bitmap) font is found, it is returned without
further checking scalable fonts.

---
Kenichi Handa
handa@m17n.org

Re: Default face problem

[Kim F. Storm]

Kenichi Handa <handa@m17n.org> writes:

> In article <m3aca6lyrz.fsf_-_@kfs-l.imdomain.dk>, storm@cua.dk (Kim F. Storm) writes:
>
>> storm@cua.dk (Kim F. Storm) writes:
>>> Sascha Wilde <wilde@sha-bang.de> writes:
>>> 
>>>>>> I still do see a heavy misalignment of the header line in ses (with
>>>>>> X11), but only when using a font with an odd size
>>>>>> (-*-terminus-medium-r-*-*-17-*-*-*-*-*-iso8859-1 here).
>>> 
>>> I see it too.
>>> 
>>> If I customize the default face, and change the height from 99 to 100,
>>> it works again.  I'll look into what's wrong.
>
> This is because the current Emacs refuses to use an
> auto-scaled font because it's usually too agree to use for
> the editing work.  

Thanks for the explanation.  I think I understand.

But why does it think it is ok to use such a font as the
frame's default font?

The problem we see is because the :align-to specs in the header line
are formatted based on the width of the frame's default font, but if
the default font is not used in the frame text, the result is very
confusing.


>                    It at first checks the availability of
> the specified font (without checking it's auto-scaled or
> not), but, later on deciding a font for a face, it lists
> fonts matching with family-name and registry-name, then
> selects the best one among them.  

Wouldn't it make sense to fix the frame's default font at this
step (eg. in realize_basic_faces) when it is detected that
the specified default font is "not available".

The test could be something like this (pseudo-code) inserted
just after realizing the default face:

if (frame->default_face->font != frame->default_font)
  frame->default_font = frame->default_face->font;


>                                   On this selection,
> auto-scaled font is refused even if scalable-fonts-allowed
> is non-nil.  So, in your case the 16-dots font (that is
> surely included in terminus font package) is selected.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Default face problem

[Stefan Monnier]

> if (frame->default_face->font != frame->default_font)
>   frame->default_font = frame->default_face->font;

Which is equivalent to just

  frame->default_font = frame->default_face->font;


-- Stefan

Re: Default face problem

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> if (frame->default_face->font != frame->default_font)
>>   frame->default_font = frame->default_face->font;
>
> Which is equivalent to just
>
>   frame->default_font = frame->default_face->font;

Touche :-)

IIRC, setting the frame default font is a little
more trick than a mere assignment, so I should have written:

 if (frame->default_face->font != frame->default_font)
   set_frame_default_font(frame, frame->default_face->font;


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Default face problem

[Kenichi Handa]

In article <m3odyib17x.fsf@kfs-l.imdomain.dk>, storm@cua.dk (Kim F. Storm) writes:

> But why does it think it is ok to use such a font as the
> frame's default font?

I don't know why.  Perhaps, Gerd just overlooked such a
possibility.

> The problem we see is because the :align-to specs in the header line
> are formatted based on the width of the frame's default font, but if
> the default font is not used in the frame text, the result is very
> confusing.

I see.

> Wouldn't it make sense to fix the frame's default font at this
> step (eg. in realize_basic_faces) when it is detected that
> the specified default font is "not available".

I agree.

> IIRC, setting the frame default font is a little
> more trick than a mere assignment, so I should have written:
> 
>  if (frame->default_face->font != frame->default_font)
>    set_frame_default_font(frame, frame->default_face->font;

Where is set_frame_default_font?

---
Kenichi Handa
handa@m17n.org

Re: Default face problem

[Kim F. Storm]

Kenichi Handa <handa@m17n.org> writes:

>> Wouldn't it make sense to fix the frame's default font at this
>> step (eg. in realize_basic_faces) when it is detected that
>> the specified default font is "not available".
>
> I agree.
>
>> IIRC, setting the frame default font is a little
>> more trick than a mere assignment, so I should have written:
>> 
>>  if (frame->default_face->font != frame->default_font)
>>    set_frame_default_font(frame, frame->default_face->font;
>
> Where is set_frame_default_font?

I don't know :-)  Those two lines are pseudo-code...

I'm not a font expert, so I was hoping somebody knew the 
correct way to do this.

I guess x_set_font in frame.c need to be involved somehow.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Default face problem

[Kenichi Handa]

In article <m34q00vr75.fsf@kfs-l.imdomain.dk>, storm@cua.dk (Kim F. Storm) writes:
>>> if (frame->default_face->font != frame->default_font)
>>> set_frame_default_font(frame, frame->default_face->font;
>> 
>> Where is set_frame_default_font?

> I don't know :-)  Those two lines are pseudo-code...

> I'm not a font expert, so I was hoping somebody knew the 
> correct way to do this.

> I guess x_set_font in frame.c need to be involved somehow.

When a font-related attribute of the default face is
changed, set_font_frame_param (xfaces.c) is called.  So,
perhaps calling it or simulating what it does is the right
thing.

---
Kenichi Handa
handa@m17n.org

Re: Default face problem

[Kim F. Storm]

Kenichi Handa <handa@m17n.org> writes:

> When a font-related attribute of the default face is
> changed, set_font_frame_param (xfaces.c) is called.  So,
> perhaps calling it or simulating what it does is the right
> thing.

Well, the Fmodify_frame_parameters call in that function
will cause a call to x_set_font.

x_set_font calls recompute_basic_faces which calls
realize_basic_faces, which calls realize_default_face.

To me, it sound like realize_default_face would be a good
place to fix this, but I'm not an expert on this.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Default face problem

[Kenichi Handa]

In article <m3r734u2s5.fsf@kfs-l.imdomain.dk>, storm@cua.dk (Kim F. Storm) writes:

> Kenichi Handa <handa@m17n.org> writes:
>> When a font-related attribute of the default face is
>> changed, set_font_frame_param (xfaces.c) is called.  So,
>> perhaps calling it or simulating what it does is the right
>> thing.

> Well, the Fmodify_frame_parameters call in that function
> will cause a call to x_set_font.

> x_set_font calls recompute_basic_faces which calls
> realize_basic_faces, which calls realize_default_face.

Ummm.

> To me, it sound like realize_default_face would be a good
> place to fix this, but I'm not an expert on this.

It seems that there's no expert other than Gerd.

Anyway, I've just tried this patch along your idea.

*** xfaces.c	13 Apr 2006 09:46:44 +0900	1.345
--- xfaces.c	10 May 2006 13:06:28 +0900	
***************
*** 7072,7077 ****
--- 7072,7087 ----
    check_lface (lface);
    bcopy (XVECTOR (lface)->contents, attrs, sizeof attrs);
    face = realize_face (c, attrs, 0, NULL, DEFAULT_FACE_ID);
+ 
+ #ifdef HAVE_WINDOW_SYSTEM
+ #ifdef HAVE_X_WINDOWS  
+   if (face->font != FRAME_FONT (f))
+     /* As the font specified for the frame was not acceptable as a
+        font for the default face (perhaps because auto-scaled fonts
+        are rejected), we must adjust the frame font.  */
+     x_set_font (f, build_string (face->font_name), Qnil);
+ #endif	/* HAVE_X_WINDOWS */
+ #endif	/* HAVE_WINDOW_SYSTEM */
    return 1;
  }
  
It seems that it works well.  I tried:
% emacs -fn -*-terminus-medium-r-*-*-17-*-*-*-*-*-iso8859-1
and did M-x ses-mode.  Column alignment seems to be correct
now.

But, I really don't know if it's ok to call
recompute_basic_faces recursively.  Could you also test and
verify it?

---
Kenichi Handa
handa@m17n.org

Re: Default face problem

[Kim F. Storm]

Kenichi Handa <handa@m17n.org> writes:

> But, I really don't know if it's ok to call
> recompute_basic_faces recursively.  Could you also test and
> verify it?

It works for me too.

Looking at the code, it seems to be safe.

--
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Default face problem

[Kenichi Handa]

In article <m3ejz2m5o0.fsf@kfs-l.imdomain.dk>, storm@cua.dk (Kim F. Storm) writes:

> Kenichi Handa <handa@m17n.org> writes:
>> But, I really don't know if it's ok to call
>> recompute_basic_faces recursively.  Could you also test and
>> verify it?

> It works for me too.

> Looking at the code, it seems to be safe.

Thank you for checking it.  I've just installed the patch.
Perhaps, "#ifdef HAVE_X_WINDOWS ... #endif" is not
necessary, but I can't test it on the other platform, and it
seems that this problem happens only on X.

---
Kenichi Handa
handa@m17n.org

Re: Default face problem

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> Date: Wed, 10 May 2006 21:41:26 +0900
> Cc: wilde@sha-bang.de, jyavner@member.fsf.org, emacs-devel@gnu.org, rms@gnu.org,
> 	monnier@iro.umontreal.ca
> 
> Perhaps, "#ifdef HAVE_X_WINDOWS ... #endif" is not
> necessary, but I can't test it on the other platform, and it
> seems that this problem happens only on X.

If you tell me how to reproduce it, I could try it on MS-Windows.

Re: Default face problem

[Kenichi Handa]

In article <ur73193kv.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

>> Perhaps, "#ifdef HAVE_X_WINDOWS ... #endif" is not
>> necessary, but I can't test it on the other platform, and it
>> seems that this problem happens only on X.

> If you tell me how to reproduce it, I could try it on MS-Windows.

I don't know the recipe for MS-Windows.

---
Kenichi Handa
handa@m17n.org

Re: Default face problem

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> CC: wilde@sha-bang.de, jyavner@member.fsf.org, emacs-devel@gnu.org
> Date: Thu, 11 May 2006 09:36:20 +0900
> 
> In article <ur73193kv.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Perhaps, "#ifdef HAVE_X_WINDOWS ... #endif" is not
> >> necessary, but I can't test it on the other platform, and it
> >> seems that this problem happens only on X.
> 
> > If you tell me how to reproduce it, I could try it on MS-Windows.
> 
> I don't know the recipe for MS-Windows.

What is the recipe for X?

Re: Default face problem

[Kenichi Handa]

In article <ud5el8c0h.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

>> From: Kenichi Handa <handa@m17n.org>
>> CC: wilde@sha-bang.de, jyavner@member.fsf.org, emacs-devel@gnu.org
>> Date: Thu, 11 May 2006 09:36:20 +0900
>> 
>> In article <ur73193kv.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> Perhaps, "#ifdef HAVE_X_WINDOWS ... #endif" is not
>> >> necessary, but I can't test it on the other platform, and it
>> >> seems that this problem happens only on X.
>> 
>> > If you tell me how to reproduce it, I could try it on MS-Windows.
>> 
>> I don't know the recipe for MS-Windows.

> What is the recipe for X?

Start emacs by specifying a bitmap font with non-existing
size.  For instance, if you have these fonts,

% xlsfonts -fn -etl-fixed-medium-r-normal-*-iso8859-1
-etl-fixed-medium-r-normal--0-0-72-72-c-0-iso8859-1
-etl-fixed-medium-r-normal--14-140-72-72-c-70-iso8859-1
-etl-fixed-medium-r-normal--16-160-72-72-c-80-iso8859-1
-etl-fixed-medium-r-normal--18-180-72-72-c-90-iso8859-1
-etl-fixed-medium-r-normal--24-240-72-72-c-120-iso8859-1

start Emacs as this:
% emacs -fn -etl-fixed-medium-r-normal--17-*-*-*-*-*-iso8859-1

X server can open a font auto-scaled from one of the
existing bitmap fonts.  But, such a font is rejected while
choosing a font for the default face, which leads to
mismatch of the frame font and the default face font.

The fix is to the adjust frame's font to what chosen for the
default face font in such a case.

---
Kenichi Handa
handa@m17n.org

Re: Default face problem

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> CC: wilde@sha-bang.de, jyavner@member.fsf.org, emacs-devel@gnu.org
> Date: Thu, 11 May 2006 13:35:16 +0900
> 
> Start emacs by specifying a bitmap font with non-existing
> size.  For instance, if you have these fonts,
> 
> % xlsfonts -fn -etl-fixed-medium-r-normal-*-iso8859-1
> -etl-fixed-medium-r-normal--0-0-72-72-c-0-iso8859-1
> -etl-fixed-medium-r-normal--14-140-72-72-c-70-iso8859-1
> -etl-fixed-medium-r-normal--16-160-72-72-c-80-iso8859-1
> -etl-fixed-medium-r-normal--18-180-72-72-c-90-iso8859-1
> -etl-fixed-medium-r-normal--24-240-72-72-c-120-iso8859-1
> 
> start Emacs as this:
> % emacs -fn -etl-fixed-medium-r-normal--17-*-*-*-*-*-iso8859-1

When I try this, I get an error message, e.g.:

  No fonts match `-raster-System-bold-r-normal-normal-12-*-*-*-*-*-*'

This comes from faces.el:x-resolve-font-name, because on w32,
x-list-fonts returns nil for a pattern that has no matches.

Does this mean this problem will never happen on w32, or should I try
something else?

Re: Default face problem

[Kenichi Handa]

In article <uody25b4h.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

>> % xlsfonts -fn -etl-fixed-medium-r-normal-*-iso8859-1
>> -etl-fixed-medium-r-normal--0-0-72-72-c-0-iso8859-1
>> -etl-fixed-medium-r-normal--14-140-72-72-c-70-iso8859-1
>> -etl-fixed-medium-r-normal--16-160-72-72-c-80-iso8859-1
>> -etl-fixed-medium-r-normal--18-180-72-72-c-90-iso8859-1
>> -etl-fixed-medium-r-normal--24-240-72-72-c-120-iso8859-1
>> 
>> start Emacs as this:
>> % emacs -fn -etl-fixed-medium-r-normal--17-*-*-*-*-*-iso8859-1

> When I try this, I get an error message, e.g.:

>   No fonts match `-raster-System-bold-r-normal-normal-12-*-*-*-*-*-*'

> This comes from faces.el:x-resolve-font-name, because on w32,
> x-list-fonts returns nil for a pattern that has no matches.

On X also, x-list-fonts returns nil for a pattern that has
no matches.  The problem is that X server thinks that it has
the font -etl-fixed-medium-r-normal--17-*-*-*-*-*-iso8859-1.

> Does this mean this problem will never happen on w32, or should I try
> something else?

Sorry, but I have no idea.

---
Kenichi Handa
handa@m17n.org

Re: Default face problem

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> CC: wilde@sha-bang.de, jyavner@member.fsf.org, emacs-devel@gnu.org
> Date: Mon, 15 May 2006 10:41:28 +0900
> 
> >> start Emacs as this:
> >> % emacs -fn -etl-fixed-medium-r-normal--17-*-*-*-*-*-iso8859-1
> 
> > When I try this, I get an error message, e.g.:
> 
> >   No fonts match `-raster-System-bold-r-normal-normal-12-*-*-*-*-*-*'
> 
> > This comes from faces.el:x-resolve-font-name, because on w32,
> > x-list-fonts returns nil for a pattern that has no matches.
> 
> On X also, x-list-fonts returns nil for a pattern that has
> no matches.  The problem is that X server thinks that it has
> the font -etl-fixed-medium-r-normal--17-*-*-*-*-*-iso8859-1.

Sorry, I don't understand your last sentence.  If x-list-fonts returns
nil, Emacs will not start at all, it prints the above error message
and exits immediately (at least that's what happens on w32).  So what
problem happens on X due to the fact that ``X server thinks that it
has the font -etl-fixed-medium-r-normal--17-*-*-*-*-*-iso8859-1''?

Or does Emacs start on X even though x-list-fonts returns nil?

Re: Default face problem

[Kenichi Handa]

In article <uac9k3qth.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

>> On X also, x-list-fonts returns nil for a pattern that has
>> no matches.  The problem is that X server thinks that it has
>> the font -etl-fixed-medium-r-normal--17-*-*-*-*-*-iso8859-1.

> Sorry, I don't understand your last sentence.  If x-list-fonts returns
> nil, Emacs will not start at all, it prints the above error message
> and exits immediately (at least that's what happens on
> w32).

Yes.

> So what problem happens on X due to the fact that ``X
> server thinks that it has the font
> -etl-fixed-medium-r-normal--17-*-*-*-*-*-iso8859-1''?

I've already written the reason.  In short, because, on
deciding the default face's font, the current code refuses
to use such an auto-scaled font.  Please check my previous
mails for detail.

If Windows never provide an auto-scaled font, it doesn't
have the current problem.

---
Kenichi Handa
handa@m17n.org

Re: Default face problem

[Eli Zaretskii]

> From: Kenichi Handa <handa@m17n.org>
> Date: Wed, 10 May 2006 13:17:56 +0900
> Cc: wilde@sha-bang.de, jyavner@member.fsf.org, emacs-devel@gnu.org, rms@gnu.org,
> 	monnier@iro.umontreal.ca
> 
> In article <m3r734u2s5.fsf@kfs-l.imdomain.dk>, storm@cua.dk (Kim F. Storm) writes:
> 
> It seems that there's no expert other than Gerd.

Why not ask him, then?

Re: incomplete header-line with 3d boxes and prop fonts

[Stefan Monnier]

>     But the result (in ses-mode) isn't pleasing ... the cell contents gets
>     more and more misaligned with the header line.  I tracked this to a
>     problem with the calculation of the size of a :box'ed stretch glyph.

> If the bug in ses.el is obvious, can you fix it?  If not, would you
> like the maintainer of ses.el to fix it?  I have cc'd him.

I'm to blame for this part of SES's code.


        Stefan