[Date Prev][Date Next][Thread Prev][Thread Next] [Search] [Date Index] [Thread Index]

Re: [MacPerl] The MacPerl Pages and book (update)



At 11:36 +0100 30/10/1997, Matthias Ulrich Neeracher wrote:
>The problem is that the entire locale engine is not implemented in the
>Standard
>C library I use, and, cool as this would be, I simply don't have the time or
>inclination at the moment to write one (Does anybody know of a portable, PD
>implementation?).

No, I'm afraid not.

The current behaviour is OK, I think.
Which is why I wondered about Prymmer referring to different behaviour. (In
fact you didn't clear this up: has MacPerl ever behaved as Prymmer referred
to?)

>This should not mean that I doubt the merit of locales, coming from a country
>with two different sets of accented characters.

At least you haven't had to convince ISO that one of your letters _is_ a
letter and not a ligature (Unfortunately, it is still referred to as
æ), or that the ring above a in 'Œ' is _not_ an accent. (I used to
have a silly habit of reading DS - Dansk Standard - newsletters.)

Also, POSIX LC_COLLATE can't deal properly with the Danish '' and 'Œ',
when it is also sometimes written as 'Aa' and 'aa' (mostly in names, where
people and cities often decide to keep an oldfashioned spelling), which
still should always be last in a collate-sequence. In Perl, fortunately,
this is easy:
@names = sort {
        my $aa = $a; my $bb = $b; # mustn't change the names
        $aa =~ s/aa/Œ/g; $aa =~ s/Aa//g;
        $bb =~ s/aa/Œ/g; $bb =~ s/Aa//g;
        $aa cmp $bb; } @names;

(Hmm. At least we can use ISO-8859-1. Many countries aren't as "fortunate".)

Alas, without locale, both ISO-8859-1 and the Mac charset ordinate '®¯' in
the order '®¯', so a sort of names based on ordinal character values is
always plain wrong. Of course inserting

$aa =~tr/Œ¿¯/¿Œ¯/; $bb =~tr/Œ¿¯/¿Œ¯/;

above could fix this. But suddenly sorting names has turned out to be
pretty complex.

Well, how is the collate sequence for Swiss accented letters?

I don't know too much about POSIX, I guess it depends on ISO-charsets and
doesn't concern itself with proprietary charsets? In that case, a
POSIX-based MacPerl would have to deal with ISO charsets somehow. I doubt
that this is a smart thing to do, as the scripts would be handling
Mac-text, which is not ISO.

An alternative approach would be to define a meaning for use locale in a
non-POSIX context, or define means other than POSIX::setlocale that affect
locale. Again, this might not be smart, because it would create
cross-platform incompatibilities. On the other hand however, since the
incompatibilities exist already (due to lack of full POSIX on the Mac) this
might not be _too_ bad. Perhaps a MacOS parallel to POSIX, implementing
functions equivalent to some POSIX functions, but with Mac-specific
conventions, from the toolbox?

Maybe use locale in itself could then just use the current settings in the
Text control panel, and some special call (an equivalent to setlocale)
could change this locally for the script.

I'm not asking for features, just contemplating on what possibilities there
would be.

-Lasse



***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch