I think I am experiencing this ages-old behaviour in a TYPO3 6.1 site
http://forge.typo3.org/issues/15522
As soon as there is more than one image in a textpic field, this TypoScript
tt_content.image.20.maxWInText = 300
will produce very small images - their size is the given rendering size divided by number of images.
So with three images in a textpic element, this will give me three 100px wide images.
How can this be set to work normally (value 300 applied to each image?)
EDIT: I'm posting the full config I've been using:
imgWidth=CASE
imgWidth{
key.field = header_layout
default=TEXT
default.value=1000
1=TEXT
1.value=1000
2=TEXT
2.value=500
3=TEXT
3.value=300
4=TEXT
4.value=500
5=TEXT
5.value=300
6=TEXT
6.value=500
7=TEXT
7.value=300
8=TEXT
8.value=0
9=TEXT
9.value=0
10=TEXT
10.value=150
10=TEXT
10.value=1000
}
tt_content.image.20.maxWInText.cObject < imgWidth
tt_content.image.20.maxW.cObject < imgWidth
This setting is supposed to affect the width occupied by all images in a column. Therefore it must effect all images.
You should take a look at
tt_content.image.20.maxW
Related
I need ag-grid to be responsive on all devices. When I tried this.gridApi.sizeColumnsToFit() It looks nice on desktop, but in mobile screen column width gets zero
as shown in this image.
When I give this.gridColumnApi.autoSizeColumns(allColumnIds, false); it leaves a blank space if there are less number of columns like shown in this image.
Is there a way to autoFit in desktop and autoSize in smaller screens?
you can call them after another. I'd suggest to first call the autoSizeColumns.
Afterwards you calculate the actual tableWidth with something like
const tableWidth = grid.columnApi.getAllColumns()
.reduce((i, current) => i += current.getActualWidth(), 0);
and then you calculate the actual container width
const {left, right} = grid.api.getHorizontalPixelRange();
const containerWidth = right - left;
and only if the tableWidth is smaller than the container width you call `sizeColumnsToFit``
if (tableWidth < containerWidth) {
grid.api.sizeColumnsToFit();
}
I have this implementation, using it in a page level 2 submenu. Each level 2 menu has multiple subpages. Each subpage has one image. So this implementation produces an image from each page for each submenu. For example, a submenu with 2 subpages will have 2 images (one from each subpage).
1 = FILES
1 {
references {
table = pages
fieldName = media
data = levelmedia:-1, slide
}
begin = 0
maxItems = 2
renderObj = COA
renderObj {
2 = IMAGE
2 {
file {
//params = -sharpen 50 +profile "*" -quality 100
import.data = file:current:uid
treatIdAsReference = 1
width.optionSplit = 300c|*|400c
height.optionSplit = 350c|*|450c
}
}
}
}
Would like to have images cropped in different sizes such that image 1 is cut to different dimensions from image 2 and so on.
My ImageMagick installation works perfectly. Am actually cropping single images with it without a hitch.
Without the optionSplit above, the images are cut to size nicely. Unfortunately with the optionSplit it simply outputs the images in their original sizes.
How can I produce different image sizes? My understanding is that optionSplit is the way to go (from the manuals). I read in articles that soureCollection for responsive images use optionSplit. I imagine another way would be to use an image register counter and use CASE to determine how to cut image 1, 2, 3 and so on, but am not familiar with register counters (maybe someone can show me how to do this?). And yet another way would be to use a file/image index number but I've tried looking at the manuals for hours for such a pointer and nowhere is it listed if there's any to help with processing. Anybody know a way to do this?
rendering two consecutive images with different paramters will be difficult in typoscript:
your optionsplit can not success as in the renderObj you always have only one file. A bad habit of all renderObj.
on the other hand: there is no property optionSplit. the functionality is build in any wrap property.
therefore a handling in typoscript could be to concatenate the elements, then split them again, but then use different options in the split renderObj to handle it separately.
or implement a counter with a register variable, then evaluate the register to set different values.
easier would be a handling in fluid, where you could use an iterator with the f:forviewhelper, and then do an f:if (for two cases) or an f:switch (for more cases) on {iterator.index} to render individual versions.
Based on #Bernd answer on the fact that each page (as item) is delivered as an object in TMENUs in each iteration, it is possible to achieve such image rendering in one of two ways:
First,
Through the use of two register entries register:count_menuItems which holds the total number of items you will be processing; and register:count_MENUOBJ which holds the index of the current item being iterated (starts at 1). These two can be use in conjunction with a CASE statement to thoroughly process each image to one's liking. If a page has multiple images, there are two more register items one can use, these are, register:FILES_COUNT (which starts to count starting with 0) and register:FILES_NUM_CURRENT. No need for implementing a registry counter since these registry entries are in-themselves, counters.
Secondly,
There's a much easier way, a far less time-consuming way, that uses a wrap as explained by #Bernd, as follows;
NO = 1
NO {
1 = LOAD_REGISTER
1 {
width.cObject = TEXT
width.cObject.stdWrap.wrap = 100c||200c
height.cObject = TEXT
height.cObject.stdWrap.wrap = 300c||400c
}
2 = FILES
2 {
# Get the images related to the current page
references {
table = pages
fieldName = media
}
# Render each image and wrap it as appropriate
renderObj = IMG_RESOURCE
renderObj {
file {
treatIdAsReference = 1
import.data = file:current:uid
width = {REGISTER:width}
width.insertData = 1
height = {REGISTER:height}
height.insertData = 1
}
}
stdWrap {
wrap = <img src="|" />
}
}
}
As you can see, this code is being used in a TMENU and processes each image based on different rules defined in segment 1 and stored by the LOAD_REGISTER. The trick is in the wraps. stdWrap's wrap already contains optionSplit. So by storing the desired pattern, the stdWrap will process the correct value to be stored for each iteration.
It has worked for me. Hope it helps someone.
If I create a Label in a 500x500 area with wordwrap, how can I find out the height of the wrapped text ? I'm looking for the yellow height, not the salmon height.
Answer of #idrise doesn't work for system font And here I give a more flexible answer.
Assume we want to create a text/label which has a fixed width, but dynamic height according to text's length. for that you can use below code:
Label *lbl = Label::createWithSystemFont("aaa aaa aaa aaa aaa aaa", "Arial", 50);
lbl->setDimensions(FIXED_WIDTH, 0); // "0" means we don't care about wrapping vertically, hence `getContentSize().height` give a dynamic height according to text's length
////
auto dynamicHeight = title->getContentSize().height; // According to text's length :)
And obviously for fixed height you can do similarly.
Hope Help someone :]
This may seem a little counter intuitive.
First you set the dimensions with an excessively large height.
Calling getLineHeight and getStringNumLines will calculate the height based on the width passed.
You send the width and height back to setDimensions.
Now your labels getContentSize() will return the actual size of the text.
IE
label->setDimensions(width, 2000);
label->setDimensions(width,label->getStringNumLines() *
ceil(label->getLineHeight()));
They added the functionality you want:
Added three overflow type to new label: CLAMP, SHRINK, RESIZE_HEIGHT.
Overflow type is used to control label overflow result, In SHRINK mode, the font size will change dynamically to adapt the content size. In CLAMP mode, when label content goes out of the bounding box, it will be clipped, In RESIZE_HEIGHT mode, you can only change the width of label and the height is changed automatically. For example:
//Change the label's Overflow type
label->setOverflow(Label::Overflow::RESIZE_HEIGHT);
mTexto=Label::createWithTTF(mTextoHelp.c_str(),CCGetFont(), 30);
mTexto->setHeight(100.f);
mTexto->setOverflow(Label::Overflow::RESIZE_HEIGHT);
mTexto->setDimensions(mSize.width*0.8f, 0.f);
I want to increase the default size of HeaderButton Widget in MGWt.I tried this:
headerBackButton.setHeight(String.valueOf(50)+"px");
headerBackButton.setWidth(String.valueOf(50)+"px");
headerBackButton.getElement().getStyle().setWidth(50, Unit.PX);
headerBackButton.getElement().getStyle().setHeight(50, Unit.PX);
I have just tried in the mgwt.showcase (class UIViewImpl) and using the headerBackButton.setWidth("75px"); works perfect (just after headerBackButton = new HeaderButton(); ).
Have you checked you do not have other elements or other css´rules that block the resize??
For example, in the mgwt showcase after 80px the button does not get bigger because the p child element has the rule max-height
Are it's possible to resize vb6 inner form, because if i use Form1.Height or Form1.Width it's including window border height and width, so i just can use this code in one window theme (ex. it's work best in WinXP with XP theme, but not work in WinXP with Classic theme, it's seen too long), any suggestion?
What you can do is compare the Width (the outside size) to the ScaleWidth (which is the inside size) to get the size on the non-client border. Likewise, you can compare the Height to the ScaleHeight to get the non-client size at the top and bottom. From that you can set your final height and width based on the inner (client area) size you want plus the non-client size.
Something like this could go in your Form_Load:
Const DesiredClientHeight as Single = 3435
Const DesiredClientWidth as Single = 3345
Dim fNonClientHoriz As Single, fNonClientVert As Single
fNonClientHoriz = Me.Width - Me.ScaleWidth
fNonClientVert = Me.Height- Me.ScaleHeight
Me.Width = DesiredClientWidth + fNonClientHoriz
Me.Height = DesiredClientHeight + fNonClientVert
Be aware that the form width and height are always in Twips, so if you change your scale mode to something other than twips you will need to account for that.