AWS Textract 人工审核流程，pdf图片加载失败

【以下的回答经过翻译处理】 挑战在于，虽然现代浏览器本身也可以渲染PDF，但处理PDF的embedding方法是不同于处理图片的。据我所知，没有内置的SageMaker Crowd HTML Element能够可互换地处理这两种类型 - 您使用预构建UI的经验似乎也证实了这一点。

在A2I/SMGT中展示PDF 这个简单的示例建议使用 < iframe type = “ application/pdf”> 通过浏览器的本机渲染器显示 PDF。您可以尝试这种方法...但是截至2022年3月，我发现这种方法的支持是不完善的，因为一些浏览器的默认安全策略限制加载交互式内容的跨源 iframe。 如果浏览器的本机渲染器对用户不起作用，可以改用开源 PDF.js 渲染器。下面是一个较为复杂的示例模板(https://github.com/aws-samples/amazon-textract-transformer-pipeline/blob/0ac365f8e174d44337a5881a7dca6d61b94016cd/notebooks/review/fields-validation-legacy.liquid.html#L24)。从我的经验来看，PDF.js很强大，但对刚开始使用的人不太友好。此示例中的基本流程是：

• 从CDN引用PDF.js的<script>和stylesheets
• 在您的HTML中包含一个PDF查看器结构
• 通过 JavaScript 传递 A2I 对象 URL，设置查看器，并包含您需要的任何其它交互(这里的第二个内联脚本标记可能会被忽略: 它特定于模板收集的数据)

扩展模板的复杂性 由于浏览器的多样性和开发人员使用工具的限制，用 HTML 编写直接到浏览器的内联 JavaScript 可能会很难处理（尽管近年来这种情况已经有了很大改善）。如果您想构建更高级的交互式任务模板，您可能需要探索在 A2I/Ground Truth 中使用 React/Angular/Vue 等前端框架。 上述 PDF.js 模板实际上是一个遗留模板，因此它被示例中的 VueJS 应用程序所取代。在这种情况下，我们进行转换的原因是因为我们想要自定义 PDF 查看器（在文档上渲染检测框），并且应用程序的复杂性证明设置适当的工具链是合理的。您可以在讨论区找到应该在A2I 中使用一般框架还是 VueJS的讨论，并且可以使用该应用程序作为提前构建自己的复杂模板的起点。请注意，如果我从头开始重新构建它，我大概率会使用更少的流动模板，而在 JS 框架内实现更多功能，如此处所讨论的。

您可以在此处查看使用(SageMaker) Python notebook构建/部署的复杂模板，并在此处查看其实际操作的屏幕截图。AWS ML博客文章中进一步讨论了此端到端示例。

处理PDF/图像混合内容 如果您需要模板同时处理 PDF 和图像，这会增加额外的复杂性。您的 JavaScript 能否从对象 URL（文件名）推断输入对象属于哪个类别，并动态设置 <img> 标签或 PDF 查看器？你能从 JS 中获取对象并检查 Content-Type 响应头吗？将文件类型作为输入添加到 A2I 循环并以这种方式传递可能会更简单吗？ （例如，时候使用条件液体模板来渲染 <img> ？）

您可以根据您能在流程中的哪个步骤知道文件类型，而采用多种不同的方法来解决此问题。但最终，您可能会在生成 img 还是 PDF 查看器之间切换：无论这些 HTML 元素是由静态 Liquid 模板创建还是由动态 JS 创建。