bug#4090: Bug#541704: emacs-snapshot ruins w3m-el-snapshot tables

bug#4090: Bug#541704: emacs-snapshot ruins w3m-el-snapshot tables

[jidanni]

One notes an additional problem with the two images I just posted.
You will notice that gimp assumes the icewm toolbar is part of
emacs-snapshot. That is because emacs-snapshot extends beyond the bottom
of the screen, underneath the icewm toolbar! emacs23 does not have this
problem. The problem is related to the emacs-snapshot toolbar at the top
of the screen pushing the minibuffer under the icewm toolbar at the
bottom of the screen. One needs to hit ALT F10 to be able to use
emacs-snapshot with the minibuffer properly visible.

bug#4090: Bug#541704: emacs-snapshot ruins w3m-el-snapshot tables

[Kenichi Handa]

In article <87hbw5yoc4.fsf@jidanni.org>, jidanni@jidanni.org writes:

> OK, here is what I see using the current Debian versions of these packages.

Thank you.

> It turns out the C-u C-x = output is
>   xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-14-*-*-*-m-0-iso10646-1
> for all cases, in contrast to what I reported earlier.

I'm very very confused.  Why does Emacs start to use the
different font?  Did you change some font setting (or
install/uninstall some fonts) after your previous report?

By the way, that font has all box-drawing characters.  I
have no idea why Emacs can't draw them even if that font is
selected.

---
Kenichi Handa
handa@m17n.org

bug#4090: [emacs-w3m:10999] Re: bug#4090: Bug#541704: emacs-snapshot ruins w3m-el-snapshot tables

[Hideyuki SHIRAI]

From: jidanni@jidanni.org said
Subject: [emacs-w3m:10999] Re: bug#4090: Bug#541704: emacs-snapshot ruins w3m-el-snapshot tables
Message-ID: <87hbw5yoc4.fsf@jidanni.org>
Date: Wed, 19 Aug 2009 02:22:03 +0800

> OK, here is what I see using the current Debian versions of these packages.

Thank you for your report.

There is a possibility for this problem to occur with emacs23 or
later. A problem occurs for the width of the box drawing
character changed. So, calculation of string-width goes miss,
and it becomes for that like your image.


For example 
(BOX DRAWINGS LIGHT VERTICAL AND HORIZONTAL, #x253c)
・Emacs22.3
(char-width (make-char 'mule-unicode-2500-33ff 32 92)) => 1

・Emacs23.1
(char-width (make-char 'mule-unicode-2500-33ff 32 92)) => 2


It is very difficult to correct this problem on all
emacsen. Therefore, please use emacs-w3m because of the
following settings. 

(setq w3m-use-symbol nil)

This change was commited to CVS HEAD of emacs-w3m.

TNX.

-- 
Hideyuki SHIRAI (mailto:shirai@meadowy.org)

bug#4090: [emacs-w3m:10999] Re: bug#4090: Bug#541704: emacs-snapshot ruins w3m-el-snapshot tables

[Kenichi Handa]

In article <20090819.151543.04477307.shirai.hideyuki@meadowy.org>, Hideyuki SHIRAI (=?iso-2022-jp?B?GyRCR3IwZj0oOVQbKEI=?=) <shirai@meadowy.org> writes:

> For example 
> (BOX DRAWINGS LIGHT VERTICAL AND HORIZONTAL, #x253c)
> ・Emacs22.3
> (char-width (make-char 'mule-unicode-2500-33ff 32 92)) => 1

> ・Emacs23.1
> (char-width (make-char 'mule-unicode-2500-33ff 32 92)) => 2

FYI, with Emacs 23, in non-CJK environment, that value is 1.

---
Kenichi Handa
handa@m17n.org

bug#4090: Bug#541704: emacs-snapshot ruins w3m-el-snapshot tables

[jidanni]

>>>>> "K" == Kenichi Handa <handa@m17n.org> writes:

K> In the trunk of CVS, I added CJK fonts for those box-drawing
K> characters in the default fontset.  So, in CJK environment,
K> CJK fonts are preferred.  Perhaps, the selected CJK font
K> claims that it has glyphs for those characters, but actually
K> doesn't contain valid glyphs.  I think those vanishing
K> characters has at least 1 dot width of space.  Please put
K> cursor on one of them and type C-u C-x = to check which font
K> is selected for it.

>> • │ ┌ ┐ └ ┘ ├ ┤ ┬ ┴ ┼
In emacs23, all are visible, and very nice
   x:-efont-fixed-medium-r-normal--16-160-75-75-c-80-iso10646-1
In emacs-snapshot all are invisible in w3m-el-snapshot, but visible but
ugly replying here in gnus.  "•" is the same
   x:-efont-fixed-medium-r-normal--16-160-75-75-c-80-iso10646-1
but all the rest are
   x:-eten-fixed-medium-r-normal--16-150-75-75-c-160-big5.eten-0

bug#4090: Bug#541704: emacs-snapshot ruins w3m-el-snapshot tables

[Kenichi Handa]

In article <873a7poeoy.fsf@jidanni.org>, jidanni@jidanni.org writes:

>>>>>> "K" == Kenichi Handa <handa@m17n.org> writes:
>>> In the trunk of CVS, I added CJK fonts for those box-drawing
>>> characters in the default fontset.  So, in CJK environment,
>>> CJK fonts are preferred.  Perhaps, the selected CJK font
>>> claims that it has glyphs for those characters, but actually
>>> doesn't contain valid glyphs.  I think those vanishing
>>> characters has at least 1 dot width of space.  Please put
>>> cursor on one of them and type C-u C-x = to check which font
>>> is selected for it.

>>> • │ ┌ ┐ └ ┘ ├ ┤ ┬ ┴ ┼
> In emacs23, all are visible, and very nice
>    x:-efont-fixed-medium-r-normal--16-160-75-75-c-80-iso10646-1
> In emacs-snapshot all are invisible in w3m-el-snapshot, but visible but
> ugly replying here in gnus.  "•" is the same
>    x:-efont-fixed-medium-r-normal--16-160-75-75-c-80-iso10646-1
> but all the rest are
>    x:-eten-fixed-medium-r-normal--16-150-75-75-c-160-big5.eten-0

Your answer is too terse for me to understand your situation
correctly.  Do you mean that the same font:
   x:-eten-fixed-medium-r-normal--16-150-75-75-c-160-big5.eten-0
is selected for "│┌..." in the invisible case and in the
ugly case?  And what do you mean by "ugly"?  Isn't it
possible to provide the screen-shot of that ugly case?

---
Kenichi Handa
handa@m17n.org

bug#4090: Bug#541704: emacs-snapshot ruins w3m-el-snapshot tables

[jidanni]

Package: emacs-snapshot
Version: 1:20090814-1
X-debbugs-cc: 4090@emacsbugs.donarmstrong.com, emacs-w3m@namazu.org,naota@elisp.net, svenjoac@gmx.de

On Debian, using versions
emacs-snapshot 1:20090814-1
emacs23: 23.1+1-2
set /tmp/f.html
cat <<EOF > $@
<table border="1"><tr><td>bla</td></tr></table>
EOF
LC_ALL=zh_TW.UTF-8 emacs-snapshot -f w3m $@ # bad
LC_ALL=C           emacs-snapshot -f w3m $@ # good
LC_ALL=zh_TW.UTF-8 emacs23        -f w3m $@ # good
LC_ALL=C           emacs23        -f w3m $@ # good

One sees that these characters,
 • │ ┌ ┐ └ ┘ ├ ┤ ┬ ┴ ┼
vanish in the above "bad" case.

I.e.,
┌───┐
│bla│
└───┘
becomes
─
bla
─

It makes w3m-emacs unusable for browsing any web page with tables.

Can even reproduce with
$ HOME=/tmp LC_ALL=zh_TW.UTF-8 emacs-snapshot -Q -l w3m -f w3m $@ # bad

Also installed is w3m-el-snapshot
Version: 1.4.364+0.20090802-1

bug#4090: Bug#541704: emacs-snapshot ruins w3m-el-snapshot tables

[Kenichi Handa]

In article <87r5vdos8q.fsf@jidanni.org>, jidanni@jidanni.org writes:

> LC_ALL=zh_TW.UTF-8 emacs-snapshot -f w3m $@ # bad
> LC_ALL=C           emacs-snapshot -f w3m $@ # good
> LC_ALL=zh_TW.UTF-8 emacs23        -f w3m $@ # good
> LC_ALL=C           emacs23        -f w3m $@ # good

> One sees that these characters,
>  • │ ┌ ┐ └ ┘ ├ ┤ ┬ ┴ ┼
> vanish in the above "bad" case.

> I.e.,
> ┌───┐
> │bla│
> └───┘
> becomes
> ─
> bla
> ─

In the trunk of CVS, I added CJK fonts for those box-drawing
characters in the default fontset.  So, in CJK environment,
CJK fonts are preferred.  Perhaps, the selected CJK font
claims that it has glyphs for those characters, but actually
doesn't contain valid glyphs.  I think those vanishing
characters has at least 1 dot width of space.  Please put
cursor on one of them and type C-u C-x = to check which font
is selected for it.

---
Kenichi Handa
handa@m17n.org