Project

General

Profile

Actions

Bug #17107

closed

maxW for image rows is not the maximum

Added by Ralf Hettinger over 17 years ago. Updated about 6 years ago.

Status:
Closed
Priority:
Should have
Category:
Content Rendering
Target version:
-
Start date:
2007-03-10
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:

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

0005186-4.1.0.RC2.patch (869 Bytes) 0005186-4.1.0.RC2.patch Administrator Admin, 2007-03-10 02:12
0005186-4.1.0.RC2.v2.patch (881 Bytes) 0005186-4.1.0.RC2.v2.patch Administrator Admin, 2007-03-10 02:19
0005186-4.1.0.RC2.v3.patch (996 Bytes) 0005186-4.1.0.RC2.v3.patch Administrator Admin, 2007-03-10 02:47
5186_example.jpg (102 KB) 5186_example.jpg Administrator Admin, 2007-04-20 14:50
5186_trunk.patch (1.18 KB) 5186_trunk.patch Administrator Admin, 2008-01-26 11:40
5186_4.3.alpha1.patch (2.04 KB) 5186_4.3.alpha1.patch Administrator Admin, 2008-12-22 23:31
0005186_4.4trunk-rev6782.patch (2.11 KB) 0005186_4.4trunk-rev6782.patch Administrator Admin, 2010-01-16 19:00
typo3-v443dev-rev8607.patch (3.96 KB) typo3-v443dev-rev8607.patch Administrator Admin, 2010-08-20 14:47
typo3-v443dev-rev8642.patch (7.72 KB) typo3-v443dev-rev8642.patch Administrator Admin, 2010-08-23 12:52
bug_5186.patch (8 KB) bug_5186.patch Administrator Admin, 2010-10-06 10:10
typo3-maxW-bug.png (666 KB) typo3-maxW-bug.png Administrator Admin, 2010-11-11 10:33
typo3-maxW-bug-corrected.png (662 KB) typo3-maxW-bug-corrected.png Administrator Admin, 2010-11-11 10:33

Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Bug #25264: Multi-Column image generation broken after update from 4.3.9 to 4.3.11Closed2011-03-07

Actions
Actions #1

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.

Actions #2

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.

Actions #3

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!

Actions #4

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

Actions #5

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.

Actions #6

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.

Actions #7

Updated by Ralf Hettinger almost 16 years ago

5186_4.3.alpha1.patch provides better code readability of what is done.

Actions #8

Updated by Ralf Hettinger almost 15 years ago

CGL cleanup.

Actions #9

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>

Actions #10

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

Actions #11

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.

Actions #12

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?

Actions #13

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

Actions #14

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.

Actions #15

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!)

Actions #16

Updated by Susanne Moog almost 14 years ago

4-3 rev 9838
4-4 rev 9839
trunk rev 9840

Actions #17

Updated by Benni Mack about 6 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF