> I am not sure what you claim about web formats.¶ If you try to print any non-trivial Web page with any of the existing Web browsers[…] For instance, Firefox and Chrome[…]

... why do you think this matters? Like, at all? We're talking about LibreOffice.

> Nothing could be less true for anything that is used on the Web.

This is, uh, crazy. In the first place, PDF is used on the Web, and it's both better suited for print-perfect sources and it's more portable. In the second place, believing that there's some magic inside ODF (or some other office suite's native format) that can't be represented in XML, JSON, or some other plain-text format is delusional.

▲

adrian_b 16 hours ago | parent [-]

If you claim that some text format used on the Web is suitable for storing a document, you should be able to point to some application that demonstrates the use of that text format in a manner that can be used for a document.

If none of the existing Web browsers can render a Web page in a predictable way in all circumstances, that clearly disqualifies all "Web formats". If the most complex programs like the Web browsers cannot always render correctly a Web page, then who can?

> There is nothing in ODF that's inherently unrepresentable in JSON or pure XML.

Since ODF is XML, that is a tautology.

I do not doubt that it is likely that ODF is more complicated than really necessary, and that something better could be designed.

However anyone who criticizes it should define an alternative better format and describe its advantages.

Pointing to some of the existing markup text formats is not this, because those lack a great number of features that are absolutely necessary for any document file format, so they are not comparable at all.

Saying that a markup text format can be suitable as a document format resembles the claim of the Americans that ASCII should be good enough for the speakers of non-English languages.

	▲	cxr 13 hours ago \| parent [-]
		It would be great if you would stop and at least try to understand the argument you find yourself in and what's being claimed/described by the other side, especially in the comments you're choosing to respond to, instead of hallucinating some altogether completely different claims, like whether any two Web browsers consistently render HTML- and CSS-based Web pages in the wild the same—as if that's somehow pertinent. > If none of the existing Web browsers can render a Web page in a predictable way in all circumstances, that clearly disqualifies all "Web formats"[†]. If the most complex programs like the Web browsers cannot always render correctly a Web page, then who can? There is no brilliant observation here. We are not talking about how "the existing Web browsers can render a Web page in a predictable way in all circumstances". The answer to your question literally doesn't matter. We're talking about the choices available to LibreOffice—choices about how to encode documents in a bytestream that can still be processed by apps that don't have explicit support for formats like ODF, and processed by those that do (apps like, you know, LibreOffice) that's (a) done in a way that's still consistent with the way that it (again: LibreOffice) treated the content the first time around, before it wrote it out to disk (b) consistent with the way that other apps that commit to the same standard of interoperability treat that content. Those are the _only_ tests that matter in this conversation. You can imagine all sorts of other tests and cross-examine against them, but no matter what you manage to come up with, they do not matter. It's your insistence on not understanding this that's the problem. The questions—again, the _only_ questions—to answer are: 1. Can LibreOffice encode its documents in such formats and in such a way that it doesn't compromise its ability to have the documents cleanly "round tripping" their way out (of LibreOffice) and back in (to LibreOffice) again—i.e., whether it can use one of these formats as its container (rather than the ZIP-for-XML-&c container that ODF uses). The answer to that question is an unequivocal "yes"—there is literally _nothing_ magical about ODF that can't be captured/encoded using some other scheme for representing data. It's equal parts baffling and maddening that this needs to be stated so, so, so, so, so many times in this discussion. 2. And whether LibreOffice—and any other desktop publishing app that aims to be interoperable—can render those documents "in a [reliably] predictable way in all circumstances". The answer is "yes—assuming it's able to do that now with ODF, and you aren't just putting your thumb on the scale in two dimensions [instead of just the one, as you've been doing throughout this exchange]". Any and all other of these asinine tests and complaints about the deficient behavior of non-LibreOffice apps (like Firefox, or Chrome, or Windows 95's calc.exe…) are all half-thought-out red herrings that have next to no bearing on the topic at hand. Just mindnumbing attempts to move the goalposts. † As I already pointed out in my previous comment, and which you inexplicably ignored, PDF is, in fact, quite good at this—and not even just that; it's so much better suited for what you're kvetching about. > ODF is XML Uh, no. ISO 26300[1], much like the Open Packaging Conventions[2] used for Microsoft's OOXML and XPS, "uses a package file to store the XML content of a document together with its associated binary data, and to optionally compress the XML content. This package is a standard Zip file". Leaving that aside and the monumental difference that that detail makes wrt the claim and its relevance to this situation: There are no provisions within the spec requiring ODF producers make sure to spit out a ZIP bytestream that is carefully constructed so it can be processed by a pipeline that is expected to yield a meaningful result when it's treated as something other than ODF-flavored-XML-inside-ZIP (like application/pdf, image/png, image/svg+xml, or text/html, etc)—i.e. ODF packaging has none of the guarantees that SingleFileZ archives provide. > However anyone who criticizes it should define an alternative better format and describe its advantages. Boy am I done with this thread. 1. <https://www.iso.org/standard/66363.html> 2. <https://en.wikipedia.org/wiki/Open_Packaging_Conventions>