Rename ocrd_sbb_textline_detector

[stweil]

I suggest to rename ocrd_sbb_textline_detector to ocrd-sbb-textline-detector or ocrd-sbb-segment-line which fit better to the OCR-D conventions.

CC'ing @kba.

[cneud]

WONTFIX, because this tools is from another funded project, not OCR-D, and we want/need to be transparent ;-)

[stweil]

I am sorry, but I don't understand why replacing _ by - would be in-transparent?

[kba]

I think @cneud meant that we won't rebrand non-OCR-D tools as ocrd-?

[cneud]

I think @cneud meant that we won't rebrand non-OCR-D tools as ocrd-?

Precisely! This is NOT an OCR-D effort, and we are required for funders to be clear about this! We cannot simply rebrand products of other funded projects.

[cneud]

It is a voluntary concession by SBB to also issue QURATOR tools with OCR-D compliant interfaces (where possible).

[stweil]

For me, the ocrd- prefix just indicates that it is a tool which fits into the OCR-D toolchain. I did not interpret it as an indicator that it was funded in the OCR-D context.

Why not omit ocrd_ as well, and use - in the name of the script nevertheless?

[cneud]

Maybe, but we have another project here with another naming scheme in use. Does it really matter?

[kba]

@cneud Just to clarify, @stweil is referring to the executable ocrd_sbb_textline_detector in the ocrd-tool.json. This is already prefixed ocrd_ and should indeed follow the same convention as all the other tools, i.e. ocrd and kebab-case.

[cneud]

Yeah I think we can rename the OCR-D-Processor.

But just to be aware that there is a full framework context with specs (incl. naming conventions etc.) behind here, as well - just not the one of OCR-D ;-)

[stweil]

I only talked about your already existing OCR-D script and am a little bit surprised about the reaction.

[cneud]

We already try in QURATOR what we can to be as compatible to OCR-D, see e.g. ocrd_calamari, dinglehopper. But this is all extra, and we simply have other obligations/priorities in the other project, too.

I will make another PR about the OCR-D script.

[kba]

I will make another PR about the OCR-D script.

10

[cneud]

I will make another PR about the OCR-D script.

10

OK you beat me to it ;-)

[bertsky]

It appears the above fix is only half done:

  File "qurator/sbb_textline_detector/ocrd_cli.py", line 34, in __init__
    kwargs['ocrd_tool'] = OCRD_TOOL['tools'][TOOL]
KeyError: 'ocrd_sbb_textline_detector'

(So it's not enough to change the name in the tool json and setup.py entry points, there is another mention in ocrd_cli.py waiting to be renamed as well.)

Please re-open!

[kba]

Remaining mention in ocrd_cli.py is in #12.

[mikegerber]

Tested and merged #12

[mikegerber]

Some opinions as the author of the OCR-D CLI here (My colleague @vahidrezanezhad is responsible for most of the rest):

• PRs are nice! PRs that are tested even nicer, so please do test the change before PRing and please please test before merging
• As for the naming conventions of the OCR-D project: This is not part of the OCR-D project but we try to stay compatible and friendly with it :) I personally couldn't care less I just like consistency (so I am not a big fan of having a ocrd_something project with ocrd-something-etc processors in it, but I do like the consistency of having all processors being named ocrd-something-etc).
• In this case I would have preferred merging the PR as the author of the CLI, especially because the rename breaks my setup.

[stweil]

@mikegerber, I am sorry that I approved a pull request without testing it. To help avoiding such problems in the future, I suggest to add some continuous integration tests. A first one is added by pull request #13.

See https://travis-ci.org/stweil/sbb_textline_detector/builds for some results.