Witam,
A więc kolejno
... : program powinien wymagać jak najmniejszej wiedzy ze strony usera i powinna to obsłużyć p. Kasia która będzie pić kawę podczas przetwarzania plików i Zenek vel "Speedy" guru pisania skryptów w pythonie. Zakładamy oczywiście, że wypadków eksteremalnych w obu przypadkach będzie mało, zatem musi to obsłużyć średniozaawansowany w generalnej obsłudze kompów user. Idealnym rozwiązaniem byłoby gdyby interfejs pozwalał w sposób "klikalny" na regulowanie wszystkich parametrów. Minder ma tutaj dużo racji proponując żeby móc wybrać rozmaite poziomy skomplikowania ustawień, aż do najwyższego w którym będzie możliwość wpisania komend.
Oczywiście, że w pierwszym etapie nie będziemy chcieli optymalizować etc. - ale dlaczego w drugim nie? Zrobimy wersję 1.0 a potem optymalizacja, optymalizacja! (czy bibliotek?) A może wersji 2.0 ten progs będzie mógł korzystać z Djvulibre i pluć djvu?
Ważne jest aby zrobić ten projekt dosyć szybko wersja stabilna winna się pojawić w ciągu jakichś 3-4 tygodni. Dlaczego tak? Dzisiaj byłem na spotkaniu w jednej z instytucji państwowych która też chce podjąć się zdigitalizowania całego swojego zasoby. Nie spojrzała w stronę środowiska open jak NAC i chce to zrobić w oparciu o firmy komercyjne (systemy, wiadomo sprzęt tak czy siak trzeba kupić). W tym momencie potrzebuje właśnie takiego oprogramowania do wsadowej konwersji plików - jeśli dostarczymy takiego oprogramowania zyskamy może jeszcze jedno wsparcie a być może niedługo i neofitów
...
Venomous: Cieszę się, że system jest i działa tak jak powinien. Nie wiem czy firma zgodzi się na kompletną dostępność do kodu czyli najzwyczajniejsze open source. Tu chodzi o powszechne wdrożenie a nie o łaskę korzystania w NAC czy w dwóch, trzech "apach" (archiwach państwowych). W wypadku firmy nie robi ona tego beinteresownie ale wpisuje się pracowicie na listę referencyjną
... ale nie chcę wchodzić tu w dywagacje na temat tego co i jak. Zastanawiam się też nad jednym: dlaczego do tej pory firma ta nie udostępniała swoich narzędzi środowisku jako opensource? To nie znaczy, że należy w czambuł potępiać wszystko co zrobili -warto skorzystać z ich doświadczeń i proszę abyś fakycznie monitorował tę sprawę - szczerze powiedziawszy wiedzę masz tak dużą, że z palca jesteś w stanie wskazać pewne sprawy
... Summa summarum nie chcemy wyważać otwartych drzwi ale nie chcemy też włazić oknem bo drzwi są za małe...
david: nie wiem co nie podoba Ci się w tiff - jest to standard zalecany przez środowisko archiwalne, co do raw nie mam nic przeciwko - a output powinien być w wybranym formacie a nie w jednym - nie zamykajmy sobie grona odbiorców. Co do rozdzielczości - tu nie można powiedzieć, że jest wystarczające: o ile dokument napisany na maszynie, czy nawet pisany ręcznie (ale tu już zależy jaki) zeskanowany w 300 dpi to i tak za dużo o tyle pieczęć, zdjęcie 600 dpi wymaga bardzo tej rozdzielczości.
piotrpsz: Piotrze jeśli potrzebujesz dokładnych "workflowsów" co ma progrsik robić (nawet flowcharty na ile potrafimy - choć nie wiem czy to tu będzie potrzebne) mówisz i masz - postaram się aktywizować w tej kwestii ludzi z pracowni z digitalizacji, choć i ja kiedyś w tam pracowałem to mogę opisać co i jak z tego co pamiętam
...
Co do nazwy może: NA(r)Cyz?
logo możnaby zrobić niezłe
... a właśnie - JAKBY KTOŚ MÓGŁ ZROBIĆ LOGO DO TEGO PROGRSIKU BYŁOBY TO GENIALNE - oczywiście po wybraniu nazwy
... Jak macie jakichś fajnych grafików znajomych to byłoby super.
Generalna uwaga: zróbmy może jeszcze jeden obrót dyskusji w związku z dosyć dużą pilnością sprawy (jak się okazało - ja myślałem, że to taki lajtowy projekcik i będziemy przy nim mogli dłubać i dłubać) i podzielimy sobie robotę żeby za te 3-4 tygodnie mieć coś stabilnego w ręku
Pozdrawiam
Rafał
P.S. dPes: Informacja dotycząca ilości danych funkcjonalności etc. będzie natomiast dotyczyła głównego projektu czyli budowy systemu zintegrowanego. Przepraszam, że jeszcze nie macie tych danych ale jak pisałem są w drodze
...
