Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.comp.software.thunderbird > #16095 > unrolled thread

Pasting photos in html emails

Back to article view | Back to alt.comp.software.thunderbird

Contents

  Pasting photos in html emails "Carlos E.R." <robin_listas@es.invalid> - 2025-03-20 22:00 +0100
    Re: Pasting photos in html emails "Alan K." <alan@invalid.com> - 2025-03-20 17:51 -0400
      Re: Pasting photos in html emails VanguardLH <V@nguard.LH> - 2025-03-20 17:36 -0500
        Re: Pasting photos in html emails bad sector <forgetski@_INVALID.net> - 2025-03-21 06:15 -0400
          Re: Pasting photos in html emails VanguardLH <V@nguard.LH> - 2025-03-21 18:52 -0500
            Re: Pasting photos in html emails bad sector <forgetski@_INVALID.net> - 2025-03-22 22:22 -0400
        Re: Pasting photos in html emails "Carlos E.R." <robin_listas@es.invalid> - 2025-03-21 12:39 +0100
          Re: Pasting photos in html emails VanguardLH <V@nguard.LH> - 2025-03-21 18:57 -0500
            Re: Pasting photos in html emails "Carlos E.R." <robin_listas@es.invalid> - 2025-03-22 15:32 +0100
        Re: Pasting photos in html emails Mark Lloyd <not.email@all.invalid> - 2025-03-21 17:08 +0000
          Re: Pasting photos in html emails "Carlos E.R." <robin_listas@es.invalid> - 2025-03-22 15:34 +0100
        Re: Pasting photos in html emails NFN Smith <worldoff9908@gmail.com> - 2025-03-21 17:05 -0700
    Re: Pasting photos in html emails Andy Burns <usenet@andyburns.uk> - 2025-03-21 06:40 +0000
      Re: Pasting photos in html emails "Carlos E.R." <robin_listas@es.invalid> - 2025-03-21 12:41 +0100
        Re: Pasting photos in html emails Andy Burns <usenet@andyburns.uk> - 2025-03-21 11:48 +0000
          Re: Pasting photos in html emails "Carlos E.R." <robin_listas@es.invalid> - 2025-03-21 13:59 +0100
        Re: Pasting photos in html emails Retirednoguilt <HapilyRetired@fakeaddress.com> - 2025-03-21 09:27 -0400
          Re: Pasting photos in html emails "Carlos E.R." <robin_listas@es.invalid> - 2025-03-21 15:07 +0100
            Re: Pasting photos in html emails Char Jackson <none@none.invalid> - 2025-03-21 11:31 -0500
              Re: Pasting photos in html emails Mark Lloyd <not.email@all.invalid> - 2025-03-21 17:17 +0000
                Re: Pasting photos in html emails Char Jackson <none@none.invalid> - 2025-03-21 15:59 -0500
                  Re: Pasting photos in html emails Mark Lloyd <not.email@all.invalid> - 2025-03-22 16:43 +0000
                    Re: Pasting photos in html emails Char Jackson <none@none.invalid> - 2025-03-22 16:26 -0500
              Re: Pasting photos in html emails "Carlos E.R." <robin_listas@es.invalid> - 2025-03-22 15:35 +0100
                Re: Pasting photos in html emails Char Jackson <none@none.invalid> - 2025-03-22 16:40 -0500
                  Re: Pasting photos in html emails Mark Lloyd <not.email@all.invalid> - 2025-03-23 19:50 +0000
                    Re: Pasting photos in html emails Char Jackson <none@none.invalid> - 2025-03-24 01:36 -0500
                      Re: Pasting photos in html emails "Carlos E.R." <robin_listas@es.invalid> - 2025-03-24 11:50 +0100
                      Re: Pasting photos in html emails Mark Lloyd <not.email@all.invalid> - 2025-03-24 18:32 +0000
          Re: Pasting photos in html emails Newyana2 <newyana@invalid.nospam> - 2025-03-21 11:33 -0400
            Re: Pasting photos in html emails Mark Lloyd <not.email@all.invalid> - 2025-03-21 17:24 +0000
              Re: Pasting photos in html emails Mark Lloyd <not.email@all.invalid> - 2025-03-22 16:47 +0000
                Re: Pasting photos in html emails Newyana2 <newyana@invalid.nospam> - 2025-03-22 13:31 -0400
                Re: Pasting photos in html emails Char Jackson <none@none.invalid> - 2025-03-22 16:10 -0500
                  Re: Pasting photos in html emails "Carlos E.R." <robin_listas@es.invalid> - 2025-03-22 23:50 +0100
    Re: Pasting photos in html emails Newyana2 <newyana@invalid.nospam> - 2025-03-21 08:17 -0400
      Re: Pasting photos in html emails "Carlos E.R." <robin_listas@es.invalid> - 2025-03-21 15:12 +0100
        Re: Pasting photos in html emails Newyana2 <newyana@invalid.nospam> - 2025-03-21 11:30 -0400
          Re: Pasting photos in html emails "Carlos E.R." <robin_listas@es.invalid> - 2025-03-22 15:40 +0100
    Re: Pasting photos in html emails "Carlos E. R." <robin_listas@es.invalid> - 2025-05-27 14:32 +0200
      Re: Pasting photos in html emails knuttle <keith_nuttle@yahoo.com> - 2025-05-27 09:34 -0400
        Re: Pasting photos in html emails "Carlos E. R." <robin_listas@es.invalid> - 2025-05-27 16:07 +0200

Page 1 of 3  [1] 2 3  Next page →

#16095 — Pasting photos in html emails

Hi,

Sometimes I send html emails to friends with summaries of some news for 
chatting on them, and I add photos. Normally, the photos are links, so 
the email weight is small.

Take this article, for instance (using firefox): 
<https://ubuntuhandbook.org/index.php/2025/03/photogimp-updated-to-help-switching-from-photoshtop-to-gimp-3-0/>

I click on the first photo, then right click on the menu, and select 
"Copy Image". Then on the email, I simply do ctrl-v and paste the photo.

But since recently, this has a twist. The email weights one megabyte. On 
TB, I double click on the image, and Image location contains 
"data:image/png;base64,iVBOR…8EtAFbFgqOrgAAAABJRU5ErkJggg==". If I save 
the email, it has 1 megabyte.

The remedy is to delete this line, go to firefox, right click on the 
image, select "copy image link", and on TB paste that link in the "Image 
Location" field of the photo 
(<https://ubuntuhandbook.org/wp-content/uploads/2025/03/gimp3-patched.webp>). 
Now when saving the email it weights just 3.5 KB.

This was not happening some time ago, I always got the photo links. Now 
I have to be careful when sending photos that I don't get the heavy version.

Why, what is going on?

-- 
Cheers, Carlos.

[toc] | [next] | [standalone]

#16096

On 3/20/25 05:00 PM, Carlos E.R. wrote:
> Hi,
> 
> Sometimes I send html emails to friends with summaries of some news for chatting on them, 
> and I add photos. Normally, the photos are links, so the email weight is small.
> 
> Take this article, for instance (using firefox): <https://ubuntuhandbook.org/ 
> index.php/2025/03/photogimp-updated-to-help-switching-from-photoshtop-to-gimp-3-0/>
> 
> I click on the first photo, then right click on the menu, and select "Copy Image". Then on 
> the email, I simply do ctrl-v and paste the photo.
> 
> But since recently, this has a twist. The email weights one megabyte. On TB, I double 
> click on the image, and Image location contains "data:image/png;base64,iVBOR… 
> 8EtAFbFgqOrgAAAABJRU5ErkJggg==". If I save the email, it has 1 megabyte.
> 
> The remedy is to delete this line, go to firefox, right click on the image, select "copy 
> image link", and on TB paste that link in the "Image Location" field of the photo 
> (<https://ubuntuhandbook.org/wp-content/uploads/2025/03/gimp3-patched.webp>). Now when 
> saving the email it weights just 3.5 KB.
> 
> This was not happening some time ago, I always got the photo links. Now I have to be 
> careful when sending photos that I don't get the heavy version.
> 
> Why, what is going on?
> 
Seems firefox assumes when you say copy image, it means just that.  The image is copied to 
the clipboard.   If you went to Word or Libreoffice writer or Gimp or Photoshop (etc) and 
pasted, you'd get your image from the clipboard.

When you paste into email, email programs do not handle photos literally.  They translate 
them into base64 code.  Base64 has the each 8bit byte of the image translated to ascii 
characters that can be easily sent via email programs.  The problem as you have noticed is 
the overhead is huge.

One workaround, other than your first find, would be to 'save image as', then attach it to 
your email.  This would work if you were writing to say: "See my new car" and you attached 
the image.   Not so well though if  you wanted to disperse images all though the email.  I 
think your plan is the better, as long as the links don't rot.
-- 
Linux Mint 22.1, Cinnamon 6.4.8,  Kernel 6.8.0-55-generic
Thunderbird 128.8.0esr, Mozilla Firefox 136.0.1
     Alan K.

[toc] | [prev] | [next] | [standalone]

#16097

"Alan K." <alan@invalid.com> wrote:

> When you paste into email, email programs do not handle photos
> literally.  They translate them into base64 code.  Base64 has the
> each 8bit byte of the image translated to ascii characters that can
> be easily sent via email programs.  The problem as you have noticed
> is the overhead is huge.

ALL e-mail is sent as text characters.  ALL.  Not some, not most, but
ALL e-mail is text.  No binary content is allowed at all.  Attachments
in e-mails are not the original file.  Attachments get encoded
(transformed) into a MIME part as a long text string, and that encoding
bloats the original content by 133%, or much more.  Look at the raw
source of any e-mail with an attachment, like a binary (e.g., image).
You won't find the binary content anywhere inside the e-mail.  You will
find MIME parts (content-disposition=attach or inline are hints to the
e-mail client how to present the attachment) in the body of the message
where the binary content got encoded into a long text string.  E-mail
was never designed to be a file transfer venue despite users trying to
use it that way.  

MIME got added to allow the addition of non-ASCII text in messages
(i.e., language support), and to allow e-mail to carry non-text content
as attachments.

https://datatracker.ietf.org/doc/html/rfc2045

> One workaround, other than your first find, would be to 'save image
> as', then attach it to your email.  This would work if you were
> writing to say: "See my new car" and you attached the image.   Not so
> well though if  you wanted to disperse images all though the email. 
> I think your plan is the better, as long as the links don't rot.

Sending just the URL of an image is polite.  The recipient gets to
decide whether to see the online image or not rather than wasting the
bandwidth and disk space (in both sender's and recipient's mailboxes on
their servers and in the clients) to get an e-mail with content they may
not want.  Including huge attachments could result in consuming a
recipient's mailbox to its max quota preventing receipt of further
e-mails until the recipient deletes the bloated e-mail.

However, copying the link to an image in a web page may not always work.
Some sites dislike direct links to their content, or the URL won't work
later in a dynamic web page (aka Javascripted).  When that happens, you
may still be able to save the image to a local file, upload to online
storage, and then give a URL to that location.  Using Javascript events,
a site can disable right-clicking on an image to prevent saving a local
copy.  Sites may try to block theft of their content.

[toc] | [prev] | [next] | [standalone]

#16099

On 3/20/25 18:36, VanguardLH wrote:
> "Alan K." <alan@invalid.com> wrote:
> 
>> When you paste into email, email programs do not handle photos
>> literally.  They translate them into base64 code.  Base64 has the
>> each 8bit byte of the image translated to ascii characters that can
>> be easily sent via email programs.  The problem as you have noticed
>> is the overhead is huge.
> 
> ALL e-mail is sent as text characters.  ALL.  Not some, not most, but
> ALL e-mail is text.  No binary content is allowed at all.  Attachments
> in e-mails are not the original file.  Attachments get encoded
> (transformed) into a MIME part as a long text string, and that encoding
> bloats the original content by 133%, or much more.  Look at the raw
> source of any e-mail with an attachment, like a binary (e.g., image).
> You won't find the binary content anywhere inside the e-mail.  You will
> find MIME parts (content-disposition=attach or inline are hints to the
> e-mail client how to present the attachment) in the body of the message
> where the binary content got encoded into a long text string.  E-mail
> was never designed to be a file transfer venue despite users trying to
> use it that way.
> 
> MIME got added to allow the addition of non-ASCII text in messages
> (i.e., language support), and to allow e-mail to carry non-text content
> as attachments.
> 
> https://datatracker.ietf.org/doc/html/rfc2045
> 
>> One workaround, other than your first find, would be to 'save image
>> as', then attach it to your email.  This would work if you were
>> writing to say: "See my new car" and you attached the image.   Not so
>> well though if  you wanted to disperse images all though the email.
>> I think your plan is the better, as long as the links don't rot.
> 
> Sending just the URL of an image is polite.  The recipient gets to
> decide whether to see the online image or not rather than wasting the
> bandwidth and disk space (in both sender's and recipient's mailboxes on
> their servers and in the clients) to get an e-mail with content they may
> not want.  Including huge attachments could result in consuming a
> recipient's mailbox to its max quota preventing receipt of further
> e-mails until the recipient deletes the bloated e-mail.
> 
> However, copying the link to an image in a web page may not always work.
> Some sites dislike direct links to their content, or the URL won't work
> later in a dynamic web page (aka Javascripted).  When that happens, you
> may still be able to save the image to a local file, upload to online
> storage, and then give a URL to that location.  Using Javascript events,
> a site can disable right-clicking on an image to prevent saving a local
> copy.  Sites may try to block theft of their content.


Hmmm, thanks, I had no idea. What happens to image quality, does the 
image remain bit-for-bit identical?

[toc] | [prev] | [next] | [standalone]

#16115

bad sector <forgetski@_INVALID.net> wrote:

> Hmmm, thanks, I had no idea. What happens to image quality, does the 
> image remain bit-for-bit identical?

Depends on the storage service to where you upload the photo.  I haven't
used Google Photos in a very long time, but I recall that the default
was to compress the image to a smaller file, so some resolution was
lost.  Those photos did not count against your storage quote.  However,
if you uploaded without compression, those photos counted against your
storage quota.

https://support.google.com/photos/answer/6220791

You have to check upload handling at whatever online file storage
service you elect to use, and check if they have an override option
should they default to compression on upload/import.

16MP at Google Photos is pretty big for an image file.  Depends on far
your recipient needs to zoom into the image.  Since you are stea....,
um, borrowing images from web site, likely those are much lower
resolution hence far fewer pixels.  Even a photo at 2048x1638 only uses
3,354,624 pixels, not 16 million of them.

https://photographylife.com/why-16-megapixels-when-i-could-have-50

Web images are rarely super-high resolution.  1080x1080 (1 MP) are
typical, or much smaller.  If you copy an image you are viewing in a web
page, you're not getting super-high resolution, anyway.  You would have
to download the image file itself to see at what resolution the image
was originally saved.

https://www.youtube.com/watch?v=Dw3FPcpy3m0

That guy is talking about taking pics using cameras, and saving to a
file to retain full resolution.  However, once a pic is shown as an
image at a web site, there has already been a huge reduction in pixels
or lots of compression.  The web site wants to deliver a decent pic, not
spend LOTS of superfluous bandwidth (that they have to pay for to handle
all that traffic) to deliver a super-high resolution image.

For example, look at an image of a motherboard.  I selected "Large" for
sizing in the Google Image search.  See:

https://pg.asrock.com/mb/photo/B760M%20PG%20LightningD4(L2).png

Alas, right-clicking on the image does not show properties, like image
sizing.  So, save the image to a local file.  Then open the .png file in
whatever image viewer you like, but one that gives properties on the
image, like size.  I used XnView Classic, and used Edit -> Properties to
look at the width and height in pixels: 1200 x 1000 -- barely over 1 MP.
I could zoom in, but the white silkscreen printing on most modules are
barely legible.  

Using advanced in Google Image search, I could up the image size from
Large to 15 MP.  Unfortunately that resulted in really bad images (lots
more blur) because the users weren't photographic experts, especially
with lack of focus outside the center point of the photo.  I did find:

which I downloaded (the file).  It was 8192x5464 (45 MP).  I could zoom
into that photo, but only in the center as the rest was out of focus.
However, you normally don't find images that large in pixels as
presented in a web page that you choose to copy.

[toc] | [prev] | [next] | [standalone]

#16129

On 3/21/25 19:52, VanguardLH wrote:
> bad sector <forgetski@_INVALID.net> wrote:
> 
>> Hmmm, thanks, I had no idea. What happens to image quality, does the
>> image remain bit-for-bit identical?
> 
> Depends on the storage service to where you upload the photo.  I haven't
> used Google Photos in a very long time, but I recall that the default
> was to compress the image to a smaller file, so some resolution was
> lost.  Those photos did not count against your storage quote.  However,
> if you uploaded without compression, those photos counted against your
> storage quota.
> 
> https://support.google.com/photos/answer/6220791
> 
> You have to check upload handling at whatever online file storage
> service you elect to use, and check if they have an override option
> should they default to compression on upload/import.
> 
> 16MP at Google Photos is pretty big for an image file.  Depends on far
> your recipient needs to zoom into the image.  Since you are stea....,
> um, borrowing images from web site, likely those are much lower
> resolution hence far fewer pixels.  Even a photo at 2048x1638 only uses
> 3,354,624 pixels, not 16 million of them.
> 
> https://photographylife.com/why-16-megapixels-when-i-could-have-50
> 
> Web images are rarely super-high resolution.  1080x1080 (1 MP) are
> typical, or much smaller.  If you copy an image you are viewing in a web
> page, you're not getting super-high resolution, anyway.  You would have
> to download the image file itself to see at what resolution the image
> was originally saved.
> 
> https://www.youtube.com/watch?v=Dw3FPcpy3m0
> 
> That guy is talking about taking pics using cameras, and saving to a
> file to retain full resolution.  However, once a pic is shown as an
> image at a web site, there has already been a huge reduction in pixels
> or lots of compression.  The web site wants to deliver a decent pic, not
> spend LOTS of superfluous bandwidth (that they have to pay for to handle
> all that traffic) to deliver a super-high resolution image.
> 
> For example, look at an image of a motherboard.  I selected "Large" for
> sizing in the Google Image search.  See:
> 
> https://pg.asrock.com/mb/photo/B760M%20PG%20LightningD4(L2).png
> 
> Alas, right-clicking on the image does not show properties, like image
> sizing.  So, save the image to a local file.  Then open the .png file in
> whatever image viewer you like, but one that gives properties on the
> image, like size.  I used XnView Classic, and used Edit -> Properties to
> look at the width and height in pixels: 1200 x 1000 -- barely over 1 MP.
> I could zoom in, but the white silkscreen printing on most modules are
> barely legible.
> 
> Using advanced in Google Image search, I could up the image size from
> Large to 15 MP.  Unfortunately that resulted in really bad images (lots
> more blur) because the users weren't photographic experts, especially
> with lack of focus outside the center point of the photo.  I did find:
> 
> which I downloaded (the file).  It was 8192x5464 (45 MP).  I could zoom
> into that photo, but only in the center as the rest was out of focus.
> However, you normally don't find images that large in pixels as
> presented in a web page that you choose to copy.

I was concerned mainly by sending images as email attachments back and 
forth, always presuming that what is received is exactly like the source 
image {maybe I misread the article}.

[toc] | [prev] | [next] | [standalone]

#16100

On 2025-03-20 23:36, VanguardLH wrote:
> "Alan K." <alan@invalid.com> wrote:
> 
>> When you paste into email, email programs do not handle photos
>> literally.  They translate them into base64 code.  Base64 has the
>> each 8bit byte of the image translated to ascii characters that can
>> be easily sent via email programs.  The problem as you have noticed
>> is the overhead is huge.
> 
> ALL e-mail is sent as text characters.  ALL.  Not some, not most, but
> ALL e-mail is text.  No binary content is allowed at all.  Attachments
> in e-mails are not the original file.  Attachments get encoded
> (transformed) into a MIME part as a long text string, and that encoding
> bloats the original content by 133%, or much more.  Look at the raw
> source of any e-mail with an attachment, like a binary (e.g., image).
> You won't find the binary content anywhere inside the e-mail.  You will
> find MIME parts (content-disposition=attach or inline are hints to the
> e-mail client how to present the attachment) in the body of the message
> where the binary content got encoded into a long text string.  E-mail
> was never designed to be a file transfer venue despite users trying to
> use it that way.

Yes. There are several methods of encoding them, but it is always text. 
I do this when I know the recipient wants to archive the photo, and I 
know they want them in email.

> 
> MIME got added to allow the addition of non-ASCII text in messages
> (i.e., language support), and to allow e-mail to carry non-text content
> as attachments.
> 
> https://datatracker.ietf.org/doc/html/rfc2045
> 
>> One workaround, other than your first find, would be to 'save image
>> as', then attach it to your email.  This would work if you were
>> writing to say: "See my new car" and you attached the image.   Not so
>> well though if  you wanted to disperse images all though the email.
>> I think your plan is the better, as long as the links don't rot.
> 
> Sending just the URL of an image is polite.  The recipient gets to
> decide whether to see the online image or not rather than wasting the
> bandwidth and disk space (in both sender's and recipient's mailboxes on
> their servers and in the clients) to get an e-mail with content they may
> not want.  Including huge attachments could result in consuming a
> recipient's mailbox to its max quota preventing receipt of further
> e-mails until the recipient deletes the bloated e-mail.

Exactly. And for years, my method has done just this. Only recently I 
noticed failures, and instead of the link I got the data.

> 
> However, copying the link to an image in a web page may not always work.
> Some sites dislike direct links to their content, or the URL won't work
> later in a dynamic web page (aka Javascripted).  

Right. But this I notice instantly, the photo does not appear in the 
email I am composing. When in doubt, I look at the draft folder.

> When that happens, you
> may still be able to save the image to a local file, upload to online
> storage, and then give a URL to that location.  Using Javascript events,
> a site can disable right-clicking on an image to prevent saving a local
> copy.  Sites may try to block theft of their content.

The easy way is to capture a screenshot of the photo and paste that. The 
email becomes heavier, so I use that sparely.

-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#16116

"Carlos E.R." <robin_listas@es.invalid> wrote:

> The easy way is to capture a screenshot of the photo and paste that. The 
> email becomes heavier, so I use that sparely.

How many pixels is the resolution of your monitor?  My monitor is set to
its native resolution of 2560 x 1440, or 3.6 MP.  However, the web site
is very likely presenting an image that is far smaller in pixels to
severely reduce the bandwidth they would need to expend to show their
images to the casual web surfer.

Could be downloading the image file would give you a much higher pixel
count.

[toc] | [prev] | [next] | [standalone]

#16118

On 2025-03-22 00:57, VanguardLH wrote:
> "Carlos E.R." <robin_listas@es.invalid> wrote:
> 
>> The easy way is to capture a screenshot of the photo and paste that. The
>> email becomes heavier, so I use that sparely.
> 
> How many pixels is the resolution of your monitor? 

1920*1080

> My monitor is set to
> its native resolution of 2560 x 1440, or 3.6 MP.  However, the web site
> is very likely presenting an image that is far smaller in pixels to
> severely reduce the bandwidth they would need to expend to show their
> images to the casual web surfer.
> 
> Could be downloading the image file would give you a much higher pixel
> count.

Yeah, but I do this when the download fails. Or the linking.


-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#16111

On Thu, 20 Mar 2025 17:36:22 -0500, VanguardLH wrote:

[snip]

> Sending just the URL of an image is polite.  The recipient gets to
> decide whether to see the online image or not rather than wasting the
> bandwidth and disk space (in both sender's and recipient's mailboxes on
> their servers and in the clients) to get an e-mail with content they may
> not want.  Including huge attachments could result in consuming a
> recipient's mailbox to its max quota preventing receipt of further
> e-mails until the recipient deletes the bloated e-mail.

Also, when you include a link in email, be sure to test it. Some links 
don't actually go to the page you copied it from (probably because of 
server-side script).

[snip]

-- 
Mark Lloyd
http://notstupid.us/

"They are not jackbooted Nazi thugs. They are merely German policemen in
spiffy uniforms here to help us." - Vichy government (1941 - 1945)

[toc] | [prev] | [next] | [standalone]

#16120

On 2025-03-21 18:08, Mark Lloyd wrote:
> On Thu, 20 Mar 2025 17:36:22 -0500, VanguardLH wrote:
> 
> [snip]
> 
>> Sending just the URL of an image is polite.  The recipient gets to
>> decide whether to see the online image or not rather than wasting the
>> bandwidth and disk space (in both sender's and recipient's mailboxes on
>> their servers and in the clients) to get an e-mail with content they may
>> not want.  Including huge attachments could result in consuming a
>> recipient's mailbox to its max quota preventing receipt of further
>> e-mails until the recipient deletes the bloated e-mail.
> 
> Also, when you include a link in email, be sure to test it. Some links
> don't actually go to the page you copied it from (probably because of
> server-side script).

And some sites use geofencing. I may be telling something about a tool 
from a hardware store, but they can not see the photo because site is 
stupid.


> 
> [snip]
> 


-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#16117

VanguardLH wrote:
> "Alan K." <alan@invalid.com> wrote:


> 
> ALL e-mail is sent as text characters.  ALL.  Not some, not most, but
> ALL e-mail is text.  No binary content is allowed at all.  

[ Good explanation, including mention of email not being intended to be 
a file transfer tool snipped. +1 to all of that ]

> 
> MIME got added to allow the addition of non-ASCII text in messages
> (i.e., language support), and to allow e-mail to carry non-text content
> as attachments.

> 
> Sending just the URL of an image is polite.  The recipient gets to
> decide whether to see the online image or not rather than wasting the
> bandwidth and disk space (in both sender's and recipient's mailboxes on
> their servers and in the clients) to get an e-mail with content they may
> not want.  Including huge attachments could result in consuming a
> recipient's mailbox to its max quota preventing receipt of further
> e-mails until the recipient deletes the bloated e-mail.

Your focus is primarily on the effects of storage for the receiver, 
bandwidth, and the effect on the sender's storage are also worth 
considering.

In the days of POP and dial-up connections, the problem was far worse. 
For POP, if a sender sent a large message, then the effect to the user 
was a hairball in the mail stream, and where more recent messages could 
not be downloaded until the large message (often low-priority) was 
moved.  It was in that era when I learned the methodology of making use 
of a web client for alternate access to a mailbox.  If there was a 
hairball in the inbox, then the thing to do was to go to web access, 
move (or delete) the offending large message out of the inbox, to allow 
download of other traffic.  This problem seemed to be worst in the years 
that the world was transitioning from dialup to broadband, and the worst 
offenders seemed to be the people who had broadband, but not realizing 
that there were still lots of people that still had dialup.

Even with IMAP and broadband, a further effect of emailing large content 
is that a copy of all that volume gets left in the Sent Mail folder. 
It's a duplicate copy of content that is already stored locally, and 
merely takes up storage space on the server.  With the perception of 
unlimited space in Gmail, most people don't really pay attention to 
quotas, but they are there, and eventually enough attached content may 
cause issues with a nearly-full mailbox.

Although there are places where I will send embedded photos (and where 
it's appropriate to do so), my preference as receiver is links to 
content (especially for things like PDF files) with clear descriptions 
of what is at the other end of the link, that I can choose to follow or 
not.  And for photos, beyond reducing resolution to no larger than 150 
dpi), if I'm sending, I frequently go the route of attachment, rather 
than embedding.

For attachments, then Thunderbird's capacities for deleting or detaching 
become useful, as well.  For something that I send, I may need the cover 
message, but I already have the attachment, and deleting the attachment 
means that I'm not taking up space with the saved copy, whether in Sent 
Mail or whatever folder I save to.  The other effect that I've found 
with attachments is that there are far too many people in the world with 
the bad habit of replying to a message by simply quoting the entire 
received message, and then inserting a top-quoted reply.

If my original has embedded photographs in it, it means that the 
top-quoted reply has all of my photographs, and even if I want to keep 
the reply, it means that I have to keep the quotation of my original 
content, which is the large majority of the message, rather than just 
the several sentences of reply that I actually want.

It is possible to export such a message and edit out the MIME-encoded 
content, and then import it back, but the process is tedious.  I've done 
it a few times, but infrequently enough that I have to do some 
trial-and-error to get it to work, and I've never documented it.

On the other hand, if I send photos as attachments, then if somebody 
replies, those attachments aren't included in the response, unless the 
other person explicitly sets the reply to include them, and people who 
send top-posted replies normally don't.

The result is that if I send photos as attachments, I can delete the 
attachments from the copies I save, and if a reply comes back with an 
attachment, I can delete that as well, even if I keep the rest of the 
message.

Smith

[toc] | [prev] | [next] | [standalone]

#16098

Carlos E.R. wrote:

> This was not happening some time ago, I always got the photo links. Now 
> I have to be careful when sending photos that I don't get the heavy 
> version.
> 
> Why, what is going on?

The website isn't sending you a http:// link to the image, its sending 
you the whole image in a data:// url that contains the full image, TB is 
just copying what it ws given.

[toc] | [prev] | [next] | [standalone]

#16101

On 2025-03-21 07:40, Andy Burns wrote:
> Carlos E.R. wrote:
> 
>> This was not happening some time ago, I always got the photo links. 
>> Now I have to be careful when sending photos that I don't get the 
>> heavy version.
>>
>> Why, what is going on?
> 
> The website isn't sending you a http:// link to the image, its sending 
> you the whole image in a data:// url that contains the full image, TB is 
> just copying what it ws given.

But I can right click on the image, select "copy url to image", and then 
insert that in TB. It works.

-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#16102

Carlos E.R. wrote:

> But I can right click on the image, select "copy url to image", and then 
> insert that in TB. It works.

and does it paste a data:// url into the email?

you can check with view source of the message in your sent folder

[toc] | [prev] | [next] | [standalone]

#16104

On 2025-03-21 12:48, Andy Burns wrote:
> Carlos E.R. wrote:
> 
>> But I can right click on the image, select "copy url to image", and 
>> then insert that in TB. It works.
> 
> and does it paste a data:// url into the email?
> 
> you can check with view source of the message in your sent folder

I check the size of the email.

The procedure I do is:

  right click on FF image
  ctrl-v in TB
  save draft
  If size of email is large, open image, delete the "data://..." part, 
and replace with URL obtained from FF. Save draft, check size.


I check now the source on sent folder:

<img
src=3D"https://ubuntuhandbook.org/wp-content/uploads/2025/03/gimp3-patche=d.webp"
         alt=3D"" moz-do-not-send=3D"true" width=3D"1541" height=3D"838">


-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#16105

On 3/21/2025 7:41 AM, Carlos E.R. wrote:
> On 2025-03-21 07:40, Andy Burns wrote:
>> Carlos E.R. wrote:
>>
>>> This was not happening some time ago, I always got the photo links. 
>>> Now I have to be careful when sending photos that I don't get the 
>>> heavy version.
>>>
>>> Why, what is going on?
>>
>> The website isn't sending you a http:// link to the image, its sending 
>> you the whole image in a data:// url that contains the full image, TB is 
>> just copying what it ws given.
> 
> But I can right click on the image, select "copy url to image", and then 
> insert that in TB. It works.
> 

I usually download the image to my PC to make sure that it's not huge.
If it is, I use an image resizer (that installs into my right click drop
down menu when I've clicked on an image file) to choose the size I want
to attach to the email.  See:
https://github.com/bricelam/ImageResizer/releases

[toc] | [prev] | [next] | [standalone]

#16106

On 2025-03-21 14:27, Retirednoguilt wrote:
> On 3/21/2025 7:41 AM, Carlos E.R. wrote:
>> On 2025-03-21 07:40, Andy Burns wrote:
>>> Carlos E.R. wrote:
>>>
>>>> This was not happening some time ago, I always got the photo links.
>>>> Now I have to be careful when sending photos that I don't get the
>>>> heavy version.
>>>>
>>>> Why, what is going on?
>>>
>>> The website isn't sending you a http:// link to the image, its sending
>>> you the whole image in a data:// url that contains the full image, TB is
>>> just copying what it ws given.
>>
>> But I can right click on the image, select "copy url to image", and then
>> insert that in TB. It works.
>>
> 
> I usually download the image to my PC to make sure that it's not huge.
> If it is, I use an image resizer (that installs into my right click drop
> down menu when I've clicked on an image file) to choose the size I want
> to attach to the email.  See:
> https://github.com/bricelam/ImageResizer/releases

Sure. I do that if I know the other person wants a copy. That's not the 
case, they prefer a link. It doesn't matter if it dies in a month.


I could use links to my own server, but Telefónica did something to my 
router and now they don't work.

-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#16110

On Fri, 21 Mar 2025 15:07:38 +0100, "Carlos E.R."
<robin_listas@es.invalid> wrote:

>On 2025-03-21 14:27, Retirednoguilt wrote:

>> I usually download the image to my PC to make sure that it's not huge.
>> If it is, I use an image resizer (that installs into my right click drop
>> down menu when I've clicked on an image file) to choose the size I want
>> to attach to the email.  See:
>> https://github.com/bricelam/ImageResizer/releases
>
>Sure. I do that if I know the other person wants a copy. That's not the 
>case, they prefer a link. It doesn't matter if it dies in a month.
>
>
>I could use links to my own server, but Telefónica did something to my 
>router and now they don't work.

That's why I never use the router provided by the ISP. I leave it in its
box and put it on a closet shelf, preferring instead to use my own
router.

[toc] | [prev] | [next] | [standalone]

#16112

On Fri, 21 Mar 2025 11:31:02 -0500, Char Jackson wrote:

[snip]

> That's why I never use the router provided by the ISP. I leave it in its
> box and put it on a closet shelf, preferring instead to use my own
> router.

I always use my own router too. It's a part of MY network, not theirs.

Also, when I changed ISPs a couple of years ago, I didn't want to have to 
redo all that network setup (just change the WAN connection and reboot the 
router).

BTW, I use "address reservation" for most devices. It prevents a lot of 
network problems.

-- 
Mark Lloyd
http://notstupid.us/

"They are not jackbooted Nazi thugs. They are merely German policemen in
spiffy uniforms here to help us." - Vichy government (1941 - 1945)

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | alt.comp.software.thunderbird

csiph-web