pavbaranov Arch

W zamierzchłych czasach narzędziem do skanowania oferowanym w ramach KDE była Kooka. O ile pamiętam, to nigdy nie ukazała się oficjalnie jej wersja dla KDE4, gdzie została zastąpiona przez skanlite. Ta pierwsza ponad skanowanie dokumentu dodawała możliwość jego rozpoznania przez jeden z trzech silników OCR. Tym samym kooka stawała się namiastką programów typu Recognita dla KDE. Namiastką, albowiem samo rozpoznawanie tekstu w linuksie, szczególnie polskiego tekstu, było bardzo ułomne. Obecnie nieco zapomnieliśmy o tej funkcjonalności komputerów i większość dokumentów jest po prostu zapisywanych w nieedycyjnych formatach graficznych, w tym w pdf. Obecnie takim narzędziem jest np. gimagereader dostępny w AUR w dwu wersjach: używającej bibliotek Gtk+ , przez co lepiej nadaje się dla środowisk o nie opartych oraz używającej Qt5 . Niemniej jednak, jak feniks z popiołu odradza się Kooka, która w większym stopniu zintegrowana jest z Plasmą (oparta o KF5). Aplikacja działa i na pewno nadaje si...

W AUR istnieje skrypt umożliwiający budowę Gimagereadera - programu OCR dla linuksa, opartego o silnik tesseract. Niemniej jednak jest to wersja zbudowana w oparciu o biblioteki Gtk. Źródła programu umożliwiają jednak również budowę opartą o Qt5. Także qtspell , używany przez program może być zbudowany na podstawie Qt5 (a nie, jak w AUR, w oparciu o Qt4). Tym samym możemy się pokusić o zbudowanie aplikacji OCR, która będzie się zachowywać natywnie w środowiskach opartych o Qt5 (Plasma, LXQT, a także takich jak np. Hawaii). Załączam paczkę , która składa się z dwu katalogów. Po rozpakowaniu otrzymamy katalogi: gimagereader/qtspell-qt5 gimagereader/gimagereader-qt5 zawierające PKGBUILDy. Budując aplikację musimy zachować kolejność. Najpierw zatem budujemy paczkę qtspell-qt5, a następnie gimagereader-qt5. Zgodnie z zasadami panującymi w Archu, gimagereader-qt5 jako zależność ma wyłącznie silnik OCR - tesseract, ale już nie paczki ze słownikami. Chcąc zatem skorzystać z możliwości ...