Question

可以从

开始检索打开的Google文档文档的元素

DocumentApp.openById(doc_id, folder_id)

但是文档的评论是通过Drive API检索的，Comments.list

在包含2条评论的文档上运行此操作：一个在图像上，一个在一个段落中的单词上显示，当文本锚定的评论执行时，图像不会返回context条目：

 "content": "test comment on text",
 "deleted": false,
 "status": "open",
 "context": {
  "type": "text/html",
  "value": "some text the comment is placed on"
 },
 "anchor": "kix.xxxxxxxxxxx1",

 "content": "test comment on an image",
 "deleted": false,
 "status": "open",
 "anchor": "kix.xxxxxxxxxxx2",

其中xxxxxxxxxxx1 / xxxxxxxxxxx2是唯一的锚点ID后缀，kix是Google的“专有”锚定/ editor系统的前缀（正如Steven Bazyl在“the video”开发者指南页面的Managing comments and discussions中所述。）

“锚点基本上告诉我们这篇评论所适用的文件在哪里。因为这是我们的格式[在谷歌]我们确实有一个专有的锚定方案，这使你很难 - 或者更确切地说 - 不可能 - 让你去策划^create？注释固定在我们的文档格式的文本中...但如果它是您控制的文档格式，或者它是某种地方呃......有办法以可互换的方式找到它，您可以将锚点放在那里，您的应用程序可以正确定位，并且可能其他应用程序也可以正确读取和定位。“

如果我看不到放置注释的元素，是否尝试将图像源URL存储在相应图像的注释中注定？ _{^{（上下文：制作.gdoc-to-.md converter）}}

如果是这样，将评论与图像匹配的唯一方法是检索所有上下文无字段注释并假设每个图像都要注释？

GitHub没有将Google Apps脚本列为一种语言（可能是因为它基于Javascript非常密切）。是否有自定义评论锚定系统的开源示例我可以看看？
- 我实际上并不认为使用当前的API可以实现这样的锚定系统。虽然anchor方法提供了Comments.list，但Comments.insert仅允许fileId，content，context.type和context.value：否这里有独特的锚定ID的可能性。
- 相关尝试：Creating anchored comments programmatically in Google Docs
如果我要使用云端硬盘评论SDK编写内容（正如史蒂文所建议的那样），是否有任何方法可以覆盖内置的Google文档评论（例如Ctrl / Cmd + M或自定义按钮使用GAS可访问的context）评论图像？

Answer 1

简单的答案是你无法可靠地匹配。这些锚点在任何地方都不会暴露在Document API中。如果它们被暴露，我希望它们显示为NamedRange或Bookmark条目，但是它们都不会被注释锚点填充。

如何在Google文档中使用kix锚点（或不使用）来匹配图像上的注释

1 个答案: