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. >>> >> >
