<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 12/15/2020 8:19 PM, David Starner
via Unicode wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAMZ=zj6hBhzAgvd7Qx2ZUtAXCRNEdf-RpHxcNL6j1Bzdw+85Nw@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">On Tue, Dec 15, 2020 at 4:47 PM Sławomir Osipiuk via Unicode
<a class="moz-txt-link-rfc2396E" href="mailto:unicode@unicode.org"><unicode@unicode.org></a> wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">"Implementations of Unicode that already make use of out-of-band
mechanisms for language [or format] tagging or “heavy-weight” in-band
mechanisms such as XML or HTML will continue to do exactly what they
are doing and will ignore the tag characters completely. They may even
prohibit their use to prevent conflicts with the equivalent markup."
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
So every single thing that interfaces with HTML now has to handle
Unicode italics on any plain text input, or silently dump them into
the stream, and the web browser may have to handle them or not.
</pre>
</blockquote>
^^^That.<br>
<blockquote type="cite"
cite="mid:CAMZ=zj6hBhzAgvd7Qx2ZUtAXCRNEdf-RpHxcNL6j1Bzdw+85Nw@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">It's meant for preservation, not decoration.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
I've done preservation, and don't see how this helps at all. You can
go with various preservation file formats, like TEI Lite, or various
more directly readable file formats like HTML or PDF. None of those
has any problem handling italics. Plain text willfully drops many
details, so probably isn't a realistic choice for preservation.
</pre>
</blockquote>
<p>Plain text isn't a "preservation" format. It is something
different.</p>
<p>On the one hand, it is a minimalist format, the lowest common <br>
denominator to get text across. Something that every platform,<br>
system, protocol, etc. can (and therefore will) support.<br>
<br>
On the other hand, it serves as the backbone for every rich-text,<br>
full featured, high-fidelity description of "text" in the wider
sense;<br>
including formats that exist to transcribe and preserve richly<br>
annotated, decorated, or idiosyncratically formatted text, some-<br>
times down to the choice of irregular glyph shape alternates.<br>
</p>
<div class="moz-cite-prefix">On 12/15/2020 7:18 PM, Zach Lym via
Unicode wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CABWuLVeffgXCmARPUb5TeUbp9rgcv7V-WAYMyn5v-Y163G=E9g@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">For those of us that can recall the exuberance of the XHTML movement,
<i>, <b> and friends were all deemed to be insufficiently semantic and
slated to be replaced by <em> and <strong>. Of course, this was a
distinction without a difference and now we just have extra tags that
are more verbose and less literal.
But that begs the question: if the authors of a rich text standard
can't agree on what counts as semantic, how would Unicode decide?
What about <mark>, <strikethrough>, or as I previously suggested
<blink>? ...</pre>
</blockquote>
<p>This is indeed a strong argument.<br>
<br>
It is difficult enough to clearly understand how various letter
shapes,<br>
taken individually, are used and when they are used contrastively,<br>
and whether that choice is about what is expressed as opposed to<br>
how it is presented.<br>
<br>
Trying to do the same for various styles, is simply hopeless --
there's<br>
a fair gradient of usage that starts somewhere where font
selection<br>
ends and continues via helpfully marking, or annotating
distinctions,<br>
(like marking foreign terms) to marking emphasis and other
featured<br>
that may disambiguate or otherwise help understand the text. At <br>
the end of that spectrum, you may indeed reach instances where<br>
loss of styling leads to loss of authorial intent or loss of
meaning.<br>
<br>
But it is a spectrum.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CABWuLVeffgXCmARPUb5TeUbp9rgcv7V-WAYMyn5v-Y163G=E9g@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">
The line between semantics and styling is inherently fuzzy, but every
attempt at encoding similarly fuzzy semantics within Unicode is
something humanity must deal with for the rest of all time. ...
</pre>
</blockquote>
<p>There are millions of different reasons someone may have used<br>
italics in a printed document. Some of them can be traced to style<br>
guides, like italicizing species names or foreign terms. Those are<br>
are easy enough to capture with semantic markup, because the<br>
semantics are clear.</p>
<p>In some cases, there even exists variations in styling other than
<br>
italics for the same types of uses. Text typeset in Fraktur would
use<br>
alternation with text typeset in an Antiqua font to mark foreign<br>
terms and some other items that we nowadays might use italics<br>
for; a perfect case for semantic markup, that would allow a style-<br>
sheet to switch the text over to Fraktur and switch italics to<br>
Antiqua for certain semantically marked items.<br>
<br>
Except: the rules are slightly different and you would have to <br>
semantically mark text that in modern typesetting is not marked<br>
by a style or font difference to make that possible.<br>
<br>
Altogether, the "semantic markup only" can only ever capture<br>
a subset of things and style sheets + semantic markup would have<br>
to be designed with <i>all</i> the possible resultant variants of
text <br>
appearance in order to be sure that you could get from one to<br>
the other via style-sheet change alone.<br>
<br>
In that context, Unicode has little to contribute. There's no way<br>
to cut the gordian knot in semantic markup (not even when you<br>
code that using TAG characters). And, conversely, hardcoding <br>
visual appearance is really the least helpful, because that
totally<br>
undercuts the the ability for style sheets to address
presentation.<br>
</p>
<blockquote type="cite"
cite="mid:CABWuLVeffgXCmARPUb5TeUbp9rgcv7V-WAYMyn5v-Y163G=E9g@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">
What puzzles me is why this discussion wasn't moderated to the null
bin. This <b class="moz-txt-star"><span class="moz-txt-tag">*</span>exact<span class="moz-txt-tag">*</span></b> question is answered in the FAQ and is regularly
shot down.</pre>
</blockquote>
<p>I'm not sure that I would place doubting Unicode's encoding and<br>
other policy decisions, even long-standing ones, on the same level<br>
as, say, doubting the conservation of energy.<br>
<br>
A physics forum might shunt proposals for perpetual motion engines<br>
to the "null bin" (or "black hole" to use something more physical<br>
as a metaphor) but that's because the understanding of the con-<br>
servation of energy is not improved by discussing that particular<br>
kind of impossible invention.<br>
<br>
On the other hand, discussing why Unicode makes a decisive <br>
cutoff among a gradient of choices is always useful. Even if some
of<br>
us have heard it all before. <br>
<br>
A./<br>
</p>
<p><br>
</p>
</body>
</html>