| Summary: | Western acronyms not correctly formatted in RTL context | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | ajlittoz <page74010-sf> |
| Component: | Writer | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | enhancement | CC: | dgp-mail, heiko.tietze, vsfoote |
| Priority: | medium | ||
| Version: | 6.0.6.2 release | ||
| Hardware: | All | ||
| OS: | All | ||
| See Also: | https://bugs.documentfoundation.org/show_bug.cgi?id=58434 | ||
| Whiteboard: | |||
| Crash report or crash signature: | Regression By: | ||
| Bug Depends on: | |||
| Bug Blocks: | 43808, 102345 | ||
| Attachments: |
Sample file showing the issue
The sample file with bidi control characters |
||
|
Description
ajlittoz
2018-11-05 20:02:24 UTC
Created attachment 146325 [details]
Sample file showing the issue
One-line document with a Persian sentence interspersed with C++ and C# acronyms
No matter how Defaut Style paragraph style and Technical character style are defined, acronyms are laid out as ++C and #C
Created attachment 146332 [details]
The sample file with bidi control characters
This is the intended bidirectional text layout, characters with neutral directionality follow the direction of the enclosing text (RTL here since the overall text is RTL). You can change this by using Unicode direction control characters. Enclosing the abbreviation between U+202A LEFT-TO-RIGHT EMBEDDING and U+202C POP DIRECTIONAL FORMATTING fixes the rendering. I don’t know if there is a way to automatically insert these control characters around some words.
@ajlittoz, Khaled Hosny Thanks, guys. I don't know this is a bug or not. cuz the status of this report is UNCONFIRMED still. If it is a bug, so: this is a bug like any others bugs! But if it is not and LibreOffice does not support the requirement: this is a required feature. we expect LibreOffice to do this automatically. why? because the end user doesn't care about technical reasons that are related to. A user wants to work without thinking about that. I'm a technical guy and understand this. but from a non-technical user, it is not acceptable. As an Author, currently working on my new book. and I have selected the LibreOffice word and I faced with many challenges during these days. don't understand his one. (In reply to Ali Baghernejad from comment #3) > @ajlittoz, Khaled Hosny > > Thanks, guys. > I don't know this is a bug or not. cuz the status of this report is > UNCONFIRMED still. > If it is a bug, so: > this is a bug like any others bugs! It isn’t a bug. You get the same behavior in any other application. The direction of the characters in not determined by the language, but by fixed Unicode character properties and the Unicode Bi-direction Text Algorithm (http://unicode.org/reports/tr9), which LibreOffice is complaint with. > But if it is not and LibreOffice does not support the requirement: > this is a required feature. we expect LibreOffice to do this automatically. > why? because the end user doesn't care about technical reasons that are > related to. A user wants to work without thinking about that. > I'm a technical guy and understand this. but from a non-technical user, it > is not acceptable. That is unfortunate, but I don’t see how LibreOffice would know at which side the user wants the punctuation when both options are possibly valid and the one in use now is the most common, replace the + with an exclamation mark or closing quote, would you want it to be on the right of the C? (In reply to Khaled Hosny from comment #4) > (In reply to Ali Baghernejad from comment #3) > It isn’t a bug. You get the same behavior in any other application. The > direction of the characters in not determined by the language, but by fixed > Unicode character properties and the Unicode Bi-direction Text Algorithm > (http://unicode.org/reports/tr9), which LibreOffice is complaint with. I take the point. But there is something on which LO Writer might improve. I played a bit with the sample file containing the directionality markers. There is no visual clue they are present. Worse, even when positioning the cursor where they're supposed to be, you can't delete them with Backspace or Delete. To get rid of them (to edit/tune the sequence), you must select more then need, erase and retype the extra selection. Definitely, some indication when "display formatting marks" is enabled would be more user-friendly. Something in the way NO-BREAK SPACE or soft hyphens are shown against a grey background, the same as for field content or index anchor. Should this be described in a separate feature request? Or could this NOTABUG be transformed into such a feature request? (In reply to ajlittoz from comment #5) > (In reply to Khaled Hosny from comment #4) > > (In reply to Ali Baghernejad from comment #3) > > > It isn’t a bug. You get the same behavior in any other application. The > > direction of the characters in not determined by the language, but by fixed > > Unicode character properties and the Unicode Bi-direction Text Algorithm > > (http://unicode.org/reports/tr9), which LibreOffice is complaint with. > > I take the point. But there is something on which LO Writer might improve. > > I played a bit with the sample file containing the directionality markers. > There is no visual clue they are present. Worse, even when positioning the > cursor where they're supposed to be, you can't delete them with Backspace or > Delete. > > To get rid of them (to edit/tune the sequence), you must select more then > need, erase and retype the extra selection. > > Definitely, some indication when "display formatting marks" is enabled would > be more user-friendly. Something in the way NO-BREAK SPACE or soft hyphens > are shown against a grey background, the same as for field content or index > anchor. > > Should this be described in a separate feature request? Or could this > NOTABUG be transformed into such a feature request? That is a different issue and I agree the current behavior is sub-optimal, we support making several other invisible characters visible, and we should extend that list. Please open a new issue for this (I don’t know how to make the invisible characters visible, though, but hopefully someone will know and fix it). An even simpler (and bit easier) solution is to insert left to right mark after the C++ (Insert → Formatting Mark → Left-to-right mark). It works as an invisible left to right character and fixes the issue here since there is a left to right character (the C) on the other side already. IMHO believe => WFM is the more appropriate resolution. Input is correctly handled by applying the U+200E LEFT-TO-RIGHT MARK [LRM] with Insert -> formating mark, or Alt+X toggle provides expected typographical behavior. The same Left-to-right mark/Right-to-left mark UNO commands are available to assign to menu, toolbar button, context menu, or Keyboard shortcuts. Though establishing a default keyboard shortcut _might_ be appealing for some locales. Otherwise enhancements of see also bug 58434 for showing formatting marks when displaying non-printing characters remains to be implemented, still mostly as in table of attachment 112798 [details], would improve the UX by exposing use of the Unicode control. Would be nice if the auto correction can enter the unicode characters. So typing C++ could automatically add the needed formatting. (In reply to Heiko Tietze from comment #9) > Would be nice if the auto correction can enter the unicode characters. So > typing C++ could automatically add the needed formatting. Actually auto correct can be used to do this now, as done with localized emoji, project could provide some subset of international abbreviations correctly flagged with U+200e and/or U+200f |