hi tzafrir,
is this a property the 'l2r' programs should be able to read/modify? is
this something that most users will want/need to modify? how do you
suggest we give a graphical interface to it? (an obscure interface is
almost as bad as no interface at all)
isn't leaving the default as 'neutral' good enough for most (all) of the
cases?
(i have no problem with extending the possible states or adding a new
set of states, i'm just not sure it's necessary).
On Tue, 3 Jul 2001, Tzafrir Cohen wrote:
> As I've said before, I believe that biditext should have a couple of more
> sstates. Spesifically, the base bidi direction.
>
> Perhaps it should be a seperate type, and not part of R2L_STATE.
>
> Possible values:
>
> Neutral: should be the default (I believe)
> LTR: Right-to-Left (is currently the default)
> RTL: Left-to-Right
>
> Explanation: the bidi algorithm (the function that converts from logical
> to visual) leavs one decision to the caller, because it depends on the
> context: what is the direction of the environment in which this text
> resides.
>
> For instance, in Windows' text entry widget (and in notepad, that uses
> this widget) you can choose between either LTR and RTL by pressing
> Ctrl-Left_shift or Ctrl-right_shift (accordingly).
>
> If the base direction is neutral, then the string's direction will be
> determained by the first "strong-directionality" character, which is a
> relatively good heuristic (but fails if a line of hebrew text happens to
> begin with an english word or a number. (Nadav or anybody: would you mind
> giving a clearer explanation?)
>
> Currently biditext calls fribidi_log2vis with a base direction of LTR .
> This means that if a hebrew sentence containing a latin character it will
> be rendered incorrectly.
>
> If any of you remebers/uses btkbidi: it has a neutral direction by
> default, but the direction can be set by the user explicitly to RTL or
> LTR.
>
> I did a simple implementation of such a change. I didn't want to make any
> other system call, so I decided that for a quick-and-dirty implementation
> I better abusse the st_size field of the stat() result (Muli: to answer
> your question: the code checks: if stat()!= -1).
>
> if size is 0: direction is neutral (touch .rev, echo -n >~/.rev)
> if size is otherwise even: direction is RTL (echo "a" >~/.rev)
> if size is odd: direction is LTR (echo >~/.rev)
>
> The required changes were fairly trivial. But anyway, I have put:
>
> http://www.technion.ac.il/~tzafrir/biditext-0.9.1-size-dir.tar.gz
> http://www.technion.ac.il/~tzafrir/biditext-0.9.1.tar.gz
>
> (I also updated 0.9.1 today. It now really includes an rpm spec file, but
> it doesn't include the original r2l. No need to boter...)
>
> I'm not sure that this feature is required, but I believe that it needs
> testing. Even if it does stay, the abuse of the file size property should
> go away ASAP.
--
mulix
http://www.advogato.com/person/mulix
linux/reboot.h: #define LINUX_REBOOT_MAGIC1 0xfee1dead
