I could supply a tesseract-ocr-3.01-win32-lib-include-dirs.zip similar to my leptonica-1.68-win32-lib-include-dirs.zip that would also contain the tesseract libraries and include files. (See my question on the header files later on). However, I am NOT volunteering to maintain future tesseract-ocr Win32 releases. *Suggested library names* static libraries: libtesseract301-static.lib libtesseract301-static-debug.lib DLLs: libtesseract301.lib (import library) libtesseract301.dll libtesseract301d.lib (import library) libtesseract301d.dll
*Questions* Are the 12 sub-library static libraries still necessary? The solution would be much less complicated (especially when converting to VS2010) if you just have one project that builds the entire library using all the source files and headers from the existing projects. I tried to do this by copying all the files to a new project but got an error that indicated that some file name collisions occurred. (I'll have to write a short python script to figure out the duplicate names).
When I "Clean" the tesseract project, all the sub-library projects also get Cleaned? I don't know if this is some strange result of having tesseract be dependent on the libraries? I don't notice this happening when I'm building the Leptonica example programs. Given the other slightly strange behavior I'm seeing, I'm leaning towards just creating a new tesseract.sln from scratch. It appears that DLLSYM is no longer really needed? The only things that should be exported to the DLL are now marked with TESSDLL_EXPORTS instead? So ccstruct/hpddef.h can be removed?
For my trial DLL I removed the inclusion of cctutil/notdll.h from tesseract/tesseractmain.h. However, maybe that isn't necessary since it only sets DLLSYM?
Apps built against these new libraries will also, of course, need access to the include files. This isn't such a big deal with Leptonica since there are only a few. However, libtesseract seems to require about 265 header files? I suppose I could write a short python script to automatically copy all the headers from the 12 sub-library directories to a "main" include/tesseract directory (similar to my include/leptonica directory).
When I "Clean" the tesseract project, all the sub-library projects
also get Cleaned? I don't know if this is some strange result of
having tesseract be dependent on the libraries? I don't notice this
happening when I'm building the Leptonica example programs. Given the
other slightly strange behavior I'm seeing, I'm leaning towards just
creating a new tesseract.sln from scratch.
It appears that DLLSYM is no longer really needed? The only things
that should be exported to the DLL are now marked with TESSDLL_EXPORTS
instead? So ccstruct/hpddef.h can be removed?
For my trial DLL I removed the inclusion of cctutil/notdll.h from
tesseract/tesseractmain.h. However, maybe that isn't necessary since
it only sets DLLSYM?
Apps built against these new libraries will also, of course, need
access to the include files. This isn't such a big deal with Leptonica
since there are only a few. However, libtesseract seems to require
about 265 header files? I suppose I could write a short python script
to automatically copy all the headers from the 12 sub-library
directories to a "main" include/tesseract directory (similar to my
include/leptonica directory).
Shouldn't baseapi.h (instead of baseapi.cpp) include
resultiterator.h? Apps using libtesseract should really only have to
include one file (or two if they also want to use Leptonica functions).
My python program copies the union of the following files to the
"public" include folder:
baseIncludeSet = {
r"api\baseapi.h",
r"api\apitypes.h",
r"ccstruct\publictypes.h",
r"ccmain\thresholder.h",
r"ccutil\unichar.h",
r"ccutil\platform.h",
r"api\resultiterator.h",
r"api\pageiterator.h",
r"api\apitypes.h",
}
strngIncludeSet = {
r"ccutil\strngs.h",
r"ccutil\memry.h",
r"ccutil\host.h",
r"ccutil\serialis.h",
r"ccutil\errcode.h",
r"ccutil\fileerr.h",
}
genericVectorIncludeSet = {
r"ccutil\genericvector.h",
r"ccutil\tesscallback.h",
r"ccutil\errcode.h",
r"ccutil\host.h",
r"ccutil\helpers.h",
r"ccutil\ndminx.h",
}
blobsIncludeSet = {
r"ccstruct\blobs.h",
r"ccstruct\rect.h",
r"ccstruct\points.h",
r"ccstruct\ipoints.h",
r"ccutil\elst.h",
r"ccutil\host.h",
r"ccutil\serialis.h",
r"ccutil\lsterr.h",
r"ccutil\ndminx.h",
r"ccutil\tprintf.h",
r"ccutil\params.h",
r"viewer\scrollview.h",
r"ccstruct\vecfuncs.h",
}
Currently 28 files are in the include\tesseract directory.
I decided to include blobs.h since it seemed to me people might want
blob information (and tesseractmain.h includes it).
I'm not positive this is the minimal set of headers files needed, but
I have successfully built and run a sample program that includes:
#include "allheaders.h"
#include "baseapi.h"
#include "resultiterator.h"
#include "strngs.h"
#include "blobs.h"
The supplied sample app was created using the VS2008 "Win32 Console
Application" Project Wizard and then just copying most of
tesseractmain.cpp. It's project settings correctly refer to the
"public" include & lib directories using relative paths. The
include\tesseract_versionnumbers.vsprops Property Sheet is used to
avoid explicit library version number dependencies. Precompiled
headers are used. LIB_Debug, LIB_Release, DLL_Debug, and DLL_Release
build configurations are supported.
I believe all the pieces are now available for someone to create an
official tesseract-3.01-win32-include-lib.zip. This would provide all
the files people need to link to libtesseract without having to
compile it themselves (or download the full source). OTOH, I'm not
sure how useful this will be? Most people who are seriously using
libtesseract & Leptonica should download & build them on their own.
I'm still tweaking my python script but I'll make that available in
the near future. I want to add the ability to compare the libtesseract
Project files with the actual files in the "sub-library" directories.
This should make it easier to keep the VS2008 solution in synch as the
underlying files are deleted/added.
Oooops. Removed it.
> As far as I quickly check on internet 'afxres.h' is part of 'Microsoft
> Platform SDK'[1]. Is it really needed? I just try to avoid another
> dependancy...
>
Hmmmm. I'm using VS2008 NOT the VC++ 2008 Express Edition. On my
system I see afxres.h in C:\Program Files\Microsoft Visual Studio
9.0\VC\atlmfc\include\. But I gather that the Express Edition doesn't
come with support for MFC and therefore probably doesn't have this
folder? [1]
You can just manually change:
#include "afxres.h"
to
#include "windows.h"
However, any time someone changes the version resource using the
VS2008 Resource Editor, that line will get changed back again. I also
gather that the Express Edition doesn't come with any sort of Resource
Editor? You can just edit the various *.rc files directly to fix the
VS_VERSION_INFO VERSIONINFO section. Alternatively, you could use
something like http://www.resedit.net but that also requires the
Windows Platform SDK.
I'll add a short section to my readme.txt file on using the Express
Edition and that error message.
> Another issue is regarding svn commit ;-) I am fine with remove leptonica
> from tesseract source and keep it as external library. But tesseract
> relevant files (\include\leptonica_versionnumbers.vsprops,
> \include\tesseract_versionnumbers.vsprops and \include\stdint.h ) should be
> moved to \tesseract-3.01\vs2008 directory structure...
I'll make a copy of these in a vs2008\include directory. However, the
Project files use a relative path like "..\..\..\include" to reference
the C:\BuildFolder\include directory. Therefore the source package for
Win32 needs to be structured like I have it (but with the additional
vs2008\include directory) That will make it easy to check the vs2008
directory into the SVN repository but still let people just extract
the archive and not have to worry about copying the vs2008\include
directory to C:\Builder\Include.
[1] ""How useful is Visual C++ 2008 Express Edition for commercial
use?"" http://jayakrishnan.livejournal.com/3521.html
On Wed, Nov 9, 2011 at 7:02 AM, zdenko podobny <zde...@gmail.com> wrote:Oooops. Removed it.
> Thanks for you files.
> I just started my tests and found these issues:
>
> fatal error RC1015: cannot open include file 'afxres.h'
> project 'cntraining' includes 'cntraning.h' but there is no such file in ;-)
>
Hmmmm. I'm using VS2008 NOT the VC++ 2008 Express Edition. On my
> As far as I quickly check on internet 'afxres.h' is part of 'Microsoft
> Platform SDK'[1]. Is it really needed? I just try to avoid another
> dependancy...
>
system I see afxres.h in C:\Program Files\Microsoft Visual Studio
9.0\VC\atlmfc\include\. But I gather that the Express Edition doesn't
come with support for MFC and therefore probably doesn't have this
folder? [1]
You can just manually change:
#include "afxres.h"
to
#include "windows.h"
However, any time someone changes the version resource using the
VS2008 Resource Editor, that line will get changed back again. I also
gather that the Express Edition doesn't come with any sort of Resource
Editor?
You can just edit the various *.rc files directly to fix the
VS_VERSION_INFO VERSIONINFO section. Alternatively, you could use
something like http://www.resedit.net but that also requires the
Windows Platform SDK.
I'll add a short section to my readme.txt file on using the Express
Edition and that error message.
I'll make a copy of these in a vs2008\include directory. However, the
> Another issue is regarding svn commit ;-) I am fine with remove leptonica
> from tesseract source and keep it as external library. But tesseract
> relevant files (\include\leptonica_versionnumbers.vsprops,
> \include\tesseract_versionnumbers.vsprops and \include\stdint.h ) should be
> moved to \tesseract-3.01\vs2008 directory structure...
Project files use a relative path like "..\..\..\include" to reference
the C:\BuildFolder\include directory. Therefore the source package for
Win32 needs to be structured like I have it (but with the additional
vs2008\include directory) That will make it easy to check the vs2008
directory into the SVN repository but still let people just extract
the archive and not have to worry about copying the vs2008\include
directory to C:\Builder\Include.