Linux HTML mail agent with RTL and LTR paragraph explicit support

[Shachar Shemesh]

On 06/25/2012 09:56 PM, Eli Zaretskii wrote:
>> 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
> Again, I think such an interpretation is against the spirit of HL1.
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.

More to the point, I think you are reading HL1 wrong.

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):
> Here's the full text:
>
>   HL1. Override P3, and set the paragraph embedding level explicitly. 
>   
>   . A higher-level protocol MAY set any paragraph level.
Okay. We may. We may not. Both are okay.
>  This MAY be
>     done on the basis of the context, such as on a table cell,
>     paragraph, document, or system level.
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.

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.
>  (P2 MAY be skipped if P3 is
>     overridden).
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".
>  Note that this does not allow a higher-level protocol
>     to override the limit specified in BD2.
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.
>
>   . 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.
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.

All in all, I find it hard to see ANY policy for setting the paragraph
direction that would violate HL1.

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.

Personally, I see no way to read this standard but as allowing arbitrary
determination of paragraph direction with no restrictions on how.
> But whatever the interpretation, ...
>
>> even if Eli Zaretskii doesn't approve.
> ... 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.
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.

Shachar

-- 
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
http://www.lingnu.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20120626/9bd54e81/attachment.html>