[PULL REQUEST] table print implementation
Lubomir I. Ivanov
neolit123 at gmail.com
Thu Jul 11 05:03:42 PDT 2013
On 11 July 2013 14:49, Dirk Hohndel <dirk at hohndel.org> wrote:
> On Thu, 2013-07-11 at 14:28 +0300, Lubomir I. Ivanov wrote:
>> On 11 July 2013 13:56, Dirk Hohndel <dirk at hohndel.org> wrote:
>> >> the approach of doing the table print is by using the QTextDocument class
>> >> with HTML/CSS with table/tr/th tags. it allows some freedom of what can be done
>> >> in the table, but not as much as if you draw it manually with cairo/pango
>> >> or with QPainter and this HTML/CSS implementation REALLY is as subset.
>> >> but as you have already guessed it is much easier to maintain, which
>> >> perhaps can be seen in printlayout.cpp...
>> > I think I like this approach. If we do this right it should make it
>> > quite easy to support custom templates that users can create and share.
>> > I know that almost every country has their own preferred logbook format,
>> > and often even more than one. So having the ability for users who just
>> > know a bit of html/css to be able to contribute layouts would be a real
>> > strength for Subsurface...
>> i was thinking about designing a template based structure, where
>> programmatically the table columns can be preset.
>> this could be based on a custom format specified in the preferences
>> with a parseable string, for example:
>> would only create a table with these dive properties in columns with
>> certain width (name, %).
> This will work for the table, but what about the 6up, 4up, 2up, 1up
> layouts. You'll have to design a complex "language" to describe which
> element goes where... that's why I was hoping for something more
ah, i see. well, we still would need to parse "dive" specific
variables inserted in whatever format exposed to the user.
this might end up as being difficult, if we want it to be rendered at
least somehow decently.
looking forward to other opinions, as well..
>> the real problem that i've encountered is the limitation of the Qt
>> HTML/CSS subset..
>> a good example would be that the table border and color can only be
>> controlled via the <table> tag style and not from the inner <th>, <tr>
>> tags. and there are a lot of missing, common CSS properties which
>> means that users trying to create a style template will have to be
>> aware of the Qt specific limitations in this case otherwise their
>> style sheets will be broken.
> I'm sure those are documented somewhere. Right? Thiago?
> And then we can point users to that documentation. Still seems easier
> than creating a new description language that we need to parse.
>> the preferred columns to be printed is something that can be done at
>> this stage, but if we plan to allow table style mods (like colors) we
>> really need to 'sandbox' the user outside of the actual Qt CSS, with a
>> list print dialog options/controls i'd think.
CSS/HTML wise and like i said, i think the subset is way to limited to
be exposed to divelog users with some CSS knowledge, but no Qt CSS
personal opinion, of course...
>> >> it detects a new page by a rather expensive (i think) operation, but it seems
>> >> to work OK, so far.
>> > For 230 or so dives it easily took 13 seconds before the preview came
>> > up. That seems rather long :-)
>> i found reports on the web that QTextDocument is slow in general.
>> after each row added, the current algorithm requires passing a new
>> string to the QTextDocument object (with setHtml()) and then calling
>> pageCount() to determine if a new page has occurred. this is the only
>> way i found out how to do it so far, so that table headers are
>> inserted on that new page.
>> if someone has tips for a better solution i would be happy to apply it.
> Thiago, Tomaz, any suggestions?
i was reading on rendering to table widgets instead of a
QTextDocument, but it will be surprising if faster.
on the other hand it may allow better flexibility for style customization?
More information about the subsurface