Sending a Newsletter in HTML with images: huge filesize.
I'm trying to send a Newsletter which also contains images. The Newsletter is composed in Dreamweaver CS-6, making sure that the links to images refer to the images on my website. I copy the source-code, open TB, select Insert >> HTML and paste it and the e-mail displays the Newsletter correctly. However when I save the result the size of this mail is huge: some 500 kB, whereas the size of the source-code is less than 10 kB. Investigating the reason for this I found that TB has changed the links to my images from "http:\\www.website-adres\etc" into "mailbox:\\\mailbox-location\etc". Not only that, it also adds bitmaps of all my images at the end of the message. No wonder these mails become huge..... Questions: 1. Why is TB operating in this curious way? 2. Is there any other way in TB to do this correctly? And if not is there any other program you can recommend?
Note: I discovered that after importing the HTML code it is possible to manually correct the image-location: Format >> Image properties. After doing that the size of the message shinks from 500 kB to a mere 9 kB and still displays perfectly....
Alle antwurden (3)
1. It is not a curious way, it is ensuring the recipient sees the mail as the sender sees it.
Dreamweaver does not include the appropriate tag to stop the process of sanitizing the location of images. That is probably because it is a web page development tool and not a mail program.
Images require a moz-do-not-send tag Despite the name appearing as it does it is an official mail tag, not something Mozilla just dreamed up
2. Your inserting a file that may or may not be compatible. Not all HTML is supported in email. Thunderbird supports perhaps less that others as the HTML of mail is sanitized to make it "safe"
3. Are the images cropped? I am not sure just what occurs, but using images of more than about 120DPI is a waste as monitors do not display much more than that. The exception being the apple retina displays which go out to around 300. Windows defaults to 96. Other programs also will display the cropped version of an image, but not change the file. so the whole original version of he file is used and cropped each time it is displayed.
Clearly: this is not a Dreamweaver issue, because Dreamweaver is not a mail program as you correctly point out. Nor is image-size (1200DPI) an issue here.
Apparently I didn't make my question clear. What I'm referring to is the way the location of images in Newsletters are handled by TB. Let me clarify the issue with an example:
When HTML code (from Dreamweaver or any other HTML editor) is inserted into TB, the program modifies the source-code as follows:
img src="http://www.website/folder/image-1.jpg" height="110" width="700" alt="image-1" /
into:
img src="mailbox:///C:/mailboxlocation_on_local_harddisk?number=0&part=1.2&filename=image-1.jpg" height="110" width="700" alt="image-1" /
and includes a bitmap of every image in the e-mail.
Doing it that way results in huge e-mails.
What I am suggesting (proposing if you like) is that when inserting HTML into TB, it should (as default) leave the source-code intact and only add a 'moz-do-not-send tag' as follows:
img moz-do-not-send="true" src="http://www.website/folder/image-1.jpg" height="110" width="700" alt="image-1" /
and NOT include any bitmaps.
The resulting Newsletter shows up EXACTLY identical, but its size is only a few kB instead of hundreds of kB (or even MB) because bitmaps of images are no longer needed. As you mentioned the 'moz-do-not-send tag' is supported by TB, so why not use it?
Actually most Newsletters I receive from commercial parties all use a similar method!
I hope I've made my point clear and hope you will take my suggestion in consideration.
Your mobile recipient is going to be paying for that bandwidth (the Megabytes) to view your mail. Personally I think anything that dissuades people from including megabytes of images with an email is a good idea. You are now aware that your mail is huge and imposing an impost on the recipient.
If you want to institute a change Bugzilla is the place to file your enhancement request. https://bugzilla.mozilla.org/ a developer will be seen here occasionally, usually responding to a change they have made not looking for bugs or enhancement requests. They expect those in Bugzilla.