I am working on developing an app that will generate a digital card from the user. At the moment I am working on the rmagick code in a .rb file. Then just running it from the command line untill I figure it all out. I am having a few problems.
The source image I can't figure out the path to it. the only way I can get it to work is if I place it in the controllers directory with the cards.rb file. I want to have it in assets/cards/
Saving the file, same issue as above. I want to save it in assets/cards/#card_id.png
I'm trying to use a custom font in the assets/fonts/ dir I've tried self.font = “#{RAILS_ROOT}/assets/fonts/dreamorphansbd.ttf” but the code will not run. If I remove the quotes it runs but the font is not correct.
The last thing and I have yet to try it is adding the caption as the card.event from the db. I'm think it will along those line but not sure.
require 'RMagick'
include Magick
blank = Magick::Image.read("Blank-Card.png").first
text = Image.read("caption:Some big long text would go here.") do
self.gravity = CenterGravity
self.font = #{RAILS_ROOT}/app/assets/fonts/dreamorphansbd.ttf
self.background_color= "Transparent"
self.size = "638x"
self.pointsize = 40
end
blank.composite!(text[0], CenterGravity, Magick::OverCompositeOp)
blank.write("card.png")
try: Magick::Image.read(Rails.root.join('image', 'Blank-Card.png')).first
try: blank.write(Rails.root.join('image', 'card.png'))
With: Magick.fonts, you will see all available fonts
try: Image.read("caption:#{obj_active_record.your_attribute}")
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")%>
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
We have a Ruby on Rails application that needs to convert a PDF into a PNG with a transparent background. We're using rmagick 2.13.1. On our development machines the following code works exactly how we want it.
pages = Magick::Image.from_blob(book.to_pdf.render){ self.density = 300 }
page = pages[0]
image_file = Tempfile.new(['preview_image', '.png'])
image_file.binmode
image_file.write( page.to_blob { |opt| opt.format = "PNG" } )
We thens save the image_file and all is peachy. When we deployed to a review server on Heroku, though, the generated image has a white background. It turns out that Heroku's cedar stack is using imagemagick ImageMagick 6.5.7-8 2010-12-02 where we're using ImageMagick 6.7.5-7 2012-05-08 on our development machines.
I've scoured the net for older posts that might apply to the older version to try and figure out how to generate the transparent PNGs. It's surely supported, but, so far I haven't been able to figure out the right combination of settings.
To verify that it wasn't the PDF generation that was the problem, I downloaded a PDF generated on Heroku and successfully converted it using the above code (slightly modified to read the file in instead of generate it) to a transparent PNG.
Some of the things I've tried in various combinations are:
page.matte = true
page.format = "PNG32"
page.background_color = "none"
page.transparent_color = "white"
page.transparent("white")
So, the question is "is this possible?". If so, which settings do I need to set on the image before writing it out?
I'm also investigating including a compiled binary of a more up to date Imagemagick on Heroku.
Any help is appreciated.
This should no longer be an issue, as Heroku has ImageMagick versions 6.7-6.9 on their various stacks.
I am getting the width and height of an image stored on Amazon S3 using Paperclip as follows:
Paperclip::Geometry.from_file(user.avatar.url)
It has been working fine, but it is erroring on an image that has a space in the filename:
Paperclip::NotIdentifiedByImageMagickError: my_amazon_s3_path_is_here/Martian landslide.jpg?1294675113 is not recognized by the 'identify' command.
The image loads okay when you go to the URL in a browser. What can I do to fix this?
EDIT: Forgot to mention that images without a space in their filename work fine, so it's not an issue with Imagemagick/Paperclip setup.
Do you need to URL Encode the url's? eg replace spaces with %20
Usually when you see:
not recognized by the 'identify' command.
It means ImageMagick isn't set up correctly. Are other images working correctly?
Have you tweaked this setting yet?
Paperclip.options[:command_path] = "/opt/local/bin"
It needs to point to the location where identify is installed. From the command line, you can determine this with:
which identify
I have the same problem and file 'Снимок экрана от 2013-02-28 14:36:49.png' returns the same error. But it works correctly on heroku. So I think the problem is in ImageMagick