> Re: "paragraph direction and alignment are two different things." Certainly > true (and, from many discussions here and elsewhere, it's obvious to me > that > anyone who cares about such things already knows this as well) but, I > think, > misses the primary point, which is to eliminate a bizarre and confusing > user > interface.
I don’t think there is anything bizarre or confusing about this user interface (speaking as a RTL user), but your mileage may vary. > So: Two responses to your comment: "This usually means you didn’t set the > paragraph direction and just aligned the paragraph to the right while > leaving its direction LTR. No jumping would happen if the paragraph has > RTL > direction." > > First off, I'm basing my own opinions on the idea that following the > Unicode > Standard in this regard *should be* the objective, since a) it is well > thought out and b) results in an interface that is both more intuitive and > far easier to use in practice. The reference for that, by the way, is > http://www.unicode.org/reports/tr9/tr9-35.html for the official “Unicode® > Standard Annex #9: UNICODE BIDIRECTIONAL ALGORITHM.” We do follow it. > So here goes. > > To your point about setting the paragraph direction, you are correct. But > why should a user need to do so if it is unnecessary? Annex 9 clearly > recommends that the *default* paragraph direction should be set to the > directionality of the first strongly directional character entered into a > that paragraph. This is just my interpretation, of course, but it's > bolstered by the fact that it makes life easier. More on the *default* in > a > bit ... True, but it also allows for higher level protocols to control it, see http://unicode.org/reports/tr9/#HL1, which is what we do here and pretty much any system that allows text formatting. The problem with setting paragraph direction based n first string is that it is heuristic, and it often fails; if your RTL paragraph starts with a LTR word it will get the wrong paragraph direction, or if it does not contain any strong direction characters (e.g. numbers only) then you can’t even determine the direction. In Writer you simply need to select paragraph direction just once when you start a new document and it will use it for all paragraphs until you change it. This have the benefit of being explicit rather than implicit, if there was a 100% certain way to auto detect paragraph direction it would have been the default. > The Calligra Words and FocusWriter word processors, as well as the gEdit > and > Kate text editors both act in this manner, so it's not unheard of. Of > course, neither word processor has the feature set of Writer, but that's > not > the scope of this discussion - I will say that, for some complex or > extensive entry where intermingling of bidirectional text is required, I > will switch to one of those to do the actual typing, and then copy the > block > to Writer to make use of its other features. In such situations, Writer's > behavior is actually annoying. Most of these are plain text editor, and they have no option but to use the heuristic since plain text has no way to store paragraph direction. Calligra Words is not very different from Writer, it has explicit paragraph direction setting, but if you didn’t explicitly set it it will use the heuristic. Not sure what I feel about this, seems a bit surprising but I’m a UX expert, and it sounds like a valid improvement request if someone wants to open an issue on the bug tracker. > Secondly, you seem to be assuming that paragraphs run in just one > direction > or another. For certain use cases, that's reasonable, of course, but as a > general rule, that is entirely too limiting. (Think of translators, > literary, morphological, and etymological analyses, and so forth). That is how the Unicode Bidirectional Algorithm works, there need to be a paragraph (base) direction, whether it is set explicitly or auto-detected using a heuristic or another. For embdded text that need a different base direction than the parent paragraph, you have to resort to control characters (LRE, RLE, FSI, etc). > Far and away the most annoying aspect of this is when initially entering > an > RTL phrase of more than one word in an otherwise LTR paragraph. Having the > cursor jump to the right as each space (a non-directional or "neutral" as > Annex 9 calls it) between each RTL word is entered is fun to watch, but > certainly not what a typical user would expect. That is how bidi works, the space at the end of the paragraph will take the paragraph direction and be LTR, until you insert another RTL character. If you know any application that does better here, or have a concrete suggestion how to improve the situation, please share it (preferably on the bug tracker). > Annex 9 does not specify this (although I've read some postings suggesting > it does). The relevant section says “Generally, NIs [i.e. neutral and > isolate formatting characters] take on the direction of the surrounding > text. In case of a conflict, they take on the embedding direction.” But, > if > the user hasn't yet entered any character beyond the space, there is no > SURROUNDING text - there is only PRECEDING text. The cursor should stay > just > where it is unless and until the user enters another LTR character. Of > course this doesn't take into account very unusual needs (where the > isolate > formatting characters are needed), but for typical text entry, this is the > most common use case for mixing bidirectional text in a single paragraph. If there is no surrounding text, it is taking the paragraph direction which is LTR here. How do you know that the user is going to insert new text, may be his paragraph just ended? > The original poster also mentioned his struggle with placing the period at > the end of a sentence; in a normally LTR paragraph containing > bidirectional > text that ENDS WITH the non-default directionality I could almost hear him > screaming as it took me ages to figure out how to overcome that in Writer, > but it seems that interpreting "surrounding" is the culprit here as well. Please give a concrete example, I’m unable to follow you here. > I'm not sure if you've ever explained to a non-technical translator how to > insert a zero-width character before, but it can turn into a fascinating > conversation - I'd like to see Writer (and, to be fair) many other apps a > bit more intuitive to use in such cases. As a matter of fact I did, plenty of times. Being a software localizer myself I use bidi control characters all the time, and have explained them to many localizer over the years and they seem to grasp the concept quickly and appreciate it. > Are you, by the way, the "HarfBuzz" Khaled Hosny, or is that a different > person? I do contribute occasionally to HarfBuzz. Regards, Khaled -- View this message in context: http://nabble.documentfoundation.org/Struggling-with-Hebrew-in-LO-tp4198211p4202396.html Sent from the Users mailing list archive at Nabble.com. -- To unsubscribe e-mail to: [email protected] Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/users/ All messages sent to this list will be publicly archived and cannot be deleted
