Przestań parsuć pliki PDF w czasie renderowania
Większość narzędzi frontendowych do ekstrakcji PDF zawodzi.
Programiści próbują zgadywać strukturę dokumentu na podstawie wizualnego wyniku. Analizują wyrenderowane piksele, aby znaleźć kolumny, tabele lub listy. Wykorzystują wizję komputerową lub bliskość pikseli, aby zdecydować, gdzie zaczyna się ramka.
To błędne podejście do budowy.
Plik PDF zawiera już jawne dane strukturalne w swoim strumieniu operatorów (operator stream). Tabela to nie tylko grupa sąsiadujących pikseli. Jest ona rysowana za pomocą konkretnych poleceń, takich jak moveTo, lineTo czy rectangle. Granice, których chcesz poszukać, są już zakodowane w źródle.
Jeśli Twój ekstraktor zwraca inne kolumny przy powiększeniu 100% niż przy 150%, to nie wyciągasz struktury. Dopasowujesz wzorce do artefaktów wizualnych.
Przestań używać heurystyk wizualnych. Zacznij parsuć strumień operatorów.
Dlaczego strumień operatorów jest lepszy:
- Jest deterministyczny. Działa tak samo, niezależnie od skali czy hintingu czcionek.
- Wykorzystuje rzeczywiste dane. Używasz faktycznych ścieżek i współrzędnych zdefiniowanych przez twórcę.
- Unika błędów matematycznych. Na przykład używanie punktów środkowych między środkami tekstu w celu znalezienia stref prowadzi do błędów zaokrągleń. Użycie rzeczywistej górnej krawędzi ramki ograniczającej (bounding box) to jedyna poprawna metoda.
Trudna droga to właściwa droga.
Musisz zrozumieć stos CTM. Musisz śledzić stany macierzy i klasyfikować podścieżki (subpaths). Aby to opanować, musisz przeczytać specyfikację PDF i kod źródłowy.
Wymaga to większego nakładu pracy na początku. Ale działa dla każdego pliku PDF, który prześle użytkownik. Narzędzia oparte na pikselach działają tylko dla kilku plików w Twoim zestawie testowym.
Zbuduj prawdziwy ekstraktor, a nie demo.