Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
  • #26687


    We are using to generate the pdf file from HTML pages. The tool is working great but the time taken to generate the file with css is too long. If we do not apply css on our pages, the time is not too much but if the HTML contains images and css is applied on it, the time taken to generate the pdf file is too high. We are generating pdf fore more than 50 pages having images in it.

    Can you please suggest is there any possible way to decrease the render time or it’s a known issue?


    If the CSS stylesheet is linked as a external resource and it impacts the performance, first I would suspect network delays/routing issues by the CSS loading.

    Also try to add a simple progress monitor to determine at which conversion phase the delay occur:



    The css on our webpages are included as the css files. We are not using inline styling. We are generating the pdf file from pd4ml on the server where our web application exist (web pages + css + images etc). Therefore, its a less probability of any networking delays.

    If we generate our webpages containing images but without CSS the performance is not that bad but with CSS its too slow. Like 139 pdf pages (with css styling, fonts and images ) are generated in approx. 80 secs. We have embed the fonts files in the jar file of our application.

    Can you please answer the following questions:
    The CSS that we are using is quite heavy (approx 4000 lines, 137KB size). Could heavy css size be the reason for slow performance?

    If yes, does the css lines which are not used on the page also adds to the pdf generation time or time is only dependent on the how much css styling is applied on the page. In other words if only a section of css is getting applied on my pdf pages, does rendering of that particular section of css account for the generation time or whole css is parsed and rendered by pd4ml, does not matter if all the css is applied on html or not.

    Is there any CSS or HTML tags/attributes/property which takes too much of time to render by pd4ml and we should avoid it to enhance the performance?

    Any common tips that can imporve the performance of the overall pdf generation time.



    I would also like to provide you the dump of progress monitor for our few pages:

    Scenerio1: Generate 10 big HTML pages with no images in it (only plain text) and minimum styling is applied (excluded heavy css file), it generates 91 pdf pages out of it and following is the important information from progress monitor dump:

    204 progress html parsed
    5532 progress document tree structure built
    5579 progress layouting…
    8172 progress generating PDF… 1
    53684 progress done.

    Scenerio2: Same as scenerio1 with heavy css file
    203 progress html parsed
    30046 progress document tree structure built
    30093 progress layouting…
    32155 progress generating PDF… 1
    74826 progress done.

    Scenerio3: Generating 10 HTML pages containing text and images with minimum styling (excluding heavy css that I mentioned in previous post), it generates around 30 pages.

    94 progress html parsed
    3125 progress document tree structure built
    3141 progress layouting…
    3641 progress generating PDF… 1
    6594 progress done.

    Scenerio4: Same as scenerio3 with heavy css

    109 progress html parsed
    19140 progress document tree structure built

    19890 progress generating PDF… 1
    23499 progress done.



    I am also seeing this issue on pd4ml version 3.8.0fx3 pro
    Seems to have to do with heavy amounts of CSS.

    Unfortunately for me, the actual CSS is generally out of my control, so trimming it is not an option.

    It is not a server issue. Please benchmark and see for yourselves.

    Additionally: It seems to work very fast on a Windows Desktop, but is very noticeably slower on a multi-server Linux Machine. I’m using this through the provided jar, so this shouldn’t be an issue.

Viewing 5 posts - 1 through 5 (of 5 total)

The forum ‘General questions / FAQ’ is closed to new topics and replies.