Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 84104 - Multibyte large page not fully printed
Summary: Multibyte large page not fully printed
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: cups
Version: 9
Hardware: i386
OS: Linux
high
medium
Target Milestone: ---
Assignee: Tim Waugh
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-02-12 06:25 UTC by David Joo
Modified: 2007-03-27 04:00 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-05-07 04:12:22 UTC


Attachments (Terms of Use)
Test file for Simplified Chinese (deleted)
2003-02-12 06:26 UTC, David Joo
no flags Details
error_log of couple jobs (deleted)
2003-02-13 07:14 UTC, Leon Ho
no flags Details
double4.txt (deleted)
2003-02-13 12:44 UTC, Leon Ho
no flags Details

Description David Joo 2003-02-12 06:25:38 UTC
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:
Everytime

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 06:26:21 UTC
Created attachment 90021 [details]
Test file for Simplified Chinese

Comment 2 Yu Shao 2003-02-12 06:37:00 UTC
One point to add, beta4 was ok, hope this will help to pinpoint the problem quickly.

Comment 3 Akira TAGOH 2003-02-12 14:32:23 UTC
I've installed libgnomeprint[ui]22 2.2.1.1-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.

Comment 4 Leon Ho 2003-02-12 15:58:07 UTC
Tagoh-san, will it related to NPTL on latest glibc etc? 

Comment 5 Leon Ho 2003-02-12 17:31:19 UTC
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 17:41:07 UTC
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 18:53:06 UTC
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 18:58:39 UTC
Leon:
not sure. perhaps it's related the filters? at least pstops works for me, though.


Comment 9 David Joo 2003-02-13 00:49:07 UTC
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.

Regards,
David Joo

Comment 10 David Joo 2003-02-13 00:51:28 UTC
Also, save to a pdf file crashes gedit.. it seems...
I tried to save it to four.pdf

Comment 11 Yu Shao 2003-02-13 03:24:21 UTC
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 06:57:13 UTC
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 07:14:14 UTC
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
etc) SUCCESS
Job 20 - print out four.txt with en_US settings on gedit (no pre-filtering etc)
SUCCESS
Job 21 - print out double4.txt with en_US settings on OO (no pre-filtering etc)
FAILED

Comment 14 Leon Ho 2003-02-13 09:03:49 UTC
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) 
successfully 

Comment 15 Leon Ho 2003-02-13 12:44:53 UTC
Created attachment 90046 [details]
double4.txt

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
ZYSong18030
- Print it to printer

Comment 16 Tim Waugh 2003-02-13 14:16:01 UTC
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 15:19:46 UTC
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-14 00:16:38 UTC
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.