I'm currently evaluating QuickPDF for using Arabic in PDFs. 

I'm able to print in the PDF char by char or unicode by unicode. 

But the problem is that languages like Arabic have ligatures and glyphs that don't have exact unicode mapping. My understanding is that they use an approach of like combining 2 or more existing unicodes to another glyph which is mostly present in the font file (.ttf).

For an illustration something like the below:
unicode1 + unicode2 = glyph1

unicode2 + unicode3 = glyph2 .. etc

My code looks like the below:
...
int fontId = DPL.AddUnicodeFont(L"Arial Unicode MS {1256}", 0, 1);

int rc = DPL.SelectFont(fontId);
DPL.DrawText(100, 600, L"تم إستلامه في");
...

the output I get via QuickPdf is basically broken into its chars:

https://www.dropbox.com/s/9v7ustqeqnvmkzq/QuickPDFOut.PNG?dl=0

the output I get via Microsoft Print to PDF is same as the input string:

https://www.dropbox.com/s/0kpunaa124mzm50/MicPrintPdfOut.PNG?dl=0

Can QuickPDF give the same output like what I'm getting via Microsoft Print to PDF?

Thanks. 

There is an 'experimental' QPDF function named DrawUniscribeText which is definitely worth a try.  Check it in the QPDF Reference Guide.  Microsoft say (Google Uniscribe API) that this is intended to improve the handling of Middle-East and Asian character sets.

I cannot test this here without changing our application, but do please report back here if it works for you, as it may help other users.  If not, this is an issue to raise with Foxit/Debenu support: here we are just users, like you.

Thanks for the response 

DrawUniscribeText() worked fine 

I'll need to still try out other Arabic strings to confirm its working fine in most of the cases. 

Even though the return from DrawUniscribeText() is 0 (The font group name was invalid or the text string contained no valid characters), its working fine in the PDF.