I didn't see this bug elsewhere, but I can't believe I'm not posting a duplicate... Anyway, Mozilla won't let me print pages with Latin2 characters correctly. When I print the page to file, and then I print it with ghostscript, there are squares instead of national accented characters. When I pipe the file through ogonkify or a2ps and then print it, the chars are either squares or other nasty glyphs, but they never appear correctly. Is there no way the mozilla team's gonna fix it? Is there no way I can print pages with Mozilla (pages that contain non-ASCII chars)? Is there an utility to solve the prob?
Reporter: It would help if you give an example page with latin2 characters that shows up badly when printed.
From: Tomasz Jarzynka <firstname.lastname@example.org> Date: Tue, 26 Dec 2000 20:26:46 +0100 To: email@example.com Subject: Re: [Bug 63737] Changed - trouble printing latin2 (iso8859-2) characters On Tuesday 26 December 2000 16:57, you wrote ([Bug 63737] Changed - trouble printing latin2 (iso8859-2) characters): > ------- Additional Comments From firstname.lastname@example.org 2000-12-26 07:57 > ------- Reporter: It would help if you give an example page with latin2 > characters that shows up badly when printed. Yes, sure. http://moo.pl/ogonki/main.html for instance. You can do a gs -sDEVICE=jpeg and open the file. The squares should be visible enough. PS. I do have Latin2 fonts installed on Ghostscript, but it won't set up the vectors etc (I don't know, I never studied postscript). Converting the document with ogonkify won't work (it does for Netscape 4.x and some other apps)
So what's up with the bug? Is it a WONTFIX, or WORKSFORME, or a dupe? Thanks, Tom.
Reopening as per reporters comments: I have just used the 10 Jan build, and it of course has the bug. Printing it with lpr won't work. Trying converting with the only app available (ogonkify) neither. So please reopen the bug and remind the print people that this is a huge no-no in many countries (certainly all using Latin2 characters).
spam : changing qa to sujay (new qa contact for Printing)
This bug is still active. I have Mozilla Build ID: 2001020908, and I can't print iso8859-2 characters corectly
I confirm this bug - it was in previous milestones as well (and as the rapporteur I did not bother to check whether it was ever filed). Using W98(US)/M0.8Build20011021508 I would extend the problem to Win1250 codepage - M0.8 does not print correctly these pages as well. Examples: http://www.ceskenoviny.cz http://pes.internet.cz
I have also noticed this problem of printing squares instead of the intended character but i've had this problem with it printing simple quote characters such as ' and " as squares, here's the page i had problems with (i was trying to print out an assignment for english class): http://courses.ncsu.edu/eng112/lec/037/
i forgot, i'm using build 2001021908
Update onmy previous comment-the problem is printer-driver dependent. I.e., wiht AdobePS HP Laserjet drive Moz. printed the sqaures, crosses and other weird stuff. With the native HP driver - it prints well. However, other programs did not have this diffuculty, both drivers worked fine. Could be that the drivers are only 99% compatible and Moz uses the remaining 1%?...
I don't know. I am using PPA output driver, which outputs a raw bitmap. No conversion to any internal printer format is done (it is done, of course, but later, with another driver, which operates on bitmaps, not glyphs - not possible to mess it then) at that time. If the problem exists, it has to be Ghostscript or Mozilla-related.
****. I am using, of course, PNM (or PNMRAW, or PBM, or PBMRAW, depending on printout type), not PPA, which is the last stage of the printout on my HP 720.
Setting milestone to future
updated milestone, keywords
I looked at postscript code generated by Mozilla. I am glad to see that it generates unicode. But code for printing unicode can be updated. '/unicodeshow' is working char-by-char. Order of call of functions (if character is not from ASCII): '/real_unicodeshow', '/real_unicodeshow_native', '/real_unicodeshow_cid' and '/draw_underfined_char' (prints empty square). As I understand, first function relies on '/Unicodedict' -- map from unicode code to postscript program for priting character. But '/Unicodedict' defined nowhere, so function fails. Second function relies on '/Unicode2NativeDict' -- map from unicode code to native font code. But '/Unicode2NativeDict' defined nowhere, so function fails. Third function tries to use unicode font '/UCS2Font'. It fails on my system. In result, empty square is printed.
Filed bug 85399 for Xprint to track this issue in Xprint land. It looks that Xprint module can print this page correctly except the detail that it doesn't find the matching encoding for the font...
Oups, seems to forgot to CC: myself to this bug... ;-( Vaclav Dvorak wrote: > Xprint and how to use it? Because bug 85399 is fixed. Well, I assume this is not your only question, therefore I am currently writing a FAQ about it - see http://puck.informatik.med.uni-giessen.de/people/gisburn/work/xprint/Xprint_FAQ.txt Additionally I wrote a "quick guide how to print in koi8-r locales" , see http://puck.informatik.med.uni-giessen.de/people/gisburn/work/xprint/quickguide_koi8_r.txt (well, I assume the docs can be much better - I am working on it... but suggestions/contributions/etc. are every welcome, too :) which may be usefull to setup Xprint for ISO-8859-2, too... :))
see also bug 65784
I visited the urls given in comment 2 and comment 9, printed each to a file, and viewed them using ghostscript. I didn't see any characters being replaced by little squares. a mozilla print job prints squares instead of characters when it can't find a glyph for the character in the fonts it has available. This happens while the document is being printed so it's somewhat affected by the actual fonts installed with the postscript interpreter. It could be that my copy of ghostscript has glyphs available that aren't in standard fonts such as Times-Roman. Or it could be that the glyph-searching algorithm has been improved since this bug was reported.
I tested the sample URL by printing it on a couple of PS printers at the office (an HP 5si and a Xerox 3285, or something like that). Again, none of the characters were replaced with little rectangles. I know mozilla's printing is pretty bad for character sets outside of iso-8859-1, but this particular bug doesn't seem to be reproduceable any more. I'm going to resolve this.
*** Bug 82982 has been marked as a duplicate of this bug. ***