Optical Character Recognition (GOCR)

Hello

When using -m 130 with last cvs version gocr shows
unrecognized area twice.

Also, could it be possible to show there CONTEXT
with unrecognized area? That would make it easier
to understand symbol by operator.


Alex.

> >>if(c1!='P')F0("first byte should be P in
> PNM-files");
> >>if(c2!='5' && c2!='4' && c2!='6')// F0("no
> PNM-RAW"); //
> >>PGM-RAW,PBM-RAW,PPM-RAW
> >>if(c2!='1' && c2!='2' && c2!='3')F0("no PNM");
> >>    
> 
> so it really means
> 
>    if(c1!='P')
> 	F0("first byte should be P in PNM-files");
> 
>    if ((1 > c2) || (6 < c2))
>       F0("no PNM");
> 

If you are getting into form, I prefer

     // any char other than 1 to 6 because ....
     if ((c2 < '1') || ('6' < c2))
        F0("no PNM");

Placing the values as if on a number line in ascending
value.
The comment should say what is happening and why. When
I read the above set of if's, I would think that not
starting with a 'P' already covers the "no PNM"
condition. What is special about not being 1-6?


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

You can use PNM cut module as preprosessing task before use gocr
for char recog. 
----- Original Message ----- 
From: <jocr-devels-request@...>
To: <jocr-devels@...>
Sent: Wednesday, January 11, 2006 9:58 AM
Subject: Jocr-devels digest, Vol 1 #318 - 2 msgs


> Send Jocr-devels mailing list submissions to
> jocr-devels@...
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/jocr-devels
> or, via email, send a message with subject or body 'help' to
> jocr-devels-request@...
> 
> You can reach the person managing the list at
> jocr-devels-admin@...
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Jocr-devels digest..."
> 
> 
> Today's Topics:
> 
>   1. jocr (Almanova Sistemi)
>   2. if code (Christopher Priest)
> 
> --__--__--
> 
> Message: 1
> Date: Tue, 10 Jan 2006 12:34:16 +0100
> From: Almanova Sistemi <almanova@...>
> To: jocr-devels@...
> Subject: [Jocr-devels] jocr
> 
> Hi everybody.
> 
> I need to know if is possible to recognize only some part of a document.
> 
> Thank's.
> 
> Massimo
> 
> 
> --__--__--
> 
> Message: 2
> Date: Tue, 10 Jan 2006 18:22:49 -0800 (PST)
> From: Christopher Priest <christopherpriest@...>
> To: jocr-devels@...
> Subject: [Jocr-devels] if code
> 
>> >>if(c1!='P')F0("first byte should be P in
>> PNM-files");
>> >>if(c2!='5' && c2!='4' && c2!='6')// F0("no
>> PNM-RAW"); //
>> >>PGM-RAW,PBM-RAW,PPM-RAW
>> >>if(c2!='1' && c2!='2' && c2!='3')F0("no PNM");
>> >>    
>> 
>> so it really means
>> 
>>    if(c1!='P')
>> F0("first byte should be P in PNM-files");
>> 
>>    if ((1 > c2) || (6 < c2))
>>       F0("no PNM");
>> 
> 
> If you are getting into form, I prefer
> 
>     // any char other than 1 to 6 because ....
>     if ((c2 < '1') || ('6' < c2))
>        F0("no PNM");
> 
> Placing the values as if on a number line in ascending
> value.
> The comment should say what is happening and why. When
> I read the above set of if's, I would think that not
> starting with a 'P' already covers the "no PNM"
> condition. What is special about not being 1-6?
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> 
> 
> 
> --__--__--
> 
> _______________________________________________
> Jocr-devels mailing list
> Jocr-devels@...
> https://lists.sourceforge.net/lists/listinfo/jocr-devels
> 
> 
> End of Jocr-devels Digest

Hi everybody.

I need to know if is possible to recognize only some part of a document.

Thank's.

Massimo

Dear List,
               this isn't a patch, but it might turn
into one.

Here are three consecutive lines lines from jocr/src/pnm.c:

    if(c1!='P')F0("first byte should be P in PNM-files");
    if(c2!='5' && c2!='4' && c2!='6')// F0("no PNM-RAW"); // PGM-RAW,PBM-RAW,PPM-RAW
    if(c2!='1' && c2!='2' && c2!='3')F0("no PNM");

(as at 17:38 GMT,  6th January 2005)

I have a deep, deep, deep suspicion that the first '//' in the middle line
is the Wrong Thing, as it kills the ';' following the invocation of F0().
Surely the intention was to evaluate the third line in all cases, not
only in the case where the second condition is met?

Here, as elsewhere, the code suffers from truly abominable
and furiously inconsistent layout, which makes the intention
unclear (and the effect hard to spot).
Is there any chance of taking a global whitespace change
(with NO compiler-significant changes, just layout) and
then resuming development when it is possible to see
what one is doing?  If it seems like a good idea, is
there a preference for any particular brace style?

Bernard Leak
--
Before they made me, they broke the mould

Trying gocr and ocrad on the trivial case of ocr, namely black/white
printed printed digital text, I was not quite fine with the results.
The following stumbling blocks occured, and the observed outcomes of
different versions, sorted by subjective severity of the error:

a) Ligature "ft"                        b) Character "ß"
a2) "ft" via db mode                    b2) "ß" via db mode
a3) "_"                                 b3) "_"
a4) "R" in spite of db mode             b4) "R" in spite of db mode

c) Ligature "rw"                        d) Ligature "rt"
c1) "rw"                                d1) "rt"
c2) "rw" via db mode                    d2) "rt" via db mode
c3) "rrw" in spite of db mode           d3) "rrt" in spite of db mode

e) Character "x"                        f) Character "g"
e1) "x"                                 f1) "g"
e2) "x" via db mode                     f2) "g" via db mode
                                        f3) "9" (nine)
                                        
g) Character "w"			h) Character "W"
g1) "w"                                 h1) "W"
g2) "w" via db mode                     h2) "W" via db mode
g3) "N"

i) Character "l" vs. "I"                j) Character ":"
                                        j1) ":"
i2) all "l" except in capitals
i3) some "I" as "l", capitals correct   j3) "="
                                        j4) ".." after asking for "."
                                        
                                        k) Character "?"
l) Character "!"
k1) "?"                                 l1) "!"
k3) "7."                                l3) "!."

m) The sequence "..."                   n) Punctuation order
m1) "..."                               n1) ok
m2) "...", leading space missing        n4) one line too high
m3) sometimes "."/"..", sometimes "..."
m4) "...", sometimes ".. ."

General note: gocr sometimes produces different result depending on whether
some db entry was just made or was in the db from a previous run.

Also note that "l" and "I" were not optically distinguishable, so no useful
result can be expected there. In the combinations "rt", "rw", and "ft" the
first letter touched the second.

gocr was always run with the options -m 130 -f UTF8 -s 10 -p somepath/ and
(for each binary a different) database. The last binary is current cvs plus
a patch that fixes the broken db (but re-introduced another bug).

Listed after each executable were the characters asked for. The "." was
always bogus. Then the outcomes for the listed problems.

                                        abcdefghijklmn

gocr 0.39: ß rt rw ft g . x             22332211341124

gocr @2004-02-13: ß rt rw ft g . x      22332211341124
gocr @2004-02-14: ß rt rw ft g . x      22332211341124
gocr @2004-02-20: ß rt rw ft g . x      22332211341124
gocr @2004-02-24: ß rt rw ft g . x      22332211341124
gocr @2004-03-17: ß rt rw ft g . x      22332211341124
gocr @2004-09-08: ß rt rw ft g . x      22332211341124
gocr @2004-10-09: ß rt rw ft g . x      22332211341124
gocr @2004-10-12: ß rt rw ft g . x      22332211341124
gocr @2004-11-26: ß rt rw ft g . x w W  22332222341124
gocr @2005-01-11: ß rt rw ft g . x w W  22332222341124
gocr @2005-01-26: ß rt rw ft g . x w W  22332222341124
gocr @2005-02-24: ß rt rw ft g . x w W  22332222341124
gocr @2005-03-01: ß rt rw ft g . x w W  44222222341124
gocr @2005-03-08: ß rt rw ft g . x w W  44222222341124
gocr @2005-03-09: ß rt rw ft g . x w W  44222222341114
gocr @2005-03-11: ß rt rw ft g . w W    44221222341114
gocr @2005-03-12: ß rt rw ft g . w W    44221222343314
gocr 0.40:        ß rt rw ft g . w W    44221222333311
gocr @2005-03-14: ß rt rw ft g . w W    44221222343314
gocr @2005-03-15: ß rt rw ft g . w W    44221222343314
gocr @2005-03-21: ß rt rw ft g . w W    44221222343314
gocr @2005-03-23: ß rt rw ft . w W      44221322343314
gocr @2005-03-31: ß rt rw ft . w W      44221322343314
gocr @2005-04-03: ß rt rw ft . w W      44221322343314
gocr @2005-04-19: ß rt rw ft . w W      44221322343314
gocr @2005-05-19: ß rt rw ft W          44221332311141
gocr @2005-05-20: ß rt rw ft W          44221332311141
gocr @2005-05-24: ß rt rw ft W          44221332331141
gocr @2006-01-08-fix: ß rt rw ft W      22331332331141

The versions where the dates where changes were made in cvs. Since the sf
cvs is pretty broken currently, I may have missed ones. Between compiles I
did make clean. However, release 0.40 does not fit into the scheme as it
behaves differently than the versions around it.

Additionally, database-only mode was tried. Problems: "..." was detected
as ". . .", bug c3) / d3), '' detected as ll, other spacing problems.

For comparison, the current version of ocrad (output with s/"/''/g and
empty lines dropped for comparison):

Ocrad 0.13:                             33111111211131
* "ist ja" detected as "istja"
* one s capitalized wrong

Interesting that it doesn't stumble over the "rw" and "rt" combinations.
If ocrad had a database mode, it would certainly give the best results.


Here's the patch to fix the database problems (note the tarball you
mentioned on this list does _not_ fix the problem):

ruediger@...> cvs di lines.c | tee diff
Index: lines.c
===================================================================
RCS file: /cvsroot/jocr/jocr/src/lines.c,v
retrieving revision 1.32
diff -u -r1.32 lines.c
--- lines.c     18 May 2005 08:49:07 -0000      1.32
+++ lines.c     8 Jan 2006 18:28:43 -0000
@@ -278,6 +278,12 @@
         if (box2->num_ac>1) { /* output alist */
         }
       }
+      if (box2->obj && (JOB->cfg.out_format!=XML || box2->obj[0]!='<')) {
+        buffer=append_to_line(buffer,box2->obj,&len);
+        j+=strlen(box2->obj);
+        /* should we free box2->obj here and reset? not very clean */
+        free(box2->obj); box2->obj=NULL;
+      } else
       if (box2->c != UNKNOWN && box2->c!=0) {
         buffer=
           append_to_line(buffer,decode(box2->c,JOB->cfg.out_format),&len);
@@ -285,16 +291,9 @@
             box2->c <= 'z') i2++; /* count non-space chars */
       } else {
         wchar_t cc; cc=box2->c;
-        if (box2->obj && (JOB->cfg.out_format!=XML || box2->obj[0]!='<')) {
-          buffer=append_to_line(buffer,box2->obj,&len);
-          j+=strlen(box2->obj);
-          /* should we free box2->obj here and reset? not very clean */
-          free(box2->obj); box2->obj=NULL;
-        } else {
           if (cc==UNKNOWN && !(mo & 8)) { cc=box2->ac; } /* take alternate char */
           buffer=
             append_to_line(buffer,decode(cc,JOB->cfg.out_format),&len);
-        }
       }
       if (JOB->cfg.out_format==XML) {
         if (box2->num_ac>0) { /* output alist */


Additionally, there are a few things wierd in cvs. There are generated
Makefiles checked in - they'll be overwritten by configure anyway, and there
are no .cvsignore hiding the generated files from cvs.

./bin/.cvsignore:.cvsignore
./bin/.cvsignore:gocr
./doc/.cvsignore:Makefile
./doc/.cvsignore:.cvsignore
./man/.cvsignore:Makefile
./man/.cvsignore:.cvsignore
./src/api/.cvsignore:Makefile
./src/api/.cvsignore:.cvsignore
./src/.cvsignore:Makefile
./src/.cvsignore:.cvsignore
./src/.cvsignore:gocr
./.cvsignore:Makefile
./.cvsignore:.cvsignore
./include/.cvsignore:config.h
./include/.cvsignore:.cvsignore

Also, the file confdefs.h is deleted on make clean, but in cvs.

-- 
"See, free nations are peaceful nations. Free nations don't attack
 each other. Free nations don't develop weapons of mass destruction."
      - George W. Bush, Milwaukee, Wis., Oct. 3, 2003

Dear List,
               the patches detailed in this this
message were attached to the wrong message,
namely "gocr: and another thing (in src/pnm.c)",
sent earlier today. I won't repeat them here,
to save bandwidth.

The code-base is as at 17:38 GMT,  6th January 2005

Patch A:
A small "remove warnings" patch for  jocr/src/ocr0.c
This uses the (possibly undefined) macro name
USEFUL_TAG (feel free to change the name!)
to control both the inclusion of some debugging
code (currently #if 0 in the source) and the
declaration of some of its local variables (which
are otherwise unused).  On the whole, I recommend
replacing "#if 0" stuff everywhere with this kind
of named tag, with all such tags listed at the top
of the file for easy reference, ideally with some
sort of comment on their purpose.  If no purpose
can be identified, remove the code!

One other change: there is no merit to the
inline function 'sq', and it has been replaced
with a macro.  This makes it independent of
assumptions about the type of the argument,
though everywhere it seems to be used for
'int' arguments anyway.  The argument *was*
of type 'int', by silent implication.  Just
possibly the coder was aware of this and
relied on it (though it is officially deprecated):
more likely it 'just worked' and was never
properly considered.

The macro will yield different results from
the (inline) function if the argument has an
unexpected type (when the macro is surely
more likely to be right), or if the literal
argument is modified by being evaluated
(e.g., it may include a function call, or -- or
++).  There are no such cases in this file
(indeed, many of the arguments are integer
constant expressions).

Patch B:
This is a big baggy 'remove warnings' patch.
All separate patch regions are independent.

Patch C:
YEOWCH!
What is this rubbish about 'sizeof(char)"  ?

(a) If you want to work with K&R C (or vaguely similar),
        you shouldn't be using '//'-style comments,  or 'void',
        or 'FILE', or '<stdlib.h>', or prototype-style function
        definition headers.  These came in, some with the
        early versions of C++, and some with the first ANSI
        standard for C.
(b) ISO C90 requires sizeof(char) = sizeof(unsigned char) =
sizeof(signed char) = 1:
        see 6.3.3.4 in ANSI/ISO 9899-1990   (appealing to the definition
of 'byte' in 3.4)
        (And '//' comments aren't allowed here either!).
(c) ISO C99 allows the '//' comments, but the size of a byte hasn't changed:
       see 6.5.3.4 (3) in ISO/IEC 9899-1999 (from the definition of 'byte'
in 3.6)

The only remotely plausible circumstance in which your code could work, with
sizeof(char) not 1, would be a truly horrible weird non-ANSI version of C
which was roughly based on K&R, incorporated a few early changes eventually
incorporated into the ANSI standard, and even early C++-isms (like '//'
comments),
but worked on a machine with tiny bytes (4-6 bits?).  I seriously doubt
whether any such implementation has ever existed.  Do you know otherwise?
Would you like to bet anything on gocr/jocr compiling successfully on such
a machine (let alone running)?  Anyone who can get it running under
GNOME on such a machine deserves a prize...

As a *MUCH* more rational alternative, how about a configure-time sanity
check?  Unfortunately, sizeof(char) won't evaluate in the preprocessor,
so a simple
#if (1 != sizeof(char))
#error sizeof(char) is not 1
#endif /* #if (1 != sizeof(char)) ... here */

won't work.

Anyway, patch C removes all this poo.
This horror is to be found in api/doc/api.{lyx,tex,txt} , and
the multiplications by sizeof(char) (&c) in
api/src/image.c
src/database.c
src/lines.c
src/pgm2asc.c
src/pnm.c


While it's about it, it incorporates another minor improvement.
All malloc() returns are now cast to the appropriate type.
This helps to pick up accidental type changes, or programmer
misrecollections of the relevant type.  One type-cast was
already in use: this was actually generating a warning!  The
cast should have been to (unsigned char *), but was to
(char *) instead.  In principle this is a different change, but
the changes overlap and I don't see either as controversial.

Patch D
Short and sweet: helps the GNOME build to work if '.' isn't in the path.


Bernard Leak
--
Before they made me, they broke the mould