From: "Kenneth Whistler" <[EMAIL PROTECTED]> > Philippe Verdy continued: > > > What surprizes me the most in the Unicode spec is that it > > both says that its purpose is to create arbitrary length > > of leaders > > As in plain text, as can be seen in Table of Content listings > in many RFCs, for example. (Which, however, use ASCII 0x2E for the > same purpose.)
RFCs are not writen using Unicode. They are limited to ASCII, even if they are originally created in a XML-based rich text format. That's why they are converted using the standard fallback conversions to sequences of full stops. I don't see the interest of this argument, given that ASCII has no leader characters. It is reasonnable in the RFCs to write them with full dots because there's no other choice, given the constraints of the ASCII format and a typewriter style with a fixed number of columns. RFCs are plain text but this format is not a flawed text, for historical reasons (even the page layout is fixed!). However, most RFCs are now available too in a flawed rich text format that allow them to be presented in a much more readable format for printing. In some future, when all past RFCs will have been rewritten to the new rich text format, they will be available as XML+XSL text, HTML text, preformatted PDF files, ... It is even possible that the RFC Editor abandons the ASCII format at some time, because of the difficulties to integrate schemas, graphics, and tables, and the difficulties to interpret some notations sometimes needed because of the absence of a richer character set. At that time the XML format may become the only supported normative format, with all other formats derived from this source (note that new RFC submissions MUST now be created with this new format with a normative DTD, before discussions and approval of its content, which will be converted to preformated ASCII text later). The main reason is the difficulty to maintain the preformated text when it is discussed (it requires too much manual editing).
