- Status Closed
- Percent Complete
- Task Type Bugs
- Category User Interface
-
Assigned To
tomers - Operating System All players
- Severity Low
- Priority Very Low
- Reported Version Daily build (which?)
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
FS#10670 - The first letter of a scrolling line starts to appear at the end of the line
Somewhere between r23021-091009 and r23059-091009 (the narrowest range I am able to investigate via daily builds), scrolling lines of text began to exhibit a bug where a fragment of the line’s first letter appears at the end of the line.
For instance, a line will scroll to display text like the following:
A Line of Text is Scrolling in This Example/
…where the “/” at the end is the beginning of the first letter “A”.
This behavior is consistent throughout the system, in the menus as well as in the WPS’, and it continues to exist as of r23091-091011. My suspicion, from looking at the change log for that period, is that this bug is in some way related to the commits involving RTL implementation, but I unfortunately lack the expertise to confirm that.
2009-10-12 16:33
Reason for closing: Accepted
Additional comments about closing: Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407
Fixed in r23132
Thanks Teruaki Kawashima (teru) for the
solution!
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
It is most probably related to r23021 - “Handle text scrolling in RTL”
While r23021 had its own issues (i.e. text turning to gibberish characters on the return scroll) that have since been fixed, the text-wrapping bug described above was not yet present in it…so I have to believe a later revision (perhaps even the very next one) is the cause of this particular problem.
r23022 deals with bi-directional scrolling specifically, and it is during bi-directional scrolling that this bug presents itself…so perhaps that’s worth a look?
[r23022: “Fix a bug in a bidirectional text scrolling; s→offset doesn’t need to be set when backward scrolling starts. This fixes bidirectional scrolling in
RTL and for certain file-names in LTR.”]
Yes the problem is with 23022. Apparently it happens to certain file names only (at least what I get here) so probably why I missed it.
Could you try this patch ( reverts r23022) and see if it fixes the problem ?
An idea of fix. this revrets r23021 and r23022, and adds offset handling to depper function.
This should fix the issue but may affect other non-scrolling putses with offset.
It also fixes wrong selecter drawing.
Fix patch. Obviously does not fix this issue yet (RTL mode - Hebrew, file viewer, long English folder name)
Well, I’m now noticing that – somewhere between r23111-091011 and the current build (r23121-091011) – the bi-directional text-wrapping bug has been replaced with a different one; on the return scroll, the beginning of a line of text now turns to gibberish characters and then the line jumps back to the end. Incidentally, this same behavior was happening with r23021 (which predates the bi-directional text-wrapping bug).
I assume r23118 (”Revert r23021, since it broke non-RTL scrolling. RTL scrolling still needs fixing”) is the culprit? Should I start a separate bug report for this?
woops, sorry. somehow my previous patch doesn’t included reverting r23022.
this is correct and updated one. almost equivalent to tomers’ one as reverting r23022 is done in r23118.
lcd-bitmap-common.2.patch fixes the bi-directional scrolling problem described by David Thacker (introduced in r23118). I have not seen the original problem reported by David, so I can’t comment on whether or not it has been fixed.