Things are getting a little confused without the proper context, I've re-inserted the context.
OK, but a developer can't "fix" what is not specified. msoffice formats are not specified so that they can be implemented. So that's not something a oo developer would be able to fix by himself.
Sometimes code's behavior is the documentation.
Yes, that is the definition of undocumented software, when the only documentation is its observed behaviour.
I should have used quotes around "documentation" but the point is that programmers frequently fix things that are observed anomalies and not failures to meet a specification, contrary to the "can't "fix" what is not specified" notion. Or if you want to get overly "corporate" the "specification" in such a case is the "bug report" not a "design document".
Being a government, they can ditch it completely if it makes sense for them. Where I live, there is a law that requires all gov data to be available in open formats, so it's even easier to comply that way.
Successfully reading and interpreting a file is one thing. Rendering its contents is another. The Office Open XML format, .docx, is open: ISO/IEC 29500.
No, it's not open. First, OOXML is a sanctioned standard, but it's not open. For example, there is no open reference implementation, only proprietary binaries.
Also, and most importantly, msoffice does not implement OOXML completely. Its small differences are what make compatibility a moving target.
My point is that a standard has more to do with successfully reading, interpreting and writing a file than defining absolute visual layout; and that it is common to have an adhoc heuristic in an implementation to better meet a users intention. For example "is the user trying to define a page break with all those CR/LF's? If I'm near a natural page break maybe I'll ignore a CR/LF or two that goes past the break." Basically it is not uncommon for a specification to leave things at that level implementation dependent. Yes, it would be nice to have a reference implementation to demonstrate such heuristics. But the lack of a reference is no reason not to implement such observed behavior, an observed heuristic. Especially for something related to very basic functionality such as pagination.
So, the second to best solution is to just acknowledge msoffice is not compatible with other software, so either ditch it completely, or keep it completely. Half assed efforts are doomed to fail from the start.
That is a fine strategy if you are not trying to get people to convert to your app. Blowing off a valid user expectation hurts adoption.
But these guys were not trying to get people to convert to anything. Their job was to provide office productivity software for the city personnel.
I'm referring to the FOSS developers. As for the guys providing the FOSS software to users, well that takes us back to my original post: "The town should have had an easy way to report their difficulties to the FOSS developers and the FOSS developers should have been responsive. Such reporting and response is necessary for FOSS adoption."
The hybrid solution was a bad idea, they failed because they tried something that is known not to work. OpenOffice/LibreOffice guys can work on interoperability as much as they want. That doesn't automatically make it viable as a solution for a big organization.
My point is that given FOSS a lack of implemented spreadsheet macros and pagination differences should not have torpedoed a project. These were addressable issues. Perhaps things to be implemented by the developers on their own due to the obvious goal of promoting adoption of their product, perhaps a donation from the town to the developers might have been the most cost effective thing for the town to do, or hiring a contractor to implement and submit the changes, etc. It is FOSS after all, its not supposed to be necessary to take things as they are and live with it.