qlik-oss / sn-table

table supernova for nebula.js
https://qlik.dev/libraries-and-tools/visualizations/table
MIT License
6 stars 14 forks source link

feat: support multi-page pdf by rendering rows as a single-line row #1060

Closed quanho closed 1 year ago

quanho commented 1 year ago

The main idea is that: First client side of the reporting service will send a request to ask sn-table to get number of visible rows for a pdf page. This can be done by using virtualized table (or may be pagination table) to render rows as a single-line row. After reporting service get the answer from the sn-table, it will generate an array of requests, each of which is to ask sn-table to render a number of rows (as single-line row) for a pdf page.

haxxmaxx commented 1 year ago

The main idea is that: First client side of the reporting service will send a request to ask sn-table to get number of visible rows for a pdf page. This can be done by using virtualized table (or may be pagination table) to render rows as a single-line row.

If you know the height of the PDF and the font size, you can calculate how many rows will fit, as long as you sticking to one line per cell. The paddings, border widths etc are all constant. And the line height is 4/3. So if you take the font size * 4/3 + padding + border height you get the height of a cell

EDIT: I guess if we want to be able to support more than one line later, I see the point of doing the estimation from the start

quanho commented 1 year ago

The main idea is that: First client side of the reporting service will send a request to ask sn-table to get number of visible rows for a pdf page. This can be done by using virtualized table (or may be pagination table) to render rows as a single-line row.

If you know the height of the PDF and the font size, you can calculate how many rows will fit, as long as you sticking to one line per cell. The paddings, border widths etc are all constant. And the line height is 4/3. So if you take the font size * 4/3 + padding + border height you get the height of a cell

EDIT: I guess if we want to be able to support more than one line later, I see the point of doing the estimation from the start

So you mean reporting service needs to send a request to sn-table to ask for font family, font size, padding, etc. to calculate. To avoid to ask many things like that and then do calculation, reporting service only need to ask for the row heights and it should don't care how to calculate the row height. Calculating the row height should be in sn-table.

haxxmaxx commented 1 year ago

So you mean reporting service needs to send a request to sn-table to ask for font family, font size, padding, etc. to calculate. To avoid to ask many things like that and then do calculation, reporting service only need to ask for the row heights and it should don't care how to calculate the row height. Calculating the row height should be in sn-table.

No not really. My point was mainly that you can calculate it exactly, I understood it as the plan was to estimate it.