Sunday, September 16, 2018

Printing from electronic logbooks

The "paperless" society has never actually arrived.  Despite the obvious superiority (at least in my opinion) of electronic logbooks on every dimension, old habits die hard, not just among pilots but also among airlines and regulators: lots of people still want paper renditions of their logbooks, whether as a backup to electronic, or for sharing with potential employers or regulators.

MyFlightbook has fairly rich printing support.  If you go to the Print View (under the Logbook tab on the website), you can see a printer-optimized version of your logbook, including a summary of your totals and your endorsements. 

There are two ways you can print.  You can simply print from the browser, or you can download a PDF.  If you choose to do the former, don't worry, the web-specific items (page header, and the user interface for configuring your print) will not show up on the printed page.  However, different browsers implement the HTML specification for printing a bit differently, so you may see some differences from browser to browser (one example is whether or not the table column headers are repeated on each page).  If you download the PDF, of course, this is not an issue, and better still, you don't have to kill trees - you can back it up or email as you like without ever putting ink to paper.

MyFlightbook supports an array of different style layouts that mimic common paper layouts around the world.  Some of these are rather prescriptive (e.g., EASA), specifying exactly which columns must be present, what order they must be in, etc.  Others are not so much.  This is an area where I think the FAA has overall been quite enlightened: they specify what they want you to log, but do not specify the manner in which it is logged.  This flexibility does show itself in some of the layouts, where you can add additional columns not otherwise present in the layout, or include pictures from flights; neither of these are possible with the more prescriptive layouts.

In addition to choosing a layout, MyFlightbook supports quite a few options around printing.
  • You can exclude properties that aren't relevant for your printout, to reduce clutter.  E.g., if you're applying for a job, you may not want to include details like your fuel cost.  You can also choose how to separate properties when a flight has multiple properties - e.g., putting each on a line, or separating them with a comma.
  • As mentioned above, depending on the layout, you can choose up to 4 additional columns.  This is useful, for example, if you want to call out turbine or complex time or a specific property.  It is only available for the layouts which are not prescriptive, however.
  • Also dependent on the layout, you can choose to include any pictures that you have saved with your flights.  You probably don't need that when applying for an airline job, but if you're flying for fun, you absolutely should have it; after all, a logbook isn't just a record keeping requirement, it's a place for memories!
  • You can select an approximate number of flights to display per page; subtotals will be inserted after that many flights.  This is only approximate, however, for reasons discussed below.
  • You can choose which criteria to print out (e.g., only a specific date range, or only flights in a glider), and whether to include totals and endorsements.  Note that if you have uploaded PDF endorsements, you will need to print those out separately; MyFlightbook cannot embed one PDF into another, either as a file or on the printed page.
  • If you are downloading a PDF file, you can specify the orientation (landscape generally works best), the page size, and any margins.
It is important to note, however, that electronic logbooks and paper are inherently different, and as a result you will never have pixel perfect fidelity between the two.  (Warning: a bit of my personal bias is about to be exposed).

The first difference is per-page subtotals (see the bottom highlighted portion in the image below).  All paper logbooks have these, but the reason for it is utterly obsolete and pointless in an electronic world: human computation.  Per-page subtotals allow you to add up your totals by hand without having to go back to the start of your logbook.  It's entirely about making pencil-and-paper computation tractable.  Of course, in the electronic world, computers don't mind going back to the start of the logbook for every computation, and they don't make math errors.  And in MyFlightbook, totals are shown at the end of all of the flights.  So there is really absolutely no good reason for this other than as an aid to human computation.

Some people like per-page subtotals even in the electronic world because they also keep a paper logbook and it allows them to double-check their paper backup; while that is true, it doesn't change the fact that it's still about human computation.  They could still keep the paper logbook and not bother with the per-page subtotals; if it's a backup, having the individual flights is enough - you could delay computing any totals by hand indefinitely unless/until the backup becomes necessary.

I've also heard some people say that airlines/etc. want per-page subtotals.  This may be true, probably because it's what they're used to.  But it really isn't necessary.  After all, can you imagine a hiring manager at an airline double checking (by hand!) the math on something that was clearly computer generated?  And if they don't trust computer generated totals, why would they trust the subtotals?  If they want to verify the totals, it would make more sense to send them the PDF for human readability, and the spreadsheet backup; then they could use the spreadsheet to verify any math (assuming that they trust Excel's math skills).

Of course, as I said above, old habits die hard, so MyFlightbook supports per-page subtotals.

A page from my old paper logbook - note the percentage of the page devoted to human computation!

Another difference between the printed page and an electronic logbook is that paper logbooks are generally designed for a certain kind of flying and don't scale well beyond that.  In particular, most logbooks have a column for SEL Airplane, MEL Airplane, and maybe one or two columns for other category/classes of flying (glider, helicopter, etc.)  As with per-page-subtotals, this is also utterly obsolete and pointless: the reason for independent columns for category/class - which is, of course, completely determined by the aircraft column - is (you guessed it) to aid in human computation of these subtotals.  Alas: if humans aren't doing the math, then there's no need for this column. 

But if pointless redundancy in the columns weren't bad enough, this paper artifact suffers two additional sins.  One is that it's limited.  E.g., I personally have ratings for SEL, SES, and MEL aircraft, but I have also taken a glider lesson and a helicopter lesson.  In a paper layout, one of those latter two has to give; there just aren't enough columns to handle that. 

Sure, you could add yet another column, but that gets to the second "sin": of all the real estate on the printed page, horizontal (i.e., columns) is the most precious.  That is because printouts are meant to be read linearly - from top to bottom.  Adding new flights and spilling over onto a new page as a result is no problem; it's just a new page.  But adding new columns means you either have to shrink everything to fit (making it hard to read), or spill out to a new page *horizontally*, which means now you have to read in two dimensions: paging from left-to-right to view all of the columns, and then paging top-to-bottom to view all of the flights.

This is (one) reason that in the paper world glider logbooks and military logbooks generally look different from general aviation logbook. But in the electronic world, you can accommodate all of this without needing new columns - or (as I've done), by supporting multiple layouts and a few optional columns.

The third difference is the layout model.  A paper logbook has a fixed form; you can shrink your handwriting to fit into the row, or you can spill from one row into the next, using multiple rows for a single entry.  Obviously, this is because paper is inherently inflexible: the boundaries of the printed form must be created before any content.  In the electronic world, however, this is not the case.  The row, therefore, grows or shrinks to fit all of the necessary data. 

This is the reason that choosing a specific number of flights per page is at best approximate.  If a given flight has a lot of data, it can easily cause some flights to spill over onto the next page (particularly if the selected paper size is small).

There's actually a more subtle reason why the flights-per-page is approximate: printing engines don't know how to render per-page subtotals; MyFlightbook has to do that before it sends it for rendering (where everything gets measured using the correct fonts and laid out on the printed page).  So MyFlightbook fills in the requested number of rows, then adds the per-page subtotals, and only then sends it to be rendered.  Which means that MyFlightbook can only guess whether or not they will fit.  MyFlightbook has some heuristics so that it automatically reduces the number of flights on a page when it sees what appear to be "tall" flight entries, but because it doesn't have a rendering engine, these heuristics are only approximate.

There are only two ways to solve this.  One is if MyFlightbook could try out a particular pagination, send it to the renderer, then get it back from the renderer, and make adjustments, and repeat until a good solution is found.  But this isn't possible because the renderer doesn't give MyFlightbook anything that can be consumed in this way: the layout is either done by your browser (when you print from there), which means it is on your computer and is sent straight to the printer without a chance to go back to the MyFlightbook server, or it is done in the PDF engine on the server, but the PDF it produces is essentially opaque.

The other way would be for MyFlightbook to do its own rendering, where it would add flights to a page one-by-one, computing subtotals totals and seeing if it all fits, then adding another flight until they don't fit any more, and then moving on to the next page.  The short answer is that this is a very hard problem to solve correctly - it basically requires writing my own browser.

For these reasons, I actually generally suggest using "Continuous" rather than targeting a fixed number of flights per page. Since there are no subtotals to compute, all of the data can be computed up front and pagination can be performed by the printing engine.  This setting also uses paper wisely, since it fits as many as possible on a page, without splitting a single flight across pages (unless that flight is so big that it literally will not fit by itself on a single page).  You give up per-page subtotals when you do this, but hey: it's generated by a computer, so as I asserted above, you don't really need per-page subtotals!!!

I'll finish this with three tips/tricks that can help your printed logbook look its best:
  • If your comments on your flights are long, you can use "///" within the remarks to indicate that everything that follows should not be printed.  E.g., a comment that is "Print this /// not this" will print as simply "Print this".
  • Building on that, if you use "///--" it will force a the next flight to begin a new page.  So if you are doing, say, 10 flights per page and flights 9 and 10 are spilling onto a new page by themselves, you can edit flight 8 to have "///--" and that will force it to be the last flight on the page; the 2 flights that had been alone on a page will now be the first two flights of the next 10-flight page.
  • You can use simple markdown in your comments on flights for emphasis or italics.  Specifically put asterisks around text to make it bold and underscores (_) to make it italic.  E.g., *bold* or _italic_ will show up as bold or italic.