OpenOffice insert graphics, print and sometimes save=frozen client

Jim Kronebusch jim at
Mon Sep 17 04:28:13 BST 2007

> 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 :-)


This message has been scanned for viruses and
dangerous content by the Cotter Technology 
Department, and is believed to be clean.

More information about the edubuntu-users mailing list