I Finally Did It: WORD FOR THE WISE is now an ebook

I know, I know, I haven’t posted in ages. I’ve been very busy. Anyone want to know how to scan and restore foreign edition paperbacks and turn them into ebooks and print books without being able to understand the words? *crickets* No? Okay, on to the subject at hand.

After years of cleaning and processing MS Word docs, and posting tips and tricks and hacks for using Microsoft Office Word for writing and self-publishing, and answering a lot of emails about problems with Word, I finally compiled that hard-earned knowledge into a book.

2017-11-08_Ebook Cover_Manus_Word for the Wis copy

Here’s an excerpt from the Introduction:

Word is an excellent word processor, one of the most powerful on the market. All that power comes with a price: Where the act of composing fiction or nonfiction is a simple process (in technical terms) Word is complicated. It’s right there in the name itself: Microsoft Office Word. It’s a productivity program for businesses; not a publishing program for writers of commercial fiction and nonfiction.

For writing a report or a business proposal or a policy & procedures manual, it’s one of the best programs around. For writers, though? It’s kind of like driving a Porsche Carrera to the grocery store.

Even so, just about every writer I deal with uses Word. Even Mac users. Even writers who wouldn’t touch a Microsoft program send material that has been exported as a Word doc. Word is everywhere thanks to Microsoft having installed it on all Windows PCs for decades. (They no longer give away the Microsoft Office Suite; Word must now be licensed via subscription.)

Smashwords, the largest and heartiest of the aggregators for self-publishers to distribute and sell ebooks, converts Word docs into a wide variety of ebook platforms. (A publisher can also upload an EPUB file to Smashwords.) Other sites now allow self-publishers to upload Word docs. Even Amazon allows it. The conversion processes they use are programmed to recognize and modify the HTML coding in a Word doc.

Writers are using Word to compose their work, and some use it to format ebooks, and others use it to format print-on-demand editions. Even some professional ebook and print formatters use Word. Word might not be the best word processor for writers, but it is everywhere and it’s not going away for a long, long time.

I have processed thousands of Word docs, millions and millions of words, from hundreds of clients. The majority of those writers are like me from ten years ago, using the program inefficiently and often destructively. Cleaning up those files is how I’ve become an expert.

I can help you use Word like an expert, too.

My goals with this book are:

  • Teach writers to customize Word to suit their particular needs.
  • Teach writers to use the features that actually make their writing lives easier.
  • Help writers increase their creative productivity by eliminating destructive practices.
  • Teach writers to create the various types of docs used for editorial tasks, digital submissions, ebooks and print-on-demand interior files.

Even if you don’t use Word, you might find this book useful. There are dozens of word processors and programs created specifically for creative writing. The majority use the same underlying principles as Word.

I give you my promise. There are no gotchas in this book. No traps. No need for special skills or technical knowledge. I won’t use tech-speak because I don’t know any; I’m talking to you writer to writer. You don’t even need a spectacular memory since many of the things I recommend will require your attention just once. Set it and forget it and write on.

For the time being it’s only available on Amazon. (Have to figure out how to sneak all the mentions of Amazon and Kindle past Apple–heh.) I’m working on the print edition and should have that live in a week or so.

So if you ever wanted to know what I know about using MS Word, now you can, all in one easy guide.

WORD for the Wise:
Using Microsoft Office Word for Creative Writing and Self-Publishing

Advertisements

More About Ebook Formatting, Source Files and Tales of Tagging

First an apology for not answering every comment this week. On the “Source Files Update” post there were some great comments. People are coming up with solutions and solving problems. So go read the comments over there. One commenter in particular is hard at work on the subject of formatting ebooks from word processor files. I’ve been corresponding with William Ockham regarding his efforts to create a program that will make it easy to format a word processor file into a good-looking ebook. I’ve sent William some grotty files and he’s been problem solving. I’ve brought one of his comments over to this post so you can get a better idea of what he’s doing:

Wow, I’m flattered. I’ve been busy with my guest blogging stint over at http://www.thepassivevoice.com and didn’t see all these comments. Since there is some interest here, I’ll share what I can of my plans. I firmly believe that writers should use whatever tool works for them. For most people, that’s Microsoft Word. Some folks are using Scrivener and almost everyone else is using some word processor (a flavor of OpenOffice or those WordPerfect holdouts).

The first thing I’m going to release is a free document to source file converter service (to use Jaye’s terms). You save your manuscript in RTF format (pretty much every program supports RTF) and upload it to my service. My program will go through and do all the stuff that Jaye talks about. It will strip all the formatting except bold, italics, and chapter headings. You get back a nice clean source file in RTF format. You load it up into your tool and save it back as a .doc file and you have a source file suitable as the input for ebook formatting. It’s not much, but it is a nice little timesaver and your ebook formatter will thank you (even if you DIY). Did I mention it would be free?

I really appreciate all the expressions of support. I hadn’t really given much thought to a Kickstarter, but I am thinking about it now. In the meantime, there is something you could do to help. I need test cases. That is, I need real manuscripts before they’ve been given the Jaye Manus treatment. If anyone has copies of their novels (or short story collections) that they wouldn’t sharing with me, I would really appreciate it. I promise not use them for anything other than perfecting my software. I will send you the cleaned up version and destroy or return the original when I’m done.

If you can help in this way, save your gnarliest files (smart quotes, em dashes, paragraphs indented with tabs and spaces, whatever) in RTF format and
email them
to razoroftruth at
gmail dot
com

Let me know what program (i.e Microsoft Word) and version (like 2000 or 2007) and whether you are using Windows, Mac, or Linux (or other Unix variant).

Which brings us to another problem I’m working on with source files–tagging. One of the things keeping me so busy this week is learning HTML. Turns out it’s kind of fun and quite the challenge. I also discovered that my resulting ebook files are much smaller–why? Who knows. But that’s a plus since I love using graphics for headers and such. Anyhow, the biggest challenge has been doing an ebook in screenplay format. It’s not difficult. It requires essentially three styles: Centered, Block Quote and Hanging Text. Since it ran about 120 pages in manuscript form, the real challenge was making sure every style was properly applied. I also wanted a way to NOT have to go in and tweak every line of text.

Now me, I happen to think FIND/REPLACE is the greatest invention since the light bulb. I’ve stated before that Word’s F/R is a powerhouse. Indeed. I also made some very interesting discoveries about Word and text editors and how they interact re formatting tags.

Le sigh…

Let’s talk about the two most common special formatting tags in the writing universe. Asterisks to indicate bolded text and underscores to indicate italics. Most editors and agents understand what those marks mean. Sending an e-query with those tags in place would be perfectly acceptable. Except… Even if you turn off the auto-formatting features, Word treats them like special characters and so does a text editor. Meaning, a text editor will strip them out. So those are out. You can use them if you like–they are easy to read–but if you ever have to copy the file into a text editor, you’ll lose the tags and your special formatting.

Anyhow, I’ve been using my own little special formatting tags–ii for italics, BB for bolding, and UU for underlining. Nobody but me sees them or has to read them, so no big deal. BUT, I am in the process of creating a cheat sheet for Source Files, and need to come up with tags that One) Make sense; Two) Are easy to remember and use; Three) Don’t activate “helpfulness” in word processors; Four) Work well in FIND/REPLACE operations. Number three is a bitch. I popped around in different programs to see how they handle various tags. Turns out non-letter characters are a problem when created in strings–Word, especially, kept getting wobbly and persnickety. Plus, some can cause problems in HTML coding because it uses so many characters for commands. For instance, I tried i/TEXT/i for italics. That seems fairly straightforward, right? It didn’t make Word go all wobbly either and it translated into a text editor. Problems arose when I did F/R operations in the text editor. I needed characters that are NOT used in coding. Which leaves out almost all of them.

Ah ha, most FIND operations can be made case sensitive. And there is one non-letter character that gave me no problems at all–the lowly dash/hyphen. So here are a few of the tags I ended up with:

  • -ITAL-   -NOITAL-
  • -CTR-     -NOCTR-
  • -BQ-        -NOBQ-
  • -NBSP-

Those might seem a little “wordy” but they are pretty self-explanatory (italics, centered text, block quote, no break space) and they don’t cause interpretation wars between programs. When I paste the Word file into the text editor, all I have to do is run FIND/REPLACE operations to insert the coding. (ex: -ITAL- becomes <i> and -NOITAL- becomes </i> to make italicized text) Most fiction doesn’t require every paragraph be tagged. So I won’t go in to the nifty little shortcuts I found.

The really important thing I’ve discovered is that not all tagging is equal and some of the old printer’s tags will not work because the programs want to do something with them and it’s not always what the writer intends.

So how about you, folks? What nifty tricks tricks have you come up for tagging the special formatting in your files?

Source Files Update

So last week I talked about the importance of writers shifting their mindset from thinking “Print Documents” to thinking  “Electronic Files.” Judging by the responses I got, I’d say I’m not the only one concerned with this subject. One of the problems is that the tools we use–namely word processors–are superb for producing printed documents, but frustrating, maddening and over-powered when creating electronic files.

Currently, I’m in the process of creating a booklet/cheat sheet to help fiction writers who are NOT computer programmers to painlessly use the tools they have–and are comfortable using–to create electronic files suitable for e-queries, e-submissions and ebooks. You’d think this would be simple, but it’s not. For one thing, there’s a language problem. I’m a fiction writer, not a programmer. I think in terms of print. Adjusting my way of looking at the subject is difficult and I backslide worse than a dieter at a chocolate fountain. I’ve been talking to William Ockham and he thinks my efforts are on the right track, but kind of sad, too, because he is a computer programmer and he is frustrated by how out-of-synch users and developers are. He is currently working on a program for ebook producers. Essentially he wants a program similar to what blogging sites use. The user selects a “theme” for how he/she wants the ebook to look, then loads in their text and images and the program takes care of all the formatting. If William succeeds, I’ll be his first customer.

In the meantime, I’d thought I’d show you what we’re up against.

First, here is a document provided by a writer for whom I’m producing an ebook. Those little marks you see in the image indicate spaces and paragraph returns.

The writer has created a document suitable for print. Everything is nicely laid out on the screen and without the Show/Hide feature toggled, one would look at it and think, “Beautiful.” Here’s how it looks if I convert this and load it on my Kindle.

Because the writer used paragraph returns to make a new page (instead of inserted page breaks) this is what the start of chapter two looks like:

Now here is the same document with all the extra paragraph returns and spaces removed, and the special formatting and paragraph returns tagged.

Here is what the same document looks like loaded into a text editor for HTML formatting:

Here is what the same document looks like when I upload a cleaned up copy into Scrivener for ebook formatting:

Here is what it looks like if I format it for an ebook in Word (for uploading to Smashwords):

Here is an end product I’m going for (still some tinkering left to do, but you get the idea):

I had thought (foolishly) that all my problems were solved by getting away from Word (except to use its turbo-charged Find/Replace feature to clean up files) and using Scrivener to produce ebooks. It does a great job and it’s relatively painless. Last week I learned there is a problem with one of the books I produced. The problem occurred because Amazon updated older model Kindles and now some people will find that some ebooks–not all!–are compressed and they will have to manually enlarge the screens. Why? I think it’s something Amazon did, but hey, I’m a fiction writer, not a programmer. I do not know why.

Until I do know why and can figure out how to prevent that from happening, I’m now leery of Scrivener. So, damn it, I’m doing what I told myself I really didn’t want to do, and am learning HTML in order to produce ebooks. Come to find out, there are different languages and coding for HTML, too! Ay yi yi. My eyes aren’t red just from the Colorado wildfires, but from spending hours trying to figure this shit out.

It shouldn’t be this hard. Electronic files should not be filled with tiger traps and landmines waiting to turn our lovely words into gibberish marching all over a user’s screen. Those e-queries and e-submissions we labor over until they are perfect should not turn into funhouse mirror words the moment we hit SEND. Creating an ebook should not require a degree in Computer Science and fluency in programming languages. There shouldn’t be different formats requiring different source file layouts and conversion programs and different requirements from every single e-distributor.

Woulda, coulda, shoulda…

The reality is, this Tower of Cyber-Babel and the Facebook Effect (taking something that works fine, and people enjoy using, and tinkering and “fixing” it until everybody loathes it) are what we have to deal with right now. It is more important than ever for writers to change the way they think about the files they create and how they will be used (e-queries, e-submissions, ebooks, print) and adjust the way they use their favored word processors.

Watch this space. The cheat sheet is slowly becoming a reality and I’ll let you know when it’s ready to go.

 

Ebook Formatting Resources

There has been a lot of interest in my posts on ebook formatting. So rather than make people wade through the entire blog, I put all the links on one page. You can find it in the header under Ebook Formatting Resources or click here.

I’ve linked all my posts on the subject, plus added links to useful sites and resources for the DIY indie. I’ll continue to update the page as I learn new tricks or find useful new blogs and websites.

Scrivener and the Ebook

I heard about the Scrivener writing program last year. I followed a link to Literature and Latte, roamed the site and got interested. What finally hooked me was the promise of a new way to organize a writing project. So in January I purchased the program. (Why so long? Because I’m scared of hardware. Go ahead and laugh, the old man does. Then again he’s a mechanical genius and never worries about the damned things eating him while he sleeps. When he starts fiddling with things, I have to leave the room, freaked out about him pissing off the machines. Because I’m convinced my computer is just waiting for me to do something stupid, it takes me forever to work up the nerve to install new programs. Now you know.)

As a novelist I’m not exactly tidy. My process involves notebooks, Post-it notes, scraps of envelopes, colored pens and pencils, sketch pads, clippings, piles of reference books bristling with place markers and file folders. Rolls of butcher paper, colored Sharpies, white boards and reams of printed manuscript also play a role. Clutter is part of my process. I need to see it, need to have it where I can put my hands on it. That’s what Scrivener does. It digitizes my clutter. Instead of having it scattered on my desk top, it’s on the screen, available with a click of the mouse.

Scrivener is not a word processor. It’s a writing program. It’s not for generating printed documents, it’s for generating files. (You can use it to create printed documents, but using Scrivener to write a letter to your mom would be like using a bulldozer to dig a post hole.) It very easily and quickly generates lots of different types of files, including PDF, RTF, Word, epub and mobi (Kindle) files.

Me, being me, I got ideas. Once I got interested in self-published ebooks, I had to try it for myself. I’m always interested in how things are made. Since I read almost exclusively on my Kindle now, I see a wide range of quality in ebook production. When I see a problem, I try to figure out the source of the problem. If you’re a regular reader, you have seen my obsession with em dashes and spacing issues and ways to exploit the ereader vehicle. To me, the two biggest concerns for any ebook formatter should be: Readability and easy navigation.

There are many ebook formatters who are familiar with programming, coding and HTML. I’m not one of them. I have no idea what goes on behind the screen. Because of the limitations of MS Word and the often interesting glitches that occur when converting Word files, learning ebook production increased my vocabulary (children, cover your ears). I also had problems organizing layouts. Every change made in Word offers the program new chances to screw things up. So I was figuring out HTML and basic programming, but slowly.

Then came Scrivener. It speaks my language and doesn’t require me to memorize codes and commands. With its organizational capabilities, I saw a way to make more than a simple ebook. I could make beautiful ebooks. It took me a few tries to figure out the possibilities until I achieved something that came close to matching my vision. You can see my latest creation here.

I also discovered a few quirks and limitations. BUT, by using Word’s powerhouse Find and Replace feature to take care of spacing issues and oddball punctuation, then stripping the file in a text editor, I can produce a squeaky clean file ready for layout in Scrivener. (And yeah, I know, it’s not particularly efficient, but I can do it very quickly and it makes sense to my peculiar way of thinking.) Scrivener’s special character map is far better than Word’s, too. So while I’m proofreading it is very easy to make a little cheat sheet off to the side for any special characters needed, then a simple search and replace takes care of those. Also, Scrivener’s formatting is basic, without all the desktop publishing features of Word (full of cute little traps that can make a total mess of an ebook). Since ebook formatting (for fiction) is quite basic, too, Scrivener’s simple design is perfect. I created a template so all I have to do is break up the main file, then move sections around to get the layout I want. I can send an RTF or PDF file to the writer for their approval, and if they want things changed around, no problem at all. Minimal risk of screwing up the formatting.

Graphics are a breeze with Scrivener, too. I’m not talking about covers. I’ve tried my hand at making ebook covers, with decidedly mixed results, but that’s a whole other project I’m working on. I’m talking about such things as fancy font chapter heads, scene break indicators and illustrations. Graphics open up a whole new world of possibilities to make an ebook visually appealing. I have only dabbled in graphics thus far, but I can see the potential and have several interesting experiments in mind.

Granted, not every indie author is interested in learning how to format their ebooks. Formatting isn’t difficult at all, but there is a learning curve and a million and one little details to track. If you want to focus on the writing and hire out the production jobs, that’s fine. Formatting isn’t terribly expensive and won’t break any writer’s bank. If, however, you’re a die-hard do-it-yourselfer, but you aren’t adept at programming and coding, Scrivener is an excellent way to go.

If anyone who uses Scrivener has tips and tricks for ebook production, or would like to know exactly how I created Beauty and the Feast, leave a note in the comments. I can write another blog post.

 

My Computer Doesn’t Like Your Computer: Formatting Electronic Submissions

So Writing Buddy and I met yesterday for bacon and shop talk. She had an article she was getting ready to submit and I happened to notice that she still uses two spaces after the end of every sentence. Earlier we had been talking about some of the problems I see in e-books. Some formatting errors are caused by sloppiness, some are a result of ignorance, but quite often the publisher does everything right, or tries to anyway, but the programs misinterpret the coding and errors result. The most common formatting errors I see are font size changes or extra spaces between lines. When I see those, in an otherwise nicely formatted e-book, I assume it is a coding error.

E-books aren’t the only places I see translation errors. I receive a lot of manuscripts as attachments. Quite often when I open them they look like circus advertisements on the screen. Sometimes funny things happen in e-mails, too. Strange symbols, little circles, bolding here and there at random, and occasionally giant fonts.

The problem isn’t that the originator of the document is doing anything wrong, it’s just that my computer doesn’t necessarily like your computer. Every program has its own coding. And too many programs try to be helpful. Much the way toddlers are helpful in the kitchen. Or the government.

This wasn’t a problem when everybody was submitting manuscripts to agents and editors via snail mail. You learned standard formatting, you printed a copy, and you sent it off in the mail. Whatever you put in the envelope is exactly what the agent or editor received. Electronic submissions, however, are a little trickier. What you put in the body of an e-mail or attach to an e-mail might be read on a computer or on an iPhone or an iPad or a Kindle or Nook or smart phone or aluminum foil space mirror with alien technology. Since every gadget and program has its own way of doing things, they have to interpret and translate to the best of their ability. It’s like an electronic version of Telephone.

There really isn’t anything a writer can do to make sure their electronic manuscripts are read perfectly on every gadget. But there are things you can do to make sure that even when hiccups occur, your manuscript will still be readable.

Now I’m not familiar with every word processing program on the market. I use Word. I use the Word 2000 version because newer versions are so junked up with hidden codes and “helpful” features, they are maddening to use. Word seems to be pretty much the standard, though. Any suggestions I make here should translate fairly well over to other word processors. The principles remain the same.

  • First and foremost, get out of the habit of using the Tab key. I don’t know what it is about it that encourages programs to be so “helpful,” but using the Tab key about guarantees weird formatting errors.
  • Use style sheets to format the manuscripts. Style sheets will give you consistency and a minimum of code for the computer to screw up.
  • Be aware that any manual spacing you use to make a new page (or center text or otherwise move text around on the page) gives programs permission to screw things up.
  • Never use headers for electronic submissions. This includes numbering pages. Because of the many different screen sizes, headers will appear in inconvenient places.

Hidden codes are the enemy. You want to compose your electronic submissions in such a way that it does not encourage Word to insert hidden codes in an effort to be “helpful.” The very first thing you want to do is go under Tools and select AutoCorrect. It looks like this:

What you want to do is go through the menus and disable most of the AutoCorrect features. It is pretty safe to keep some of the auto format features turned on, such as curly quotes and bold and italics. With everything else you’re probably better off keying them in by hand.

If you are working on a manuscript and have been using tabs it is very easy to strip them out. Do a search and replace with ^t in the search box and then leave the replace box empty. If you have extra spacing, either between sentences, or to rearrange text on the page, or have used hard returns to start a new page, you will need to take those out. One way is to use the search-and-replace feature. Hit the space bar twice (or the number of offending spaces) in the search box, and then put the desired number of spaces in the replace box (one or zero). To make sure you have removed all the offending spaces use the “Show” feature in the menubar. In Word it looks like the paragraph symbol. ¶ (the “show” symbols do not print) Extra spaces will show up as dots and you can manually delete them. From this point forward you will use the “insert page break” feature, and stylesheets for arranging text so it’s indented, centered or right justified or whatever you need.

Making a user-defined stylesheet is very easy. From the menu bar under Format select “Style…”:

You are going to create a user-defined style. Select “New…”

Give it a name. I used “Manuscript.” The style type will be “paragraph.” Base it on “body text.” Style for the following paragraph will be “Manuscript.” Then select “format” and from the drop down menu go to “paragraph.”

Fill in the boxes so it looks like the above. Then hit OK. Select format again and select font.

I recommend you leave the special effects and character spacing alone. Some of those don’t translate well. Times New Roman and Garamond both show up well on most readers, no matter what size the screen. If you prefer to work with a different font, put that in your style sheet. When you are ready to submit, you can select all and change the font to Times or Garamond.

Now hit apply.

Save your style sheet by selecting “organizer” from the Style box. Highlight your style, select Copy and it will show up on the right hand side. Now, when you open a new document, you can just go to Style, selected user-defined styles and your custom style sheet(s) will be there, ready to go.

There you have it. A simple format good for composing on your computer and with fewer chances of translation errors when you make an electronic submission. If you’re not familiar with style sheets, I recommend you play around with them. You won’t hurt anything. Trust me. Try different fonts, different spacing. See what happens. When you’re comfortable with a basic body text style, you can make style sheets for chapter heads and other things. Break those old habits of manual spacing and using the Tab key, and you’ll create electronic submissions that give various gadgets and programs fewer opportunities to be “helpful.” And the agents and editors you submit to will thank you for it.

If you have any tips for formatting documents that are helpful to those of us who are unfamiliar with or are just learning the wonders of HTML and CSS, I’d love to hear them.

 

 

 

 

 

 
https://jwmanus.wordpress.com/tag/word-processors/
jwmanus.wordpress.com
crawl=CC-MAIN-2018-17
124872
application/http; msgtype=response
sha1:UZ3H6MQN4XPQNGRFKWR5CCBYJDRNJBN5
<urn:uuid:f5493272-798c-4fcb-8602-e2d9aec4bf2d>
2018-04-24T08:49:17Z
192.0.78.13
text/html
sha1:TYGSCOG3AHNUDWOWF75MLOTWUVIZ7N6C
<urn:uuid:17716597-5bb2-4f20-94c9-a20b7debff7e>
https://jwmanus.wordpress.com/tag/word-processors/
length
response
<urn:uuid:c68dcce7-f0cb-4cf4-bb3f-8546b9265b8e>
robots: classic
hostname: ip-10-168-23-116.ec2.internal
software: Nutch 1.6 (CC)
isPartOf: CC-MAIN-2018-17
operator: Common Crawl Admin
description: Wide crawl of the web for April 2018
publisher: Common Crawl
format: WARC File Format 1.0
conformsTo: http://bibnum.bnf.fr/WARC/WARC_ISO_28500_version1_latestdraft.pdf