From: pinmacs <pinmacs@cas.cat>
To: Eli Zaretskii <eliz@gnu.org>, Robert Pluim <rpluim@gmail.com>
Cc: visuweshm@gmail.com, emacs-devel@gnu.org
Subject: Re: yank-media: allow users to limit image types that can be inserted
Date: Mon, 23 Sep 2024 15:00:54 -0300 [thread overview]
Message-ID: <3a015d0f-549a-401f-be1c-651c9dbd5d9a@cas.cat> (raw)
In-Reply-To: <86cykufhw7.fsf@gnu.org>
Before yank-media, I was using org-download [1], so I got used to just
insert a screenshot with no question to answer (such as the type of the
image).
Recently, I moved to yank-media, but to have the same functionality, I
had to tweak it a little bit, full detail here [2].
I see utility on asking for the image/png and image/jpeg and here you
have details why you would care about [3]. But I am not familiar with
image/pbm, image/xbm, image/xpm, image/tiff; for me, it is a nonsense to
appear as types to select. But maybe somebody wants them, so that's why
an option to pre-filter (or not) the candidates; and also the option to
just stick with png (and save a keystroke, and a nonrelevant decision).
[1] https://github.com/abo-abo/org-download
[2] https://mail.gnu.org/archive/html/emacs-orgmode/2024-09/msg00209.html
[3]
> The JPEG compression algorithm operates at its best on photographs
> and paintings of realistic scenes with smooth variations of tone
> and color (...) However, JPEG is not well suited for line drawings
> and other textual or iconic graphics, where the sharp contrasts
> between adjacent pixels can cause noticeable artifacts. Such
> images are better saved in a lossless graphics format such as
> TIFF, GIF, PNG, or a raw image format. The JPEG standard includes
> a lossless coding mode, but that mode is not supported in most
> products.
https://en.wikipedia.org/wiki/JPEG#Typical_use
> The JPEG (Joint Photographic Experts Group) format can produce a
> smaller file than PNG for photographic (and photo-like) images,
> since JPEG uses a lossy encoding method specifically designed for
> photographic image data, which is typically dominated by soft,
> low-contrast transitions, and an amount of noise or similar
> irregular structures. Using PNG instead of a high-quality JPEG for
> such images would result in a large increase in file size with
> negligible gain in quality. In comparison, when storing images
> that contain text, line art, or graphics – images with sharp
> transitions and large areas of solid color – the PNG format can
> compress image data more than JPEG can. Additionally, PNG is
> lossless, while JPEG produces visual artifacts around
> high-contrast areas.
https://en.wikipedia.org/wiki/PNG#JPEG
On 2024-09-23 13:34, Eli Zaretskii wrote:
>> From: Robert Pluim <rpluim@gmail.com>
>> Cc: visuweshm@gmail.com, pinmacs@cas.cat, emacs-devel@gnu.org
>> Date: Mon, 23 Sep 2024 18:10:43 +0200
>>
>>>>>>> On Mon, 23 Sep 2024 18:54:25 +0300, Eli Zaretskii <eliz@gnu.org> said:
>> >> From: Robert Pluim <rpluim@gmail.com>
>> >> Cc: Visuwesh <visuweshm@gmail.com>, pinmacs@cas.cat, emacs-devel@gnu.org
>> >> Date: Mon, 23 Sep 2024 17:09:03 +0200
>> >>
>> Eli> IMO, for users we already have what is needed: when we detect several
>> Eli> formats, we show them to the user and ask him/her to tell us which
>> Eli> format he/she wants to use.
>> >>
>> >> But that requires user interaction. I think the original request could
>> >> be summed up as "if the list contains image/png, donʼt ask me, just
>> >> insert the image".
>>
>> Eli> That's not how I understand the request. It was not always PNG, it
>> Eli> was "sometimes PNG, but if so-and-so-happens, the JPEG" etc.
>>
>> Yes, but the "so-and-so" is determined by a user option. So
>>
>> 1. Always prefer "png" -> user option == "png"
>> 2. Want to choose between "png" and "jpeg" -> user option == ("png"
>> "jpeg")
>> 3. All of the formats -> user option == nil
> That makes little sense to me: how can the user decide in advance to
> use only PNG? by what logic?
>
> And anyway, this is not what the OP said. Let's get back to what he
> said:
>
>> Eli> And no one has explained yet why I would prefer PNG to JPEG or vice
>> Eli> versa, btw. The usual choices I'm familiar with is whether or not to
>> Eli> preserve typefaces, colors, and other fancy attributes; regarding
>> Eli> images, there's just a decision whether you want to paste the material
>> Eli> as a picture or as some kind of text, whether rich or not. So the
>> Eli> background and the context for this request is still not clear to me.
>>
>> I can definitely see a use for case 1 above: "donʼt bother asking me,
>> if png is available just use that".
> I don't understand why would someone define their preference in the
> terms of image format. It makes no sense.
>
next prev parent reply other threads:[~2024-09-23 18:00 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-22 16:53 yank-media: allow users to limit image types that can be inserted pinmacs
2024-09-23 11:20 ` Eli Zaretskii
2024-09-23 13:46 ` Visuwesh
2024-09-23 14:30 ` Eli Zaretskii
2024-09-23 15:06 ` Visuwesh
2024-09-23 15:48 ` Eli Zaretskii
2024-09-23 15:09 ` Robert Pluim
2024-09-23 15:14 ` Visuwesh
2024-09-23 15:20 ` Robert Pluim
2024-09-23 15:58 ` Eli Zaretskii
2024-09-24 5:00 ` Visuwesh
2024-09-24 5:10 ` Visuwesh
2024-09-24 11:57 ` Eli Zaretskii
2024-09-24 12:42 ` Visuwesh
2024-09-23 15:54 ` Eli Zaretskii
2024-09-23 16:10 ` Robert Pluim
2024-09-23 16:34 ` Eli Zaretskii
2024-09-23 18:00 ` pinmacs [this message]
2024-09-23 18:35 ` Eli Zaretskii
2024-09-23 20:45 ` Pedro
2024-09-23 21:08 ` pinmacs
2024-09-24 8:15 ` Robert Pluim
2024-09-24 11:30 ` Eli Zaretskii
2024-09-24 12:18 ` Robert Pluim
2024-09-24 13:08 ` Eli Zaretskii
2024-09-24 13:38 ` Visuwesh
2024-09-24 13:50 ` Eli Zaretskii
2024-09-24 5:08 ` Visuwesh
2024-09-24 12:00 ` Eli Zaretskii
2024-09-24 12:50 ` Visuwesh
2024-09-24 13:23 ` Eli Zaretskii
2024-09-24 13:37 ` Visuwesh
2024-10-26 17:27 ` Ihor Radchenko
2024-10-26 19:09 ` Eli Zaretskii
2024-10-27 8:17 ` Ihor Radchenko
2024-10-27 9:14 ` Eli Zaretskii
2024-10-27 9:36 ` Visuwesh
2024-10-27 10:09 ` Eli Zaretskii
2024-10-27 15:02 ` Visuwesh
2024-10-27 17:11 ` Eli Zaretskii
2024-10-28 13:37 ` Visuwesh
2024-10-29 11:29 ` Visuwesh
2024-10-30 23:22 ` Pedro
2024-10-31 8:29 ` Eli Zaretskii
2024-10-31 10:47 ` pinmacs
2024-10-31 11:16 ` Eli Zaretskii
2024-10-31 11:51 ` pinmacs
2024-10-31 14:31 ` Eli Zaretskii
[not found] ` <c67bb616-710b-4272-919d-bf4ece8e7c99@imayhem.com>
2024-10-31 14:20 ` Eli Zaretskii
2024-10-31 18:21 ` Ihor Radchenko
2024-10-31 19:03 ` Eli Zaretskii
2024-10-31 19:08 ` Ihor Radchenko
2024-10-31 19:29 ` Eli Zaretskii
2024-10-31 19:42 ` Ihor Radchenko
2024-11-01 7:01 ` Eli Zaretskii
2024-10-31 8:48 ` Visuwesh
2024-10-31 8:24 ` Eli Zaretskii
2024-10-31 8:46 ` Visuwesh
2024-10-31 9:56 ` Eli Zaretskii
2024-11-01 5:20 ` Visuwesh
2024-11-01 7:38 ` Eli Zaretskii
2024-11-03 17:19 ` Ihor Radchenko
2024-11-03 18:47 ` Eli Zaretskii
2024-11-04 4:04 ` Visuwesh
2024-11-04 20:03 ` Ihor Radchenko
2024-11-04 20:19 ` Eli Zaretskii
2024-10-28 18:39 ` Ihor Radchenko
2024-10-28 18:50 ` Eli Zaretskii
2024-09-23 18:11 ` Eli Zaretskii
2024-09-24 8:38 ` Robert Pluim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3a015d0f-549a-401f-be1c-651c9dbd5d9a@cas.cat \
--to=pinmacs@cas.cat \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=rpluim@gmail.com \
--cc=visuweshm@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.