GNU bug report logs -
#4090
23.1.50; Vertical table separators gone
Previous Next
Reported by: jidanni <at> jidanni.org
Date: Sun, 9 Aug 2009 01:50:04 UTC
Severity: normal
Found in version 1:20090814-1
Done: Glenn Morris <rgm <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 4090 in the body.
You can then email your comments to 4090 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#4090
; Package
emacs
.
(Sun, 09 Aug 2009 01:50:04 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
jidanni <at> jidanni.org
:
New bug report received and forwarded. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Sun, 09 Aug 2009 01:50:05 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):
Vertical table separators ugly enough:
$ set http://jidanni.org/comp/wiki/article-category.html
$ LC_ALL=zh_TW.UTF-8 HOME=/tmp emacs23 -f w3m $@
Now totally gone:
$ LC_ALL=zh_TW.UTF-8 HOME=/tmp emacs-snapshot -f w3m $@
In GNU Emacs 23.1.50.1 (i486-pc-linux-gnu, GTK+ Version 2.16.5)
of 2009-07-31 on elegiac, modified by Debian
w3m-version "w3m/0.5.2" emacs-w3m-version "1.4.364"
One needs emacs-snapshot -nw to see the separators.
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, 4090 <at> emacsbugs.donarmstrong.com, emacs-w3m <at> namazu.org,naota <at> elisp.net, svenjoac <at> gmx.de, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#4090
; Package
emacs
.
(Sat, 15 Aug 2009 18:30:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
jidanni <at> jidanni.org, 541704 <at> bugs.debian.org
:
Extra info received and forwarded to list. Copy sent to
4090 <at> emacsbugs.donarmstrong.com, emacs-w3m <at> namazu.org,naota <at> elisp.net, svenjoac <at> gmx.de, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Sat, 15 Aug 2009 18:30:05 GMT)
Full text and
rfc822 format available.
Message #10 received at 4090 <at> emacsbugs.donarmstrong.com (full text, mbox):
Package: emacs-snapshot
Version: 1:20090814-1
X-debbugs-cc: 4090 <at> debbugs.gnu.org, emacs-w3m <at> namazu.org,naota <at> elisp.net, svenjoac <at> 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
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#4090
; Package
emacs
.
(Thu, 20 Aug 2009 19:59:24 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Kenichi Handa <handa <at> m17n.org>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Thu, 20 Aug 2009 19:59:25 GMT)
Full text and
rfc822 format available.
Message #15 received at 4090 <at> emacsbugs.donarmstrong.com (full text, mbox):
In article <20090819.151543.04477307.shirai.hideyuki <at> meadowy.org>, Hideyuki SHIRAI (=?iso-2022-jp?B?GyRCR3IwZj0oOVQbKEI=?=) <shirai <at> 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 <at> m17n.org
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#4090
; Package
emacs
.
(Thu, 20 Aug 2009 20:17:06 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Kenichi Handa <handa <at> m17n.org>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Thu, 20 Aug 2009 20:17:08 GMT)
Full text and
rfc822 format available.
Message #20 received at 4090 <at> emacsbugs.donarmstrong.com (full text, mbox):
In article <87r5vdos8q.fsf <at> jidanni.org>, jidanni <at> 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 <at> m17n.org
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#4090
; Package
emacs
.
(Thu, 20 Aug 2009 20:17:27 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
jidanni <at> jidanni.org
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Thu, 20 Aug 2009 20:17:28 GMT)
Full text and
rfc822 format available.
Message #25 received at 4090 <at> emacsbugs.donarmstrong.com (full text, mbox):
>>>>> "K" == Kenichi Handa <handa <at> 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
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#4090
; Package
emacs
.
(Thu, 20 Aug 2009 20:17:48 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Kenichi Handa <handa <at> m17n.org>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Thu, 20 Aug 2009 20:17:49 GMT)
Full text and
rfc822 format available.
Message #30 received at 4090 <at> emacsbugs.donarmstrong.com (full text, mbox):
In article <873a7poeoy.fsf <at> jidanni.org>, jidanni <at> jidanni.org writes:
>>>>>> "K" == Kenichi Handa <handa <at> 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 <at> m17n.org
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#4090
; Package
emacs
.
(Thu, 20 Aug 2009 20:18:16 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
jidanni <at> jidanni.org
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Thu, 20 Aug 2009 20:18:21 GMT)
Full text and
rfc822 format available.
Message #35 received at 4090 <at> emacsbugs.donarmstrong.com (full text, mbox):
[Message part 1 (text/plain, inline)]
OK, here is what I see using the current Debian versions of these packages.
$ set http://jidanni.org/comp/wiki/article-category.html
$ LC_ALL=zh_TW.UTF-8 HOME=/tmp emacs-snapshot -f w3m $@
[emacs-snapshot.png (image/png, attachment)]
[Message part 3 (text/plain, inline)]
$ LC_ALL=zh_TW.UTF-8 HOME=/tmp emacs23 -f w3m $@
[emacs23.png (image/png, attachment)]
[Message part 5 (text/plain, inline)]
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.
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#4090
; Package
emacs
.
(Thu, 20 Aug 2009 20:18:44 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
jidanni <at> jidanni.org
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Thu, 20 Aug 2009 20:18:45 GMT)
Full text and
rfc822 format available.
Message #40 received at 4090 <at> emacsbugs.donarmstrong.com (full text, mbox):
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.
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#4090
; Package
emacs
.
(Thu, 20 Aug 2009 20:37:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Kenichi Handa <handa <at> m17n.org>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Thu, 20 Aug 2009 20:37:02 GMT)
Full text and
rfc822 format available.
Message #45 received at 4090 <at> emacsbugs.donarmstrong.com (full text, mbox):
In article <87hbw5yoc4.fsf <at> jidanni.org>, jidanni <at> 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 <at> m17n.org
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#4090
; Package
emacs
.
(Thu, 20 Aug 2009 20:37:04 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Hideyuki SHIRAI (白井秀行) <shirai <at> meadowy.org>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Thu, 20 Aug 2009 20:37:04 GMT)
Full text and
rfc822 format available.
Message #50 received at 4090 <at> emacsbugs.donarmstrong.com (full text, mbox):
From: jidanni <at> jidanni.org said
Subject: [emacs-w3m:10999] Re: bug#4090: Bug#541704: emacs-snapshot ruins w3m-el-snapshot tables
Message-ID: <87hbw5yoc4.fsf <at> 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 <at> meadowy.org)
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#4090
; Package
emacs
.
(Thu, 20 Aug 2009 20:37:05 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
jidanni <at> jidanni.org
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Thu, 20 Aug 2009 20:37:05 GMT)
Full text and
rfc822 format available.
Message #55 received at 4090 <at> emacsbugs.donarmstrong.com (full text, mbox):
OK, thanks 白井先生. By the way
$ cat /tmp/q
Táisǎo Zhōnggōng
$ export LC_ALL=zh_TW.UTF-8
$ set -- -sony-fixed-medium-r-normal--16-120-100-100-c-80-iso8859-1
$ emacs23 -Q -fn $1 /tmp/q #looks great
$ emacs-snapshot -Q -fn $1 /tmp/q #looks terrible
$ LC_ALL=C emacs-snapshot -Q -fn $1 /tmp/q #looks great
The great looking ones use
x:-efont-fixed-bold-r-normal--16-160-75-75-c-80-iso10646-1 (#x1CE)
the bad looking ones use xft:-arphic- etc. I wish I could make them all
great looking.
bug closed, send any further explanations to jidanni <at> jidanni.org
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Fri, 25 Feb 2011 00:09:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Fri, 25 Mar 2011 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 14 years and 148 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.