Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix code for generating config files #4074

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

Balearica
Copy link
Contributor

Resolves #3943, see that issue for a full explanation and previous discussion on this issue.

In short, the function ParamUtils::PrintParams previously created a machine-readable config file with parameter names and values. It was then edited to add human-readable descriptions to each of the parameters. While this change undoubtedly made the results easier for users to interpret, the resulting files no longer functioned properly as config files. This (1) broke the parts of the code that assumed ParamUtils::PrintParams created machine-readable config files and (2) meant there was no longer an API function for creating machine-readable config files using the current settings.

This PR fixes both issues:

  1. A boolean parameter has been added to ParamUtils::PrintParams to specify whether descriptions of parameters should be printed
    1. This parameter is true by default, so printing to the console (for example) still includes the descriptions
    2. When ParamUtils::PrintParams is inarguably being used with the intent of creating a machine-readable config file, the parameter is set to true
  2. An API function named DumpVariables has been added, which creates config files (the old behavior of PrintVariables)

@zdenop
Copy link
Contributor

zdenop commented May 12, 2023

Can you please add it also to C-API?

@Balearica
Copy link
Contributor Author

Can you please add it also to C-API?

I added corresponding functions to the C API.

@stweil
Copy link
Contributor

stweil commented May 12, 2023

Can you please add it also to C-API?

Do we really need any new API function not only for C++ but also for C?

@zdenop
Copy link
Contributor

zdenop commented May 12, 2023

Why C and C++ API should not be synchronized (providing the same features)?

@stweil
Copy link
Contributor

stweil commented May 12, 2023

Each additional API creates some costs (implementation, maintenance, code size). And is there still a need for a C API? Maybe we should even consider dropping the whole C API in a future version 6.

If a C API for a new function is really missing it can be added any time later.

@zdenop
Copy link
Contributor

zdenop commented May 18, 2023

IMO costs are minimal for CAPI. I see no benefit in removing it.
AFAIK it is still in the use (e.g. tess4j or NET wrapper for tesseract-ocr)

zdenop referenced this pull request May 12, 2024
zdenop referenced this pull request May 19, 2024
@stweil
Copy link
Contributor

stweil commented May 19, 2024

What about keeping the API unchanged, but fixing the API regression (introduced in commit c51691f)?

tesseract --print-parameters could still print the parameter information, but use purely private code for that.

That is my preferred solution because I try to minimize API changes.

@stweil
Copy link
Contributor

stweil commented May 19, 2024

@Balearica, if you want to update your pull request with a new implementation which avoids API changes, it would be nice if you could review your author information. Many projects refuse pull requests without a valid real name for the author, and I think that would be good for Tesseract contributions, too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

PrintVariables produces config file that ReadConfigFile does not properly read
3 participants