Subject: Re: bug#71909: 30.0.60;

From: Eli Zaretskii <[email-masked]>
Date: Wed, 30 Oct 2024 17:35:36 +0200

> Date: Wed, 30 Oct 2024 10:05:08 +0100
> From: Cecilio Pardo <[email-masked]>
> 
> >> The image conversion is done using GdiPlus functions, which are
> >> already used on w32image.c, but are static. I have splitted this file
> >> into .c and .h, to be able to reuse those definitions. The image
> >> conversion requires that native image functions are activated.
> > 
> > What happens with yank-media if the user disables native image APIs?
> > Do we signal an error or is there some graceful degradation (like
> > using another MIME type)?
> 
> The ability to yank DIBV5 will be lost. If there is no alternative such 
> as PNG or image/*, then yank can't be done.

Is this because w32-use-native-image-API set to nil disables loading
of GDI+?  If so, we could load it even if w32-use-native-image-API is
nil, but just return false from w32_can_use_native_image_api.  This
would allow us to use the GDI+ functions needed for yanking, but not
those needed for image display.  Does this make sense?

> > Why a unibyte string?  Is this always binary data or something?  If
> > this could be text (e.g., text/html), then a unibyte string is not the
> > best choice.
> 
> It can be binary, but not always.  Is unibyte ok for binary cases?

Yes.  But we need to document that in the doc string.

> I can 
> treat text/* differently, and make exceptions for types like image/svg+xml.

That'd be much better.

> > In any case, if the function must return a unibyte string in some
> > cases, that should be mentioned in the doc string, because callers
> > will otherwise not expect to get a unibyte string.  Also, where will
> > this unibyte string be decoded?
> 
> In the binary case, is there any decoding to do?

No.