TYPO3 Core

No, they don't have all int casts.
Take eg. a look at line 181:

$width = $options['maxWidth'];

and line 187:

$height = $options['maxHeight'];

and line 194:

$width = $options['minWidth'];

and line 200:

$height = $options['minHeight'];

In all cases, there is no int-cast afterwards, unless their values are “0” or $GLOBALS['TYPO3_CONF_VARS']['GFX']['processor_allowUpscaling'] == true and the width or height is larger than the cropArea width or height.
This is by far not always the case.

Yes, we would need to check if maybe bootstrap_package passes these options as floats, hence asking for the full stacktrace to see where they come from. Ideally we shouldnt fix a symtpom but a cause.

Line 120: public static function fromCropScaleValues(int $incomingWidth, int $incomingHeight, int|string $width, int|string $height, array $options): self

This method is a public (static) not internal marked method, where the $options attribute has only to be an array.

Why should we search for the cause outside?

At the beginning of this method, there is a call to streamlineOptions. Maybe this would be a good place to make sure the critical options become integers if set?

This method (streamlineOptions) has this doc comment:

/**
 * @return array{
 *             maxWidth?: int,
 *             maxHeight?: int,
 *             minWidth?: int,
 *             minHeight?: int,
 *             crop?: Area,
 *         }
 */

Let's investigate with the stack trace and where it comes from, thank you.
Of course you're free to propose any patch you deem fit, but I personally always want to know where an issue arises from.

Also, please let's be constructive and appreciative to each other, I feel like I need to defend myself when all I want is to help.

I like to do that too. I'm sorry if you got a different feeling.

I was just a bit annoyed, because I already created a patch for the site where I discovered this problem and I had to revert it first.
After doing this, I first thought the problem was magically gone, but after clearing the processed images cache it pops up again.
Next problem was the huge stack trace, where I had no idea how to add it to this tracker.

Another thought that just popped into my head:
Since the private method “streamlineOptions” is only used once and the "fromCropScaleValues" method needs integer values in the end, the proposed solution seemed the most efficient to me.

Maybe also interesting:
The svg image (attached) that creates the problem has a width of 400. The output of the bootstrap_package content element "cards from subpages" is used in the main column of the "2 columns layout with left side sub navigation". The settings inside this content element are alignment left with 4 columns.

Patch set 5 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/88206

Patch set 6 for branch main of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/88206

Patch set 1 for branch 13.4 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/88238

Hi Alexander,

you may have seen the patch got merged more quickly than I thought. I did rework the patch to add (int) casting like you proposed. Maybe you could check it out and see if that works out for you this way?

Regards,
Garvin