> Hi Andres,
>
> > How can a serious project depend on ONLY ONE guy (that Ray) who is missing
> > ? …and he doesn’t answer emails for MONTHS, is unreachable and leaved the
> > project LOCKED as rthomas said ? If this project should rely on only one
> > person, he doesn’t seem to be in conditions to do that. What should be the
> > reason to continue waiting for him ?
>
> Sometimes this pattern can be fine, when a project reaches a certain
> maturity. But for Tesseract i think it's not okay yet.
>
> > I don’t know OCRopus but
> > here:http://googlesystem.blogspot.com/2007/04/open-source-ocr-software-spo...they
> > tell that it’s partly based on Tesseract…I’m curious about how the
> > Tesseract modifications are being managed. Anyone knows something about
> > that ?
>
> i have no idea, i'm totally new to these two projects. i'm relying on people
> reading the mailing list for such information.
>
> > Perhaps if some of you are used to write to OCRopus list it would be a good
> > idea to ask there about what’s the reason of the lack of support here.
>
> i believe there has to have at least one or two people who are subscribers of
> the two lists, reading theses lines. Maybe we also need someone in this
> "fork" project, to help us discussing with OCRopus guys.
>
> > I mostly agree with you Pierre about what you said about relying on extern
> > libraries, but I think that there is an exception to be made, the boost
> > libraries, don’t you agree?
>
> Yes, boost could do the trick, or any library of this kind (i myself prefer
> Qt, but that's a matter which is too early to discuss yet).
>
> > I encourage those who had been following this thread silently as me to
> > share their opinion.
>
> Absolutelly, and again: i would appreciate a list of potential contributors,
> because again: forking Tess is clearly not a one-man job.
>
> Cheers,
> Pierre.
I share a rather other point of view of what should be an universal C+
+ OCR engine.
Python is great on "Intel" or more precisely on Google Apps Engine.
Do you known about Windows Mobile 4, 5 or 6? Do you know about Nokia?
Or AS/400 ? Beagleboard (that I don't know) ?
These kind of platforms doesn't like STL, BOOST, Qt and I'm sure an
OCR doesn't need these kind of library. What for ? For string class,
vectors, list, map...
An OCR doesn't need very advanced string class, vectors, list and map
we can find more portable implementation.
My point of view is a super very simple code, that only do OCR. No I/
O, no image decompression, nothing else than OCR.
I never use smart pointers and never get a memory leak.
Most platform already have image loading libraries (jpeggroup,
libtiff, gdiplus, ...)
Imagine OCR API begin with OCR_
int main(int argc, char **argv)
{
// Parse aguments
OCR_Params oparams; // Contain language def, OCR params
LoadParametersFromFile(&oparams); // Or from a stream, a db, ...
developer specific
OCR_Image image; // A simple 24 bit image format
LoadImageFromFile(&image); // Decode JPEG, TIFF with platform
library
OCR_Result result;
if (OCR_DoOcr(&oparams, &image, &result))
{
// Use the result
for (int i=0; i<result.WordCount; i++)
{
OCR_Word word;
result.GetWord(i, &word);
}
}
OCR_CleanResult(&result); // Perhaps needed
}
No new, no delete, no memory leak
Very easy to call from Java, Phyton
OCR_DoOCR is basic C++ code that compile everywhere. #ifdef isn't
needed in source code
This is exactly my point point of view of what a portable OCR should
be.
Remi
--
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.
