Bug 137534 - Wrong char width for Japanese ideographs
Summary: Wrong char width for Japanese ideographs
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Fedora
Classification: Fedora
Component: emacs
Version: 3
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jens Petersen
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-10-29 11:16 UTC by Nakai
Modified: 2007-11-30 22:10 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2005-05-16 05:57:05 UTC
Type: ---
Embargoed:


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

Description Nakai 2004-10-29 11:16:43 UTC
Description of problem:
Full-width qoute char's width is wrong in Emacs by default,
So .emacs or other emacs settings needs the appropriate
addition.

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


How reproducible:
Everytime


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 11:20:32 UTC
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-31 02:05:09 UTC
'ascii must be on top of the list, or you can't input '\'(backslash).
And complete charset list would be better.

(un-define-change-charset-order 
 (list
  '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-3 
  '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 
  'mule-ucs-unicode-multichar))

Comment 3 Jens Petersen 2004-11-02 00:51:26 UTC
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
--- Mule-UCS-current/lisp/un-define.el~	2004-11-01 21:22:16.556475869
+0900
+++ Mule-UCS-current/lisp/un-define.el	2004-11-01 21:22:16.571473901 +0900
@@ -143,6 +143,8 @@
 	      ipa
 	      japanese-jisx0208
 	      japanese-jisx0212
+	      latin-jisx0201
+	      katakana-jisx0201
 	      chinese-gb2312
 	      chinese-cns11643-1 
 	      chinese-cns11643-2
@@ -154,8 +156,6 @@
 	      chinese-big5-1
 	      chinese-big5-2
 	      korean-ksc5601
-	      latin-jisx0201
-	      katakana-jisx0201
 	      thai-tis620
 	      ethiopic
 	      indian-is13194


Comment 4 Jens Petersen 2004-11-02 01:43:07 UTC
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 07:18:56 UTC
No, comment #3 patch doesn't make sense.

Comment 6 Jens Petersen 2004-11-09 03:56:26 UTC
Why not? :)

Comment 7 Nakai 2004-11-09 05:25:19 UTC
I mean it doesn't work on my desktop. I don't know the reason.

Comment 8 Jens Petersen 2005-05-16 05:57:05 UTC
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.