The new "visibility" attribute, TESS_API, has been successfully
applied to classes to limit the symbols in the libtesseract shared
library/DLL. This results in better portability between unix and
Windows (libtesseract.so and libtesseract.dll now have the same
exported symbols). See the "Visibility" thread for details [1].
Zdenko and I have also demonstrated (to ourselves anyway) that the
tesseract-ocr training apps can theoretically be dynamically linked
with a "visibility"-enabled libtesseract. However, we are going to
abandon further work on linking training apps with the shared
library/DLL version of libtesseract (for 3.02 they will have to link
with the static version of libtesseract). Our reasons:
+ Ray Smith has said there will be major changes in how training apps
are built. So is there any point in investing too much time on the
"dynamically linked training apps" issue for now?
+ Using a brute force approach (make classes visible until link errors
go away) requires making too many classes visible.
+ Instead of blindly making classes visible based on link errors, we
should instead understand the class dependencies and see if they
can be "removed" via forward declarations. This takes time and deep
understanding of the class dependencies.
+ There are unanswered questions about making individual methods
visible vs making the entire class visible. We need time to
understand the underlying mechanics of what this is actually doing
(vtable impact?).
+ There are questions about fixing the VS2008 C4251 warning: "Class A
needs to have dll-interface to be used by clients of class
B". Other than for templates which shouldn't have TESS_API applied
to them, is this worth doing? What are the implications if we
ignore this warning?
For 3.02, I suggest focusing on:
1) The "public" include issue. Are we going to make a tesseract/include
directory?
2) Making sure TessBaseAPI lets programmers do what they can reasonably
expect to do. For example, it was decided that the PageIterator and
ResultIterator classes needed to be made visible in libtesseract.
For me, this means finishing my VS2008 APIExamples Solution so I can
learn more about TessBaseAPI.
3) In addition to possibly increasing the number of visible classes, we
should also look into removing them.
For example, with the previous visibility (before we added
PageIterator & ResultIterator), it would have been pretty easy to
remove the STRING class (just convert STRING to char* in the
api). GenericVector<STRING> could have been just an array of char* or
we could have used a Leptonica string array instead.
However, adding PageIterator & ResultIterator classes might have
changed this. That is, in order to effectively use those two
additional classes, maybe there are now too many uses of STRING &
GenericVector<STRING> to fix?
We should also look into reducing the number of visible classes by
forward declaring classes that end users really don't need to know
about. If a header file only uses pointers to a class and never
expects the user to dereference them, then that class is a candidate
for forward declaration.
Simplifying the API means it is easier to understand and document. It
also means a smaller public interface that we have to keep constant to
maintain compatibility.
4) Improving the documentation (On Windows initially).
+ How to install & build tesseract (mostly done, at least for Windows).
+ How to use tesseract.
+ More info on config file use.
+ More HOWTO examples of special cases.
+ Complete details on pagesegmode.
+ Document common/useful config file params.
+ Other topics?
+ How to program with libtesseract.
+ How to preprocess PIX before calling api.SetImage() (mostly done)
+ What sorts of info one can get back from libtesseract?
(work-in-progress).
+ Other topics?
+ What to do when things go wrong (and they still do at this point).
+ How to debug tesseract crashes.
+ How to train tesseract.
By the time I am done, no one will be able to say there isn't any
documentation on tesseract-ocr (on Windows anyway).
5) Fix portability issues.
For example, the config files don't work right if they use Windows
line ending. We need to strip config file lines of trailing
whitespace.
In ccutil/mainblk.cpp, automatically add dirsep char if it's not
already last char of TESSDATA_PREFIX. This is an easy error to make
on Windows and results in unnecessary "But I do have TESSDATA_PREFIX
set" questions.
Due to its importance, maybe we should automatically print out the
value of the calculated datadir to reduce support questions?
Add ScrollView functionality on Windows?
6) Start writing some unit tests. Decide on what unit testing framework
to use and start using it.
7) Fix bugs.
-- Tom
[1]
http://groups.google.com/group/tesseract-dev/browse_thread/thread/976645ae98189127
--
You received this message because you are subscribed to the Google
Groups "tesseract-ocr" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/tesseract-ocr?hl=en
