[PULL REQUEST] table print implementation

[Tomaz Canabrava]

On Thu, Jul 11, 2013 at 9:03 AM, Lubomir I. Ivanov <neolit123 at gmail.com>wrote:

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

Wait, Wait. :)

Take a look at here before continuing;
http://www.gitorious.org/grantlee/pages/Home

\o/




>
> lubomir
> --
> _______________________________________________
> subsurface mailing list
> subsurface at hohndel.org
> http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20130711/1d17172f/attachment.html>