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

Submitter:  Peter Maydell <pm215>
Submitted:  Sun 20 Nov 2005 04:25:35 PM UTC
   
 
Category:  None Severity:  2 - Minor
Priority:  * 5 - Normal Status:  None
Assigned to:  opk Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group 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>
Group Member
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>
Group administrator

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

Follow 2 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2006-01-15 bress Open/ClosedOpen Closed
2005-12-15 opk Assigned toNone opk

Back to the top

Powered by Savane 3.13-d3ae.
Corresponding source code