Printing from an electronic logbook and traditional "paper" logbooks

A few months ago, I had a blog post about printing from MyFlightbook.

I had a Facebook conversation with a pilot today about why sometimes the per-page subtotals spill onto an additional page, consuming extra paper and occasionally leaving swaths of blank space on a page.

The question he asked was twofold: (a) why do I have the extra clutter of having additional category/class rows in the per-page subtotals, and (b) why can't I reliably keep a page's flights the subtotals for that page actually on a single printed page?  Specifically: "is the challenge regarding the coding of it?"

It's a perfectly legitimate question, and I realize my earlier post may not have sufficiently or clearly explained that, so I decided to dive in and answer in a bit more depth, which I'm reproducing below (lightly edited for clarity, to remove typos, and to translate from Facebook format):

First: why do my per-page subtotals subdivide by category/class?

Paper logbooks put each category/class into their own columns. This makes sense for exactly one reason - allowing you to compute category/class totals by hand. You can't do (easy) hand summation if category/classes are co-mingled in a single column. (Of course, computers don't care, that works just fine).

But there are two really bad tradeoffs for doing this: one is that columns don't scale well at all. So if you've got some ASEL time, some ASES time, some AMEL time, some glider time, some balloon time, some helicopter time, ...well, now when you go to print you have a 2-dimensional problem: each flight of your logbook needs to spill over across two horizontal pages (Or, columns need to narrow, which means everything needs to grow vertically and becomes really hard to read!!!).

The other really bad tradeoff is that it effectively means you need to limit the number of category/classes you support. This is why most paper logbooks are focused on JUST airplanes, or JUST gliders, and might have only one column for "other".

Those are bad - but necessary - tradeoffs in the paper world. But in the electronic world, these are simply terrible tradeoffs, especially since the exact problem that they're trying to solve (aiding human computation of totals) doesn't exist once computers are can do the math.

So if you did this in the electronic world, you'd get all the downside with none of the upside. That seems utterly ridiculous.

For this reason, I striped the per-page subtotals by category/class because adding rows works great (stays within the flow of reading from page to page) but adding columns doesn't.

So - why can't I do a better job of keeping things on a page, from occasionally spilling on a page?

I'll back up for a moment to another problem with paper: the form in the paper world is sized and printed before any content is added. I.e., the layout is fixed. So you have three choices when you fill in oversized data:

• You can "spill over", with one flight spanning more than one row of the paper page;
• You can "clip" your data - stopping when you hit the boundary of the flight's row and discarding what didn't fit;
• Or you can "shrink to fit", making the text smaller and smaller until it fits the allotted space.

All of those are truly terrible solutions, but with paper, they are the only options; you can only choose the least evil.

In the electronic world, however, that ridiculous constraint is removed: the row can shrink or grow to accommodate the data. i.e., each row can be a unique height that is appropriate for the data contained therein.

So...your question was "is the challenge regarding the coding of it." At one level, the answer is "no, it's not complicated".

What you would do in this scenario is add a flight to the page, compute the subtotals for the page,  add those subtotals to the page as well, and see if it fits. Then repeat for the next flight. If the flight you add causes the subtotals to spill to the next page, then back up to where you were just prior to adding the flight, finish off that page, then start a new page with the new flight. There are a few other issues, but at the core, that's the process and it's straightforward.

Here we get to an architectural issue. MyFlightbook uses an abstract layout methodology (HTML). So I say "here's a row of a table; it has these cells and each cell contains this text." MyFlightbook doesn't know anything about fonts, font sizes, pixels, word wrapping, page margins, page dimensions, screen or printer resolutions, or a whole slew of other things that are required in order to figure out what to draw on a page. That is all handled on the web by the browser (which takes the HTML and converts it into stuff on a screen), or by the PDF generator that I use, which does the exact same thing as a browser, except that instead of drawing on the screen it draws into a PDF file.

So I can't implement the algorithm I described above (add a row, see if it fits, if not, start a new page). That is, I have to render the entire page in HTML, and THEN either send it to you so that your browser can render it to the screen, or send it to the PDF generator so that I can send you a PDF file. There's no ability to have the back-and-forth interaction that such an algorithm requires.

The ONLY way to solve that is to build an entire rendering engine - something that DOES know how to measure things, lay them out on the screen, perform word wrapping, make tables fit their contents (itself actually a really hard problem). I.e., I would quite literally need to re-implement most of what a browser does.

But I think about the herculean effort that represents (much bigger than all of MyFlightbook combined - and MyFlightbook actually isn't a small piece of code!), and I step back and ask "what problem would this solve?"

The answer is simple: per-page subtotals. That's it. No other purpose whatsoever is served.

And what makes per-page subtotals so important? Paper tradition. Per page subtotals serve exactly one purpose: if you're doing manual computation, you don't want to go back to the start of your logbook every time you want to compute your totals; that's ridiculous with a pen and paper. But in the electronic world, computers don't complain about doing that. So per-page sub-totals are an insane holdover from paper-and-pencil human arithmetic. Why on earth let an artifact of the 14th century drive such a massive software undertaking?

So in summary, the correct answer to the question "is the challenge regarding the coding of it", the answer is "yes. It would require literally thousands of man years of effort to actually solve an obsolete problem."

My suggestion? Turn off per-page subtotals. They are truly utterly pointless. "Continuous" mode will make much more efficient use of your paper and will still get the math right because computers don't make math mistakes. And your pagination will work great.

Update: since writing this blog post, I have added a hack to allow for better pagination.  If you have, say, 10 flights per page and on one page the 9th and 10th flights are "spilling over" onto a new page, you can edit the 8th flight on that page to include "///---" at the end of the comments.  The "///" and everything after is not included in the print layout, but it will force a new page after that flight, so what had been the 9th and 10th flight alone on a new page in this example would now be the 1st and 2nd flight on a new 10-flight page.