Dive Table printing

[Dirk Hohndel]

Lutz Vieweg <lvml at 5t9.de> writes:

> On 08/20/2012 07:53 PM, Dirk Hohndel wrote:
>> May I suggest that we allow "formats" that describe the output?
>
> What do you mean when you say "formats" - sprintf-style "%"-sequences,
> XSLT, CSS...?
>
>> This way people could design the print output that they want.
>
> I guess that every formatting method that requires one to
> wield a keyboard for design would keep 99% of potential users
> from acutally doing so. (Not that I would complain, I'm just
> trying to help subsurface to achieve market leadership :-)

Oh, I didn't express myself clearly then.

I want a number of these formats bundled with subsurface, with the
option for people to add new formats and just contribute them back.
Especially if we just use HTML/CSS there are lots of people out there
who have the skills to do so - many more than there are who could
rewrite the C code...

>> It seems that there
>> are strong regional preferences (page size, amount of information
>> displayed, number of dives per page).
>
> Yes.
>
>> Other dive log software appears to
>> simply allow the users to define the layout in some form and then parse
>> that when printing.
>
> I have to admit my experience so far is limited to SDM, never used
> others before. And SDM offers practically no options besides "index"
> vs. "one dive per page".
>
>> Hey, we could output in HTML and allow CSS files to render the output...
>
> The amount of people capable of writing CSS is not that high, either.
> But HTML may still be a viable alternative, as many browsers do at
> least implement some options for printing. Would be difficult to enable
> or disable "columns" in the table, though.

Again - the assumption would be that we have a number of formats
shipping with subsurface:

6-up with profiles on Letter
6-up with profiles on A4
4-up with profiles on A5
2-up with profiles on A5
table no profiles on Letter
table no profiles on A4
table no profiles on A5

You get the idea.

/D