BidiMirrored property and ancient scripts (Was Re: Plain text custom fraction input)
richard.wordingham at ntlworld.com
Fri Jul 24 15:23:52 CDT 2015
On Fri, 24 Jul 2015 10:09:18 -0700
Asmus Freytag <asmusf at ix.netcom.com> wrote:
> On 7/24/2015 2:59 AM, Frédéric Grosshans wrote:
> > Let me rephrase my remark in a less “stupid and dangerous” way.
> > If a LTR character has the BidiMirrored=No property, it may
> > either be mirrored or not when typeset in RTL, depending on other
> > factors. Specifically, the BidiMirrored property has not been
> > specified for ancient LTR scripts which are mirrored when RTL or
> > boustrephodon, like Italic, Runic, Archaic Greek, Archaic Latin,
> > Egyptian Hieroglyphs. Note that some RTL script, like Old North
> > Arabian, are mirrored when LTR.
> We do want "BidiMirrorred=No" to be honored; for example for the
> arrows and the ornate parens. And we do not want that to be overridden
And at present, that may be overridden in a right-to-left context!
I think Frédéric meant Bidi_Class=Left_To_Right by 'LTR', in which
case the only paired arrows included are U+2347 APL FUNCTIONAL SYMBOL
QUAD LEFTWARDS ARROW and U+2348 APL FUNCTIONAL SYMBOL QUAD
RIGHTWARDS ARROW. It's definitely appropriate for U+101D9 PHAISTOS DISC
> The issue with the ancient scripts (or any script used to capture
> paleographic texts) seems to be primarily with letter shapes, not
> and further would apply only to unpaired forms.
> A carefully written note would keep in scope all paired characters.
> It would be nice if there was a property that covered them, but I'm
> afraid that BidiMirroringGlyph does not cover the character pairs to
> use when BidiMirrored=No and code points need to be substituted to
> get the RTL layout correct. That kind of property would be useful for
> modern text, e.g. to allow support for automatic re-layout from RTL
> to LTR and vice versa for texts containing arrows.
Microsoft has frozen BidiMirroringGlyph. Text rendering honours it up
to Unicode 5.1 (I think), but thereafter it's up to the font. That may
be appropriate for some bidirectional writing systems - I dimly recall
that mirroring had a tendency to fail with some letters.
> Declaring all unpaired code points overridable "in certain contexts"
> or "depending on other factors" might then work.
I think a stronger indication is needed. U+2044 FRACTION SLASH had
better not be overridable between European numbers or between Arabic
numbers, for with a generally linear layout the number on the left is
the numerator and the number on the right is the denominator. Am I
missing something on the options for this character in a wider
right-to-left context? A sequence looking like (numerator, on right)
(backslash) (denominator, on left) seems to be known in Arabic maths.
I think it is useful to gather the information together in one list,
More information about the Unicode