. Peter Constable wrote, > Sure, but why do we want to place so much demand on plain text when the > vast majority of content we interchange is in some form of marked-up or > rich text? Let's let plain text be that -- plain -- and look to the markup > conventions that we've invested so much in and that are working for us to > provide the kinds of thing that we designed markup for in the first place. > Besides, a "plain-text" file that begins and ends with p14 tags is a > marked-up file, whether someone calls it "plain text" or not. We have > little or no infrastructure for handling that form of markup, and a large > and increasing amount of infrastructure for handling the more typical forms > of markup.
We place so much demand on plain text because we use plain text. We continue to advance from the days when βplain textβ meant ASCII only rendered in bitmapped monospaced monochrome. We donβt rely on mark-up or higher protocols to distinguish between different European styles of quotation marks. We no longer need proprietary rich-text formats and font switching abilities to be able to display Greek and Latin text from the same file. > I repeat, plain text remains legible without anything indicating which eng > (or whatever) may be preferred by the author, and (since the requirement > for plain text is legibility) therefore this is not really an argument for > using p14 language tags. IMO. Is legibility the only requirement of plain text? Might additional requirements include appropriate, correct encoding and correct display? To illustrate a legible plain text run which displays as intended (all things being equal) yet is not appropriately encoded (this e-mail is being sent as plain text UTF-8): π°π πππ πππ ππππ ππππ πππππππ... πππ πππ ππππ ππ ππππ π΄π¨π¨π¨* ππ π«π΅πͺπ±π«π΅πͺπ±π«π΅πͺπ±ππΈπ½π¬πΈπΆ (*π πΊππ ππ πππΊπ»πΎππ ππ»πππΎππ πππππππππ) Clearly, correct and appropriate encoding (as well as legibility) should be a requirement of plain text. Is correct display also a valid requirement for plain text? It is for some... Respectfully, James Kass .
