OpenOffice insert graphics, print and sometimes save=frozen client

Philipp Hanselmann philipp at
Mon Sep 17 07:12:14 BST 2007

Hi Jim

I don't know what server CPU you have ..., anyway
Have you checked in the BIOS, if  Threading Technology is enabled ?

Jim Kronebusch wrote:
>> 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

SchoolNet NA - Youth Empowerment through Information and Communication Technology

SchoolNet Namibia provides sustainable, low cost technology solutions and internet access, as well as technical support, training services and rich educational content to schools, community-based educational organisations, and educational practitioners throughout Namibia.

More information about the edubuntu-users mailing list