[whatwg] Supporting scanners on the web

[Ian Hickson]

On Thu, 26 Sep 2013, Benjamin Smedberg wrote:
>
> One of the use cases that has come up for why people are still using 
> plugins is supporting scanning to the web, in particular multi-page 
> scanning. It seems to me that we could hook this up to <input 
> type="file" multiple>, but that we should try to provide UAs with a hint 
> that a page expects a document instead of images. This primarily may 
> affect whether/how the browser presents a scanner option to the user in 
> addition to or instead of camera/photos when selecting an image.

Right now, with <input type=file accept=image/* capture> [1], a browser 
can be told to prefer an appropriate media capture device rather than 
offering a file system or gallery option by default.

[1] http://dev.w3.org/2009/dap/camera/

In practice I don't know how much that has really taken off. On mobile 
devices, especially on Android, where intent-based application cooperation 
is pretty mature, <input type=file accept=image/*> tends to be enough to 
offer the user a full list of appropriate applications, including scanners 
or cameras or galleries or whatnot.

See also:
   https://www.w3.org/Bugs/Public/show_bug.cgi?id=17879


On Thu, 26 Sep 2013, Jonas Sicking wrote:
> 
> What we've done in Firefox for Android is to treat <input type=file 
> accept="image/*"> as a hint that the page wants an image any source. So 
> we give the user options to use any built-in gallery or camera apps for 
> example.
> 
> We could do the same on desktop platforms and display an additional 
> button next to the normal "select file" button if we detected that there 
> are additional image sources like cameras or scanners available.
> 
> There's also been proposals around <input type=file accept="image/*" 
> capture>. This was supposed to mean "invoke media specific capturing 
> methods". I think there was also something like <input type=file 
> capture=camera> being proposed which would specifically enable 
> camera-backed capturing.

capture="" has moved to just being a boolean attribute.

But yeah, I think we should focus on this kind of approach before exposing 
new controls and APIs, to see what authors end up wanting.



On Thu, 26 Sep 2013, Benjamin Smedberg wrote:
>
> * Do/can PNG images contain information about their resolution, so that 
> the site can reconstruct the actual page size?

They can.


> * Should we give the site any way to specify preferred resolution or 
> color depth for an image? Or should the site be prepared process any 
> images to the required resolution, convert to monochrome, etc.

The question is, what are the use cases? Presumably the user's hardware 
might be limited in ways the page didn't expect anyway, so whether the 
page gives defaults or not they'll have to deal with varied results, so 
the use case isn't simplicity.


On Thu, 26 Sep 2013, Jonas Sicking wrote:
> 
> The most requested ability is to resize images to a particular 
> resolution. This is something that can be done using canvas, but not for 
> videos or animated images. And currently you can't do it off the main 
> thread, which is an issue for larger images.
> 
> It would be nice to expose a image-resize API to the web. This way they 
> could do things like resize images to the various sizes needed and just 
> upload the resized images. Currently you have to upload the fullsized 
> image, or you have to resize once to the maximum size you want and 
> upload that, and then resize again on the server. But that results in 
> lower image quality.
> 
> Likewise it would be nice to have an API for re-encoding images without 
> using canvas. This will likely be especially important if we decide on a 
> jpeg successor to add support for.

This comes up occasionally, but we always end up going back to just 
working on putting canvas on workers, so...


On Thu, 26 Sep 2013, Benjamin Smedberg wrote:
>
> * Should the spec recommend any specific MIME types for scanner page 
> images? Most desktop scanners appear to default to .tiff, but that's not 
> a normal web format: perhaps we should recommend that UAs convert to 
> PNG.

On Thu, 26 Sep 2013, Anne van Kesteren wrote:
> 
> So what do the plugins do here (pointers to the plugins?)? It seems if 
> we want to replace these plugins, knowing what they do would be a great 
> start.

Anyone?


On Fri, 27 Sep 2013, Robert O'Callahan wrote:
> 
> PNG sounds good given it's lossless and ubiqutious. Apps can transcode 
> to JPEG (or any other format the browser supports encoding of) on the 
> client if they want to.
> 
> Is implementing a full scanning UI in a Web app in scope or out of 
> scope? If it's in scope, then we'd need the ability to display 
> incremental scan results, and we'd need to be able to do a preview vs 
> full-view scan, and control the area scanned.

On Mon, 30 Sep 2013, Benjamin Smedberg wrote:
>
> For now I intend to focus on implementing the scanning UI in the browser 
> and just handing the site the final product. Any thoughts of exposing a 
> fine-grained control over previews and incremental results needs 
> significantly more thought about how that would work on both desktop and 
> mobile devices.

I'd recommend going with <input type=file accept=image/*> for now, and 
seeing where that gets us. We can always add attributes or an API if 
there's a real need for more control.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'