<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> </head> <body><div class="auto-created-dir-div" dir="auto" style="unicode-bidi: embed;"><style>p{margin:0}</style><span style="white-space-collapse: preserve;">Erik Carvalhal Miller wrote as follows.</span><div><p><span style="white-space-collapse: preserve;"><br></span></p><p><span style="white-space-collapse: preserve;">> </span><span style="white-space-collapse: preserve; display: inline !important;">But, you may ask,</span></p><span style="white-space-collapse: preserve;">
what about the mathematical Latin and Greek alphanumeric symbols, rich </span><span style="white-space-collapse: preserve;">in implied typographical styles including italic?</span></div><div><p><span style="white-space-collapse: preserve;"><br></span></p><p><span style="display: inline !important;">Thank you for replying.</span><br></p><div><br></div><p>Yet I did not. As a mathematician I understood the difference of approach. I never had any intention of seeking to try to use the encoding of those characters as a precedent. That concept got refuted as a possible precedent notwithstanding that I had not contemplated trying to do that.</p><p><br></p><p>> <span style="white-space-collapse: preserve; display: inline !important;">This statefulness applies even to </span><span style="white-space-collapse: preserve; display: inline !important;">pre‐computer days of metal type: A compositor about to set a run of </span><span style="white-space-collapse: preserve; display: inline !important;">italic type would turn to a case of italics from which to pick out the </span><span style="white-space-collapse: preserve; display: inline !important;">next several glyphs, then turn back to a non‐italic case when that run </span><span style="white-space-collapse: preserve; display: inline !important;">was complete, rather than serially start and finish using the italic </span><span style="white-space-collapse: preserve; display: inline !important;">case many times in a row.</span></p><p><br></p><p>If the type were being handset, that may well be true in relation to the practical use of typecases, with the compositor perhaps needing to move to work at a different table where the typecase or typecases for italic glyphs had been placed, the compositor perhaps needing to use separate typecases for uppercase letters and punctuation, and for lowercase letters and punctuation. I do not know at present how the process worked if the compositor were using machine composition using a Linotype Machine or a Monotype machine. <span style="display: inline !important;">I learned to handset metal type back in the 1960s as I was involved in private press printing as a family hobby. Metal type in use was not stateful regarding italics as each piece of metal type in a sequence of handset metal type was an independent unit and there was no state set anywhere that insisted that the next piece of type after an italic character would be an italic character as sometimes it would not be, such as after an italicized word had been completed, and indeed, except for a very few special founts such as Palace Script, the spaces used between words were the same both for the roman fount and for the italic fount. For the avoidance of doubt, there were space sorts available in the italic case, for convenience when setting a sequence of words in italic sorts, yet they were from the same purchase of spacing material from the type foundry and were fount-independent too in relation to founts of the same point size, except for a few founts such as Palace Script that had special angled space sorts.</span></p><p><span style="display: inline !important;"><br></span></p><p>A modern computer desktop publishing text editor program could allow a compositor to switch from roman to italic for a sequence of characters and yet allow, as an option, the text to be output to a file as plain text with a VS14 character after each of the italicized characters, so in practice, if implemented, there need not be any tediousness in applying a VS14 character after each text character. I say that allowing the VS14 proposal to become encoded would be practical and would not make a string of Unicode characters stateful. In days gone by, suggesting a character to switch on italics and a character to switch off italics was rejected as it would have made Unicode stateful. So, as time went by and I learned, a method to achieve the result without making Unicode stateful was devised, tested and it worked great, but that was rejected too, because it was not stateful! </p><p><br></p><p>Actually, my main reason for wanting to be able to encode italics in plain text was to be able to transcribe historical texts into plain text on a computer, including such things as the title pages of printed books.</p><p><br></p><p>I consider that, alas, an opportunity for progress has been dismissed due to adherence to concepts from long ago that are not relevant in some modern usage situations. The capabilities of plain text could be improved if that were allowed.</p><p><br></p><p>William Overington</p><p><br></p><p>Wednesday 11 October 2023</p><p><br></p></div></div></body></html>