While I was coding my first “not-so-large” java program I got a phone call from my collegue in linux-plus ‘Ahmed Kamal’, he said to me that they are doing a major migration project from windows to Linux in some company that uses Oracle eBusiness Suite. They had everything done except for one thing.

The version of the Oracle eBusiness suite they are using exports the reports to “pdf” which contains encoded arabic characters in ISO8859-6 (old) encoding, and it can’t be read correctly unless you open it using Acrobat Reader 3 on windows (which is very old) and for some reason, all the pdf viewers in linux and the recent versions of Acrobat Reader cannot decode the arabic content!. they tried to convert the encoding of the pdf file into unicode *utf-8* and I tried too with complete failure, so they told me that they decided to run “wine” under linux and run acrobat Reader 3.0 to open the file correctly under linux.

Actually running a pretty old version of Acrobat Reader wasn’t a problem to ‘wine’ but the real problem happened when I tried to open the pdf file generated by the Oracle eBusiness suite with a surprise that arabic encoding was read incorrectly thus having a characters looking like this

so we had to find a way to reorder the text and choose the correct glyph for each arabic letter which is called “arabic shaping”, we got help from a wine developer who had a patch for this using libicu which we used to fix the arabic problems, but it was a hard way to apply this patch correctly and make things get to be like this:

but as you can see the characters are sometimes overlapped and very far away sometime, we asked for help from wine developers with no answer so I tried to hack the wine code to calculate the correct width and spacing of characters.

we got a message from a wine developer stating that this issue is related to “freetype.c” which is responsible for decoding the freetype fonts and I spent about 8 hours trying to understand the code anatomy in this file and finally decided to leave this source file as it’s not related to the situation we are having here, I found that “font.c” is the one deciding the box width to have a character drawn inside, so I played with this simple calculation to get something like this:

as you can see, the result is pretty better but I noticed that the spaces between characters are not equal, this means that he is calculating the wrong glyph width so virtually there should be a glyph inside this area but the actual glyph that is drawn is larger or smaller, so gotcha I had to calculate the width again and override this behaviour, after many hacks I got an idea to use “deltas”, those deltas are values to be added or subtracted to the currently calculated width and add a number which is positive or negative dynamically to fix the width problem. after trying this technique I got a result like this:

Congratulations man, we got to the point as we are having here a constant spaced characters, so this technique is working but it seems that it needs more tweaking, so after additional effort to calculate the deltas correctly, I got this result:

Congratulations arabic is shaped and written in its best way After this tweak I discovered that arabic wasn’t shown that pretty on windows the alignment was incorrect while running Acrobat Reader 3 under windows, the thing which made me quite happy