We are in the final stages of our digital production of The Circular Staircase – the end is nigh!
But we had some questions about how we would be able to produce both a high-quality and stylized print and ebook version of our epub file:
How do we add page numbers and page headers?
How do we get it into facing pages/book format?
John came up with a great solution! There is in fact a separate print typesetting package, but we need to clarify whether its affiliated with PanDocs or Gitit. Bottom line is it’s a completely different process, but it will actually end up being two different versions of the same file. Essentially, it will be one wiki full of files that will go into two paths. We do all our editorial for the digital version of the book on Sigil, and few modifications will be made in the typesetting package for the print copy.
Does the file automatically add the title at the top of the page and show you your progress (page numbers)?
Through Readium and testing out the epub file on a kobo reader, we saw that it does in fact automatically show your file information and reading progress.
How do we add margins, indents, etc – This was very straightforward. All we needed to do was modify styles on a CSS. This involved research online to find the appropriate code, and a ton of experimentation, but it all got ironed out with time and patience.
We decided to group the chapters in six parts in order to speed up the exporting process on Gitit. We initially hoped to do three parts, but after some experimenting, we realized that there is a word limit for each page on Gitit, so we had to settle for dividing the book into six parts – still much more convenient than repeating the process 34 times! Now came the tricky part – getting our heads wrapped around what was actually happening to our edited files on Gitit and how that would end up as a book. The following steps (described to us in very clear detail by John) is a great guide to getting a cloned version of our files from Gitit, and creating a master copy in a repository that we can work from and synchronize with for our different files that can eventually be published:
1. YOU NEED GIT – Download it.
The repository with all our files wiki are in a central server – this maintains the version control. So the wiki we were using sits on top of the repository and that’s where our structural edit was done.
2. Clone the repository on remote computers to synchronize with master editorial copy – digital and print comes from our clone (production stage)
3. To clone: Make a folder in our laptop to house everything
Install Git – get clone from ssh://email@example.com/home/jmax/mywiki/wikidata/
4. Git pull will sync our files with the repository
5. Pandoc will consolidate, compile and order the files.
First hiccup: We had issues getting Pandoc to compile all our pages in Step 5. The problem was we missed a step, or took another route rather, and ended up exporting the parts individually into epub files, instead of taking ALL the wiki pages and converting them into ONE single epub file. So essentially, we were making more work for ourselves. What we had to end up doing is go back into Pandocs and using the following command:
Pandoc cover\ page.page Page\ 1.page ……. Page\ 24.page –t –o book.epub
This worked, but it only transferred over Chapters 1-6. The problem was, the other chapters weren’t broken into separate pages because we hadn’t synchronized with our master copy. So after using Gitpull again, that slightly fixed the problem. We then hit our second problem: we didn’t have separate parts, which were our first level heads in our wiki. Easy fix, we just had to command pandocs to pull these headings from the wiki as well.
We started to see the value of pandocs in the expediency of the publishing process. Sure, it is difficult to see how the epub file would be shaped purely going on commands that we read about in pandoc documentation. But once we mastered our style sheet and had a solid idea about what instructions we wanted to send out to modify our file, it took literally 2 seconds to synchronize with the master copy where editorial is done, and get the compiled files in book ready form.
Then we could open this in Sigil to see how our style sheet worked with the text from here. There were some troubles compiling our style sheet – it was difficult figuring out line breaks and getting used to the consistency of writing the code. We also hit a road bump when getting the first paragraph flush left, but we went into the CSS and grouped the paragraph with the chapter heading (h2), and after some experimentation with margin values, we got it working! The universal search and replace was our best friend when going into the html, changing heading names to correlate with the CSS. It was fun playing around with different styles, inserting images, adding padding to our headings, adding margins and increasing the line-height for added readability on e-readers. This probably could have been avoided if we had done more editorial changes in the wiki before exporting through pandocs. We ended up having to go back and forth between the epub file and the wiki to make changes to the text, which was laborious.
For future reference, a better series of events in using the Gitit/Pandocs combination to publish a book in digital and print form would be:
1. Upload your text file into a reasonable amount of pages in the wiki.
2. Use markdown to add basic formatting to the text: Heading levels, indentations, smart quotes, em dashes,etc.
3. Use Git to clone your pages on the wiki.
4. Make a folder in your laptop to house the pages.
5. Use pandocs to take all the pages in the wiki and compile them into ONE epub file.
6. Add your style sheet to the epub file in the command screen of pandocs.
This is a majorly simplified guide to using this method, but it gives you a general idea of how well this method works for version control and how useful it is when you have numerous users working on the same file.
Further significant problems we encountered
We encountered another problem when exporting files from Gitit. We issued a command to separate each chapter (that began with a second-level header) into its own file. However, due to a character limit in Gitit, we had to separate the book into several parts. And for some mysterious reason, each chapter that began each part was included in the file for the chapter preceding it instead of being placed in its own individual file. For example, Chapter 8 began Part 2, but the text for Chapter 8 was included in one file with Chapter 7. To resolve this issue, we manually extracted the text and inserted the chapters into their own files, and renamed them.
Our most persistent problem was the Table of Contents, which initially generated with some of the chapters included in one file. Thus, the target links pointed to the wrong file. But after we selected the “tools” section of the toolbar and generated a new ToC based on our updated file, our new ToC reflected the proper changes with proper target links.
Readium display vs. Kobo display
Stylistic appearances like fonts don’t appear consistently for each medium. On the Kobo reader, images like our thumbprint marker don’t appear as well as the line height spaces we specified in CSS. However, on Readium, the images do appear and formatted correctly with regards to our stylesheet.