Description of problem: Files fail to print correctly if they contain characters whose hex value is greater than 7F. Version-Release number of selected component (if applicable): cups-1.5.4-11.fc17.x86_64 How reproducible: Create a text file containing the following line: Test character ø (<compose><o></>) whose value is hex F8. and then try to print it. Steps to Reproduce: 1. Create file foo with contents as above. 2. cp foo foo.txt 3. cp foo foo.c 4. lp foo 5. lp foo.txt 6. lp foo.c Actual results: Files foo and foo.txt do not print at all. File foo.c prints only the first two words: Test character Expected results: Each of the three lp statements should cause the line in the file to print. Additional info: The file command on each file says each is an "ISO-8859 text" file. If I make a page in firefox that has the same contents and print it, it prints correctly. I have set LC_CTYPE=en_US.iso8859-1 and LANG=C in my .bashrc, and Firefox is currently set to en_US.iso8859-1 encoding. A file containing the registered trademark symbol was the first instance where the file didn't print. It seems to happen with all the characters whose hex values lie in the range 80-FF.
The default encoding for CUPS is UTF-8, and most likely that input file will not validate as UTF-8 (and even if it did, the output would not be as intended). To tell CUPS you are submitting a file encoded as ISO-8859-1, do so as follows: lp -o document-format="text/plain;charset=iso-8859-1" ...
That did not work. It still has the same outcome. Please reopen this bug.
Slightly new behavior: now foo.c doesn't print, either.
/var/log/cups/error_log contains some interesting entries: E [03/Jan/2013:08:10:19 -0800] [Job 120] Can't detect file type E [03/Jan/2013:08:10:19 -0800] [Job 120] Job stopped due to filter errors; please consult the error_log file for details. D [03/Jan/2013:08:10:19 -0800] [Job 120] File of type text/plain queued by "greta". D [03/Jan/2013:08:10:19 -0800] [Job 120] envp[18]="CHARSET=utf-8" D [03/Jan/2013:08:10:19 -0800] [Job 120] envp[19]="LANG=en.UTF-8" D [03/Jan/2013:08:10:19 -0800] [Job 120] HP-Printer: Error while converting strings. D [03/Jan/2013:08:10:19 -0800] [Job 120] The print file is empty. D [03/Jan/2013:08:10:19 -0800] [Job 120] prnt/hpcups/HPCupsFilter.cpp 531: cupsRasterOpen failed, fd = 0 D [03/Jan/2013:08:10:19 -0800] [Job 120] prnt/backend/hp.c 833: ERROR: null print job total=0 D [03/Jan/2013:08:10:19 -0800] [Job 120] End of messages Exact command used: lp -o document-format="text/plain;charset=iso-8859-1" foo foo contains the Norwegian letters æ, ø, and å. Apparently the "charset" portion of the command line options did not work.
Thank-you for reopening this bug. If there's any more info you need, I'll be happy to provide it. If there are any other settings I should use, I'll be happy to try that, too.
That's OK. It's *meant* to work that way though. I've reported it upstream.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
In Fedora 19, the behavior is a bit different. Whether or not the document format is used, the printed output contains the words up to the first Norwegian character, then prints a question mark in a box, and nothing else. The file was printed as a txt file and as a c file. No difference.
For the time being I think that text documents need to be converted to UTF-8 before they can be submitted to CUPS, as it does not handle document-format;charset correctly.
What does work properly is using the ISO-8859-1 character encoding in Thunderbird and printing out an e-mail that contains the Norwegian characters. What does not work is setting LC_CTYPE=en_US.iso8859-1 in .bashrc and printing out a txt file or c file that contains the very same letter. Using UTF-8 means the Norwegian characters get translated into other characters, the Greek letters used in math. So, not very useful.
As I mentioned: the text document should be converted to UTF-8. One way to do this: iconv -f iso-8859-1 -t utf-8
Unfortunately, that changes the characters that print out. The UTF-8 file now has æ, ø, and Ã¥ rather than æ, ø, and å. When printed out the UTF-8 file has three other characters that I have no clue how to reproduce. The first is a vertical line with a very short horizontal line sticking out to the right in the middle, with a superscript a. The second has the same two lines and sticking to the right of it a backwards p. The third has the same two lines, and a capital N with a tilde over it.
No, extraneous "Ã" characters indicates you are trying to view UTF-8 encoded text in some other character set such as ISO-8859-1. If that's what you see when you print the UTF-8 file, it sounds like CUPS is using a difference character set. The input text file character set must match the character set CUPS is using. What does 'systemctl show-environment' say?
BOOT_IMAGE=/boot/vmlinuz-3.9.9-302.fc19.x86_64 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin LANG=en_US.UTF-8
Thanks. Now please attach the file you're trying to print.
Created attachment 784846 [details] ISO8859-1 file with Norwegian characters testfile.txt contains six Norwegian characters. They have been created using the compose key: <compose><a><e> for æ, <compose><o></> for ø, <compose><a><a> for å. And the three capital letters.
Thanks. That file is in a different encoding (ISO-8859-1) to the one CUPS is using (UTF-8), so it needs to be converted. As mentioned in comment #1, the way this would normally work would be to tell CUPS what encoding the file is in and lets CUPS handle it... however, that is not currently working (and is reported upstream). That's why I suggested using iconv (in comment #11) to convert the document before printing it. Just to spell out what I mean by that: iconv -f iso-8859-1 -t utf-8 testfile.txt > utf8.txt lp utf8.txt However, you said in comment #12 that this isn't working for you. Could you please confirm that the above gives you incorrect output?
On 7/28, I updated to cups-1.6.3-4.fc19.x86_64. I just tried printing the utf8.txt file, and it now prints correctly. Thank-you.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
This problem does not affect printing; that is, underscores, characters with ascenders or descenders, and international characters are printed correctly although they may not be displayed correctly. For more information visit - https://macsupportnumber.com/blog/how-to-connect-ps4-controller-to-mac/
If you have problems when you try to print a particular document, close the problem document, and then try to print a different document. If you cannot print other documents, create a new document, and then try to print it. to know more: https://avastsupportnumber.co.uk/blog/fix-avast-error-7005/