Re: "paragraph direction and alignment are two different things." Certainly
true (and, from many discussions here and elsewhere, it's obvious to me
anyone who cares about such things already knows this as well) but, I
misses the primary point, which is to eliminate a bizarre and confusing
I don’t think there is anything bizarre or confusing about this user
(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
First off, I'm basing my own opinions on the idea that following the
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
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,
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
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
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
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
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
sure what I feel about this, seems a bit surprising but I’m a UX expert, and
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
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
a heuristic or another. For embdded text that need a different base
than the parent paragraph, you have to resort to control characters (LRE,
Far and away the most annoying aspect of this is when initially entering
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
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,
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
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
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
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
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
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
Are you, by the way, the "HarfBuzz" Khaled Hosny, or is that a different
I do contribute occasionally to HarfBuzz.
View this message in context:
Sent from the Users mailing list archive at Nabble.com.
To unsubscribe e-mail to: firstname.lastname@example.org
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
Re: [libreoffice-users] Struggling with Hebrew in LO · Dotan Cohen
- Re: [libreoffice-users] Re: Struggling with Hebrew in LO (continued)
Impressum (Legal Info)
: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (MPLv2
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our trademark policy