bugThe nmh Mail Handling System - Bugs: bug #15017, scan can't cope with multibyte or...

 
 

bug #15017: scan can't cope with multibyte or wide characters

Submitted by:  Peter Maydell <pm215>
Submitted on:  Sun 20 Nov 2005 04:25:35 PM UTC  
 
Category: NoneSeverity: 2 - Minor
Priority: 5 - NormalStatus: None
Assigned to: Oliver Kiddle <opk>Open/Closed: Closed

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Sun 15 Jan 2006 02:33:50 AM UTC, comment #2:

I just added a fix for this in CVS.

The fix isn't perfect, but it'll work for now. The whole fmt_scan.c file needs an overhaul.

Josh Bressers <bress>
Project Member
Thu 15 Dec 2005 01:13:28 PM UTC, comment #1:

This is more wishlist than bug. I mentioned this when I made the change to make it use iconv to handle RFC2047 encoded headers in other character sets. (RFC2047 decoding has been there for a long time but previously it only handled headers using the same character set as is used natively).

I've started work on the fix but put it aside for the 1.2 stabilising work. Isn't too much to do apart from the fact that most of the relevant code is written as huge multi-line C macros.

Can you think of any other areas of nmh that need changing to handle multi-byte (and/or double-width) characters?

Oliver Kiddle <opk>
Project MemberIn charge of this item.
Sun 20 Nov 2005 04:25:35 PM UTC, original submission:

scan now does RFC2047 decoding of i18n characters in the From header and other places. However, the various format modifiers that do things like print fields in a given number of characters all make the assumption that number of bytes == number of characters == number of screen columns used. With languages like Japanese both of these are false.

The effect is that the columns in scan output may not be lined up properly, and bogus characters may be displayed if a character is chopped in two by the length-limitation code.

We need to sort out whether these format modifiers deal in characters or screen columns (the latter seems most sensible for column-lining up purposes) and indeed whether we need to provide both options.

I had a quick look at this -- the major culprit is the stuff at the top of sbr/fmt_scan.c -- but I think it probably ought to wait until post 1.2.

Peter Maydell <pm215>
Project Administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

Please enter the title of George Orwell's famous dystopian book (it's a date):

 

 

Follow 2 latest changes.

Date Changed By Updated Field Previous Value => Replaced By
Sun 15 Jan 2006 02:33:50 AM UTCbressOpen/ClosedOpen=>Closed
Thu 15 Dec 2005 01:13:28 PM UTCopkAssigned toNone=>opk

Back to the top


Powered by Savane 3.1-cleanup1