I use control named WebEngine (javafx) to show mail content downloaded by javamail. It's fine when the content is plain text or html with image src=http link, but when mail has embedded images (has content id in src) control dont show this images (of cource because has no idea where is it). What is the best control to show email? How to do it, when image storing in the memory. Maybe load mail in WebEngine is not a good idea...
You need a URLStreamHandler that handles the "cid" URL protocol and supplies the data from the appropriate part of the MIME message. I believe you need to configure the URLStreamHandler by creating a URLStreamHandlerFactory and calling the URL.setURLStreamHandlerFactory method. The trick, as I remember, is that there's no way to get the default URLStreamHandlerFactory so that your version can delegate to the default version for all the other URL protocols.
Alternatively, you can save all the attachments to disk and then process the html content before it's displayed to convert all cid: references into file: references.
My guess is that WebEngine isn't decoding and displaying multipart mime encoded messages such as what you are trying to process in your incoming mail. If I recall correctly some browsers like IE didn't handle multipart mime encoded messages either (and maybe still don't).
What you can do is decode the multipart message yourself using something like Mime4J and then display the decoded content parts in controls (or external apps of necessary) based on the decoded mimetype you get from the multipart message.
WebView will be able to display a bunch of mime types like text/html,
text/plain, image/jpeg, etc.
pdf can be displayed with JPedalFX PDF Viewer.
text/plain could be rendered by Label.
the various image/* mime types could be rendered by ImageView.
word docs and other formats not natively supported by any JavaFX controls could be written to a file and launched via HostServices.showDocument or DeskTop.open.
Related
I am trying to write a Java program where I need to send an image to Gmail. I am sending the image as an embedded object.
<img src="data:image/jpg;base64,iVBORw0KGgoAAAANSUhEUgAAACcAAAAsCAYAAADmZKH2AAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAABISURBVFhH7c4hAQAgEAAxEhGGZN8YOkwhTsxvnT33V+VUOVVOlVPlVDlVTpVT5VQ5VU6VU+VUOVVOlVPlVDlVTpVT5dTHubkPuMrNUFKjQWUAAAAASUVORK5CYII=">
Other mail service providers are showing it fine, but Gmail specifically is removing it, so it is not visible in the message.
How can I make it visible in Gmail as well as the other mail service providers?
Place the image in a publicly accessible server and give the url for src attribute instead of dataUrl.
It is not possible in Gmail, outlook etc. They ignore base64 images.
For further information follow the link at below.
https://www.campaignmonitor.com/blog/email-marketing/2013/02/embedded-images-in-html-email/
There is an alternative way for doing this. Embed images in the email using the cid method. (Basically including the image as an attachment, and then embedding it).
https://www.campaignmonitor.com/blog/how-to/2008/08/embedding-images-revisited/
Is there a posability in Vaadin 7 or in Java generally, to check if a browser has an embedded pdfreader or not?
I need to know that because it depends on that how i open the pdf.
There is unfortunately no way to consistently check if the browser supports viewing PDF files or not. I would recommend using something like PDF.JS (https://github.com/mozilla/pdf.js) or FlexPaper (http://flexpaper.devaldi.com/products.jsp) on your web site to display your documents to make sure your visitors can see your documents
Both those options are available as open source
In a web application, Java (and per se, Vaadin) runs on server side, so you cannot know which technology is installed on client, in this case, the browser. Just fire your file download with the application/pdf mime header and let the client do it's work. If you want to fire it as a general file download, use application/octet-stream mime header instead.
Here's a more generic q/a on this topic: How to determine if the user's browser can view PDF files
I need to send to the client a byte[] with a pdf data from my tomcat server.
I'm using this:
response.setContentType("application/pdf");
response.setHeader("Content-Disposition:","inline; filename=test.pdf");
But (at least) with firefox I get a file download instead of inline display.
The only way to show pdf data inline is to remove the Content-Disposition header record however, if I do so I cannot set the filename, the pdf name is get from the last folder of url.
You seems to be setting the right headers. But rendering of pdf or another such formats depends on the browser capabilities as well. I mean browser need to have a pdf plugin installed in order to render a pdf when it sees the same in the contentType header field. So make sure you install a pdf plugin for your firefox and try to test after that. You can download firefox pdf plugin from here:
https://addons.mozilla.org/en-US/firefox/addon/pdf-download/
Does anyone have an example of how to send both binary (image) and text-based data in a single servlet response? An example is returning an image and image-map all generated on the server. I was also not able to find a mixed-mode mime type to use to be able to perform this operation.
Thoughts?
Browser support for multipart responses is still pretty dicey (read here). But if you are planning to parse the response on the client side yourself there are some pretty good examples out there. The mime-type you are looking for is multipart/mixed.
You can use Data URI to embed binary objects into generated HTML.
E.g.
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4/8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==" alt="Red dot">
See also: https://serverfault.com/questions/241218/why-do-http-servers-not-send-a-single-file-back-when-possible#241224
This is not how HTTP and HTML work. A first request is made to load HTML code. This HTML code contains <img src="..."/> tags, which point to the URL of the image. A second request is then made by the browser to load the image. You can't download the HTML and the image in a single request.
Many WAP browsers supports multi-part responses, but I don't think "regular" browsers do.
Also see Browser support of multipart responses
I am trying to send an email with Java, I am using apache commons email library.
I cannot achieve to send an email with a body as HTML and an attachment as PDF (or any file type)
If I use EmailAttachment() and add it to an HtmlEmail object, my mail looks like with two attachment. First one is for HTML, second is for PDF.
Is there any way to do that?
Thank you very much!
It sounds like relatively normal behaviour for a message that's being sent as both text and HTML, and/or a mail client (at the receiving end) that prefers text emails. I suspect that this is due to the behaviour of the client, which you won't be able to change (but on the plus side all HTML emails would appear like this).
The thing is, an HTML email (with a textual component) really is a multipart message, with the HTML content as one of the "extra" parts. All you're actually sending in the email from the server side is a bunch of text, and it's up to the receiving mail client to decide how to display it. In that respect, it is not wrong for the client to display your HTML as an attachment - just like it is not wrong for a smart client to infer that the HTML isn't a "real" attachment and activate some kind of toggle between text and HTML (rather than displaying it as an attachment).
If you're convinced that the client would normally treat HTML in this smart way, then:
You'll have to mention which client you're using to check, because this isn't really an issue with the sending per se; and
You might want to take a look at the raw source of email that "works", and your email that doesn't, in order to determine what the critical differences are that trigger the different rendering modes. Depending on the client software, this could be just about anything - but I'd pay particular attention to part MIME types and charsets.
I tried apache commons mail v1.2 instead of 1.1.
It works!?
Andrej, by the way many thanks for your kindly help.