We develop high quality grammar based proofing tools (including grammar checkers), and we have a https://github.com/GrammarSoft/proofing-gasmso, but the APIs are so fragmented and anemic that it is extremely hard or even impossible to do what we want.
A unified proofing tool API would be amazing, but barring that we need the individual APIs' to achieve feature parity and overall improved.
We need at least:
- Temporary wavy underlines or highlighting to mark ranges where errors are (also requested here). Really important they are temporary - we don't want to create highlights that get saved with the document.
- That those ranges are clickable and emit a trigger so we know which error they want to look at.
- Navigate the user's view to the next/previous error when they're done with current.
- Track paragraphs precisely, so we know where an error belongs in the document after getting the result from our analyzer.
- Lock the document so the user cannot manually insert text while proofing is ongoing.
- Alternatively to locking, be able to set a trigger to know exactly when and where a modification happens, to invalidate the errors in that paragraph (also requested here).
For Word, we have implemented this in a sidebar. We can sort of highlight errors in the document by changing the user's selection, but that can only highlight 1 error at a time and it overrides their selection and it isn't clickable. Outlook can't do it at all, as selection isn't available in that application.
And speaking of Outlook, that really needs an API boost. You can only get or set the whole email body, and if you want formatting then you get the whole HTML markup. We don't need or want this markup - it's just superfluous and greatly hinders parsing. Plus when you get the whole body, you get the WHOLE body including replied-to text and no way to reliably distinguish that it is replied-to, but obviously such text should not be seen or modified by our tools unless explicitly invoked on a selection of it.
And none of the applications support as-you-type events, so implementing reliable as-you-type proofing is just impossible.
A unified proofing tool API would eliminate all these differences. A very similar API would be useful for translation.
(http://web.archive.org/web/20201021221732/https://officespdev.uservoice.com/forums/224641-feature-requests-and-feedback/suggestions/10475778-proofing-tool-api, and https://issuetracker.google.com/issues/37938468)
3 Comments
Yun_WangMicrosoft
TinoDidriksen Please see our latest update on annotation and paragraph event. Word JavaScript API requirement set 1.7 - Office Add-ins | Microsoft Learn
We also have canvas card APIs in preview requirement set now.
Further feedback written at https://github.com/OfficeDev/office-js/discussions/5826
Yun_Wang​ thanks! For some reason I wasn't notified of this reply. I randomly found out about Annotations last week by going through the Word API changelog, so I checked this thread.
Unfortunately, because Annotations are tied to a Microsoft 365 subscription, we can't rely on it. Large customers, such as companies, schools, and government offices, are all on perpetual licenses. Only individuals are on M365.
It is an absolute travesty that Microsoft differentiates APIs based on which kind of license you have. E.g., currently we target WordApi 1.3, so we should be able to tell our customers that it requires "Office 2019 or newer" and not have to provide a caveat that it depends on how they installed Office. It's an absurd situation for support to have to ask the customer to check exact version numbers and installation method.
