Date: prev next · Thread: first prev next last
2016 Archives by date, by thread · List index


Khaled:

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.

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.”

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 ...

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.

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).

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.

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.

As a further comment on "No jumping would happen if the paragraph has RTL
direction." The same distracting behavior will occur in the opposite
direction if an LTR segment is entered into a RTL paragraph. (except when
numeric digits are entered, which are mostly LTR even with RTL languages;
they seem to be handled independently of other characters in most
implementations - but again, that's a distraction from this particular
thread).

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.
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.

Editing text in bidirectional paragraphs is a bit different, of course,
since the settled layout needs to be disrupted, but the issues there are a
bit more involved than entry, so I'll leave well enough alone for the
moment.

But thanks for responding; it's good to know that some attention is being
bestowed on those (apparently very) few of us who type such things.

Are you, by the way, the "HarfBuzz" Khaled Hosny, or is that a different
person?

-Frank



--
View this message in context: 
http://nabble.documentfoundation.org/Struggling-with-Hebrew-in-LO-tp4198211p4202315.html
Sent from the Users mailing list archive at Nabble.com.

-- 
To unsubscribe e-mail to: users+unsubscribe@global.libreoffice.org
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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: 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.