I guess that's why the two most important suppliers of OLED panels for PC monitors (LG and Samsung) are rearranging their subpixel to use LCD-like RGB stripes:
Thanks for your insights. I did change my mind about the need for a BOM (though not about the need to be able to parse/skip it if present).
In a future where everything defaults to UTF-8 it makes sense. This is probably easier to envision in an English-only context where the jump from 7-bit ASCII to UTF-8 is cleaner.
Where I come from, UTF-8 is not always supported. Without a header (or "BOM", though we don't like the name) you don't know in what encoding a text file was meant to be (re-)saved as when it was created. My example of an empty file was meant to illustrate that. But leaning on the Utopian side, I too shall put more energy towards all apps supporting UTF-8 :)
Makes sense, thank you. The observation about false positives for UTF-8 tending to zero helps understand. So I will vote for UTF-8 without BOM from now on (while encouraging parsers to deal with it, if present).
In a pure UTF-8 world we would not need it, sure. I get that point. But what do you want to do with 40+ years worth of text files that came after 7-bit ASCII, where they may coexist with UTF-8? If we want to preserve our past, the practical solution is that the OS or app has a default character set for 8-bit text encoding, in addition to supporting (and using as a default) UTF-8.
I also agree that "BOM" is the wrong name for an UTF-8... BOM. Byte order is not the issue. But still, it's a header that says that the file, even if empty, is UTF-8. Detecting an 8-bit legacy character set is much more difficult that recognizing (skipping) a BOM.
Even the Amiga with its 8-bit text encoding was 40 years ago. Are you saying that for some radical reason modern apps on any platform should refuse to process a BOM? Parsing (skipping) a simple BOM header isn't the same as becoming fully Unicode-aware. I did not invent the BOM for UTF-8, it's there in the wild. We better be able to read it, or else we will have this religious debate (and technical issues porting and parsing texts across platforms) for the next 40 years.
I like your answer, and the others too, but I suspect I have an even worse problem than running Windows: I am an Amiga user :D
The Amiga always used all 8 bits (ISO-8859-1 by default), so detecting UTF-8 without a BOM is not so easy, especially when you start with an empty file, or in some scenario like the other one I mentioned.
And it's not that Macs and PCs don't have 8-bit legacy or coexistence needs. What you seem to be saying is that compatibility with 7-bit ASCII is sacred, whereas compatibility with 8-bit text encodings is not important.
Since we now have UTF-8 files with BOMs that need to be handled anyway, would it not be better if all the "Unicode-unaware" apps at least supported the BOM (stripping it, in the simplest case)?
Nice article, thank you. I love UTF-8, but I only advocate it when used with a BOM. Otherwise, an application may have no way of knowing that it is UTF-8, and that it needs to be saved as UTF-8.
Imagine selecting New/Text Document in an environment like File Explorer on Windows: if the initial (empty) file has a BOM, any app will know that it is supposed to be saved again as UTF-8 once you start working on it. But with no BOM, there is no such luck, and corruption may be just around the corner, even when the editor tries to auto-detect the encoding (auto-detection is never easy or 100% reliable, even for basic Latin text with "special" characters)
The same can happen to a plain ASCII file (without a BOM): once you edit it, and you add, say, some accented vowel, the chaos begins. You thought it was Italian, but your favorite text editor might conclude it's Vietnamese! I've even seen Notepad switch to a different default encoding after some Windows updates.
So, UTF-8 yes, but with a BOM. It should be the default in any app and operating system.
My oldest son is 5, and I am having some of the same thoughts.
What system did you do the demos on in the 1990s? Might a "classic" system like that not be the "contained" environment you are looking for as a learning environment? And you are even good at that! Systems like the C64, Amiga 500 and Amiga 1200 are still references for current demoscene competitions. They are timeless, you can find them on eBay or emulate them, and your son will be able to show his skills on those even 10 years from now.
If you are afraid that these are not cool enough for your son, fear not. At retro events like VCF, Pixel Heaven, or in the dedicated area at Gamescom, children line up to play on those systems, and for some it is an element of great pride to be experts in them.
My answer to your question looks like this at the moment: I will start with a CBM 8032, after showing him how arcade games of the 1980s were. Then I will add a bit of color, sound, and maybe sprites, via a VIC-20 or C64. And then, if things go well, we can add multitasking and more OS and chipset features by exploring one of the last cool systems where you could try to master every secret: the Amiga.
It doesn't have to be "retro for life". But I think that learning with a "simple" past like this, also makes you better appreciate the present and the future.
Thanks for the feedback. The page [1] has been updated to clarify this detail. The documentation is installed with the package (Help menu, or press F1 to open it), but if you would like to contact me @mikelabatt I can send you a copy.
Me and my colleague Nicola were the ones who asked for these permissions. Iconic demos like Roots 2.0 and World of Commodore could not be included in the historical context for the reasons you mentioned. If someone does not want their work to appear in a commercial book project or in an electronic curation, I respect that. We could do better, like featuring more recent works. Perhaps one day it will be done, like the website (OTOH, some say that it has a Craigslist-like appeal to it). This always was a niche project driven by passion, and resources are tight.
While PC floppy drives are mechanically the same as Amiga floppy drives, the controller that is attached to the drive is different. The controller used in PCs can't handle the stream coming from Amiga disks. The first thing I would do is preserve those disks by creating an image with a custom controller. I am positive that the music and art can be converted, but that can be done later. First, save (image) those disks!
A century ago engineer Luigi Stipa did experiments with several flying wing aircraft designs. Here is Stipa-Caproni's "intubed propeller" from the 1930s: