Created attachment 68303 [details]
When trying to open older Lotus 123 files with extensions .wks, .wk1 til .wk4 I get file read error after the question for the character set.
"Read-Error unkown Lotus 1-2-3 file format"
Created attachment 68305 [details]
.wk4 returns "file read error" after the question for the character set.
"Read-Error unkown Lotus 1-2-3 file format"
Created attachment 68306 [details]
.wk3 returns "Read error, there is no filter available for this file type"
.FM3 file in next attaxchment.
Could not produce a .wk2 or .wks file.
.wk1 works fine.
Created attachment 68307 [details]
Created attachment 68308 [details]
Hi Horst, LibO also can't open cans, but is that a bug? ;-)
Additionally lifecycle of 3.5 has ended, so it's not useful to add Bugs there.
For gerneral criteria whether a bug should be rated as MAB please see <http://wiki.documentfoundation.org/Most_Annoying_Bugs>!
My results with "LibreOffice 184.108.40.206 rc German UI/Locale [Build-ID: 3215f89-f603614-ab984f2-7348103-1225a5b] on German WIN7 Home Premium (64bit):
"universal-content.wk4": Error Message: "Unknown Lotus-123 format" . Result is expected, in Fileopen only .WK1, .WKS, .123 are offered. Master 3.7 also fails, like AOOo 3.4.1. Gnumeric 1.10.14 opens the document without problems. So we also should be able to do that?
"universal-content.wk3" in reality has name extension ".fm3" seems to be bit by bit identical with "universal-content.fm3", I do not know ".fm3". I also renamed second attachment to .wk3 and checked. None of the test programs was able to open the documents.
.wk1 can be opened without problems, as stated by reporter, so I obsolete this not required attachment
This is not a MAB, but an enhancement request.
I believe this never worked , inherited from OOo, so I modified
Please contribute info concerning "universal-content.wk3" - "universal-content.fm3", why did you attach 2 identical(?) documents?
Can't see a regression (also not working in 3.3.3) so I remove Regression key work (@Markus: hope I did not miss something?)
Removed unrelated CRASH bugs.
Comment on attachment 68308 [details]
Is a document what can be imported without problems, so useless
FM3 files are the formatting data for wk3 formatted files, so they go together with the wk3 file. Lotus 123 used to use both. See here :
Not that that changes anything with respect to this bug report. I don't think these files were ever imported by OOo, let alone LO, so IMHO this would be a feature request, or enhancement of the existing file filters.
1) I think Alex answered the question about not identical .wk3 and .fm3 file.
2) You are right it shows only .wks, .wk1 and .123 as legal imports. But it is odd that LO recognizes the Lotus format and I was browsing in the Lotus filter source and it has header readings for .wk3/.fm3 in it. So it looks somebody worked on this problem in the past (Markus?).
I opened this bug in response to Markus in bug 55222, which was not a crash but a read error.
I can not decide right now how importent the import of older Lotus files is for the users of LO. .wk3 is first Win version of Lotus 1-2-3.
I would say if @markus sees it important and has nothing more important to do :-)) let him decide to change it to enhancement.
Thank for effort anyway and I am not realy glued to this bug.
I'll make this one an easy hack at some point.
It is not a regression. Lotus filter import is not that important but I'm willing to mentor anyone wanting to spend some time improving the filter.
Some code pointers:
Lotus import code is in sc/source/filter/lotus/ and a file format specification is at http://www.schnarff.com/file-formats/lotus-1-2-3/WSFF2.TXT and http://www.schnarff.com/file-formats/lotus-1-2-3/WSFF1.TXT.
If you are interested in extending the support please contact me and I'll provide some smaller test documents.
There are some more code pointers needed and I will add them as soon as someone shows interest in this easy hack.
adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility.
see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
I had to spend a while digging into an old WK4 file to extract some data. I thought I'd document my main finding here:
opcode 0x17 appears to be a 10-byte extended precision float. After the record header, there is a two byte row number, one byte sheet number, and one byte column number. These are common to a few record types. The remainder of it is the value, in the format described here:
I was able to extract these, at least for the small positive numbers in my sample, using the following Python code:
a = int.from_bytes(r.data[-2:], 'little')
sign = -1 if (a & (1<<15)) else 1
e = a - (a & (1 << 15)) - 16383
m = int.from_bytes(r.data[4:-2], 'little')
val = m / (1<<(63-e))
0x16 is a label, with the same row/sheet/column fields.
I started looking into making a patch, but I got confused because there appear to be opcode lookup tables both in optab.cxx and as switch statements in lotread.cxx, with different opcodes in them.
just for note as I am working on libwps(*) on a filter for Lotus wk3, wk4 files, ...
The following opcodes stores the main content:
- 0x16: contains the text strings,
- 0x17: contains big float ( 10 bytes)
- 0x18: contains small int/float ( 2 bytes)
- 0x19: contains big float ( 10 bytes ) + a formula + sometimes a string ( maybe comment)
- 0x1a: contains a string ( the result of a formula )
while the opcode 0x1b stores different data : colors, font names, graphic styles, graphic, ....
You can find some details in the file Lotus.cpp ( function LotusParser::readZone ), LotusSpreadsheet.cpp at http://sourceforge.net/p/libwps/code/ci/master/tree/src/lib/
( even if this is a work in progress )
(*) by error, libwps can already read the wk1 files ( which shares the same format as MsWorks DOS Wks files ), so why not convert also the other Lotus's files :-~
Let's mark this as assigned then. We will close it when the new libwps is integrated to LibreOffice.