Bug 122775 - Loss of Information in Quattro Pro .wq1,.wq2 Files [libwps]
Summary: Loss of Information in Quattro Pro .wq1,.wq2 Files [libwps]
Status: RESOLVED WORKSFORME
Alias: None
Product: Document Liberation Project
Classification: Unclassified
Component: General (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-01-17 06:05 UTC by EMP
Modified: 2021-09-21 13:25 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
add a file to show the problem (1.58 KB, application/octet-stream)
2019-05-24 10:12 UTC, osnola
Details
add a quattro screenshot corresponding to number.wq1 (17.70 KB, image/png)
2019-05-24 10:13 UTC, osnola
Details

Note You need to log in before you can comment on or make changes to this bug.
Description EMP 2019-01-17 06:05:51 UTC
Description:
I have just started using this product to convert old Quattro Pro files (WQ1, WQ2)into Excel XLSX files.  I can run Quattro Pro for DOS directly on a Windows 7 PC, and the files contain correct information.  When I open those same files with LibreOffice on a Windows 10 PC, I find that numbers smaller than about 1E-6 are not imported accurately.  Once numbers are smaller than about 1E-8, they are set to zero in LibreOffice.  This is on import, before conversion to XLSX files.  My only recourse thus far is to open the file both in Quattro Pro and in LibreOffice, so I can manually make repairs in LibreOffice and then convert the file to XLSX.  I think LibreOffice is not carrying enough decimal places during number import and conversion.

Steps to Reproduce:
1.Build a DOS Quattro Pro WQ2 file containing numbers ranging from 0 to 1E-14, using several significant figures in those numbers.
2.Import the Quattro Pro file into LibreOffice.
3.Observe the error in conversion.  If you cannot do this, I can provide a suitable Quattro Pro file.

Actual Results:
Actual                    Imported
1.10E-06                  1.10E-06
6.76E-07                  6.80E-07
4.07E-07                  4.10E-07
2.45E-07                  2.40E-07
1.41E-07                  1.40E-07
7.24E-08                  7.00E-08
3.72E-08                  4.00E-08
1.91E-08                  2.00E-08
8.51E-09                  1.00E-08
4.47E-09                  0.00E+00
2.29E-09                  0.00E+00
1.41E-09                  0.00E+00
9.55E-10                  0.00E+00


Expected Results:
 Imported numbers should match Actual numbers


Reproducible: Always


User Profile Reset: No



Additional Info:
That's all I know to say.  I don't know how to answer the next two items.
Comment 1 raal 2019-02-05 16:38:52 UTC
Hello,

Thank you for filing the bug. Please send us a sample document, as this makes it easier for us to verify the bug. 
I have set the bug's status to 'NEEDINFO', so please do change it back to 'UNCONFIRMED' once you have attached a document.
(Please note that the attachment will be public, remove any sensitive information before attaching it.)
How can I eliminate confidential data from a sample document?
https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F
Thank you
Comment 2 osnola 2019-05-24 10:10:33 UTC
This will be fixed with https://sourceforge.net/p/libwpd/libodfgen/ci/0f8a5b79ee841afa8b4beee53957cb2785a7249a/

Note:
- in fact, this problem currently affects all conversions done with libwps
Comment 3 osnola 2019-05-24 10:12:13 UTC
Created attachment 151657 [details]
add a file to show the problem
Comment 4 osnola 2019-05-24 10:13:39 UTC
Created attachment 151658 [details]
add a quattro screenshot corresponding to number.wq1
Comment 5 osnola 2021-09-21 13:25:23 UTC
This problem must be solved with LibreOffice 7.2 which integrates a new version of libodfgen, so I closed this bug...