We have some reports that are loaded on a asp.net webpage via the localreport.render() and a request has come in to hide a logo image if it is displayed inline as html on the page and only show the image if it's rendered as a pdf.
is there any way to determine the render mode in the report so i can create an expression to set the display property to hidden for the logo image if it's not pdf mode?
I've been searching google and msdn with no luck.
thanks!
What version of SSRS are you using? If you are using SQL Server Reporting Services 2008 R2 I think you are in luck. Check out the link below, he explains how to do what you are asking but the opposite ( display the image in HTML but NOT int PDF ). I'm sure you could just reverse the logic...
http://www.mssqltips.com/tip.asp?tip=2106
The Hidden expression for the image would be...
=Globals!RenderFormat.IsInteractive
This would evaluate to Hidden=true for HTML and Hidden=false for PDF since PDF is considered non-interactive in this context.
Here is what I did to accomplish something similar:
I used the ReportViewer.LocalReport.Render method to render the report to Excel, PDF, etc. and manually streamed that back to the user for download. In order for the report to determine if it is being exported I simply set a parameter before the export and reset the parameter after the export. Something like this:
reportViewerMain.LocalReport.SetParameters(new ReportParameter("IsExporting", "true"));
byte[] bytes = reportViewerMain.LocalReport.Render("Excel");
reportViewerMain.LocalReport.SetParameters(new ReportParameter("IsExporting", "false"));
Related
I have been using the (free version) HiQPdf libraries to converto html pages to pdf documents.
I am also using in my pages several Chart objecs from the .Net Framework (System.Web.UI.DataVisualization.Charting.Chart) to produce bar graphics dysplaying values changing along time. It works wonders in my local environment when I debug with VS, but when I publish on my IIS or on other servers the charts do not appear at all on the pdf - note: they do appear on the webpages just not on the pdf.
In the Pdfs all the html is displayed correctly, inlcuding css, showing it exactly as seen on the page, except the chart images. I kind of understand that they would not appear as in the html, the image source from the charts results in something like:
<img id="MainContent_MyPageControl_ctl00" src="/MyTestWebSite/ChartImg.axd?i=charts_0/chart_0_2.png&g=396d61e14ceb41c08be06fd956cd4dca"
Because the real generated png image is not even directly referenced as usual. But the fact is they do appear on the generated pdf when running local from VS, which produces a similar html anyway as the above.
Only difference I see is that when I run local the Image Chart Handler key is defined in the webconfig as:
add key="ChartImageHandler" value="storage=file;timeout=20;dir=c:\TempImageFiles\;"
but when publishing on a server I have changed it to:
add key="ChartImageHandler" value="storage=file;timeout=20;Url=~/MyfolderTempcharts/;deleteAfterServicing=false;"
So why dont the charts appear too on my generated pdf, or why they do appear if Im running from VS?
Anyone ever had this problem?
So I have figured out a way to deal with my problem, and I am sharing here if anyone is also in need. The deal is that the Chart objects use http handlers to render the chart generated images (you can read more about it in detail from these guys: https://web.archive.org/web/20201205231110/https://www.4guysfromrolla.com/articles/081909-1.aspx)
At first I thought I could manipulate the html (that I get before the page render) and replace the image sources with accessible links to send to the HiQPdf - for that I would need to temporarely copy the generated images to a public folder. That would be fine unless in my case I deal with sensitive data that should never be accessed even if only momentarily.
So what I do is I check that the image file does exists (in my configured folder) and extract the byte data from it, convert it to base 64 and replace it in the image source html where the handler is, and voila.
example of Base64 html embeded image:
Notice that this manipulated html is never accessible from the outside and is only worked on on the server side, in order to provide a "normal" html that the HiQPdf can pprocess.
I am building a large scale web application with many "print" requests a minute. We have dynamic content from an editor that I print out with other HTML elements. What is more efficient, rendering that html and then printing the html page or rendering a PDF server side and displaying that in an iframe to be printed?
With the multiple server side calls for rendering the images plus authenticating the user (and we also have a dynamic image header and footer dependent on the logged in user) would it be more efficient to render native PDF controls and then put a pdf in an iframe to print?
I was planning on using itext sharp or http://www.websupergoo.com/ for the rendering.
the app is a c# Web forms application.
As I see it in order to generate the PDF you need to generate the HTML. So by generating the PDF you are adding to the processing required not reducing it.
Using WKHtmlToPDF to generate PDFs for my company's web-based mapping service.
Essentially, I take a template HTML file, inject an image into a div, save the HTML to disk and use WKHtmlToPDF to render to PDF.
Now, on most templates it works a treat. On one particular one though, where the image should be (int the pdf) is a grey area. HOWEVER, if I right click on the grey area, and select "Save Image As...", the saved image is correct.
Linked are the created PDF and the HTML on which it is based. Help required most urgently, and hints appreciated.
Zip File Containing HTML and PDF
I was having an issue where a particular image was not being printed to the PDF. Other images on the same page were. The src of the missing image is from a CDN, but had no extension, i.e. src="\\path/to/image?param". Using the aforementioned -n switch (disable Javascript), the image shows up in the resulting PDF. Thanks Jordaan.
Don't know WHY this worked, but adding the "--disable-smart-shrinking" option, and/or removing the "-n"(Disable Javascript) option, fixed it.
I want to ask you how to render a pdf in asp.net using c#.
so my web can show a pdf.
You can use Aspose.PDF or iText (there is a free version).
You can read about the licensing for iText for more information on the comment provided below.
One way is to generate latex from your application and then convert latex into pdf:
http://www.emphess.net/2010/11/09/create-high-quality-pdfs-with-razor-view-engine-and-latex
The nice thing about doing it this way is that you can write your views just like all your other views, except you use latex instead of html.
You can use the ReportViewer component (in "Local Processing Mode", so you don't need the SQL Server Reporting Services) to show a Report created in Visual Studio in a web page.
If you want the report to output directly as a PDF (instead of being shown in the ReportViewer control), you can use the technique outlined in this article to render the report on the server and then send the PDF stream to the web client:
How to render client report definition files (.rdlc) directly to the Response stream without preview
The advantage of this solution is that you don't need to use any third-party libraries.
I have a 2-page PDF that I want to overlay information on (think of a form that someone manually fills out) using a C#/.NET Windows application. After this form is generated, it will need to be previewed and printed (exported into a graphic or PDF is nice, but not a requirement).
At first glance, I'm thinking of two ways to do this:
Use a PDF manipulator like iTextSharp, take a copy of the blank PDF form, and add text to the PDF. Then, launch Adobe Reader to do a print or preview.
Convert the PDF into a graphic, and put the graphic into a C# Report. Then, overlay text fields onto the report, and use a .NET ReportViewer control to preview and print the report.
The text does not need to be searchable or copyable or have any of the cool things that PDF gives me, so I'm leaning towards the second option. Am I missing anything, or is there something I'm not thinking of? Thanks in advance.
We use #1 extensively and it works perfectly. You shouldn't have any problems, it's rather easy (just need to make the fields writeable and use a FDF file and merge it with the PDF file). At least that's how we did it.