print layout

[Dirk Hohndel]

On Thu, 2013-10-17 at 16:04 +0200, Robert Helling wrote:
> On 16.10.2013, at 17:59, Dirk Hohndel <dirk at hohndel.org> wrote:
> 
> Hi everyone,
> 
> > I can look into it myself if I find time, but my todo list is rather long right now...
> 
> Regarding print templates:
> 
> I know you said this will not happen for version 4.x but I think I had some revelation this morning under the shower.
> 
> Our problem was that we cannot quite have html templates as the qt routines don't treat proper html and anything else would require us to write some non-trivial parser.
> 
> Well, there is a perfectly fine way to to describe page layouts for print in professional typesetting quality. It's called TeX. And of course we do not want to bundle subsurface with the myriad of files that a proper TeX system requires, so we don't want to use TeX for printing. 
> 
> But what we could to is export dives in TeX format (since that's a simple text file). So this could be used by the many users that already have a TeX system running (I consider it like divelogs.de or the webapp: to make use of this feature you need additional things like a divelogs.de account or an android smartphone).
> 
> Here are two patch files for a proof of concept: 
> 
> This adds an entry to the dive list context menu to export a dive as TeX. Right now it always exports to a file named dive.tex in the pwd (as well as writing the profile picture to profile.png).
> 
> If the user has a TeX system installed she can then run 
> 
> pdftex dive
> 
> to obtain a nice (I know, tastes differ…) printable file dive.pdf.
> 
> The cute thing is that this is realized as a template: In dive.tex the data only goes into a number of macro definitions, and then logbook style.tex is imported. The latter contains the actual layout. So we could have several such template files (according to personal taste) and this export works with each of them.
> 
> Obviously, this is only a proof of concept and far from complete (things like hard coded file names and only some of the fields of struct dive are represented since I stole this form my old dive log software). But please let me know what you think.

We briefly talked about this on IRC but I'll repeat it here - I admire
the spirit of it (and vaguely remember having used TeX 20 years ago in
university), but this is completely missing our target audience. 70% of
our users are on Windows, 15% on a Mac. Very few (if any) of them will
know how to get from TeX output to something that they can print. And
even the remaining 15% who appear to be on Linux - I would bet no more
than half of them would know what to do. If I go by the quality of end
user questions that we are getting, that may even be optimistic.

What we REALLY need (for Subsurface 7.8) is a visual layout editor so
people can just point and click to get the layout they want. For
Subsurface 4.0 I think we'll give them a fixed layout that does a
somewhat better job than what we have.

One idea that I pondered is to give them a menu that allows them to pair
down what they get - which allows for more Notes and less clutter.

Under the "1 / 2 / 6 dives per page" selection there's an "Advanced
Configuration" button that opens another menu. That menu offers
something like this (envision this done in a visually attractive manner)

"The following information is listed below the profile - the more
elements you pick, the less space will be left for the Notes"

x Location
x Date / Time
x Duration
x Max Depth
x Avg Depth
o Tank used
o Gas mix
o Gas used
o SAC rate
o Max CNS
o Fresh/saltwater
o Total weight
x Divemaster
x Buddy
o Suit
x Viz
x Rating
o Tags
x Notes

I'd suggest the x ones to be on my default, the others off.
And then we need our algorithm to try and fill these reasonably
intelligently into the space provided. Maybe we give an minimum width
for each of them and write an NP-complete algorithm that packs them
together in an ideal way. Or alternatively we could just group them
logically into lines and say we'll drop a line if none of the members
are there and we merge two lines if their combined minimum length is
still less than the space available in a line. That still means we could
get several lines that are only 2/3 used, but it's a start.

What do people think about that?

/D