Plans for tesseract 5.x.y

[amitdo]

I suggest to focus on 5.x for 2022 at least.

That means we should not break the API (and ABI?). Use C++17, not C++20/C++23.

[stweil]

What about releasing a 5.0.1 after Christmas at the end of December? I think there are several fixes since 5.0.0 which would be good for a new release.

[amitdo]

Mind reader :-)
I was about to suggest to release 5.0.1 before year end. It would be nice if we can fix #3683 before releasing 5.0.1.

[amitdo]

Right before tagging 5.0.1, you can update this sentence from the README:

The latest stable version is 5.0.0, released on November 30, 2021.

[egorpugin]

What should be added into v5?
5.x changes could be merged into branch and cherry picked into v6 main.

[stweil]

We already have a wish list for improved training, a lot of issues with layout detection, want improved logging, and much more. Maintaining two branches did not work good with 4.x, and I am afraid it would not work better with 5.x.

[egorpugin]

Maybe keep 5.0 as is? It is a good release with a number of changes.
Everything else will go straight into 6?

[amitdo]

https://github.com/tesseract-ocr/tessdoc/blob/main/ReleaseNotes.md#changes-made-since-last-release

[amitdo]

What about releasing a 5.0.1 after Christmas at the end of December? I think there are several fixes since 5.0.0 which would be good for a new release.

Do you plan to release 5.0.1 next week?

[stweil]

Yes, unless we discover that something very important is still missing.

[stweil]

It would be nice if we can fix #3683 before releasing 5.0.1.

There is still no fix, and I have no clang-cl, so I cannot look for a fix myself. Should we release 5.0.1 without a fix? Are other things missing for 5.0.1 (besides updating of the documentation)?

[egorpugin]

clang-cl is not worth it currently.

[amitdo]

You can release 5.0.1 without the clang-cl fix.

[stweil]

Release 5.0.1 is now online.

[stweil]

The next release could be a new minor version 5.1.0 with new features, maybe end of January (unless there is an urgent need for a bug fix release 5.0.2). I want to have especially image information in ALTO and hOCR output (see PR #3710 which implements that for hOCR), maybe more from the project list. The new minor release would also disable OpenMP by default for autoconf builds, too.

[amitdo]

https://packages.ubuntu.com/search?keywords=tesseract-ocr

@AlexanderP,

Are you going to update Ubuntu 22.04 to 5.0.1 soon? The feature freeze date is February 24.

[AlexanderP]

@amitdo

i uploaded:

• tesseract-ocr 4.1.3 and 5.0.1 https://mentors.debian.net/package/tesseract
• tesseract-lang 1:5.0.0~git39-6572757-1 https://mentors.debian.net/package/tesseract-lang/

I hope @jbreiden will upload them to debian.

[amitdo]

Hi @AlexanderP,

I hope @jbreiden will upload them to debian.

From https://tracker.debian.org/pkg/tesseract :

maintainer: [Alexander Pozdnyakov]

So, why can't you directly push new versions of Tesseract to Debian?

[stweil]

I'd like to create a new release Tesseract 5.1.0 soon. Originally I had planned it for end of January.

Are there any contributions or important bug fixes which should be included still pending (then I'd wait), or can we release now?

[Shreeshrii]

I suggest you go ahead with 5.1.0 now.

I would like to see improvements related to training and evaluation implemented, but they could go in a future release.

[stweil]

Release 5.1.0 is now available.

[AlexanderP]

@amitdo no rights to upload to debian

[stweil]

There are now several fixes and improvements in git master, so I think it's time for a new release 5.1.1.

@egorpugin, is it possible to fix the CI sw build which is currently failing?

Are there any other contributions or important bug fixes which should be included still pending (then I'd wait), or can we release now? Ideally #3782 should also be included.

[egorpugin]

Yes, I'll check.

[zdenop]

Unfortunately windows build does not work (for me): I tried Clang (14) and MS Visual Studio (2019). Here are logs:
clang_build.zip
msvc_build.zip

[amitdo]

cmake-win64 action fails (since March 29).

cmake and vcpkg actions pass.

[egorpugin]

I fixed sw build in ci.
Zdenko, is it fails only on VS2019? Can you check VS2022.

[zdenop]

cmake-win64 action has some strange error: it fails already on unzipping zlib (or maybe even earlier: during setting up shell?)

And vcpkg is IMO not building the HEAD, but 5.1.0:

And I see this with HEAD:

[zdenop]

@egorpugin: VS2019 is quite heavily used. I would suggest supporting it with the next release...

[kloczek]

5.4.1 has one issue. It uses bundled googletest included in source tree as submodules.
Why not use system installed gtest? 🤔 All distros provides gtest ..

[amitdo]

@kloczek,

It's not the right place to discuss the gtest issue.

The gtest issue is not new and we discussed it in the past in #2838 and #3679.

[stweil]

It's time for a new bug fix release. Is there anything urgent which should be included or fixed in the next release?

[zdenop]

I am in the process of creating cmake files with autotools (leptonica has it already) This is not critical, but it takes more time than I expect it...

[stweil]

... and it currently breaks the autotools builds.

[zdenop]

This is unrelated topic as cmake generate tesseract.pc from other template (tesseract.pc.cmake) Maybe it could be unified, but this is not topic for now.

[amitdo]

@stweil, please go ahead with a new release.

[stweil]

I'll try to fix the CI failures before tagging a new release.

[egorpugin]

I've checked this issue
https://github.com/tesseract-ocr/tesseract/pull/4330/files

TessBaseAPI::GetIterator() and some other methods (like GetUTF8Text()) return raw memory.
It would be nice so they return unique_ptr<T> instead.
Doing this we clearly state memory management of returned objects instead of documentation mention.

I propose to impove memory management of public APIs in tess v6 because it is API breakage.

In addition C API implementation will be updated from

TessResultIterator *TessBaseAPIGetIterator(TessBaseAPI *handle) {
  return handle->GetIterator();
}

to

TessResultIterator *TessBaseAPIGetIterator(TessBaseAPI *handle) {
  return handle->GetIterator().release();
}

So C API will be retained the same.

---

So,

1. How and when do we want API breaking changes?
2. What other public API/ABI changes do we want? We need a tracking issue for it? Do we have one already?
3. I think we have enough 5.x.x releases already, maybe switch master branch to v6 and create separate v5 branch for small fixes?

[stweil]

I just added #4336, and we can discuss and track API changes there.

[amitdo]

@stweil, when do you plan to make a new release?

[stweil]

Soon (this weekend) unless there is something open or missing which requires more time. The new release will contain enough changes to justify the move to 5.5.0.

[stweil]

Meanwhile release 5.5.0 is available. Thank you to everybody who contributed in any way.

[stweil]

I think it's time for a new release 5.5.1, maybe on 2025-05-01.
Are there important things which are still missing for the new release?

[AlexanderP]

Hi.
Tesseract-OCR from Git is not compiled with "-Werror=format-security".

tesseract_5.5.0+git6543-d6805c26-1_amd64.log

[egorpugin]

@AlexanderP, what is your compiler and its version?

[AlexanderP]

@egorpugin

Debian Sid

g++ -v 

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-linux-gnu/14/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 14.2.0-19' --with-bugurl=file:///usr/share/doc/gcc-14/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2,rust --prefix=/usr --with-gcc-major-version-only --program-suffix=-14 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/libexec --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-libstdcxx-backtrace --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/reproducible-path/gcc-14-14.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/reproducible-path/gcc-14-14.2.0/debian/tmp-gcn/usr --enable-offload-defaulted --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-serialization=3
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.2.0 (Debian 14.2.0-19)

[egorpugin]

@AlexanderP

Can you try to change this function with the following and see if the error is still there please?
https://github.com/tesseract-ocr/tesseract/blob/main/src/ccutil/tprintf.h#L35

template <typename ... Types> auto tprintf(const char *fmt, Types && ... args) {
  return fprintf(get_debugfp(), fmt, std::forward<Types>(args)...);
}

[egorpugin]

Reverted to va_args 4a39a49

[davidecavestro]

Do you plan to provide an official RPM for 5.5.1?
I could be wrong, but it seems that RPMs from @AlexanderP are no longer available for previous versions.

PS: I just posted on the group yesterday, but I'm also writing here in the hope that Alexander will see it.

[AlexanderP]

@davidecavestro I will build 5.5.1 for openSUSE and Fedora.

Created two projects:
https://build.opensuse.org/project/show/home:Alexander_Pozdnyakov:Fedora
https://build.opensuse.org/project/show/home:Alexander_Pozdnyakov:SUSE

The appimage will also be created.
https://github.com/AlexanderP/tesseract-appimage/releases/tag/v5.5.0

[davidecavestro]

Thank you very much @AlexanderP!
Since I also need the rpm for the old Centos8 (for use on UBI8), would you mind adding them or even sharing the old Centos8 rpm sources so we can manage to build them?
Alternatively, I would start from the sources of the rpms you just released.

[amitdo]

@stweil, please make a new release.

[davidecavestro]

@davidecavestro I will build 5.5.1 for openSUSE and Fedora.

Created two projects: https://build.opensuse.org/project/show/home:Alexander_Pozdnyakov:Fedora https://build.opensuse.org/project/show/home:Alexander_Pozdnyakov:SUSE

The appimage will also be created. https://github.com/AlexanderP/tesseract-appimage/releases/tag/v5.5.0

@AlexanderP I saw in the meantime you published a repo for Centos8, but tesseract-common depends on tesseract-langpack-eng which seems not available.

[stweil]

@stweil, please make a new release.

Yes, I want to do this on next Sunday. And to simplify the release process, I suggest that ChangeLog will no longer track all changes but only link to the release notes on GitHub. Or should we remove this file?

[amitdo]

I agree to the suggested change (link to the release notes or removal of the whole file).

[stweil]

The new release 5.5.1 is now available. Thank you to everyone who contributed to it by reporting issues, providing pull requests, testing, offering advice, and participating in discussions.