Once again, OpenOffice is doing the wrong thing. Other ODF programs act like Excel. OpenOffice must be fixed, and the best fix is to copy whatever Excel does. It should not be hard to type these things into Excel and find out.
This is still not an excuse for Microsoft to make their files incompatible with everybody else, when (due to their controlling the market) they are by definition the standard implementation.
OpenOffice.org operating differently compared to other ODF implementations has nothing to do with Microsoft's implementation of ODF itself - it is an example to illustrate the ambiguity of ODF 1.1 formulas.
The problem is that it actually is an example that the ambiguity does not exist. This is quite clearly a bug in OpenOffice, it is quite obvious that the vast majority of programs, including Microsoft's own, do the expected thing. There are only TWO results he or anybody found, in searching two dozen programs: the way Microsoft does it, and a BUG in ONE program, OpenOffice!
Normally you would think Microsoft would be quite happy to point out that OpenOffice has a bug. But not when it conflicts with these insane shenanigans. Oh no, we are going to pretend and lie and obfuscate and say that this bug is proof that we have to write our files in an incompatable manner! Yep, that's the ticket. What a bunch of assholes, sorry, they are not proving to want any symphathy at all with this stunt.
I can't see any logical reason for a string to turn into zero.
Now it could turn into an error, or could turn into a boolean (where an empty string is false and a non-empty one is true). This would then be a plausable (though not recommended) incompatible implementation.
But the current OpenOffice behavior is a bug and not an excuse for Microsoft to be incompatible.
I am saying EXACTLY the same thing you are. In the example everybody quotes (really I would think Microsoft with all their resources could have located more than one or two examples!) of 1+"2"=1, this is a BUG in Open Office. Other ODF programs and Excel implement it the same way. This is EXACTLY what you are specifying, this is non-standard and broken behavior. So of course you write the obvious standard behavior.
Except if you are Microsoft and are fishing desperately for an excuse to claim you are obeying some standard but absolutly require that import/export not work. Then this bug can be uses as an indication that you must make EVERY SINGLE FORMULA (not just the ones with the bug) incompatible!
This is mind boggling. And that people like you can excuse it is absolutely revolting. I did not believe until now that there were such sick people in the world.
No, Microsoft has done exactly what they want and they are really truly being evil in this case. Other things they do are incompetent, and other things are people just imagining evil when in fact they did not ever consider such implications. But this is so blatenly obvious that I do not see how anybody (with some programming experience) other than paid shills can see anything other than pure malice in their intentions.
OOo has a BUG. Please look up "bug" if you are unsure of what it means. By your definition every single minor version of Excel and/or OO should use a different namespace, because I'm sure there is some formula that makes a different answer in each of them. This is normally called "bug fixing" but not when some twisted individual at Microsoft decides they need a bogus excuse to be incompatible.
Obviously if Microsoft continues with this, everybody reading/writing ODF will just alter their programs to strip this namespace and add it when storing, which is what you are proposing. That is what Microsoft wants, they have changed the open standard into something they have embraced and will extinguish, and they will continue to change it, every single release, so as to guarantee that ODF files are useless.
As you and the MSDN asshat have pointed out, there is a bug in OpenOffice. Other ODF programs interpret the sample the same as Excel. Open Office has a BUG! This does not mean the formulas are undefined and is not an excuse to make every single other formula incompatible!
As you suggest, it is certainly easy to strip the msoxl prefix, and add it when storing all the formulas. And you can use the excuse that you need to recognize back-compatibility with OpenOffice, just like mr microsoft does.
However how about this new solution: admit there is a bug in OpenOffice and fix the damn thing. NOBODY cares about back-compatibility with this bug, they want Excel compatibility. Saying otherwise is just denying the truth and makes you open to Microsoft's shenanigans.
Microsoft wants everybody running around in circles. As soon as everybody has altered their software to only write this new prefix, they are going to locate another bug in some ODF-reading piece of software and use it as an excuse to make *another* prefix. And another, and another, forever.
No, this joker searched until he found a bug in OpenOffice and then claimed that the different behavior meant the formulas were "undefined". That is nonsense, there is simply a bug in OpenOffice. He even points out that Excel and Symphony act the same, but for some mysterious reason his convoluted logic does not say this means Symphony and Excel should share the same namespace, but that they should be different, while the two programs he just demonstrated are different should use the same space! Of course logic would not allow him to arrive at his pre-planned bogus conclusion.
Microsoft is saying "The Oxford and American English Dictionaries disagree on the definition of a few words and don't define every possible word that will ever be invented. Therefore will write all our text in Klingon".
That is the truth as much as it hurts your world view.
Standards are normally written with the assumption that people interpreting them have a desire to interoperate. This was of course a mistake when you have a hostile party like Microsoft.
It is trivial to comply to the letter with lots of standards yet make an implementation that does not interoperate at all. Maybe this should be some new variation on the obfuscated-C style contests. Pick some computer standard and write some software that does not work with it yet technically obeys every part of the standard. More modern ones that are designed for expansion such as ODF make this pretty easy, older communication standards would be more fun I think.
By that token, then, OO's poor support of Microsoft formats is also OO's fault.
Yes of course that's OO's fault. I'm thinking you are making a statement that you believe people will disagree with? Sorry but when you astroturf you have to think a little or you sound like an idiot.
WOW! One program disagrees about ONE formula (the 1+2 example, where the 2 is a text field) and several other programs agree. And you think this is the same as a program disagreeing about EVERY SINGLE FORMULA!!!!
Microsoft is trolling for excuses. I am absolutely flabbergasted at their perversion that they would do this and pay people like you to write this crap.
Again it is so blatently obvious how to read/write the formulas. They were copied from Microsoft's OWN software!
You had better realize that there really are some intelligent people here who can see through your transparent arguments.
It is BLATENTLY OBVIOUS how to write an ODF formula. It is about 100 times easier than trying thousands of formulas in order to find some bugs in two different ODF readers, which is what Microsoft apparently thinks is a good use of their engineer's time.
You are missing one ENORMOUS detail: the formulas ARE defined, they are defined by Open Office and every other ODF user as "do what Excel does" (to be pendantic they are "do what Excel does when set to a locale that uses commas as the decimal point").
Microsoft is in the BEST position to do this, better than anybody else including OpenOffice! I believe they have the most accurate implementation of Excel. Or are you going to claim otherwise?
Complicated wording and excuses from Mr Dave Mahugh just show that he is a truly sick and moralless individual. It is blatently obvious how to do the formulas. He is purposly writing stuff he knows as absolute bullshit in order to satisfy his paymasters. A bug in OpenOffice does not mean "don't write any ODF formulas" which is basically what he is claiming. WRONG.
It sounds like the basic cause is something attempting to translate a string into "unicode" before using it.
For some reason, normally intelligent programmers turn into complete morons when presented with UTF-8 and other Unicode encodings. They become convinced that it is somehow physically impossible to do anything to these strings without first finding all the "characters" (actually Unicode code points, which are not "characters") and will write pages and pages of elaborate and bug-prone code to do this and "count characters". This code is COMPLICATED and there is the basic fact that the mapping is often not 1:1 and even when it is different implementations vary and thus don't invert correctly. This causes bugs, nasty ones like you can see right. here.
In fact it would be trivial to just treat it as a string of bytes that happens to maybe represent some text. The ONLY time you need "characters" is when you are rendering the string into an image that humans will look at, and if you want to do semantic analysis such as grammar checking. It is not needed if you are looking for the period that starts the extension or trying to find a number.
What is really sad and mysterious is that this disease only seems to be triggered by UTF-8. Nobody worries about finding the boundaries between "words". Nobody seems to worry about UTF-16 surrogate pairs, and nobody was really concerned with older Japanese multi-byte encodings.
This is NOT Microsoft-specific so don't feel complacent. Microsoft's moronic decision to name files with UTF-16 is really bad, but witness open source Python 3.0 which has decided that all strings will have to be converted to "unicode" (acutally UTF-16 or UTF-32 depending on the platform) before anything is done to them. Python is heavily used to parse HTML and URLs and I expect a huge mess from this stupid idea.
I'm sure there will be a few responses claiming some magical property of "characters" so that you can't do anything about it. PLEASE, try some thought experiments. Try substituting "words" in your example, it will either be stupid, or you will realize that that only a tiny portion of software needs it. Go and write some code where you leave the strings in UTF-8 and maybe you will learn.
OS/X option is "hide *known* extensions". A file called x.foo (where.foo is an unrecognized extension) will show as x.foo. Also they seem to consider the first dot to be the start of the extension (rather than the last dot which is what Windows and I think most Linux software does). Therefore ".doc.pdf" is an unrecognized extension and shows up.
I still don't see any reason for this and turn off this option on OS/X.
Actually it's not running libmagic. The slowness is due to the attempt to make thumbnail versions of the files. Microsoft started doing this as well, with the same problems (though I think Nautilus is much worse).
Which makes it even stranger that Microsoft keeps hiding extensions. Obviously some people there understand how to do this in a safe way.
I also think the OS/X solution of warning if you actually try to change the extension is a good idea. Combined with the Vista selection of only the name it would be the best one.
Metadata/etc appeals to academics but it is pretty obvious that it is not what real users prefer or understand.
I can tell you that OS9 behavior like that is a pain in the ass. Widnows (and Linux) are a lot easier in this regard.
When I have a.jpg I want to open it in my favorite.jpg viewer, or pick the program to open it with from a popup menu. I don't want to open it in whatever the person who touched it up painting program.
I am at a loss to explain why hiding the extensions is considered user friendly by Microsoft. Talking to novice computer users and helping them out, it is pretty obvious that they know what the extensions are and what they mean. They even know they can "fix" a file to open correctly by changing the extension. They are also visible in all the file open/save dialogs and in the recent-files list in applications.
Supposedly because the execute bit will not get set by the program that downloaded the file.
However I very much suspect that if Windows had done this, the downloading programs would have helpfully set the execute bit. It certainly would be a pain if the user had to run some other program to fix it. So this would serve no security purpose.
The exectute bit is really just an artifact of early Unix systems. To make the shell fast it needed a list of all the programs that would work in memory. People put lots of non-executable files in the path so listing all files would make too big of a list (memory was really small back then). Reading the disk was slow so opening each file was out of the question. The executable bit was the fastest way to throw away all the non-executables so the in-memory list could be made as quickly and as compactly as possible.
Turning this historical artifact into a security feature is somewhat bogus. I suppose it is turning into a security feature (it's being used to fix the.desktop vulnerability and apparently effectively) but I think it is an accident and not a real carefully thought-out feature.
Actually it is easier to recognize a small 3-letter combo. Try it sometime. Also extremely helpful if you want to describe what to recognize in a text or voice message.
Slashdot Mirror
Once again, OpenOffice is doing the wrong thing. Other ODF programs act like Excel. OpenOffice must be fixed, and the best fix is to copy whatever Excel does. It should not be hard to type these things into Excel and find out.
This is still not an excuse for Microsoft to make their files incompatible with everybody else, when (due to their controlling the market) they are by definition the standard implementation.
OpenOffice.org operating differently compared to other ODF implementations has nothing to do with Microsoft's implementation of ODF itself - it is an example to illustrate the ambiguity of ODF 1.1 formulas.
The problem is that it actually is an example that the ambiguity does not exist. This is quite clearly a bug in OpenOffice, it is quite obvious that the vast majority of programs, including Microsoft's own, do the expected thing. There are only TWO results he or anybody found, in searching two dozen programs: the way Microsoft does it, and a BUG in ONE program, OpenOffice!
Normally you would think Microsoft would be quite happy to point out that OpenOffice has a bug. But not when it conflicts with these insane shenanigans. Oh no, we are going to pretend and lie and obfuscate and say that this bug is proof that we have to write our files in an incompatable manner! Yep, that's the ticket. What a bunch of assholes, sorry, they are not proving to want any symphathy at all with this stunt.
I can't see any logical reason for a string to turn into zero.
Now it could turn into an error, or could turn into a boolean (where an empty string is false and a non-empty one is true). This would then be a plausable (though not recommended) incompatible implementation.
But the current OpenOffice behavior is a bug and not an excuse for Microsoft to be incompatible.
Can you please explain your convoluted reasoning.
I am saying EXACTLY the same thing you are. In the example everybody quotes (really I would think Microsoft with all their resources could have located more than one or two examples!) of 1+"2"=1, this is a BUG in Open Office. Other ODF programs and Excel implement it the same way. This is EXACTLY what you are specifying, this is non-standard and broken behavior. So of course you write the obvious standard behavior.
Except if you are Microsoft and are fishing desperately for an excuse to claim you are obeying some standard but absolutly require that import/export not work. Then this bug can be uses as an indication that you must make EVERY SINGLE FORMULA (not just the ones with the bug) incompatible!
This is mind boggling. And that people like you can excuse it is absolutely revolting. I did not believe until now that there were such sick people in the world.
No, Microsoft has done exactly what they want and they are really truly being evil in this case. Other things they do are incompetent, and other things are people just imagining evil when in fact they did not ever consider such implications. But this is so blatenly obvious that I do not see how anybody (with some programming experience) other than paid shills can see anything other than pure malice in their intentions.
OOo has a BUG. Please look up "bug" if you are unsure of what it means. By your definition every single minor version of Excel and/or OO should use a different namespace, because I'm sure there is some formula that makes a different answer in each of them. This is normally called "bug fixing" but not when some twisted individual at Microsoft decides they need a bogus excuse to be incompatible.
Obviously if Microsoft continues with this, everybody reading/writing ODF will just alter their programs to strip this namespace and add it when storing, which is what you are proposing. That is what Microsoft wants, they have changed the open standard into something they have embraced and will extinguish, and they will continue to change it, every single release, so as to guarantee that ODF files are useless.
As you and the MSDN asshat have pointed out, there is a bug in OpenOffice. Other ODF programs interpret the sample the same as Excel. Open Office has a BUG! This does not mean the formulas are undefined and is not an excuse to make every single other formula incompatible!
As you suggest, it is certainly easy to strip the msoxl prefix, and add it when storing all the formulas. And you can use the excuse that you need to recognize back-compatibility with OpenOffice, just like mr microsoft does.
However how about this new solution: admit there is a bug in OpenOffice and fix the damn thing. NOBODY cares about back-compatibility with this bug, they want Excel compatibility. Saying otherwise is just denying the truth and makes you open to Microsoft's shenanigans.
Microsoft wants everybody running around in circles. As soon as everybody has altered their software to only write this new prefix, they are going to locate another bug in some ODF-reading piece of software and use it as an excuse to make *another* prefix. And another, and another, forever.
No, this joker searched until he found a bug in OpenOffice and then claimed that the different behavior meant the formulas were "undefined". That is nonsense, there is simply a bug in OpenOffice. He even points out that Excel and Symphony act the same, but for some mysterious reason his convoluted logic does not say this means Symphony and Excel should share the same namespace, but that they should be different, while the two programs he just demonstrated are different should use the same space! Of course logic would not allow him to arrive at his pre-planned bogus conclusion.
Face the facts.
Microsoft is saying "The Oxford and American English Dictionaries disagree on the definition of a few words and don't define every possible word that will ever be invented. Therefore will write all our text in Klingon".
That is the truth as much as it hurts your world view.
What makes you think those copies of Office were paid for? He was probably trying to obey the law.
Standards are normally written with the assumption that people interpreting them have a desire to interoperate. This was of course a mistake when you have a hostile party like Microsoft.
It is trivial to comply to the letter with lots of standards yet make an implementation that does not interoperate at all. Maybe this should be some new variation on the obfuscated-C style contests. Pick some computer standard and write some software that does not work with it yet technically obeys every part of the standard. More modern ones that are designed for expansion such as ODF make this pretty easy, older communication standards would be more fun I think.
By that token, then, OO's poor support of Microsoft formats is also OO's fault.
Yes of course that's OO's fault. I'm thinking you are making a statement that you believe people will disagree with? Sorry but when you astroturf you have to think a little or you sound like an idiot.
So, it's lazier to load up & store something you don't recognize, than to ignore it?
Yes it is.
I take it you are not a software engineer if you would ask such a stupid question.
WOW! One program disagrees about ONE formula (the 1+2 example, where the 2 is a text field) and several other programs agree. And you think this is the same as a program disagreeing about EVERY SINGLE FORMULA!!!!
Microsoft is trolling for excuses. I am absolutely flabbergasted at their perversion that they would do this and pay people like you to write this crap.
Again it is so blatently obvious how to read/write the formulas. They were copied from Microsoft's OWN software!
You had better realize that there really are some intelligent people here who can see through your transparent arguments.
It is BLATENTLY OBVIOUS how to write an ODF formula. It is about 100 times easier than trying thousands of formulas in order to find some bugs in two different ODF readers, which is what Microsoft apparently thinks is a good use of their engineer's time.
You are missing one ENORMOUS detail: the formulas ARE defined, they are defined by Open Office and every other ODF user as "do what Excel does" (to be pendantic they are "do what Excel does when set to a locale that uses commas as the decimal point").
Microsoft is in the BEST position to do this, better than anybody else including OpenOffice! I believe they have the most accurate implementation of Excel. Or are you going to claim otherwise?
Complicated wording and excuses from Mr Dave Mahugh just show that he is a truly sick and moralless individual. It is blatently obvious how to do the formulas. He is purposly writing stuff he knows as absolute bullshit in order to satisfy his paymasters. A bug in OpenOffice does not mean "don't write any ODF formulas" which is basically what he is claiming. WRONG.
It sounds like the basic cause is something attempting to translate a string into "unicode" before using it.
For some reason, normally intelligent programmers turn into complete morons when presented with UTF-8 and other Unicode encodings. They become convinced that it is somehow physically impossible to do anything to these strings without first finding all the "characters" (actually Unicode code points, which are not "characters") and will write pages and pages of elaborate and bug-prone code to do this and "count characters". This code is COMPLICATED and there is the basic fact that the mapping is often not 1:1 and even when it is different implementations vary and thus don't invert correctly. This causes bugs, nasty ones like you can see right. here.
In fact it would be trivial to just treat it as a string of bytes that happens to maybe represent some text. The ONLY time you need "characters" is when you are rendering the string into an image that humans will look at, and if you want to do semantic analysis such as grammar checking. It is not needed if you are looking for the period that starts the extension or trying to find a number.
What is really sad and mysterious is that this disease only seems to be triggered by UTF-8. Nobody worries about finding the boundaries between "words". Nobody seems to worry about UTF-16 surrogate pairs, and nobody was really concerned with older Japanese multi-byte encodings.
This is NOT Microsoft-specific so don't feel complacent. Microsoft's moronic decision to name files with UTF-16 is really bad, but witness open source Python 3.0 which has decided that all strings will have to be converted to "unicode" (acutally UTF-16 or UTF-32 depending on the platform) before anything is done to them. Python is heavily used to parse HTML and URLs and I expect a huge mess from this stupid idea.
I'm sure there will be a few responses claiming some magical property of "characters" so that you can't do anything about it. PLEASE, try some thought experiments. Try substituting "words" in your example, it will either be stupid, or you will realize that that only a tiny portion of software needs it. Go and write some code where you leave the strings in UTF-8 and maybe you will learn.
And replace the wchar_t Qt strings with stl::string!
Both you and a previous poster have pretty much said exactly this:
1. The GPL is useless because I can't use the code for my projects.
2. But dual licensing is useless because everybody can use the GPL version!
Do you realize how stupid you sound?
OS/X option is "hide *known* extensions". A file called x.foo (where .foo is an unrecognized extension) will show as x.foo. Also they seem to consider the first dot to be the start of the extension (rather than the last dot which is what Windows and I think most Linux software does). Therefore ".doc.pdf" is an unrecognized extension and shows up.
I still don't see any reason for this and turn off this option on OS/X.
Actually it's not running libmagic. The slowness is due to the attempt to make thumbnail versions of the files. Microsoft started doing this as well, with the same problems (though I think Nautilus is much worse).
Which makes it even stranger that Microsoft keeps hiding extensions. Obviously some people there understand how to do this in a safe way.
I also think the OS/X solution of warning if you actually try to change the extension is a good idea. Combined with the Vista selection of only the name it would be the best one.
Metadata/etc appeals to academics but it is pretty obvious that it is not what real users prefer or understand.
I can tell you that OS9 behavior like that is a pain in the ass. Widnows (and Linux) are a lot easier in this regard.
When I have a .jpg I want to open it in my favorite .jpg viewer, or pick the program to open it with from a popup menu. I don't want to open it in whatever the person who touched it up painting program.
I am at a loss to explain why hiding the extensions is considered user friendly by Microsoft. Talking to novice computer users and helping them out, it is pretty obvious that they know what the extensions are and what they mean. They even know they can "fix" a file to open correctly by changing the extension. They are also visible in all the file open/save dialogs and in the recent-files list in applications.
iWork is $39.99 from the Apple website if you are adding it to a machine. I know because I just decided to not bother getting it with a new machine.
However I think there are equivent discounts on home-Word/etc when you buy from Dell, etc. I thought it was sometimes thrown in for free?
Supposedly because the execute bit will not get set by the program that downloaded the file.
However I very much suspect that if Windows had done this, the downloading programs would have helpfully set the execute bit. It certainly would be a pain if the user had to run some other program to fix it. So this would serve no security purpose.
The exectute bit is really just an artifact of early Unix systems. To make the shell fast it needed a list of all the programs that would work in memory. People put lots of non-executable files in the path so listing all files would make too big of a list (memory was really small back then). Reading the disk was slow so opening each file was out of the question. The executable bit was the fastest way to throw away all the non-executables so the in-memory list could be made as quickly and as compactly as possible.
Turning this historical artifact into a security feature is somewhat bogus. I suppose it is turning into a security feature (it's being used to fix the .desktop vulnerability and apparently effectively) but I think it is an accident and not a real carefully thought-out feature.
Actually it is easier to recognize a small 3-letter combo. Try it sometime. Also extremely helpful if you want to describe what to recognize in a text or voice message.