Bug #47272
closed
css_styled_content in Typo3 6.0 breaks imageheight
Added by Klaus Hinum over 11 years ago.
Updated over 7 years ago.
Category:
Content Rendering
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
- File images_4_7 added
- File img_6.0 added
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.
I've just updated your images, because they had a missing file extension:
4.7:
6.0:
- File deleted (
images_4_7)
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.
- Status changed from New to Accepted
- Priority changed from Should have to Must have
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
- Category changed from Frontend to Content Rendering
- Target version set to 7.2 (Frontend)
- Target version changed from 7.2 (Frontend) to 7.4 (Backend)
- Target version changed from 7.4 (Backend) to 7.5
- Target version deleted (
7.5)
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.
- Status changed from Accepted to Closed
Also available in: Atom
PDF