[
https://issues.apache.org/jira/browse/PDFBOX-3674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15999957#comment-15999957
]
Andreas Lehmkühler commented on PDFBOX-3674:
--------------------------------------------
The following code is suspicous
{code}
// We only normalize if the codepoint is in a given range.
// Otherwise, NFKC converts too many things that would cause
// confusion. For example, it converts the micro symbol in
// extended Latin to the value in the Greek script. We normalize
// the Unicode Alphabetic and Arabic A&B Presentation forms.
char c = word.charAt(q);
if (0xFB00 <= c && c <= 0xFDFF || 0xFE70 <= c && c <= 0xFEFF)
{code}
The comment is about ranges, but the if clause doesn't work that way. It should
be as follows
{code}
if ((0xFB00 <= c && c <= 0xFDFF) || (0xFE70 <= c && c <= 0xFEFF))
{code}
Can someone please double check if this is ok. At least the linked TIKA pdf is
correct now
> Incorrect ordering of fatha -- potentially indicative of larger issue with RTL
> ------------------------------------------------------------------------------
>
> Key: PDFBOX-3674
> URL: https://issues.apache.org/jira/browse/PDFBOX-3674
> Project: PDFBox
> Issue Type: Bug
> Components: Text extraction
> Reporter: Tim Allison
> Assignee: Andreas Lehmkühler
> Priority: Minor
> Fix For: 2.0.6, 3.0.0
>
>
> On TIKA-2257, [~ccreutzig] shared a file that triggers PDFBox to flip the
> order of the fatha. I suspect this is happening in {{normalizeAdd}} within
> PDFTextStripper, but I'm not familiar enough with the code to diagnose and
> fix.
> I confirmed this is still happening in trunk.
> Triggering file and the start of a diagnosis is available on the Tika issue.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
