lol'd hard.
"I think you will all appreciate this person's commenting style"
71–80 of 91 posts
Re: "I think you will all appreciate this person's commenting style"
#72Earlier quoted context omitted.
It's still worse than ODT (which itself isn't exactly pretty), for no good reason. That's sad.
ODT is also XML-based, to Docx's problems compared to ODT can't be blamed on XML.
I never said it has anything to do with XML. OOXML is extremely complex for little reason. Even though it is also quite complex, ODT is much, much simpler.
Re: "I think you will all appreciate this person's commenting style"
#73Earlier quoted context omitted.
ODT is also XML-based, to Docx's problems compared to ODT can't be blamed on XML.
I never said it has anything to do with XML. OOXML is extremely complex for little reason. Even though it is also quite complex, ODT is much, much simpler.
I'm not disagreeing with you; but the context is mostly about the use of XML.
Re: "I think you will all appreciate this person's commenting style"
#74Earlier quoted context omitted.
The deicision was a big step forward; however, moving off XML to an equivalent but less verbose (in number of meaningless bytes) format wouldn't hurt. All else being equal, it would be less electricity wasted on reading and sending things over the wire, and also more human-readable format. See also: SEXP vs. XML. This argument applies the more, the bigger markup-to-data ratio is.
its zipped; nothing is wasted.
But to read it you have to first unzip it, and then parse all that fluff.
Re: "I think you will all appreciate this person's commenting style"
#75Earlier quoted context omitted.
So just out of curiosity, why doesn't Adobe embark on those two projects? We're entering a new era of desktop software, surely that should be a catalyst for redesigning both from scratch?
And cut all backwards compatibility in doing so? Risky move indeed. Not so sure the benefits would make up for it.
No, it wouldn't cut backwards compatibility at all. They have made plenty of additions to the format over the years, and they give you the option of saving to be compatible with previous versions. They could just keep doing that.
Re: "I think you will all appreciate this person's commenting style"
#76Earlier quoted context omitted.
Simple version (in pseudo-C): struct Atom { uint32 length; uchar type[4]; uchar data[length - 8]; }; The file is a single atom that has other atoms (and random parameters and such) in its data field. You end up with a big tree of atoms which can be parsed as needed. Super simple format -- like the parent, I use atom trees all the time for serialization.
Sounds almost like the IFF format, which was used for just about everything on the Amiga, and then later (with minor changes) as the basis to microsoft's RIFF, underlying wave files, .AVI and a lot of other formats. IFF is: struct chunk { char tag[4]; int32 length; byte data[length]; byte padding[(2-(length%1))%2]; } The padding is to two bytes; the tag uses ascii exclusively and no space (33-127), although every for…
JPEG uses a variation of IFF, which puts an additional checksum at the end of each chunk. A nice extension for detecting errors.
Re: "I think you will all appreciate this person's commenting style"
#77Earlier quoted context omitted.
Is it not strange to call it an Atom? Atom is etymologically indivisible, when here we can have arbitrary structure.
Atoms can be linked together to form an arbitrary structure. After all, a tree is a graph.
But once they are linked we call the linkage a molecule or compound.
Re: "I think you will all appreciate this person's commenting style"
#78Earlier quoted context omitted.
No? It seems to be working up well enough so far for e.g. ODT, or indeed the web. A file format that might need to be read in 20 years seems like one of the few cases where the super-verbose XML style is actually appropriate.
I'm all for super-verbosity in useful information and flexible structure, but XML is also super-verbose in terms of redundant markup. Compression helps a bit, but it still costs processing power for no real reason. See the good ol' S-expressions vs. XML discussion, recently reincarnated as JSON vs. XML.
JSON is not where one gos to flee verbosity. It is almost identical to XML, save punctuation.
Re: "I think you will all appreciate this person's commenting style"
#79Re: "I think you will all appreciate this person's commenting style"
#80Earlier quoted context omitted.
And cut all backwards compatibility in doing so? Risky move indeed. Not so sure the benefits would make up for it.
No, it wouldn't cut backwards compatibility at all. They have made plenty of additions to the format over the years, and they give you the option of saving to be compatible with previous versions. They could just keep doing that.
> They could just keep doing that
Then it wouldn't be a new, "clean" format. Then it'd be the old format with additions. Which it already is. Your post makes no sense to me.