James Kass wrote:
If a text is published in all italics, that’s style/font choice. If a text is published using italics and roman contrastively and consistently, and everybody else is doing it pretty much the same way, that’s a convention.
Asmus Freytag responded:
But not all conventions are deemed worth of plaintext encoding.
What are the criteria for “worth”?
Way back when, when plain text was very very plain, arguments about not including text styling seemed reasonable. But with the inclusion of numerous emoji as James mentioned, it seems odd to be protesting a few characters that would enhance “plain text” considerably. Plain text editors today support bold, italic, and other styles as a fundamental requirement for usability. More text editors support styling than support bidi or interlinear annotation.
If there was support for the handful of text features used by most plain text editors (bold, italic, strikethrough, underline, superscript, subscript, et al) (perhaps using more generalized names such as emphasis, stress, deleted…) then many of the redundant (bold, italic, …) characters in Unicode would not have been needed. HTML seemed to do very well with a very few styling elements. HTML is of course rich text, but I am just demonstrating that a very small number of control characters would bring plain text into the modern state of text editing. Editors that don’t have the capability for bolding, underlining, etc. could ignore these controls or convert them to another convention.
As James requested, it would also provide interoperability.
Arguments about all of the conventions that Unicode does not support doesn’t seem compelling to me, as it seems increasingly random as what is accepted and what isn’t, or at least the rationales seem inconsistent.
A case in point is the addition of the “SS” character which made implementation complex with little benefit.
Interlinear annotation is perhaps another example.
I don’t want to enter into a debate about why these deserved inclusion. I am only saying they seem less useful than some other cases which seem deserving.
**And right now, Dr. Strangelove style, my right hand is restraining my other hand from typing on the keyboard, to avoid saying anything about emoji.**
Ken distinguished numerous variations of stress, which of course have their place, representations and uses. But perhaps for plain text we only need a way to indicate “stress here”, leave it to the text editor to have some form of rendering. For more distinctions the user needs to use rich text. Surely there is an 80/20 rule that motivates a solution rather than letting the one percent prevent a capability that 99% would enjoy.
(Yes I mixed metaphors. I feel an Occupy Unicode movement coming on. J )
I don’t see how adding a few text style controls would be a burden to most implementers. Given ideographic variation sequences, skin tones, hair styles, and the other requirements for proper Unicode support, arguing against a few text styling capabilities seems very last century. (Or at least 1990s…) And it might save having to add a few more bold, italic, superscript, et al compatibility characters…
tex
Received on Wed Jan 09 2019 - 03:38:14 CST
This archive was generated by hypermail 2.2.0 : Wed Jan 09 2019 - 03:38:14 CST