Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||need workaround for files that cause OOo to crash|
|Component:||open-import||Assignee:||AOO issues mailing list <issues>|
|Status:||UNCONFIRMED ---||QA Contact:|
|Issue Type:||ENHANCEMENT||Latest Confirmation in:||---|
Description tmber 2006-03-10 00:47:51 UTC
Several times, I have ended up with OOo Impress files that could not be opened because OOo would crash when loading them. That sort of thing is very seriously and makes Impress nearly unusable for preparing presentations: a user can't use a presentation tool if he has to fear that making even a small change will result in a presentation file that cannot be loaded or displayed. Somehow, this needs to get fixed. Frankly, I don't have much confidence that a huge C/C++ project like this is ever going to catch all the bugs that cause the application to crash. But at least a workaround for these kinds of problems would be good. My suggestion would be to create a robust import function that gives the user more control over what slides get loaded. In particular, it might give the user the following options: -- exclude all embedded images -- exclude all linked images -- exclude all objects -- remove aniations -- exclude specific slides -- remove all theming Such a workaround is less than perfect, but until OOo stops crashing, it's necessary.
Comment 1 wolframgarten 2006-03-10 07:49:51 UTC
I have never met an application from the normal user variety that does not have defects or crash. Every software has defects. If you have crashed: did you ever sent a crash report if you where offered to? Which email did you use, which description? This would help us to fix the problem. If you cannot give us a detailed stp by step description or a document with which the problem occurs we go on to search for the needle in the haystack. But your idea makes sense. I will change this issue to enhancement and reassign it. Thanks for your help.
Comment 2 tmber 2006-03-11 03:16:43 UTC
"I have never met an application from the normal user variety that does not have defects or crash. Every software has defects." The problem isn't that OOo has defects, the problem is in the way it handles them: if it encounters a defect, it just throws up a dialog box and says "sorry, report it and maybe we'll fix it some time". A lot of other software doesn't do that--it attempts to fail and recover gracefully. "If you have crashed: did you ever sent a crash report if you where offered to?" Yes, multiple times. So, what do you suggest? That I postpone my presentation until you get around to fixing that particular bug? Making software robust and dependable doesn't mean fixing all the bugs, it means having it fail gracefully in the presence of the bugs that are inevitably there; OOo doesn't, and that's a major defect. If you don't like the workarounds I suggested, maybe you can find some other solution. But if you want people to take OOo seriously, the situation that a user saves a file and then can never load it into OOo again because OOo reproducibly crashes right after loading it simply is not acceptable.
Comment 3 Bugcruncher 2014-10-30 21:56:00 UTC
no activity for 8 years, should be closed