Doug Ewell wrote: > William took exception to being "reduced" to a company in > this way, but I think it makes the scenario a bit more > realistic. [...]
In fact. I absolutely did not mean to be offensive or anything. Simply "Xyz Inc." sounded more like something that can pay my rent than "William Xyz". (But, of course, anybody feel welcome to pay my rent :-) > > 1. The text MUST be transmitted in UTF-8 (because the CEO of > > Overington Inc. thinks that UTF-8 is cute). > > That's a perfectly legitimate requirement. BTW, I think UTF-8 is cute > too. :-) And I as well. In my real life, I am selling UTF-8 as the key to migrate applications to Unicode. > Too bad the customer in this scenario didn't think SCSU was cute. BTW, would it be possible to encode XML in SCSU? > > a. An XML file is human readable and may be edited with any text > > editor; although the Plain-14 file claims to be "plain text", each > > language tag character appears as a three black boxes in any UTF-8 > > editor (and as a random twelve "accented" characters in a non-UTF-8 > > editor). > > While I'm no longer in the business of defending Plane 14 tags, it > should be mentioned that rendering engines are *not* supposed > to display tag characters as black boxes (although they all do). > [...] That's fine, but I must add that this ubiquitous bug is the "feature" that allowed me to minimal editing of my sample text file. > As for the non-UTF-8 editor, well, UTF-8 was a customer > requirement, so not only will the tags display badly, > so will every other character outside the Basic Latin > range. It was a requirement for the host system, not necessarily for every developer's computer. In real life, many colleagues of mine are still using DOS editors or old versions of VI, but they are still able to edit source code in UTF-8, as long as they are just interested in the ASCII part (i.e., the commands, tags, statements, etc.). _ Marco
