Re: Proposal for isolation characters in Unicode and the unicode-bidi:isolate and unicode-bidi:plaintext definitions

The idea behind the choice of options 2 is that an isolate would protect
its surroundings against extra or missing PDFs in it contents. For example,
if I have a site that displays the name of a user, and some user codes
their name as "Having fun[RLO]", it will cause the rest of the paragraph in
which this user's name appears to come out backwards. However, putting each
user name in an isolate will prevent that - but only if option 2 is used.
The symmetrical approach does not have that property. Also note that the
current specification of CSS isolates (separate bidi paragraphs) also has
this property, so retaining it means that changing the CSS spec to use
Unicode isolates will have fewer visible effects. In all honesty, this is
the part that appeals to me most about option 2.


On Fri, Jul 20, 2012 at 7:21 PM, Matitiahu Allouche <
matitiahu.allouche@gmail.com> wrote:

> I am late joining this discussion, because I did not see really compelling
> arguments in favor of option 1 rather option 2 or vice versa.****
>
> Just to add to the fun, I want to suggest a third option: in the case of
> improperly  nested embeddings/overrides/isolates, both PDF **and** PDI
> will close all unmatched controls.****
>
> Going back to examples a and b:****
>
> a: RLI LRE PDI PDF****
>
> b: RLE LRI PDF PDI****
>
> ** **
>
> In example a, the PDI will close the RLI and the LRE, PDF does nothing.***
> *
>
> In example b, the PDF will close the LRI and the RLE, PDI does nothing.***
> *
>
> If nothing else, this option has the merit of symmetry.****
>
> However, I am not in mad love with it, and I can live with either one of 1
> or 2.****
>
> ** **
>
> ** **
>
> Shalom (Regards),  *Mati*****
>
> ** **
>
> *From:* Glenn Adams [mailto:glenn@skynav.com]
> *Sent:* Monday, July 09, 2012 5:07 PM
> *To:* Aharon (Vladimir) Lanin
> *Cc:* Martin J. Dürst; W3C style mailing list; public-i18n-bidi@w3.org
> *Subject:* Re: Proposal for isolation characters in Unicode and the
> unicode-bidi:isolate and unicode-bidi:plaintext definitions****
>
> ** **
>
> ** **
>
> On Mon, Jul 9, 2012 at 12:28 AM, Aharon (Vladimir) Lanin <
> aharon@google.com> wrote:****
>
> > I don't understand your logic. You say option 2 offers greater forward
> compatibility,****
>
> > but then say you are choosing 2 because forward compatibility is NOT
> important.****
>
> ** **
>
> Not because it isn't important, but because in certain cases is LESS
> important than another consideration. It's a trade-off.****
>
> ** **
>
> In other words, I think that well-formed documents, i.e. ones where
> isolates and embeddings/overrides are properly nested, should display as
> well as possible on systems that do not support isolates. That is why the
> proposal has been modified to include PDI. On the other hand, when it comes
> to essentially broken documents, where embeddings/overrides and isolates
> are not properly nested, I think it is more important to let isolates do
> their job and isolate the missing and extra PDFs in the apps that do
> support isolates than to make the document display as similarly as possible
> on old and new apps, when apps that don't understand isolates can't
> possibly display the document 100% as intended anyway.****
>
> ** **
>
> > I think backward compatibility is more desirable, i.e., a system that
> knows nothing of****
>
> > isolates should work without modification,****
>
> ** **
>
> By definition, it can't display the document 100% as intended. We
> introduce PDI is so its disability is limited to displaying isolates
> incorrectly (but then limit this to when isolates and embeddings/overrides
> are properly nested).****
>
> ** **
>
> > and yet option 2 requires PDI to close an embedding/override,****
>
> ** **
>
> Only when the isolate began before the embedding/override. If we have LRE
> RLI PDI PDF, the PDI only closes the isolate, not the embedding.****
>
> ** **
>
> That stills leaves that case where pre-PDI implementations would behave
> differently than PDI aware implementations, since the former would not
> close the embedding/override at the same position. I believe that may be a
> problem, and should be avoided.****
>