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.

Received on Monday, 9 July 2012 14:07:47 UTC