@Cap'n Steve said:That's a good point, [b]are[/b] there bold and italic characters in Unicode?The argument of having plaintext support for bold/italics is not quite the same are the argument about layout characters in Unicode. Bold and italics versions are physically different font files eg. glyph sets. The relation between the "normal" and "bold" version of a font is entirely dependent on the matching font name in the file's meta data.Fuckups of this match is the reason I have 2,583 Helvetica weights in Photoshop instead of 1 Helvetica font with 2,583 variants in the second dropdown. In the same vein, my Mrs. Eaves font is a ligatures set in "normal", but small-caps in "bold". It's fucked. There really is no explicit way of saying "This single font file is a complete set of its variants".Thart's how it is on Windows, anyway. :)I argue that there is no semantic difference whatsoever between a control character, and semantic markup fed into a layout engine. \r\n and CRLF mean the same as <br />. All plaintext renderers (including notepad) are already, by necessity, layout engines -- even if they are rudimentary ones compared to, say, an ML/CSS parser+renderer.So where do you draw the line between rudimentary layout (expressed as characters, i.e. by Unicode) and advanced layout (expressed as explicit commands in some form of source code*)?I remember Ye Olde Wordperfect with its underwater view: the line was drawn at the absolute plaintext zero. Everything that concerned layout, even (soft) breaks, was visible as a tag.