|
From: | Antonio Diaz Diaz |
Subject: | [Bug-ocrad] Re: OCRAD project: library is needed |
Date: | Wed, 09 Jun 2010 18:11:07 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.7.11) Gecko/20050905 |
Dmitry Katsubo wrote:
Maybe you are using features of ocrad not in "ocradlib.h"? In this case, I think the right thing is to add those features to "ocradlib.h".Yes, you are right. In OSRA module [1] we are using classes Control, Rectangle, Character, Blob. You are welcome to provide any nice solution, how to share thee classes. Or maybe you can give an advise, how to use OCRAD code more correctly. [1]http://osra.svn.sourceforge.net/viewvc/osra/trunk/osra_ocr.cpp?view=markup
As explained here[1], Blob is an internal type of ocrad. It is neither documented not guaranteed to remain stable. Moreover, Blob has some requirements, like pixel connectivity, that could make osra inestable if your data does not meet them.
[1] http://lists.gnu.org/archive/html/bug-ocrad/2009-12/msg00003.htmlLines 195-220 of osra_ocr.cpp already use the public API from ocradlib.h. I think they are comented out because Igor Filippov found they produce worse results than directly using Blob. I have to investigate this, and it would be useful if someone could provide me with an image showing the bug (correctly recognized as Blob, but not recognized by new API).
I need to include most of the headers, plus some extra ones (as common.h should include <stdio.h>, character.h should include <vector>, blob.h should include "bitmap.h", ...). Maybe you can fix this in headers, as I think, header should be self-contained, no matter how it is included.
Sorry, but I never do nested includes. It also would be of no use once all the needed features are declared in "ocradlib.h" and the private headers are no more used by OSRA.
Regards, Antonio.
[Prev in Thread] | Current Thread | [Next in Thread] |