84948 - Print: charset (encoding) override (manual setting) is not honored in mail print/print preview.

Status: NEW

(MailNews Core :: Internationalization, defect)

Description

[marina]

*** observed with 2001-06-07-13 build ****
Steps to reproduce:
- take a message that is NoMime encoded ( has no charset info in header or body)
- correct the display by setting the right charset;
//note: the display is correct before you Print;
- hit Print; get the printed page ;
//note: printed page looks as of no charset override was done

Comment 1

[marina]

Attachment: this is a shift-jis message

Comment 2

[marina]

NoMime JA printing will work on JA system but won't work on US system, NoMime
iso-8859-1 will work on US system and won't work on JA. Mime encoded messages
will loose accented chars whenprinted on JA system

Comment 3

[nhottanscp]

>- correct the display by setting the right charset;
By charset menu or by folder charset setting?

Comment 4

[marina]

by charset menu( i have a multilingual folder so i didn't specify the folder
charset)

Comment 5

[marina]

changing qa contact to myself

Comment 6

[Frank Tang]

move to future

Comment 7

[marina]

with folder charset setup printing of NoMime messages doesn't have this problem,
the problem is showing up when the folder charset is set to the default and
different from the message charset.

Comment 8

[msanz]

marking nsbranch- as per Frank's comment

Comment 9

[Jungshik Shin]

*** Bug 208788 has been marked as a duplicate of this bug. ***

Comment 10

[Jungshik Shin]

*** Bug 275888 has been marked as a duplicate of this bug. ***

Comment 11

[Jungshik Shin]

sorry for bug spam.

Comment 12

[Rotem Liss]

See also http://www.mozilla.org.il/board/viewtopic.php?t=2275 (Hebrew).

Comment 13

[Jo Hermans]

*** Bug 347715 has been marked as a duplicate of this bug. ***

Comment 16

[Ludovic Hirlimann [:Usul]]

 	
Jungshik are you still working on this ?

Comment 17

[lasdka88+mozbugs]

The simple fact is that the user's choice of character encoding is not respected when printing.

This occurs whether or not the original email has the wrong character set specified (and so the user has had to manually change the encoding for it to display correctly - as is my case) or whether the original email has no character encoding information (and so the user has to manually choose the correct one).

This bug has been open for about 10 years now. I'd love to see it fixed in the next version. Cheers.

Comment 18

[Ludovic Hirlimann [:Usul]]

Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.

Comment 19

[:aceman]

Hi, is this still happening?
We are touching print preview in bug 759039 and this could be related.

Comment 20

[Eyal Rozenberg]

Re Comment #19:
Still happening with Thunderbird 56.0b4 . And thus still preventing the BiDi Mail UI extension (which I maintain) from applying its misdetection-correction of RTL language charset when printing messages.

Comment 21

[Eyal Rozenberg]

Whoops, forgot the flag.

Comment 22

[lasdka88+mozbugs]

I've only got access to Thunderbird 52.3.0 (64-bit) at the moment. I can confirm that the issue is still present in it.

Comment 23

[Vera]

Still happening in Thunderbird 60.4.0 (64-bit)...

Comment 24

[Sergio Callegari]

Seen also here (Thunderbird 60.9.0 on Ubuntu Linux).

I have received a message which appears with "weird" looking chars, because Thunderbird cannot detect the encoding correctly and tries to use UTF-8 when the encoding is Western (Latin1, I suppose). Using View->Text Encoding->Western, I can see the message correctly on screen. However, it seems impossible to print the message correctly.