Or should we just place that into "application/octet-stream" and hope
whoever listens for the clipboard scans the magic bytes of an OpenEXR?

On Thu, Jun 25, 2015 at 2:56 PM, Florian Bösch <pya...@gmail.com> wrote:

> Well let's say some webapp generates an OpenEXR and wants to put it into
> the clipboard as "image/x-exr" which would make sense cause any eventual
> program that'd support OpenEXR would probably look for that mime type.
> You've said you're going to restrict image types to jpeg, png and gif, and
> so my question is, how exactly do you intend to support OpenEXR?
>
> On Thu, Jun 25, 2015 at 2:51 PM, Wez <w...@google.com> wrote:
>
>> Sorry Florian, but I don't see what that has to do with whether or not
>> the Clipboard Events spec mandates that web content can generate their own
>> JPEG or PNG and place it directly on the local system clipboard.
>>
>> What is it that you're actually proposing?
>>
>> On Thu, 25 Jun 2015 at 13:31 Florian Bösch <pya...@gmail.com> wrote:
>>
>>> No idea. Also doesn't matter jack. There could be some now or in the
>>> future. There's a variety of programs that support HDRi (photoshop,
>>> lightroom, hdri-studio, etc.). It's fairly logical that at some point some
>>> or another variant of HDR format will make its way into clipboards. The
>>> same applies to pretty much any other data format be that a file or
>>> something else.
>>>
>>
>

Reply via email to