Closed
Bug 397469
Opened 18 years ago
Closed 14 years ago
Printing on Kyocera fails if the title tag contains certain characters
Categories
(Core :: Printing: Output, defect)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: hana.skoumalova, Unassigned)
References
()
Details
(Whiteboard: [closeme 2011-03-15])
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4
When printing a web page on Kyocera FS-1030D the printing fails if the title tag contains any of the characters 'č', 'ď', 'ě', 'Č', 'Ď', or 'Ě'. There may be more characters from iso-8859-2 charset with this behaviour, but I only checked the Czech alphabet.
When I try to print such a page, some PJL commands mixed with the corrupted title of the web page are printed and then many empty pages go out of the printer.
Reproducible: Always
Steps to Reproduce:
1. Open a web page with 'č' in its title.
2. Print it on Kyocera FS-1030D via CUPS (with corresponding PPD installed).
3.
Actual Results:
A page with PJL commands and some rubbish is printed and then empty pages are comming out.
Expected Results:
Printed page.
I am using CUPS with proper PPD file. The printer is a network printer using ipp.
I tried to change the encoding from iso-8859-2 to utf-8, but it didn't help.
When I look to my Print Notifier I can see that names of the documents to be printed are just the titles of the web pages - perhaps this is the cause of the problem.
The problem can also be hidden in the printer but I don't know how to check this. The printer doesn't have problems with any other application except for SeaMonkey/Firefox.
Updated•18 years ago
|
Assignee: general → nobody
Component: General → Printing
Product: Mozilla Application Suite → Core
QA Contact: general → printing
Reporter | ||
Comment 1•16 years ago
|
||
The problem is in the print job name - some characters are replaced with "^M" and the printer is confused by it. I tried the new Seamonkey (2.0a1) and this bug is fixed there (the name is in UTF encoding). If there are plans to continue developing the 1.1.x series, then this bug should be fixed, otherwise we will just wait for the stable release.
The same bug occurs in Firefox 2.x and it's fixed in 3.x.
Comment 2•14 years ago
|
||
do you see this issue still with version 3.6 or 4.0 beta?
Whiteboard: [closeme 2011-03-15]
Comment 3•14 years ago
|
||
No response to needed information. -> incomplete report
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•