Pisa pdf 转换器对于大表来说非常慢

发布于 2024-12-07 01:19:41 字数 160 浏览 0 评论 0原文

我正在使用 Pisa 将 HTML 转换为 PDF（在 Django 项目中）。处理跨多个页面的表时速度非常慢：

200 行的表最多需要 150 秒才能转换，而如果我将其拆分为更小的表，则需要 15 秒。

是否有构建由 Pisa 处理的 HTML 表格的提示或最佳实践？

原文

分享到QQ

分享到微博

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

发布评论

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

习惯成性 2024-12-14 01:19:41

我也有同样的问题。该文件只是一个首页和一张巨大的表格。 PDF 渲染时间随着内容表的大小呈指数增长。

我制作了一个清单，检查可能是

我对 PDF 渲染函数进行简单计时的问题（因为它可能是 HTML 渲染，将其传递给 StringIO，或创建 HTTP 响应），并注意到 pisa. pisaDocument 调用确实需要 60 秒才能返回。我列出了可能出现问题的清单，并逐一进行了处理。检查表包括图像、CSS、标记复杂性和框架。

图像几乎不会影响渲染时间（我每页只有一张，所以 YMMV）。框架也没有。

标记复杂性是我的模板的主要问题。显然，pisa 会非常非常缓慢地渲染表中的几列

该表花费了太多时间来渲染，但我注意到，如果我将表拆分为较小的表，则渲染时间不会再呈指数增长，并且它的时间也不会增加。渲染所有东西都被切成两半。我在 Django 模板中使用了以下代码：

    {% if forloop.counter|divisibleby:20 %}</table><table>{% endif %}

编辑：此修复对于重复表头效果不佳，因此如果您正在执行 repeat="1"，则必须确切地知道每页适合多少行。

另外，我的 CSS 中有一个怪物般的选择器：

    html, body, div, span, applet, object, iframe,
    h1, h2, h3, h4, h5, h6, p, blockquote, pre,
    a, abbr, acronym, address, big, cite, code,
    del, dfn, em, img, ins, kbd, q, s, samp,
    small, strike, strong, sub, sup, tt, var,
    b, u, i, center,
    dl, dt, dd, ol, ul, li,
    fieldset, form, label, legend,
    table, caption, tbody, tfoot, thead, tr, th, td,
    article, aside, canvas, details, embed,
    figure, figcaption, footer, header, hgroup,
    menu, nav, output, ruby, section, summary,
    time, mark, audio, video{
        ...
    }

通过将其更改为 * {...} ，渲染速度会加快一些。这是违反直觉的，因为当您使用 * 选择器时，浏览器渲染页面的速度不会比使用上述怪物时快。

此外，由于某种原因，将两个页内

I had the same problem. The document was just a front page and a huge table. PDF rendering time was increasing exponentially with the size of my content table.

I made a checklist of things to check out which might be the problem

I did simple timing on my PDF rendering function (since it could be the HTML rendering, passing it to StringIO, or creating the HTTP response), and noticed that the pisa.pisaDocument call did take 60 seconds to return. I did a checklist of things that might be the problem, and worked on them each. The checklist included Images, CSS, Markup complexity, and Frames.

Images barely affected the rendering time (I only had one per page, so YMMV). Neither did Frames.

Markup complexity was the main problem of my template. Apparently pisa will render several columns in a table very, very slowly

The table was taking too much time to render, but I noticed that if I split the table into smaller tables, the rendering time didn't increase exponentially anymore, and the time it took to render everything was cut in half. I used the below code in my Django template:

    {% if forloop.counter|divisibleby:20 %}</table><table>{% endif %}

edit: This fix does not work well with repeating table headers so if you're doing repeat="1" you have to know exactly how many rows to fit in each page.

Also, I had this monster of a selector in my CSS:

    html, body, div, span, applet, object, iframe,
    h1, h2, h3, h4, h5, h6, p, blockquote, pre,
    a, abbr, acronym, address, big, cite, code,
    del, dfn, em, img, ins, kbd, q, s, samp,
    small, strike, strong, sub, sup, tt, var,
    b, u, i, center,
    dl, dt, dd, ol, ul, li,
    fieldset, form, label, legend,
    table, caption, tbody, tfoot, thead, tr, th, td,
    article, aside, canvas, details, embed,
    figure, figcaption, footer, header, hgroup,
    menu, nav, output, ruby, section, summary,
    time, mark, audio, video{
        ...
    }

By changing it to * {...} the rendering sped up a bit. This was counter-intuitive since browsers will not render your page as fast when you use the * selector than when you are using the above monster.

Also, for some reason, merging two in-page <style> tags into one tag decreased rendering time, too.

回复收藏 0 原文

~没有更多了~