My company utilizes a software system that can generate reports and export them to a variety of formats. One of the formats is HTML and it does indeed look nice and keep the fidelity of the reports. However, when I go to print the report some of the elements on the page don't get printed. They are mostly stylistic things like lines that act as borders between areas. They are there when viewed in Chrome or Firefox, but immediately disappear when you go to print.
Everything is made with inline css styling such as:
<div style="page-break-inside:avoid;page-break-after:always;">
<span style="position:absolute;top:0.09388888in;left:0.7161965in;width:6.658803in;height:0.2861111in;font-family:Arial;font-size:14pt;color:Black;font-weight:bold;vertical-align:top;background-color:#FFFFFF;"><nobr>Report</nobr></span>
Here is a fiddle of the report so you can see what I'm talking about:
https://jsfiddle.net/otictac1/60pahz8e/
The yellow bar doesn't print nor do the borders that surround the table looking thing on the right.
Any thoughts on what might be causing that?
Related
I am attempting to print a web page via Ctrl-P or right-click print so I can save it as a PDF. Up until several minutes ago, this was working flawlessly. I have made some minor sizing edits to the grid I am working with on the page and now when I attempt to print, the web page is displaying some formatting glitches on the preview screen.
The problem is shown below. There are various borders missing from the grid and this is carrying over to the PDF when fully saved. Nothing is missing when viewing the page normally.
I am aware this is a silly question, but for the sake documenting it, I did find out my issue.
My textareas are currently overlapping borders in certain areas of my grid. This appears to cause those grid borders to disappear to show the full textarea.
Below I took a snapshot to show how the textarea's blue line is going over my grid.
Solution: add padding to a bordered <div> if a textarea is in it
This is the design of my report:
But when I click a button on runtime to preview the report that is about to be saved as PDF file it looks very different!
However when I download the file as PDF it looks just the way I designed it:
How do I fix the preview design?
White-space is very finicky in SSRS and you are experiencing this different behavior because you are using two different renderers and they are just flat out behaving a bit different. Looking at your design screen, it appears that you have just floating textboxes and white-space underneath between the last content and the footer. HTML rendering can be tricked into rendering that white-space before the footer by placing empty content (textbox or rectangle) in that space like so:
Red box: I would try inserting a blank rectangle off to the side, but the whole height, first.
Blue box: The next option would be to wrap the whole page contents into a rectangle.
It's actually a bit funny because most people are stuck trying to get rid of white-space in their HTML rendered report and you actually have the opposite issue here.
Had this issue when working with report viewer - now having the same issue with SSRS. Basically what happens is I create a report with a certain font - it looks perfect in the preview mode - however, when I go to print it - it makes the text look different - kind of squeezed and looks to be complete different font as a matter of fact. Included image with what it looks like in PREVIEW and PRINT.
Anyone had an issue like this before?
Thank you.
This page and many similar ones give information about rendering, but none of them seem to answer the questions "does this text fit in this box?" and "How big will this box be?" Rendering to IE, Chrome, Safari, Word, and PDF was an exercise in frustration and compromise, especially considering that Visual Studio and Report Builder were also different. In all cases, the height and width of the text boxes changed, the font size changed, and the spacing around the text changed.
Our technique was to prioritize the various output formats, then find settings that produced the best output based on those priorities. Given this, users see better (but still not quite perfect) results than we see in Visual Studio.
I am using “#media print” for printing my html page. Here I am getting problum with background color is not visible of modelbox, when I am trying to print my html page.
FF, Chrome is working fine but IE7 and IE8 it go off. Here is the link : http://jsfiddle.net/9BmXv/
attached screenshot is print preview of html.
Browsers usually have a user preference along the lines of "Print backgrounds" which is turned off by default (to avoid burning through vast amounts of ink). This cannot be overridden by page authors.
Consequently, print designs should almost always aim for a plain white background.
With a design like that, since the main content is covered up, you probably should display: none the main content so you are just printing the area you care about.
It's a setting in IE. I don't think there's a great deal you can do about it other than design your page to work well when printed with white / transparent backgrounds
We have an HTML page which displays a bunch of pretty bars using divs and repeating backgrounds. We are in the process of making a report out of this that can be printed nicely, but this may take some time because we don't have a reporting framework in place. As an interm solution we'd like to make the HTML version printable. The background of the divs are the only problem, and they don't print because of the default setting (which can't be enabled because the workstations are locked down).
I have found a work around for printing background images, but this doesn't work when the background needs to be repeated.
Are there any other work arounds which might be able to help? I have also been trying to insert an image inside the dive and stretch it, but this is throwing off all the other relative positions and is proving to be very difficult to fix. I am still looking into this however.
I have used this ActiveX Component in situations where controlling the printer output was absolutely neccessary (think printing stickers etc).
The function you'd want is : printBackground
However this doesn't come with their free license but perhaps the cost of that license outweigh the other work arounds implementation time.
Drawback: IE only.
If you can educate your users, there is an option in the print dialog box of IE and Firefox that is labeled something like 'Include Background Images' or 'Print Background Images'
This will include repeating background images.
I couldn't load the link, and I may not be understanding the problem correctly, but...
This is more of a work-around than a solution, but would you be able to make a single image that just appears to be repeated? Or at least, is repeated (for variable browser and screen sizes), but is large enough to be 'proper' for printing (which is a much more standard size)?
The easiest way I can think of achieving this is to have different stylesheet for printing that uses standardised images that fit the containers printed on paper.
The display stylesheet would continue to use the repeated images which wouldn't hinder performance as the full images loaded in the print stylesheet would only be loaded when the page is sent to the printer.
...at least, that's what the HTML spec says should happen. Whether this is actually the case, I can't be 100% sure.