| Summary: | Document text orientation option (RTL and LTR) | ||
|---|---|---|---|
| Product: | [Applications] kate | Reporter: | peter.verkinderen |
| Component: | general | Assignee: | KWrite Developers <kwrite-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | oded, safa1996alfulaij, waqar.17a |
| Priority: | NOR | ||
| Version: | 20.12.2 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Other | ||
| Latest Commit: | https://invent.kde.org/frameworks/ktexteditor/commit/8c814351a7a6685790d3488b7e8f3a3c776af937 | Version Fixed In: | |
| Sentry Crash Report: | |||
| Attachments: | first line LTR, second line RTL | ||
NB: ideally, the line numbers should also switch to the right side if the document text direction is set to RTL. You might find it somewhat useful if you disable line wrapping. This will force everything to align to left (but won't change any direction of text.) So something like: تجربة English will show تجربة on the right and English on the left. *** Bug 461320 has been marked as a duplicate of this bug. *** A possibly relevant merge request was started @ https://invent.kde.org/frameworks/ktexteditor/-/merge_requests/537 Git commit 8c814351a7a6685790d3488b7e8f3a3c776af937 by Christoph Cullmann, on behalf of Waqar Ahmed. Committed on 06/04/2023 at 12:20. Pushed by cullmann into branch 'master'. Allow forcing RTL direction The option is available under the "View" menu. Once the option is checked, all the text is forced to the right. Having "Dynamic Word Enabled" is necessary for this to work correctly. Reason being that with static wrapping there is no "right" to which we can force the lines to, "right" is infinity/INT_MAX. Related: bug 468151 M +2 -1 src/data/katepart5ui.rc M +5 -1 src/render/katerenderer.cpp M +19 -0 src/view/kateview.cpp M +3 -0 src/view/kateview.h https://invent.kde.org/frameworks/ktexteditor/commit/8c814351a7a6685790d3488b7e8f3a3c776af937 (In reply to Christoph Cullmann from comment #5) > Having "Dynamic Word > Enabled" is necessary for this to work correctly. Reason being that > with static wrapping there is no "right" to which we can force the lines > to, "right" is infinity/INT_MAX. One might expect that in RTL document orientation, the display will simply be right to left - i.e. the start of the line will be the right side of the display and the end of the line will be the left size of the dispaly - not just an LTR display that is "text aligned to the end". So without line wrapping, the display area will simply extend to the left. That the layout is always LTR (even if your desktop is RTL) is intentional and unlikely to change. The reason being KTextEditor is a plain text editor component and a lot of plain text is LTR. Many programmers/people who use RTL languages still prefer an LTR layout when writing code or dealing with plaintext. It is like this since the last 15 years and so far I haven't seen any complaints. Well, supporting an RTL global document layout - as an option that will be only be useful to some users - is kind of what this report is all about. 😄 The issue I have is that - as part of my programming work - I sometimes need to edit simple text documents that are BiDi (and predominantly RTL with minority of strong LTR text), often with JSON formatting (or other formats that Kate is usually really good with) and doing that in Kate is a huge mess, with lines sometimes right aligned and sometimes left aligned to the point that it is too much extra effort to use Kate. My workaround is to work mostly in a bad editor (which can be as simple as an HTML textarea set with dir=RTL) and copy back and forth to Kate. I would love to ditch that workflow and use Kate exclusively by being able to view some documents with a text layout of RTL. I'm not suggesting setting the QGuiApplication.layoutDirection - in things like QTextEdit there used to be an option to set the direction layout of just the text itself, so something like that. BTW - I haven't tested the new code yet - maybe forcing right align combined with Kate's normally pretty good BiDi support will work well enough. It's just that generally treating right-aligning as replacement for true LTR layout ends pretty badly, and personally I almost always work with word wrapping disabled. Its not right aligned, the start of the line will be on the right. Just the UI layout will still be LTR i.e., the line number area will be on the left side and the scrollbar on the right. And yes, with static wrapping it won't work because of the reason mentioned in the commit. > Its not right aligned, the start of the line will be on the right.
Its right aligned + text direction forced to be RTL
So it will be RTL for LTR text as well (which as you might guess will be annoying).
(In reply to Waqar Ahmed from comment #11) > > Its not right aligned, the start of the line will be on the right. > > Its right aligned + text direction forced to be RTL > > So it will be RTL for LTR text as well (which as you might guess will be > annoying). I'm confused. I guess I'll have to checkout the code, tomorrow probably. Thanks! 🙏 |
Created attachment 136349 [details] first line LTR, second line RTL SUMMARY One of the things I really like about Kate is how well it deals with RTL (right-to-left) scripts. The only downside is that Kate does not allow to set the text orientation for an entire document to either RTL or LTR. Rather, it depends on the first character in a line to decide whether that line should be displayed RTL or LTR. While this is often a good solution, in documents which contain both RTL and LTR text, this has the irritating effect that some lines start on the right side of the screen and others on the left. This is not always desirable, for example, if you have a document in which the main body of text is written in a RTL language but contains markup tags in ASCII characters. Having an option to fix the text direction for the entire document (LTR, RTL or dynamic) would be a big improvement. Inserting directionality characters in the text should not be considered an option. STEPS TO REPRODUCE 1. Write a line that starts with a tag consisting of ASCII characters, followed by Arabic text (e.g., "<p>هذه كلمات عربية") 2. Write a line that starts with Arabic text ("كما أن هذه كلمات عربية") OBSERVED RESULT The first line will run from left to right, the second line from right to left EXPECTED RESULT Both lines RTL SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION