Is ScanTailor Advanced an abandoned project?

[mara004]

Dear @4lex4,
First of all, thank you very much for the development time and effort you put into improving ScanTailor!
However, it seems to me that this project has become more or less unmaintained, with the latest commit having taken place in May 2020 (which was merging a pull request concerning the Qt 5.15 build). Since this time, there has been no response to new pull requests or issue reports, not to mention a new release.
The ScanTailor Advanced users and contributors community, including myself, would like to know whether you have stopped developping ScanTailor, or whether you plan to resume working on the project some time soon, as this has an impact on the decision of creating new bug reports or pull requests for ScanTailor Advanced.
If you do not wish to spend time on ScanTailor anymore, I/we would appreciate if you could mark the repository as archived or leave a short comment on what your plans related to further development are.

[rljacobson]

Since the author cannot be reached, someone needs to fork it. That someone doesn't even need to commit to maintenance, only to giving write access to other devs willing to contribute.

[mara004]

@rljacobson Of course it would be very nice if someone could take over maintaining ScanTailor. However, I don't think it's that easy, unfortunately. Only forking and giving access to others probably wouldn't be an improvement to the codebase. We'd need someone who really understands the code, who is able to maintain it in a reliable way, and who can supervise contributions. Otherwise, I fear the quality of the program would decrease a lot and the code get messed up. Anyway, there currently doesn't seem to be a developer who has the time and interest to work on ScanTailor Advanced, which is a pity...

The only still maintained variant of ScanTailor that I know of is ScanTailor Universal by Alexander Trufanov; however, last time I tried, it was by far not as feature-rich as STA. I personally am mostly using ScanTailor Experimental now. It has some flaws and it's not maintained either, but page geometry corrections - particularly dewarping - work better than in any other ScanTailor variant.

[rljacobson]

Well... you're not wrong. I had in mind a maintenance mode more than continued active development: bug fixes, updates to accommodate newer versions of dependencies, maybe new translation contributions. As it is right now it is still useful to me, but there might come a day when it no longer runs on the latest version of macOS, for example, or it can't compile on Windows. That's how these projects die.

There is also the philosophical question of whether a codebase steadily increasing in entropy is actually worse than a codebase that is fixed forever in time. I'm not sure it is. I mean, given the choice between no movement whatsoever versus a repo that at least accepts PRs even if the code quality is poor, I still think I'd choose the latter.

[vigri]

Hi guys,

unfortunately this repository seems to be not maintained anymore and many PRs are open.

I have created a fork and added German (my translation) and from the PRs French, Polish and Korean. Further I have synchronized all the language files.

I compiled Scan Tailor Advanced as version 1.0.17 with these new changes. You can find the x64 binary for Windows here: https://github.com/vigri/scantailor-advanced/releases

My "main language" is not C++, however it would be a pity if this great project would not be developed further. Therefore this approach.

PRs are highly welcome :-)

[mara004]

@vigri It is good to hear that someone finally tries to take over maintaining STA, thank you for doing this.
It would be nice if you could take a look at my PR #179. You might also want to review the changes made in this fork by @yozhic (the osx-fork and develop branches).

[mara004]

PS: I also created a German translation for STA some time ago. It was one of my first ever software translation projects, so the quality might not have been that good, and I didn't have time to improve it yet, but this looks like my latest version, for you to compare if you like: scantailor_de.ts.txt
I don't know if you based your translation on that of the original ScanTailor or ScanTailor Experimental, but mine was mostly written from scratch with a few parts taken over from Experimental.

[vigri]

@mara004

PS: I also created a German translation for STA some time ago.

I have to admit: First I created the translation completley on my own and then completely your translation :)
Feel free to give me feedback if you think some translations are weird or wrong.

You might also want to review the changes made in this fork by @yozhic (the osx-fork and develop branches).

I'll take a look at it 👍

[jgod]

Sucks when forks of forks of forks happen...

[tukusejssirs]

How about merging all those forks and all their features in a single repo (ideally named simply scantailor)? All maintainers and contributors could split the job.

I don’t code in C++ either, we might want to try to port it to Rust (not a requirement).

---

I might be a good idea to talk to all those people and create a scantailor GitHub organisation (incl a general email address).

[vigri]

How about merging all those forks and all their features in a single repo (ideally named simply scantailor)? All maintainers and contributors could split the job.

I don’t code in C++ either, we might want to try to port it to Rust (not a requirement).

I might be a good idea to talk to all those people and create a scantailor GitHub organisation (incl a general email address).

I have absolutely no problem with "my" fork being merged here or into another repository.

When I created the fork it was only important to me that STA does not die completely. I myself am not an active developer on this project and try to merge all PRs that come into my repository.

So if there is a "better" future for STA, I am absolutely open.

[mara004]

As of this writing, the only active ScanTailor repos I'm aware of are ST Universal by @trufanov-nok and a fork of ST Experimental by @zvezdochiot. And of course @vigri's contributions-only fork (with a major Qt6 patch by @kunzjacq, BTW).

How about merging all those forks and all their features in a single repo (ideally named simply scantailor)? All maintainers and contributors could split the job.

@tukusejssirs STU and STEX differ fundamentally, it's not possible for them to simply "merge".
They are also maintained by independent devs who have different goals and, I think, prefer to do their own thing.
I know the fragmentation is somewhat unfortunate, but that's how OSS is, devs are free to do what they like.

I don’t code in C++ either, we might want to try to port it to Rust (not a requirement).

Good gracious, consider what you're writing. That would effectively mean a rewrite from scratch, taking tremendous effort until one could expect productive results equivalent to current ST. It would be a different program (even if targetting similar functionality), not the maintenance takeover we are looking for here.

[zvezdochiot]

Hi @mara004 .

⚠️ But Qt6 turned out to be (so far) a complete crap: memory leaks, crooked support for graphic formats.

[konos93]

hi zvezdochiot .
is qt6 the reason u cannot export your version in windows?

[zvezdochiot]

Hi @konos93 .

❓ What does "reason" mean? And what does "export" mean?

⚠️ Qt6 is just a whim of the STA maintainers. My fork initially has a normal build on Qt5 by @plzombie.

👽 If you are talking about STEX, then there are no builders capable of fixing cmake instructions for Windows in order to build for Windows.

[mara004]

But Qt6 turned out to be (so far) a complete crap: memory leaks, crooked support for graphic formats.
Qt6 is just a whim of the STA maintainers.

I can't really judge on this because I'm not developing with Qt. The few Qt6-based end user apps I have seem to run OK, but I don't use them very much (e.g. shotcut, qpwgraph).
However, for what STA is concerned, I don't think it matters so much how stable Qt6 is at the moment (it builds with both Qt5 and Qt6 after all). IMHO the important thing is to have an API port available since this will probably the future of Qt API.

Apart from that, people ranting about new major versions of widespread libs/languages (or leastways unwillingness to port) always happens. It has happened with the Python 2 -> 3 transition (e.g. didjvu), with Qt4 -> Qt5 (e.g. natron compositor), GTK 2 -> 3 etc. However, it is usually the new major versions that survive in the long term.

[zvezdochiot]

@mara004 say:

Apart from that, people ranting against new major versions of widespread libs/languages (or leastways unwillingness to port) always happens. It has happened with the Python 2 -> 3 transition (e.g. didjvu), with Qt4 -> Qt5 (e.g. natron compositor), GTK 2 -> 3 etc.

I fully support these people. For me, Qt4 will forever remain the most balanced version of the framework. And certain “disadvantages” could be eliminated through evolution.

In short, Qt's policies are far more trouble than they're worth. And the rest boldly take a bad example from her.

[zvezdochiot]

Hi all.

STEX: 0.2023.09.13: Build for Windows by @Нубий-IV.

[jgod]

Since @zvezdochiot and others don't intend to (if it were even possible) merge back in the changes from their forks, can we get the Readmes of the forked versions to say what they added to their forks?

We could theoretically read the commits or hop around comments in Github issues but this for each of the forks is hard to follow and gives the impression that none of them are stable/supported for use.

So far @mara004 's comment is the best high level summary I've seen.

[zvezdochiot]

@jgod say:

Since @zvezdochiot and others don't intend to...

What does "don't intend to..." mean? I can't. This is impossible for me.

[wegavision1]

If the project is ever continued again, I would have a few things here that could be changed that bother me in my daily work.

• More default settings: fixed location from where the images are loaded, resolution, color etc, everything has to be set every time, even if you always take the same values yourself.
• The frame with which you determine the content should be more felxible.

1. you should be able to move it as a whole
2. you should be able to define different frames for even and odd pages, because books are built differently.

I'm sure I can think of more, I'll write it here again, the program is great, but also not optimal.