On Wed, Oct 8, 2008 at 13:20, Havoc Pennington <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 7, 2008 at 5:50 PM, Brian J. Tarricone <[EMAIL PROTECTED]> wrote: >> I think what he really meant (or if not, here's my take on it) was that NUL >> bytes aren't *printable* text... like you'd say of low-value ASCII data. >> Sure, it's technically "text," but most of it isn't something you can >> represent visually in a useful manner. > Exactly. I don't see why you would ever want a nul byte, in a > situation where text is expected. Valid UTF-8 and printable text are different concepts. > Another way to put it, I don't think nul bytes are a user-explainable > concept. If anybody who isn't a programmer sees (how? what's the > glyph?) a nul byte in a _text_ file, that's just bizarre. How is "oh, you can't open /that/ file in a text editor because it has a character in it that isn't a user-explainable concept" (I'm not trying to make a straw man argument) better than simply opening the file, displaying the NUL as a box with 0000 in it (like Pango does for other characters it can't render) and be done with it? I don't see how it's the programs responsibility to state what can and what cannot be in a file the user wants to open, as long as the file is valid in the chosen encoding. _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
