https://wicg.github.io/handwriting-recognition/ [in review]
An API for web applications to make use of advanced handwriting recognition services (e.g. those on operating systems) to recognize text from handwriting drawings (inks) in real time. In this context, handwriting drawing means the temporal and positional information used to describe a human handwriting process.
Different browsers (and operating systems) will expose different underlying implementations and produce different outputs given the same input. We think this is acceptable given the implementation is machine-learning based, and it is not feasible or desirable to precisely specify the expected output for a given input in a standard. In the past, we have taken this approach for the Web Speech and Shape Detection APIs.
Gecko: No signal (https://github.com/mozilla/standards-positions/issues/507) Feedback requested, no reply yet.
WebKit: No signal (https://lists.webkit.org/pipermail/webkit-dev/2021-March/031762.html) Feedback requested, no reply yet.
Web developers: Positive (https://github.com/WICG/handwriting-recognition/issues/21) Twitter: https://twitter.com/ChromiumDev/status/1428640785810051074
N/A. Existing DevTools tooling works for this feature.
No. Full coverage relies on platform-specific implementation. WPT only tests failure cases.
Intent to prototype: https://groups.google.com/a/chromium.org/g/blink-dev/c/VXUq1UY4m7Y
Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/o8RqlFwZItQ/m/vgHLF_pHBQAJ
This intent message was generated by Chrome Platform Status.
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPV%2BSg-5XE4cpDbwT69_T4u2CPN18O-9y_8nAW%2Bq-XYpwtjn3A%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9XKeNj0Vznbv7bz_O%2BqvstWn89GOaO1xrzbe2XnDB8%2Bw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CANFkJJ%3DajkSxJ4XYiN%2BQ9viW8TsgSVjf09tPnrQh2DtGjkoEPw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_Z6%2BANqj2yV1gJtYMZXPd1GCixB%2BM4SijwMOH0t0diQQ%40mail.gmail.com.
We expect the following to potentially be closed source:
The OS-specific implementation of the handwriting recognizer and its models. In other words, how to convert a list of points to some recognized text. Example: the implementation of Microsoft Windows Ink, and Windows Ink’s English recognizer model.
We expect the following to potentially diverge by platform:
The handwriting recognizer implementation being used (depending on availability). Example: Uses Windows Ink on Microsoft Windows, Use MLService on Chrome OS, use Apple PencilKit on macOS.
Language fallback rules (depending on OS-specific models). Example: If the OS model recognizes both “zh-Hans” and “zh-Hant” at the same time, the Web recognizer supports “zh” language tag. If the model only supports “zh-Hans”, the Web recognizer doesn’t support “zh” language tag (because “zh” should also cover “zh-Hant”).
Availability of languages (depending on availability of OS-specific models). Example: Windows Ink doesn’t support az-Latn (Arabic in Latin alphabet), but Google MLKit supports this language.
The factors contributing to divergence:
Recognizer models could be large (the model for a single language can exceed 20MB), thus impractical to ship them with the browser
Allowing the use of proprietary recognizers (which could outperform open-source ones)
Allowing browsers and OSs to compete on recognizer quality