在页面中嵌入 PDF 并打印 - IE9 问题

发布于 2024-12-21 06:26:51 字数 1908 浏览 0 评论 0原文

我有一些代码,通过将容器的innerHTML 设置为该函数返回的字符串,将 PDF 文档动态加载到网页中:

function getPdfString(url) {
    return '<object data="' + url + '" type="application/pdf" classid="clsid:ca8a9780-280d-11cf-a24d-444553540000" style="width:100%;height:600px"></object>';
}

在安装了 Adob​​e Reader 插件的 IE 中(由检测 PDFObject),我的代码将此 HTML 插入到隐藏容器中,将对对象元素的引用放入 el ,然后运行此代码(Repeater是一个自定义类):

log("** start repeater **");
var r = _repeater = new Repeater(function() {
    try {
        var delta = timeInterval();
        log("iteration - " + delta + "ms");

        el.gotoFirstPage(); //throws exceptions until the PDF is loaded

        log("** assuming success, stop **");
        r.stop();
        r = undefined;

        setTimeout(function() {
            el.print(); //should succeed, can't tell because it doesn't throw or return anything
        }, 100);
    } catch(e) { }
}, 0, 100);

这非常复杂,但很有必要,因为无法判断 PDF 何时加载,也无法判断 el.print() 是否成功。我花了很长时间才弄清楚,但它似乎在 IE7 和 IE8 中运行得很好。 IE9 时好时坏,通常在我的本地计算机(运行 IIS7.5)上运行,但有时不能运行。当网站在我的测试服务器上运行时,IE9 从未工作过,而测试服务器出于需要而运行 IIS6。我不知道我运行的 IIS 版本是否导致了我的问题,但从 Fiddler 日志来看,我对此表示怀疑。

我一直在仔细研究 Fiddler,到处进行一些小调整,看看是否有什么不同。到目前为止,什么都没有。我能看到的唯一区别是 Server 标头。

我发现IE7和IE8需要classid属性;否则,他们会对 PDF 发出多次请求,并且经常无法加载它。它还显着改进了 IE9 的缓存行为。

每次获取的 PDF 都会略有不同。我目前没有将其保存到临时文件或任何其他文件中,但如果绝对必要的话我可以这样做(这样我就可以在后续请求中重新发送相同的 PDF)。

响应正在进行 gzip 编码,但无论是否启用,我都有同样的问题。

我注意到,当问题发生时,终止 AcroRd32.exe 有时可以暂时解决问题。

旁注:Firefox 和 Opera 在嵌入 PDF 的页内弹出窗口中使用相同的 HTML。这工作得很好。 (遗憾的是,Adobe Reader NPAPI 插件上没有我能够找到的 print() 方法,因此弹出窗口指示用户单击嵌入视图的“打印”按钮)

没有什么可以阻止我尝试其他嵌入方法例如 iframe,但当我第一次尝试它时,我遇到了一些奇怪的问题(在经历了这些混乱之后,我不记得它们现在是什么了)。

我想这就是我现在所知道的关于这个问题的一切......

I have some code which dynamically loads a PDF document into a web page by setting a container's innerHTML to the returned string of this function:

function getPdfString(url) {
    return '<object data="' + url + '" type="application/pdf" classid="clsid:ca8a9780-280d-11cf-a24d-444553540000" style="width:100%;height:600px"></object>';
}

In IE with the Adobe Reader plugin installed (as determined by the code that detects the Adobe ActiveX at PDFObject), my code inserts this HTML into a hidden container, puts a reference to the object element into el, and then runs this code (Repeater is a custom class):

log("** start repeater **");
var r = _repeater = new Repeater(function() {
    try {
        var delta = timeInterval();
        log("iteration - " + delta + "ms");

        el.gotoFirstPage(); //throws exceptions until the PDF is loaded

        log("** assuming success, stop **");
        r.stop();
        r = undefined;

        setTimeout(function() {
            el.print(); //should succeed, can't tell because it doesn't throw or return anything
        }, 100);
    } catch(e) { }
}, 0, 100);

This is very convoluted, but necessary because there's no way to tell when the PDF is loaded, nor whether or not el.print() succeeded. It took me a long time to figure out, but it seems to work well in IE7 and IE8. IE9 has been hit and miss, usually working on my local machine (which runs IIS7.5), but sometimes not. IE9 has never worked when the site is running on my test server, which runs IIS6 out of necessity. I don't know if the version of IIS that I am running is causing my issue, but judging from the Fiddler logs, I doubt it.

I have been poring over Fiddler, making small tweaks here and there to see if anything makes a difference. So far, nothing has. The only difference that I can see is the Server header.

I found that the classid attribute is needed by IE7 and IE8; otherwise, they will make multiple requests for the PDF, and often fail to load it. It also significantly improves IE9's caching behavior.

The PDF is slightly different each time it is acquired. I'm not currently saving it to a temporary file or anything, though I could if it is absolutely necessary (so I could re-send the same PDF in a subsequent request).

The response is being gzip encoded, but I have the same problem whether it is enabled or not.

I have noticed that when the problem occurs, terminating AcroRd32.exe sometimes fixes the issue temporarily.

Side note: Firefox and Opera use the same HTML in an in-page popup which embeds the PDF. This works perfectly fine. (The Adobe Reader NPAPI plugin doesn't have a print() method on it that I have been able to find, sadly, so the popup instructs users to click the embedded view's Print button)

Nothing is stopping me from trying other methods of embedding such as an iframe, but I had some weird issues with it when I first tried it (can't remember what they were now, after all this mess).

I think that's everything I know about the problem right now...

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

离笑几人歌 2024-12-28 06:26:51

这似乎是 Adob​​e Reader 和 IE 插件特有的问题。我发现一些论坛主题表明这是一个常见的、可重现的错误(http://forums.adobe .com/thread/758489)。

解决方案似乎是在 / 标记上使用 iFrame。

This seems to be a problem specifically with Adobe Reader and the IE plugin. I've found a few forum threads that indicate this is a common, reproducible error (http://forums.adobe.com/thread/758489).

The solution seems to be using an iFrame over an <object>/<embed> tag.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文