Warning: file_get_contents(/data/phpspider/zhask/data//catemap/1/asp.net/32.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
Asp.net 将大型HTML文档转换为PDF_Asp.net_Html_Pdf Generation - Fatal编程技术网

Asp.net 将大型HTML文档转换为PDF

Asp.net 将大型HTML文档转换为PDF,asp.net,html,pdf-generation,Asp.net,Html,Pdf Generation,我正在使用一个asp.net应用程序,它可以从HTML生成大型PDF文档。与典型用法相比,内容可能比较复杂(详细的网格类型列表,css样式,运行40多页)。我们尝试过的库中没有一个性能良好。通常,在功能强大的多核计算机上渲染一个40页的文档需要一分钟以上的时间 我们能够将生成与web应用程序分离,并在某些情况下预生成文档。不过,内容更改的频率需要更快的解决方案 那么,是否有人有过PDF生成组件的经验,该组件可以在几秒钟而不是几分钟内输出内容繁重的40页文档?还是我们的期望不切实际 注意:我不想“

我正在使用一个asp.net应用程序,它可以从HTML生成大型PDF文档。与典型用法相比,内容可能比较复杂(详细的网格类型列表,css样式,运行40多页)。我们尝试过的库中没有一个性能良好。通常,在功能强大的多核计算机上渲染一个40页的文档需要一分钟以上的时间

我们能够将生成与web应用程序分离,并在某些情况下预生成文档。不过,内容更改的频率需要更快的解决方案

那么,是否有人有过PDF生成组件的经验,该组件可以在几秒钟而不是几分钟内输出内容繁重的40页文档?还是我们的期望不切实际


注意:我不想“淘汰”性能较差的组件,因为我们正在寻求供应商的支持以进行改进。我已经回顾了以前在StackOverflow上发布的问题,似乎没有一个问题涉及这种类型或大小的文档。

一个选项可能是不将html转换为PDF,而是采取另一种方法。我们使用生成PDF的ActiveReports报告工具,它在为多数据集报告使用子报告时非常强大,并与visual studio完全集成

这意味着您需要重新生成报告,以生成屏幕上显示的相同数据。这有时并不是一件坏事,因为您可以专门为打印而设置报告的样式


PDF可以通过后端服务生成和/或通过电子邮件发送,或在浏览器上即时生成。

我确信还有其他报告工具,值得一看,甚至SQL Server reporting services也可以提供帮助,因为它可以输出PDF。感谢您的建议。您是否尝试过任何一个选项,输出的大小与我们需要的大小相同,即样式化、文本密集、嵌套的表格/40多页的网格?带状报告工具是为表格数据而构建的,子报告只是报告中的报告。给定一个数据源或2个、40多页根本不会是问题,就像任何数据检索一样,需要优化。分组、页面编号、页面大小、报告/组/页面/页眉/页脚等规则可用。您可以使用样式在报表上添加图像和各种其他组件。它肯定比html到PDF的转换要好。我们已经分析了这个过程,并将最终转换隔离为唯一“无法解决”的问题。我引用的数字是对PDF组件的最后调用,不包括数据检索和HTML生成+1对于建议和提及的子报告。。。让我意识到,在某些情况下,较大的PDF是较小PDF的组合。这使我们可以选择预生成子报告并合并PDF以创建更大的复合文档。是的,生成单独的报告并合并也是构建复杂报告的一种好方法(报告工具不存在,没有它们自己的缺点)有很多库和工具可以进行合并等。像itextSharp这样的库对于我所说的单页合成非常有用,这意味着将文本和图像行放到新的或现有的PDF页面上,而对于表格数据或跨多个页面运行的数据来说并不太好。看看将html(从浏览器)打印到PDF生成器(如PDFCreator)时会获得什么样的性能,这将是一件有趣的事情。顺便说一句,因为你不会提供任何关于你的供应商的信息,你使得提供答案变得更加困难,而这个帖子对其他可能处于类似地位的人来说就没那么有用了。明天列表上的任务之一就是按照你的建议做,并通过桌面工具获得一些打印到PDF的指标。关于讨论供应商,在我们确定x在特定场景中的性能优于y之前,我不愿意这样做。如果事实上所有的供应商都同样没有能力,那么建议某个供应商在我们的场景中表现不好是不公平的。我不排除(正如我在最初的问题中提到的)我们的期望实际上是不现实的。我当然会更新这个问题或添加一个答案,以及我们发现的任何有用的结果。