pavbaranov Arch

Niezbyt wiele mamy aplikacji stanowiących GUI dla silników OCR w linuksie, zatem każdą z nich należy pielęgnować. W świecie oprogramowania opartego o Qt 5, spośród stale rozwijanych w zasadzie istnieje jedynie gImageReader. W AUR znajdziemy dwa PKGBUILDy: gimagereader oparty jeszcze o Qt 4 oraz gimagereader-qt5 oparty o Qt 5. Pierwszym nie będę się zajmować. Najwyższy czas, by dawno już porzucone Qt 4 odeszło w mroki dziejów. Niestety po psikusie, jakim było wprowadzenie enchant w wersji 2 do repozytorium (extra), aplikacja ta przestaje działać. Pominąwszy pewne perturbacje, jakie były w międzyczasie, dzisiaj już udaje się przywrócić możliwość działania gImageReaderowi. Niestety nie podam Wam co i jak należy zmienić w istniejących PKGBUILDach w AUR. Jeśli chcecie używać, to będziecie się musieli zdać na moje rozwiązanie. Zacznijmy od tego, że gImageReader wymaga do swojego działania i budowy qtspell, ten natomiast wymaga enchant. Obecna sytuacja w repozytoriach i w AUR jest następująca...

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 ...