RE: Question about the directionality of "Old Hungarian" (document N3531)

From: Kent Karlsson (
Date: Mon Nov 03 2008 - 14:19:21 CST

  • Next message: linuxa linux: "Solutions to the IDN Problems Discussed"

    André Szabolcs Szelp wrote:

    Sorry, there is a misunderstanding.

    I was starting my letter with "Not considering bustrophaedon", which means not considering it!

    Ok. But graphically mirroring every line is very similar to graphically mirroring every second line...

     I was speaking of the default behaviour of the script to be able to be written EITHER rtl OR ltr, (and NOT bustrophaedon).

    You can have only one of them as "default". <> proposes that
    the "default" be RTL for Old Hungarian.

     So the question is, again, DISREGARDING bustrophaedon (which I still believe is actually a non-issue, as I put it in a longish mail in reply to Gábor Hosszú),

    For LTR override: wouldn't Bidi_Mirroring bring exactly the expected behaviour?

    Short answer: no.
    Long answer:
    Only characters that have the resolved directionality of R (at step L4 of the bidi alg.) can get their glyphs
    mirrored, according to the bidi algorithm. And among those, the characters that have the property
    bidi_mirrored=true are to be mirrored. There is a loophole allowing "higher-level-protocols" to mirror also some
    characters that have bidi_mirrored=false to be mirrored. I would not count on such a higher-level-protocol
    though (I haven't heard of anyone suitable, as yet anyway).
    So if the letters are strong L (LTR), and (preferably, not counting on a higher level protocol) have bidi_mirrored=true,
    and you have a span where one has overridden the direction to R (RTL), the glyphs are to be mirrored according
    to the bidi algorith. Modern punctuation marks (not counting on a higher level protocol), except for parentheses/
    bracket/similar (which aren't really mirrored, but replaced by the counterpart character in the output pipeline,
    consider italics) would not get mirrored.
    But if the letters are strong R (RTL), and you have a span where one has overridden the direction to L (LTR),
    *no* glyphs are to be mirrored (according to the bidi algorithm as it stands), even if they have bidi_mirrored=true.
    (And there is currently no loophole for higher-level-protocols in this case.)
    From <>, I get the impression, from "When the direction of
    characters is changed, they are mirrored, like Old Italic and other scripts.", that you want to change the bidi
    algorithm to do mirroring in a way it does not do now. I don't think one should do that (and I have the impression
    that changing the bidi algorithm now is next to impossible), since that would start mirroring Hebrew, Arabic, and
    other modern RTL scripts when LTR overridden, and mirror LTR scripts when RTL overridden. One could still
    consider introducing new properties, like mirror_when_ltr_overridden and mirror_when_rtl_overridden (or trying to
    conflate these: mirror_when_overridden_to_opposite_direction). That would still require a change to the bidi
    algorithm. I'm far from sure that this approach would be good, and even if it is, that it would be accepted by
    the UTC, given that the bidi algorithm now is next to impossible to change. Adding a loophole for the L case
    like that for the R case maybe is possible (but I, for one, don't really like the loophole approach).
    Graphically mirroring a line (every line, or just every second) is different. It does not involve the bidi algorithm,
    but a (different) higher level protocol (setting, if you like) to just mirror lines (after bidi processing and it's
    mirroring, and after line breaking). This would have a different effect, and mirror the entire line (as a whole)
    including mirroring modern punctuation marks (and Latin text too for that matter). That can then be done on
    every line (in an span), or every second line (in a span). As you say, the latter (every second line) may not
    be of interest for Old Hungarian. This does not involve changing the bidi algorithm in any way, not require bidi
    overrides, and it would mirror, literally, all punctuation marks (some will sometimes be mirrored twice, the first
    via the bidi alg.). But italics would get a perhaps strange effect (literally mirrored, but maybe that is expected),
    and LTR scripts will also get mirrored.
            /kent k


    2008/11/2 Kent Karlsson <>

    Szabolcs Szelp wrote:
    > Not considering bustrophaedon,
    > even in the described standard behaviour of OH of having the
    > characters mirrored when overriden LTR, I believe it is problematic
    > that one has to replace the punctuation characters.
    > Usually one would think of the LTR and RTL in OH as the same text with
    > the same information, ie. the same string of characteres, only
    > displayed differently (i.e. other text-flow direction, and mirrored).
    > So why do we have to use other characters?

    Bidi (in the Unicode sense) and bustrophedon (while in a quite different
    way "bidirectional") are unrelated and should not be conflated in any way.

    > The passage in the current proposal authored by Michael and me
    > contains the passage above cited by Karl, it was included on grounds
    > of verbal communication of Michael about the preference "by the
    > committee".
    > However, I do believe that it should be open for discussion.
    > Karl suggested (privately) having the punctuation included in the OH
    > block, alongside with the Bidi_Mirrored=Yes property.

    Naa. Bidi_Mirrored is for handling Arabic, Hebrew and similar scripts.
    It's NOT for handling bustrophedon, which mirrors *all* glyphs (once)
    on every second line. Bidi override controls never mirror characters
    which have Bidi_Mirrored=FALSE. Also the bidi overrides do not go well
    together with bustrophedon and automatic line breaking. Bustrophedon
    is simply a quite different beast from Arabic/Hebrew/etc. Bustrophedon
    should simply graphically mirror the entier line, every second line.

           /kent k

    This archive was generated by hypermail 2.1.5 : Mon Nov 03 2008 - 14:22:37 CST