https://bugs.documentfoundation.org/show_bug.cgi?id=151473
--- Comment #2 from Kevin Suo <suokunl...@126.com> --- Copy pasting my comment in https://gerrit.libreoffice.org/c/core/+/141231: ''' The issue in tdf151473 is another issue, that was in the xpdfimport part (i.e. the GPL code in sdext/source/pdfimport/xpdfwrapper, which uses the third-party library "poppler" to process the pdf and yield xpdf tokens, then the tokens are passed to the sdext/source/pdfimport/wrapper and then further to sdext/source/pdfimport/tree to generate an ODF XML tree before it appears in Draw). That bug was not caused by the reverseString code in drawtreevisiting.cxx. This can be observed when you run: $ ./instdir/program/xpdfimport sdext/source/pdfimport/test/testdocs/tdf104597_textrun.pdf -f /dev/null and you get: drawChar 145.050000 709.189000 163.822000 709.189000 1.000000 0.000000 0.000000 1.000000 26.000000 A drawChar 163.822000 709.189000 181.138000 709.189000 1.000000 0.000000 0.000000 1.000000 26.000000 B drawChar 181.112000 709.189000 198.428000 709.189000 1.000000 0.000000 0.000000 1.000000 26.000000 C drawChar 198.428000 709.189000 207.086000 709.189000 1.000000 0.000000 0.000000 1.000000 26.000000 ) drawChar 207.086000 709.189000 213.586000 709.189000 1.000000 0.000000 0.000000 1.000000 26.000000 drawChar 213.586000 709.189000 232.358000 709.189000 1.000000 0.000000 0.000000 1.000000 26.000000 D drawChar 232.358000 709.189000 248.218000 709.189000 1.000000 0.000000 0.000000 1.000000 26.000000 E drawChar 248.244000 709.189000 262.700000 709.189000 1.000000 0.000000 0.000000 1.000000 26.000000 F drawChar 136.100000 709.189000 145.044000 709.189000 1.000000 0.000000 0.000000 1.000000 26.000000 ) when sorted by the 2nd column (which is the horizontal position of the character), we get: drawChar 136.100000 709.189000 145.044000 709.189000 1.000000 0.000000 0.000000 1.000000 26.000000 ) drawChar 145.050000 709.189000 163.822000 709.189000 1.000000 0.000000 0.000000 1.000000 26.000000 A drawChar 163.822000 709.189000 181.138000 709.189000 1.000000 0.000000 0.000000 1.000000 26.000000 B drawChar 181.112000 709.189000 198.428000 709.189000 1.000000 0.000000 0.000000 1.000000 26.000000 C drawChar 198.428000 709.189000 207.086000 709.189000 1.000000 0.000000 0.000000 1.000000 26.000000 ) drawChar 207.086000 709.189000 213.586000 709.189000 1.000000 0.000000 0.000000 1.000000 26.000000 drawChar 213.586000 709.189000 232.358000 709.189000 1.000000 0.000000 0.000000 1.000000 26.000000 D drawChar 232.358000 709.189000 248.218000 709.189000 1.000000 0.000000 0.000000 1.000000 26.000000 E drawChar 248.244000 709.189000 262.700000 709.189000 1.000000 0.000000 0.000000 1.000000 26.000000 F which when combined, is: ")ABC) DEF", while we expect it to be "(ABC) DEF". In other words, the tokens returned by xpdfimport is already wrong. It is also wrong even if a paragraph is set to RTL direction with pure ASCII characters with brackets. This may due to a bug in poppler, or be a bug in the sdext/source/pdfimport/xpdfwrapper wrapper codes. Thus this should be fixed separately. ''' > We're using ICU Libs BiDi for detection of RTL to trigger collection of the > run. As far as I know, we are not using ICU's BiDi in sdext/pdfimport. > But isn't this to be expected. If we have "(ABC) DEF" shown in the PDF, then we would expect "(ABC) DEF" if open it in Draw. -- You are receiving this mail because: You are the assignee for the bug.
