Printing Support - brainstorm.

Tomaz Canabrava tcanabrava at kde.org
Thu Jul 18 14:05:00 PDT 2013


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.


>
> that a good estimation can be made when deciding to shift rows and
> place headers on a new page.
>
> lubomir
> --


More information about the subsurface mailing list