Android Question ESC/POS thermal printers showing incorrect Arabic characters

[Inman]

I have been using @agraham's library for ESC/POS printing for the last few months and it has worked great. Recently I got a client from the Middle East and they want to print Arabic along with English characters.

I understand that you need to set the codepage corresponding to the language you intend to use. This is the codepage manual of the printer my client uses.

https://www.bixolon.com/_upload/manual/Manual_SPP-R410_Code_Pages_english_Rev_1_00.pdf

According to the test page printed by the printer, it uses code page Windows-1256 by default, which is what is used to display Arabic characters. The data reaches the app via an HTTP request, in JSON string. This is how the Arabic string looks within the app and my client confirms this is the right form.

But when the same data is printed via the ESC/POS printer, this is how it looks.

I don't know Arabic but visually it looks different and the client confirms the same. The code used to print is this.

Printer1.WriteString2(PrintProduct(i).name,"windows-1256")

The above code prints the incorrect Arabic. I tried the following as well.

Printer1.WriteString(PrintProduct(i).name)

The above code prints just random characters so I am assuming the right way is to use WriteString2 and set the custom encoding.

Another interesting thing is that when I showed it to a friend who knows Arabic, he says while the letters printed are correct, they are in the wrong order; as in the letters are printed from Left to Right like in English but in Arabic it should be Right to Left as it is an RTL language. This is all very confusing and without the printer in hand the debug process in incredibly complicated.

So my question is, other than setting custom encoding using WriteString2, should any other parameter be set to indicate the string is in Right to Left form?

 

[Hamied Abou Hulaikah]

I tried a lot of methods and approaches, I got a headache about this, It is hard to solve!
I gone in another simple way >> use webview >> show your text/html on webview >> then webview captureimage >> print image with this library.
All my apps use this printing approach for Arabic and others.

 

[Jmu5667]

Have you tried maybe creating an image of the text first, then print the image ?

 

[Inman]

Have you tried maybe creating an image of the text first, then print the image ?

I haven't but I am worried about the complications that will arise from it. Like I need to print both English and Arabic name on the same line. So I am wondering if I will be able to align them correctly so that they look proper. Another issue is that longer sentences should wrap to the next line, which will happen automatically if it is in text.

 

[agraham]

while the letters printed are correct, they are in the wrong order;

In that case your code page selection looks correct but your generated Arabic characters seem to be left to right instead of right to left which is how Arabic is read. I don't know how you are generating the Arabic string but that is what you need to look at.

 

[Hamied Abou Hulaikah]

I haven't but I am worried about the complications that will arise from it. Like I need to print both English and Arabic name on the same line. So I am wondering if I will be able to align them correctly so that they look proper. Another issue is that longer sentences should wrap to the next line, which will happen automatically if it is in text.

- Zero complications using wevbiew captureimage.
- with loadhtml for webview you can make whatever style you want, right left inline etc .. it is html tags.
- html wrap lines automatically
- it is a solution for all languages, not just Arabic.
Just try

 

[Inman]

In that case your code page selection looks correct but your generated Arabic characters seem to be left to right instead of right to left which is how Arabic is read. I don't know how you are generating the Arabic string but that is what you need to look at.

I actually tried reversing the string before printing and that made the words right. But what happened is since it reversed the letters individually, the script was still inaccurate. My client says it broke the cursive writing style of Arabic and therefore while it might be correct alphabetically, it is still wrong visually. And it is not the fault of the printer itself, as demonstrated by the photos below.

This is a JSON string that was sent to the client as txt file. He opened it in Notepad and printed it by simply hitting the Print button from the menu.

Apparently the words came out right. Now check the same words when printed from the app.

Like the client pointed out, the individual letters seem to be broken instead of being in a joint cursive style and are therefore visually different. Perhaps @Hamied Abou Hulaikah can shed some light on this.

 

[Inman]

- Zero complications using wevbiew captureimage.
- with loadhtml for webview you can make whatever style you want, right left inline etc .. it is html tags.
- html wrap lines automatically
- it is a solution for all languages, not just Arabic.
Just try

This will be my last resort if nothing works out. But I will have to change the entire printing logic that too across multiple activities. Since the printer does seem capable of printing the correct Arabic, I am hoping some tweak will fix it finally.

 

[agraham]

the individual letters seem to be broken instead of being in a joint cursive style and are therefore visually different

I think it may be because although the printer can print the individual characters it is doing so with a fixed width font so it can never reproduce a proportionally spaced Arabic sentence.

 

[Inman]

I think it may be because although the printer can print the individual characters it is doing so with a fixed width font so it can never reproduce a proportionally spaced Arabic sentence.

But the same printer does produce the proportionally spaced Arabic sentence when printed from Windows using Notepad

 

[agraham]

Sorry - out of ideas unless the Windows printer driver has something to do with it.

 

[emexes]

it can never reproduce a proportionally spaced Arabic sentence.

not to mention that the characters change form depending on what comes before and after, like with cursive handwriting but amped up to 11

(I have a far-distant memory - ie, not this century - of helping an Egyptian programmer friend implement an Arabic paging system, including making our own EGA* Arabic characters)

* or maybe VGA