Odczytaj plik PDF za pomocą itextsharp, gdzie język PDF jest inny niż angielski

Question

Próbuję przeczytać this PDF, używając itextsharp w języku C#, który przekonwertuje ten plik PDF na plik Word. również musi utrzymywać formatowanie tabeli i czcionki w słowie , gdy próbuję z angielskim pdf będzie działać idealnie, ale przy użyciu niektórych języków indyjskich, takich jak hindi, marathi to nie działa.

public string ReadPdfFile(string Filename) 
     { 

      string strText = string.Empty; 
      StringBuilder text = new StringBuilder(); 
      try 
      { 
       PdfReader reader = new PdfReader((string)Filename); 
       if (File.Exists(Filename)) 
       { 
        PdfReader pdfReader = new PdfReader(Filename); 

        for (int page = 1; page <= pdfReader.NumberOfPages; page++) 
        {      ITextExtractionStrategy strategy = new SimpleTextExtractionStrategy(); 
         string currentText = PdfTextExtractor.GetTextFromPage(pdfReader, page, strategy); 

         text.Append(currentText); 
         pdfReader.Close(); 
        } 
       } 
      } 
      catch (Exception ex) 
      { 
       MessageBox.Show(ex.Message); 
      } 
      textBox1.Text = text.ToString(); 
      return text.ToString(); ; 
     } 

Answer 1

Sprawdziłem twój plik ze szczególnym uwzględnieniem próbki "मतद | र" wyodrębnionej jako "मतदरर" w najwyższym wierszu stron dokumentu.

W skrócie:

Twój sam dokument zawiera informację, że na przykład glify "मतद | र" w linii nagłówka reprezentują tekst "मतदरर". Powinieneś zapytać źródło swojego dokumentu o wersję dokumentu, w której informacje o czcionce nie wprowadzają w błąd. Jeśli nie jest to możliwe, powinieneś wybrać OCR.

w szczegółach:

Górna linia pierwszej stronie jest wytwarzany za pomocą następujących operacji w strumieniu zawartości strony:

/9 280 Tf 
(-12"!%$"234%56*5) Tj 

Pierwsza linia wybiera czcionki nazwie /9 o wielkości 280 (operacja na początku strony skaluje wszystko o współczynnik 0,05, a więc efektywny rozmiar to 14 jednostek, które obserwujesz w pliku).

Druga linia powoduje drukowanie glifów. Glify te są przywoływane pomiędzy nawiasami za pomocą niestandardowego kodowania tej czcionki.

Gdy program próbuje wyodrębnić tekst, musi wywnioskować rzeczywiste znaki z tych odniesień glifów, używając informacji z czcionki.

Czcionka /9 na pierwszej stronie PDF jest definiowana za pomocą tych obiektów:

242 0 obj<< 
    /Type/Font/Name/9/BaseFont 243 0 R/FirstChar 33/LastChar 94 
    /Subtype/TrueType/ToUnicode 244 0 R/FontDescriptor 247 0 R/Widths 248 0 R>> 
endobj 
243 0 obj/CDAC-GISTSurekh-Bold+0 
endobj 
247 0 obj<< 
    /Type/FontDescriptor/FontFile2 245 0 R/FontBBox 246 0 R/FontName 243 0 R 
    /Flags 4/MissingWidth 946/StemV 0/StemH 0/CapHeight 500/XHeight 0 
    /Ascent 1050/Descent -400/Leading 0/MaxWidth 1892/AvgWidth 946/ItalicAngle 0>> 
endobj 

więc nie ma /Kodowanie elementem, ale przynajmniej jest to odniesienie do /ToUnicode mapę. W związku z tym program wyodrębniający tekst musi opierać się na danym mapowaniu /ToUnicode.

strumienia wskazywanego przez /ToUnicode zawiera następujące mapowania interesów podczas wydobywania tekstu z (-12 234% 56 * 5 "% $!"):

<21> <21> <0930> 
<22> <22> <0930> 
<24> <24> <091c> 
<25> <25> <0020> 
<2a> <2a> <0031> 
<2d> <2d> <092e> 
<31> <31> <0924> 
<32> <32> <0926> 
<33> <33> <0926> 
<34> <34> <002c> 
<35> <35> <0032> 
<36> <36> <0030> 

(Już tutaj można zobaczyć, że wiele charakter kody są przypisane do tego samego punktu kodu Unicode ...)

Zatem wydobycie tekst musi skutkować:

- = 0x2d -> 0x092e = म 
1 = 0x31 -> 0x0924 = त 
2 = 0x32 -> 0x0926 = द 
" = 0x22 -> 0x0930 = र instead of | 
! = 0x21 -> 0x0930 = र 
% = 0x25 -> 0x0020 = 
$ = 0x24 -> 0x091c = ज 
" = 0x22 -> 0x0930 = र 
2 = 0x32 -> 0x0926 = द 
3 = 0x33 -> 0x0926 = द 
4 = 0x34 -> 0x002c = , 
% = 0x25 -> 0x0020 = 
5 = 0x35 -> 0x0032 = 2 
6 = 0x36 -> 0x0030 = 0 
* = 0x2a -> 0x0031 = 1 
5 = 0x35 -> 0x0032 = 2 

Zatem tekst Wyrażenie iTextSharp (a także Adobe Reader!) z nagłówka na pierwszej stronie dokumentu jest dokładnie tym, co dokument w informacjach o czcionce jest poprawny.

Przyczyną tego jest myląca informacja o odwzorowaniu w definicji czcionki, dlatego nie należy się dziwić, że w całym tekście występują błędne interpretacje.

Answer 2

Jak powiedział @mkl, potrzebujemy więcej informacji, dlaczego rzeczy nie działają. Ale mogę ci powiedzieć kilka rzeczy, które mogą ci pomóc.

Najpierw SimpleTextExtractionStrategy jest bardzo prosty. Jeśli read the docs za to zobaczysz, że:

Jeżeli PDF renderuje tekst w sposób non-top do dołu, spowoduje to tekst nie jest prawdziwa reprezentacja jak wydaje się w PDF

Co oznacza, że ​​chociaż plik PDF może wyglądać tak, jak powinien być czytany od góry do dołu, może być napisany w innej kolejności. Plik PDF, do którego się odwołujesz, ma najpierw drugą linię wizualną. Zobacz mój post here for a slightly smarter text extraction strategy, który próbuje zwrócić tekst od góry do dołu. Kiedy uruchomię mój kod na pierwszej stronie twojego pliku PDF, wydaje się, że poprawnie usuwa on każdą "linię".

Po drugie, pliki PDF nie mają koncepcji tabel. Oni po prostu mają tekst i linie narysowane w pewnych miejscach i żadne z nich nie są ze sobą powiązane. Oznacza to, że musisz obliczyć każdą linię i zbudować własną koncepcję stołu, nie znajdziesz żadnego kodu w iTextSharp, który robi to za ciebie. Osobiście nawet nie zawracałbym sobie głowy pisaniem.

Po trzecie, ekstrakcja tekstu służy do wyciągania tekstu, który nie ma nic wspólnego z czcionkami. Jeśli chcesz, musisz zbudować tę logikę w sobie. Zobacz mój post here dla bardzo podstawowego początku.