Apache OpenOffice (AOO) Bugzilla – Issue 5044
No spaces / no pages when printing to Kyocera FS-1800
Last modified: 2013-08-07 14:43:39 UTC
The Kyocera FS-1800 is a postscript capable printer, and is set to postscript mode. There are two problems, probably related: 1. On certain documents nothing is printed. The printer waits for data, and eventually gives a "form feed timeout" error message. Example document: http://www.devnet.org.nz/oo_no_print.doc This is a MS Word document. Please note other documents are printed. 2. On certain documents, there are no spaces between words on some lines when printed. Example: http://www.devnet.org.nz/oowriter_print_bug.png (please save link to local file system as server not configured to serve PNG images!!) This was also a MS Word document. With this document, page is printed after printout the printer also waits for data and gives "form feed timeout" error message. These same documents print fine from OpenOffice1.0 for Windows. http://www.devnet.org.nz/KM1800EE.PPD contains the PPD used. No other Linux applications have issues when printing to this printer. OpenOffice under Linux can print to our HP Laserjet 1100 without issues. Thank-you. Damon
OOo 1.0 for Linux also fails to print its help pages correctly to the Kyocera FS-1800, i.e. there are no spaces between words. But it does seem the text in bold is in the correct place. Damon
Reassigned to Ulf.
Downloaded the bugdoc. Not reproducible with OOo1.0.1. I noticed that the document uses paper format "letter". Make sure that your printer supports this paper format. Or change it to something else in OOo Writer: Format/Page. > OOo 1.0 for Linux also fails to print its help pages correctly you probably use RedHat, do you? This is probably double to issue 4718. us->pl: "form feed timeout" is this something that could be caused by us? The bugdoc displays fine in gs, with the provided PPD.
"form feed timeout" is just the printer's way of saying it considers the job looping and will abort it. This could be related to a wrong pagesize; this could be checked by erasing everything in the PostScript file between and including %%BeginFeature and %%EndFeature pairs. If that solves the problem then it would be helpful to know which of them is the culprit by erasing only single ones until it works. I would do that myself, but we don't have such a printer. The font issue should be rechecked with OOo 1.0.1; this may have to do with the pspfontcache issue (issue 4366).
US->Damon Lynch: What are your findings in OOo 1.0.1/OOo643? Did you find anything suspicious between %%BeginFeature and %%EndFeature in the PS file that bothers the printer? Pls. cooperate, as we are heading to OOo 1.1 Beta, and I considered your issue to be important for Beta.
Apologies for the delay. I've tried OO.org 1.01 as found in Mandrake 9.0 and the 1.02 & 643C tars as single user, also on Mandrake 9.0. After following the suggestions, this is what I've found: 1. 1.01 and 643C both do not print US letter (the printer is set to A4), with "waiting... time out" being reported by the printer. This happens with all pages that are US letter (the printer is set to A4). As soon as the document is set to A4, it prints. Alternatively, if I remove these lines from the ps file, it prints: %%BeginFeature: *PageSize Letter <</Policies <</PageSize 2>> /PageSize [612 792] /ImagingBBox null>> setpagedevice %%EndFeature So if that is expected behaviour, there is no bug, by the looks of things. As an aside, gnome 2.0 appears to have the same problem, but KDE 3.03 seems to somehow resolve letter to A4. I must admit I'm a bit confused, as the printer normally prompts for letter paper to be inserted if that is what it is sent. Perhaps that is for windows only? 2. 1.01 still prints bold / italics/ bullet characters badly (this is with pages size being A4). But the good news is that 643C prints the same page perfectly. I don't know if this was related to issue 4718 in any manner, as the help pages were always able to display correctly. 1.02 seems to print bold / italics better, but no bullet points are printed. I hope that clarifies things. Thanks, Damon
us->pl: pls. close if it is a user error resp. printer limitation.
The printer behaviour is still strange; the /Policies<< /PageSize 2 >> explicitly tells the printer to interact with the user in case of a missing paper. Still this is not an issue with OOo as the commands are delivered by the printer vendor. The font issue with the bullets probably stems from opensymbol which is broken; that issue is said to be fixed in the beta. I think there does not remain a problem for OOo to solve here, so i'll close the issue.
closed