fix(layout_utils): correct conditional logic in adapt_bbox function

[Raphilanthrope]

The second 'if' statement in the adapt_bbox function was changed to 'elif'
to properly handle the conditional flow for different DocItemLabel types.

This change ensures that the function correctly processes TABLE, PICTURE,
and other DocItemLabel types as intended.

Resolves: #362

Checklist:

• Commit Message Formatting: Commit titles and messages follow guidelines in the
  conventional commits.
• Documentation has been updated, if necessary.
• Examples have been added, if necessary.
• Tests have been added, if necessary.

[mergify]

Merge Protections

Your pull request matches the following merge protections and will not be merged until they are valid.

🟢 Enforce conventional commit

Wonderful, this rule succeeded.

Make sure that we follow https://www.conventionalcommits.org/en/v1.0.0/

• title ~= ^(fix|feat|docs|style|refactor|perf|test|build|ci|chore|revert)(?:\(.+\))?:

[cau-git]

@Raphilanthrope I can not find any logical difference between the original code and your proposal.
Do you have a practical case where this change makes a difference? If yes, please post a PDF and instructions to reproduce the issue.

[Raphilanthrope]

@Raphilanthrope I can not find any logical difference between the original code and your proposal. Do you have a practical case where this change makes a difference? If yes, please post a PDF and instructions to reproduce the issue.

I don't have a practical example where this change induces a difference.

In fact, it might be the case that it does not induce any difference if the label of the object given to adapt_bbox is restricted to [TABLE, PICTURE], otherwise if the label is authorized to be different than these two labels, when it is, both the first 'if' and the 'else' clauses are treated whereas only the first clause is treated when the second 'if' is replaces by 'elif'.

In summary, the question is: Is the label of the object given to adapt_bbox restricted to [TABLE, PICTURE] ?
If not, the PR would ensure the wanted behavior suggested by the comment after the 'else' keyword (that indicates that the object is expected to be a table).

[PeterStaar-IBM]

@cau-git please update

[cau-git]

@Raphilanthrope I am closing this because it will be obsolete with an update I am making to the layout postprocessing.