0

在我看来相当异国情调。我们最近从 Windows Server 2003 升级/迁移到 2008，现在使用 Doc.AddImageUrl() 时似乎无法渲染图像。（保存 pdf 时，图像以正确的尺寸显示，但 IE8 丢失图像 x 出现）。

如果我理解正确的话，ABCpdf 在内部使用 IE 渲染来处理这类事情。

我们认为这可能是权限问题，但我们检查了 IE ESC 并且似乎按照他们的建议进行了配置。有没有其他人遇到过类似的问题？也许需要代码配置？

不是整个片段，而是 ABCpdf7 的东西：

using (Doc doc = new Doc())
        {
            doc.HtmlOptions.PageCacheEnabled = false;
            doc.HtmlOptions.UseNoCache = true;
            doc.HtmlOptions.PageCacheClear();
            doc.HtmlOptions.PageCachePurge();
            doc.HtmlOptions.UseResync = true;
            doc.HtmlOptions.ImageQuality = 25;

            int pageID = doc.AddImageUrl(url + "&guid=" + url.GetHashCode());

            while (true)
            {
                if (!doc.Chainable(pageID))
                    break;
                doc.Page = doc.AddPage();
                pageID = doc.AddImageToChain(pageID);
            }

  // file saving etc.
    }
4

1 回答 1

0

从代码中提取单元测试以在多个环境中进行测试。事实证明，我们的开发数据库服务器（这是唯一一个运行 2008 年的服务器）能够以几乎完全相同的配置运行单元测试。

掌握了这些信息，我们能够将其范围缩小到生产中的 dll。尽管 ABCpdf.dll 是正确的（32 位），但 64 位内核 (ABCpdf7ce.dll) 正在生产中。

我猜因为组件的核心是 COM (iirc)，所以我们没有抛出任何错误。此外，我们能够从无图像的 html 生成 pdf 的事实对我来说很奇怪。

而且，最重要的是，我们的存储库中没有 64 位 dll 的记录，而 32 位 dll 在我们的 GAC 中。据我所知，核心 DLL 仅用于构建，因此我们从受影响的环境中删除了这些 dll，并且看起来状况良好。

于 2010-03-19T06:00:38.670 回答