[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:
>>
>> nr,15|divemaster,30|location,50|gps,15
>> 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
> generic
>

ah, i see. well, we still would need to parse "dive" specific
variables inserted in whatever format exposed to the user.
<table><th>$cyl_gasmix</th></table>

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.
>
> Why?

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
subset knowledge.
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?

lubomir
--


More information about the subsurface mailing list