printing a browser window with scrolled page

[acarur01]

I had a question about browser printing with SmartClient. In normal websites, if I go to File->Print, I get a printed version of the whole website page, including the out-of-view data. If I do the same with a smartclient page in which the root layout is a VLayout that has overflow as "auto", only the visible content at the time of the printing shows up. Do you know why this happens? Is it because this isn't actually the browser's scrollbar? How do we enable it so that it prints everything on the page including the part that is only visible when we scroll down?

[Isomorphic]

When you print with the SmartClient printing system, you get whatever content you ask for - scrolling has no effect.

When you use native browser printing on a page, browsers do pretty wildly varying things - we don't try to guarantee any particular behavior here.

[acarur01]

Sorry but I don't understand. Take for example the attached html. Load in IE or Firefox. Re-size the browser so that the scroll bar appears. Now go to File->Print on the browser window. What I see is the window itself being printed, including the scrollbar image.

What I was expecting was a printout of the content in the page kind of like when I print this list http://forums.smartclient.com/forumdisplay.php?f=13 in a resized browser window. So what makes the SmartClient UI different from regular HTML pages?

[Isomorphic]

So what makes the SmartClient UI different from regular HTML pages?

Almost everything? The markup used for sophisticated widgets differs in almost every way from that used for just ordinary web content.

So again:

When you use native browser printing on a page, browsers do pretty wildly varying things - we don't try to guarantee any particular behavior here.

You should use the SmartClient printing system to get printed output. Direct browser printing is going to produce wildly inconsistent results.

[acarur01]

Ok. Can you then tell me how to manipulate the SmartClient printing so that the printout is almost identical to what is currently on the screen? There are elements that you remove by default when printing. Our client thinks it is ugly. Unnecessary obviously, but ugly. I know I can use PrintProperties to include Buttons but there must be an easier way to say "include everything".

[acarur01]

To give you an example,here is how I tried invoking the printPreview - even after I have added Button class and Image class, the printout was still missing the checkbox icon and the listgrid headers in the html sample I attached in an earlier response

			var controlsArray = new Array();
			controlsArray[0] = "Button";
			controlsArray[1] = "ListGrid";
			controlsArray[2] = "Menu";
			controlsArray[3] = "Image"
			controlsArray[4] = "DynamicForm";
			controlsArray[5] = "MenuButton";
			controlsArray[6] = "HeaderSpan";
			isc.Canvas.showPrintPreview(VerticalLayout,{includeControls:controlsArray});

[Isomorphic]

There isn't an easy way to do that, because we really don't think that makes any sense. Buttons and Menus have generally been observed to work poorly after being printed ;)

To get closer to what's literally shown on the screen, you would have to, as you say, manipulate PrintProperties to re-introduce Buttons. But this would not re-introduce all interactive controls, because several widgets have printed output that omits interactive controls which are not Buttons or other Canvas subclasses per se (for example, FormItem icons), or that just omits interactive controls without references PrintProperties, since this is considered *always* desirable in printed output.

You would also have to re-add gradients and other things that print poorly to the CSS styles that are specifically used for printing. But because the printed output uses simplified DOM structures that work better when printing, we would not expect it to be possible to produce even a close facsimile of the normal, non-printed output, and this is a non-goal of the system.

The best advice we can give is to try to convince this particular client that printing interactive controls doesn't make sense. We've never heard anyone else ask for that.

[acarur01]

This customer does not want to back down. To summarize what they want - pretty much a "what you see is what you get" printout of their screens, including the window-level scrollable UI. We are willing to look into sponsorship for this if this is the only way to get support for the behaviour they want.

[Isomorphic]

That's unfortunate. And frankly bizarre.

We can help with this, but to set expectations, this will not be sponsorship (or only a tiny part of it will be). We absolutely do not want to try to support a WYSIWYG printing mode in the framework - as we explained before, we consider that pretty much useless.

But we can help via Consulting. To get that started, use the Contact page.

But first, you should clarify what you want - you just referred to WYSIWYG behavior with a "window-level scrollable UI". Does this mean that, for example, a grid showing a scrollbar should still show a scrollbar, clipping off records that were not shown on the screen? Because if you want that.. maybe you should just encourage your customer to take a screenshot.