1

TLDR

I want to increase the time available to manipulate the DOM before the print version is generated.

Use case

In a website I work on, we have embedded charts from a 3rd party provider (Qlik). We now want to be able to print the page with the charts using the browser's native print functionality.

The charts need to be redrawn in a different size before printing, otherwise they will look cut off.

The scripts from the 3rd party do subscribe to a resize event, which I can trigger using e.g. window.dispatchEvent(new Event('resize'));. Or alternatively I can directly call qlik.resize();.

Problem

On print, if I attempt to trigger a redraw on 'beforeprint', I see the redrawn charts only in the actual webpage, whereas the print preview still shows the old version of the charts before the redraw, or a broken half-redrawn version.

Observations

It seems that starting with the 'beforeprint' event, I still have ~210 milliseconds to alter the DOM, after that further changes have no effect on the printed output.

I get to the 210ms with the following experiment:

  // (This sample uses jQuery, adjust as you see fit)
  const $display = $('h2#chart-section');
  window.addEventListener('beforeprint', function () {
    console.log('beforeprint', window.matchMedia('print').matches);
    $display.append(' beforeprint');
    for (let dt = 0; dt < 1000; dt += 10) {
      window.setTimeout(function () {
        console.log('beforeprint t0', window.matchMedia('print').matches);
        $display.append(' t' + dt);
      }, dt);
    }
  });

The h2 in the printed version will be like '...t210', whereas in the screen version it goes up to '...t990', even while the print preview is open.

Also interestingly the window.matchMedia('print').matches always gives false.

Question

How can I force more time to pass before the print version is "frozen"?

donquixote
  • 4,877
  • 3
  • 31
  • 54
  • Have you tried having a print button that opens a page that specifically is made for print and has the charts already drawn for print? – imvain2 Aug 02 '22 at 19:40
  • It's not possible to cancel the print https://stackoverflow.com/a/28937612/3807365 - so therefore probably not possible to delay it – IT goldman Aug 02 '22 at 19:45
  • I think, normally, you'd use `qlik.resize()`. However, the docs say that this just fires off resize events to each qlik component, which separates those actions from the `beforeprint` event. I think you need a way to resize without wrapping that action in new events. Also, this may not be resolvable if qlik requires retrieving remote content to do the resize, as in a SaaS. – Ouroborus Aug 02 '22 at 20:01
  • @imvain2 Yes, the dedicated print button is an alternative solution I am following. However in this question I would like to see how far I can get with plain native browser print. In the end, if I choose the alternative, I want to be able to explain why browser print is a dead end. – donquixote Aug 02 '22 at 20:06
  • @Ouroborus My experiment suggests that it would work if the new events all complete in under 200ms. But it seems that Qlik needs longer than that. – donquixote Aug 02 '22 at 20:07
  • 1
    In my own testing, in Firefox, nothing in the `setTimeout` callbacks make it into the printed document. Just the " beforeprint" from the event callback. – Ouroborus Aug 02 '22 at 20:35
  • @Ouroborus I confirm, Firefox gives me none. Chromium consistently gives me around ~210ms, even for a totally different test document. – donquixote Aug 02 '22 at 21:08

0 Answers0