Re: [w3ctag/design-reviews] Handwriting Recognition API (#591)

Hi, @cynthia

> Writing direction
We'll add a `direction` hint to indicate the expected parsing / reading direction.

So that the recognizer for ("en" and "ar") can differentiate the following two outputs, for text "نشاط التدويل، W3C"
* JS String: W3C, [Arabic characters]
* JS String: [Arabic characters], W3C

Could you confirm this addresses your concern?

> Navigator
Recognition contexts are isolated for each recognizer. Different tabs don't share the recognition context. But they may use the same recognition service on the OS (e.g. process).

Is there any documents on navigator layering?

----

Hi, @atanassov 

The handwriting process looks like this:
User input --(1)--> Stroke Data --(2)--> Text

Websites can already collect handwriting and analyze them. All they need is some user input (step 1), and some analysis code. For example, ask user to draw on canvas, use PointerEvent to collect the drawing, then everything to a server for analysis (they don't have to use our API). 

Our API is at step 2. It converts stroke data (represented with our proposed HandwritingStroke and HandwritingDrawing) to some text. 

Websites can already analyze handwritings in JavaScript. Our API made this easier (call a method instead of supplying a bunch of JavaScript code) and more efficient (run in native code / accelerators). In short, our API isn't introducing new things that Web can't already do.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/591#issuecomment-840366071