[Libreoffice-ux-advise] [Bug 92657] Questionable Default for Bullet Sizing

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=92657

--- Comment #29 from Frank <foberle at enteract.com> ---
(In reply to Khaled Hosny from comment #21)

** I must have posted this to the wrong place, as it isn't showing below: it's
an earlier response I had posted.

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.