Version: 0.5.2 (using KDE 3.5.2-6 Red Hat, Red Hat Linux (Bordeaux)) Compiler: Target: i386-redhat-linux OS: Linux (i686) release 2.6.16-1.2080_2.rhfc5.cubbi_suspend2 typing Hebrew words in the quick search bar returns pages that contain reverse order letters of the searched word. example (in English): search for FOOD returns pages with DOOF in them. the Hebrew language has a Visual and Standard font encoding which reverse order the word's letters in a document. maybe it's searching a document without regarding the doc's encoding. not sure, thu. here is a link to an Hebrew PDF sample doc: http://www.sviva.gov.il/Enviroment/Static/Binaries/Articals/recycle_list_1.pdf kindly, nadav :-)
PDF has no such thing as encoding. There's just "a bunch of glyphs" positioned somewhere in the page. If the document was written backwards without regards for directionality of the flow, it's the document creator's fault. It could happen to LTR languages as well. However, Copy & Paste from the document yielded proper text, so it at least looks like to be respecting the flow.
thanks for the info. (you open my eyes) i think we should close this issue.
Considering Copy & Paste worked, let's wait for Albert to take a look.
Give me some time, things are sidetracking me lately
Seems we should revert the string we pass to the internals in case of RTL languages, but the problem is that i do not know how to ask a qlineedit if the text it has is rtl or ltr :-(
*** Bug 125310 has been marked as a duplicate of this bug. ***
PDF stores the text in Visual Hebrew, and not Logical. This is why you need to search the text in "reverse mode". We can apply some ugly hacks (like saving the text as ISO8859-8 to get it in visual mode). Nadav, this is not something trivial.
thanks diego for clarifying this for me :-)
*** Bug 156380 has been marked as a duplicate of this bug. ***
*** Bug 165804 has been marked as a duplicate of this bug. ***
I am facing these problems with Arabic, too. I cannot search. I cannot copy and paste in a proper way. Things are reversed. It's also not a limitation in the PDF because Adobe Acrobat works great. I tested acroread in Intrepid and it works.
I can confirm this bug in Okular from KDE 4.2.2 when testing with the file provided in the OP. However, Adobe Reader 9 for Linux has the correct search behaviour when opening the same file. So at least Adobe found a workaround.
Thank you for your bug report or feature suggestion. The "KPDF" application is no longer maintained, and all tickets are now closed. We recommend to switch to the "Okular" application. Due to the high number of bugs/suggestions in "KPDF" we are not able to go through all of them and verify if they are still valid in "Okular". That's why are we asking you to help us by checking if your bug/suggestion is still valid in Okular and if it still is opening a new bug/suggestion against it. Thank you for your effort in making KDE better :) (This is an automatic message from the KDE bug triaging team)