Bug #47272
closedcss_styled_content in Typo3 6.0 breaks imageheight
0%
Description
When using more images in a column and adding a imageheight (Image Adjustments - Height (px)) parameter, the css_styled_content of Typo3 6.0 uses exactly this height (even if the images in this columns are getting too large). Using the css_styled_content from 4.7 the images are still scaled down correctly to fit into a column.
E.g., three images in a 600px column. Set max height = x, so that each image is wider than 200px.
Therefore, it is now hard to add a list of images with the same height (but different widths) in a column, as you have to calculate the image heights manually.
Files
Updated by Klaus Hinum over 11 years ago
- File images_4_7 added
- File img_6.0 added
Updated by Klaus Hinum over 11 years ago
looks like
tt_content.image.20.
imgList.override.field = image_fileUids
on line 662 of setup.txt is the cause for the problems.
/* Update, seems like also with 6.1.1 the images are added twice in sys_file repository, no matter which css_styled_content is used
However, when removing this line, the images are added again to sys_file without a repository, therefore the 4.7 css_styled_content option is not useable.
Updated by Ernesto Baschny about 11 years ago
- File images_4_7.png images_4_7.png added
- File images_6_0.png images_6_0.png added
- Is Regression set to No
I've just updated your images, because they had a missing file extension:
4.7:
6.0:
Updated by Thomas Skierlo about 11 years ago
Can confirm the problem for all 6.x releases:
Seems to happen here, if FAL images are used (CssStyledContentController):
if ($equalHeight) { // Initiate gifbuilder object in order to get dimensions AND calculate the imageWidth's $gifCreator = GeneralUtility::makeInstance('TYPO3\\CMS\\Frontend\\Imaging\\GifBuilder'); $gifCreator->init(); $relations_cols = array(); // contains the individual width of all images after scaling to $equalHeight $imgWidths = array(); for ($a = 0; $a < $imgCount; $a++) { $imgKey = $a + $imgStart; $imgInfo = $gifCreator->getImageDimensions($imgPath . $imgs[$imgKey]); // relationship between the original height and the wished height $rel = $imgInfo[1] / $equalHeight; // if relations is zero, then the addition of this value is omitted as the image is not expected to display because of some error. if ($rel) { $imgWidths[$a] = $imgInfo[0] / $rel; // counts the total width of the row with the new height taken into consideration. $relations_cols[(int)floor($a / $colCount)] += $imgWidths[$a]; } } }
$imgInfo always stays empty. Same happens if you sanitize the path for FAL. So I guess that GifBuilder can't be used to return current image dimensions. If so, this is a serious one.
Updated by Ernesto Baschny about 11 years ago
- Status changed from New to Accepted
- Priority changed from Should have to Must have
Updated by Helmut Hummel about 11 years ago
Thomas Skierlo wrote:
Can confirm the problem for all 6.x releases:
Seems to happen here, if FAL images are used (CssStyledContentController):
[...]
$imgInfo always stays empty. Same happens if you sanitize the path for FAL. So I guess that GifBuilder can't be used to return current image dimensions. If so, this is a serious one.
This part should be completely rewritten to make use of the FAL Processing API
Updated by Mathias Schreiber almost 10 years ago
- Category changed from Frontend to Content Rendering
- Target version set to 7.2 (Frontend)
Updated by Benni Mack over 9 years ago
- Target version changed from 7.2 (Frontend) to 7.4 (Backend)
Updated by Susanne Moog over 9 years ago
- Target version changed from 7.4 (Backend) to 7.5
Updated by Riccardo De Contardi over 7 years ago
I think I can safely close this ticket: I performed the following test using 6.2.30:
I used 3 images with the following dimensions:
- 200px x 300px
- 300px x 300px
- 900px x 300px
TS Constants:
styles.content.imgtext.maxW=600
I added a content element "text and images" with the following configuration
Image Adjustments: height:300px position:above,left number of columns:3
Result: the three images get scaled in both width and height to keep their proportions and to keep their combined witdh within 600px
(See attached image)
If you think that this is the wrong decision or that a different test should be done to reproduce the issue then please reopen it or open a new issue with a reference to this one. Thank you.
Updated by Riccardo De Contardi over 7 years ago
- Status changed from Accepted to Closed