any chance to fix it in 1.1.1

Set target release to 1.1.1.

I have such problem, 1.1.1 version
may be demonstrated like this:
(russian letters replaced by questions?? )

$g_email_padding_length = 28;

1. only numbers: (new line at 28)
   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28
   29 30 31 32 33 34 35 36 37 38 39 40

2. numbers + letters (russian and latin), without patch
   (new line at 25 with russian and 26 with english)
   ? ? ? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
   26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

G G G 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
27 28 29 30 31 32 33 34 35 36 37 38 39 40

3. the same with patch from here and str_pad replaced with mb_str_pad
   (same result as without patch)

? ? ? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

G G G 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
27 28 29 30 31 32 33 34 35 36 37 38 39 40

when lines contain many russian letters, email formatted like this:

????? ???????? ??????? ??????? ?
?????????????? ???????????? ? ???????
?? mantis.
??????????? ????????????? ? ???????
????? ???????.

how i can format it as "only numbers" width?

my comment related to body of added notes, not to header... maybe it is another bug.

but as I can see, it's related with WrapText() in phpmailer function bug.

see:
in email_api.php
$mail->WordWrap = 80; # set word wrap to 50 characters (funny,
edit the comment too ;)

in class.phpmailer.php
$this->Body = $this->WrapText($this->Body, $this->WordWrap);

try to set $mail->WordWrap = 120; or $mail->WordWrap = 0; - same view, no effect

make a workaround :

--- email_api.php.orig 2008-02-25 12:51:51.000000000 +0300
+++ email_api.php 2008-02-25 12:46:26.000000000 +0300
@@ -1080,7 +1080,8 @@

• $t_message .= wordwrap( $t_bugnote->note ) . " \n\n";
• $t_message .= $t_bugnote->note . " \n\n";

wordwrap() function need to be reworked with utf8 in mind

... also the function "email_format_attribute()"
The issue 0008798 is a result of the function email_format_attribute()
The german expression of priority is "Priorät" and the alignment in this row is wrong (see screenshot).

These are the two issues in my opinion!

in 1.1.2, i meet the same problem with wrap text in email.
I expect this bug will resolved in 1.2.*?

I found alternative to function mb_str_pad from first post, it's utf8Wordwrap from http://ru.php.net/wordwrap (comment at 28-May-2008 03:56)

with it, i need to replace only 2 call to wordwrap() to utf8wordwap().

maybe it's more simple than replace all calls to str_pad.

I just happened to stumble across this page.
In case you're interested, here's what we use in "Gemeinschaft" (GNU GPL).
https://svn.amooma.com/gemeinschaft/trunk/opt/gemeinschaft/inc/mb_str_pad.php
http://www.amooma.de/gemeinschaft/

if (! function_exists('mb_str_pad')) {
function mb_str_pad( $str, $len, $padstr=' ', $padtype=STR_PAD_RIGHT, $enc='' )
{
if (! function_exists('mb_strlen'))
return str_pad( $str, $len, $padstr, $padtype );

if ($enc==='') $enc = mb_internal_encoding();
$strlen = mb_strLen($str,$enc);
$flen = $len - $strlen;
if ($flen <= 0) return $str;
$pad = str_repeat($padstr, $flen);

switch ($padtype) {
case STR_PAD_RIGHT:
    $pad = mb_subStr($pad, 0, $flen, $enc);
    return $str . $pad;
case STR_PAD_LEFT:
    $pad = mb_subStr($pad, 0, $flen, $enc);
    return $pad . $str;
case STR_PAD_BOTH:
    $flenh = $flen/2;
    $padl = mb_subStr($pad, 0, floor($flenh), $enc);
    $padr = mb_subStr($pad, 0, ceil($flenh), $enc);
    return $padl . $str . $padr;
default:
    trigger_error('mb_str_pad(): Padding type has to be STR_PAD_LEFT, STR_PAD_RIGHT, or STR_PAD_BOTH.', E_USER_WARNING);
    return null;
}

}
}

Similar problem exists with Subjects of e-mails. For example this Subject is split into multiple lines incorrectly:

Subject: =?utf-8?B?W1JlYWx0b3ItT25saW5lIDAwMDAwMzRdOiDQl9Cw0L/RgNCw0YjQuNCy0LDQ?=

=?utf-8?B?tdC80L7Qs9C+INGE0LDQudC70LAg0L3QtSDRgdGD0YnQtdGB0YLQstGD0LXR?=

=?utf-8?B?giDQuNC70Lgg0L7QvSDQvdC10LTQvtGB0YLRg9C/0LXQvQ==?=

(reported in http://www.mantisbt.org/forums/viewtopic.php?f=3&t=6522 )

Fixed via issue 0010303 implementing multibyte-aware string functions.