jocr-devels

Re: [Jocr-devels] gocr-0.43 compile error

[Joerg S. <Joe...@UR...>]

On Mon, 19 Feb 2007, Gordon Thagard wrote:

> Nevermind. I found it. I had to include something in src/progress.h:
>
> 	#include <sys/time.h>
>
> You may want to update your source...
>
> Gordon Thagard wrote:
>> Any suggestion???

Sorry, a patch  can be found on the download page. A updated version will 
be released soon. I want to fix some other problems before releasing it.

Joerg

Re: [Jocr-devels] gocr-0.43 compile error

[Gordon T. <go...@en...>]

Nevermind. I found it. I had to include something in src/progress.h:

	#include <sys/time.h>

You may want to update your source...

Gordon Thagard wrote:
> Any suggestion???

[Jocr-devels] gocr-0.43 compile error

[Gordon T. <go...@en...>]

Any suggestion???

Solaris 5.9
gcc 3.46
netpbm-10.27

$./configure --with-netpbm=/usr/local/netpbm
...
$make
...
$autoconf (TRIED WITH AND WITHOUT THIS)
$make
make -C src all
make[1]: Entering directory `/usr/local/src/gocr-0.43/src'
gcc -g -O2 -I/usr/local/netpbm/include  -I../include -DHAVE_CONFIG_H -c 
-o pgm2asc.o pgm2asc.c
gcc -g -O2 -I/usr/local/netpbm/include  -I../include -DHAVE_CONFIG_H -c 
-o box.o box.c
gcc -g -O2 -I/usr/local/netpbm/include  -I../include -DHAVE_CONFIG_H -c 
-o database.o database.c
gcc -g -O2 -I/usr/local/netpbm/include  -I../include -DHAVE_CONFIG_H -c 
-o detect.o detect.c
gcc -g -O2 -I/usr/local/netpbm/include  -I../include -DHAVE_CONFIG_H -c 
-o barcode.o barcode.c
gcc -g -O2 -I/usr/local/netpbm/include  -I../include -DHAVE_CONFIG_H -c 
-o lines.o lines.c
gcc -g -O2 -I/usr/local/netpbm/include  -I../include -DHAVE_CONFIG_H -c 
-o list.o list.c
In file included from list.c:61:
progress.h:21: error: syntax error before "time_t"
progress.h:21: warning: no semicolon at end of struct or union
progress.h:22: warning: data definition has no type or storage class
progress.h:24: warning: data definition has no type or storage class
progress.h:35: error: syntax error before '*' token
progress.h:35: warning: data definition has no type or storage class
progress.h:37: error: syntax error before '*' token
progress.h:39: error: syntax error before "progress_counter_t"
list.c: In function `list_sort':
list.c:266: error: `pc' undeclared (first use in this function)
list.c:266: error: (Each undeclared identifier is reported only once
list.c:266: error: for each function it appears in.)
make[1]: *** [list.o] Error 1
make[1]: Leaving directory `/usr/local/src/gocr-0.43/src'
make: *** [src] Error 2

[Jocr-devels] redistribute gocr binaries?

[Mark H. <mha...@sk...>]

Hi all,
  I'm involved with the 'spambayes' project (spambayes.org), an open-source
client-based spam solution, and we've had recent success in using gocr with
our recent OCR enhancements.  Spambayes is released under a 'Python' style
open-source license which is closer to a BSD license than to the GPL.

Are there any license considerations or any other objections to us including
a gocr binary with our Windows binaries?  If not, are there any other
requests or guidelines you would like us to adhere to?  We are looking at
including the unmodified binary at
http://www-e.uni-magdeburg.de/jschulen/ocr/gocr043.exe in our application
directory (an email address for Peter B L Meijer wasn't obvious, otherwise
I'd CC him)

Thanks,

Mark

Re: [Jocr-devels] >gocr043.exe -m 2 myfile.pgm - error

[Turko <gra...@gm...>]

I solved the problem by myself and Im writing you the solution:

in function "readpgm" in file pnm.c at line 244:

static FILE *f1=3DNULL;

REMOVE the static modifier or on Windows will get the error above.

In fact on the second call of readpgm due to the "static" the FILE pointer
is not NULL.


Byez,
Turko


On 2/9/07, Turko <gra...@gm...> wrote:
>
> This is the debug data:
>
> >gocr.exe -v 33 -m 2 E.pgm
> # Optical Character Recognition --- gocr 0.43
> # options are: -l 0 -s 0 -v 33 -c _ -m 2 -d -1 -n 0 E.pgm
> # using unicode
> # PNM P5 h*w=3D30*25 c=3D255 head=3D58 min=3D0 max=3D255
> # PNM EOF
> # db_path=3D (null)
> # OTSU: value ihist chist mass_dipol_moment
>
> # I cutted this long part
>
> # OTSU: thresholdValue =3D 130 gmin=3D0 gmax=3D255 cmax=3D255 i=3D 192 55=
8
> # thresholding new_threshold=3D 160
> # load database ./db/ (null) ...                             <-- is there
> the problem?
> ERROR src\pnm.c L279: read magic2
>  1 chars loaded
> # scanning boxes nC=3D   1 avD=3D 22 23
> # dust size histogram   1     0
> # auto dust size =3D 0 nC=3D   1 ..   1 avD=3D 22 23 .. 22 23
> # ...   0 white pixels removed, cs=3D160 nC=3D   1
> # smooth big chars 7x16 cs=3D160 ...   5 changes in 1 of 1
> # detect barcode , 0 bars, boxes-0=3D1
> # detect pictures, frames, noAlphas, mXmY=3D 22 23 ...  0 - boxes 1
> # averages: mXmY=3D 22 23 nC=3D 1 n=3D 1
> # src\remove.c L286: remove pictures
> # ... status: pictures=3D 0  other=3D 1  nC=3D 1
> # ... deleted=3D 0 pictures (big or on border)
> # ... status: pictures=3D 0  other=3D 1  nC=3D 1
> # ... deleted=3D 0 nested pictures
> # ... status: pictures=3D 0  other=3D 1  nC=3D 1
> # count subboxes
> # ...   0 subboxes counted (mini=3D0, same=3D0) nC=3D 1
> # glue holes to chars nC=3D 1
> # ... glued:   0 holes,   0 same, nC=3D 1
> # scanning lines
> # ...  trouble on line 1, wt*100=3D 56
> #   m=3D    4  +0 +22 +22
> #   i=3D    1   0   0   1 (counts)
> #   all boxes of same high!
> #   num_lines=3D 1
> # add line infos to boxes ... done, num_line_chars=3D1 rest=3D0
> # mark lines for out10.ppm
> # writing out10.ppm
> "pnmtopng" non =E8 riconosciuto come comando interno o esterno,
>  un programma eseguibile o un file batch.
> # divide vertical glued boxes, numC 1
> # searching melted serifs ...   0 cluster corrected, 0 new boxes
> # count subboxes
> # ...   0 subboxes counted (mini=3D0, same=3D0) nC=3D 1
> # glue broken chars nC=3D 1
> # ... glued:   0 fragments (found   0),   0 rest, nC=3D 1
> # detect dust (avX,nC), ...    0 +   0 boxes deleted, nC=3D 1 ?
> # check for word pitch
> #  line  0 num_gaps=3D  0 (WARNING num_gaps<8)
> #  line  1 num_gaps=3D  0 overall space width is 2 proportional
> # char recognition unknown=3D 1 picts=3D 0 boxes=3D 1
> #
> #DEBUG: ocr_db (2,4)
>
>
>


--=20
"Il mondo non gira intorno agli uomini: essi chiamano Fortuna o Sfortuna ci=
=F2
che in realt=E0 =E8 IL CASO,
alternando le due infauste parole a seconda di momentanei capricci.
Forse =E8 questo che ci rende cos=EC imperfetti rispetto agli d=E8i."

Re: [Jocr-devels] >gocr043.exe -m 2 myfile.pgm - error

[Turko <gra...@gm...>]

This is the debug data:

>gocr.exe -v 33 -m 2 E.pgm
# Optical Character Recognition --- gocr 0.43
# options are: -l 0 -s 0 -v 33 -c _ -m 2 -d -1 -n 0 E.pgm
# using unicode
# PNM P5 h*w=3D30*25 c=3D255 head=3D58 min=3D0 max=3D255
# PNM EOF
# db_path=3D (null)
# OTSU: value ihist chist mass_dipol_moment

# I cutted this long part

# OTSU: thresholdValue =3D 130 gmin=3D0 gmax=3D255 cmax=3D255 i=3D 192 558
# thresholding new_threshold=3D 160
# load database ./db/ (null) ...                             <-- is there
the problem?
ERROR src\pnm.c L279: read magic2
 1 chars loaded
# scanning boxes nC=3D   1 avD=3D 22 23
# dust size histogram   1     0
# auto dust size =3D 0 nC=3D   1 ..   1 avD=3D 22 23 .. 22 23
# ...   0 white pixels removed, cs=3D160 nC=3D   1
# smooth big chars 7x16 cs=3D160 ...   5 changes in 1 of 1
# detect barcode , 0 bars, boxes-0=3D1
# detect pictures, frames, noAlphas, mXmY=3D 22 23 ...  0 - boxes 1
# averages: mXmY=3D 22 23 nC=3D 1 n=3D 1
# src\remove.c L286: remove pictures
# ... status: pictures=3D 0  other=3D 1  nC=3D 1
# ... deleted=3D 0 pictures (big or on border)
# ... status: pictures=3D 0  other=3D 1  nC=3D 1
# ... deleted=3D 0 nested pictures
# ... status: pictures=3D 0  other=3D 1  nC=3D 1
# count subboxes
# ...   0 subboxes counted (mini=3D0, same=3D0) nC=3D 1
# glue holes to chars nC=3D 1
# ... glued:   0 holes,   0 same, nC=3D 1
# scanning lines
# ...  trouble on line 1, wt*100=3D 56
#   m=3D    4  +0 +22 +22
#   i=3D    1   0   0   1 (counts)
#   all boxes of same high!
#   num_lines=3D 1
# add line infos to boxes ... done, num_line_chars=3D1 rest=3D0
# mark lines for out10.ppm
# writing out10.ppm
"pnmtopng" non =E8 riconosciuto come comando interno o esterno,
 un programma eseguibile o un file batch.
# divide vertical glued boxes, numC 1
# searching melted serifs ...   0 cluster corrected, 0 new boxes
# count subboxes
# ...   0 subboxes counted (mini=3D0, same=3D0) nC=3D 1
# glue broken chars nC=3D 1
# ... glued:   0 fragments (found   0),   0 rest, nC=3D 1
# detect dust (avX,nC), ...    0 +   0 boxes deleted, nC=3D 1 ?
# check for word pitch
#  line  0 num_gaps=3D  0 (WARNING num_gaps<8)
#  line  1 num_gaps=3D  0 overall space width is 2 proportional
# char recognition unknown=3D 1 picts=3D 0 boxes=3D 1
#
#DEBUG: ocr_db (2,4)

[Jocr-devels] >gocr043.exe -m 2 myfile.pgm - error

[Turko <gra...@gm...>]

Hi, this is my first message here. I m writing becouse I get the following
runtime error while executing binary version of gocr on Win :

>gocr043.exe -m 2 myfile.pgm

ERROR C:\ccode\mysource\gocr\gocr-0.43\src\pnm.c L271: read magic2

I previously built a little database in .\db of course.

#ifdef HAVE_POPEN
        f1=3Dpopen(buf,"r");
#else
        F0("only PNM files supported (compiled without HAVE_POPEN)");
#endif
        if(!f1)F1("opening pipe %s",buf);
      }
    }
    c1=3Dfgetc(f1); if (feof(f1)) { E0("read magic1"); return -1; }
  }
  c2=3Dfgetc(f1); if (feof(f1)) { E0("read magic2"); return -1; }   // Line
271

I guess it'is a problem with popen, but I don't know how to solve it. Shoul=
d
I recompile?

Thanks,
Fabio





--=20
"Il mondo non gira intorno agli uomini: essi chiamano Fortuna o Sfortuna ci=
=F2
che in realt=E0 =E8 IL CASO,
alternando le due infauste parole a seconda di momentanei capricci.
Forse =E8 questo che ci rende cos=EC imperfetti rispetto agli d=E8i."

Re: [Jocr-devels] Barcode detection issues within GOCR

[Alessandro Z. <azu...@to...>]

On Wed, 6 Dec 2006 23:18:31 +0100 (CET)
Joerg <Joe...@UR...> wrote:

> 
>  
> > Also, it's only a subset of the GOCR process, and it takes a lengthy 
> > time to do OCR on the rest of the image.
> > There should be a way to tell GOCR to barcode detect only, and select 
> > just one code type, say code39 or code128.
> 
> gocr -m 312  switches off nearly everything except barcode detection.
> Think thats enough.


 Hello,

 I've just tried this tip and found there's a difference
 for about 3 seconds between gocr -m 312 and
 a version of gocr i've crafted to exclude everything but
 barcode support.

-- 

 Best regards,

 Alessandro Zummo,
  Tower Technologies - Torino, Italy

  http://www.towertech.it

[Jocr-devels] Source files missing licenses

[Orion P. <or...@co...>]

The following source files are missing license information:

otsu.c
pnm.c
pcx.c
tga.c

Could this please be fixed?  Trying to package gocr up for Fedora Extras
and need all of our ducks in a row...

Thanks!

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  or...@co...
Boulder, CO 80301              http://www.cora.nwra.com

Re: [Jocr-devels] GOCR-0.43 on OpenBSD4.0

[Todd L. <tl...@iv...>]

On Sun, Dec 24, 2006 at 05:10:08AM -0500, sc...@ma... wrote:

>I have a directory named gocr-0.43 from which I have tried to run
>./configure and I see this in the output:
>checking for library containing pnm_readpnminit... no
> * * * try option --with-netpbm=PATH
>When I try to run make I get this:

You can't run make until you get the configure to work properly.  The
commandline ./configure --with-netpbm=/usr/local/ will probably get you
going.  The above error message is telling you "I don't know where to
find the netpbm header files and/or the netpbm shared library files, so
you have to tell me exactly where they are."  I'm not a BSD guy, but I'd
look first in the /usr/local/* heirarchy.

># make
>make -C src all
>make: unknown option -- C

This is just a syntax issue with options you're passing to make.  It
doesn't know what the -C option is.

>Also when I try make install I get this:
># make install
>make -C src install
>make: unknown option -- C

Related to above.

-- 
Regards...		Todd
   A friend of mine was at the military and had to check new recruits for
color-blindness. Only after the 20th color-blind man in a row he realized
for the first time in hist life that it was _him_, being the color-blind.
                                                    --Johannes Schindelin
Linux kernel 2.6.17-5mdv   2 users,  load average: 0.04, 0.11, 0.14

[Jocr-devels] GOCR-0.43 on OpenBSD4.0

[<sc...@ma...>]

I have a directory named gocr-0.43 from which I have tried to run
./configure and I see this in the output:
checking for library containing pnm_readpnminit... no
 * * * try option --with-netpbm=PATH
When I try to run make I get this:
# make
make -C src all
make: unknown option -- C
usage: make [-BeiknPqrSst] [-D variable] [-d flags] [-f makefile]
            [-I directory] [-j max_jobs] [-m directory] [-V variable]
            [NAME=value] [target ...]
*** Error code 2

Stop in /root/gocr-0.43 (line 82 of Makefile).

Also when I try make install I get this:
# make install
make -C src install
make: unknown option -- C
usage: make [-BeiknPqrSst] [-D variable] [-d flags] [-f makefile]
            [-I directory] [-j max_jobs] [-m directory] [-V variable]
            [NAME=value] [target ...]
*** Error code 2

Stop in /root/gocr-0.43 (line 124 of Makefile)

I have netpbm installed via the ports/package system of OpenBSD 4.0
Is there someone that can give me a tip on what I can do next?
Thanks for your time.
Scott Borthwick

Re: [Jocr-devels] The pixel() function and thresholds

[Rupert S. <rup...@li...>]

Oops! Should have checked a bit more! This version scales up to a
virtual bit depth of 1024 and should work for maxval>1!

Rupert

Re: [Jocr-devels] The pixel() function and thresholds

[Rupert S. <rup...@li...>]

I don't really understand the code, as I said, but this seems to work.
Am I missing something important?

Rupert

Re: [Jocr-devels] The pixel() function and thresholds

[Joerg <Joe...@UR...>]

On Fri, 15 Dec 2006, Rupert Swarbrick wrote:

> 1.
> 
> I've been trying to get Conjecture to compile when gocr is using libpbm.
> This would be easy, apart from the fact that there's a namespace
> collision that you've avoided via only including libpbm in a file that
> doesn't include gocr.h
> 
> The problem is that you define the function pixel() in gocr.h and libpbm
> typedefs pixel in pam.h. The problems do go away if we rename pixel() to
> getpixel() in gocr. I don't know whether you'd consider doing it, but
> I'd guess that this namespace collision might rear its ugly head in
> future in your code anyway otherwise.

no problem, I will rename it.
 
> 2.
> 
> The reason I was doing this in the first place is that the thresholding
> algorithm in gocr isn't working for "ocr-a.pnm" in the Conjecture
> tarball. Sadly it appears that the problem wasn't with the file-loading
> (which is why I was trying to do netpbm to see whether that fixed it).
> I'm continuing to investigate...

I dont have problems with ocr-a.png on my system.
But tell me if you find something.

Joerg.

[Jocr-devels] The pixel() function and thresholds

[Rupert S. <rup...@li...>]

1.

I've been trying to get Conjecture to compile when gocr is using libpbm.
This would be easy, apart from the fact that there's a namespace
collision that you've avoided via only including libpbm in a file that
doesn't include gocr.h

The problem is that you define the function pixel() in gocr.h and libpbm
typedefs pixel in pam.h. The problems do go away if we rename pixel() to
getpixel() in gocr. I don't know whether you'd consider doing it, but
I'd guess that this namespace collision might rear its ugly head in
future in your code anyway otherwise.

2.

The reason I was doing this in the first place is that the thresholding
algorithm in gocr isn't working for "ocr-a.pnm" in the Conjecture
tarball. Sadly it appears that the problem wasn't with the file-loading
(which is why I was trying to do netpbm to see whether that fixed it).
I'm continuing to investigate...

Regards,

Rupert

Re: [Jocr-devels] A gcc pointer cast error

[Joerg <Joe...@UR...>]

Thanks. I will apply it next week.

Joerg

On Fri, 15 Dec 2006, Rupert Swarbrick wrote:

> Just to say that the current cvs sources die at compilation due to line
> 32, which needs an explicit pointer cast.
> 
> Here's the output of 'cvs diff src/progress.c' after a fix:
> 
> Index: src/progress.c
> ===================================================================
> RCS file: /cvsroot/jocr/jocr/src/progress.c,v
> retrieving revision 1.2
> diff -r1.2 progress.c
> 32c32
> <   pc = malloc( sizeof(progress_counter_t) );
> ---
> >   pc = (progress_counter_t*)malloc( sizeof(progress_counter_t) );
> 
> Thanks,
> 
> Rupert
> 
> 

[Jocr-devels] A gcc pointer cast error

[Rupert S. <rup...@li...>]

Just to say that the current cvs sources die at compilation due to line
32, which needs an explicit pointer cast.

Here's the output of 'cvs diff src/progress.c' after a fix:

Index: src/progress.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: /cvsroot/jocr/jocr/src/progress.c,v
retrieving revision 1.2
diff -r1.2 progress.c
32c32
<   pc =3D malloc( sizeof(progress_counter_t) );
---
>   pc =3D (progress_counter_t*)malloc( sizeof(progress_counter_t) );

Thanks,

Rupert

Re: [Jocr-devels] Fwd: compiling gocr 0.43 on MS Windows

[Peter M. <fee...@se...>]

Hi Joerg,

Thank you for the answer. For me the issue is roughly that I
expect that in the long run all major OCR engines will have
deskewing and other image preparation techniques built-in for
use with mobile cameras. I could try and develop my own code
for that and apply that in The vOICe before invoking an OCR
engine like GOCR, but by the time that OCR engines can do it
my effort to compensate for OCR engine limitations will be
largely wasted, and it is a non-trivial task to do it well.

BTW, rotation compensation is not good enough. You will need
a more general perspective correction when the snapshot was
taken not quite perpendicular to the print surface (assuming
still that the print surface is flat). See for instance

    Perspective Correction Methods for Camera-Based Document Analysis
    http://www.m.cs.osakafu-u.ac.jp/cbdar/proceedings/papers/P6.pdf

I do agree that it makes sense to make the techniques optional,
e.g., to save on CPU time in case one already knows that one is
using a flatbed scanner that does not need any of this. It is
also very attractive to have the perspective correction as a
separate tool such that one can apply it with any OCR engine.
In principle it could even be a project separate from GOCR,
but I'm not aware of any existing open source project for this,
while a seamless integration also has merits for the end user.

Of course it is fine that you first focus on finishing the
vectorization, and I am pleased with the improved recognition
in going from GOCR 0.41 to 0.42 and 0.43.

Thanks,

Peter Meijer


Mobile OCR, Face and Object Recognition
http://www.seeingwithsound.com/ocr.htm



Joerg wrote:
> 
>> Will you be adding deskewing in one of the next versions?
> 
> I think I will need some more time, because its better to finish
> vectorisation first. I dont want rotate pixel images, because its slow and
> has a lot of side effects (quantization errors, regions which rotate out
> of the image and so one).
> May be one could try a three-step-process:
> 1) calling gocr -v 1 and grep the rotation angle
> 2) do back rotation using a seperate specialized tool (pnmrotate?)
> 3) call gocr again
> 
> I tried
> 
> pngtopnm jocr/examples/rotate45.png > a.pnm
> pnmrotate -45 a.pnm >aa.pnm
> ./gocr -v 39 aa.pnm 2>o
> 
> Recognition was about 50%, may be because of the antialiazing.
> If I double the size of image before rotating it, its nearly perfectly
> recognized ... hmm ... thats impressive.
> 
> May be I should output the angle and a recommendation how to call
> pnmrotate and pnmscalefixed which can be used by a outside script
> or calling pnmrotate and gocr via pipe recursively?
> 
> What do you think would be more practical?
> 
> Regards, joerg.

Re: [Jocr-devels] Fwd: compiling gocr 0.43 on MS Windows

[Joerg <Joe...@UR...>]

> Will you be adding deskewing in one of the next versions?

I think I will need some more time, because its better to finish 
vectorisation first. I dont want rotate pixel images, because its slow and 
has a lot of side effects (quantization errors, regions which rotate out 
of the image and so one). 
May be one could try a three-step-process:
1) calling gocr -v 1 and grep the rotation angle
2) do back rotation using a seperate specialized tool (pnmrotate?)
3) call gocr again

I tried 

pngtopnm jocr/examples/rotate45.png > a.pnm
pnmrotate -45 a.pnm >aa.pnm
./gocr -v 39 aa.pnm 2>o

Recognition was about 50%, may be because of the antialiazing.
If I double the size of image before rotating it, its nearly perfectly 
recognized ... hmm ... thats impressive.

May be I should output the angle and a recommendation how to call 
pnmrotate and pnmscalefixed which can be used by a outside script
or calling pnmrotate and gocr via pipe recursively?

What do you think would be more practical?

Regards, joerg.

 

Re: [Jocr-devels] v0.43 updgrade fails @ 'make'; v0.41 'ok'

[snowcrash+jocr <sch...@gm...>]

> The same (attached) patch should work for osx

works perfectly.

and, downstream build of software *using* gocr-0.43 also works w/o error.

thanks!

Re: [Jocr-devels] Fwd: compiling gocr 0.43 on OS/2

[Franz B. <fb...@gm...>]

On Wed, 13 Dec 2006 16:48:03 +0100 (CET), Joerg Schulenburg wrote:

> I have add <time.h> in progress.h, which was simply forgotten and gcc did 
> not complain (see attached patch).

compiles fine now, with the patch, the only warnings I get are:

 unicode.c: In function `decode':
 unicode.c:1275: warning: comparison is always true due to limited range of data type
 unicode.c:1282: warning: comparison is always true due to limited range of data type
 unicode.c:1290: warning: comparison is always true due to limited range of data type
 unicode.c:1299: warning: comparison is always true due to limited range of data type

It seems  wchar_t  is  unsigned short on  OS/2 at the moment, if I interpreted the comments
in the gcc-headers here correctly.

> I dont see a reason, to include time.h in list.c.
> Can you tell me what the compiler is complaining about list.c?

Your patch moved  '#include time.h' from progrsss.c to progress.h
(which is included in list.c ) so there is no reason anymore now.

Thanks for including the patches.
Franz

Re: [Jocr-devels] Fwd: compiling gocr 0.43 on MS Windows

[Peter M. <fee...@se...>]

Hi Joerg,

 > Can you tell me, why inline => __inline is necessary?

It is a Microsoft specific syntax, see

    http://msdn2.microsoft.com/en-us/library/z8y1yy88.aspx

"The inline keyword is available only in C++". I compile gocr
as non-C++. Otherwise both inline and __inline should work
(I didn't verify this). You may put in your ocr0.h

#ifdef WIN32
#define inline __inline
#endif

Also notice the inconsistency between pgm2asc.c and pgm2asc.h
in using "const" in pgm2asc.h

    wchar_t *wcschr (const wchar_t *wcs, wchar_t wc);

and not in pgm2asc.c

    wchar_t *wcschr (wchar_t *wcs, wchar_t wc)

Will you be adding deskewing in one of the next versions?

Peter Meijer


Seeing with Sound - The vOICe
http://www.seeingwithsound.com


Joerg Schulenburg wrote:
> Hi,
> 
> On Wed, 13 Dec 2006, Peter Meijer wrote:
> 
>> The Microsoft Windows executable for GOCR 0.43 is now also available,
>> ... while changing inline => __inline in ocr0.h, as with
>> previous releases.
> 
> Can you tell me, why inline => __inline is necessary?
> 
> It seems to me nonstandard to do so.
> Would a 
> 
> #ifndef __GNUC__
> static inline
> #endif
> int sq(...) {...}
> 
> help?
> 
> Joerg

Re: [Jocr-devels] Fwd: compiling gocr 0.43 on MS Windows

[Joerg S. <Joe...@UR...>]

Hi,

On Wed, 13 Dec 2006, Peter Meijer wrote:

> The Microsoft Windows executable for GOCR 0.43 is now also available,
> ... while changing inline => __inline in ocr0.h, as with
> previous releases.

Can you tell me, why inline => __inline is necessary?

It seems to me nonstandard to do so.
Would a 

#ifndef __GNUC__
static inline
#endif
int sq(...) {...}

help?

Joerg

Re: [Jocr-devels] v0.43 updgrade fails @ 'make'; v0.41 'ok'

[Joerg S. <Joe...@UR...>]

The same (attached) patch should work for osx

Joerg.

On Tue, 12 Dec 2006, snowcrash+jocr wrote:

> i've been building/using
> 
>    gocr-0.41
>    gocr-0.41-pgm.patch
> 
> on osx.
> 
> updgrading to v0.43,
> 
>     ./configure
> 
> is error free, but,
> 
>     make
> 
> fails at,
> 
> make
> make -C src all
> gcc -g -O2 -I/usr/local/netpbm/include  -I../include -DHAVE_CONFIG_H
> -c -o list.o list.c
> In file included from list.c:61:
> progress.h:21: error: parse error before 'time_t'
> progress.h:21: warning: no semicolon at end of struct or union
> progress.h:22: warning: data definition has no type or storage class
> progress.h:24: warning: data definition has no type or storage class
> progress.h:35: error: parse error before '*' token
> progress.h:35: warning: data definition has no type or storage class
> progress.h:37: error: parse error before '*' token
> progress.h:39: error: parse error before 'progress_counter_t'
> list.c: In function 'list_sort':
> list.c:266: error: 'pc' undeclared (first use in this function)
> list.c:266: error: (Each undeclared identifier is reported only once
> list.c:266: error: for each function it appears in.)
> make[1]: *** [list.o] Error 1
> make: *** [src] Error 2
> 
> 
> again, v0.41 + patch builds fine.
> 
> thanks.
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Jocr-devels mailing list
> Joc...@li...
> https://lists.sourceforge.net/lists/listinfo/jocr-devels
> 
> 

Re: [Jocr-devels] Fwd: compiling gocr 0.43 on OS/2

[Joerg S. <Joe...@UR...>]

On Tue, 12 Dec 2006, Franz Bakan wrote:

> Hi,
> 
> as I didn't get a reply for my mali to Joergs gmx adress
> I report again to this list, which is probably the better place anyway.
> 
> gocr 0.43 compiles fine on OS/2 with two minor modifications:
> 
> 1.
>  src/list.c
> needs 
> 
>  #include <stdlib.h>
> +#include <time.h>
>  #include "list.h"

I have add <time.h> in progress.h, which was simply forgotten and gcc did 
not complain (see attached patch).
I dont see a reason, to include time.h in list.c.
Can you tell me what the compiler is complaining about list.c?
 
> 2.
>  src/Makefile.in
> needs
> 
> +SHELL = @SHELL@
>  EXEEXT = @EXEEXT@
> 
> Would be nice if these two lines could make it into the sources.
> 

I included the SHELL.
 
Joerg