Printing on Kyocera fails if the title tag contains certain characters




11 years ago
8 years ago


(Reporter: hana.skoumalova, Unassigned)


Firefox Tracking Flags

(Not tracked)


(Whiteboard: [closeme 2011-03-15], URL)



11 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv: Gecko/20070802 SeaMonkey/1.1.4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv: 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).
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.
Assignee: general → nobody
Component: General → Printing
Product: Mozilla Application Suite → Core
QA Contact: general → printing

Comment 1

10 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

8 years ago
do you see this issue still with version 3.6 or 4.0 beta?
Whiteboard: [closeme 2011-03-15]
No response to needed information. -> incomplete report
Last Resolved: 8 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.