We set out to design TQ in a way that is simultaneously beautiful, true to the intent of the contributors’ work, and functional for us over the long term. I asked Ryan Gunn, TQ’s Intern and Chief Layout Wrangler, to share with you some of the challenges and solutions we found. – Jessamyn Smyth
JS:
In print publishing, almost any formatting a writer can imagine a publisher and book designers can reproduce: various software options fully support print text-design. In electronic publishing, however, formatting is more context-dependent, and every tool for an online journal carries both pros and cons.
At TQ, we settled on using a customized WordPress platform for our site, as it gives us so many options we like, allows for people of many skill levels to do the work over the long haul, and is fast and versatile for most of our needs. But complex text-formatting in WordPress has limitations: would you talk a bit about those, and the kinds of solutions we needed to find?
RG:
Wordpress is fantastic, especially for a literary journal. There is so much functionality to make an online journal great: back issues become available at the click of a mouse, tagging allows readers to filter content by author or genre, and much more.
Despite all of the wonderful things WordPress allows us to do, it also causes a lot of problems when it comes to formatting white space. Some of the most inventive poems are those that take advantage of the white space and use it to say more than just what the words alone can convey. Accurately recreating the formatting of these poems poses a lot of issues, and can at worst render a beautifully formatted poem unreadable. The problem is that WordPress automatically removes any “excess” white space from a post. This means that a traditional five-space indent of the first line of a paragraph of prose is removed. It also means that double or triple spacing after the end of a paragraph or stanza is reduced to a single space. The “tab” button on the keyboard becomes useless. Single spaces between words and one line paragraph breaks are the only given options.
JS:
Working with traditionally-spaced prose, or poems employing only full breaks at each line’s end, electronic publishers have many choices. But in work that has complex spacing within the bodies of each line, or varied and complex justification and use of white-space, we encounter some very real challenges, and every good solution creates several new issues. What are some of the pros and cons of the many ways people have solved these problems?
RG:
The most common solution I’ve seen is to simply not publish work that includes complex formatting. But eliminating any and all complexly formatted work hurts the magazine and the supporting literary community. The second widely used solution I’ve seen is the infamous “period trick.” This involves putting in periods instead of spaces, where multiple spaces are needed, and then coloring those periods white (or whatever color the site background may be). At a glance, this solution works perfectly. Issues arise, however, when someone selects the text, or has their web browser set in a way that reveals the extra punctuation marks.
The most promising and also most problematic solution involves embedding PDFs in the body of a post. PDFs were designed to preserve formatting across devices, but a PDF page simulates how content will look on a printed page. This includes margins, headers, and footers, and embedding a PDF means you get all of that. The process works fine for single page poems. But for multi-page poems or long prose, the top and bottom margins cause massive white spaces between pages. Even after going through the painstaking and supremely inefficient process of cropping margins from a PDF using third party software, extra space still exists from page breaks. On top of that, PDFs carry issues of accessibility and storage space. Adobe comes pre-installed on most computers, but anyone who does not have it is presented with a blank space instead of the posted content. PDFs take up an enormous amount of space compared to plain text and thus take a long time to load, so people with slower connections may not be able to see the content. The extra server storage space required by PDFs poses another problem.
JS:
In talking with other electronic journal editors and the webmasters who work with them to wrangle complex layout, what became clear was that the thing we all want–a fast, easy way to format complex text in electronic form, true to the author’s intent and also easy enough to be replicated by a constantly-changing staff with widely varying levels of technical skill–is essentially a unicorn. Or a magic wand.
Everyone comes up with the idiosyncratic solutions that work best for their particular journal, but often, those solutions are more complicated than we’d like. A 35-step high-skill process including complex code-writing or style sheet tailoring for each post is not a going proposition, in terms of either available time or reliable staff, intern, or volunteer skill. Likewise, only accepting work that carries no particular formatting challenges, while understandable, wasn’t a limitation we were willing to accept. Having our publication only be reliably view-able by some browsers at some connection speeds (and very few, if any, mobile devices) also wasn’t acceptable.
You found us the closest thing to that unicorn with a magic wand I’ve yet heard of: a simple, elegant solution (using common non-breaking space code and working in the text editor vs. WYSIWYG) we can use within the WordPress platform without much layout pain at all. Explain?
RG:
Unfortunately I cannot claim to be a magician, conjuring up white space from nothing. The answer was out there before I came along and has likely been used in exactly this context before, but it seems many people remain unaware of it.
The “Visual Editor” (WYSIWYG) in WordPress is at the root of a lot of frustration, but it was actually because of that frustration that I discovered our solution: a tiny piece of HTML code that anyone viewing a website from the outside will never notice:
& n b s p ; – HTML shorthand for “non-breaking space”
Non-breaking space functions more or less like the regular space one gets from pressing the space-bar, but, because it is code, it fools WordPress into thinking there is actually something there – and therefore it is not automatically deleted.
Using non-breaking space for poem formatting is simple.
Go into the Text/HTML editor and paste & n b s p ; (without spaces between the characters) – you’ll likely need to use more than one, i.e.: & n b s p ; & n b s p ; & n b s p ; anywhere you require more than one space. If you need a blank line between stanzas or paragraphs, put & n b s p ; on a line by itself.
The one problem with this method is that non-breaking space and the Visual Editor in WordPress don’t play nice. Viewing content in the visual editor converts non-breaking spaces into normal spaces and subsequently erases them. I find it best to disable the Visual Editor in the settings and only use the Text/HTML editor for creating posts. But if you are married to the functionality of the Visual Editor, then I recommend you do all of your visual editing before you begin formatting with the Text/HTML editor.
Formatting in this way is time consuming, but less so than working with multi-page PDFs and with none of the associated problems. I’ve found that complex formatting is the exception rather than the rule, but taking the time to create non-breaking space in the text code allows us to publish beautiful work like Kristina Erny’s ‘Paraclete’ or Arra Ross’s ‘How I Set Her Down.’