PDF Viewer Email Extension

PDF Viewer Email Extension

Posted by: pdan2993 on 28 September 2017, 4:22 am EST

• 

  pdan2993

  • Post Options:
  • Link
    Copy

  Posted 28 September 2017, 4:22 am EST

  [activereports_archive]

  Can anyone figure this out. It is a lingering issue with no sollution!!
  
  
  
  Originally addressed in article 104005
  
  
  
  When generating a report using the .NET WebControl to PDF format I am unable to email the report with the correct extension. The report generates correctly but the email attachment supplied by the Acrobat viewer has the extension *.ArCacheItem.
  
  
  
  If you do a direct stream, the file name is that of the page creating the stream…ending in .aspx
  
  
  
  I have seen other threads that touch on this issue but have not seen any clear concise sollitions. What are my options? Is there any way to possibly create a HTTPHandler to catch the request and modify the extension before it is sent to the viewer?
  
  
  
  Any assistance on this issue would be helpful. My users are not intellegent enough to save the file to the hard drive and attach it up the old fashioned way.

  [/activereports_archive]

• 

  brandon-dd

  • Post Options:
  • Link
    Copy

  Posted 28 September 2017, 4:22 am EST

  [activereports_archive]

  If you must use the webviewer control, I don’t believe there’s anyway to save the report with an extension other than ARCacheItem since the webviewer is expecting the file to come through the HTTP Handlers with that extension. If you were to stream the report (like in the standard web sample), you could control the file name with the Content Disposition header as shown in KB article 868.
  
  
  
  brandon. -DD

  [/activereports_archive]

• 

  pdan2993

  • Post Options:
  • Link
    Copy

  Posted 28 September 2017, 4:22 am EST

  [activereports_archive]

  This issue was already hashed out here with no solution. The DD team said it was an Adobe issue. I beg to differ. Since your view creates an ARCacheItem and that is the file name adobe uses…then that renders the ability to email from the Adobe viewer useless. One of the major powers of Acrobat viewer is the ability for business professionals to easily transmit documents via email using such an easy function.
  
  
  
  Seems like the same old problem is being rehashed and getting the same old asnwers. If someone tells me this is an Adobe Acrobat issue I think I will explode. It just cant be that hard to change the page name behind the scenes. I am just too stupid to figure it out!!!
  
  
  
  If anyone knows anything about httpmodules and could advise on how to change the url path but not redirect to it, I think that would enough of a work around to get adobe acrobat to use the correct file name. context.rewritepath will not work. That rewrites and redirects…ugly error on that one.
  
  
  
  Oh…actually, a content-disposition set to Attachment WILL work…but it throws the stupid download message. I must have it inline. Just like the guy in the previous post.

  [/activereports_archive]

• 

  pdan2993

  • Post Options:
  • Link
    Copy

  Posted 28 September 2017, 4:22 am EST

  [activereports_archive]Anyone…Anyone…Anyone…Bueler…Bueler…?

  [/activereports_archive]
• 

  brandon-dd

  • Post Options:
  • Link
    Copy

  Posted 28 September 2017, 4:22 am EST

  [activereports_archive]

  Once the PDF is exported to Adobe, ActiveReports no longer has control over the PDF file. The application (Acrobat Reader) will need to determine the correct file type. The webviewer control needs the extension .ArCacheItem to display the PDF file. ActiveReports cannot change the filename in the PDF since it’s purpose is to generate the PDF. The only other solution is creating the PDF on the server and emailing it from the server, outside of the webviewer control.
  
  
  
  brandon. -DD

  [/activereports_archive]

• 

  pdan2993

  • Post Options:
  • Link
    Copy

  Posted 28 September 2017, 4:22 am EST

  [activereports_archive]

  I came up with the following sollution and would greatly appreciate any feedback or input to streamline the approach.
  
  
  
  Every bit of the below code is done so that once the stream is sent to the client, the URL will read orderreport.pdf instead of orderreport.aspx and thus acrobat viewer has the correct file name and format.
  
  
  
  1) I mapped .pdf extensions to .NET
  
  2) In source page (OrderReport.aspx) button click event I generate using report.run(), export to pdf, write to stream and save stream to session state - Then response.redirect(“orderreport.pdf”)
  
  3) Global_BeginRequest - If context.response.path.endswith(orderreport.pdf) then Context.RewritePath(“…/reportviewer.aspx”)
  
  4) Global_AquireRequestState - if path ends with reportviewer.aspx then
  
  Dim mStream As System.IO.MemoryStream = _
  
  CType(Context.Session(“CurrentReport”), IO.MemoryStream)
  
  Context.Response.ContentType = “application/pdf”
  
  Context.Response.AddHeader(“Content-Length”, mStream.Length.ToString())
  
  Context.Response.AddHeader(“Content-Disposition”, “inline; filename=pdftest.pdf”)
  
  Context.Response.BinaryWrite(mStream.ToArray())
  
  Context.Response.End()
  
  
  
  Then session.clear(“currentreport”) cause the stream is no longer needed.
  
  
  
  The only catch here is having a completely blank reportviewer.aspx that does nothing but exist so you don’t get a page not found error. And also having to do the pdf mapping in IIS.
  
  
  
  Anyone have any better ideas. This method works like a charm but just seems like a little too much work for such a simple task.
  
  
  
  

  [/activereports_archive]

• 

  scottgc

  • Post Options:
  • Link
    Copy

  Posted 28 September 2017, 4:22 am EST

  [activereports_archive]
  
  On the Internet the way to provide a suggested filename for saving the file is done with the content-disposition header. As is described in RFC2183, the filename parameter of the content-disposition header should be used as the basis for the actual filename when the document is stored in a separate file. This works with MSExcel and other applications, just not Acrobat.
  
  However, I realize this is not a solution for what you’re asking. I’ve recorded a suggestion and assigned it issue #CR12628 to investigate a way to make Adobe Acrobat’s Save As… dialog display a file ending with extension .pdf. I have a couple of ideas for improving this using the WebViewer in the future. However, there will be a trade off. One goal is to make the configuration of the WebViewer and HttpHandlers as easy as possible (i.e. none), as the WebViewer’s main goal is to provide a very easy way to display reports in ASP.NET applications. However, I think implementing a solution to trick Acrobat into displaying a .PDF file name for a dynamically generated file may require some additional setup (installing ISAPI extensions or other IIS configuration). Your suggestions and comments on this trade-off would be appreciated.
  
  
  
  Anyway, for now, I believe the only solution for this would be one of the following:
  
  - Save the PDF to a file on the server, and redirect the browser to the file.
  
  - Use the Application’s BeginRequest handler as “pdan2993” describes.
  
  - Create and install a IHttpModule to attach to attach a BeginRequest handler.
  
  
  
  Saving the PDF to a file is certainly the easiest approach, but has the undesirable side-effect of requiring cleanup of the created files. The other two options are more involved and complicated, but enable dynamic generation of the files (no cleanup).
  
  [/activereports_archive]

• 

  cal1ga

  • Post Options:
  • Link
    Copy

  Posted 28 September 2017, 4:22 am EST

  [activereports_archive]

  Is there any update on this issue. It’s too much hassle just get the extension right.
  
  
  
  Also, is there a detail write-up on pdan2993’s solution. I’m a AR (asp.net as well) newbie .
  
  
  
  not familiar at all with “Application BeginRequest”

  
  
  

  [/activereports_archive]
• 

  scottgc

  • Post Options:
  • Link
    Copy

  Posted 28 September 2017, 4:22 am EST

  [activereports_archive]I have taken some time to look for other sites that set the name of a PDF file. So far I’ve only seen Acrobat work with one of the three solutions described in my earlier post which are:
  
  - Save the PDF to a file on the server, and redirect the browser to the file.
  
  - Use the Application’s BeginRequest handler as “pdan2993” describes.
  
  - Create and install a IHttpModule to attach to attach a BeginRequest handler.
  
  
  
  I’ve left the suggestion open in case somebody else recommends a workaround to fix Acrobat’s problem of not recognizing the content-disposition header. If we find a reasonable workaround we should implement it.
  
  [/activereports_archive]

• 

  pdan2993

  • Post Options:
  • Link
    Copy

  Posted 28 September 2017, 4:22 am EST

  [activereports_archive]I have written the perfect solution to the problem. I have a HttpHandler catching all of my PDF requests and it even ensures that the PDF’s are opened in a new window.
  
  

  I am not yet a licensed user for AR.NET. We are still on the Evaluation due to memory issues. We are still deciding whether to go with MS Reporting Services.
  
  
  
  I would be happy to share a working copy of my sollution of DataDynamics would like to cut me a deal on a License :)
  
  
  
  I don't really feel like breaking the code out since I am not sure if we are even going to purchase the product. But...If we were to get a break...I would difinitely break it out. It really is simple...or atleast...I think it is.

  [/activereports_archive]
• 

  cal1ga

  • Post Options:
  • Link
    Copy

  Posted 28 September 2017, 4:22 am EST

  [activereports_archive]Tried to implement beginrequest handler, without much success. I got an error on AcquireRequestState. could you post some sample code to the httpmodule![/activereports_archive]

• 

  brooke1

  • Post Options:
  • Link
    Copy

  Posted 28 September 2017, 4:22 am EST

  [activereports_archive]

  For months I was having an issue with emailing Reports that were generated as PDF files using Adobe 6.0 from our .Net application. I came to the site seeking a solution. I tried the using the following code I found as suggested solution here:
  
  Response.AddHeader(“Content-Length”, P_Stream.Length.ToString())
  
  Response.AddHeader(“Content-Disposition”, “attachment; filename=foo.pdf”)
  
  The users were not happy about the additional widow that opened. So I continued my investigation.
  
  I found the solution in Adobe Reader 6.0. In the Internet Preference if the “Display PDF in browser” option is not checked (which is checked by default) then the correct file extention will be sent. So I did not have to add the code above. The users were asked to modify their Adobe setting and now they are emailing without an issue.

  [/activereports_archive]

• 

  brandon-dd

  • Post Options:
  • Link
    Copy

  Posted 28 September 2017, 4:22 am EST

  [activereports_archive]

  If you change the line:
  
  Response.AddHeader(“Content-Disposition”, “attachment; filename=foo.pdf”)
  
  to read:
  
  Response.AddHeader(“Content-Disposition”, “inline; filename=foo.pdf”)
  
  
  
  It should have the same effect as setting the property on the users machines.
  
  
  
  brandon. -DD
  
  

  [/activereports_archive]

• 

  brooke1

  • Post Options:
  • Link
    Copy

  Posted 28 September 2017, 4:22 am EST

  [activereports_archive]

  I have tried it both ways and:
  
  Response.AddHeader(“Content-Disposition”, “inline; filename=Report.pdf”) does not work for me. It attaches the .aspx file. In my application the email is generated and then the user emails if from Adobe if he chooses. When the property is set on the client’s machine the generated report does not open in the browser
  
  window where you see the path for the page from which the report was generated. Instead it opens the Adobe window with the name of the PDF document. Therefore it is not confused as to what file to attach.
  
  

  [/activereports_archive]

• 

  philjmcc

  • Post Options:
  • Link
    Copy

  Posted 28 September 2017, 4:22 am EST

  [activereports_archive]

  When accessing your report .aspx page add a querystring with value of “/filename.pdf” to the end.

  reportPage.aspx?EXT=/filename.PDF

  This will work because the PDF viewer will use the text in the URL after the last “/” character for the mailto attachment filename.

  For DD to get the WebViewer to work with PDF mailto, could they append a similar querystring to the end of the “.ArCacheItem” extension.

  “.ArCacheItem?EXT=/filename.PDF”

  I do agree this is a issue with the PDF viewer because if you use “Save a Copy” the PDF viewer automatically appends a “.PDF” exetension.

  Anyway I hope this hack helps.
  
  

  [/activereports_archive]