Typesetting n-up documents

[thinlines]

Here's a question I originally asked on Gitter:

Is there a class or package that enables n-up output? I'm an ESL teacher and I print handouts on smaller size paper to save resources. Currently I just set papersize=a7, etc. and do it manually from Adobe Acrobat print options, but Acrobat adds extra margin around each page, so things can be difficult at the paper cutter.

---

nphyx and @Omikhleia were helpful in making some different suggestions, including post-processing with pdfjam, writing a class with a custom page layout, and writing a custom outputter. #1515 was also mentioned. If I am able to come up with a solution, I will post it here. Thanks for everyone's help!

[thinlines]

For now, I have solved my problem through the printer options. It offers a "2-on-1" or (n-on-1) option for printing, and it solves the extra margin problem I mentioned with Acrobat. The only slight issue is that the printer I have can't print on the outside 5mm of the page, so some extra trimming is necessary, but this solves my problem for now.

BTW if it helps anyone, I wrote a command that repeats a given variable on n number of pages. I'll leave it here in case it's useful for someone.

  self:registerCommand("repeatpage", function(options, content)
    limit = tonumber(options.n) or 2
    for i = 1, limit do
      if options.cmd then
        SILE.call(options.cmd)
      else
        SILE.process(content)
      end
      if i < limit then SILE.call("eject") end
    end
  end, "Repeat a page's content")

[Omikhleia]

Sorry for not having commented earlier, I have been quite busy...
As mentioned during the original exchange on Gitter, I considered two possible ways.

1. A first idea is to use a modified outputter which keeps track of the pages and assembles them differently. I did a quick and dirty experiment by just modifying the outputters/libtextpdf.lua "outputter" for 2-up printing, doubling the papersize. Here is the file, renamed so as to be allowed here: libtexpdf_modified.txt
   It works (e.g. processing the full SILE manual, which is in A4 (untouched), you now get you 2-up printing on A3... But it's quick and dirty in the sense that I just replaced the outputter, so now my SILE is always outputting 2-up: if we wanted to do the things more cleanly, things then get a bit more tricky: we could refactoring this version as a "new outputter"¹ that can be selected with the -b option on the command line; or merge it with the standard version but use options for triggering the expected output².
   However correctly implemented, this method has pros and cons. Without being necessarily exhaustive:

   • Pros
     • It's a single compilation pass from the input source to the output PDF
     • PDF bookmarks (outline), internal links (annotations) all work.
     • Images and fonts are embedded only once, etc. -- so the eventual file size is about the same.
   • Cons
     • It works only with ISO-like paper sizes, where doubling them still leads to a valid paper size (so one can go from a document in A5 to A4 2-up, but it's probably useless with non ISO paper sizes)

2. Another idea would be to follow the same path as pdfjam, that is to process the input to PDF, and then re-assemble it. Pdfjam is just a small shell script; (a) using a few tools (e.g. pdfinfo from poppler) to retrieve information from the PDF (metadata, number of page, etc.); (b) crafting a LaTeX document including the pages (via the pdfpages package for LaTeX), and finally (c) invoking LaTeX.
   Having to use poppler tools and LaTeX could be avoided in our case, obviously. We could also have this implemented in a script (I would suggest using Lua rather than a shell script, for even a better integration). It would (a) retrieve information from the PDF³; (b) craft a SILE document including all the pages⁴; and (c) finally invoke SILE.
   It would be quite a fun coding exercise! It has pros and cons too:

   • Cons
     • It's a two-pass solution (first generate your PDF, then re-assemble it)
     • Including each page separately as embedded PDF images might not be optimal (I have no idea how fonts and repeated images are then embedded, perhaps we get several copies of these? I dunno!)
     • PDF outlines and links might not work out-of-the-box...
   • Pros
     • It's a general PDF-to-PDF reassembling tool. A SILE-based pdfjam, for true. Pretty neat concept! And it could find other uses and draw attention on SILE...
     • We can do many more things that the previous solution, e.g.
       • rescale pages (so we are not limited to ISO-like formats)
       • rotate pages (so sheets can be folded for small booklets)
       • and even assemble pages in some other order (e.g. re-grouped as "quires" -- in older times, a then younger me had much fun doing A5 leaflets, at the time using the "quire" module from the TeX midnight collection, that I would print, fold in the middle and stapple together ^^

Footnotes

1. But some packages (pdf, url, rotate, etc.) currently check the outputter's name, so the ideal refactor needed for them to still work goes farther than just adding an ouputter. ↩

2. There is however no official way to pass options to outputters directly from the command line... and using a class option (that be passed with -O) is not perfect either, IMHO. ↩

3. Here we can perhaps avoid using poppler by extending our libtexpdf Lua wrapper, as it might have the needed methods, rather than using poppler? If impractical, we could also use the poppler library with our own Lua wrapper, to avoid invoking shell commands... ↩

4. Two considerations here: (1) If we do this in Lua, we could even avoid generating SIL code, we could even directly generate a SILE AST and stream all that to the engine (2) At this date, we might not have the strict equivalent of LaTeX's pdfpages package, but our image package supports including a PDF page as an image, so maybe it's actually sufficient for a start? ↩

[Omikhleia]

BTW, I do think these two ideas would be great to implement. Maybe this question should have been left unanswered :)

[thinlines]

Sorry, I have just seen your reply to my question. Here are my thoughts on the two methods you mention:

Modified outputter: My initial inclination is to prefer this method because it would be potentially easier for me to use in my case. I agree that class options might not be ideal, as I could imagine several things that could be configurable. Could this be implemented as a package? I don't know if packages can select or modify the outputter. From my perspective as a user, my main concern would be that the n-up could be set from within each document itself because I am running SILE from a build system.

A SILE "PDFJam": I agree that this could be very useful and that it would potentially give some good publicity for SILE. I think for my own use case, it wouldn't work well for me because of the two-pass problem. It's the same reason I didn't opt for PDFJam when looking to solve my issue.

Re: the "quires", I didn't know what these were called :) I recently put together a PDF of a stage play script my students wrote and I printed them as A5 booklets, folded and stapled together. I just used Adobe PDF because it has a print option for that, though.

Maybe this question should have been left unanswered :)

I closed it because I had found a solution to my problem. Should it be reopened? Is that possible? I will try and see if I can.