> I understand that Mac developers would consider a conversion to unicode > "lossy" or "non-reversible" if the directionality indicators are not > preserved somehow (using RLE/LRE or RLO/LRO), and this might constitute > an "algorithmic" approach that 'enc2xs' would not support. > > Is there a work-around that will allow all the MacArabic code points to > be converted successfully, given that their respective character > semantics are all well established in unicode? Even a "lossy" > conversion (ditching the directionality specs) would be better than the > failures I'm getting now.
(1) If you can forgive information loss on the text direction, how about use of fallback? e.g. 0x2B <LR>+0x002B # PLUS SIGN, left-right 0xAB <RL>+0x002B # PLUS SIGN, right-left in http://www.unicode.org/Public/MAPPINGS/VENDORS/APPLE/ARABIC.TXT can be converted to <U002B> \x2B |0 # PLUS SIGN <U002B> \xAB |3 # PLUS SIGN, right-left in Encode/ucm/macArabic.ucm. (2) I've briefly written a module (attached with this mail) for MacArabic with Perl 5.6.1 or later. I hope it would be able to be built on Mac; but I haven't worked with Macintosh, and I'm not well-informed in Macintosh nor "bidi", please report me if something wrong. (at least, the version here doesn't support embedding or nesting of direction.) SADAHIRO Tomoyuki
Lingua-AR-MacArabic-0.00.tar.gz
Description: Binary data
