FS#1574 - hebrew: correctly display hebrew from right to left

Attached to Project: Rockbox
Opened by Gadi Cohen (gadicohen) - Sunday, 03 August 2003, 22:42 GMT
Last edited by Gadi Cohen (gadicohen) - Wednesday, 06 August 2003, 02:11 GMT
Task Type Patches
Category LCD
Status Closed
Assigned To No-one
Operating System
Severity Low
Priority Normal
Reported Version Unstable (example)
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No


see comments in related e-mail on the mailing list
This task depends upon

Closed by  Gadi Cohen (gadicohen)
Wednesday, 06 August 2003, 02:11 GMT
Reason for closing:  
Comment by Gadi Cohen (gadicohen) - Sunday, 03 August 2003, 23:27 GMT

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

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.