> I've been trying to make this fail. Can't The document you sent me works > just fine.
> Printer: > Brother HL-1060 laser printer, setup in cups, using cups supplied driver. > Connected initially to server, via usb to parallel adapter > Also tested with being plugged into thin client, and remote print queue set > up via jetpipe. > Observations: > Mouse does become slightly jerky, probably from printing querying fonts > on client, however, no crash observed. > No errors in .xsession-errors of note related to OO.o, nothing observed > in /var/log during the time period when test was conducted. I think this has to due with a printer memory issue. I have tested 3 clients, a DevonIT 6020p with 128MB RAM, a Term150 with 128MB RAM, and a Gateway 3200 with 128MB RAM. All the clients have different processor speeds, same amount of RAM, and all different Graphics cards. All seemed to exhibit the same problem with printing to the Networked HP 4000, but when printing to a HP 4550 or the Ricoh, they all exhibited the same thing you describe (jerky graphics and mouse until the job is queued to the printer, which is more than tolerable). The only difference is the DevonIT 6020p has this weird problem of scattering the graphics from the document all over the top of the screen covering the toolbars, etc and don't clear up until the object repaint on the screen by selecting menus or the monitor sleeps and is re-awakened (but I am sure this is a problem with either the Graphics chip or driver for the DevonIT as it also has other minor graphics problems). This leads me to believe the problem lies either within the cups driver for the HP4000 or with printers with lower onboard memory. I assume all instances where you printed to test allow for better caching of the print jobs (print server or direct attachment, where networked with the jet direct relies totally on printer memory). And since the problems I am seeing involve graphics I think this is even more backed up. Tomorrow I am going to look into how much memory is in each type of printer we have and then test print to it, this may paint a better picture. So at this point I am thinking this problem is due to the print job being sent to a printer that does not have enough onboard memory to cache the job in its entirety, and at some point the communication between the printer and the client/server about where to store the extra data is lost and maybe this is causing the freeze. Not sure if that makes sense but being that you understand how this stuff talks to each other this may make more sense to you. If that is the case I may be able to band-aid my problems by running the printers from a print server or increasing the internal memory (we have probably a dozen of the HP 4000N's on campus). If anyone has a similar setup and could confirm that the problem happens with networked printers with say less than 2MB onboard RAM this may give the issue more merit. I am glad to hear that you and Dave Trask are not able to reproduce the errors except the sluggish mouse response while the print job is dispatched. Wondering why this happens? I would think the server itself is actually sending the job and my server having never seen higher than 5% total CPU usage or more than 3GB of the 16GB RAM being used plus 6GB NICS teamed I would think could handle it. There must be something about the job being sent that messed with X being displayed on the client, right? This may be a clue as to why mine freeze on lower memory printers. I have contacted DevonIT about my video issues with the 6020p. I think this is a separate problem not related to printing. I am hoping to find a tweak for the video card in xorg.conf. If I receive a fix from them I will post it back to the list. Scott, thanks for taking the time to test. Sorry for being a pain in the ass the last two weeks. I just put a lot on the line switching the school over and feel I'm under a lot of pressure to get things working as good or better than with the Mac setup, which is probably why I sound pushy.....but that doesn't mean my lack of good testing and a risky switch is your problem :-) If nothing else I just hope my struggles help evolve Edubuntu and make it better for the future and other users. Besides, this is all very heavy testing and any flaws found now may be able to be squeezed into Gutsy. I wish I understood programming better and could lend a hand in development. You handful of guys are trying to accomplish more than a few billion dollars and a really large Seattle based company can :-) Jim -- This message has been scanned for viruses and dangerous content by the Cotter Technology Department, and is believed to be clean. -- edubuntu-devel mailing list edubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/edubuntu-devel
