Roozbeh Pournader wrote:
> This is the most simple but working method, one that's
> implemented in good
> old bidi software that got implemented by native bidi people.
> The users
> feel easy with this, but this may not be enough for them.
> [...]
> In short, good bidi editing should address both the visual and logical
> needs of the user. What you are suggesting, although is one
> of the few
> good and simple methods, only addresses her visual needs. In
> short, if you
> want your software to have a market in bidi countries, what
> you said is
> the minimum requirement.
You are right: my approach may be destructive to some logical distinctions
that might be in the original text.
For instance, if one wants to write in right-to-left Greek (to reproduce
some archaic manuscript) she has to mark the text as RTL override. Otherwise
she will get a text that *looks* RTL, but is actually only *reversed* and,
thus, unusable to all non-visual lexical processes (such as searching).
But I see no easy way to conjugate the complexity of bidi embedding and
overriding with the simplicity of a WYSIWYG representation. Not in plain
text, however.
If you allow embedding and overriding codes to be manually inserted by the
user (as opposed as being automatically generated by the "DErenderer"), then
you loose the simplicity of the approach.
But, although I mentioned rich text, what I really had in mind was plain
text. Maybe in a rich text environment, where it is normal to get a run of
text it and tag it with some property (e.g. underlined, bold, etc.), it
would also be possible to select a block and say "this is embedded LTR
text".
But, in this case, each *single* character in the block must be
independently flagged with the property, so that it retains it also if it is
copied&pasted somewhere else: the actual start and end codes will only be
generated when rebuilding the Unicode string at the end of editing.
_ Marco
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:21:20 EDT