Description of problem: After update to Fedora 19, Japanese characters are replaced with a placeholder symbol. This worked in Fedora 19. Version-Release number of selected component (if applicable): cups-1.6.3-1.fc19.x86_64 ghostscript-9.07-10.fc19.x86_64 How reproducible: 100% Steps to Reproduce: 1. echo 'проверка test テスト' | lpr Actual results: Blank Japanese characters, Russian characters okay Expected results: All characters printed Additional info: Since Russian works, we know that UTF-8 text is parsed properly, so perhaps it's just some fonts missing. However, the point is that this system was upgraded and the upgrade broke something. Hopefuly it's just Requires: in a spec somewhere, or an upgrade scriptlet.
Since I updated with yum, I kept the old /var/log/yum.log, here's the versions that worked previously: Feb 23 14:02:38 Updated: 1:cups-1.5.4-20.fc18.x86_64 Feb 23 17:27:54 Updated: gutenprint-cups-5.2.9-2.fc18.x86_64 Apr 24 09:00:53 Updated: gutenprint-cups-5.2.9-7.fc18.x86_64 Also, Ubuntu bug says that a question mark is printed. In my case, a square is printed.
With cups-filters we switched over to texttopdf for formatting text/plain, and unfortunately it has a design issue: it uses its own static mapping for which fonts to use for each unicode range, rather that using fontconfig to do work out glyph coverage at run-time. I'm not sure how hard it would be to fix this, but last time we had a new implementation of the texttops filter (the paps-based texttopaps) it took quite a time before the bugs were ironed out. I would rather switch back to texttopaps for the time being until texttopdf is more mature and better able to handle unicode. However, in my local testing I discovered another paps issue... I'll file that now.
I've changed the cost for the text filters from '0' to '200' so that paps will be used by preference if installed. If the paps filters do not give good output, they can be uninstalled and texttopdf will be used instead.
ghostscript-9.07-12.fc19,cups-filters-1.0.36-2.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/ghostscript-9.07-12.fc19,cups-filters-1.0.36-2.fc19
Package ghostscript-9.07-12.fc19, cups-filters-1.0.36-2.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing ghostscript-9.07-12.fc19 cups-filters-1.0.36-2.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-15111/ghostscript-9.07-12.fc19,cups-filters-1.0.36-2.fc19 then log in and leave karma (feedback).
ghostscript-9.07-12.fc19, cups-filters-1.0.36-2.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
Tim, I'm sorry to report that the update didn't fix the problem. However, if it matters, the output has changed: the placeholder rectangles were empty before, but they have question marks in them now. So, a different font is selected, perhaps. I am hesitant to reopen, because it does not seem too important. For now I work around it by copy-pasting into LO and printing from there.
I forgot to mention that I re-installed F19 from scratch, so this is not the original updated system anymore. ghostscript-9.07-12.fc19.x86_64 cups-filters-1.0.36-2.fc19.x86_64
Oh, I should have mentioned: the cups-filters/ghostscript change was partly to adjust the filter costs so that the "paps" package gets used in preference when converting text/plain. Do you have paps installed?
Yes, paps-0.6.8-26.fc19.x86_64.
If you install the vlgothic-fonts package, does it work correctly then?
I already have vlgothic-fonts-20130607-1.fc19.noarch, but yes, I suspected a font was missing. The text shows fine in gnome-terminal, but I have no clue how to know what's being used for a font.
If you run that input through paps by hand, do the characters render correctly?