Bug 137534 - Wrong char width for Japanese ideographs
Wrong char width for Japanese ideographs
Product: Fedora
Classification: Fedora
Component: emacs (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jens Petersen
: i18n
Depends On:
  Show dependency treegraph
Reported: 2004-10-29 07:16 EDT by Nakai
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-05-16 01:57:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Diff for lang-coding-systems-init.el (565 bytes, patch)
2004-10-29 07:20 EDT, Nakai
no flags Details | Diff

  None (edit)
Description Nakai 2004-10-29 07:16:43 EDT
Description of problem:
Full-width qoute char's width is wrong in Emacs by default,
So .emacs or other emacs settings needs the appropriate

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Add full width quote word to Canna dict.
2. Run emacs.
3. Input full width quote word into emacs through Canna.
Actual results:
Half width

Expected results:
Full Width

Additional info:
http://d.hatena.ne.jp/rna/20041027#p2 (Japanese)
Comment 1 Nakai 2004-10-29 07:20:32 EDT
Created attachment 105933 [details]
Diff for lang-coding-systems-init.el

This language setting file include all languages settings.
Previous language settings were separated by each language.
I wonder why you unified them while Red Hat splitted
input method settings in /etc/X11/xinit/xinit.d/ for each langauge.
Comment 2 Ryosuke Nanba 2004-10-30 22:05:09 EDT
'ascii must be on top of the list, or you can't input '\'(backslash).
And complete charset list would be better.

  'ascii 'japanese-jisx0208 'japanese-jisx0212 'katakana-jisx0201 
  'latin-iso8859-1 'latin-iso8859-2 'latin-iso8859-3 'latin-iso8859-4
  'cyrillic-iso8859-5 'greek-iso8859-7 'hebrew-iso8859-8 'latin-iso8859-9
  'latin-iso8859-14 'latin-iso8859-15 'ipa 
  'chinese-gb2312 'chinese-cns11643-1 'chinese-cns11643-2
  'chinese-cns11643-4 'chinese-cns11643-5 'chinese-cns11643-6 
  'chinese-cns11643-7 'chinese-big5-1 'chinese-big5-2 'korean-ksc5601 
  'latin-jisx0201 'thai-tis620 'ethiopic 'indian-is13194 
  'chinese-sisheng 'lao 'vietnamese-viscii-lower 'vietnamese-viscii-upper 
  'mule-unicode-0100-24ff 'mule-unicode-2500-33ff 'mule-unicode-e000-ffff 
Comment 3 Jens Petersen 2004-11-01 19:51:26 EST
Perhaps this should indeed only be changed for ja, but does
the following patch do the right thing for Japanese?
And how does it affect affect input for other languages?

diff -u Mule-UCS-current/lisp/un-define.el~
--- Mule-UCS-current/lisp/un-define.el~	2004-11-01 21:22:16.556475869
+++ Mule-UCS-current/lisp/un-define.el	2004-11-01 21:22:16.571473901 +0900
@@ -143,6 +143,8 @@
+	      latin-jisx0201
+	      katakana-jisx0201
@@ -154,8 +156,6 @@
-	      latin-jisx0201
-	      katakana-jisx0201
Comment 4 Jens Petersen 2004-11-01 20:43:07 EST
With regards to comment 1, at the time it seemed all the language
files were so similar that unifying to one file made sense -
more so because of the common code needed to setup MuleUCS for utf-8.

But in retrospect perhaps it would be better to split up
lang-coding-systems-init.el again: specially if different
coding-system orders are going to be needed for different locale...
Comment 5 Nakai 2004-11-08 02:18:56 EST
No, comment #3 patch doesn't make sense.
Comment 6 Jens Petersen 2004-11-08 22:56:26 EST
Why not? :)
Comment 7 Nakai 2004-11-09 00:25:19 EST
I mean it doesn't work on my desktop. I don't know the reason.
Comment 8 Jens Petersen 2005-05-16 01:57:05 EDT
According to the url in the original report this has been
improved in the coming version of emacs.  Since there doesn't
seem to be obvious clear solution for 21.3 closing for now.

Note You need to log in before you can comment on or make changes to this bug.