- Status Closed
- Percent Complete
- Task Type Patches
- Category LCD
- Assigned To No-one
- Operating System
- Severity Low
- Priority Very Low
- Reported Version Unstable (example)
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
FS#1574 - hebrew: correctly display hebrew from right to left
see comments in related e-mail on the mailing list
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
This patch introduces a compile time option which will
correctly display hebrew text, from right-to-left, from
inside of rockbox. It is emplemented on an ‘OS’ level,
meaning any text displayed through the firmware will be
affected (including directly display, wps and text file
viewer). [Read on for more technical info.]
This was mostly a quick hack, using some Hebrew code I found
(and modded) in BitchX by crisk. Using the Unicode BiDi
algorythm on an application level seemed a bit of an
overkill, especially since we have no need for
logical-to-visual mapping for cut and paste, or vice versa.
Ideally we might have wanted a right-to-left interface /
‘document direction’, but for me this patch is more than
adequate.
The code affects any text with an ASCII value between 224
and 250 (according to ISO8859-8, the encoding generally used
in Hebrew filesystems) but the macros could probably be
modified very easily to include Arabic characters aswell.
Only major problem: on my rockbox, whenever the scrolling
algorythm is called, I get some junk appearing on the 2nd
last column of all non scrolling lines. This does not happen
in the UI simulator. My main change is a “str =
hebrew_process(str)” in lcd_putsxyofs, and it seems the
problem only manifests itself when s→offset > 0. Maybe
someone familiar with the LCD code can comment. Nevertheless
despite this oddity the code seems_ stable and I’ve been
quite enjoying it.
Only other cause for attention: I wasn’t sure how big to
make the buffers, so set some fairly arbitary values. This
should probably be something like sizeof(scrollinfo→line)
but I thought I’d leave this to someone who is actually sure
what kind of data gets pumped into the putsxyofs routine.