The making of a Cryptic Word Search - Part 4

Publishing our puzzles involves yet another aspect of our app. The goal is to create a PDF file that we can upload for publishing. We use Adobe InDesign, a layout program we’ve used for books since around 2005.

The more recent riddle books we’ve published under the Cloud Kingdom Games imprint, as well as all of Sudoku-USA’s Sudoku books have used InDesign. While the older books were generated with copy and paste, starting in 2005, we began using InDesign’s automation features.

The first, and most time consuming part for the books is creating the template document. This is essentially a desktop publishing document with the introduction, page numbering, chapter headers and what-not in place, together with essentially blank pages associated with templates known as ‘master pages’. We use two main ones, one for puzzle pages, where the word searches are placed, and another template for the answer pages.

To get the puzzles onto the pages, we make use of JavaScript, the same coding language used in just about every web site on the internet. InDesign can run JavaScript and so our app takes a puzzle and creates Typescript (a newer form of JavaScript) to tell InDesign how to publish the puzzles. Effectively, we tell InDesign to go to page xxx, find the spot on the page we want the puzzle to be on, then create the word grid. Then go to the spot for the answers and fill them in.

Our Cryptic Wordsearch #2 book’s script was about 13,000 lines long, only about 500 hundred of which were hand generated: the functions written to do the placement. The remaining lines of code were generated by our publishing app from other templates. For each puzzle, we generated a new “program” from the template which made a bunch of calls to functions, each of which was designed to do one particular part of the publishing process.

When the script finishes, we have a draft of the book. Yay! Except now we get to see what went wrong. The first draft is always fairly iffy. The templates for puzzles are generic, good for a puzzle of average size. If the puzzle is larger or the clues are too wordy, things don’t fit well and we often need to shrink or grow the space allocated for the puzzle, or perhaps change the font size for the answers, maybe make a column wider or … we play with the document until things look good. To make things even more fun, as a general rule, we try to make formatting changes only to the ‘base document’, the one with the layout, but empty space for the puzzles. So it’s an iterative process: run the script against the base document to make a draft, review the draft for problems (or just aesthetics), modify the base, run the script again. 

But then, sooner or later, it’s time to upload the PDF and discover we’ve overlooked something that the publisher (Amazon Create Space) doesn’t like about the PDF. A few years ago, their errors were something like ‘there are characters beyond the printable margin’, leading to the fun game of ‘guess what they’re thinking’. These days, they at least tell you what page the problem is on.

 

With the contents ready and a cover created, it’s time to publish!

An unhandled error has occurred. Reload 🗙