Our First Week in Booktype – CoinFlip Publishing

In Answer to John’s Probing at Our Last Post:

CoinFlipLogo

Why We Chose CoinFlip Publishing:

In that first meeting we had thought to call our company Jabberwocky Press. However, there were other things to discuss, so having tentatively decided on a name we moved that to the back-burner while we tackled other considerations. One of these considerations was our decision-making policy. We chose to function as a majority consensus, but agreed that if we ever disagreed on decisions we would flip a coin. We figured that if things ever got heated, flipping a coin would save time, energy and relationships. At some point one of us said “CoinFlip Publishing” and someone responded, “I like that” and the name stuck. As an added benefit, by choosing a name that has to do with the company and how it functions rather than the chosen text for the assignment, we would thereby expand the potential of our company beyond the scope of this one book.

CoinFlip Publishing ran into some major issues with the BookType Software during this first week and have spent most of our time researching and attempting to resolve them.

The Major Issues:

The first stumbling block came in the nature of the software itself. The Demo version of BookType is public access, and without a private server or a paid version of the software, the Demo is the only option we seemed to have. The platform was optimized for multiple authors to collaborate on one book over a short period of time. This is a problem for us because without a private server, our book could potentially be edited or deleted by anyone also using BookType. It is also running from a public server that is frequently reset, and therefore, any books created through the Demo could be deleted.

Our next step was to ask John to load BookType onto a private server, which he did, but it was unstable.  He then reloaded the software onto the server in  a more secure fashion and we have been up and running since the evening of Friday the 13th.

Within the software itself we were confronted with our biggest stumbling block.  BookType promotes formless content, which means that the page is not constrained by margins, line spacing, or regular page break functions. BookType have adopted this policy because of the changing face of hardware and software interaction. As we move away from static webpages to dynamic ones that shift content dependent on the size of the device and screen being used, more web developers are abandoning the idea of margin constraints. BookType is applying this concept to the idea of ebooks and the inevitable shift in technology that will come with e-readers over the next few years. So, while BookType uses this dynamic, seamless style of publishing for e-books, the ability to constrain margins is essential for our print book.

Finally, also within the software, we are having a lot of issues with formatting. Our first attempt at flowing the text directly from the Gutenberg simple text file resulted in everything being set on a single line, no paragraphs or pages. We then figured out that if we first copy the text into a word processor, such as TextEdit, and then into BookType we are able to adjust the format, but will still have to manually adjust the text line by line. This is especially important as we attempt to create the look we want for the poems we intend to include. The formatting options that are availble directly in BookType are applied as the last step to publishing the book through the software. Instead of formatting the text as we flow it into the software, we must format as we export into a published format. Therefore we will need to publish to a print or epub file before we can see how it will look.

Some Resolutions to These Issues:

We came up with a way to include poetry in the manuscript while maintaining its format in spite of the formatting constraints of BookType. We will place the poems as image files and insert them into the book by treating these poems like we would images. BookType formatting is a major problem for prose let alone poetry so this will hopefully be a great help to us.

We also have decided on limiting the number of images for the book, there are 41 original illustrations in Alice’s Adventures in Wonderland and we would like to restrict that to one per chapter.

Finally we have decided on US Trade book size for printing.

NB: We are unsure of how the seamless style of the e-reader is going to affect the images, and now, the poetry that we are including in the edition. More on this as we press forward.

Questions Left With Us to Ponder:

1. How will photos look in ebook formatting? (Consider black & white, size, quality)

2. BookType has a page break function that does not work. How will we deal with this? Can we fix it with html? What other options do we have for this problem?

3. How will the ebook version look in different e-readers? (Kindle, iPad, Kobo, Sony eReader)

4. How can we utilize WordPress to create a promotional site for our company and for this project?

 

2 thoughts on “Our First Week in Booktype – CoinFlip Publishing

  1. JMax

    Good analysis and reportage of your progress.

    The problem you note…

    BookType promotes formless content, which means that the page is not constrained by margins, line spacing, or regular page break functions. BookType have adopted this policy because of the changing face of hardware and software interaction.

    is not specific to BookType at all; rather, it is a characteristic of web- and markup-based publishing systems generally. The notion of a page—and this of page breaks, margin widths, and so on—is a function of paper. Once we move beyond a paper-based publishing system, content either becomes page-less (aka “reflowable”) or at least notions like pagination and margins become relative at best, arbitrary at worst.

    One anchor, for reading experience at least, is the typographic convention that a line of text should not be more than about 60-70 characters long, lest the reader’s eye have trouble finding its way back to the start of the next. So designers of reading systems have looked to constraining the width of the text setting first, and then the size of the type, the relative size of the margins, and so forth as a function of that.

  2. JMax

    One more thought:

    Poetry as images? May I ask that you reconsider that? There are other ways to do it—which, no doubt, bring with them a host of headaches and hassles. But to set text in a image is to rob it of its very textuality. For starters, it is not searchable. Second, you lose the ability to re-style it (if you decide to change typefaces, you have to throw away all your poems and start over). Third, the size of an image is not nearly as forgiving of re-sizing as a genuine text setting is. So if we are to read Alice on a phone, what will happen to the poems?

Leave a Reply