TYPO3 Core

I think this is the default behaviour from CSS Styled IMGtext..?

As far as I know (and could test), IMGTEXT always behaved like that, and this also seems to be documented that way. From TSref:

"
maxW: max width of the image-table.

This will scale images not in the right size! Takes the number of columns into account!
"

So this is the maximum width for the whole Image-TABLE. If I have maxW 100 and 2 columns of images (no borders, no colSpace), I should get two 50px wide images side by side, which is what the "new" css_styled_content implementation also does.

And I think this is the correct behaviour, because you as the site admin have to specify the maximum width of the whole content part (imagine you have a fixed-width content column). If you want give the editors more flexibility, you have to set maxW to something astronomic and use the (new) defaultW setting, which will apply whenever no width is specified for an content with images.

Maybe there is some setup I am not considering, but if you can construct an example where this is not backwards compatible, I would like to take a look at it. Simply switching to "content (default)" shows not difference to the css-variant for me. If you are upgrading from older "css_styled_IMGTEXT" extensions, there might be an incompatibility, because there the maxW was incorrectly calculated (there was no "multiple-columns" support anyway). But at least "cron_cssstyledimgtext" (which is what was integrated into 4.0) always worked like what is documented in TSref.

Maybe - and if this is the case this is definitely a blocker that should prevent RC2 from becoming final.

Imagine people running sites containing a few hundred image elements with CSS-styled-content and 3.8.1 - they never used cron-CSS-styled-imgtext - now they update to 4.0 and all elements show thumbnails instead of the desired size?

Setting the compatibility mode to 3.8.1 helps to disable the bug, but this would either mean that the user is forced to stay with this mode forever or having to change all elements manually to have the possibility of switching the mode to 4.0

@ernesto: You are right if you mention the default behaviour of maxW.
But this is not the problem here:

Default behaviour of IMGTEXT with 3.8.1
(no cron- or whatever-CSS-styled-version)
You can set "width" in the BE form and this is used as the width of a SINGLE image.
You can set maxW in the constants.
The check that is performed in this case: Sum up the width of all images + spacing and check if this is <= maxW. If this is the case, don't change anything. If the sum is > maxW reduce the image width accordingly.

New behaviour:
Setting the "width" in the BE form specifies the width of the WHOLE image block instead of only one single image. This overrides maxW as long as width < maxW.

Result:

3.8.1
width (in BE form) = 100
maxW (in constants) = 600
single Image width for
1 Column = 100
2 Columns = 100
3 Columns = 100
4 Columns = 100
5 Columns = 100
6 Columns = (600 - ((cols-1)*spacing)) /cols

4.0
width (in BE form)= 100
maxW (in constants) = 600
single image width is always = (100 - ((cols-1)*spacing))/cols
1 Column = 100
2 Columns < 50
3 Columns < 33
4 Columns < 25
5 Columns < 20
6 Columns < 17

This is absolutely unacceptable since you have to calculate the width based on the number of columns and fill it manually each time you change the columns. And it leads to completely unpredictable results when updating sites from default to new behaviour

You are right, mastablasta!

I will fix the problem ASAP and submit a patch to the core team. There are some other still pending things to be commited at this part, and I can also include this fix.

Interesting is that even though cron_cssstyledimgtext has always worked like that, nobody ever noticed it. :)

Ok, this patch (attached to this bug report) is now the cumulated changes that need to go in before releasing. Should apply on RC2.

This fixes the following problems (already submitted to core-list through Stucki):

• Now the CSS version of "Text w/images" and "Images" (table-less) also respect the textMargin constant so that (finally) the user can specify a different margin to separate the image block from the text. "colSpacing" now only applies to inter-images spacing, which is what the table-based approach also does.
• For this to work we need to apply two new classes to the images (csc-textpic-firstcol and csc-textpic-lastcol). This is configurable through an optionSplitted new property "addClassesImage" of the USER object
• Having this also allowed us to fix a bug in positioning: The whole image-block can now stretch correctly over the given width without any margins around it (which is required if you have just an image-block, without text). Without the patch, you always have "margin-right" (if images are placed to the left or center) or "margin-right" (if images are placed to the right).
• Fixed also a problem with the calculation of image width if we have borders and border-spacings: Now the whole image-block will always be exactly maxW wide (so if you have borders and spacing, the images will get slightly smaller). Without this, the image-block could "explode" a fixed-width layout.

But now (Michael, Core-team!!) new in this patch:

• Changes to the original patch as suggested by Franz Holzinger in core-mailing list.
• Bug fix for bug #15522: wrong image widths for images that have explicit width set in the content element (now it works like the "good-old" content (default) does, so backwards compatible)
• Removed "unused" defaultW property, which were added by cron_cssstyledimgtext but never used in the integration.

I would appreciate if mastablasta and Joey could test the rendering with this patch applied, if it works on all cases. If you give some feedback here, chances are larger that we can integrate this soon.

This is an updated patch for css-styled-content in regard of IMGTEXT rendering.
Fixes this newly discovered bug (#15522) and includes all changes that already have been submitted to the core list but weren't integrated into RC2.
Also includes changes proposed by Franz Holzinger to the core-list.

Well - since mastablasta and Joey are the same person I think "both" of us will manage to coordinate the efforts ;-)

Joey

Oh, I thought I have seen the username "JoH" here in the bug-tracker once, my fault. Acknoledged, I will try to remember that in future. :)

I will integrate the patch into the core, as soon as Joey confirms it is working as expected for him.

Seems to be working now.
Images are resized to the given single size.
Size is reduced as soon as the overall size of the block extends maxW.

Thanx for the quick solution, Ernesto

Alright, I'm now going to submit the patch to the core list.

In CVS since 2006-04-04, so this fix was released with 4.0rc3 and thus went into 4.0.0.