Grab-bag of todo items and buglets from book-printing WIP demo.

Created by: kfogel

This is a punch-list of all the various things that remain to be done / fixed in book printing, based on our meetings of Dec 15th and Dec 23rd. Note that Mike's work is happening on the feat/print-pdf branch.

Our initial testing used proposals from the data that goes with the torque-sites repository, so this ticket will refer to "proposals", meaning essentially wiki pages.

On the initial Book Creation page (the page you see when you first start assembling a book):

• Remove the two notices (one with exclamation point in red icon, the other with i-in-blue-circle). They appear both here and on the Manage Book page.

On the tops of proposals during Book Creation (i.e., during proposal selection):

• Change the wording to say "items" instead of "pages", because "pages" is a confusingly overloaded term given that it can refer to proposals (i.e., wiki pages, which is what is meant here) or to pages in a PDF (which is not what is meant here, so when the middle bit says "Show book (5 pages)" that is a wildly misleading statement that almost every user is going to misunderstand :-) ).
• Remove the "Suggested Pages" option and its magic wand.

On the "Manage Book" page (the final stop before you create the PDF):

• Remove the two notices (one with exclamation point in red icon, the other with i-in-blue-circle). They appear both here and on the initial Book Creation page.
• Remove the PediaPress link
• Title and Subtitle need to work.
• Paper choice should default to US Letter.
• Get rid of the Columns option.

On the post-submission page:

• Make the progress meter work.
• Auto-refresh to show progress.
• Remove extraneous text and links (there's some note on the page about some help on can read to learn how to make better PDFs or something -- whatever it is, if it's not essential to the function of the page, let's remove it).

During the rendering step:

• Proposals whose titles have commas in them break the system at render time, causing a traceback, because comma is used as a separator in value passed for the --urls option to the command-line program we're invoking as a subprocess to grab the wiki pages and render them. (At least, that's @kfogel's understanding from talking to @Nolski.) Solution: make a true escape-sequence syntax for parsing the separator within that option's value, so that proposals can have any character in their names and not have to worry. For reproduction purposes: the ID numbers of the specific proposals that demonstrated this bug were (in this order in the rendered PDF): 78, 3711, 211, 3341, 2410.

In rendered PDF:

• TOC is currently in monospaced font, to make width calculations easier. That's okay for now, but eventually we should have it be in the same font as everything else, and that's probably not going to be fixed-width.
• TOC has right-side numbers alignment issue. It seems like there's a calculation error that leads to page numbers that are single digits or "10" are one space (one dot, I guess, but in fixed-width font it doesn't matter what the charcter is) too far to the right.
• In the TOC, should we include proposals' review numbers (their identifying numbers)? Has LFC expressed a preference about this? We should ask them. We do show those numbers in TOCs in the browser, but that doesn't necessarily carry over to PDF books of course. (Answer: for now, no. We might revisit this later.)
• Page numbering within the PDF still needs to be implemented. A thought from Karl: let's put page numbers in the lower-left and lower-right corners. That way they'll be conveniently located whether someone prints out two-sided or one-sided.
• Within each proposal, the inline per-proposal table of contents should go away.
• Some Torque proposal pages have a weird <li class="mw-empty-elt"></li> empty and invisible bullet point in some of their lists (e.g., in proposal 3348, the last three of the five bullet points in the list in the "Key Partners" section are of this invisible kind). While those bullet points are not rendered by the browser to the user, they are rendered for printing, which means they show up as empty bullet points in the PDF. So whatever style-sensitivities we're coding into our printing-by-rendering-via-headless-browser method, here's another thing it needs to take into account: those bullet points should invisible in the PDF as well as in the browser. (We don't know what purpose they serve in the wiki page, but for now let's just take them as a given and handle them correctly.)
• Double-check that "LFC Analysis" pages render well when printed, particularly in Lone Star competition. (@frankduncan can help find some if you need.)