Printing Support - brainstorm.

[Lubomir I. Ivanov]

On 19 July 2013 00:05, Tomaz Canabrava <tcanabrava at kde.org> wrote:
> On Thu, Jul 18, 2013 at 5:57 PM, Lubomir I. Ivanov <neolit123 at gmail.com> wrote:
>>
>> On 18 July 2013 23:16, Tomaz Canabrava <tcanabrava at kde.org> wrote:
>> >
>> >
>> > On Thu, Jul 18, 2013 at 5:14 PM, Tomaz Canabrava <tcanabrava at kde.org> wrote:
>> >>
>> >> Heya.
>> >>
>> >> let's brainstorm a bit. :)
>> >> The current way that lubomir programmed the Printing support seems to be a
>> >> no-go because it's damn-slow.
>> >> the problem seems to be with QTextDocument parsing of HTML, but if we use
>> >> QTextCursor to manipulate the QTextDocument, the time goes down from 15s to
>> >> 2, with is mostly-acceptable. *but* that broke CSS. I'v tried to follow Qt
>> >> guidelines on QTextDocument but that was unfruitfull - the doc seems to be
>> >> wrong there ( or I didn't understand what it was saying, and since english
>> >> is not my first language this is always a possibility. )
>> >>
>> >> So I researched a bit on how people do 'Table-based printing' and
>> >> discovered that they usually get a QTableView and send it to print, simple
>> >> as that. That however doesn
>> >
>> > Sorry - send it without finished. -
>> > that however doesn't do one thing well - correct table layouting per page,
>> > with a nice heading and such.
>> >
>> > But there is a digia website that explained how to do it in a good way:
>> > http://blog.qt.digia.com/blog/2012/08/24/qt-commercial-support-weekly-25-printing-large-tables-2/
>> >
>> > The full code is for commercial guests, but that already gave me a few hints
>> > on how to do.
>> >
>> > Lubomir, since you are the one that tackled single-handed the Printing
>> > issue, what do you think about the blog post that I pasted here?
>> >
>>
>> on a very quick scroll trough the post, so i may have missed something:
>>
>> if the entire hidden widget is "grabbed" into a pixmap and we have a
>> fixed size for header and data rows, the proposal seems "legit" and
>> easy if we know the page rectangle. i think, however one potential
>> issue occurs where rows will have variadic (or growable) size, as the
>> current QTextDocument solution supports! while the widget is converted
>> to a pixmap it may also be required to write a lookup table with all
>> row vertical offset indexes (i.e. at what offset each rows stars), so
>
>
> ui->tableWidget->rowHeight(r);
>
> we have the rowHeigth, passing the index.
>
>

ok, i see. also, can the rows auto-grow vertically in the widget for given data?
perhaps it will be best to pre-estimate/fill the entire table with
header rows at the exact page offsets and only then grab the widget to
a pixmap.

pseudo/untested:

insertDataRow(data);
currentHeight += tableWidget->rowHeight(tableWidget->rowCount - 1);
if (currentHeight > currentPage * pageHeight) {
    currentHeight -= tableWidget->rowHeight(tableWidget->rowCount - 1);
    revertLastDataRow();
    resizeRowBeforeToFitPageEnd(); // if needed. with ->setRowHeight(...)
    currentPage++;
    insertHeaderRow();
    currentHeight += tableWidget->rowHeight(tableWidget->rowCount - 1);
}

something in these lines should do...i'm not very familiar with the
table widget, but i can try taking a look at that "soon". if you have
some free time please go ahead.

lubomir
--