Not to criticise but... (excel->LO)

[David99]

It seems to me that it is a parser development issue to be able to provide the functionality to translate an arbitrary excel spreadsheet/book to a LO sheet/book.

I see lots of energy devoted to marketing LO as an “alternative” to MS Office but I do not see that it will ever be able to compete as anything beyond a rather weak political statement without the ability to correctly translate any excel item to an exactly equivalently functioning LO option. And when excel changes, an auto-update should ask if I want to download the latest translator.

Shouldn’t this be a major priority for the LO community?

[hyogapag]

Not to criticize, but reverse engineering is not a perfect science. It is of public notoriety that Microsoft uses closed format (even when flagged as open like OOXML, which is even not truly implemented by MS itself) to ensure the lock-in of its user base. You can find good literature about open standards, open formats and the likes on the internet. You can also note that Microsoft is a board member of the OASIS, the foundation that defines the formats used in LibreOffice and OpenOffice. For instance, this quote from Microsoft :

Microsoft Corp.
“As an OASIS Foundational Sponsor, Microsoft is pleased to see the approval of ODF 1.2, which Microsoft participated in and supported. This is an important milestone for the ODF format and the ODF community.”
– Doug Mahugh, Senior Standards Professional, Microsoft

So, a better question would be : why the ODFs are so poorly supported in MS Office? Why can’t it provide a good conversion tool from pseudo-OOXML to ODF?

What’s more, TDF (the foundation behind LibreOffice) members are spending a lot of time (and money) improving the OOXML filters that could be used for functionality or usability enhancements. For instance, German and Swiss public administrations are spending money on this, that is, to do the job MS should do.

So yes, there is an interoperability problem between Excel and Calc, but the guilty is the one who closes the gates to prevent its people from leaving. Strange vision of “free market” and “free and undistorted competition” isn’t it?

[cloph]

That translation is what the import and export filters already do. So that kind of stuff does exsist already, and devs are constantly improving interoperability.

As mentioned before, it requires a bit of reverse engineering, and sometimes corner cases are not interpreted correctly/simply not thought of since not encountered in the wild usually. Even the specifications that are available leave room for interpretation sometimes.

So to improve the import/export filters, it is best to provide samples to the developers by filing a bug (https://www.libreoffice.org/get-help/bug/) and attaching a small sample document (the smaller the better) that is not imported correctly.

There are two basic types of bugs:

• it doesn’t work because there is no equivalent in LibreOffice, i.e. you cannot do the same in LibreOffice, thus the import filter cannot do anything, first LibreOffice must be extended to cover the same features
• you could do the same in LibreOffice, but the import doesn’t carry it over properly.

The second one can obviously be fixed much faster.

[David99]

hyogapag, thanks for the comment.

I am not sure relying on the deep/ODF representation is the appropriate strategy for creating interchangeability with excel, and similar closed products. Why blame MS for doing what MS does, and why rely on them? The goal is not to “make” them conform to ODF standards and to “make good” on their promises. The goal is to make the two products interchangeable.

Each spreadsheet has a textual representation in each cell and the VBA behind each sheet. A parser that built an AST of the excel representation and then compiled it into the appropriate LO pieces (source-to-source) would be one way for LO to control its fate and not depend on MS. There’s either " ‘they’ won’t let us" or there’s “we’ll do it anyway.” The “anyway” approach would be useful to the community of users and would, I think, be a marketing point to what I imagine to be many large MS users who won’t switch because they have big knowledge and economic investments in excel and don’t want the cost and risk of re-tooling by hand.

[mariosv]

It’s a good premise to know what one is talking about.

[David99]

“premise” → “policy”.

[hyogapag]

Thank you David for this answer.
I agree when you say that “the goal is to make the two products interchangeable”. Then, my purpose was not to blame MS for poor interoperability but to show those who blame LO for this were wrong.

It’s not as simple as building an AST since LO members are trying to climb it by night (and the format is buggy, see for instance how MS Office finds out the number of the week). The anyway approach, as you call it, has always been the one used by OOo and LO developers. If this is vital in the short term to be able to open files from MS, I don’t think it is enough in the long run. But here we move from your question to a political one, so let’s stop there.

Last point : Microsoft is saying it will end support for VBA for years, and even if it seems it still exists in Office 2013, as often you can see compatibility from a version to the next (so just imagine from, let’s say, MSO 97 to 2013…) is everything but perfect.

[David99]

hyogapag,
Thanks for the info on the LO engineering approach.

I am not a fan or basher of either MS or LO. I simply make the observation that it is against MS business interests to do anything to facilitate interoperability. They are pretty astute in that regard and unlikely to do anything but slow roll, including killing VBA, which would hurt them with a large base of major legacy app users, such as US Gov.

That means to me that if LO wishes to provide a realistic alternative to MS i.e., one that would be adopted by major users with significant investments in excel or by organizations who must work with such entities, it is likely that the short term solution you refer to will have to be the mid-/long- term solution. That is, technically down and dirty.

Once that solution is generally available, supported, and bi-directional, I suspect power users would adopt LO and similar if it meant that they rely on LO-produced pseudo-OOXML to ODF tools to which you refer. My bet is once that is achieved, MS would (have to) play.

[hyogapag]

So we mainly agree. Just note that even MSO produce pseudo-OOXML : the one it implements is not the one approved by the ISO (though the name is the same…)

[David99]

Yes, we agree. Seems wrong to me to place a dependency on MS for any straight-line business strategy, including production of standards-based representations of OOXML for MS products. It is against MS interests to conform and, so far, they are winning the battle.