Closed Bug 9332 Opened 27 years ago Closed 24 years ago

Does not print cyrillic characters

Categories

(Core :: Internationalization, defect, P2)

x86
Windows NT
defect

Tracking

()

CLOSED WORKSFORME

People

(Reporter: serhunt, Assigned: erik)

References

()

Details

(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.
Assignee: ftang → erik
Status: REOPENED → NEW
QA Contact: teruko
Over to erik as a reminder bug.
Status: NEW → ASSIGNED
Depends on: 8801
Target Milestone: M9
Wait until font prefs are implemented. Then test it. Marking dependent on 8801.
Target Milestone: M9 → M10
Blocks: 11275
Target Milestone: M10 → M14
Don't need to test this before beta. Marking M14.
Target Milestone: M14 → M16
Depends on: 24172
No longer depends on: 8801
Moving all M16s to M17. Please make comments if you disagree.
Target Milestone: M16 → M17
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.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → 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.
QA Contact: teruko → rspain
Added new blocker bug. Can’t test at this time
Blocks: 41044
blocker bug was resolved. This problem longer exists in win32 build 2000060808. 
marking as verified
Status: RESOLVED → VERIFIED
closing
closing
Status: VERIFIED → CLOSED
You need to log in before you can comment on or make changes to this bug.