I'm trying to do an image conversion in a rails app from SVG to PNG. ImageMagick didn't work out for me, due to Heroku not able / wanting to upgrade IM at this time. I'm testing out some ideas of using RSVG2 / Cairo in dev but running into a roadblock.
I can easily convert and save the SVG to PNG like this:
#svg_test.rb
require 'debugger'
require 'rubygems'
require 'rsvg2'
SRC = 'test.svg'
DST = 'test.png'
svg = RSVG::Handle.new_from_file(SRC)
surface = Cairo::ImageSurface.new(Cairo::FORMAT_ARGB32, 800, 800)
context = Cairo::Context.new(surface)
context.render_rsvg_handle(svg)
surface.write_to_png(DST)
But this only lets me write PNG files out. In the app, I need to be able to generate these on the fly, then send them down to the client browser as data. And I can't figure out how to do this, or even if its supported. I know I can call surface.data to get the raw data at least, but I don't know enough about image formats to know how to get this as a PNG.
Thanks
Ah ha! I was so close and its pretty obvious in hindsight. Simply call the surface.write_to_png function with a StringIO object. This fills the string object, which you can then get the bytes for. Here's the finished svg_to_png function I wrote, along with a sample controller that calls it. Hope this helps someone else somewhere.
ImageConvert function:
def self.svg_to_png(svg)
svg = RSVG::Handle.new_from_data(svg)
surface = Cairo::ImageSurface.new(Cairo::FORMAT_ARGB32, 800, 800)
context = Cairo::Context.new(surface)
context.render_rsvg_handle(svg)
b = StringIO.new
surface.write_to_png(b)
return b.string
end
Test controller:
def svg_img
path = File.expand_path('../../../public/images/test.svg', __FILE__)
f = File.open(path, 'r')
t = ImageConvert.svg_to_png(f.read)
send_data(t , :filename => 'test.png', :type=>'image/png')
end
Related
Context
In our platform we allow users to upload word documents, those documents are stored in google drive and then dowloaded again to our platform in HTML format to create a section where the users can interact with that content.
Rails 5.0.7
Ruby 2.5.7p206
selenium-webdriver 3.142.7 (latest stable version compatible with our ruby and rails versions)
Problem
Some of the documents have charts or graphics inside that are not processed correctly giving wrong results after all the process.
We have been trying to fix this problem at the moment we get the word document and before to send it to google drive.
I'm looking for a simple way to export the entire chart and/or table as an image, if anyone knows of a way to do this the advice would be much appreciated.
Edit 1: Adding some screenshots:
This screenshot is from the original word doc:
And this is how it looks in our systems:
Here are the approaches I have tried that haven't worked for me so far.
Approach 1
Using nokogiri to read the document and found the nodes that contain the charts (we've found that they are called drawing) and then use Selenium to navigate through the file and take and screenshot of that particular section.
The problem we found with this approach is that the versions our gems are not compatible with the latest versions of selenium and its web drivers (chrome or firefox) and it is not posible to perform this action.
Other problem, and it seems is due to security, is that selenium is not able to browse inside local files and open it.
options = Selenium::WebDriver::Firefox::Options.new(binary: '/usr/bin/firefox', headless: true)
driver = Selenium::WebDriver.for :firefox, options: options
path = "#{Rails.root}/doc_file.docx"
driver.navigate.to("file://#{path}")
# Here occurs the first issue, it is not able to navigate to the file
puts "Title: #{driver.title}"
puts "URL: #{driver.current_url}"
# Below is the code that I am trying to use to replace the images with the modified images
drawing_elements = driver.find_elements(:css, 'w|drawing')
modified_paragraphs = []
drawing_elements.each do |drawing_element|
paragraph_element = drawing_element.find_element(:xpath, '..')
paragraph_element.screenshot.save('paragraph.png')
modified_paragraph = File.read('paragraph.png')
modified_paragraphs << modified_paragraph
end
driver.quit
file = File.open(File.join(Rails.root, 'doc_file.docx'))
doc = Nokogiri::XML(file)
drawing_elements = doc.css('w|drawing')
drawing_elements.each_with_index do |drawing_element, i|
paragraph_element = drawing_element.parent
paragraph_element.replace(modified_paragraphs[i])
end
new_doc_file = File.write('modified_doc.docx', doc.to_xml)
s3_client.put_object(bucket: bucket, key: #document_path, body: new_doc_file)
File.delete('doc_file.docx')
Approach 2
Using nokogiri to get the drawing elements and the try to convert it directly to an image using rmagick or mini_magick.
It is only possible if the drawing element actually contains an image, it can convert that correctly to an image, but the problem is when inside of the drawing element are not images but other elements like graphicData, pic, blipFill, blip. It needs to start looping into the element and rebuilding it, but at that point of time it seems that the element is malformed and it can't rebuild it.
Other issue with this approach is when it founds elements that seem to conform an svg file, it also needs to loop into all the elements and try to rebuild it, but the same as the above issue, it seems that the element is malformed.
response = s3_client.get_object(bucket: bucket, key: #document_path)
docx = response.body.read
Zip::File.open_buffer(docx) do |zip|
doc = zip.find_entry("word/document.xml")
doc_xml = doc.get_input_stream.read
doc = Nokogiri::XML(doc_xml)
drawing_elements = doc.xpath("//w:drawing")
drawing_elements.each do |drawing_element|
node = get_chil_by_name(drawing_element, "graphic")
if node.xpath("//a:graphicData/a:pic/a:blipFill/a:blip").any?
img_data = node.xpath("//a:graphicData/a:pic/a:blipFill/a:blip").first.attributes["r:embed"].value
img = Magick::Image.from_blob(img_data).first
img.write("node.jpeg")
node.replace("<img src='#{img.to_blob}'/>")
elsif node.xpath("//a:graphicData/a:svg").any?
svg_data = node.xpath("//a:graphicData/a:svg").to_s
Prawn::Document.generate("node.pdf") do |pdf|
pdf.svg svg_data, at: [0, pdf.cursor], width: pdf.bounds.width
end
else
puts "unsupported format"
end
end
# update the file in S3
s3.put_object(bucket: bucket, key: #document_path, body: doc)
end
Approach 3
Convert the elements since its parents to a pdf file and then to an image.
Basically the same issue as in the approach 2, it needs to loop inside all the elements and try to rebuild it, we haven't found a way to do that.
When using a web service I receive a string that looks like this:
JVBERi0xLjIgDQoxIDAgb2JqDQo8PA0KL1R5cGUgL0NhdGFsb2cNCi9QYWdlcyAzIDAgUg0KL1BhZ2VNb2RlIC9Vc2VOb25lDQovUGFnZUxheW91dCAvU2luZ2xlUGFnZQ0KPj4NCmVuZG9iag0KMiAwIG9iag0KPDwNCi9Qcm9kdWNlciAoUGRmQ3JlYXRvciB2ZXJzaW9uIDEuMCkNCi9BdXRob3IgKCkNCi9DcmVhdGlvbkRhdGUgKEQ6MjAxNzA4MjUxMTM0MDApDQovQ3JlYXRvciAoKQ0KL0tleXdvcmRzICgpDQovU3ViamVjdCAoKQ0KL1RpdGxlICgpDQovTW9kRGF0ZSAoRDoyMDE3MDgyNTExMzQwMCkNCj4+DQplbmRvYmoNCjMgMCBvYmoNCjw8DQovVHlwZSAvUGFnZXMNCi9LaWRzIFs0IDAgUiBdDQovQ291bnQgMQ0KPj4NCmVuZG9iag0KNCAwIG9iag0KPDwNCi9UeXBlIC9QYWdlDQovUGFyZW50IDMgMCBSDQovTWVkaWFCb3ggWzAgMCA0MjUgMjkyIF0NCi9SZXNvdXJjZXMgPDwNCi9Gb250IDw8DQovRjAgNiAwIFINCi9GMSA4IDAgUg0KPj4NCi9YT2JqZWN0IDw8DQovMCA3IDAgUg0KPj4NCi9Qcm9jU2V0IFsvUERGIC9UZXh0IC9JbWFnZUMgXQ0KPj4NCi9Db250ZW50cyA1IDAgUg0KPj4NCmVuZG9iag0KNSAwIG9iag0KPDwNCi9MZW5ndGggNDE4DQovRmlsdGVyIFsvRmxhdGVEZWNvZGUgXQ0KPj4NCnN0cmVhbQ0KeF6lVMtu2zAQvPMr9tjmwHCXD1G9uXkiCBI3VtND0YNj0akL20ppGQX69V1Slp2iRWI4ECCMRHJmd2ek43MFpSwsVFORMKqEFKQrPoqPlUCpFD89u3dvtHe820g+uhDvEE6a+bx5D9UPcVbtCBAl8Y7rl5k8kKYN0+D+omf5+k1BLbQpgbyFhTBoMpp3yDlGeTWjrui7C4HwS6z264EPUtErn8fxcrJtoRMnVQBRmcV5L6Mkzp2jZ5RWO7QVV3uLI4tjP78jPTo9uz+xxnhntTNH/Qx+CnJWKpObs066EpyXSgNZaQ1MFuJYwWkjPmX7/F/ula8MPg+RJGUHB9PfYVmH+OEfD1+jyTNi/zqe4e2ournuSf6TqX0ikSoz5SYRw2bV7hi32dyXRxcbntEsztarOoYwBUMwOCisqTJyG0ZCTV8quGyaaV038ekgRuJvjtC/vdlMpPrahqENEeoAd+sZo4NLw5KDlp29nddh+bCOjyGu2jget4C62BmNgJyAZz8P1Ongi59+Khk9Ss4tC2hb6NEVfG5jmHxve+Y/1ub6WwplbmRzdHJlYW0NCmVuZG9iag0KNiAwIG9iag0KPDwNCi9UeXBlIC9Gb250DQovU3VidHlwZSAvVHlwZTENCi9GaXJzdENoYXIgMzINCi9MYXN0Q2hhciAyNTUNCi9CYXNlRm9udCAvSGVsdmV0aWNhDQovRW5jb2RpbmcgPDwNCi9UeXBlIC9FbmNvZGluZw0KL0RpZmZlcmVuY2VzIFszMiAvc3BhY2UgMTk2IC9BZGllcmVzaXMgMjE0IC9PZGllcmVzaXMgMjIwIC9VZGllcmVzaXMgMjI4IC9hZGllcmVzaXMgMjQ2IC9vZGllcmVzaXMgMjUyIC91ZGllcmVzaXMgMjIzIC9nZXJtYW5kYmxzIDE5MiAvQWdyYXZlIDE5NCAvQWNpcmN1bWZsZXggMTk4IC9BRSAxOTkgL0NjZWRpbGxhIDIwMCAvRWdyYXZlIDIwMSAvRWFjdXRlIDIwMiAvRWNpcmN1bWZsZXggMjAzIC9FZGllcmVzaXMgMjA2IC9JY2lyY3VtZmxleCAyMDcgL0lkaWVyZXNpcyAyMTIgL09jaXJjdW1mbGV4IDE0MCAvT0UgMjE3IC9VZ3JhdmUgMjE5IC9VY2lyY3VtZmxleCAxNTkgL1lkaWVyZXNpcyAyMjQgL2FncmF2ZSAyMjYgL2FjaXJjdW1mbGV4IDIzMCAvYWUgMjMxIC9jY2VkaWxsYSAyMzIgL2VncmF2ZSAyMzMgL2VhY3V0ZSAyMzQgL2VjaXJjdW1mbGV4IDIzNSAvZWRpZXJlc2lzIDIzOCAvaWNpcmN1bWZsZXggMjM5IC9pZGllcmVzaXMgMjQ0IC9vY2lyY3VtZmxleCAxNTYgL29lIDI0OSAvdWdyYXZlIDI1MSAvdWNpcmN1bWZsZXggMjU1IC95ZGllcmVzaXMgMTk3IC9BcmluZyAyMTYgL09zbGFzaCAxOTMgL0FhY3V0ZSAyMDUgL0lhY3V0ZSAyMTggL1VhY3V0ZSAyMjEgL1lhY3V0ZSAyMjkgL2FyaW5nIDI0OCAvb3NsYXNoIDIyNSAvYWFjdXRlIDIzNyAvaWFjdXRlIDI1MCAvdWFjdXRlIDI1MyAveWFjdXRlIDIxMCAvT2dyYXZlIDI0MiAvb2dyYXZlIDIwNCAvSWdyYXZlIDIzNiAvaWdyYXZlIDE5NSAvQXRpbGRlIDIxMyAvT3RpbGRlIDIyNyAvYXRpbGRlIDI0NSAvb3RpbGRlIDIyMiAvVGhvcm4gMjU0IC90aG9ybiAyMDkgL050aWxkZSAyNDEgL250aWxkZSAxMzggL1NjYXJvbiAxNTQgL3NjYXJvbiAyNDMgL29hY3V0ZSAyMTEgL09hY3V0ZSBdDQo+Pg0KL1dpZHRocyBbMjc4IDI3OCAzNTUgNTU2IDU1NiA4ODkgNjY3IDE5MSAzMzMgMzMzIDM4OSA1ODQgMjc4IDMzMyAyNzggMjc4IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiAyNzggMjc4IDU4NCA1ODQgNTg0IDU1NiAxMDE1IDY2NyA2NjcgNzIyIDcyMiA2NjcgNjExIDc3OCA3MjIgMjc4IDUwMCA2NjcgNTU2IDgzMyA3MjIgNzc4IDY2NyA3NzggNzIyIDY2NyA2MTEgNzIyIDY2NyA5NDQgNjY3IDY2NyA2MTEgMjc4IDI3OCAyNzggNDY5IDU1NiAzMzMgNTU2IDU1NiA1MDAgNTU2IDU1NiAyNzggNTU2IDU1NiAyMjIgMjIyIDUwMCAyMjIgODMzIDU1NiA1NTYgNTU2IDU1NiAzMzMgNTAwIDI3OCA1NTYgNTAwIDcyMiA1MDAgNTAwIDUwMCAzMzQgMjYwIDMzNCA1ODQgMCA1NTYgMCAyMjIgNTU2IDMzMyAxMDAwIDU1NiA1NTYgMzMzIDEwMDAgNjY3IDMzMyAxMDAwIDAgNjExIDAgMCAyMjIgMjIyIDMzMyAzMzMgMzUwIDU1NiAxMDAwIDMzMyAxMDAwIDUwMCAzMzMgOTQ0IDAgNTAwIDY2NyAwIDY2NyA1NTYgNTU2IDU1NiA1NTYgNjY3IDU1NiAzMzMgNzM3IDM3MCA1NTYgNjExIDAgNzM3IDYxMSA0MDAgNTU2IDMzMyAyMjIgMzMzIDU1NiA1MDAgMzMzIDMzMyAyNzggMzY1IDU1NiA1MDAgODM0IDgzNCA1MDAgNjY3IDY2NyA2NjcgNjY3IDY2NyA2NjcgMTAwMCA3MjIgNjY3IDY2NyA2NjcgNjY3IDI3OCAyNzggMzMzIDMzMyA3MjIgNzIyIDc3OCA3NzggNzc4IDc3OCA3NzggNTg0IDc3OCA3MjIgNzIyIDcyMiA3MjIgNjY3IDY2NyA2MTEgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgODg5IDUwMCA1NTYgNTU2IDU1NiA1NTYgMjc4IDI3OCAzMzMgMzMzIDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1ODQgNjExIDU1NiA1NTYgNTU2IDU1NiA1MDAgNTU2IDUwMCBdDQovTmFtZSAvRjANCj4+DQplbmRvYmoNCjcgMCBvYmoNCjw8DQovTGVuZ3RoIDE2Mg0KL0ZpbHRlciBbL0ZsYXRlRGVjb2RlIF0NCi9UeXBlIC9YT2JqZWN0DQovU3VidHlwZSAvSW1hZ2UNCi9Db2xvclNwYWNlIFsvSW5kZXhlZCAvRGV2aWNlUkdCIDIyMyA8MDAwMDAwIDAwMDAzMyAwMDAwNjYgMDAwMDk5IDAwMDBjYyAwMDAwZmYgMDAzMzAwIDAwMzMzMyAwMDMzNjYgMDAzMzk5IDAwMzNjYyAwMDMzZmYgMDA2NjAwIDAwNjYzMyAwMDY2NjYgMDA2Njk5IDAwNjZjYyAwMDY2ZmYgMDA5OTAwIDAwOTkzMyAwMDk5NjYgMDA5OTk5IDAwOTljYyAwMDk5ZmYgMDBjYzAwIDAwY2MzMyAwMGNjNjYgMDBjYzk5IDAwY2NjYyAwMGNjZmYgMDBmZjAwIDAwZmYzMyAwMGZmNjYgMDBmZjk5IDAwZmZjYyAwMGZmZmYgMzMwMDAwIDMzMDAzMyAzMzAwNjYgMzMwMDk5IDMzMDBjYyAzMzAwZmYgMzMzMzAwIDMzMzMzMyAzMzMzNjYgMzMzMzk5IDMzMzNjYyAzMzMzZmYgMzM2NjAwIDMzNjYzMyAzMzY2NjYgMzM2Njk5IDMzNjZjYyAzMzY2ZmYgMzM5OTAwIDMzOTkzMyAzMzk5NjYgMzM5OTk5IDMzOTljYyAzMzk5ZmYgMzNjYzAwIDMzY2MzMyAzM2NjNjYgMzNjYzk5IDMzY2NjYyAzM2NjZmYgMzNmZjAwIDMzZmYzMyAzM2ZmNjYgMzNmZjk5IDMzZmZjYyAzM2ZmZmYgNjYwMDAwIDY2MDAzMyA2NjAwNjYgNjYwMDk5IDY2MDBjYyA2NjAwZmYgNjYzMzAwIDY2MzMzMyA2NjMzNjYgNjYzMzk5IDY2MzNjYyA2NjMzZmYgNjY2NjAwIDY2NjYzMyA2NjY2NjYgNjY2Njk5IDY2NjZjYyA2NjY2ZmYgNjY5OTAwIDY2OTkzMyA2Njk5NjYgNjY5OTk5IDY2OTljYyA2Njk5ZmYgNjZjYzAwIDY2Y2MzMyA2NmNjNjYgNjZjYzk5IDY2Y2NjYyA2NmNjZmYgNjZmZjAwIDY2ZmYzMyA2NmZmNjYgNjZmZjk5IDY2ZmZjYyA2NmZmZmYgOTkwMDAwIDk5MDAzMyA5OTAwNjYgOTkwMDk5IDk5MDBjYyA5OTAwZmYgOTkzMzAwIDk5MzMzMyA5OTMzNjYgOTkzMzk5IDk5MzNjYyA5OTMzZmYgOTk2NjAwIDk5NjYzMyA5OTY2NjYgOTk2Njk5IDk5NjZjYyA5OTY2ZmYgOTk5OTAwIDk5OTkzMyA5OTk5NjYgOTk5OTk5IDk5OTljYyA5OTk5ZmYgOTljYzAwIDk5Y2MzMyA5OWNjNjYgOTljYzk5IDk5Y2NjYyA5OWNjZmYgOTlmZjAwIDk5ZmYzMyA5OWZmNjYgOTlmZjk5IDk5ZmZjYyA5OWZmZmYgY2MwMDAwIGNjMDAzMyBjYzAwNjYgY2MwMDk5IGNjMDBjYyBjYzAwZmYgY2MzMzAwIGNjMzMzMyBjYzMzNjYgY2MzMzk5IGNjMzNjYyBjYzMzZmYgY2M2NjAwIGNjNjYzMyBjYzY2NjYgY2M2Njk5IGNjNjZjYyBjYzY2ZmYgY2M5OTAwIGNjOTkzMyBjYzk5NjYgY2M5OTk5IGNjOTljYyBjYzk5ZmYgY2NjYzAwIGNjY2MzMyBjY2NjNjYgY2NjYzk5IGNjY2NjYyBjY2NjZmYgY2NmZjAwIGNjZmYzMyBjY2ZmNjYgY2NmZjk5IGNjZmZjYyBjY2ZmZmYgZmYwMDAwIGZmMDAzMyBmZjAwNjYgZmYwMDk5IGZmMDBjYyBmZjAwZmYgZmYzMzAwIGZmMzMzMyBmZjMzNjYgZmYzMzk5IGZmMzNjYyBmZjMzZmYgZmY2NjAwIGZmNjYzMyBmZjY2NjYgZmY2Njk5IGZmNjZjYyBmZjY2ZmYgZmY5OTAwIGZmOTkzMyBmZjk5NjYgZmY5OTk5IGZmOTljYyBmZjk5ZmYgZmZjYzAwIGZmY2MzMyBmZmNjNjYgZmZjYzk5IGZmY2NjYyBmZmNjZmYgZmZmZjAwIGZmZmYzMyBmZmZmNjYgZmZmZjk5IGZmZmZjYyBmZmZmZmYgYzBjMGMwIDgwODA4MCA4MDAwMDAgMDA4MDAwIDAwMDA4MCA4MDgwMDAgODAwMDgwIDAwODA4MCA+IF0NCi9XaWR0aCAyMjA5DQovSGVpZ2h0IDENCi9CaXRzUGVyQ29tcG9uZW50IDgNCi9OYW1lIC8wDQo+Pg0Kc3RyZWFtDQp4XsWVUQ7AIAxCvf8Fvc7+tImEPuKy+bXUKZTSOtaaaontHSpf+6zfpveNdWEDV0mLVM6QZUBRHVIlnGsqGFBSXgqpI5b5n4RlRlLfi6rmGlAGmv5ZTto8k/aqJyjg0lDJDPuK2hh1cesMVdWYwduF1qOBJcznIB3QrOh3GvgnwjHAvpIQXz4L22qtK9l0D//iqGqAxO81lbYxO/XVA7D3SAYKZW5kc3RyZWFtDQplbmRvYmoNCjggMCBvYmoNCjw8DQovVHlwZSAvRm9udA0KL1N1YnR5cGUgL1R5cGUxDQovRmlyc3RDaGFyIDMyDQovTGFzdENoYXIgMjU1DQovQmFzZUZvbnQgL0hlbHZldGljYS1Cb2xkDQovRW5jb2RpbmcgPDwNCi9UeXBlIC9FbmNvZGluZw0KL0RpZmZlcmVuY2VzIFszMiAvc3BhY2UgMTk2IC9BZGllcmVzaXMgMjE0IC9PZGllcmVzaXMgMjIwIC9VZGllcmVzaXMgMjI4IC9hZGllcmVzaXMgMjQ2IC9vZGllcmVzaXMgMjUyIC91ZGllcmVzaXMgMjIzIC9nZXJtYW5kYmxzIDE5MiAvQWdyYXZlIDE5NCAvQWNpcmN1bWZsZXggMTk4IC9BRSAxOTkgL0NjZWRpbGxhIDIwMCAvRWdyYXZlIDIwMSAvRWFjdXRlIDIwMiAvRWNpcmN1bWZsZXggMjAzIC9FZGllcmVzaXMgMjA2IC9JY2lyY3VtZmxleCAyMDcgL0lkaWVyZXNpcyAyMTIgL09jaXJjdW1mbGV4IDE0MCAvT0UgMjE3IC9VZ3JhdmUgMjE5IC9VY2lyY3VtZmxleCAxNTkgL1lkaWVyZXNpcyAyMjQgL2FncmF2ZSAyMjYgL2FjaXJjdW1mbGV4IDIzMCAvYWUgMjMxIC9jY2VkaWxsYSAyMzIgL2VncmF2ZSAyMzMgL2VhY3V0ZSAyMzQgL2VjaXJjdW1mbGV4IDIzNSAvZWRpZXJlc2lzIDIzOCAvaWNpcmN1bWZsZXggMjM5IC9pZGllcmVzaXMgMjQ0IC9vY2lyY3VtZmxleCAxNTYgL29lIDI0OSAvdWdyYXZlIDI1MSAvdWNpcmN1bWZsZXggMjU1IC95ZGllcmVzaXMgMTk3IC9BcmluZyAyMTYgL09zbGFzaCAxOTMgL0FhY3V0ZSAyMDUgL0lhY3V0ZSAyMTggL1VhY3V0ZSAyMjEgL1lhY3V0ZSAyMjkgL2FyaW5nIDI0OCAvb3NsYXNoIDIyNSAvYWFjdXRlIDIzNyAvaWFjdXRlIDI1MCAvdWFjdXRlIDI1MyAveWFjdXRlIDIxMCAvT2dyYXZlIDI0MiAvb2dyYXZlIDIwNCAvSWdyYXZlIDIzNiAvaWdyYXZlIDE5NSAvQXRpbGRlIDIxMyAvT3RpbGRlIDIyNyAvYXRpbGRlIDI0NSAvb3RpbGRlIDIyMiAvVGhvcm4gMjU0IC90aG9ybiAyMDkgL050aWxkZSAyNDEgL250aWxkZSAxMzggL1NjYXJvbiAxNTQgL3NjYXJvbiAyNDMgL29hY3V0ZSAyMTEgL09hY3V0ZSBdDQo+Pg0KL1dpZHRocyBbMjc4IDMzMyA0NzQgNTU2IDU1NiA4ODkgNzIyIDIzOCAzMzMgMzMzIDM4OSA1ODQgMjc4IDMzMyAyNzggMjc4IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiAzMzMgMzMzIDU4NCA1ODQgNTg0IDYxMSA5NzUgNzIyIDcyMiA3MjIgNzIyIDY2NyA2MTEgNzc4IDcyMiAyNzggNTU2IDcyMiA2MTEgODMzIDcyMiA3NzggNjY3IDc3OCA3MjIgNjY3IDYxMSA3MjIgNjY3IDk0NCA2NjcgNjY3IDYxMSAzMzMgMjc4IDMzMyA1ODQgNTU2IDMzMyA1NTYgNjExIDU1NiA2MTEgNTU2IDMzMyA2MTEgNjExIDI3OCAyNzggNTU2IDI3OCA4ODkgNjExIDYxMSA2MTEgNjExIDM4OSA1NTYgMzMzIDYxMSA1NTYgNzc4IDU1NiA1NTYgNTAwIDM4OSAyODAgMzg5IDU4NCAwIDU1NiAwIDI3OCA1NTYgNTAwIDEwMDAgNTU2IDU1NiAzMzMgMTAwMCA2NjcgMzMzIDEwMDAgMCA2MTEgMCAwIDI3OCAyNzggNTAwIDUwMCAzNTAgNTU2IDEwMDAgMzMzIDEwMDAgNTU2IDMzMyA5NDQgMCA1MDAgNjY3IDAgNzIyIDU1NiA2MTEgNTU2IDU1NiA2NjcgNTU2IDMzMyA3MzcgMzcwIDU1NiA2MTEgMCA3MzcgNjExIDQwMCA1NTYgMzMzIDI3OCAzMzMgNjExIDU1NiAyNzggMzMzIDMzMyAzNjUgNTU2IDUwMCA4MzQgODM0IDUwMCA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiAxMDAwIDcyMiA2NjcgNjY3IDY2NyA2NjcgMjc4IDI3OCAyNzggMjc4IDcyMiA3MjIgNzc4IDc3OCA3NzggNzc4IDc3OCA1ODQgNzc4IDcyMiA3MjIgNzIyIDcyMiA2NjcgNjY3IDYxMSA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA4ODkgNTU2IDU1NiA1NTYgNTU2IDU1NiAyNzggMjc4IDI3OCAyNzggNjExIDYxMSA2MTEgNjExIDYxMSA2MTEgNjExIDU4NCA2MTEgNjExIDYxMSA2MTEgNjExIDU1NiA2MTEgNTU2IF0NCi9OYW1lIC9GMQ0KPj4NCmVuZG9iag0KeHJlZg0KMCA5DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMTEgMDAwMDAgbg0KMDAwMDAwMDExMSAwMDAwMCBuDQowMDAwMDAwMjk4IDAwMDAwIG4NCjAwMDAwMDAzNjMgMDAwMDAgbg0KMDAwMDAwMDU3MyAwMDAwMCBuDQowMDAwMDAxMDc0IDAwMDAwIG4NCjAwMDAwMDMwMDcgMDAwMDAgbg0KMDAwMDAwNDk1MSAwMDAwMCBuDQp0cmFpbGVyDQo8PA0KL1NpemUgOQ0KL1Jvb3QgMSAwIFINCi9JbmZvIDIgMCBSDQo+Pg0Kc3RhcnR4cmVmDQo2ODg4DQolJUVPRg0K
Sorry for that.
Anyway, this should be a pdf because that was one of the request parameters. (I could also have chosen for .gif, or .jpg in different qualities.)
I tried reading the content, like this:
#label_binary = #response_label[:generate_label_response][:response_shipments][:response_shipment][:labels][:label][:content]
binary_data = Base64.decode64(#label_binary)
#label = File.open('file_name.pdf', 'wb') {|f| f.write(Base64.decode64(binary_data))}
But what this prints then as #label is just a number (three of four digits). Same when I use urlsafe_decode64.
Not very helpful.
Preferred end-result would be a pdf image file that I can immediately display (in this case a barcode on top of an invoice for sending a package).
Could I for this purpose save the file temporarily? Meaning: every time I need to display I rebuild this image. I think that would be best.
EDIT
I am making the call now directly to a 600dpi .jpg image and then:
base_64_binary_data = #response_label[:generate_label_response][:response_shipments][:response_shipment][:labels][:label][:content]
#jpg_file = File.open('label.jpg', 'wb') do |file|
content = Base64.decode64 base_64_binary_data
file << content
end
This file shows up at my_apps_name/label.jpg.
In my filesystem I can see the picture crystal clear.
In my view I then put:
<%= image_tag #jpg_file.path %>
When I inspect my html in the browser I see:
<img src="/images/label.jpg" alt="Label">
I suppose this is easily fixed, suggestions are still welcome of course, but...
..more importantly: What if this call is made several times at once. Will rails manage? Should I maybe save these images (to my S3) or build some kind of chronejob to manage it?
(I am not sure of the added value of mini_magic anymore, since I can see the .jpg being already there.)
Then on a complete side note, maybe better left for a separate question: what if the API on the other side fails?
Step one
decode http response
require "base64"
BASE_64_BINARY_DATA = "PASTE YOUR BIG STRING HERE"
pdf_file = File.open('your_pdf.pdf', 'wb') do |file|
content = Base64.decode64 BASE_64_BINARY_DATA
file << content
end
Step two
convert pdf file to an image
add to gemfile 'gem 'mini_magick' and use 'bundle install' command
put somewhere in your code
require 'mini_magick'
pdf = MiniMagick::Image.new(pdf_file.path)
pdf.pages.first.write("preview.png")
image saved as preview.png
To display pdf image put in the view
<%= image_tag ("path_to_image/preview.jpg")%>
Firstly, I am aware that there are quite a few questions that are similar to this one in SO. I have read most, if not all of them, over the past week. But I still can't make this work for me.
I am developing a Ruby on Rails app that allows users to upload mp3 files to Amazon S3. The upload itself works perfectly, but a progress bar would greatly improve user experience on the website.
I am using the aws-sdk gem which is the official one from Amazon. I have looked everywhere in its documentation for callbacks during the upload process, but I couldn't find anything.
The files are uploaded one at a time directly to S3 so it doesn't need to load it into memory. No multiple file upload necessary either.
I figured that I may need to use JQuery to make this work and I am fine with that.
I found this that looked very promising: https://github.com/blueimp/jQuery-File-Upload
And I even tried following the example here: https://github.com/ncri/s3_uploader_example
But I just could not make it work for me.
The documentation for aws-sdk also BRIEFLY describes streaming uploads with a block:
obj.write do |buffer, bytes|
# writing fewer than the requested number of bytes to the buffer
# will cause write to stop yielding to the block
end
But this is barely helpful. How does one "write to the buffer"? I tried a few intuitive options that would always result in timeouts. And how would I even update the browser based on the buffering?
Is there a better or simpler solution to this?
Thank you in advance.
I would appreciate any help on this subject.
The "buffer" object yielded when passing a block to #write is an instance of StringIO. You can write to the buffer using #write or #<<. Here is an example that uses the block form to upload a file.
file = File.open('/path/to/file', 'r')
obj = s3.buckets['my-bucket'].objects['object-key']
obj.write(:content_length => file.size) do |buffer, bytes|
buffer.write(file.read(bytes))
# you could do some interesting things here to track progress
end
file.close
After read the source code of the AWS gem, I've adapted (or mostly copy) the multipart upload method to yield the current progress based on how many chunks have been uploaded
s3 = AWS::S3.new.buckets['your_bucket']
file = File.open(filepath, 'r', encoding: 'BINARY')
file_to_upload = "#{s3_dir}/#{filename}"
upload_progress = 0
opts = {
content_type: mime_type,
cache_control: 'max-age=31536000',
estimated_content_length: file.size,
}
part_size = self.compute_part_size(opts)
parts_number = (file.size.to_f / part_size).ceil.to_i
obj = s3.objects[file_to_upload]
begin
obj.multipart_upload(opts) do |upload|
until file.eof? do
break if (abort_upload = upload.aborted?)
upload.add_part(file.read(part_size))
upload_progress += 1.0/parts_number
# Yields the Float progress and the String filepath from the
# current file that's being uploaded
yield(upload_progress, upload) if block_given?
end
end
end
The compute_part_size method is defined here and I've modified it to this:
def compute_part_size options
max_parts = 10000
min_size = 5242880 #5 MB
estimated_size = options[:estimated_content_length]
[(estimated_size.to_f / max_parts).ceil, min_size].max.to_i
end
This code was tested on Ruby 2.0.0p0
I have a Dragonfly processor which should take a given PDF and return a PNG of the first page of the document.
When I run this processor via the console, I get back the PNG as expected, however, when in the context of Rails, I'm getting it as a PDF.
My code is roughly similar to this:
def to_pdf_thumbnail(temp_object)
tempfile = new_tempfile('png')
args = "'#{temp_object.path}[0]' '#{tempfile.path}'"
full_command = "convert #{args}"
result = `#{full_command}`
tempfile
end
def new_tempfile(ext=nil)
tempfile = ext ? Tempfile.new(['dragonfly', ".#{ext}"]) : Tempfile.new('dragonfly')
tempfile.binmode
tempfile.close
tempfile
end
Now, tempfile is definitely creating a .png file, but the convert is generating a PDF (when run from within Rails 3).
Any ideas as to what the issue might be here? Is something getting confused about the content type?
I should add that both this and a standard conversion (asset.png.url) both yield a PDF with the PDF content as a small block in the middle of the (A4) image.
An approach I’m using for this is to generate the thumbnail PNG on the fly via the thumb method from Dragonfly’s ImageMagick plugin:
<%= image_tag rails_model.file.thumb('100x100#', format: 'png', frame: 0).url %>
So long as Ghostscript is installed, ImageMagick/Dragonfly will honour the format / frame (i.e. page of the PDF) settings. If file is an image rather than a PDF, it will be converted to a PNG, and the frame number ignored (unless it’s a GIF).
Try this
def to_pdf_thumbnail(temp_object)
ret = ''
tempfile = new_tempfile('png')
system("convert",tmp_object.path[0],tmpfile.path)
tempfile.open {|f| ret = f.read }
ret
end
The problem is you are likely handing convert ONE argument not two
Doesn't convert rely on the extension to determine the type? Are you sure the tempfiles have the proper extensions?
I am creating a Rails app which is hosted on Heroku and that allows the user to generate animated GIFs on the fly based on an original JPG that's hosted somewhere in the web (think of it as a crop-resize app). I tried Paperclip but, AFAIK, it does not handle dynamically-generated files. I am using the aws-sdk gem and this is a code snippet of my controller:
im = Magick::Image.read(#animation.url).first
fr1 = im.crop(#animation.x1,#animation.y1,#animation.width,#animation.height,true)
str1 = fr1.to_blob
fr2 = im.crop(#animation.x2,#animation.y2,#animation.width,#animation.height,true)
str2 = fr2.to_blob
list = Magick::ImageList.new
list.from_blob(str1)
list.from_blob(str2)
list.delay = #animation.delay
list.iterations = 0
That is for the basic creation of a two-frame animation. RMagick can generate a GIF in my development computer with these lines:
list.write("#{Rails.public_path}/images/" + #animation.filename)
I tried uploading the list structure to S3:
# upload to Amazon S3
s3 = AWS::S3.new
bucket = s3.buckets['mybucket']
obj = bucket.objects[#animation.filename]
obj.write(:single_request => true, :content_type => 'image/gif', :data => list)
But I don't have a size method in RMagick::ImageList that I can use to specify that. I tried "precompiling" the GIF into another RMagick::Image:
anim = Magick::Image.new(#animation.width, #animation.height)
anim.format = "GIF"
list.write(anim)
But Rails crashes with a segmentation fault:
/path/to/my_controller.rb:103: [BUG] Segmentation fault ruby 1.8.7 (2010-01-10 patchlevel 249) [universal-darwin11.0]
Abort trap: 6
Line 103 corresponds to list.write(anim).
So right now I have no idea how to do this and would appreciate any help I receive.
As per #mga's request in his answer to his original question...
a non-filesystem based approach is pretty simple
rm_image = Magick::Image.from_blob(params[:image][:datafile].read)[0]
# [0] because from_blob returns an array
# the blob, presumably, can have multiple images data in it
a_thumbnail = rm_image.resize_to_fit(150, 150)
# just as an example of doing *something* with it before writing
s3_bucket.objects['my_thumbnail.jpg'].write(a_thumbnail.to_blob, {:acl=>:public_read})
Voila! reading an uploaded file, manipulating it with RMagick, and writing it to s3 without ever touching the filesystem.
Since this project is hosted in Heroku I cannot use the filesystem so that is why I was trying to do everything via code. I found that Heroku does have a temporary-writable folder: http://devcenter.heroku.com/articles/read-only-filesystem
This works just fine in my case since I don't need the file after this request.
The resulting code:
im = Magick::Image.read(#animation.url).first
fr1 = im.crop(#animation.x1,#animation.y1,#animation.width,#animation.height,true)
fr2 = im.crop(#animation.x2,#animation.y2,#animation.width,#animation.height,true)
list = Magick::ImageList.new
list << fr1
list << fr2
list.delay = #animation.delay
list.iterations = 0
# gotta packet the file
list.write("#{Rails.root}/tmp/#{#animation.filename}.gif")
# upload to Amazon S3
s3 = AWS::S3.new
bucket = s3.buckets['mybucket']
obj = bucket.objects[#animation.filename]
obj.write(:file => "#{Rails.root}/tmp/#{#animation.filename}.gif")
It would be interesting to know if a non-filesystem-writing solution is possible.
I am updating this answer for AWS SDK Version 2 which should be:
rm_image = Magick::Image.from_blob(params[:image][:datafile].read)[0]
# [0] because from_blob returns an array
# the blob, presumably, can have multiple images data in it
a_thumbnail = rm_image.resize_to_fit(150, 150)
# just as an example of doing *something* with it before writing
s3 = Aws::S3::Resource.new
bucket = s3.bucket('mybucket')
obj = bucket.object('filename')
obj.put(body: background.to_blob)
I think there's a few things going on here. First, the documentation for RMagick is sub-par, and its easy to get side-tracked. The code you're using to generate the gif can be a little simpler. I cooked up a very contrived example here:
#!/usr/bin/env ruby
require 'rubygems'
require 'RMagick'
# read in source file
im = Magick::Image.read('foo.jpg').first
# make two slightly different frames
fr1 = im.crop(0, 100, 300, 300, true)
fr2 = im.crop(0, 200, 300, 300, true)
# create an ImageList
list = Magick::ImageList.new
# add our images to it
list << fr1
list << fr2
# set some basic values
list.delay = 100
list.iterations = 0
# write out an animated gif to the filesystem
list.write("foo.gif")
This code works -- it reads in a jpg I have locally, and writes out a 2-frame animation. Obviously I've hardcoded some values here, but there's no reason this shouldn't work for you, although I am running ruby 1.9.2 and probably a different version of RMagick, but this is basic code.
The second issue is totally unrelated -- is it possible to upload an image generated in IM to S3 without actually hitting the filesystem? Basically, will this ever work:
obj.write(:single_request => true, :content_type => 'image/gif', :data => list)
I'm not sure if it is or not. I experimented with calling list.to_blob, but it only outputs the first frame, and it's as a JPG, although I didn't spend much time on it. You might be able to fool list.write into outputting somewhere, but rather than going down that road, I would personally just output the file unless that is impossible for some reason.