On 28/05/2024 11:34, Nyall Dawson
wrote:
Hi Micha,
Thanks for following up on this.
The few details (that are mentioned in
the issue tracker) that might help track down the
root of the problem:
1- There was no issue up to 3.28. The
reports appeared only on 3.30 and above.
2- I'm pretty sure that it occurs only
on Windows, and only Win 11. Just now checked again
on my Debian machine, with 3.36, and the problem
does not appear, and never has.
3- Somehow I think this might be a Qt
problem. Do you know if there were any Qt changes in
Win installs between 3.28 and 3.30.x?
Actually, if it works on a given platform, it's
by accident and not design 😁. There's no tests covering this
and I don't think it's been actually thought out by design.
So my questions related to high level design
decisions, like:
- should the switch to rtl layout determined by
the content of a label alone? Or is it determined by the font
choice? Or the users locale? Or should it be an explicit
choice set per layer, so that the project will appear
In my opinion, by the content alone. Not font choice since
many fonts have glyphs in both RTL and LTR languages. Not user's
locale, since a map can contain text in different RTL languages
even if the locale LANG setting is Western LTR. Not by layer,
since user's can have multiple text attributes with text in
different languages in each. In full featured word processors
there is, of course, a button to choose text directionality on a
per-paragraph level. But I don't think implementing that is
required for map labels.
identical when shared with a user using a
different locale for their qgis?
- how should mixed ltr and rtl string work?
Should users be required to manually insert rtl / ltr unicode
markers?
Traditionally that has been handled by the underlying bidi
library. All the problematic edge cases of (i.e. a period within a
string of numbers should be LTR but a period at the end of RTL
language string should be assumed to be at the end of the RTL
string), are taken care of by that library. I'm pretty sure this
was the case with <=3.28.x. I wouldn't expect users to know how
to insert RTL unicode. We just switch the keyboard language.
- how should rtl be handled with respect to
multiline text alignment?
Ideally, alignment (as opposed to RTL directionality) should be
user configurable. I believe you have already done this with the
legend that allows aligning legend items to the right or left.
But, regarding map labels, a minimalist approach would be to
always align RTL text to the right, and LTR text to the left.
(Don't let "perfect be the enemy of good")
- is rtl placement of characters determined by
graphemes? Ie do we split the string to graphemes and then lay
these out right to left? Or is it done on individual
characters?
Not sure I understand. But as above, the underlying bidi library
should be handling the cases of individual characters that might
be RTL in some cases, and LTR in others.
Cheers
Nyall
If I can be of any further help
testing, let me know. i.e. I can update a
colleague's machine, and prepare a very simple test
project...
Best, Micha
On 28/05/2024 5:56, Nyall Dawson via QGIS-User
wrote:
Hi lists,
I'm looking for some assistance in fixing the right-to-left labeling
issues described in https://github.com/qgis/QGIS/issues/54098 . While
I can fix the code issues, I don't have the linguistic understanding
to know how right-to-left text SHOULD behave in QGIS labels!
Is there anyone out there from a RTL language background who can add
the missing information to the above ticket and help get this bug
fixed?
Nyall
_______________________________________________
QGIS-User mailing list
qgis-u...@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
