Red Hat Bugzilla – Bug 84104
Multibyte large page not fully printed
Last modified: 2007-03-27 00:00:48 EDT
Description of problem:
For CK, (haven't tested Japanese case), if in gedit or OO, open a large txt
file, and try to print, it will only print a portion of it.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Fresh installation
2. Open the test file
3. Print in gedit and OO
Prints 3-4 pages
Print 9 pages
Created attachment 90021 [details]
Test file for Simplified Chinese
One point to add, beta4 was ok, hope this will help to pinpoint the problem quickly.
I've installed libgnomeprint[ui]22 18.104.22.168-1, gedit-2.2.0-1, and cups 1.1.17-12
on beta4. the printing four.txt out on zh_CN.GB18030 locale looks ok.
GinGin-re0211.2 was also no problem. how did you reproduce this problem on?
If this problem surely existed, it's likely fixed in the latest tree.
Tagoh-san, will it related to NPTL on latest glibc etc?
This is a blocker for GB18030 compliance test so raising priority. To meet the
current GM schedule we must ship CDs for testing to the PRC by Thursday.
Can someone let me know if this is actually a problem, or is fixed? It will
take me a while to get a machine installed in that locale.
I got 11 pages.
Next time, please *please* **please** fill out the version/release part of the
template, and give more specific instructions that 'CK locale' (what is that?).
not sure. perhaps it's related the filters? at least pstops works for me, though.
So sorry, that I just assumed too much, It won't happen next time..
For the rest ^^:
After reading all the responses, I have installed re0209.nightly again.
Simplified Chinses install with just workstation installation.
I could only get 2 pages again, with four.txt in gedit.
But, there was another scenario that we didn't take into consideration, that was
the type of printing that we were using. The office uses, HPs and we set our
printer using DirectJet.
Thanks to Paul Gampe, he suggested to test using other spools (i.e. Hypatia in
And now I got 11 pages.
I hope this helps, since we don't have spare printer, haven't tested physically
Also, save to a pdf file crashes gedit.. it seems...
I tried to save it to four.pdf
Tested with Phoebe-re0212.Beta5-RC1 and updated cups package 1.1.17-13.
Test installation is Simplified Chinese default, select Simplified Chinese as
default language, all other options are default.
Still got only the first page of four.txt.
We have tried to use printer cable to print from HP Laser 4050 but it is a no go
as well. Another test we tried are sending to a external spool which is
hypatia.brisbane (cups-1.1.14-15). All the test file are print out successfully (The
speed is much slower compare to latest cups, very smiliar to the speed of 8.0)
For locally configured printer, that is a cause of the problem (or just work
around?) for gedit, if I use en_US settings on redhat-config-printer (like no
pre-filtering, no pre-render postscript, convert text to postscript, filter locale to
C), gedit prints fine.
One behaviour is that for this setting and normal setting (with pre-filtering etc) is
that this setting prints out slower (very similar speed to 8.0 etc) compare to with
pre-filtering, is much faster.
When I print the huge job (like double4.txt - 13 pages) in OpenOffice now,
Printer (LaserJet 4050) will show "insufficient memory".
Tagoh-san and Tim, would you tell me what type of printer you use? and what
settings in printer option. I am looking at what enable to print out the test file
successfully in gedit and OO.
Created attachment 90042 [details]
error_log of couple jobs
Job 17 - send to remote cups (hypatia.brisbane) SUCCESS
Job 18 - print out double4.txt with normal settings on gedit (2nd level
Job 19 - print out double4.txt with en_US settings on gedit (no pre-filtering
Job 20 - print out four.txt with en_US settings on gedit (no pre-filtering etc)
Job 21 - print out double4.txt with en_US settings on OO (no pre-filtering etc)
I have look further, and look at these pattern:
[root@reflex root]# ls -al *.ps
-rw-r--r-- 1 root root 15069946 2ï¿½ 13 16:53 double4_gedit_after.ps
-rw-r----- 1 root root 10667141 2ï¿½ 13 16:34 double4_gedit.ps
-rw-r--r-- 1 root root 12164444 2ï¿½ 13 16:52 four_gedit_after.ps
-rw-r----- 1 root root 8601367 2ï¿½ 13 16:33 four_gedit.ps
-rw-r--r-- 1 root root 20830923 2ï¿½ 13 16:31 four_oo_after.ps
-rw-r--r-- 1 root root 15443406 2ï¿½ 13 15:48 four_oo.ps
"after" is what the output after ran the gs prerendering
The case for our currently environment is that anything larger than 10MB
postscript cannot go through to LaserJet 4050 (with 8MB of memory by default)
Created attachment 90046 [details]
Please see if you can reproduce this problem by:
- choose pre-filtering PS level 2 in redhat-config-printer
- Run OpenOffice
- open double4.txt
- Ctrl-A to hightlight all of the characters, then change the font to
- Print it to printer
Please try redhat-config-printer-0.6.47-1, which enables you to turn off
prefiltering. Previously it was stuck on.
Prints fine for me on a non-PS printer. I don't have a PS-capable printer
available to test with.
Thanks a lot for your testing Tim. After I have gathered those info
we have and have some exchanges with CUPS upstream. Michael
from CUPS told us chances are if we print a PS with TTF, we
probably will hit the PS interpreter bug in the printer. by using PCL,
and the PS interpreter isn't involved, files are printing correctly.
It should only happens on large PS files, but chances are some of
the PS with TTF may has this problem as well. So we need to keep
in mind of asking user to try on using PCL if they hit simliar bug.
I will forward you the replies from CUPS upstream.