In LibreOffice Writer:
I applied a Border character style to the string “8(a)”.
It appears good in Left-To-Right mode.
But in Right-To-Left mode it is corrupted.
Attached screenshot for Left-To-Right:
Attached screenshot for Right-To-Left:
Please provide a sample file. Mention OS name, exact LO version and save format.
I suspect that your sequence of characters is “mixed”, i.e. containing both intrinsically LTR and RTL characters.
Found a workaround with Paragraph style:
The new paragraph style:
This workaround allows to also use macros.
I hope I won’t encounter any issue with it.
Is it possible for the team to debug this issue without uploading a file?
The reproduction is very easy (as described in my post).
I simply applied RTL to the string “8(a)”.
We are not the “development team”, only users like you devoting our time to help others. Our main goal is to discriminate between user misuse of features and real bugs.
Unfortunately no.
There are so many factors, such as the choice of the font or the exact encoding of the sequence, that it is musch better that you provide a document you know is faulty.
An important information is your LO version number under which OS (there are subtle and not-so-subtle differences between platforms and releases).
EDIT: I reproduced the problem and I think I understand what happens.
Your test string is “8(a)”. Scanning it right to left would give “)a(8” but the parentheses have now the wrong orientation. To avoid this, Unicode has given special attributes to parentheses (something like “writing-direction-neutral”). Consequently the string is split into 4 bits:
which results into 4 bits instead of a single one with writing direction change in each bit. Each bit is painted separately. Since there is no “merge border with next character” attribute in character styles, you get the borders around each bit.
I think this is not the first time this kind of issue is reported in RTL context.
Thank you for the elaborated reply.
Sounds like you found the reason to this issue.
I’d like to promote a solution to this (for sometime in the future).
Where do I contact with development team to report about this issue?
On TDF Bugzilla. File a bug report with ENHANCEMENT or FEATURE REQUEST as first word in the title. Be as descriptive as possible, something looking like a specification.
When done, report the bug number here in a comment as tdf#<bug_number>.
These aren’t automatic numbering but manual numbering I guess otherwise the 8 would be inside the parentheses as far as I can discover.
Consider automatic list numbering/heading numbering if you are creating a list, you wont get the border around the list number though. There are other ways to make lists stand out, indentation, boldness, colour
If it is manually entered and it is at the beginning of a line, you could abuse the inline heading feature.
ManuallyNumberedListBorderRtoL.odt (10.0 KB)
In the sample, select (b)8 and press Ctrl+0
I tried to elaborate on @EarnestAl’s idea about list numbering but it failed again on borders. So, please, give more details about your “8(a)”. It looks legal some legal numbering, but is it so? What is your usage of this kind of string?
I think there is a fundamental flaw in Writer RTL approach. Coordinate origin seems to stay at left while IMHO everything should be mirrored (even in the UI when the context is explicitly RTL). Writing mixed text is conceptually even more complex.
Taking the example of parentheses, Unicode name them LEFT … and RIGHT … which is geometrically exact. But when you write, you think of them as “opening” and “closing” delimiters. Hence the shape should be mirrored in RTL.
I leave aside specialised usages such as mathematics where these symbols are not necessarily “opening” and “closing” delimiters (e.g. ] a, b ] is used in some countries to denote an interval open on a-side and closed on b-side; this is beyond common text manipulation).