I was working on creating a reasonably smart parser for eastern languages Arabic, Persian (Farsi) - which have are right to left and depending on the position of the letter in the word, the letter forms change, and are included in Unicode fonts.

My initial direction was to try to figure out the SDK from Jinke and try and write a new parser for Arabic using epub.

The second thing i did was study the code of nano-x (http://www.microwindows.org/) which is a lightweight X server which can run on appliance to find out if I can enable the Arabic support right from there. There is a viewer in nano-x which seems quite capable.

However as I am getting to know openinkpot more and more now I am wondering if a better approach is to go ahead with this project.

Do you have any pointers to give me? Does openinkpot support Arabic intrinsically?

Why do you need a parser? If the right Unicode character/glyph are used, all you need is pick it from the font, dont you? (and maybe switch between left-to-right and right-to-left rendering).

I was working on creating a reasonably smart parser for eastern languages Arabic, Persian (Farsi) - which have are right to left and depending on the position of the letter in the word, the letter forms change, and are included in Unicode fonts.


Not sure what you're trying to achieve. Pango already should support complex scripts rendering, and if it is not, then it's better to work with Pango developers directly to implement it.

Probably some OI UI is not RTL-aware, and this may be fixed if you point out what need to be fixed.

Are OI readers pango enabled?

FBreader uses Pango to output text, IIRC. Though it need to be double-checked

I've rewritten the rendering part of FBReader using only freetype2, because pango was too slow. Right now RTL languages are not supported. However, I've tried to add RTL rendering and I was able to read hebrew (without nekudot). But it's much harder to render arabic.

So one has to do what is done in Pango using freetype2 to render Arabic or you would suggest working with pango developers to create a light-weight pango enabled library for ebook readers?

Better work with Pango devs -- OI is just a one distribution amongst the horde, and pango optimizations will benefit many (including desktop users).

If you will, please keep us informed :)

I contacted Pango devs and they believed that I should profile to find where the slowness comes from, could you please let me know where to tweak in OI to enable Pango support to start debugging the slow performance.

Kdrive as OI X windows system seem to pose some problems rendering complex scripts, have you considered an alternative?

Oh SHIT.

NO, WE DID NOT CONSIDER SWITCHING, BECAUSE THIS F**KING X SERVER HAS NOTHING TO DO WITH FONT RENDERING.

And I hate explaining it AGAIN and AGAIN.

It's in the FBReader: zlibrary/ui/src/ewl/view/ZLEwlPaintContext.cpp.
You can compare it with gtk backend: zlibrary/ui/src/gtk/view/ZLGtkPaintContext.cpp

Really sorry to upset you, And thanks for the pointer for tweaking FBReader.

Ok, apologies accepted :)

Regarding pango speed - it's also possible to build some pango examples and run'em on device to test the speed.

ali_sade, here is a simple RTL patch for FBReader: http://users.openinkpot.org/~lunohod/fbreader-rtl.patch

The stringWidth function compiles with success with changed to Pango version but drawString does not:

ZLEwlPaintContext.cpp: In member function 'virtual void ZLEwlPaintContext::drawString(int, int, const char*, int, bool)':
ZLEwlPaintContext.cpp:303: error: no match for 'operator=' in '*(((ZLEwlPaintContext*)this)->ZLEwlPaintContext::image + ((unsigned int)(((unsigned int)((x + k) + (((y - i) + ((ZLEwlPaintContext*)this)->ZLEwlPaintContext::myDescent) * ((ZLEwlPaintContext*)this)->ZLEwlPaintContext::myWidth))) * 40u))) = ((((((int)val) << 16) | -0x00000000001000000) | (((int)val) << 8)) | ((int)val))'
/usr/arm-ip-linux-gnueabi/include/xcb/xcb_image.h:93: note: candidates are: xcb_image_t& xcb_image_t :: operator=(const xcb_image_t&)

Can you help please?

Thanks to LunohoD for http://www.dumpz.org/8310/, it compiles fine now,
Thanks