absolute image paths

[skeller1]

Hi,
I'm using dragonfly and wicked_pdf plugin in a rails 3.03 app.
Wicked_pdf transforms html views to pdf files with help of wkhtmltopdf
(webkit).

The problem: The html.pdf template needs absolute paths to all
resources (images, js, css).

Any chance to use wicked_pdf with dragonfly and his relative/absolut
image paths ("src=media/dksfh39f33dfd3249fDHF4545/image.png")?



Getting a solution for my problem I have two possibilities:

1. make dragonfly urls absolute, but dragonfly is a rack app (a route
in a rails app), I think it isn't possible, is it?

With ActionController::Base.asset_host I can make the urls remote

2. change code of wicked_pdf to allow remote images ( it's using
tempfile to create => https://github.com/mileszs/wicked_pdf/tree/master/lib
)

PS: prawn, an other pdf generator gem uses open-uri to open remote
images (https://github.com/sandal/prawn/blob/master/examples/graphics/
remote_images.rb)

Any idea?

[Nathan Hessler]

skeller1,

I may not be understanding your question completely, but depending on my understanding I see 2 solutions. in your dragonfly config you can reset the url_path_prefix to be "/media/" which would give you an absolute path and if you need an absolute url then when you call for the url pass in the hostname like this: image.process(:whatever).url(:host => "http:/yourdomain.com/"). this should give you http://yourdomain.com/media/numbers_and_letters does that answer your question?

Nathan

[skeller1]

Hi,

I've already tested it with dragonfly url option. Here the code in the
index.pdf.erb file:
(http://pastie.org/1512394)

Here is the html view in debug mode of wicked_pdf:
http://wicked.heroku.com/projects.pdf?debug=true

All image src paths are absolute and calling /projects.pdf brings a
nice pdf file with google remote image (src=http://www.google.de/
images/nav_logo29.png)

But doing this :

<%= image_tag @players.image.thumb("320x240>").url(:host => prefix) #
=> same like in http://pastie.org/1512394

breaks the pdf generation (an endless request)


So is this a problem of dragonfly? Perhaps locking problem?


PS: Nathan Hessler, do you speak German?

[Nathan Hessler]

I don't speak german. sorry.  I'm also, not familiar enough with wicked_pdf to speak to many of the errors, but the urls work fine in html debug mode so I'm not really sure why the links wouldn't work in pdf mode. I did notice that the code you put in the email says @players.image and you probably want @player.image, but it was fine in the pastie link so I'm guessing that was just an email typo. do you have anymore debugging/log info you could pass along?

[skeller1]

hi nathan,

a new app version is online now, pdf generation works
http://wicked.heroku.com/projects.pdf

But still the same problem in development mode on my pc.

I' have tested it also on 3 other computers. I have checked the source
code of wicked_pdf and the problem is in the pdf_from_file method into
the :
(https://github.com/mileszs/wicked_pdf/blob/master/lib/wicked_pdf.rb)
def pdf_from_string(string, options={})
command_for_stdin_stdout = "#{@exe_path} #{parse_options(options)}
-q - - " # -q for no errors on stdout
p "*"*15 + command_for_stdin_stdout + "*"*15 unless defined?
(Rails) and Rails.env != 'development'
pdf, err = begin
Open3.popen3(command_for_stdin_stdout) do |stdin, stdout,
stderr|
stdin.write(string)
stdin.close
[stdout.read, stderr.read]
end
rescue Exception => e
raise "Failed to execute #{@exe_path}: #{e}"
end
raise "PDF could not be generated!\n#{err}" if pdf and pdf.length
== 0
pdf
end

I always using thin to start rails apps on my local machine, but
because I did some code changes in the plugin I used shotgun gem.

I started my app with shotgun and got the pdf with only 2 of 4 images
total.

That's the output in the console of shotgun:

"***************/home/neo/Projekte/wicked/bin/wkhtmltopdf-i386 -q
- - ***************"
(eval):3: [BUG] Segmentation fault
ruby 1.8.7 (2010-01-10 patchlevel 249) [i486-linux]

[2011-01-31 19:05:43] ERROR EOFError: end of file reached


So, I think it's not a wicked_pdf or dragonfly error? But a server
issue?

Any thoughts?


PS: And thats the output in the browser view by checking stdin of
Open3.popen3.

RuntimeError in ProjectsController#index

PDF could not be generated!
Loading pages (1/5)
[> ] 0%
[======> ] 10%
[======> ] 11%
[======> ] 11%
[========> ] 14%
[=========> ] 16%
[==========> ] 18%
[============> ] 20%
[=============> ] 23%

That is the output of wkhtmltopdf in the command, so the tool can't
get all resources of the pdf.

[skeller1]

I have made a rails 3.0.3 app for testing.

Here's the link https://github.com/skeller1/dragonfly_wicked_pdf

The repo has two versions of wkhtmltopdf inside the bin folder.
Please choose the right version (i386 or amd64) in the wicked_pdf.er
in initializer folder:

Thanks

[Ryan Detert]

I'm about to start doing some pdf generation myself in the next day or two. Before I started using Dragonfly I was using gem 'pdfkit', which I'll let you know how it works.

I cloned your repo and couldn't get it to work on my Mac  

/Users/ryan/.rvm/rubies/ruby-1.8.7-p330/lib/ruby/1.8/open3.rb:73:in `exec': Exec format error - /Users/ryan/tmp/dragonfly_wicked_pdf/bin/wkhtmltopdf-i386      -q - -  (Errno::ENOEXEC)

--

[ 530.400.3185 | aim: bruceius | @rdetert ]

[skeller1]

I have no experiences with wkhtmltopdf, but you need a mac version.

Here is the link

http://code.google.com/p/wkhtmltopdf/downloads/list

[skeller1]

sorry, I have no experiences with wkhtmltopdf under OSX, so good luck

[skeller1]

I already know pdfkit, but I don't want use a middleware and doing the
pdf routing for only a few controllers is not the right way in my
opinion.
But in the end, I have already tested pdfkit and dragonfly and the
result is the same. wicked_pdf and pdfkit are using the same command
in the console. so there's no difference between both. Only the
registration process (middleware and action controller renderer)

[Nathan Hessler]

skeller1,

I'm not sure if thats a wicked_pdf or server issue, but I'm fairly certain it's not a dragonfly issue. I've been proven wrong many times before though. the reason I don't think it's a dragonfly issue is that I'm guessing the same url is build regardless and we know it works when used through the browser so maybe the pdf isn't building a proper request or something or the server is failing in some way. but if the url is the same across all cases then I find it unlikely to be dragonfly that is causing the error.