Print preview in FF and Chrome -> row id´s not properly rendered & tables overlapping

Tags: #<Tag:0x00007efc60b7f3c8>
#1

Hi there,

in general i am really happy with this component! It offers many possibilities as i need them, i.e. preloading a whole set of data and rendering it directly for printing it afterwards. I just updated to the latest version, sadly my problem is still existing - in the browser all rows with the row headers are visible, in the print dialog the last few entries are kind of “cutted” - sometimes if i got more than one table they are also overlapping!

The settings for the table are :
rowHeaders: true,
renderAllRows: true,
viewportColumnRenderingOffset: 6,
columnSorting: true,
dropdownMenu: true,
filters: true,

In the browser everything looks OK

VisibleInBrowser
VisibleInBrowser.png405×700 223 KB

In the print preview the problem gets visible

PrintDialogChrome
PrintDialogChrome.jpg1316×872 116 KB

The pdf/printed page looks exactly like the print preview

printedAsPDF
printedAsPDF.jpg319×678 87 KB

Thanks for helping :slight_smile:

#2

Hi @marc.proske,
Handsontable uses virtual rendering functionality, which might break printing if you try to print it from the main window.
There is a much better solution to print Handsontable.
You can create an iframe programmatically and put a dumped Handsontable’s data and headers inside. To dump table into the pure HTML structure you can use toHTML() method.

Here is a simple demo: https://jsfiddle.net/handsoncode/bxn4sd2k/

#3

Hi Piotr,

maybe I should have mentioned that I use VUE(Quasar framework) and use it to show more than one table - in fact up to 6 different tables at one “page” and print them with the browser functionality. To export the table to an IFrame is not a solution for me, i add footer, headers and so on which have to be in the exported print :disappointed_relieved:

The behavior for the print rendering is different as rendering the html part I guess, anyone ideas for a workaround?

Thanks in advance

#4

What i found out is that the row index is not working properly.
Workaround which is very slow…
Add column i.E. like here
columns: [
{ type: ‘text’, title: ‘INDEX’, data: ‘’ },

when the data for the HOT is present
while (indexCounter < this.$refs.hotTable.hotInstance.countRows()) {
this.$refs.hotTable.hotInstance.setDataAtCell(indexCounter, 0, indexCounter + 1)
indexCounter++
}

is there - without to manipulate the data - a chance to index in a faster way by myself?

Thanks in advance

#5

I should have mentioned that I use VUE(Quasar framework) and use it to show more than one table - in fact up to 6 different tables at one “page” and print them with the browser functionality.

But VUE is still a javascript, so it’s possible to get data from multiple instances and mix them as pure HTML in the way how you need them (you can prepare your own template for printing).

To export the table to an IFrame is not a solution for me, i add footer, headers and so on which have to be in the exported print

That means using iframe with modified content is your only solution. You can also look for 3rd party libraries to print HTML, I found this one: https://github.com/crabbly/print.js (also bases on iframes).
As far as I know, putting custom content into frame elements is the only way to solve client-side printing.

What i found out is that the row index is not working properly.

Could you add some details? What exactly doesn’t work properly with row indexes?

#6

Hi Piotr,

depending the row index it is the case, when its used with the settings property “rowHeaders: true,”, the last few entries in the preview are missing like shown in the first post. When they are replaced with my own index it´s fine. With tables that contain more than approx. 1000 rows the overlapping is still existing.

I tried using an IFrame for printing, it works quite well even with filters and so on -> sadly its not a solution because of another heavy dependency.
Another VUE component from this report shows a 3d model that is adjusted by the user before printing, these adjustments are lost on every reload, hence the same happens when its loaded in an IFrame.
This was also the root cause to print directly from the browser -> else we would have created the reports server-side. The client need to manipulate the 3d model and the result can´t be saved printable without much changes if it is even possible at all.

What do you mean with virtual rendering functionality? The height in the rendering process for the print preview seems to work differenty, this cause the tables to overlap each other and other elements.

Any other ideas left how this can be prevented?

Thank you very much, i know this problem is kind of special.

#7

Hi @marc.proske,
Sorry I didn’t notice you answered. I hope you found a solution.

virtual rendering in Handsontable simulates total scroll (horizontal and vertical) using as few elements as necessary to fill the viewport. That method helps us reduce memory usage what guides us to better performance. So, e.g. if you have 1000x1000 cells, but in one moment you can see 15x10, we render elements only for 15x10 + a few additional rows/cols to reduce flickering on scroll.
In your case, printing requires rendering all cells (1000x1000) because you need to know how much space (pages) table needs to be “printed”.

Using iframes for printing seems to be the only stable options to do that. Although, if you tried and there are some cut-off parts, I suggest reviewing CSS styles.

#8

Hi Piotr,

thanks for the detailed answer. I had to change the way we get the 3d graphic and load that result into the suggested IFrame. Unfortunately there are some difficulties with formatting the table in that IFrame, see also
https://forum.handsontable.com/t/tohtml-does-not-regard-columnrenderer/5206

Can you tell me more about the “CSS” way to maybe solve that problem?
Thanks!

#9

What problem do you mean?
If about omitting renderers in toHTML() - it is not supported.
If about using CSS in print view, it’s often project-related and suggesting anything without example/access to the code might misguide. I found a more general article about styling pages for printing using CSS on smashing magazine: https://www.smashingmagazine.com/2015/01/designing-for-print-with-css/. Maybe it will help you to adjust the print view.

#10

I think that we can close this topic as there is no reply for 2 weeks.

However, if there’s something you’d like to discuss @marc.proske, please create a new topic or send us an email at support@handsontable.com.

#11