Bug #17107
closedmaxW for image rows is not the maximum
0%
Description
If a given maximum width for more than one image in a row is set and this imagerow is wider than the given width, that currently doesn't mean in every case that the given value really is the maximum: If there is some remainder left after dividing the maximum space for all images in a row through the number of images, the image sizes will be ceiled and an image row therefore wider than maxW.
This might result in image rows being up to 1 pixel less than the number of images in a row wider than maxW would allow the imagerow to be and may harm a layout badly - and goes the worse the more one imagerow has columns.
There is no reason for this behaviour - I'd suggest to simply substract one pixel from each image in a row as long as there is some remainder left from the division. This results in image rows normally being wider will have the exact maximum width and every single image having still about the same width with +-1 pixel.
(issue imported from #M5186)
Files
Updated by Ralf Hettinger over 17 years ago
Whoops... missed one modulus for the case that no remainder is there from the very beginning. Please use v2.
Updated by Ralf Hettinger over 17 years ago
You're right... I could have thought before uploading. It just did not come to mind earlier, sorry.
Okay, so version 3 is rather a feature than solving a bug: If the remainder in an imagerow is small enough to allow alternate reducing/not reducing the ceiled size of each image for an even smoother impression of equal width, this can be achieved with the last patch.
Updated by Ernesto Baschny over 17 years ago
Hi Ralf,
I don't think I understood the problem. Could you please clarify using a simple example telling us which images you have (widths), what is maxW, what is colspacing, border, etc, and where exactly the error occurs or at least how I can reproduce it? A URL or Screenshot with the result would also be helpful.
Thanks for helping!
Updated by Ralf Hettinger over 17 years ago
No problem...
examplary settings:
maxW = 512, border = 0, colSpace =2
result for 5 images in a row: total width = 515px (3 px to wide)
result after patching: total width = 512px (correct)
Attaching an example image (derived from a screenshot of a website with and without patch - yes, I'm sure that it is reproducible ;) )
[addendum] uhm... sorry, I was way to fast again... though the problem is visible, my numbers aren't correct.
Should read:
result for 5 images in a row: total width = 513px (which is 5*101 + 4*2 and is only 1 px to wide)
result after patching: total width = 512px (which is the first image being 100 and the others 101 = 100+4*101+4*2 and correct).
There are circumstances where this would go worse than only 1 px... depending on the maxW: For 5 images in a row you had a maximum failure of 4 px... which isn't the case for my example (maxW=512) but would be for example if maxW=514px
Updated by Ernesto Baschny over 17 years ago
Ok, now I've got it. Problem with the rounding upon rescaling the images.
Thanks for the nice detailed report, Ralf. I'll try to review that ASAP, probably only next week.
Updated by Ralf Hettinger almost 17 years ago
Hm... you've probably had no time for having a look at this.
I requested this at the core list for integration, since after testing this in quite a handful of installations, I did not experience any failures anymore.
Updated by Ralf Hettinger almost 16 years ago
5186_4.3.alpha1.patch provides better code readability of what is done.
Updated by Michael Buergi almost 15 years ago
Would be very nice, if someone from the core team could fix that bug quickly.
This bug makes picture elements with more than six images per row unusable for our website (because the maximum width is exceeded by more than 6 Pixels).
We even had to put the following typoscript in our template to prevent image elements with only one single row from breaking into multiple rows on the screen:
tt_content.image.20.rendering.div.noRowsStdWrap.dataWrap = <div class="csc-textpic-imagerow" style="width:{register:rowwidth}px;"> | </div>
Updated by Ralf Hettinger almost 15 years ago
Michael,
do you have the possibility to apply the latest patch and report back if it solved your problem?
Thanks
Ralf
Updated by Michael Buergi over 14 years ago
Thanks for the patch, Ralf. It didn't solve my problems, though.
I have made my own patch and uploaded it.
It works perfectly for me. the accumulated widths do now match maxW exactly. rounding errors are evenly distributed across the whole image row.
Can you please have a look, Ernesto and Ralf?
Thanks in advance.
Updated by Ralf Hettinger over 14 years ago
Hi Michael,
thanks for your patch - at a first glance it solves a known missing piece (equalHeight set), which is mentioned here: http://lists.typo3.org/pipermail/typo3-team-core/2008-December/021779.html - haven't tested it yet, though.
It seems to me that our suggestions should be merged... does your solution handle image widths correctly without equalHeight?
Updated by Michael Buergi over 14 years ago
Hi Ralf
does your solution handle image widths correctly without equalHeight?
the new patch does.
please have a look
Updated by Michael Buergi about 14 years ago
I am submitting the latest patch to the core mailing list. the only difference to the previous patch is the fixed path which is now relative to the typo3 root folder.
Updated by Michael Buergi about 14 years ago
I was asked to provide a recipe to reproduce the bug.
Here it is:
- Have a look at typo3-maxW-bug.png
- locate the five images in a row near the top - just above the text "image caption"
- this image element uses 5 images of identical dimensions: 230x68px
- settings: 5 columns, width: 728px, orientation: above left
the unpatched typo3 produces the following output:
139x41 139x41 139x41 139x41 139x41
space between images: 10px
total width: 139*5 + 4*10 = 735px (exceeds our limit by 7px !)
the patched typo3 produces this output:
138x41 137x41 138x41 137x41 138x41
space between images: 10px
total width: 138 + 137 + 138 + 137 + 138 + 4*10 = 728px (exact!)
Updated by Susanne Moog almost 14 years ago
4-3 rev 9838
4-4 rev 9839
trunk rev 9840