Description: The attached wk1 spreadsheet contains the formula +A301 in cell A6. When opened by Calc, cell A6 displays the value of cell A301, but its formula is =A45. When the value in A45 is changed, A6 displays A45's value. The wk1 spreadsheet also contains the formula +A300 in cell A5. When opened by Calc, cell A5 displays 0 even though cell A300 contains "ALPHA TEST". A5's formula is =A44. In contrast, Gnumeric 1.12.35 correctly opens the wk1 spreadsheet. The formula shown for cell A6 is =A301 and the formula shown for A5 is =A300. Cells A6 and A5 correctly display the values of A301 and A300 respectively. Steps to Reproduce: 1.Open the attached wk1 spreadsheet 2. 3. Actual Results: Observe that the formulas in A5 and A6 are =A44 and =A45 respectively. Observe that A6 displays 100 until a different value is entered in A45. Expected Results: The formula shown for cell A6 is =A301 and the formula shown for A5 is =A300. Cells A6 and A5 correctly display the values of A301 and A300 respectively. Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: Version: 6.0.7.3 Build ID: 1:6.0.7-0ubuntu0.18.04.10 CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); Calc: group The problem was also observed in Calc on Windows, with LibreOffice 6.3.3.2 (x64)
Created attachment 154660 [details] Original example Lotus 1-2-3 spreadsheet for this bug
Confirmed. At least already since LibreOffice 5.3 (earliest version I have at hand).
Ooen fine with: Version: 4.4.7.2 Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600 Locale: es_ES first bad for me (on what I have): Versión: 5.0.0.0.beta2 (x64) Id. de compilación: 900960d3e4220f7e04f45c9bf45a1cd92cd06aff Configuración regional: es-ES (es_ES) Seems a regresion in 5.0 BTW version working fine shows as default character set 'Western Europe DOS/OS2-437/EEUU', while bad version shows 'Western Europe DOS/OS2-850'
Turns out this is a bad file format detection in external libwps src/lib/WKS4.cpp WKS4Parser::checkHeader(), resulting in version 1 instead of version 2. For the default character set similar as the creator isn't passed up in src/lib/WPSDocument.cpp WPSDocument::isFileFormatSupported() staying default libwps::WPS_MSWORKS so in writerperfect/source/calc/MSWorksCalcImportFilter.cxx MSWorksCalcImportFilter::doDetectFormat() the wrong type name "calc_MS_Works_Document" is assigned, and in MSWorksCalcImportFilter::doImportDocument() wrong "CP850" encoding is chosen (note also the encoding dialog's title reads "Import MS Works file"). Taking.
Regression after https://git.libreoffice.org/core/+/f9568335a653f72732f9c8ebf007cf8850021ff9
The culprit isn't the patch though but the newer libwps version pulled in.
The workaround for this case btw is to pre-select the filter "Lotus 1-2-3" in the file open dialog, which opens the file with a different filter.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5a7d4ee6c4dd92758e0fd213671251e96d6e7f08 Resolves: tdf#127887 Fix libwps wrong Lotus version detection It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Pending review https://gerrit.libreoffice.org/80015 for 6-3
Verified in Version: 6.4.0.0.alpha0+ Build ID: c9336bfb6bbf6d73d3f23c124262ade30133448d CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: en-US (ca_ES.UTF-8); UI-Language: en-US Calc: threaded @Eike, thanks for fixing this issue!
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-6-3": https://git.libreoffice.org/core/commit/ce15460e7b7a5e4930574f88660d03ed3d11fbfe Resolves: tdf#127887 Fix libwps wrong Lotus version detection It will be available in 6.3.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1c58b2a437a7083c40c93a1c2e12a6fe6b6fd637 Replace hotfix with upstream patch, tdf#127887 follow-up It will be available in 6.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/54239c99b7f9d82ec14492aff29e450abdafc61d Replace hotfix with upstream patch, tdf#127887 follow-up It will be available in 6.4.0.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.