I'm writing a service that generates PDF files from a set of XML files. The PDF is being correctly generated. However, everytime I click on the "view PDF" link, the browser asks the user to download the PDF file.
I need the PDF to display inline, just like any regular HTML page. I though I wrote the code right, but something must be missing - the browser keeps asking the user to download.
Here's the current code:
class PdfController < Controller
def generate
# stuff
send_data pdf_bytes, :disposition => 'inline', :type => 'application/pdf'
end
end
Any ideas?
Try removing the Content-Disposition header altogether. It's been my experience that Content-Disposition: attachment works pretty well, but many browsers have inconsistent behavior for any other value. If you want to display inline, it might just be better to remove the header and hope for the best. IE seems to have the most problems with this header. (Surprise, surprise.) Just make sure you're still setting Content-Type: application/pdf.
The other option would be to use an iframe and set the src of the iframe to your PDF file. Almost all browsers that support inline PDF viewing will handle this correctly. The downside is that you might end up displaying a blank iframe whereas non-supported browsers would have otherwise done a graceful fallback to simply downloading the PDF.
Related
I have a DSL that renders HTML. If I manually generate HTML in the console, and save it as a view (as an experiment, there's no reason to do this), so that it lives in app/views/manifests as show.pdf.erb, and then I simply render the PDF using Wicked's/Rails built in rendering, everything works great and looks great. Now, because this is dynamic HTML, meaning it can change based on the data, what I have to do is generate the HTML as a string, and then use Wicked's pdf_from_string:
html = HtmlGenerator.parse_node node, "root", #manifest
pdf = WickedPdf.new.pdf_from_string(html) # note, this is the same HTML that looks great as a view
and then send it to the browser
send_data(pdf,
:filename => "my_pdf_name.pdf",
:disposition => 'inline')
Now, everything is screwed up. It appears like the fonts are 15% bigger, all of my rows are screwed up. Does the rendering routine in WickedPDF use a different formatting that pdf_from_string?
Thanks for any help,
Kevin
I have a Grails app developed in 2.3.6
There's a GSP file with HTML and CSS elements in it, and that displays data in multiple tables with headers.
I want this data to be saved into a text file and save it. So basically what i want to do is, there will be a Export button in this GSP page, and when user clicks on it, it will download the text file with all the data from that GSP.
What i tried so far?
def textFile = {
response.setHeader('Content-Disposition', 'Attachment;Filename="textFile.txt"')
render view: 'textFile', contentType: 'text/plain'
}
The problem with above is, it saves not just data, but also HTML & CSS elements.
I don't want any HTML or CSS in the text file. Only data from GSP is needed.
Is there a simple way of doing it.
the answer is simple - you need another view withouth the html and css parts.
The rest of your code looks good. But Grails itself does not convert your view, it just sends the content type to the browser and the browser tries to diesplay the data according to the content type.
If you don't want to write a new view (in most cases, writing the new view is dead simple), you could write your own converter (something which strips the HTML and CSS from your file) by creating an afterView-Filter: http://grails.github.io/grails-doc/2.4.0/guide/single.html#filters
Hope that helps
I have a pdf being generated by prawn, it contains a header, a table and a footer. Both header and footer are repeatable, with :dynamic => true, the table is not.
The problem I'm having is that all content on the header and footer is displaying as if it's being rendered twice in the same place, and this seems to mess with the anti aliasing function so the text appears to be choppy and bold (see image below). However, when I zoom in or print it, it looks right.
Here's some code of the specific part where I start the repeater blocks:
pdf = Prawn::Document.new :page_size => "A4", :margin => [28, 20, 7, 20]
(...)
pdf.repeat :all, :dynamic => true do
pdf.bounding_box([0, 803], :width => 555, :height => 60) do
pdf.stroke_bounds
(...)
end
end
(...)
pdf.render
# End of file
As far as I know, this is the default way to declare a repeater block, I almost mirrorred it from the manual.
Here's the image: the top container is the header, inside the repeater, it looks like everything is bold, but it's the exact same font and line width as the section below, which is from the table, and looks fine. Sorry I can't post a larger part of the pdf, it's for confidentiality reasons.
If I remove the repeater, the header will look correct, as it should, but when I add it again it looks like this.
Has anyone else encountered this issue before? How do I fix it?
EDIT: Added some more code above. Also added the code below, which is inside a Rails template file, "historico.pdf.prawn", and this is how I call it on the controller to render the PDF and return it to the user:
rendered_pdf = render_to_string :template => "reports/historico.pdf"
send_data rendered_pdf, :filename => "Historico.pdf", :type => "application/pdf"
When you use pdf.repeat :all the pdf is 'reopened' after the document is already created and the data within the repeat block is added. This can cause a myriad of odd behavior, I believe this is what is causing your issue.
There is a related issue with a solution that utilizes Prawn's canvas method. If you adapt this solution to your problem (use canvas to generate your header and footer, rather than repeat :all) , you should no longer have these text-on-top-of-text problems.
Note:
It may be important for you to know that Prawn has officially stated that they are, "not in a good position to support templating features (I bring this up because you appear to be creating a template), " so similar workarounds may be needed if you continue to use this tool for these types of needs. Depending on your dependance on these types of templating features, you may want to look into using a different tool.
How do I export all my rendered view to an html file? I want to save the view to a file rather than display it to the screen. Is this possible?
Instead of render call render_to_string and save the returned string into an file.
(see: http://apidock.com/rails/AbstractController/Rendering/render_to_string)
This sort of sounds like Dynamic Page Caching. There is a Railscasts on this topic. It is rather dated, unless you subscribe (there is a revised version with subscription).
http://railscasts.com/episodes/169-dynamic-page-caching
We have translated one of our pages to french and all the html within the page displays flawlessly. That said, there is a javascript table (ext js) and the accented characters are not displaying correctly. The page is encoded UTF-8 in the HTML meta tags, but when I look inside FireBug, I see the following:
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
I'm guessing the problem is related to the ISO-8859-1 having worked its way back in. Does anyone know why the page itself would display fine, but the text inside the javascript component wouldn't? Do you somehow specify the encoding separately for the javascript files?
The Accept-Charset tag gives a set of encodings that are accepted -- if all the data sent is encoded UTF-8, then don't worry about it.
Can you elaborate on exactly what is happening?
You say "javascript table" -- I presume you are constructing an HTML table in JS and placing it in the DOM? Please elaborate, especially w.r.t. any character conversions. Are you building HTML text or building with DOM elements with attributes?
Where does the JS get its data? If with AJAX, have you verified the Encoding for that page?
Does the JS use encode() or decode()? Those don't handle UTF-8 correctly.
EDIT:
Type the URL to the JS code in your browser, and look at "Page Info" to see its encoding. I'll bet it is ISO-8859-1, which would explain the header problems.
Next, check the encoding of the AJAX data. If it's dynamically created you can:
Enable "Show XMLHttpRequests" in FireBug's console,
Load on your base HTML page,
Open the FireBug console tab,
Expand the AJAX GET/POST request and open the Response sub-tab,
Check the Encoding for the data, and fix as needed.
BTW, I'm having similar problems and haven't entirely ironed out the issues (still not sure the source data isn't badly encoded).
It's possible that the ext. JS file strips out unrecognised characters as a security precaution.
The "Accept-Charset" header can be specified in a number of places, including as an attribute in certain HTML elements. Have you performed a search for Accept-Charset (case insensitive) in the offending file?