(This bug imported from BugSplat, Netscape's internal bugsystem. It was known there as bug #64027 http://scopus.netscape.com/bugsplat/show_bug.cgi?id=64027 Imported into Bugzilla on 07/06/99 22:37) Go to the page containing Cyrillics and try to print it out. Characters will not be printed. Images are OK.

Is this the same as the bug you fixed last week?

The problem is happen when you set the font to "Times New Roman" or "Courior New" those font which have the SAME NAME in the printer but not the Cyrllic portion. It won't have problem if the font name is not those font, (for example, I cannot see the problem if I use the Cyberbit font, but I can see the problem if I use Times New Roman font) or the Times New Roman font in the PostScript printer HAVE those Cyrillic glyph. Later this. we should release note this.

Wait. Any other app including Explorer prints Times New Roman Cyr just fine. Does it mean the PostScript printer Mayo which I use has this 'Cyrillic glyph'? BTW, it happens with mail too.

Per 6/26/97 meeting, I'm re-assigning this to jliu for 5.0. Needs to change the target fix version later to match 5.0 jliu needs to talk to ftang about possible fixes.

jliu is no longer here. Reassign this to ftang ------- Additional Comments From paulmac Jul-06-1999 20:04 ------- This bug is marked TFV 5.0 but does not appear relevant in Seamonkey's new code base, so marking Resolved WONTFIX. If it's still relevant, please re-open bug in Bugzilla. ------- Additional Comments From momoi Jul-06-1999 22:41 ------- Actually this bug could be relevant to printing in 5.0. We should send th sover to 5.0 as a reminder bug since we'll be using the same sets of fonts in 5.0 under Windows.

Over to erik as a reminder bug.

Wait until font prefs are implemented. Then test it. Marking dependent on 8801.

Don't need to test this before beta. Marking M14.

Moving all M16s to M17. Please make comments if you disagree.

Does this still happen, now that some font pref work has been completed? Leaving target at M17.

I think this one is very related to bug# 24828. In general one might say that mozilla will try to rather print with correct face than with correct encoding, which is very wrong IMHO. I also can not understand how can this not be a beta stopper, since a modern browser without international printing is quite useless.

moshev, you said that this is related to bug 24828, but it doesn't seem related. Are you sure you typed the right number?

I tested this using a build built today on NT4, and it works fine. Marking WORKSFORME.

My mistake, make it 24824. BTW, this does not work on Linux. I think we should reopen it.

Hi Moshev, thanks for the bug number. I had a look, and that is a Linux bug. This bug is specifically marked Windows NT, and it works on that platform, so it is OK to mark it WORKSFORME. There is at least one separate bug report for printing I18N on Linux, so that is already covered (though not fixed, maybe).

Rob, please test this on Windows. If works fine, please put the build number which you test and mark verified.

Added new blocker bug. Can’t test at this time

blocker bug was resolved. This problem longer exists in win32 build 2000060808. marking as verified

closing

closing