On Tue, 08 Aug 2000, Roman M . Parparov wrote:
> This is a tough one. But it is known that the numerical game scores and
> likewise are being written RTL. As for math, I've seen it being written
> both ways. I am not a native hebrew speaker and I consulted some natives
> at work and no consensus was reached. It means some expanded and very
> precise spec should be written on how a pure RTL and RTL with portions of
> LTR have to look like.
>
Sounds like a road trip to me. ;-)
I'm not a native speaker, either. (As if the name didn't give that
away.) All my bi-dir GUI work has had support of a RTL widget set that
handled the display rules automatically.) I think we're just looking
to make sure that Perl can fake RTL without outside RTL support, no?
> Besides, speaking of Arabic, they do have even their own digits,
but then,
> I think they behave just like letters.
>
Arab numerals behave exactly like arabic numerals - is that
confusing? - in that they're written LTR in number form. Yes, they
have different characters, but that's actually where our evaluation
order came from. Farsi has the same requirements. There may be
other RTL languages that don't, however.
To use numbers that are (easily) transliterated.....
1,547,956.17 = 1,OEV,9O7.1V
> > Perhaps a sub-list to hash out how we
can do this without bloating Perl > > too much?
> >
> I think not at this stage. We need to decide how important this is for
> PERL and after we're done with ths more or less general stage,
> we'll roll out the Specs and then it'd be possible to start coding.
>
> Currently, an item for the discussion IMHO is - whether to empower
> existing print to handle visual RTL output, whether to write a core
> output function rtlprint, or to reduce ourselves to a Text:: module?
> I.e. - WHAT are we going to do, but not yet - HOW.
Well, I think what we can do depends on how we can do it.
This should, IMHO, be possible in Perl, but not necessarily core, but
there are some potential core issues that need to be addressed.
For instance, if formats are relegated to a module, then it would
simply be a matter of supplanting that module to give you your correct
semantics.
If, however, it's still internal, then the core will need to have hooks
to allow visual RTL. (s/will need to/should/, I suppose.)
I doubt that many people on the list have a personal involvement in
this issue, and shouldn't care one way or another if we can implement
it without penalty to everyone else. It may be that we just add this
as another reason to do foo() like bar.
(Hence my suggestion to get it down out of everyone's way.)
--
Bryan C. Warnock
([EMAIL PROTECTED])
