Print multiple recordsheets to the same file as multiple pages?

[mhjacks]

Occasionally I like to print PDFs of recordsheets, to validate how things will look before committing to paper. It seems that MML outputs a new job for every page, instead of generating the whole print job and outputting that to a file.

On Linux, printing to cups-pdf doesn't give you the option to save each output job to a new file, as the Microsoft Print to PDF option does on Windows. I was wondering what was happening to the rest of my company, since no matter how many units were in my MUL, there was only one character sheet.

Still, I would prefer a single file with a bunch of character sheets, as I can be selective about which units I print from PDF inside a PDF viewer.

[arlith]

You're right, and I noticed this while working on warships. I've got an uncommitted fix for it, but I haven't had time to update all of the printing classes yet.

[mhjacks]

What needs to be done? I could take a swipe at it and submit a PR.

[arlith]

Here's the diff. You won't have the PrintWarship class unless you checkout the printingWork branch, but from what I remember all of the Print<X> classes are basically copy/pastes of each other.

What you need to pay attention to are:
https://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html
https://docs.oracle.com/javase/8/docs/api/index.html?java/awt/print/Printable.html
http://docs.oracle.com/javase/7/docs/api/java/awt/print/Pageable.html

And here's some example code with pagination: https://docs.oracle.com/javase/tutorial/2d/printing/examples/PaginationExample.java

I think this fix is basically done, except propagating it to all of the other classes. I wanted to finish the Warship printing changes, then make this fix as a separate branch, but I haven't gotten back to warship printing yet.

print.txt

[mhjacks]

OK, let me have a go at this. Thanks!

[mhjacks]

OK, I've looked at the code a bit, and I'm wondering...will this approach fix the underlying problem, if the MUL (for example) to be printed contains different types of units? (e.g. Tanks, Mechs, BattleArmor)? If I read it correctly, the print job size will be the number of units of that type to be printed, as the master list is compiled in UnitPrintManager.java. Would it help to set the unknown number of pages constant? I'm still a little shaky about the semantics of print jobs and the master print job.

[arlith]

I'd have to go back and review the documentation, but I think you're right. I didn't consider this because I only ever wrote the code to handle one unit type, but if you've got multiple unit types, there needs to be some mechanism to know the total number of units to print, and also where they are in the process. Additionally, it would probably be good to allow units to potentially have multiple pages (there's at least one official Warships RS that has two pages....).

None of that seems particularly complicated to add, you just need the methods to compute that information (potentially a static int getNumPages(Entity), then total up the number of pages, and pass that information in. You may also need to know the starting page too.

[neoancient]

I forgot where I had seen this conversation. When I couldn't find it on Slack I just went ahead and implemented this, then just before committing I checked to see if there was an issue open, and here was the conversation I was looking for.

I used the Book class, which is a simple implementation of the Pageable interface. You use it by appending Printable objects then call PrintJob.setPageable(Book). Book.append() has an optional parameter that allows you to allot multiple pages to a Printable when adding it, which would allow multi-page record sheets. If you passed the current page count (Book.getNumberOfPages()) as a parameter to PrintWarship() it would be able to compare the pageIndex passed to print() to determine which page of the record sheet is being requested.

[mhjacks]

No sweat. I haven't had as much time IRL to work on this as I'd hoped. I'm excited to see this implemented!

[neoancient]

Implemented in 1b61a11