| Summary: | Cursor movement in Telugu language | ||
|---|---|---|---|
| Product: | [Applications] konsole | Reporter: | Venkat Akkineni <venkatram.akkineni> |
| Component: | font | Assignee: | Konsole Developer <konsole-devel> |
| Status: | CONFIRMED --- | ||
| Severity: | major | CC: | karunakar, kishore96, sebastian.englbrecht, venkatram.akkineni |
| Priority: | NOR | Keywords: | investigated, triaged |
| Version: | 17.12.3 | ||
| Target Milestone: | --- | ||
| Platform: | Mint (Ubuntu based) | ||
| OS: | Linux | ||
| URL: | https://www.youtube.com/watch?v=f7wJoVW4d2o&feature=youtu.be | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Venkat Akkineni
2014-09-21 04:53:32 UTC
*** Bug 339261 has been marked as a duplicate of this bug. *** *** Bug 339258 has been marked as a duplicate of this bug. *** *** Bug 339259 has been marked as a duplicate of this bug. *** *** Bug 339260 has been marked as a duplicate of this bug. *** Seems like this issue was discussed as far back as 2003 on KDE. "Cursor movement for Indic languages should be restricted to syllable boundaries. " This is the way it should be done. http://lists.kde.org/?l=koffice&m=104867659132606&w=2 How does xterm handle this? From how I understand terminals, the decision how to move the cursor is made by the underlying application (libreadline in the case of bash). This is not handled in any terminal. The underlying application has no knowledge that it needs to consider conjuncts/syllables. So either each application needs to have that knowledge, or it can be fixed in terminal emulator, but that breaks its semantics. This need support as done in here. http://foss.coep.org.in/fosslab/Indian-Language-support-in-gnome-terminal.pdf the hack never got into main vte (used by gnome-terminal) Note: I am no maintainer but from the bugsquad. So how do we progress in this case? I guess it is hard to fix for most non-indian people (or people who do not use those sylabies) as they would need to firstly understand the semantics correctly. As I do not speed the language at all, is it beneficial to _not_ jump over the conjunctions or is it more convenient? System Information: konsole 17.12.3 kde-plasma-version: 5.12.6 kde-frameworks-version: 5.44.0 qt-version: 5.9.5 I think it is unfair if not unrealistic to expect non-speakers to deal with this. I opened this bug to help in tracking and as an expression of my inability to code in C++. You could ask me what I have been doing for the past four years. I'd tell you I haven't learned C++. Having no formal training in programming my feelings towards C++ are a mixture of dread and awe. There is no dearth of C++ programmers who are native Telugu speakers however. I was hoping one of them would pick it up. I don't understand it completely and I could be off by quite a bit but I think the issue is with the with the way terminal emulators display characters. i.e. as monospaced blocks. And most indic scripts aren't monospaced and aren't single characters but are combinations of various character which represent various sounds. I've read somewhere that emulators behave this way because of the underlying readline library. Ex: ధ్ర is a syllable which translates to 'dhra' with a soft d. It is a combination of ధ (dha) and ర (ra). But that syllable is considered a full character in the language. i.e. it should behave as a single character. The characters and words become unreadable when cursor doesn't jump over the conjunctions. There are other issues as well. While typing the cursor movement isn't proportional to the character width. i.e. cursor doesn't always remain at the end of the typed string. The space between end of the typed string and cursor position increases as more characters are typed. I think only mlterm claims to be able to display Indian characters. Having said all that if it is possible to keep this open so someone who has the knowledge of both C++ and Telugu comes along and takes a closer look at this and concludes whether or not this is fixable with current Konsole setup, it would be nice. |