| 摘要 | 在浏览器中显示本地提供的 PDF | |
| 代码库链接 | GitHub - thoka/discourse-send-pdf-inline: Patch discourse do serve PDFs inline | |
| 安装指南 | 如何在 Discourse 中安装插件 |
功能
上传的 PDF 文件将以“content disposition inline”方式打开,允许它们 在浏览器中显示,而不是被提供下载。
配置
不需要。
| 摘要 | 在浏览器中显示本地提供的 PDF | |
| 代码库链接 | GitHub - thoka/discourse-send-pdf-inline: Patch discourse do serve PDFs inline | |
| 安装指南 | 如何在 Discourse 中安装插件 |
上传的 PDF 文件将以“content disposition inline”方式打开,允许它们 在浏览器中显示,而不是被提供下载。
不需要。
这与现有的用于执行相同操作的主题组件有何不同/更好?
该插件直接在浏览器中打开 PDF,而不是在帖子内的嵌入式元素中 ![]()
这是一个功能请求:Add configuration option to serve local PDF uploads inline
使用此插件时,“本地”是否意味着 S3 及类似服务以及 CDN 会失败?
它不会改变 S3 提供 PDF 的方式。
副作用将是神奇的。
这个插件是否仍然可用?
我们仍然在使用它。
很遗憾,它目前已损坏。
我必须调查一下。
也许我太天真了,但我认为大多数人希望默认在浏览器中渲染 PDF。
@thoka,你有没有什么理由选择发布一个插件来实现这个功能,而不是将其合并到 Discourse 中?
我已经抽出时间进行了测试。
该插件运行正常。
我不明白,在此期间可能是什么原因导致了问题。
我编写了该插件,因为我的功能请求没有得到回复。
在考虑直接将 PDF 发送到浏览器会产生哪些缺点时,我设想了以下潜在问题:
当在移动设备上将 Discourse 用作渐进式 Web 应用时,用户不可避免地会退出 Discourse 界面,或者更确切地说,退出其用户界面来显示 PDF,从而依赖用户对返回原始应用程序的熟悉程度。
此外,对于移动设备而言,用户只能听凭浏览器如何处理内联 PDF。虽然 Firefox 目前会直接显示文件,但似乎无法说服 Chrome 也这样做: