LibreOffice 25.2 Alpha 1 Open-Source Office Suite Released

[oiaohm]

Excel is a terrible tool for data analysis, but it is just good enough and cheap enough to make naïve users not want to buy* and learn how to use something more appropriate, When Microsoft's Office suite is the standard installation for businesses, it is very hard to justify a separate tool when Excel is regarded as 'good enough' by people who ought to know better, but don't.

*Or fight with a corporate IT department to install FLOSS software.

https://posit.co/products/open-source/rstudio/ Rstudio no charge FLOSS for but it has a few limitations then its over 1000 USD per install per year commercial pro edition.

R and python with all the features is absolutely not cheap. It departments not wanting to install FLOSS versions where they suit end up making this cost way way worse. Yes Rstudio allows having some of your users on the FLOSS and some of your users on the pro.

Parties like posit.co can only change so much for these tools due to how much mistakes done with Excel/spreedsheets in fact cost. Lot of training places still teach only Excel for data analysis even after how well documented spreadsheets are not up to the job.

[Old Grouch]

I am fine with that. The issue is that the change got in without being noticed.

I agree that the change getting in without being noticed is poor.

I would like to see a ISO version of ZIP but ISO IEC 21320-1 2015 is absolutely not it.

I'd like to see an ISO (FLOSS) data-at-rest compressor/decompressor. I also am not convinced that ISO IEC 21320-1 2015 is the best option for this.

Yes people spend all this time learning how to use Excel for data analysis to get into the workforce these days to be told you are forbid from using it because you must use R or Python because Excel is not trusted due to the issues with spreadsheets and the mistakes that will happen when humans use spreadsheets along with Excel designed in defects that cause Excel to miss calculate.

Excel is a terrible tool for data analysis, but it is just good enough and cheap enough to make naïve users not want to buy* and learn how to use something more appropriate, When Microsoft's Office suite is the standard installation for businesses, it is very hard to justify a separate tool when Excel is regarded as 'good enough' by people who ought to know better, but don't.

*Or fight with a corporate IT department to install FLOSS software.

[oiaohm]

[QUOTE=Old Grouch;n1510483]The fact that ODF v1 defined ZIP via Info-ZIP Application Note 970311, 1997. I regard as somewhat embarrassing.

Open Document Format for Office Applications (OpenDocument) Version 1.3 OASIS Standard 27 April 2021

https://docs.oasis-open.org/office/OpenDocument/v1.3/os/part2-packages/OpenDocument-v1.3-os-part2-packages.html#nref-zip

[ZIP] PKWARE Inc. Zip APPNOTE Version 6.2.0,
https://www.pkware.com/support/appli...-note-archives, 2004

This is the same in 1.4 as well.

https://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part3.html#__RefHeading__752781_826425813

There is no clean link to it as with 1.3 but the change from Info-ZIP to pkware 2004 is 1.2

Old Grouch OpenDocument/ODF version numbers are 2 numbers. 1.0 and 1.1 are the info-zip 1997 that is original 32 bit only zip. 1.2 and newer is the PKWARE define that contains zip64. Yes this slipped under the radar and got into ODF in 2011.

I think it would be reasonable for a future revision of the ODF standard to include a newer compression method (or even several), but retain backwards compatibility by allowing no compression, or ZIP compression.

I am fine with that. The issue is that the change got in without being noticed.

It 'would be nice' if any future compression standard used by ODF were an ISO standard and FLOSS, I'm not sure if this has yet been achieved: ZIP file format, Standardization

https://nfoworks.org/notes/2013/04/n130401-13R5EoW9HY4ZvQH/n130401c11-ISO_IEC_21320-1_2015.pdf

When you open up that standard you notice its hey lets just use a newer pkware zip format version being 6.3.3 then proceed to forbid things like splitting zip archives across multi files.

Yes the problem of ISO IEC 21320-1 2015 is it effectively makes a sub format of the PK Ware zip format that not compatible with normal zip tools.

I would like to see a ISO version of ZIP but ISO IEC 21320-1 2015 is absolutely not it.

I think it is fine that the maximum number of rows or columns has no artificial limit: an otherwise conforming application can point out what its maximum limits are, and fail with an appropriate and informative error message if presented with a file that exceeds the application limits.

The point I was making is that you do see ods documents with larger row and columns than any spreadsheet program can open. Yes you see people doing data analysis passing around spreedsheet files but it is very common they are files no spreedsheet program.

R language addon xlsx generator does not check the row or column limit either and will very happy read/write a xlsx document larger than Excel and any of it other spreadsheets can open as well.

This is one of the problems people see ODS or XLSX files been passed between people doing data analysis and presume those people are using excel or libreoffice or something spreadsheet then you notice how often these files being passed around are bigger than those programs can handle so they are coming out of something other than a spreadsheet program because today all spreadsheet programs have the same upper limits.

R and Python has replaced Excel fora lot of data analysis and this can be seen in the spreadsheet files being passed around that are too large for spreadsheet program to process. Yes malicious compliance the boss has told data analysis people to use a spreadsheet output format but they don't want the issues using a spreadsheet program bring that are part of the design of spreadsheet itself.

Yes lot of the reasons why you must have a spreadsheet program is false when you look at industry and find more and more of those use cases are done by data analysis using R or Python and this can be seen in the generated files.

The data analysis on libreoffice development to monitor development is done in R not Calc. Gets better Microsoft developers have also said the data analysis on MS Office development is also done in R.

The big thing that data analysis need out a spreadsheet program going forwards is to be able to access legacy formats to access old data and the only spreadsheets for that is ones based off libreoffice code base.

Yes people spend all this time learning how to use Excel for data analysis to get into the workforce these days to be told you are forbid from using it because you must use R or Python because Excel is not trusted due to the issues with spreadsheets and the mistakes that will happen when humans use spreadsheets along with Excel designed in defects that cause Excel to miss calculate.

[Old Grouch]

Depends on version of standard. Early version of ISO/IEC 26300 defines ZIP as infozip 199x something that was only 32 bit zip as in 4g limit then the newer version of standard update to 2004 pkware define of zip that includes ZIP64 that takes this to effectively 16EiB. This is one of those not intentional changes it was we will just update the document to use the official newer Zip format to get security things and the ZIP64 came in as by product..

https://www.youtube.com/watch?v=GZPmcpfXIhg

This is why its 2023 when Libreoffice gets ZIP64 support.

Next killer is the Open Document format does not in standard define the max number of rows and columns on a spreadsheet.

https://wiki.documentfoundation.org/Faq/Calc/022

https://support.microsoft.com/en-au/office/excel-specifications-and-limits-1672b34d-7043-467e-8e27-269d656771c3

Yes items like calc and excel has limits on max rows and columns and so do all spreadsheet programs. But these limits means your application is technically non conforming to the outer edges of the standard.

Lot of data tables for statistical processing get over the 1,048,576 rows

The R import and export options for ods really go for the max possible the ISO/IEC 26300 allows. 10 to 20 times the number of rows Calc or Excel will accept no problems right.

The fact that ODF v1 defined ZIP via Info-ZIP Application Note 970311, 1997. I regard as somewhat embarrassing. But given the group in OASIS defining ODF were document format experts, and not data compression experts, I guess it was simply missed until it was an unreasonable amount of effort to change or remedy.
I think it is fine that the maximum number of rows or columns has no artificial limit: an otherwise conforming application can point out what its maximum limits are, and fail with an appropriate and informative error message if presented with a file that exceeds the application limits.

I think it would be reasonable for a future revision of the ODF standard to include a newer compression method (or even several), but retain backwards compatibility by allowing no compression, or ZIP compression.

It 'would be nice' if any future compression standard used by ODF were an ISO standard and FLOSS, I'm not sure if this has yet been achieved: ZIP file format, Standardization

[oiaohm]

ISO/IEC 26300 (Open Document Format for Office Applications (OpenDocument)) is a standard describing a document format - it doesn't say anything about the applications that process documents conforming to that format - so a 60 gigabyte, or even 2 terabyte 'ods' file can quite happily conform to the standard, and it is up to the person who wishes to process the data, which is in an open standard format, to choose a method that works for them.

Depends on version of standard. Early version of ISO/IEC 26300 defines ZIP as infozip 199x something that was only 32 bit zip as in 4g limit then the newer version of standard update to 2004 pkware define of zip that includes ZIP64 that takes this to effectively 16EiB. This is one of those not intentional changes it was we will just update the document to use the official newer Zip format to get security things and the ZIP64 came in as by product..

https://www.youtube.com/watch?v=GZPmcpfXIhg

This is why its 2023 when Libreoffice gets ZIP64 support.

Next killer is the Open Document format does not in standard define the max number of rows and columns on a spreadsheet.

https://wiki.documentfoundation.org/Faq/Calc/022

https://support.microsoft.com/en-au/office/excel-specifications-and-limits-1672b34d-7043-467e-8e27-269d656771c3

Yes items like calc and excel has limits on max rows and columns and so do all spreadsheet programs. But these limits means your application is technically non conforming to the outer edges of the standard.

Lot of data tables for statistical processing get over the 1,048,576 rows

The R import and export options for ods really go for the max possible the ISO/IEC 26300 allows. 10 to 20 times the number of rows Calc or Excel will accept no problems right.

On the other hand, for conveying large amounts of data in a standard formats, I have even heard of people using SQLite databases.

That taps out at 140TB file size that for most cases is big enough. Having means to move around 140TB of data that it own form of nightmare.

[Old Grouch]

Archive mining the person who made the document is most likely 6 feet under so the bounce back does not work. Fun point is R can make ods documents larger than Libreoffice and Excel and every other spreadsheet program can open that are perfectly to ods standard. Yes scary when you see a 60GB single ods file and there is no pictures or anything else in it just data. Yes asking a person working in R for a spreadsheet file can equal getting a spreadsheet file that will not open in any spreadsheet program because it too huge by many times the max size of a normal spreadsheet program.

The largest ods file I have seen so far is 2TB(yes there were pictures in that one as well) and when I ask the person why they made it the answer was their boss asked for the data in spreadsheet format so they did and they did not bother check if their was a spreadsheet program that could open it. People working in R and their malicious compliance is just something else. Yes that ods file is fully to standard 2TB file.

Funny right to open a spreadsheet document at times you absolute must not use a spreadsheet program because the spreadsheet document is too large to be opened by any spreadsheet program.

ISO/IEC 26300 (Open Document Format for Office Applications (OpenDocument)) is a standard describing a document format - it doesn't say anything about the applications that process documents conforming to that format - so a 60 gigabyte, or even 2 terabyte 'ods' file can quite happily conform to the standard, and it is up to the person who wishes to process the data, which is in an open standard format, to choose a method that works for them.

Now, there are quite possibly better formats for data exchange, some of which might even be open standards. ods is not necessarily bad, as the standard describing it is open and freely accessible.

On the other hand, for conveying large amounts of data in a standard formats, I have even heard of people using SQLite databases.

[oiaohm]

Good to know and thanks for describing this case usage. For sure the world would be a better place if the odf and ods standards would be enforced and widespread. Usually, when someone sends me data in spreadsheet format I bounce it back asking for plain text file. In my experience medical doctors and biologists are the least educated in this respect.

Archive mining the person who made the document is most likely 6 feet under so the bounce back does not work. Fun point is R can make ods documents larger than Libreoffice and Excel and every other spreadsheet program can open that are perfectly to ods standard. Yes scary when you see a 60GB single ods file and there is no pictures or anything else in it just data. Yes asking a person working in R for a spreadsheet file can equal getting a spreadsheet file that will not open in any spreadsheet program because it too huge by many times the max size of a normal spreadsheet program.

The largest ods file I have seen so far is 2TB(yes there were pictures in that one as well) and when I ask the person why they made it the answer was their boss asked for the data in spreadsheet format so they did and they did not bother check if their was a spreadsheet program that could open it. People working in R and their malicious compliance is just something else. Yes that ods file is fully to standard 2TB file.

Funny right to open a spreadsheet document at times you absolute must not use a spreadsheet program because the spreadsheet document is too large to be opened by any spreadsheet program.

[timo]

Libreoffice fits in to what you wrote. To have accuracy of results in lots of cases you need to data mine archived data. Libreoffice is the mining tools not the processing plant. So professional working in science to industry should be using libreoffice form time to time to get information out of archived documents or their results are most likely missing inputs so are possible garbage in/garbage out due to missing data.

Libreoffice used as the tool it made to be by many countries national archives it a great tool. This is different to a general user MS Office replacement. Ease of UI to make new documents from scratch is zero important in the use national archives case, Be safe with virus infected documents and able to open the documents is way more important in the national archive use case..

Good to know and thanks for describing this case usage. For sure the world would be a better place if the odf and ods standards would be enforced and widespread. Usually, when someone sends me data in spreadsheet format I bounce it back asking for plain text file. In my experience medical doctors and biologists are the least educated in this respect.

[oiaohm]

Yes, I was a bit in a hurry and did not provide links, thanks for doing it. There are more, for instance regarding publication standards

There are lots of documents that are once use in business so speed of processing on them is more important than perfection. Some of the issues with MS Office documents being opening by libreoffice and libreoffice by MS Office is the fact Libreoffice does have Kerning on by default and this does effect document spacing.

https://eusprig.org/research-info/horror-stories/

Scroll down this one you will find historic hand done spreadsheet has errors.

Calculation errors in the Babylonian tablet Plimpton 322

Yes this entry.

The issue with spreadsheets starts at the concept and the problems shows before computers with them on tablets and in paper being processed by humans so the software errors are just a icing on top of a very bad cake.

By the way, to me professional is everything from science to industry requiring standards of accuracy, reproducibility and quality. You are right that there might be scenarios where LO/MSO are ok to use but I would say these are very rare instances.

I have lot more valid cases of LO than the other spreadsheet options. Remember science you need archival data. Libreoffice opens spreadsheets from the 90s and before that every other modern spreadsheet program goes I am not opening that. So I see libreoffice calc as not data processing tool but as a data acquirement tool. Data processing is job of R and python.

https://wiki.documentfoundation.org/Feature_Comparison:_LibreOffice_-_Microsoft_Office

Import of DOS/Windows legacy spreadsheet formats: Lotus 1-2-3, Quattro Pro (v1-5.5 DOS; v1.0-6.0 Windows), Microsoft Works spreadsheet, Microsoft Multiplan (v1-3 DOS)

Yes Excel and none of it alternatives other than Libreoffice/CollaboraOffice related are going to open this stuff. Yes this data cannot be taken simple straight into python or R.

This is why I don't lump MSO with Libreoffice/CollaboraOffice. In fact I don't lump Libreoffice/CollaboraOffice in with the other Office suites. Libreoffice is really the tool when you need to be data mining archives looking for data. Please note the data mining usage formatting is secondary to opening the document.

Yes Libreoffice/CollaboraOffice also opens more historic document formats in writer as well. Its seriously you go archive dumpster diving for data one of the applications that is a must because it a swiss army knife for getting old files to open is Libreoffice/CollaboraOffice.

Libreoffice/CollaboraOffice has must use case with archive documents.
MS Office has must have use cases with software like accountancy software that require MS Office as a dependency to print out reports. Do note the data processing in these cases is not done by MS Office even if it spitting out excel documents.

The other office suite options I cannot find a must use case.

professional is everything from science to industry requiring standards of accuracy, reproducibility and quality.

Libreoffice fits in to what you wrote. To have accuracy of results in lots of cases you need to data mine archived data. Libreoffice is the mining tools not the processing plant. So professional working in science to industry should be using libreoffice form time to time to get information out of archived documents or their results are most likely missing inputs so are possible garbage in/garbage out due to missing data.

Libreoffice used as the tool it made to be by many countries national archives it a great tool. This is different to a general user MS Office replacement. Ease of UI to make new documents from scratch is zero important in the use national archives case, Be safe with virus infected documents and able to open the documents is way more important in the national archive use case..

[wdb974]

Microsoft Office does 1000x the things that LibreOffice does. That's not even remotely a close comparison. I like LO, but I'll be honest... if I don't need the features of Microsoft Office then Google Docs or Office Online work just fine.

Tell me you don't use regex without telling me you don't use regex.