<html style="direction: ltr;">
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<style type="text/css">body p { margin-bottom: 0.2cm; margin-top: 0pt; } </style>
</head>
<body bidimailui-detected-decoding-type="UTF-8" bgcolor="#FFFFFF"
text="#000000">
<div class="moz-cite-prefix">On 06/25/2012 09:56 PM, Eli Zaretskii
wrote:<br>
</div>
<blockquote cite="mid:83ipef9q4z.fsf@gnu.org" type="cite">
<blockquote type="cite">
<pre wrap="">Outlook employs a higher level protocol. It is "all paragraphs are LTR,
unless the user presses CTRL+RIGHT SHIFT, in which case all paragraphs
are RTL". It is a valid, standard conforming protocol
</pre>
</blockquote>
<pre wrap="">
Again, I think such an interpretation is against the spirit of HL1.</pre>
</blockquote>
I'm not sure what "the spirit" of a standard is. Standards are
specifications. You are either conforming, or non conforming. This
is by design, and part of the reason that standards are formed by
large committees. There is an attempt to prevent threads like this
one.<br>
<br>
More to the point, I think you are reading HL1 wrong.<br>
<br>
Usually, when writing standards, certain words have a meaning that
has special stress when used in standard. These words are explained
in RFC 2119. Now, I will readily grant you that RFC 2119 does
recommend that standards that use the words with this meaning (which
is, more or less, the usual English meaning of the words) refer back
to RFC 2119 and capitalize those words. The UBA does neither.
Further, it uses the word "can", which is not defined by RFC 2119.
Still, when trying to figure out what can or cannot be written in
conformance to a standard, I find these words useful. In order to
bring us to a more strict agreement on what HL1 says, I've allowed
myself to modify the text of the paragraph to be in conformance to
RFC 2119. I've mapped "can", which is not defined by RFC 2119, to
"MAY", which has, more or less, the same meaning. I've capitalized
the key words I changed, so you can check whether you agree with my
modifications (and because RFC 2119 suggests it):<br>
<blockquote cite="mid:83ipef9q4z.fsf@gnu.org" type="cite">
<pre wrap="">
Here's the full text:
HL1. Override P3, and set the paragraph embedding level explicitly.
. A higher-level protocol MAY set any paragraph level.</pre>
</blockquote>
Okay. We may. We may not. Both are okay.<br>
<blockquote cite="mid:83ipef9q4z.fsf@gnu.org" type="cite">
<pre wrap=""> This MAY be
done on the basis of the context, such as on a table cell,
paragraph, document, or system level.</pre>
</blockquote>
These are nested options. I read it to say that even if you chose to
override the paragraph levels, you may still choose to use context
or not. Also, notice the "document" and "system level" options.
These clearly encompass the Outlook/Notepad use I mentioned in my
previous email, which you found to contradict HL1.<br>
<br>
Lastly, note that the original verb, "can", is actually weaker than
"may". In plain English, "may" is fairly neutral, while "can"
suggest that the default action is not to.<br>
<blockquote cite="mid:83ipef9q4z.fsf@gnu.org" type="cite">
<pre wrap=""> (P2 MAY be skipped if P3 is
overridden).</pre>
</blockquote>
P2 is only used to produce data used by P3, so going through the
motions of P2 if P3 is not going to be used makes no sense. I would
actually recommend this changed to "SHOULD".<br>
<blockquote cite="mid:83ipef9q4z.fsf@gnu.org" type="cite">
<pre wrap=""> Note that this does not allow a higher-level protocol
to override the limit specified in BD2.</pre>
</blockquote>
So, if you do decide to explicitly set a paragraph embedding level,
you may only choose one between 0 and 61 inclusive. I think we're
good.<br>
<blockquote cite="mid:83ipef9q4z.fsf@gnu.org" type="cite">
<pre wrap="">
. A higher-level protocol MAY apply rules equivalent to P2 and P3
but default to level 1 (RTL) rather than 0 (LTR) to match overall
RTL context.
. A higher-level protocol MAY use an entirely different algorithm
that heuristically auto-detects the paragraph embedding level
based on the paragraph text and its context. For example, it could
base it on whether there are more RTL characters in the text than
LTR. As another example, when the paragraph contains no strong
characters, its direction could be determined by the levels of the
paragraphs before and after.</pre>
</blockquote>
I think it is fairly clear that these two bullets are alternatives
to the first one (and, indeed, each other). For one thing, it is
technically impossible for an implementation to implement all three;
they are contradicting. Since the first one covers our use, the fact
that these two don't does not matter.<br>
<br>
All in all, I find it hard to see ANY policy for setting the
paragraph direction that would violate HL1.<br>
<br>
Even if so, however, please notice you can achieve the exact same
effect using only HL3, which is not limited in its use in any way
form or shape (personally, I think that neither is HL1, but I can
see where your disagreement comes from). Also note how the standard
clearly states that HL1 and HL3 are contained in what HL4 and HL5
allow you to do, and these two, again and unsurprisingly, allow you
to achieve the exact same effect. Again, these two are not limited
in what way they are being used in any way.<br>
<br>
Personally, I see no way to read this standard but as allowing
arbitrary determination of paragraph direction with no restrictions
on how.<br>
<blockquote cite="mid:83ipef9q4z.fsf@gnu.org" type="cite">
<pre wrap="">
But whatever the interpretation, ...
</pre>
<blockquote type="cite">
<pre wrap="">even if Eli Zaretskii doesn't approve.
</pre>
</blockquote>
<pre wrap="">
... there's no need to get personal. We can agree to disagree, you
know, and still be able to conduct a civilized discussion, devoid of
ad hominem.</pre>
</blockquote>
I'm sorry about that. In my defense, you made it extremely difficult
to answer to the point. You simultaneously sent out seven (!!!)
replies to different emails in the same thread, and you gave no
details as to what made you decide what you did. It sounded like an
opinion stated as fact, and I responded accordingly. Again, sorry if
you were offended. <br>
<br>
Shachar<br>
<pre class="moz-signature" cols="72">--
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
<a class="moz-txt-link-freetext" href="http://www.lingnu.com">http://www.lingnu.com</a>
</pre>
</body>
</html>