Arabic text is not mapped to correct glyphs about pdf-writer HOT 13 OPEN

Ok i'll try to take a look this weekend, thanks!

from pdf-writer.

you got it just right. hummus uses a simple glyph mapping which does not take into account script arabic considerations (and then there's right to left). There was a discussion on how to resolve this in galkahana/HummusJS#56.
you can take the solution we figured from there.

from pdf-writer.

Thanks for your quick reply.

The solution pointed by @hussasad looks promising albiet it is written in Javascript. Need to figure out how to use C++ version of that.

from pdf-writer.

@nashwaan can you provide a fully working cpp sample that shows the problem, i'm back on tackling this issue.

from pdf-writer.

I'm having the same issue ,is it fixed?

from pdf-writer.

@reemshahban It's fixed on my fork but it's not been merged. If I remember correctly @galkahana said it needs to be tested on Windows before we can merge.
Would you be able to do that?

from pdf-writer.

@amrnablus I tried to test the code of your fork on Windows but had some issues with PDFWriter code itself (could not get Arabic text to show), since those issues seem to be fixed on the master code, I merged your fixTextDirection(const std::string& inText, const std::string& charset) with the code that uses fribidi only and it works as expected as you can see bellow (@amrnablus code vs original code).
Not sure if you want me to test something else.

from pdf-writer.

Looks good to me but @galkahana has some concerns on using fribidi only, would you be able to test icu as well?

from pdf-writer.

Did it now, same results, so both of them are ok.

Edit: maybe it is important to mention that I built all libraries using Visual Studio 2013 and not MinGW

from pdf-writer.

Sounds good, tbh i have no experience whatsoever with building on windows so i can't really comment, best get a review from @galkahana and then possibly merge.
Thanks @MarcoMartins86

from pdf-writer.

Hi. I'm using this code and I noticed two mem leaks in it. One is at line 65 of UnicodeTextUtils.cpp (visual_str is never freed). The other one is deeper in the C code and I didn't have the time to pinpoint it, but it seemed to have something to do with the list manipulations in fribidi-run.c.

from pdf-writer.

Ah! thanks!
Can you provide a sample code that causes the memory leak?

from pdf-writer.

Well, I can't provide a sample right now, but it seems to happen when you call the AbstractContentContext::fixTextDirection function.

from pdf-writer.