Problem: According to the release notes for LibreOffice 4.0, the support for legacy binary StarOffice files: 1.0 -> 5.0 is dropped. The result is that all users who previously used StarOffice will not be able to open their files anymore. In my case, it is some 400+ files in the formats .sdw and .sdc. Solution: Please retain import of StarOffice legacy file formats in LibreOffice. Export is not necessary, but import is in fact important if you do not want people to lose lots of (old) valuable data. Alternative: Provide a wizard that crawls file systems and auto-converts legacy StarOffice files to ODF files.
Indeed TDF should make sure that these documents can be opened and transferred to the current ODF format. But I think it's not appropriate to keep filters for these formats in LibO for evermore, that only produces additional test and programming costs. I believe it's enough to have Versions what can to the job at a safe place for the next 20 years (at least we should do our best to ensure that) and to have a prominent hint on the TDF and LibO Website how to proceed with these old LibO versions for document format conversion. Or may be there are more elegant alternatives (except keeping these filters in latest versions)?
the filters for legacy binary StarOffice file formats were removed because they put a large maintenance burden on developers and turning them into extensions is not possible without substantially rewriting the filters (these filters are 15% of the entire code base, which is in no relation to the value they provide to users). you can use File->Wizards->Document Converter... in LibreOffice 3 to convert your existing documents to ODF.
Michael & Rainer are entirely right - it's a horribly burden to carry around. Of course if you want to do some development work to allow external binary filters to be used in LibreOffice 4 - (in fact I think we have a hacky patch around that does that), and then did a -quite-small- bit of adaptation to LibreOffice 3.6 - so you can have it installed in parallel with LibO 4.0 and use it to convert those documents - that would be fine by me. The whole thing is a reasonably do-able easy-hack; but I'd want someone that cares about this to be serious before I start digging out code pointers.
Thanks for contributions and discussion on this bug. Of course, I understand the issue lots of old code in LibreOffice which is needed for the support of the old binary StarOffice files. However, the main question is, what happens to users of LibreOffice 4.0 who want to import .sdw or .sdc files? I assume that the file conversion tool in 4.0 will not be able to convert .sdw/.sdc, right? Suggestion: It should be still possible to select .sdw /.sdc in the "file"->"open" dialogue, followed by a window explaining the options for the user: a. To use a version of LibreOffice < version 4, b. to use the online conversion tool <link> xyz </link>. This would be really helpful for users and I am sure that there is a conversion web service existing which actually uses OpenOffice/LibreOffice in its back end?!?
Gerry - we have adding a dummy filter for this that warns the user with some helpful pointer on our TODO for 4.0. On the other hand it's not getting done - so if you want to jump in and hack on that - it'd be much appreciated.
FYI, MS Office, unless an external DLL was required like PowerPoint 4.0/95 converters, tend to disable by default but not remove support.
I realise this is a RESOLVED WONTFIX. Reasons are understood. However, I did want to provide some historical end-user feedback. I feel this is imperative for context and comprehension on user-habits. I've been using computers since I was 6. This may seem trivial, but bear in mind that I am nearing 50, and that anyone having a computer was unusual, when I was 6. In all those years, I have had documents that I have kept on my computers. I am, in fact, I suspect I am one of the first people that lived their entire lives storing documents digitally... and keeping those documents. For example, I have calendar entries in my phone's calendar, going back to the 1994. I can actually discern what I did on Wed, Dec 28th, 1994. I have text documents going back to the early 80s, dumps from fidonet and punternet mail messages. Private notes. Code written on my C64. I have emails going back to the late-90s. All of this still readable. This is all just for context. Regardless, my point is .. when someone lives such a life? Older documents are like a book kept in a closet. Documents such as a diary, letters written to friends, relatives, and for important life events. Notes kept on observations, everything and anything. Now imagine you're not 20, or even 30 any more. :P You're the sort that might put a screwdriver down on a garage workbench, and literally, very literally need it 14 months later.. and know where it is. Certain parts of your life move slowly, and have little change. Which is why only now, in late 2019, did I discover this removal of sdw format imports. Literally, 5+ years might go by, before someone might attempt to open a document from 20 years ago. I am not specifically blaming anyone for this. I can't imagine keeping 30% of a codebase, not when short on time, or porting/modifying code that 14 people and a signing gorilla in the Hague might use. The removal makes sense. What I just wish, is that there was more information. I've upgraded through three entire Debian releases since 3.x has disappear on my system, making it annoying to attempt a recovery. I would ask that OOo devs consider this. Just ponder it. I don't know if there is a better way to inform users. Or to get them to port before removal. Maybe... down the road, there might be a "OH! I've noticed you have SDW formatted documents! In the next major release, they're be gone. Do THIS to save them or else you'll feel pain later!!" sort of thing? Well, there's my 2 cents. No complaints about removal, but hopes that removal will happen with a transitory period. Also, please don't become excited that I keep a calendar entries from the 90s, obtain it, and travel back in time and kill me using that specific location data. I assure you, I'll be reincarnated, and old enough to re-write this bug regardless.