[
https://issues.apache.org/jira/browse/TIKA-3858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605576#comment-17605576
]
Tilman Hausherr commented on TIKA-3858:
---------------------------------------
The font has an incorrect /ToUnicode stream which can be found at
{{Root/Pages/Kids/[0]/Resources/Font/F7/ToUnicode}} with PDFDebugger. The
incorrect line is {{<8D> <0000>}} i.e. it maps the 8D code to 0. However the
page content stream corrects this with the {{ActualText}} feature that we don't
support
{code}
/P << /MCID 8 >> BDC
/F7 14 Tf
1 0 0 -1 64 293 Tm
(\015) Tj
9.491989 0 Td
(j) Tj
5.026001 0 Td
(>) Tj
/Span << /ActualText (ft) >> BDC
7.6019897 0 Td
(\215) Tj
EMC
9.673996 0 Td
(k) Tj
EMC
{code}
More on this in PDFBOX-4532 and PDFBOX-5155.
> Ligatures convert on text extraction
> -------------------------------------
>
> Key: TIKA-3858
> URL: https://issues.apache.org/jira/browse/TIKA-3858
> Project: Tika
> Issue Type: Bug
> Components: parser
> Affects Versions: 2.4.1
> Environment: win 8, jre 1.5
> Reporter: tom hill
> Priority: Major
> Attachments: TikaChromeInboxLigature.pdf
>
>
> It appears that the issue in TIKA-1289 is still present. Ligatures get
> replaced by a question mark.
> As a particular example, the ft ligature is getting replaced by utf-8: ef bf
> bd
> Is there any new resolution on this issue? Just returning the fl ligature
> would be great, or normalizing it to f, t.
> This particular example comes from saving my gmail inbox page as a pdf, in
> chrome. It uses the ft ligature in the word "Drafts".
> There are many similar examples, it's not specific to one pdf generator.
> I'm using tika-app-2.4.1.jar
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
