Bug on Summary line.

Bug on Summary line.

[Jinhyok Heo]

Hi, all.

In summary line, the somewhat trimmed posters' names are displayed. The
names are trimmed by a defined number of characters, not a byte of
them. It can cause a problem when using two byte
characters(e.g. Korean, Japanese, Chinese). The two-byte character is
counted the same as one one-byte character, but it take double space.
So the summary lines are not aligned correctly when there are two-byte
characters.

How can I fix it?

-- 
|  Jinhyok Heo            mailto : novembre @ournature.org
|                         whoami : <http://ournature.org/~novembre/>
|  "We are still reaching for the sky. In the developed countries people
|  are coming back down, saying, `It's empty up there.'" --- a Ladakhi monk

Re: Bug on Summary line.

[ShengHuo ZHU]

Jinhyok Heo <novembreN0$PAM@ournature.org> writes:

> Hi, all.
> 
> In summary line, the somewhat trimmed posters' names are displayed. The
> names are trimmed by a defined number of characters, not a byte of
> them. It can cause a problem when using two byte
> characters(e.g. Korean, Japanese, Chinese). The two-byte character is
> counted the same as one one-byte character, but it take double space.
> So the summary lines are not aligned correctly when there are two-byte
> characters.
> 
> How can I fix it?

Probably, no solution. Does anyone how to efficiently calculate string
width in pixels?

ShengHuo

Re: Bug on Summary line.

[Daniel Pittman]

On Wed, 25 Jul 2001, ShengHuo ZHU wrote:
> Jinhyok Heo <novembreN0$PAM@ournature.org> writes:
>> In summary line, the somewhat trimmed posters' names are displayed. 
>> The names are trimmed by a defined number of characters, not a byte
>> of them. It can cause a problem when using two byte characters(e.g. 
>> Korean, Japanese, Chinese). The two-byte character is counted the
>> same as one one-byte character, but it take double space. So the
>> summary lines are not aligned correctly when there are two-byte
>> characters.
>> 
>> How can I fix it?
> 
> Probably, no solution. Does anyone how to efficiently calculate string
> width in pixels?

`char-width' gives you the number of columns that a character fills.
It's not the number of pixels but it's probably enough to be able to fix
the single/double width thang...

        Daniel

-- 
The revolution WILL be televised, but you'll only be able to
understand it if you don't watch the television coverage.
        -- Russ Nelson

Re: Bug on Summary line.

[Jinhyok Heo]

>>>>> "DP" == Daniel Pittman <daniel@rimspace.net> writes:

    DP> `char-width' gives you the number of columns that a character
    DP> fills.  It's not the number of pixels but it's probably enough
    DP> to be able to fix the single/double width thang...

You mean it can be fixed in a easy way? Could you give me some more
hints?

-- 
|  Jinhyok Heo            mailto : novembre @ournature.org
|                         whoami : <http://ournature.org/~novembre/>
|  "We are still reaching for the sky. In the developed countries people
|  are coming back down, saying, `It's empty up there.'" --- a Ladakhi monk

Re: Bug on Summary line.

[Daniel Pittman]

On Fri, 03 Aug 2001, Jinhyok Heo wrote:
>>>>>> "DP" == Daniel Pittman <daniel@rimspace.net> writes:
> 
>     DP> `char-width' gives you the number of columns that a character
>     DP> fills.  It's not the number of pixels but it's probably enough
>     DP> to be able to fix the single/double width thang...
> 
> You mean it can be fixed in a easy way? 

Er, no. I mean that it can be fixed for the case of double-width
characters in a manner that is portable across the current release
versions of Emacs and XEmacs.

Which, I should point out, is different from easy.

> Could you give me some more hints?

Sure. The real problem you have is that the width of the strings
displayed in a double-width font is different per-character to that of a
single-width font. This means that some Asian[1] characters spill out of
a max and cut specification.

This is because the `%-20,20' style specifications work in characters,
not columns. The summary buffer display, however, is a fixed *column*
width display.

As such, a character that is not one column wide spills further than it
should. For most characters, you have `(= 1 (char-width ch))'. For
double-width characters, that is actually `(= 2 (char-width ch))'.

So, what you want to do is go into `gnus-spec.el' and find the functions
`gnus-tilde-max-form' and `gnus-tilde-cut-form'. They are, for
reference, on lines 249 and 265.

You then want to rewrite those so that, rather than using `substring',
they use something akin to `truncate-string-to-width', `string-width'
and `char-width'.

That way you will treat the numbers specified as /column/ widths, not
character widths. That way Gnus will just do what people mean[2] with
regards the width specifications there.

Of course, the XEmacs sources note that `truncate-string-to-width' is
not always compatible between XEmacs and GNU Emacs, and it's sitting in
the less-favored section of the code...

Good luck. It's probably not as hard as it sounds.
        Daniel


Footnotes: 
[1]  Possibly others, but I don't know where.

[2]  Assuming, of course, that they assume what I do. :)

-- 
Romance is rape embellished with meaningful looks.
        -- Andrea Dworkin, _Philadelphia Inquirer_, May 21, 1995

Re: Bug on Summary line.

[Kai Großjohann]

On 04 Aug 2001, Daniel Pittman wrote:

> This is because the `%-20,20' style specifications work in
> characters, not columns. The summary buffer display, however, is a
> fixed *column* width display.
> 
> As such, a character that is not one column wide spills further than
> it should. For most characters, you have `(= 1 (char-width
> ch))'. For double-width characters, that is actually `(= 2
> (char-width ch))'.
> 
> So, what you want to do is go into `gnus-spec.el' and find the
> functions `gnus-tilde-max-form' and `gnus-tilde-cut-form'. They are,
> for reference, on lines 249 and 265.
> 
> You then want to rewrite those so that, rather than using
> `substring', they use something akin to `truncate-string-to-width',
> `string-width' and `char-width'.

Why not change the code that deals with `%-20,20' to grok wide chars?
IMVHO, that would be the right thing to do.  After all, suppose
somebody has a tab character somewhere...

kai
-- 
~/.signature: No such file or directory

Re: Bug on Summary line.

[ShengHuo ZHU]

Daniel Pittman <daniel@rimspace.net> writes:

> As such, a character that is not one column wide spills further than it
> should. For most characters, you have `(= 1 (char-width ch))'. For
> double-width characters, that is actually `(= 2 (char-width ch))'.
> 
> So, what you want to do is go into `gnus-spec.el' and find the functions
> `gnus-tilde-max-form' and `gnus-tilde-cut-form'. They are, for
> reference, on lines 249 and 265.
> 
> You then want to rewrite those so that, rather than using `substring',
> they use something akin to `truncate-string-to-width', `string-width'
> and `char-width'.

truncate-string-to-width and string-width don't work, at least in
Emacs 21.  I've tried use them to fixed the problem before.  Using
char-width might slow down listing the summary :-(.

ShengHuo

Re: Bug on Summary line.

[Daniel Pittman]

On Fri, 03 Aug 2001, Kai Großjohann wrote:
> On 04 Aug 2001, Daniel Pittman wrote:
> 
>> This is because the `%-20,20' style specifications work in
>> characters, not columns. The summary buffer display, however, is a
>> fixed *column* width display.
>> 
>> As such, a character that is not one column wide spills further than
>> it should. For most characters, you have `(= 1 (char-width
>> ch))'. For double-width characters, that is actually `(= 2
>> (char-width ch))'.
>> 
>> So, what you want to do is go into `gnus-spec.el' and find the
>> functions `gnus-tilde-max-form' and `gnus-tilde-cut-form'. They are,
>> for reference, on lines 249 and 265.
>> 
>> You then want to rewrite those so that, rather than using
>> `substring', they use something akin to `truncate-string-to-width',
>> `string-width' and `char-width'.
> 
> Why not change the code that deals with `%-20,20' to grok wide chars?

That's what I was suggesting, Kai. The %-20,20 form is shorthand for
%~(cut 20)~(max 20), unless I misread something in the code. :)

> IMVHO, that would be the right thing to do.  After all, suppose
> somebody has a tab character somewhere...

Ack. TAB? I don't know *any* way to make TAB show up correctly. You
would need to specially detect it. At least, that's the case under
XEmacs -- TAB has a char-width of 1.

        Daniel

-- 
Two hundred francs for sanctuary and she led me by the hand
To a room of dancing shadows where all the heartache disappears
And from the glowing tongues of candles I heard her whisper in my ear.
«J'éntend ton coeur»
        -- Marillion, _Bitter Suite (III)_ (Misplaced Childhood)

Re: Bug on Summary line.

[Daniel Pittman]

On Fri, 03 Aug 2001, ShengHuo ZHU wrote:
> Daniel Pittman <daniel@rimspace.net> writes:

[...]

>> You then want to rewrite those so that, rather than using
>> `substring', they use something akin to `truncate-string-to-width',
>> `string-width' and `char-width'.
> 
> truncate-string-to-width and string-width don't work, at least in
> Emacs 21.  I've tried use them to fixed the problem before.  Using
> char-width might slow down listing the summary :-(.

*sigh*  Well, that sucks. It's implemented as a loop counting the total
of `char-width' for each character under XEmacs and it *seems* to get it
right...

...which makes this a real PITA. At least it's not too much of a problem
for me.
        Daniel

-- 
When you realize you want to spend the rest of your life with
somebody, you want the rest of your life to start as soon as possible.
        -- Billy Crystal

Re: Bug on Summary line.

[Kai Großjohann]

Daniel Pittman <daniel@rimspace.net> writes:

> On Fri, 03 Aug 2001, Kai Großjohann wrote:
>
>> Why not change the code that deals with `%-20,20' to grok wide chars?
> 
> That's what I was suggesting, Kai. The %-20,20 form is shorthand for
> %~(cut 20)~(max 20), unless I misread something in the code. :)

Oops :-)  Didn't read the code...

>> IMVHO, that would be the right thing to do.  After all, suppose
>> somebody has a tab character somewhere...
> 
> Ack. TAB? I don't know *any* way to make TAB show up correctly. You
> would need to specially detect it. At least, that's the case under
> XEmacs -- TAB has a char-width of 1.

(char-width ?\t) => 8           ; Emacs 21.0.104
                                ; probably Emacs 20.x is the same

kai
-- 
~/.signature: No such file or directory

Re: Bug on Summary line.

[Lars Magne Ingebrigtsen]

ShengHuo ZHU <zsh@cs.rochester.edu> writes:

> truncate-string-to-width and string-width don't work, at least in
> Emacs 21.  I've tried use them to fixed the problem before.  Using
> char-width might slow down listing the summary :-(.

Indeed.  However, we could provide alternative functions for `cut' and
`max' -- `mule-cut' and `mule-max' -- that does things the hard, but
correct way.  (Or by just supplying variables to let users control
this.  Say -- `gnus-format-correct-string-widths' or something.

That way, the users who care about this can choose to take the (for
the moment) performance impact, while the rest can just carry on as
before...

So, does iterating over strings with `char-width' always give the
right answer, in all versions of XEmacs and Emacs, where
(<= emacs-major-version 20) => t?

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Bug on Summary line.

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Indeed.  However, we could provide alternative functions for `cut' and
> `max' -- `mule-cut' and `mule-max' -- that does things the hard, but
> correct way.  (Or by just supplying variables to let users control
> this.  Say -- `gnus-format-correct-string-widths' or something.

I've just implemented the latter.  It even seems to work when the
one-char-wide characters are an uneven multiple of the twice-as-big
characters.

Of course, all of this becomes irrelevant when we start using
proportional fonts.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Bug on Summary line.

[Jinhyok Heo]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

    LMI> I've just implemented the latter.  It even seems to work when the
    LMI> one-char-wide characters are an uneven multiple of the twice-as-big
    LMI> characters.

Hi,

Your implementation is on cvs now? If it is, could you give me some
more hints about using it?

-- 
|  Jinhyok Heo            mailto : novembre @ournature.org
|                         whoami : <http://ournature.org/~novembre/>
|  "We are still reaching for the sky. In the developed countries people
|  are coming back down, saying, `It's empty up there.'" --- a Ladakhi monk

Re: Bug on Summary line.

[Lars Magne Ingebrigtsen]

Jinhyok Heo <novembreN0$PAM@ournature.org> writes:

> Your implementation is on cvs now? If it is, could you give me some
> more hints about using it?

Yes, it's in CVS now.  And it's switched on by default -- I will most
likely switch it off later, but I wanted it to get a thorough testing
first.

It's controlled by the `gnus-use-correct-string-widths' variable.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Bug on Summary line.

[Jinhyok Heo]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

    LMI> Yes, it's in CVS now.  And it's switched on by default -- I
    LMI> will most likely switch it off later, but I wanted it to get
    LMI> a thorough testing first.

    LMI> It's controlled by the `gnus-use-correct-string-widths' variable.

It doesn't seem to work correctly. The current cvs shows me things the
same as before.

-- 
|  Jinhyok Heo            mailto : novembre @ournature.org
|                         whoami : <http://ournature.org/~novembre/>
|  "We are still reaching for the sky. In the developed countries people
|  are coming back down, saying, `It's empty up there.'" --- a Ladakhi monk

Re: Bug on Summary line.

[Lars Magne Ingebrigtsen]

Jinhyok Heo <novembreN0$PAM@ournature.org> writes:

> It doesn't seem to work correctly. The current cvs shows me things the
> same as before.

Hmm...  Perhaps it's a caching problem?  Try setting
`gnus-format-specs' to nil.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Bug on Summary line.

[Jinhyok Heo]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

    LMI> Hmm...  Perhaps it's a caching problem?  Try setting
    LMI> `gnus-format-specs' to nil.

I tried but failed.

My g-s-l-f is like the following line.
(setq gnus-summary-line-format "%U%R %d %4L %(%-14,14n |%B %s%)\n")

Any problem?

-- 
|  Jinhyok Heo            mailto : novembre @ournature.org
|                         whoami : <http://ournature.org/~novembre/>
|  "We are still reaching for the sky. In the developed countries people
|  are coming back down, saying, `It's empty up there.'" --- a Ladakhi monk

Re: Bug on Summary line.

[Lars Magne Ingebrigtsen]

Jinhyok Heo <novembreN0$PAM@ournature.org> writes:

> My g-s-l-f is like the following line.
> (setq gnus-summary-line-format "%U%R %d %4L %(%-14,14n |%B %s%)\n")

That should be ok.

Is your latin font scaled to match your kanji?  That is, is a kanji
character exactly twice as big as a latin character?

On this screen, things don't line up exactly, while at my home machine
everything looks fine.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Bug on Summary line.

[Jinhyok Heo]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

    LMI> Is your latin font scaled to match your kanji?  That is, is a
    LMI> kanji character exactly twice as big as a latin character?

Yes, my Korean font is twice as big as a fixed-width latin character.
I couldn't find any differece after applying your implementaion.

-- 
|  Jinhyok Heo            mailto : novembre @ournature.org
|                         whoami : <http://ournature.org/~novembre/>
|  "We are still reaching for the sky. In the developed countries people
|  are coming back down, saying, `It's empty up there.'" --- a Ladakhi monk

Re: Bug on Summary line.

[Lars Magne Ingebrigtsen]

Jinhyok Heo <novembreN0$PAM@ournature.org> writes:

> Yes, my Korean font is twice as big as a fixed-width latin character.
> I couldn't find any differece after applying your implementaion.

What do the following evaluate to for you?

(gnus-correct-length "안녕하세요")
=> 10

(gnus-correct-substring "안녕하세요" 0 6)
=> "안녕하"

If they eval to the same for you -- what's the value of your
`gnus-summary-line-format-spec' variable?

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Bug on Summary line.

[Jinhyok Heo]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

    LMI> If they eval to the same for you -- what's the value of your
    LMI> `gnus-summary-line-format-spec' variable?

They eval to the same for me.

Any my `gnus-summary-line-format-spec' is set like below.

`gnus-summary-line-format-spec' is a variable declared in Lisp.
  -- loaded from "gnus-spec"

Value: (funcall #<compiled-function nil "...(47)" [gnus-tmp-opening-bracket gnus-tmp-indentation gnus-tmp-score-char gnus-tmp-replied gnus-tmp-unread gnus-tmp-name gnus-put-text-property format "%4d: %-20s" 20 0 " " "\n" gnus-tmp-lines gnus-tmp-closing-bracket gnus-mouse-face-prop gnus-mouse-face gnus-tmp-subject-or-nil] 9>)

-- 
|  Jinhyok Heo            mailto : novembre @ournature.org
|                         whoami : <http://ournature.org/~novembre/>
|  "We are still reaching for the sky. In the developed countries people
|  are coming back down, saying, `It's empty up there.'" --- a Ladakhi monk

Re: Bug on Summary line.

[Lars Magne Ingebrigtsen]

Jinhyok Heo <novembreN0$PAM@ournature.org> writes:

> `gnus-summary-line-format-spec' is a variable declared in Lisp.
>   -- loaded from "gnus-spec"

That's not a correct value -- I think it's cached from somewhere.  Set
it to nil and see whether that helps.

Ah -- now I know what the problem is.  I have to change the
pre-computed value in gnus-spec.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Bug on Summary line.

[Lars Magne Ingebrigtsen]

I take it back.  I don't know what the problem is.  The caching
mechanism looks a bit obscure to me...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Bug on Summary line.

[Jinhyok Heo]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

    LMI> That's not a correct value -- I think it's cached from
    LMI> somewhere.  Set it to nil and see whether that helps.

I did, but didn't help.

    LMI> Ah -- now I know what the problem is.  I have to change the
    LMI> pre-computed value in gnus-spec.

It's getting close, isn't it? :-)

-- 
|  Jinhyok Heo            mailto : novembre @ournature.org
|                         whoami : <http://ournature.org/~novembre/>
|  "We are still reaching for the sky. In the developed countries people
|  are coming back down, saying, `It's empty up there.'" --- a Ladakhi monk

Re: Bug on Summary line.

[Lars Magne Ingebrigtsen]

Jinhyok Heo <novembreN0$PAM@ournature.org> writes:

>     LMI> Ah -- now I know what the problem is.  I have to change the
>     LMI> pre-computed value in gnus-spec.
>
> It's getting close, isn't it? :-)

Could you try with the version in CVS now?

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Bug on Summary line.

[Jinhyok Heo]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

    LMI> Could you try with the version in CVS now?

I tried, but failed.

I tried with setting `gnus-summary-line-format-spec' and
`gnus-format-specs nil' to nil, too.

-- 
|  Jinhyok Heo            mailto : novembre @ournature.org
|                         whoami : <http://ournature.org/~novembre/>
|  "We are still reaching for the sky. In the developed countries people
|  are coming back down, saying, `It's empty up there.'" --- a Ladakhi monk

Re: Bug on Summary line.

[안녕하십니까안녕하세요]

Jinhyok Heo <novembreN0$PAM@ournature.org> writes:

>     LMI> Could you try with the version in CVS now?
>
> I tried, but failed.

Ok...  This is a test mail to see how this looks in the summary
buffer.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Bug on Summary line.

[Lars Magne Ingebrigtsen]

"안녕하십니까안녕하세요" <larsi@gnus.org> writes:

> Ok...  This is a test mail to see how this looks in the summary
> buffer.  :-)

Does this line up for anybody, or does it give everybody a messed-up
summary buffer?

For this to work, your Korean characters have to be twice the width of
your Latin characters.  That is, the following two lines are supposed
to appear to be exactly the same width:

안녕하십니까안녕하세요
1234567890123456789012

(They don't appear that way to me with my current fonts.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Bug on Summary line.

[Karl Kleinpaste]

They don't line up for me, either, but I know little about such font
things.  I'm using *-courier-medium-r-*-*-*-120-*-*-*-*-*-* for my
normal font and intlfonts-1.1 including hangl[gm]{16,24}.pcf.  The
Korean characters appear to be 2 pixels wider than the Latin
characters, so the upper Korean line slowly stretches beyond the lower
Latin line.

Is this simply a matter of picking the right Latin font to
interoperate neatly with the Korean font?  If I used ...-140-...,
would it be OK?

And by the way, when the test mail came through, BBDB asked me whether
I wanted to change "Lars Magne Ingebrigtsen" to "iso-2022-kr". :-)
I wonder if Gnus or BBDB can be made bright enough to skip QP-encoded
names.

Re: Bug on Summary line.

[Charles Sebold]

On 5 Elul 5761, Lars Magne Ingebrigtsen wrote:

> "안녕하십니까안녕하세요" <larsi@gnus.org> writes:
> 
>> Ok...  This is a test mail to see how this looks in the summary
>> buffer.  :-)
> 
> Does this line up for anybody, or does it give everybody a messed-up
> summary buffer?

It works for me.

> For this to work, your Korean characters have to be twice the width of
> your Latin characters.  That is, the following two lines are supposed
> to appear to be exactly the same width:
> 
> 안녕하십니까안녕하세요
> 1234567890123456789012
> 
> (They don't appear that way to me with my current fonts.)

Mine do line up (using 16-pt ETL fixed font with whatever Debian turned
intlfonts into).  Debian Woody's Emacs 20.7.
-- 
Charles Sebold        K'tivah V'chatimah Tovah         5th of Elul, 5761

Re: Bug on Summary line.

[Jorge Godoy]

[-- Attachment #1: Type: text/plain, Size: 594 bytes --]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Does this line up for anybody, or does it give everybody a messed-up
> summary buffer?

It lines up.

> For this to work, your Korean characters have to be twice the width of
> your Latin characters.  That is, the following two lines are supposed
> to appear to be exactly the same width:
>
> 안녕하십니까안녕하세요
> 1234567890123456789012
>
> (They don't appear that way to me with my current fonts.)

They are the same here... 
I use ISO-8859-1 and some Unicode fonts, though. 

-- 
Godoy. <godoy@conectiva.com>

[-- Attachment #2: Type: text/plain, Size: 146 bytes --]


Solutions Developer       - Conectiva Inc. - http://en.conectiva.com
Desenvolvedor de Soluções - Conectiva S.A. - http://www.conectiva.com.br

Re: Bug on Summary line.

[Jinhyok Heo]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

    LMI> "안녕하십니까안녕하세요" <larsi@gnus.org> writes:
    >  Ok...  This is a test mail to see how this looks in the summary
    >  buffer.  :-)

    LMI> Does this line up for anybody, or does it give everybody a
    LMI> messed-up summary buffer?

It doesn't line up for me.

    LMI> For this to work, your Korean characters have to be twice the
    LMI> width of your Latin characters.  That is, the following two
    LMI> lines are supposed to appear to be exactly the same width:

    LMI> 안녕하십니까안녕하세요
    LMI> 1234567890123456789012

These do appear the correct way.

Well, some people on this ding list are reporting that the summary
buffer lines up correctly.

Then, my messed-up summary buffer is due to my wrong .gnus.

Because I'm poor at lisp and just started using gnus about two months
ago, I'm now sure I can find what's wrong with my .gnus. Anyway I'll
try to find out.

Lars, I appreciate your work.

-- 
|  Jinhyok Heo            mailto : novembre @ournature.org
|                         whoami : <http://ournature.org/~novembre/>
|  "We are still reaching for the sky. In the developed countries people
|  are coming back down, saying, `It's empty up there.'" --- a Ladakhi monk

Re: Bug on Summary line.

[Kai Großjohann]

Jinhyok Heo <novembreN0$PAM@ournature.org> writes:

> Well, some people on this ding list are reporting that the summary
> buffer lines up correctly.

With my normal fonts, it doesn't line up.

But creating a new frame from the summary buffer and selecting the "16
dot standard fontset" from the menu gives me something which lines up.

So now I need to learn how to specify my startup fontset such that it
lines up.  I know nothing about these things.

kai
-- 
Symbol's function definition is void: signature

Re: Bug on Summary line.

[Jinhyok Heo]

>>>>> "KG" == Kai Gro^[-Aß^[$)Cjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE> writes:

    KG> But creating a new frame from the summary buffer and selecting
    KG> the "16 dot standard fontset" from the menu gives me something
    KG> which lines up.

I think my problem is not related with wrong fontset. Because my
Korean font is exactly double of the latin font and, of course, they
also fixed fonts.

Thouch I've looked into my .gnus, I don't have any idea why my summary
buffer doesn't line up.

    KG> So now I need to learn how to specify my startup fontset such
    KG> that it lines up.  I know nothing about these things.

Specifying fontset is quite ambiguous to me. Some are defined in
.Xdefaults, and some are in .xemacs/custom.el. I cannot control the
font properties as I wish. Is there any good document or something for
it? Anyway, it's off the topic, I think.

Have a nice weekend~!

-- 
|  Jinhyok Heo            mailto : novembre @ournature.org
|                         whoami : <http://ournature.org/~novembre/>
|  "We are still reaching for the sky. In the developed countries people
|  are coming back down, saying, `It's empty up there.'" --- a Ladakhi monk

Re: Bug on Summary line.

[Yair Friedman (Jerusalem)]

Jinhyok Heo <novembreN0$PAM@ournature.org> writes:

>>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
>     LMI> 안녕하십니까안녕하세요
>     LMI> 1234567890123456789012
>
> These do appear the correct way.

This seems to suggest that the font used by the summary buffer
(gnus-summary-normal-unread-face?) doesn't have Korean characters
double-width, while the article do.

HTH.
--
Yair Friedman.

Re: Bug on Summary line.

[Jinhyok Heo]

>>>>> "CS" == Charles Sebold <csebold@livingtorah.org> writes:

    CS> It works for me.

    CS> Mine do line up (using 16-pt ETL fixed font with whatever
    CS> Debian turned intlfonts into).  Debian Woody's Emacs 20.7.

I suspect my problem is related with XEmacs - I use XEmacs
21.4.4. There were two post that they declare their summary buffer
line up correctly and their headers showed me they were using GNU
Emacs.

-- 
|  Jinhyok Heo            mailto : novembre @ournature.org
|                         whoami : <http://ournature.org/~novembre/>
|  "We are still reaching for the sky. In the developed countries people
|  are coming back down, saying, `It's empty up there.'" --- a Ladakhi monk

Re: Bug on Summary line.

[vvv]

Hi,

Lars wrote:

> Ok...  This is a test mail to see how this looks in the summary
> buffer.  :-)

i do not know how it looks in the summary buffer (reding it not from
gnus now), but the From header of your message definitely looks bad:

From: "=?iso-2022-kr?b?GyQpQw4+SDNnR089SjRPMW4+SDNnR088PD9kDw==?=" <larsi@gnus.org>

Again, encoded-word inside quotes... :-(

There is a class of bugs in gnus which tend to reappear after fixing them forever. :-(((
Maybe we should create gnus testsuite which should be
passed after each patch is applied? :-)

Best,
v.