The inefficiency of UTF-8 for storing Asian text is way overstated. This is because people are not making realistic measurements of the number of spaces, punctuation marks, numbers, control characters, and english words that are in real Asian text.
I think all other attempts at byte coding other than UTF-8 can be safely ignored. If you want compression you can use normal byte-based data compression methods like gzip. This will work on both UTF-8 and even on UTF-16 to reduce them to much smaller than any standard encoding scheme can.
There is no need for anything other than "bytes". Nothing requires each "character" to be a "byte". Just use UTF-8.
If you think it is a problem that the characters are different sizes, please realize that UTF-16 uses prefix codes and thus it also has characters different sizes. Even storing 32-bit Unicode would result in the need to treat multiple words as a "character" depending on how you think about prefix accent codes. Also try to get your coding out of the 1960's, modern software thinks about "words" which are varying size.
All this I18N and Unicode stuff would be a no-brainer (every single interface would use UTF-8) if it were not for this illusion by so many idiots that "characters" need to be equal in size. They aren't, it is impossible for them to be so. Deal with it.
The only documentation I have every found for Motif window manager hints is in the file/usr/include/X11/Xm/MwmUtil.h on older CDE machines (I found it on Irix).
The biggest trick is that in each of the bit flags, one of the bits indicates that whether you are turning things on from zero, or toggling them from the default.
In my work on window managers I have found it vital to pay attention to the Motif hints to turn off resize buttons, some programs assumme this will make it impossible to resize their windows. Most of the rest of the stuff can be ignored.
A menu bar at the top of the screen prevents point-to-type from working. IMHO this means it is totally unusable, and I think this is why there is no real interest in it.
Also, without modifying X11 at all, a program could put a menu bar at the top of the screen. There is no reason for all the menu bars to be the *same* window, see. As long as the programs cooperate in only showing their menu bar when they have focus.
Having anything other than the application update the scrollbars is impossible. This would require communication about the current document size and position to the windowing system, this sort of interface will easily exceed in complexity and bugs the interface needed for an application to draw a scrollbar (which is to draw some rectangles and triangles and detect mouse clicks). It would also prevent the use of the scrollbars for anything other than fixed 2-d scrolling. Check Win32 which has such scrollbars and see how many programs really use them (win32 also provides a scrollbar "widget" where the program sets everything, don't count that, only count the "scroll windows").
What X11 needs is to get some of the crap out of the window manager and to vastly simplify the interface. I would like a "the user clicked on the title bar" event, so the application can decide whether to raise the window and what other windows to raise. I would like a "the user tried to resize the window to this size" event so the application can have it's own rules about what sizes are legal. Both of these would eliminate a lot of horrible X11 window manager interface where the application has to teach the window manager how to perform.
It puts the title bars on the left edge of the window, and when you maximize the window it takes ZERO pixels vertically. I think this is what you want.
Nonsense. You encrypt your strong-encrypted result with the governments encrypter. They can look at it, determine it checksums correctly (or whatever to prove you used their algorithim) and they will think it is ok.
Even if there is a shirt in the footage that could be dated to no earlier than 1995...
Thanks a lot for being an ass and completely discrediting anybody who argues your position. You claimed "There is video tape that was recorded in 1991 that shows this". When disproved you go and say "that does not prove the footage was from today". No, of course it doesn't, hey it could be CNN actors for all I know. What it proves that YOU LIED!!!. And that completely removes any desire to believe anything else you said.
Too bad, because I once sympathised with your positions...
The terrorists who bombed the WTC think that their "buildings were burned" by the USA (or by USA's support of Israel). It does not matter whether this is true of not: they feel it exactly the same as the American Colonists did. Trying to differentiate them is not that easy.
I agree that making it impossible to fly is stupid. Instead it could set off emergency beacons so the ATC would know that it might not be controlled by the pilot.
I think ISO-8859-1 is special because it is used much much more than 2-16. For the normal world it *is* ASCII. Therefore I think the best bet is to have programs guess that text that appears to not be UTF-8 is ISO-8859-1.
Good point about the security problem, though. I have described a way in which there are two encodings for the same character. I was mostly concerned about avoiding the possibility of punctuation marks and control characters, but foreign letters are a possibility.
Maybe it would be best to make the API pure UTF-8 (illegal sequences turn into the Unicode error character). My idea would be best done by applications upon recipt of external text. They could also do guessing as to the ISO-8859- state by checking the spelling of words, etc.
MSDOS 2.0 (the one that started on copying Unix/Xenix) was a vast improvement over 1.0. There were absolutely no performance problems. There were compatability problems and they panicked and "fixed" them in bad ways that we are living with today. This compatability has been the main reason a lot of stuff does not match Unix for no reason whatsoever (like backward slashes in the pathnames, useless \r characters in the files, and drive letters).
If VMS was the source of inspiration you would expect to see things resemble VMS more than Unix. But VMS used [n,m] and colons as parts of the filenames, used field-based files for text files, and did not have drive letters. Although NT does not match Unix, it certainly resembles it more closely than VMS.
Dave Cutler and friends were pissed that their baby was massacred by BSD Unix, and saw the chance MicroSoft offered as a chance for revenge. It should be obvious that gratuitious incompatability with Unix serves MicroSoft no competitive purpose (I would expect Linux would be nowhere and MicroSoft in 100% control if they had made it easier to port Unix programs to NT) and is entirely the result of a bunch of bitter old men.
The disclaimer of warrenty is not a GPL invention. I don't think I have ever seen a piece of software (commercial, gpl, public domain, shareware, etc) that did not have this.
If this disclaimer is not legally valid all software development would stop. I don't think even MicroSoft could withstand the lawsuits. The only way software would work is users would have to "steal" it, and the people writing it would have to carefully hide their identities through many layers of encryption so that the users could never find them. I doubt this would be a good thing for software quality!
Even if unbreakable cryptography is possible (which I believe) it has nothing to do with this.
The unbreakable cryptography assummes both parties in communication are interested in keeping the contents of the message secret. This is not true for entertainment.
And we can forget about the rest of the world that doesn't use ISO-8859-1 or UTF-8?
Yes we can forget about them. This is because it will eliminate the need to transmit "which character set this is in". This will be an enormous win for software reliability!
But you've added another case to everything that has to handle UTF-8, and ignored real errors.
No, my whole point is that there is only *ONE* case, which is "handle UTF-8 but if the characters look illegal, display them as single bytes". At no point does a program have to think about whether a document is ISO-8859-1 or UTF-8, it just assummes UTF-8 at all times.
You've just introduced alternate sequences for characters (the whole security problem) in another form.
Only for characters with the high bit set. This is not a security problem. The problem is bad UTF-8 implementations that allow things like '\n' and '/' to be passed through filters by encoding them in larger UTF-8 sequences.
Huh? All the characters are in Unicode
Yes, but not at the MicroSoft code points. The problem is that if this is not a standard, programs are forced to examine the text before displaying it (because there are a huge number of documents out there with these characters, and they are not going to go away!) I also think the standards organizations were stupid for saying these are control characters, if they had assigned them we would not have MicroSoft grabbing them.
Modern IEEE floating point implementations do "range checking" in hardware, in that any calculation that will result in a number too large to represent will result in Inf or NaN. It is true that this represents a huge loss of precision (there are only 2 values for Inf, positive and negative).
The loss of precision (they called it "translational consistency") is XRender's main reason for not using floating point. It is a legitimate argument, but in my experience this is not a problem. A 32-bit floating-point number will not go below the resolution of a 24.8 fixed number until a value of 2^16, or approximately 218 feet on a 300-dpi device. If you are worried about slightly different intermediate results you can round to.8 precision as a last step.
I don't see any efficient way to do matrix transformations with integers. You have to use 64 bit intermediate products and sums. On those processors you are talking about this is a good deal slower than floating point (on modern 64-bit processors they are about the same speed).
I think you can drop support for all ISO character sets other than ISO-8859-1. This will eliminate a lot of problems because when only one set is supported, all code that has to decide which set to use can be deleted!
UTF-8 and ISO-8859-1 can be supported at the same time for all real documents. This is done by treating all illegal UTF-8 sequences as individual 8-bit characters, rather than an "error". This also makes programming easier because there are no "errors" to worry about. For an ISO-8859-1 document to be mis-interpreted under this scheme you would need an 8-bit punctuation mark followed by two accented characters, which is not likely in any real European document.
It is also necessary to treat UTF-8 sequences that code a character in more bytes than necessary as illegal, this is vital for security reasons.
I am also in favor of adding MicroSoft's assignments to 0x80-0x9F to the standard Unicode. These are pretty much standard in the real world now anyways. This will make some more sequences (one MicroSoft symbol followed by one accented character) mismatch under the above scheme, but you are likely to get such documents anyway whether you interpret the MicroSoft characters or not.
This sounds exactly like the library version numbers that have been on every shared library implementation ever made for Unix. I don't think this quite solves things for a few reasons from what I know has broken on Linux/Unix:
1. The developer may think their change is not significant enough to warrent a new version. When they are wrong, you have the same problem as before. Trying to avoid this would result in thousands of versions, and is better solved by statically linking.
2. The different versions still need to talk to underlying layers. Unless something like VMWare is used to run several copies of Windows at the same time, there is a layer where back compatability needs to be worked on. This could be solved by making a simple, well-defined lowest layer, but it is obvious that Windows (and anything in Unix designed after 1980) does not follow such design principles.
One think MicroSoft may be addressing is the obscurity of the Linux library versioning. I have been writing software for this for 8 years and I still have no idea what figures out what version of a library to use, or how it works. It would seem that the filenames are all that are needed to control it, but apparently that is not how it works. Nor do I know how to find out what version of a library a program wants (ldd prints the version it will load, which is not exactly the same).
Although he may support other units, floating point coordinates are useful even if 1.0 is a pixel, and even if anti-aliasing is not supported.
If you draw a diagonal line and the endpoints are floating point, you can get quite a few different diagonal lines (different stairstepping) even if the points all round to the same integer value. This becomes important if you want to draw small shapes. For instance (using OpenGL, which supports floating point) try drawing a thin filled rectangle at various rotations, by calculating the endpoints and passing them as floats, and rounding them to the nearest integer and passing them.
Although they will look similar, the floating point rectangle will have a more uniform thickness. The integer one will often be a trapazoid shape.
The reasons to use this when antialiasing is supported should be obvious.
XRender uses 24.8 fixed-point numbers. They give many arguments why (mostly for tranlational consistency), but I feel they may be mistaken. The main reason is that modern processors are highly optimized to handle fp anyway. Fixed point has annoying problems with the need to range-check everything.
I have found the MicroSoft ones (the original design, not the new one with the blue bottom edge and silly round buttons) to be much superior to those adjustable ones. It is at about the right angle and way sturdier, and they didn't do silly things with the shift keys (and the "caps lock" key is big enough that I can use it for ctrl). I use these keyboards on all the machines that I have.
Other people have said that other companies made ergonomic split keyboards. Of course they did, but the ability to produce one this inexpensively, and to simplify the mechanism to the minimum necessary is pretty innovative.
And as far as I know, the pad-less optical mouse really was invented by MicroSoft. I never heard of such a thing beforehand, everybody else was trying to use accelerometers.
1. Because you dislike the solutions that are being provided and want to show people your alternative solutions. This also explains why Linux refuses to have a "consistent user interface": no matter what that interface is, somebody will feel that it is bad and will provide their own example in the hope it will change the public's mind.
2. Because there is a good deal of satisfaction in knowing that your work is being used by people.
3. General ego gratification of the "I'm smart enough to do this" form. This is the main reason there is very high quality in Open Source software, the other reasons I state do not give any incentive for high quality.
True. The main way MicroSoft will get people to change to OfficeXP is that it will write, by default, files that cannot be read by older versions of Office.
Attempts to write "older Office format" will pop up endless warnings that "some information may be lost" and will then write a slightly broken file (good enough that the user can get his job done, but bad enough that they are discouraged from ever trying that again).
MicroSoft is transparently obvious in this technique. Any intelligent programmer (and there are a few at MicroSoft) would have written an extensible format so old Office programs could skip over the new parts of the document, and there would be no difference in formats. If you wanted to you could force the old format, and you would only get a warning if information would *really* be lost.
Anyway, the way to fight it would be to make a free convert-XP-to-97 program, so people can continue to use their Office97. The work would need to be done to import XP files into other word processors anyway. Such a program would completely stop MicroSoft's forced upgrade path and really mess them up by really making Office97 into their competitor.
If the average person on the street knew that one of the results of the current trends will be that they cannot fast forward or edit out commercials that are on the movies that they rent or buy, the corporations would not stand a chance.
Unfortunately the average person really does not care about rights or free speech, since they don't think it would interfere with anything they do.
We need to communicate the effects in simple concrete examples like "you will not be able to skip commercials" in order to get the public to change their mind or even care. Is anything being done about this?
Actually GTK fixed this (I know, I copied their fix into the newest version of FLTK). They use two different "clipboards", the XA_CLIPBOARD (for Ctrl+C type actions) and XA_SELECTION (for the currently selected text). Unfortunately lots of toolkits (like older fltk...) would paste the XA_SELECTION instead of XA_CLIPBOARD when you typed ctrl+V. Until the other toolkits are fixed you will continue to see this.
Middle-mouse paste is actually a much more efficient form of "drag and drop". It has the advantage that you can rearrange the windows or even open new ones before you "drop" the text. So I really want to see it stay around.
Improved rendering would go a long way to making X better for networking. I find it quite incredible that X requires a round trip to select a color to draw in (but it does, if you want to handle Colormaps in any reasonable way by multiple programs). And there is no way to do fonts on Xlib reasonably without having a program enumerate every single font and then apply it's own logic to choose the one it wants. On a system with thousands of fonts this is a significant startup overhead.
Slashdot Mirror
I think all other attempts at byte coding other than UTF-8 can be safely ignored. If you want compression you can use normal byte-based data compression methods like gzip. This will work on both UTF-8 and even on UTF-16 to reduce them to much smaller than any standard encoding scheme can.
If you think it is a problem that the characters are different sizes, please realize that UTF-16 uses prefix codes and thus it also has characters different sizes. Even storing 32-bit Unicode would result in the need to treat multiple words as a "character" depending on how you think about prefix accent codes. Also try to get your coding out of the 1960's, modern software thinks about "words" which are varying size.
All this I18N and Unicode stuff would be a no-brainer (every single interface would use UTF-8) if it were not for this illusion by so many idiots that "characters" need to be equal in size. They aren't, it is impossible for them to be so. Deal with it.
The biggest trick is that in each of the bit flags, one of the bits indicates that whether you are turning things on from zero, or toggling them from the default.
In my work on window managers I have found it vital to pay attention to the Motif hints to turn off resize buttons, some programs assumme this will make it impossible to resize their windows. Most of the rest of the stuff can be ignored.
Also, without modifying X11 at all, a program could put a menu bar at the top of the screen. There is no reason for all the menu bars to be the *same* window, see. As long as the programs cooperate in only showing their menu bar when they have focus.
Having anything other than the application update the scrollbars is impossible. This would require communication about the current document size and position to the windowing system, this sort of interface will easily exceed in complexity and bugs the interface needed for an application to draw a scrollbar (which is to draw some rectangles and triangles and detect mouse clicks). It would also prevent the use of the scrollbars for anything other than fixed 2-d scrolling. Check Win32 which has such scrollbars and see how many programs really use them (win32 also provides a scrollbar "widget" where the program sets everything, don't count that, only count the "scroll windows").
What X11 needs is to get some of the crap out of the window manager and to vastly simplify the interface. I would like a "the user clicked on the title bar" event, so the application can decide whether to raise the window and what other windows to raise. I would like a "the user tried to resize the window to this size" event so the application can have it's own rules about what sizes are legal. Both of these would eliminate a lot of horrible X11 window manager interface where the application has to teach the window manager how to perform.
It puts the title bars on the left edge of the window, and when you maximize the window it takes ZERO pixels vertically. I think this is what you want.
Nonsense. You encrypt your strong-encrypted result with the governments encrypter. They can look at it, determine it checksums correctly (or whatever to prove you used their algorithim) and they will think it is ok.
Thanks a lot for being an ass and completely discrediting anybody who argues your position. You claimed "There is video tape that was recorded in 1991 that shows this". When disproved you go and say "that does not prove the footage was from today". No, of course it doesn't, hey it could be CNN actors for all I know. What it proves that YOU LIED!!!. And that completely removes any desire to believe anything else you said.
Too bad, because I once sympathised with your positions...
The terrorists who bombed the WTC think that their "buildings were burned" by the USA (or by USA's support of Israel). It does not matter whether this is true of not: they feel it exactly the same as the American Colonists did. Trying to differentiate them is not that easy.
I agree that making it impossible to fly is stupid. Instead it could set off emergency beacons so the ATC would know that it might not be controlled by the pilot.
Good point about the security problem, though. I have described a way in which there are two encodings for the same character. I was mostly concerned about avoiding the possibility of punctuation marks and control characters, but foreign letters are a possibility.
Maybe it would be best to make the API pure UTF-8 (illegal sequences turn into the Unicode error character). My idea would be best done by applications upon recipt of external text. They could also do guessing as to the ISO-8859- state by checking the spelling of words, etc.
MSDOS 2.0 (the one that started on copying Unix/Xenix) was a vast improvement over 1.0. There were absolutely no performance problems. There were compatability problems and they panicked and "fixed" them in bad ways that we are living with today. This compatability has been the main reason a lot of stuff does not match Unix for no reason whatsoever (like backward slashes in the pathnames, useless \r characters in the files, and drive letters).
If VMS was the source of inspiration you would expect to see things resemble VMS more than Unix. But VMS used [n,m] and colons as parts of the filenames, used field-based files for text files, and did not have drive letters. Although NT does not match Unix, it certainly resembles it more closely than VMS.
Dave Cutler and friends were pissed that their baby was massacred by BSD Unix, and saw the chance MicroSoft offered as a chance for revenge. It should be obvious that gratuitious incompatability with Unix serves MicroSoft no competitive purpose (I would expect Linux would be nowhere and MicroSoft in 100% control if they had made it easier to port Unix programs to NT) and is entirely the result of a bunch of bitter old men.
If this disclaimer is not legally valid all software development would stop. I don't think even MicroSoft could withstand the lawsuits. The only way software would work is users would have to "steal" it, and the people writing it would have to carefully hide their identities through many layers of encryption so that the users could never find them. I doubt this would be a good thing for software quality!
Even if unbreakable cryptography is possible (which I believe) it has nothing to do with this.
The unbreakable cryptography assummes both parties in communication are interested in keeping the contents of the message secret. This is not true for entertainment.
Yes we can forget about them. This is because it will eliminate the need to transmit "which character set this is in". This will be an enormous win for software reliability!
But you've added another case to everything that has to handle UTF-8, and ignored real errors.
No, my whole point is that there is only *ONE* case, which is "handle UTF-8 but if the characters look illegal, display them as single bytes". At no point does a program have to think about whether a document is ISO-8859-1 or UTF-8, it just assummes UTF-8 at all times.
You've just introduced alternate sequences for characters (the whole security problem) in another form.
Only for characters with the high bit set. This is not a security problem. The problem is bad UTF-8 implementations that allow things like '\n' and '/' to be passed through filters by encoding them in larger UTF-8 sequences.
Huh? All the characters are in Unicode
Yes, but not at the MicroSoft code points. The problem is that if this is not a standard, programs are forced to examine the text before displaying it (because there are a huge number of documents out there with these characters, and they are not going to go away!) I also think the standards organizations were stupid for saying these are control characters, if they had assigned them we would not have MicroSoft grabbing them.
The loss of precision (they called it "translational consistency") is XRender's main reason for not using floating point. It is a legitimate argument, but in my experience this is not a problem. A 32-bit floating-point number will not go below the resolution of a 24.8 fixed number until a value of 2^16, or approximately 218 feet on a 300-dpi device. If you are worried about slightly different intermediate results you can round to .8 precision as a last step.
I don't see any efficient way to do matrix transformations with integers. You have to use 64 bit intermediate products and sums. On those processors you are talking about this is a good deal slower than floating point (on modern 64-bit processors they are about the same speed).
UTF-8 and ISO-8859-1 can be supported at the same time for all real documents. This is done by treating all illegal UTF-8 sequences as individual 8-bit characters, rather than an "error". This also makes programming easier because there are no "errors" to worry about. For an ISO-8859-1 document to be mis-interpreted under this scheme you would need an 8-bit punctuation mark followed by two accented characters, which is not likely in any real European document.
It is also necessary to treat UTF-8 sequences that code a character in more bytes than necessary as illegal, this is vital for security reasons.
I am also in favor of adding MicroSoft's assignments to 0x80-0x9F to the standard Unicode. These are pretty much standard in the real world now anyways. This will make some more sequences (one MicroSoft symbol followed by one accented character) mismatch under the above scheme, but you are likely to get such documents anyway whether you interpret the MicroSoft characters or not.
1. The developer may think their change is not significant enough to warrent a new version. When they are wrong, you have the same problem as before. Trying to avoid this would result in thousands of versions, and is better solved by statically linking.
2. The different versions still need to talk to underlying layers. Unless something like VMWare is used to run several copies of Windows at the same time, there is a layer where back compatability needs to be worked on. This could be solved by making a simple, well-defined lowest layer, but it is obvious that Windows (and anything in Unix designed after 1980) does not follow such design principles.
One think MicroSoft may be addressing is the obscurity of the Linux library versioning. I have been writing software for this for 8 years and I still have no idea what figures out what version of a library to use, or how it works. It would seem that the filenames are all that are needed to control it, but apparently that is not how it works. Nor do I know how to find out what version of a library a program wants (ldd prints the version it will load, which is not exactly the same).
If you draw a diagonal line and the endpoints are floating point, you can get quite a few different diagonal lines (different stairstepping) even if the points all round to the same integer value. This becomes important if you want to draw small shapes. For instance (using OpenGL, which supports floating point) try drawing a thin filled rectangle at various rotations, by calculating the endpoints and passing them as floats, and rounding them to the nearest integer and passing them.
Although they will look similar, the floating point rectangle will have a more uniform thickness. The integer one will often be a trapazoid shape.
The reasons to use this when antialiasing is supported should be obvious.
XRender uses 24.8 fixed-point numbers. They give many arguments why (mostly for tranlational consistency), but I feel they may be mistaken. The main reason is that modern processors are highly optimized to handle fp anyway. Fixed point has annoying problems with the need to range-check everything.
Other people have said that other companies made ergonomic split keyboards. Of course they did, but the ability to produce one this inexpensively, and to simplify the mechanism to the minimum necessary is pretty innovative.
And as far as I know, the pad-less optical mouse really was invented by MicroSoft. I never heard of such a thing beforehand, everybody else was trying to use accelerometers.
I did not realize that keyboards, mice, interface cards, and game boxes were software. I guess we all make mistakes....
2. Because there is a good deal of satisfaction in knowing that your work is being used by people.
3. General ego gratification of the "I'm smart enough to do this" form. This is the main reason there is very high quality in Open Source software, the other reasons I state do not give any incentive for high quality.
Attempts to write "older Office format" will pop up endless warnings that "some information may be lost" and will then write a slightly broken file (good enough that the user can get his job done, but bad enough that they are discouraged from ever trying that again).
MicroSoft is transparently obvious in this technique. Any intelligent programmer (and there are a few at MicroSoft) would have written an extensible format so old Office programs could skip over the new parts of the document, and there would be no difference in formats. If you wanted to you could force the old format, and you would only get a warning if information would *really* be lost.
Anyway, the way to fight it would be to make a free convert-XP-to-97 program, so people can continue to use their Office97. The work would need to be done to import XP files into other word processors anyway. Such a program would completely stop MicroSoft's forced upgrade path and really mess them up by really making Office97 into their competitor.
Unfortunately the average person really does not care about rights or free speech, since they don't think it would interfere with anything they do.
We need to communicate the effects in simple concrete examples like "you will not be able to skip commercials" in order to get the public to change their mind or even care. Is anything being done about this?
Middle-mouse paste is actually a much more efficient form of "drag and drop". It has the advantage that you can rearrange the windows or even open new ones before you "drop" the text. So I really want to see it stay around.
Improved rendering would go a long way to making X better for networking. I find it quite incredible that X requires a round trip to select a color to draw in (but it does, if you want to handle Colormaps in any reasonable way by multiple programs). And there is no way to do fonts on Xlib reasonably without having a program enumerate every single font and then apply it's own logic to choose the one it wants. On a system with thousands of fonts this is a significant startup overhead.