I have a template that have some images one from file system and other are from project images folder.
Images in the template that are coming from the images folder of my grails application is shown perfectly in the doc file. I am using below code to render these images:
<img src="${g.resource(dir: 'images', file: 'phone-1.gif', absolute: true)}"/>
But I have an image that is coming from file system(/opt/profileImages folder). Using below code to render this image in template:
View:
<g:img uri="${g.createLink(controller: 'personalDetail', action: 'showUserProfileImage', absolute: true)}"/>
Controller:
def showUserProfileImage() {
User user = springSecurityService.currentUser as User
String profilePicturePath = "${grailsApplication.config.profilePictureDirectoryPath}/${user?.profilePicture?.fileName}"
File file = new File(profilePicturePath)
def img = file.bytes
response.contentType = user?.profilePicture?.mimeType
response.outputStream << img
response.outputStream.flush()
}
This is working fine, showing profile image in the browser as well as in the pdf that I downloaded using grails rendering plugin.
But problem is .doc format file. When I download the template in doc format then image is not shown.
Screenshot:
Can someone please tell me where I am wrong?
Or is there any other way to do this?
Here you are trying to access image src out of your application context.
So your source should look like this.
<g:img uri="${profilePocturePath}" width="93px" height="100px"/>
Refer this
<mvc:resources mapping="/images/**" location="file:/absolute/path/to/image/dir"/>
Kanwal Nain Singh solution works only if server is running in local but if I download template in doc format from remote then again image is missing. The problem is doc search image in local machine(/opt/profileImages folder).
Following code is working perfectly:
Action:
def showUserProfileImage() {
String profilePicturePath = "${grailsApplication.config.profilePictureDirectoryPath}/${params.id}"
File file = new File(profilePicturePath)
response.contentType = URLConnection.guessContentTypeFromName(file.getName())
response.outputStream << file.bytes
response.outputStream.flush()
}
Tag:
<g:img uri="${grailsApplication.config.grails.serverURL}/user/showUserProfileImage/${userImageName}"/>
Related
I am creating a PDF file using Wicked:
pdf = WickedPdf.new.pdf_from_string('<h1>Hello There!</h1>')
I assume that this creates a temporary file somewhere. How can I get the path to this temp file?
you can do this when you are creating the pdf only u can pass in the option of your desired temp path
pdf = WickedPdf.new.pdf_from_string('<h1>Hello There!</h1>', {temp_path: "your path here")
Refer this link for more inputs this contains the function that you are using and the inputs that can be passed
Please refer to example of https://github.com/mileszs/wicked_pdf#super-advanced-usage.
The official example use File
pdf = render_to_string pdf: "some_file_name", template: "templates/pdf", encoding: "UTF-8"
# then save to a file
save_path = Rails.root.join('pdfs','filename.pdf')
File.open(save_path, 'wb') do |file|
file << pdf
end
You may use tempfile to do it as
pdf_string = WickedPdf.new.pdf_from_string(...)
overlay = Tempfile.new('overlay')
overlay.binmode
overlay.write(pdf_string)
overlay.close
overlay.path # to get path
Checking the source of WickedPDF it has a TempFile
The temporary file should be created in the temporary directory as defined in options, or in Dir.tmpdir.
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 am using spreadsheet gem to generate .xls file. After writing it to a file, I am trying to send to client browser for download.
Below is the code in rails
workbook = Spreadsheet::Workbook.new
# Constructed the data
file = "/path/to/file/sheet.xls"
workbook.write file
send_file file
This file when opened contains expected data in ideal format.
Below is the code in js:
CustomRestService.custom_post("report",{report_data: angular.toJson($scope.report_data)},"download_xls",{}).then (data)->
if data
hiddenElement = document.createElement('a')
angular.element(document.body).append(hiddenElement)
hiddenElement.href = 'data:attachment/xls,' + encodeURI(data)
hiddenElement.target = '_blank'
hiddenElement.download = "report.xls"
hiddenElement.click()
hiddenElement.remove()
But the file getting downloaded in browser contains junk data. I tried multiple solutions like below:
Using send_data, instead of send_file
Generated xls data and wrote to StringIO object to directly download
Constructed Blob object in js, with type as "application/vnd.ms-excel" and trying to download it.
All attempts failed, as I am missing something. All suggestions are welcome.
filename = "/path/to/file/sheet.xls"
tempfile = Tempfile.new(filename)
workbook = Spreadsheet::Workbook.new
...
workbook.write(tempfile.path)
send_file tempfile.path, :filename => filename
Trying to fix an old .asp site to work on an ipad. One of the features is the users ability to download their search results into an excel worksheet. The code uses:
Response.ContentType = "application/vnd.ms-excel"
Response.AddHeader "Content-Disposition", "attachment;filename=results.xls"
Response.CharSet = "iso-8859-1"
When viewing the site on the ipad, when the link is click for the page with the code above it does nothing, just spins. Is it the fact that I am trying to export the data as excel, I have read in some posts how it is the encoding! Should I convert the code to export the results page as a csv file and then allow the user to open it in anything they want/have available? What's the best way to do it to hit the most devices...
Thanks
In the past i'd a same scenario so what i did:
FILE: DOWNLOAD.ASP
<%
' get the file to download
myFile = request.querystring("File")
myFullPath = "c:\name_folder\" & myFile ' example of full path and filename
' set headers
Response.ContentType = "application/octet-stream"
Response.AddHeader "Content-Disposition", "attachment; filename=" & myFile
' send the file using the stream as
Set adoStream = CreateObject("ADODB.Stream")
adoStream.Open()
adoStream.Type = 1
adoStream.LoadFromFile(myFullPath)
Response.BinaryWrite adoStream.Read()
adoStream.Close
Set adoStream = Nothing
%>
FILE: HTML
Download Excel file
This example is full working with Ipad using the native browser Safari.
The file Result.xls is downloaded and loaded in the Viewer whitout the capability to be edit.
My iPad users use the App QuickOffice to let the file be saved in a virtual folder, rename the file, delete, ... but they cant edit the file, that App is just for manage the files and isnt required for download the file.
If your user need also edit the XLS file on the iPad i suggest to use (for example) the Google App Document, it let the user to edit and manage the file directly in the browser.
Hope it help
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?