126602 - [ps] Mozilla PS printing for UTF-8 mail and SJIS attachment does not work

Status: RESOLVED FIXED

(Core :: Printing: Output, defect)

Description

[u32858]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020205
BuildID:    2002020511

I have been trying to get japanese printouts but it never works

The following emails do not print on my system, (the print but the japaense
comes out as [] [] square boxes)

Content-Type: text/plain; charset="ISO-2022-JP"
EUC
UTF-8


Reproducible: Always
Steps to Reproduce:
1.try and print a japanese email in the 3 formats above
2.
3.

Actual Results:  [][] square boxes for each char

Expected Results:  Nice japanese print out

Comment 1

[ji]

Does it happen when you print out a japanese web page, like
http://home.netscape.com/ja

Comment 2

[Yuying Long]

I'm able to print netscape.com/ja but not on UTF-8 pages.

See comment on bug 126604.

Comment 3

[Yuying Long]

Please ignore my prviours comment, it works for me on utf-8 page also.

Comment 4

[ji]

For email printing, it's not working for a iso-2022-jp mail with a sjis
attachment, and it's also not working for a utf-8 mail. For example, in the
smoketest folder, it works for the 2nd mail, but not working for 3rd and 4th one.
Confirmed bug. Nominated for nsbeta1.

Comment 5

[ji]

It's a regression from 6.2.1.

Comment 6

[u32858]

http://home.netscape.com/ja

that prints fine for me

<meta HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=x-sjis">


it has some variation on Shift_JIS then

JG

Comment 7

[Masaki Katakai]

Found a problem, preferences have been changed, but argument
has not been changed.

   if (strstr(aName, "print.postscript.nativefont.")) {
-    lang.Cut(0, 19);
+    lang.Cut(0, 28);
   } else if (strstr(aName, "print.postscript.unicodefont.")) {
-    lang.Cut(0, 20);
+    lang.Cut(0, 29);
   }

Is it better to use strlen() to determine the length?

Comment 8

[Masaki Katakai]

Attachment: proposed patch: change length for Cut()

Comment 9

[Masaki Katakai]

Please change the Summary to 

"Japanese printing does not work at all"

because I believe this is not specific to mail.

Comment 10

[u32858]

 Additional Comments From [e-mail]  2002-02-20 19:02 -------
> Please change the Summary to 
> 
> "Japanese printing does not work at all"
> 
> because I believe this is not specific to mail.



Please See the other Mozilla bug report at
http://bugzilla.mozilla.org/show_bug.cgi?id=126604

Comment 11

[Masaki Katakai]

I'll file new bug that "Mozilla Japanese Printing does not work at
all" for generic problem. Current nightly does not work at all.

Comment 12

[Masaki Katakai]

OK, I've filed a bug 126920 for generic problem.

Currently, Mozilla PS printing for CJK is broken.

With the patch of bug 126920, it works fine for mail priting.
However, yes, as ji mentioned, UTF-8 encoded mail and SJIS
attachment can not be printed out properly. I think
it's new problem.

Jg and Ji,

Can you correct the summary?

Comment 13

[nhottanscp]

cc to shanjian

Comment 14

[Masaki Katakai]

JG,

Thank you... but summary is not still good. Generally printing
works fine with the path of bug 126920.

Problem is that

- UTF-8 mail can not be printed out
- SJIS attachment can not be printed out

So, it should be

"Mozilla PS printing for UTF-8 mail and SJIS attachment does not work"

Comment 15

[Masaki Katakai]

Regression from 0.9.8. It works on 0.9.8.

It seems that language group is not "ja" in UTF-8 encoded mail
and attachment field pane.

In 0.9.8, actually the lang group is set to "ja" when I start
Mozilla in japanese locale.

Hotta-san, Jshin, do you know about this change?

Comment 16

[u32858]

Why am I the only one with authorisation to change the summary?

Comment 17

[Masaki Katakai]

Thank you, JG. I understand only bug owner and submitter can change such fields.

Comment 18

[Jungshik Shin]

Regression from 0.9.8. It works on 0.9.8.

> It seems that language group is not "ja" in UTF-8 encoded mail
> and attachment field pane.

> In 0.9.8, actually the lang group is set to "ja" when I start
> Mozilla in japanese locale.

> Hotta-san, Jshin, do you know about this change?

  How does PS printing module determine langgroup? 
The change I made in mailnews/mime/src results in
(see bug 102623) the html doc output of the following

<div class="moz-text-plain" wrap=true graphical-quote=true
style="font-family: -moz-fixed; font-size: 16px;" lang="x-unicode">

for UTF-8 encoded emails, I believe.

In the past, it used to be something like the following: 

<div class="moz-text-plain" wrap=true graphical-quote=true
style="font-family: -moz-fixed; font-size: 16px;">


Could explicitly specifying "lang=x-unicode" be a problem
for PS printing module? 

BTW, I don't understand why it affects SJIS encoded messages as well. 

Comment 19

[Masaki Katakai]

Thanks for the info, Jshin,

Yes, it seems that lang="x-unicode" changes causes this problem. But
putting lang="x-unicode" itself should be correct change.

PS printing gets langgroup of gfx layer, which should be same with
gfx/gtk layer and there is no special codes for that.

It seems that when we set lang="x-unicode", "x-western" lang group
is passing to gfx layer... so there is no PS font for "x-western".
This is the same behavior gfx/gtk layer.

<span lang="x-unicode"> ... </span> throws "x-western" to gfx...

When only charset=UTF-8 setting in html header, "ja" is passed
to gfx which is the default lang on Mozilla.

Not sure how to fix... Can anyone have suggestion?

Comment 20

[Masaki Katakai]

For attachment issue, it seems that Mozilla uses preference
for "Message Display".

When I set to "Western (ISO-8859-1)" (default setting if
we don't have language pack), "x-western" is passed to
gfx layer, so problem happens.

When I set to "Japanese (ISO-2022-JP)" on preference,
"ja" language group is passed to gfx layer.

Language pack should overwrite the value for printing.
Also this should be desribed in release notes...

SJIS problem can be resolved by the setting.

Comment 21

[Jungshik Shin]

> Yes, it seems that lang="x-unicode" changes causes this problem. But
> putting lang="x-unicode" itself should be correct change.




 ¤ÔI sorta confirmed that 'lang=x-unicode' is the cause of this problem
by printing out Korean UTF-8 message (with Korean string in Subject: header
as well as in body) under Korean locale. The Korean string in Subject:
header gets printed fine while Korean strings in the message body
didn't get printed. Subject: header (with =?B?UTF-8?.....?= style encoding)
is printed with ko_ls while the message body is printed with default_ls. 

> It seems that when we set lang="x-unicode", "x-western" lang group
> is passing to gfx layer... so there is no PS font for "x-western".

  IIRC, once in the past, 'x-unicode' was passed along if 
lang='x-unicode', but for some reason I forgot,  it was changed
back to 'x-western'. 

  Even if the locale lang group(or x-unicode) is passed along,
Mozilla launched under ja locale may not be able to print
SC/TC/KO emails in UTF-8 (depending on fonts)..... Seems like
yet another case for FT pringing ?

Comment 22

[Masaki Katakai]

> Seems like yet another case for FT pringing ?

Yes, I think FT2 printing can solve this issue.

Actually this is a regression but do you think
this problem is high priority? Because people
usually don't use UTF-8 in mail.

Also we have a workaround (not sure whether
it's reasonable or not) that putting primary
font e.g. Ryumin-Light for me, setting for 
"x-western".

Comment 23

[Jungshik Shin]

Another work-around(or hack) might be not to 'lang=x-unicode'
for charset=UTF-8 in my patch to 102623, but that's really
a hack, isn't it? 

I agree with you that this is not a very high priority item
although I don't feel good about breaking printing of
mails in UTF-8 because I've been pushing for using UTF-8
everywhere. 

This problem would not exist if there were a higher-level
label for 'lang' of email messages (esp. in UTF-8).
What I'm thinking of is another _optional_ parameter to Content-Type
header which indicates 'lang' so that C-T header looks like

Content-Type: text/plain; charset=UTF-8; lang=ja

I searched for something like the above at IMC (internet
mail consortium) web page,
but nobody seems to have suggested it. (if it's text/html,
there's a way to embed 'lang' info. Even in 'plain text UTF-8',
Plan 14 lang. tag can be embedded 'in theory', but.....)

Comment 24

[ji]

Removed nsbeta1 nomination since on Japanese build default charset  for message
display is set to Japanese (iso-2022-jp) and this solves sjis attachment
printing problem. We still have no reasonable workaround for UTF-8 mail printing
for CJK though.

Comment 25

[nhottanscp]

So is there a problem in our printing code?
What is FT printing?

Comment 26

[Masaki Katakai]

Currently, in PostScript printing, if x-western language group is
passed for UTF-8 page, there is no way to determine the exact
language group to look up PostScript codes. We should have
implemented the way to look up a glyph per code point based,
like gfk/gtk layer. We now use only language group in printing.

I understand FT (FreeType2) printing can consider UTF-8 (UCS?)
code points and will put embedded glyphs into outputs,
which can be solved hopefully.

Comment 27

[nhottanscp]

> Currently, in PostScript printing, if x-western language group is
> passed for UTF-8 page, there is no way to determine the exact
> language group to look up PostScript codes. 
Is the code in Mozilla? 

Comment 28

[Masaki Katakai]

Yes. It's Mozilla codes.

Comment 29

[nhottanscp]

Katakai san, are you working on PS printing for mozilla? If so, can we reassign
to you?
Can the code ignore the unknown lang like "x-western" then use the default font
for Unicode?

Comment 30

[Masaki Katakai]

yes, please assgin to me and change products to browsers.

Comment 31

[dcone (gone)]

Re-assign this to katakai... thanks for handling these kinds of issues.

Comment 32

[Roland Mainz]

Is this issue now fixed ?

Comment 33

[Masaki Katakai]

No. I believe this is still reproducible.

Comment 34

[ji]

Yes, it's still happening.

Comment 35

[Kenneth Herron]

The printing code that was in place when this bug was filed has been completely replaced by a new cairo-based printing implementation, which should be able to print anything the browser can display. Please open a new bug if you can reproduce this with a current (trunk) build.