Konwersja pisma ręcznego na drukowane

O mnie - Smaczne, zdrowe... wyroby domowe

Temat: Krytyka ,,Linux +''
On 15 Oct 2001 13:02:39 GMT, Artur Skura <art@iidea.plwrote:


Michał Wasiak wrote:
| Krzysztof 'GreenSun' Krawczyk wrote:

| A juz ze zdwieniem przeczytalem "(..)Zdecydowanie nie przyjmujemy
| tekstów pisanych w TeX-u(..), a chcialem napisac atrykul...

| I jeszcze ,,zdecydowanie''. Potem efekty widać.
| To jednak duży wstyd.

Naprawdę uważasz, że przyjmowanie lub nie tekstów w TeX-u ma jakiekolwiek
znaczenie dla wspomnianych problemów?

Proces tworzenia pisma wygląda tak, że autor dostarcza tekst redaktorowi,
a ten z kolei składaczowi. Składacz ma Page Makera i przyjmuje tylko
doce czy rtf-y. Gdyby mu dać tekst w TeXu, prawdopodobnie nie wiedziałby co
to jest  i z czym to zjeść. PS/dvi mu na nic.


To jest trochę bez sensu. Dlaczego gazeta o Linuksie ma być składana
byle jak na ,,wrogim'' systemie. Nie chodzi o to, że system jest
wrogi, ale o to, że pod Linuksem jest choćby TeX, który w wielu
wydawnictach jet używany do tego celu.


Tak więc kwestia konwersji z TeX-a na rtf/doc spada na redaktora, który ma
ważniejsze rzeczy do zrobienia. Już mniejsza z tym, że każdy autor ma swój
ulubiony sposób kodowania polskich znaków, bo to można potraktowac z
automatu. Schodki zaczynają się w momencie, kiedy dokumet w TeX-u mówi o
TeX-u (tabelki itd.).  Wtedy zaczyna się ręczne dzierganie tego, co
spokojnie mógłby zrobić autor. W dodatku rezultat jest zazwyczaj gorszy.

Dlaczego nie użyć jakiegos standardu, takiego jak DocBook/HTML? Jeśli autor
zna TeX-a, poradzi sobie z w/w. Składacz też, po zastosowaniu środków
perswazji, przyjmie tekst HTML-u. A dzięki temu można za jednym zamachem
uzyskać ujednolicenie rodzajów pisma w odniesieniu do różnych
klas pojęć (nazwy plików/pakietów, listingi/fragmenty kodu, urle itd).

Nie rozumiem skąd przypuszczenie, że redaktor powinien zajmować się
rzeczami typu  konwersja TeX-to-co-zje-PM, skro równie dobrze, a nawet
lepiej, wyjdzie to samemu autorowi. Wartość tekstu to nie tylko treść, ale
i forma. Przykładowo, Chip-Specjal-Writers-HOWTO ma obecnie jakieś 85 kb i
stale rośnie. Tekst _musi_ spełniac pewne wymagania, zarówno co do treści
jak i formy, bo inaczej pisma ukazywałyby się raz na rok, a redaktorzy


Tekst drukowany tym bardziej.


chodzili z błędnym wzrokiem klnąc na czym świat stoi.


To wszystko mnie, jako czytelnika, może mało obchodzić.
Skoro sam potrafiłbym poprawniej taki sam tekst złożyć (nie mówie o
gazecie jako całości, tylko o artykule), to zastanawiam się co za
,,fachowcy'' tam pracują. Tłumaczenie, że składacz musi się
napracować, żeby taki knot w Windowsie stworzyć jest rozkładające.
Niech się biedak zwolni z roboty, albo nauczy.

Może jednak lepiej byłoby to robić w TeXu?


Źródło: topranking.pl/1355/krytyka,linux,39,39.php


Temat: Mały test OE... który aż tak badziewnym czytnikiem nie jest... (dodajmy polskie literki: ęąśżźćńłó)

JanOsik <janas@poczta.fmw artykule news:We084.80523$Oo3.1850125@news.tpnet.pl pisze...
|
| Kto jest zatem winny?
| Winny jest ZUS (konkretnie ludzie, którzy z ramienia ZUS zawierali
| umowę z firmą
| P.). ZUS powinien zażyczyć sobie programu działającego także na innych
| platformach niż Win9x. Jeśli firmie P. ciężko było zrobić trzy (lub
| więcej)
| wersji Płatnika, to należało zamówić wersję TYLKO dla DOS-a.
|
| I znowu niestety sie musze wtrącić.
| Sprawa nie jest tak klarowna jakby się mogło wydawać.
| Wydruki z Płatnika muszą być przetwarzane przez system masowego
| skanowania
| i rozpoznawania pisma.

1. Nic nie MUSI być przetwarzane. Jaki ma sens robienie programu komputerowego,
który służy TYLKO do wydruku tego, co się w niego ręcznie wklepie???
Jeśli ma to naprawdę usprawnić pracę i jakość przetwarzania danych, to po kiego
grzyba konwertować informację z postaci analogowej na cyfrową (wklepywanie),
potem z cyfrowej na analogową (wydruk), żeby
wreszcie ją konwertować ostatecznie na cyfrową (skanowanie i OCR)???
Należy założyć, że jak się już wprowadza dane do komputera, to potem się ich nie
drukuje tylko zanosi na dyskietce, CD-ROMie lub wysyła przez sieć.
Wtedy jest praktycznie ZERO przekłamań i problemów z odczytaniem dokumentów.
Taka możliwość w sumie istnieje, ale trochę za mało zrobiono, by naprawdę zachęcić
ludzi do tej formy dostarczania danych do ZUS. Zamiast być najwygodniejszą (dla obu
stron!!!) formą przepływu informacji, okazała się najbardziej kłopotliwą.

| Systemu takie wymagają stałej pozycji pól na
| formularzu.
| Pytanko za 100 punktów: Komu z was udało się na różnych drukarkach w
| systemie
| DOS uzyskać dokładnie taki sam wydruk???
| Ile z nowych drukarek atramentowych czy laserowych posiada dosowe
| sterowniki?
| (tylko takie wydruki są akceptowane - igłówki odpadają ze względu na
| słabą jakość

2. System rozpoznawania pisma (druku) nie był przygotowywany z myślą o
rozpoznawaniu wydruków z Płatnika. On ma rozpoznawać to co ludzie piszą RĘCZNIE.
W końcu nie ma obowiązku korzystania z Płatnika i wiele osób nadal wypełnia
formularz długopisem.
Stawiam dolary przeciwko orzechom, że wydruk nawet z najgorszej drukarki igłowej
jest 100 razy lepszy i łatwiejszy do zeskanowania niż najstaranniejsze pismo
odręczne.
Jeśli system OCR przygotowany dla ZUS radzi sobie z ludzkim pismem, to poradziłby
sobie także z KAŻDYM wydrukiem, nawet z igłówki.

3. Drukarki atramentowe i laserowe w ogromnej większości obsługują popularny
język PCL i nie trzeba dla nich żadnych DOS-owych sterowników.
Po prostu wysyła się komendy PCL prosto do portu równoległego.
Wyjątkiem są drukarki GDI, które PCL emulują softwarowo, ale one i tak działają
tylko pod Windows. Specjalny sterownik przechwytuje wydruki z programów DOS-owych
(uruchomionych spod Windows) i tłumaczy PCL-a na "język" konkretnej drukarki.
Krótko mówiąc, wystarczy założyć, że użytkownik ma drukarkę zgodną z HP 500 (99%).

Niedawno pisałem DOS-owy programik, który m.in. miał robić "zrzut" ekranu na
drukarkę (dowolną atramentową lub laserową obsługującą PCL).
Ja mam drukarkę GDI, więc uruchamiałem program spod Windows i bez problemu
wszystko działało. U klienta posiadającego dwie różne atramentówki HP, zarówno
spod czystego DOS-a, jak i spod DOS-a w okienku Windows też jest OK.

4. Jak się już robi program, który coś tam drukuje, to zamiast tworzyć bardzo
skomplikowany system OCR, można program wyposażyć w funkcję drukowania zawartości
formularzy zakodowanej w postaci kodów kreskowych.
(tzn. oprócz zwykłej treści tekstowej można drukować te same dane jako kody
kreskowe - obok, poniżej, na odwrocie, na osobnej kartce, itp.)
Wówczas o wiele prościej jest zeskanować te dane i trudniej o błędy, bo kody
kreskowe są wyposażone np. w sumy kontrolne.
Kod kreskowy jest wystarczająco czytelny nawet wtedy, gdy pochodzi z drukarki
igłowej. (I często spotyka się kody tak właśnie drukowane - książeczki RUM,
rachunki z gazowni, etc.)

Tak więc problemu nie widzę żadnego.


Źródło: topranking.pl/1729/maly,test,oe,ktory,az,tak,badziewnym,czytnikiem.php




 

Powered by WordPress dla [O mnie - Smaczne, zdrowe... wyroby domowe]. Design by Free WordPress Themes.