We are trying to set up screenshot tests to automate UI/ layout regression testing by comparing screenshots against an expected set of screenshots. We are using testcafé for that but we are struggling when scrollbars come into play for full-page fixed width screenshots:
const testcafe: TestController;
await testcafe
.resizeWindow(1024, 768)
.takeScreenshot({
fullPage: true
});
This will result in a screenshot with a width of 1003px (not 1024px!) and a height of 1546px. Nonetheless, the screenshot still contains the vertical scrollbar which is surely not out of coincidence 21px wide. It's neither full page as few pixels are also missing at the bottom of the page which most likely does actually result in the vertical scrollbar.
When trying to workaround the reduced width by adding additional pixels (21 to be exact), the screenshot is indeed 1024px wide and has a slightly reduced height of 1510px (as something on the page is not required to be wrapped anymore). It's still missing parts at the bottom of the screenshot and it still has a scrollbar.
const testcafe: TestController;
await testcafe
.resizeWindow(1024+21, 768)
.takeScreenshot({
fullPage: true
});
Now it gets slightly more weird: The behavior just described continues up to a width of 1024+21+20 px. Screenshots have a width of (1024-21) +21+20 px, a height of 1510px and scrollbar. Starting from 1024+2*21 though the vertical scrollbar disappears, the screenshot is complete also at the bottom with 1510px as the correct height (as again something else on the page doesn't have to wrap anymore) - but unfortunately I do have a screenshot with a width of 1045px which is not of the intended width of 1024px.
If I specify resizeWindow with a width of 1024px I do expect a screenshot exactly of that width if it does include a scrollbar. If testcafe thinks it has to take the screenshot without the scrollbar and reduce the screenshot to a width of 1003px it's also fine with me - but here I guess it has somehow considered the scrollbar but still not actually cut it off.
The same mechanism for a page which content doesn't require the height of 768px, in other words doesn't have a scrollbar to begin with, the screenshot has a width of 1024px without any "correction".
Few versions if relevant:
node: v14.16.0
testcafe: 1.10.1
browser: Chrome 89.0.4389.72 running on Windows 10
Do you have any further ideas?
i have some picture which is 675x503. I would like to make more width on it and let's say to 1024 and in height to 400. How to do that without cutting my image and keep quality? I just would like to have this image on my website top. I got photoshop 6. I tried with Image->image size but its not what i need.
If you don't want to cut the picture at all, this will distort the image due to different height and width ratios. If this is not an issue, you could simply hit ctrl(or cmd)+t when the layer with the picture is selected. It will let you resize and rotate the entire image. There is also an option in the Image -> Image Size menu called "Bicubic Sharper", found in the drop-down list at the bottom of the menu(Photoshop CS6). It's meant for image reduction and should also solve your problem.
I'm using vb.net to make a screen saver.
I want my label where the text shows to always be centered no matter what screen size it is.
is there a way to get the screen resolution of the current monitor?
if i can get that then i can calculate the middle and set my label there.
Stretch the label to the whole width of the form and dock/anchor to left and right side within the label parameters. This will center your label whatever the size of the form.
I try to setup UltraMon with a really big width and height for my Safari on Windows.
See capture : http://cl.ly/de21e9cd2cf4f265efc4
The problem is that the width and height seems to have a max value that I would like to change.
I want UltraMon not to change my width and height, even if they are bigger than the screen resolution.
Windows doesn't allow that, according to the developers of UltraMon.
See http://www.realtimesoft.com/multimon/forum/messages.asp?tmpl=UltraMon&Topic=10795#39510
I have a RDLC report and I am displaying it on the Report Viewer Control in my front end application. I am able to view the report perfectly.
But the problem arises when I try to export the report to a PDF (using the built-in option).
I print the report in 3 pages whereas my client wants it to be in a single page. I can't figure out the reason for it as in my report viewer I see only one page but in a PDF there are 3 pages.
Can something be done about it so that I can control the size of the report?
The answer is pretty similar to what Dugan said, but it's not always just the margins.
It is pretty simple though:
When you are editing the rdlc file in design mode, firstly click on an empty part of the BODY area of your design. Hit F4 to see the properties tab. Here, you will see a "Size" property. This can be expanded for the width and height. The width you see here represents the width that the body of your report requires as printable area. Even if you have white space all over, the page knows that it needs to keep it as a printable area. It reserves the space, in some sense. As for the height, the system generally knows that it can grow or shrink as necessary, unless you have specified otherwise within your controls therein. So the width is what will, usually, play the most important role.
Next, click on an empty area of the report (outside the header, body, and footer; basically the gray area around the design), then hit F4 to view the properties panel. Under the "Layout" category of the properties, you will see 3 different options:
InteractiveSize,
Margins,
PageSize.
Each of those Size attributes can be expanded to show the Width and Height. The Margins attribute can be expanded for the left/right/top/bottom.
Basically, the pdf export works out of the PageSize (though I generally try to keep Interactive and Page size equal). When the pdf file is rendered via the ReportViewer's built-in export function, the width and height of each "page" within the pdf will be determined by the width and height in the report's PageSize attribute (you could override this if you used your own custom code for the pdf rendering).
As for the margins, they specify how much space MUST be left blank and unprintable between the printable area reserved for your report and the edge of the page.
In other words:
Your report's Body's Width, Plus the Report's Left Margin, Plus the Report's Right Margin, MUST be smaller than or equal to the Report's PageSize's Width!
So...if your margins are too wide, or if your report's body is too wide, or if the PageSize's width is too narrow, the rendered result is forced to be broken down to multiple pages in order to fit!
For example: If my report's body has width 7.75", my Left margin is 0.5", my right margin is 0.5", and the width specified in the PageSize is 8.5", my report will always use 2 pages for each 1 page of data. The 7.75" width of the body, plus 0.5"+0.5" for the margins add up to 8.75", which is larger than the 8.5" available in my page. So the first 7.5" (or so) of each page of my report's body will be shown in the first page, and the rest will be split down to the next page. This will not be done inside the report viewer, as it allows for the report to grow beyond the page size by just adding a scrollbar, but it will be annoyingly noticeable in the pdf export.
In order to make my example report fit in 1 page, I can either try and reduce the body of my report to 7.5" or less, or I can reduce the left and right margins by a total of 0.25" or more (for example, set them to 0.3" for a total reduction of 0.4"), or I can increase the PageSize to something larger than 8.75".
Note: Acrobat Reader is pretty smart and knows about various paper sizes. Therefore, while arbitrary PageSizes will work, it is typically best to use real page sizes. As such, in my last example I would rather set the PageSize to have Width = 11" and Height = 8.5", which is a real letter-size in landscape! Adobe will typically understand this and print properly.
Also Note: Some printers, especially older ones, have trouble printing with less than 0.3" margins. If you want to be nice to your users, you should best keep the margins large enough for those older printers ;)
I hope this helps.
Always maintain body width : 7.5 or less
Left, Right Margin width less than 0.5
Set the Margin width first -> goto main menu Reports->Report Properties->Layout->change left margin and right margin
Total page width :8.5
Ramana
In addtion to watching your widths, I found other unrelated things that can cause extra blank page in the PDF.
If the tablix has any field with word wrap, this can cause it. You might want to make the font smaller if you have long data. Make the font size property equal to something like this:
=iif(len(Fields!RepGroupName.Value) > 25, "6pt","8pt")
Another thing you may have to do. And this helped me when I had no apparent reason for the extra page. In the Report property page, set:
ConsumeContainerWhitespace = true
Yet another thing to watch for. The body size can grow without you knowing it while making changes to the layout. You might have to knock it back down again.
This issue is highly annoying for the end user if not resolved and annoying as heck for us to resolve.
In case anyone else runs into this issue and ends up here, it's most likely a issue with your margins. If the margins are set incorrectly, you will often get "extra" pages that appear when you try and print, whereas when you view the document everything is fine.