Bug 84104 - Multibyte large page not fully printed
Multibyte large page not fully printed
Product: Red Hat Linux
Classification: Retired
Component: cups (Show other bugs)
i386 Linux
high Severity medium
: ---
: ---
Assigned To: Tim Waugh
Depends On:
  Show dependency treegraph
Reported: 2003-02-12 01:25 EST by David Joo
Modified: 2007-03-27 00:00 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-05-07 00:12:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Test file for Simplified Chinese (26.19 KB, text/plain)
2003-02-12 01:26 EST, David Joo
no flags Details
error_log of couple jobs (824.08 KB, text/plain)
2003-02-13 02:14 EST, Leon Ho
no flags Details
double4.txt (16.77 KB, text/plain)
2003-02-13 07:44 EST, Leon Ho
no flags Details

  None (edit)
Description David Joo 2003-02-12 01:25:38 EST
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):

How reproducible:

Steps to Reproduce:
1. Fresh installation
2. Open the test file
3. Print in gedit and OO
Actual results:
Prints 3-4 pages

Expected results:
Print 9 pages

Additional info:
Comment 1 David Joo 2003-02-12 01:26:21 EST
Created attachment 90021 [details]
Test file for Simplified Chinese
Comment 2 Yu Shao 2003-02-12 01:37:00 EST
One point to add, beta4 was ok, hope this will help to pinpoint the problem quickly.
Comment 3 Akira TAGOH 2003-02-12 09:32:23 EST
I've installed libgnomeprint[ui]22, 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.
Comment 4 Leon Ho 2003-02-12 10:58:07 EST
Tagoh-san, will it related to NPTL on latest glibc etc? 
Comment 5 Leon Ho 2003-02-12 12:31:19 EST
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. 
Comment 6 Tim Waugh 2003-02-12 12:41:07 EST
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.
Comment 7 Tim Waugh 2003-02-12 13:53:06 EST
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?).
Comment 8 Akira TAGOH 2003-02-12 13:58:39 EST
not sure. perhaps it's related the filters? at least pstops works for me, though.
Comment 9 David Joo 2003-02-12 19:49:07 EST
First Tim:
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
Bris.'s case).
And now I got 11 pages.

I hope this helps, since we don't have spare printer, haven't tested physically
connected printer.

David Joo
Comment 10 David Joo 2003-02-12 19:51:28 EST
Also, save to a pdf file crashes gedit.. it seems...
I tried to save it to four.pdf
Comment 11 Yu Shao 2003-02-12 22:24:21 EST
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.
Comment 12 Leon Ho 2003-02-13 01:57:13 EST
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. 
Comment 13 Leon Ho 2003-02-13 02:14:14 EST
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
pre-filtering) FAILED
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)
Comment 14 Leon Ho 2003-02-13 04:03:49 EST
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) 
Comment 15 Leon Ho 2003-02-13 07:44:53 EST
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
Comment 16 Tim Waugh 2003-02-13 09:16:01 EST
Please try redhat-config-printer-0.6.47-1, which enables you to turn off
prefiltering.  Previously it was stuck on.
Comment 17 Tim Waugh 2003-02-13 10:19:46 EST
Prints fine for me on a non-PS printer.  I don't have a PS-capable printer
available to test with.
Comment 18 Leon Ho 2003-02-13 19:16:38 EST
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. 

Note You need to log in before you can comment on or make changes to this bug.