LMGM Logo

Here is a test logo for the Last-Minute Game Master series. Any thoughts?

Further Thought on One-Page Town Templates

I’ve looked at everyone’s requests for what ought to be part of a one-page town template and condensed them into what I think works.

Some things, such as walls, aren't part of the text describing a town because the map tells you this. At most, you only need notes if these are unusual in some way.

Some things are highly specific to one person’s way of doing things: some of these, such as rating towns in terms of hit dice, could be generalized: for example, if you rate Village as 1 die, Town as 2 dice, City as 3 dice, you can multiply by two or three to fit into other schemes. Whether this is tied to a population size or a military rating is up to individual GMs. Other suggestions, such as using the six ability scores as town ability scores, are too specific to one person’s style and are left out of the template below; they can be added in Miscellaneous or written directly on the map by the GM using the one-page town.

I'm assuming margins on each side are 0.75 inches or 18.95 mm. If we call the area inside the margins the "page", we can define structures -- blocks -- on the page relative to page height and page width. There are three main blocks arranged vertically on the page:

1. Title Block: Across Top, full width of page
   

   Town Name, author’s name.

   These may actually be in separate DIVs or sections, so that the Town Name can be flush left and the author's name flush right.
2. Map Block: Below Title-Block, full width of page, 42% of page height
   Contains two more DIVs or sections arranged side-by-side, flush left and flush right:
   
   • Map: 57% of page width, flush left
   • Map Sidebar: 40% of page width, flush right
   This leaves a 3% gutter between the two sections. Below this structure is a Legend Block that extends the full width of the Map Block. There may be a horizontal rule separating the Legend from the next block.
3. Main Text Block: Below Map Block, full width of page, remainder of page height
   Divided into a Town Quarters block that is arranged in two columns, evenly split, and a Miscellaneous Notes block below that that is is single-column mode.

Annotations on the map:

• walls, palisades or ramparts
• towers, other structures or important locations
• moats, streams and bridges

Contents of Map Sidebar:

• descriptive phrase and dice rating
• one-sentence background or theme
• population table (class/race/type breakdown)

You can swap Map and Map Sidebar.

Legend below Map:

Notes on anything unique about the above: walls made of glass or iron, for example.

Town Quarters:

• Noble Quarter (ruling class, name of baron/prince/mayor NPC, if any)
• Common Quarter (main labor type, any legal restrictions)
• Trades Quarter (price shifts, surpluses, shortages)
• Special Quarter (town specialty, if any)

Miscellaneous:

Recent Events, Town Secrets, Unusual NPCs, and any unusual cultural info

Licensing Notes  can be placed at the bottom.

I'll see about making a template along these lines in the next couple days.

Blue Maps

After I talked about writing details directly on town maps, something occurred to me about old school maps. TSR-era maps are usually printed in a shade of blue, instead of in black. Specifically, it’s non-photo blue, RGB #A4DDED, a shade that can’t be detected by the graphics arts cameras typically used back then. TSR used this shade to prevent high-quality reproductions of their maps in bootleg copies of the modules.

This, of course, is no longer true with digital image techniques, but old schoolers are so used to seeing maps that look like that, there are a number of OSR publishers who do their maps in that color. For example, Dragonsfoot uses it in their modules. New schoolers laugh at the stupid nostalgia of the OSR.

However, when I made example maps GM info placement directly on town maps to reduce lookup time, I was having problems getting both the text and the underlying map to be equally readable. It was only after I posted my examples that I realized the solution is to print the player map in black, but make the GM map non-photo blue, so that that GMs can add notes directly to the map in pencil and still be able to read both the map and the notes. It’s a nice re-purposing of an old tradition.

StackEdit

I’m trying out a new app. It’s specifically designed for Google Chrome, and it’s called StackEdit. What it is is an in-browser Markdown editor that syncs with Google Drive, Dropbox, and Blogger… so, instead of using the Blogger interface to write a post, you can do plain text. It even has an easier way to do tables than in Blogger itself. And you can save a copy to Google Drive.

I’m exploring it because I’m a big Markdown booster, obviously. But also to see if it’s a better way to write blogposts while retaining a copy to eventually make its way into a zine or PDF. And I’ve noticed two immediate flaws:

1. Like every alternative way to post to Blogger I’ve tried, there’s no way to schedule posts in advance. It’s now or never, dQQd. I’m not even sure you can tag posts before they are published. (Correction: Turns out you can specify the tags in a YAML block, but you won't know about this until you try to publish. Read the link they give, then cancel publishing to Blogger so you can add the block.)
2. Because of the weird way Blogger handles images, you can’t just add images to your document, then publish, unless you are linking to an image that’s elsewhere on the web. You have do add the image in the Blogger editor. Which wouldn't be so bad, if you could “publish” as a draft, but see #1.

But still, you get a live preview of what it will look like as a web page, and you can click to view the HTML code, copy the code, and paste that into the Blogger editor. And when you upload an HTML version to Google Drive, you can use Google Docs to convert to PDF, so it’s a simple pipeline for those who want to do combined blogging and amateur RPG publishing.

Written with StackEdit.

Bad Design

Randall has some disparaging things to say about most "professional"-looking RPG products, and I completely agree. In particular, I don't think the White Wolf books, the WotC D&D books, or Nobilis were all that good-looking. It's like people are blinded by the glitz and didn't think about the usability.

Specific points Randall raises that I'd like to comment on:

Page Backgrounds should hardly ever be used. If you are going to use them at all, use a simple design, one to four large symbols, at about 5% grayscale, or a very pale blue, red, green, or yellow. And only use it intermittently, like on the first page of a chapter. Use it to help readers navigate, not because you think it's pretty. Solid colors that are much lighter than the color of the text may be reasonable, as well. Busy designs are crap, because then you have trouble reading overprinted text; for this reason, don't use them unless the busy part of the background is in the top half or bottom half of a page that's only half-full of text.

Borders, as Randall says, should be functional. One function he doesn't mention is as a divider. If, for example, you have a border on the top and bottom of the page, and page headers above the top border, page numbers below the bottom border, then the borders are separating the main text from the page headers and page numbers. That's useful. A border between the sidebar and the main text is also a reasonable idea, as is a section divider or border for a pull quote/optional rule/chapter summary.

The more often a stylistic element is used, the simpler it should be. Stuff that appears on every page, like the margin borders, should be very simple. Complicated designs should be reserved for chapter head, chapter end, and things like that. You should not have an illustration on every single page, because sparser illustrations help to distinguish one section of a chapter or book from another. Think of it this way: you shouldn't have more than four pages or so in a row that all have the same design. After two to four pages of plain text, throw in an illustration, a pull-quote, or a table. Likewise, after two to four pages of tables, throw something in to break up the monotony. Don't use the same limit for the number of pages in a single style, either. Sometimes throw in an illustration after two pages, sometimes four, sometimes a run of three pages with illustrations. It's all about a careful balance between a uniform appearance and a monotonous one.

Layout Series Poll

To those following my Layout Tutorial series: I've just posted about about wrapping text around an image for web and EPUB output. I could do a quick installment about doing the same for PDF format, or I could do one to three installments focusing on EPUB, so that I can come back and do the same for PDF/print.

I'm going back and forth on this. Logically, since the layout and design procedures are different at this point, I should just focus on one, then switch to the other. But I figure there might be a couple people waiting desperately for the instructions on how to wrap text around images in PDF. 

So I'm polling the readership. What's your preference?

Another Fix

I had to fix Part 6 of the Layout series, because I forgot (again) that copying it into Blogger messes up the STYLE examples. Should be OK now.

I really should just write a filter and test a work-around someone suggested for uploading posts directly to Blogger. I'd have less grief that way.

Eventually, I'll gather all the layout tutorials into a single EPUB or PDF and it will look better.

Layout: Web/EPUB Graphics

The installments so far in the DIY layout tutorials for hobby press publishing:

• Part 1 --- Free programs and setting up an efficient workspace;
• Part 2 --- Basic blog posts, webpages, and draft EPUB/PDF;
• Part 3 --- Structuring documents, using links, using templates;
• Part 4 --- Creating tables;
• Part 5 --- Graphics for simple projects.

Here is Part 6.

Layout Tutorial 6: Graphics for Web and EPUB Projects

I made a distinction in Part 5 between simple projects and complex projects. A simple project is a single master/source document that will appear more or less the same, no matter what the final output is (web, ebook, PDF.) A complex project needs to distinguish between web layouts, ebook layouts, and PDF/print layouts. To do this, anything specific to one layout is separated from the shared content. This typically means more than one file. Sometimes, the content itself is broken up into several files, perhaps separated by chapter.

Project Folders

Up to this point, I've been dumping all my files into a \proj\blog\ folder. That's fine, for simple projects. But if I were going to create, say, a unique monster manual, with pics for some of the monsters, I would want to create a new folder, something like \proj\mon\ (Keep the name short...) My content file or files would be here.

Your file names, excluding the extension on the end, should be divided into two or three parts, like this:

01-mon01.txt
01-mon01-adv.txt
01-mon01-gm.txt
01-mon01-lo.txt
01-mon01-hi.txt
02-mon02.txt
etc.

The parts are chapter number, identifier, and an optional control key.

When you first start working on a project, your master document only uses the identifier, something like mon01.txt. For larger projects, you should split your master into chunks of related material. Use a three-to-five character identifier that matches the name of the project's folder, followed by a 2-digit number, starting with foo01 and increasing by 1 each time you start a new chunk. After you've finished a couple solid parts, you can add the two-digit chapter number in front, separated by a hyphen from the rest of the name. This indicates the actual order of the parts, starting with 01. They do not have to match the two-digit identifier; in fact, the reason for using both a part number and an identifier is so you can change the first two digits freely to change the order of the parts, or to make room for other material.

(I've skipped 00-mon00.txt and its companion files because they will be the last thing added to your project: the title page and the information it includes, plus other front matter.)

The control key after the second hyphen indicates optional material, such as:

adv

"advanced" material, so that you could produce basic and advanced versions of a single book.

gm

"GM-only" material, so that you can print one version of a house rules document for players and a different version for the GM.

pc

"Player" material, an alternative to the "GM-only" tag, used when you want GM-only material (the main text) to appear first.

The point of this naming scheme is to use wildcards to select which parts to include when producing a draft or final product, and to keep them in the proper order. I'll be expanding on this later.

More on Image Formats

As I said before, the web browser or ereader figures out how to display images for those output formats, while the LaTeX engine figures out how to insert a graphic into a PDF. Browsers and ereaders do not have to support all image formats; I believe some ereaders will only support JPEG, PNG, the GIF format that PNG is meant to replace, and SVG (scalable vector graphics.) They might also support BMP (bitmap.) Web browsers will usually support all of these, plus several others, but only if the web server sends a code (called the MIME type) telling the browser what the image format is. There's no guarantee that a web server will be properly configured to support PCX or TIFF, for example.

In contrast, PDFs produced by LaTeX can contain JPEG, PNG, encapsulated PostScript (EPS,) and scalable vector graphics in PDF format. I'm not going to deal with EPS in these tutorials, because I'm trying to keep things simple and it looks like using EPS requires a few steps that require more effort.

Low Res/Hi Res Versions of a Product

A second thing to consider is the image resolution. Web graphics are usually low resolution: 72 dots per inch (dpi.) It keeps both the image size and web page load times low. It's also passable for EPUBs and PDFs you plan to use for your personal game. However, if you want to distribute a semi-pro product, you will probably want a higher resolution, such as 300 dpi. What this means is you need a way to separate which images appear in a web page or draft/amateur product from those that appear in a higher-quality EPUB or PDF.

There is a fairly simple way to do this. Remember the way we indicate the references for links and images in our master document?

[Part 1]: /2013/04/layout-tutorial-getting-ready.html
[Part 2]: /2013/04/layout-tutorial-2.html
[Part 3]: /2013/04/layout-tutorial-3.html
[Part 4]: /2013/05/layout-text-tables.html
[Part 5]: /2013/05/sack-dangers.html

[image 1]: /proj/pix/image1.png
[image 2]: /proj/pix/image2.png
[image 3]: /proj/pix/image3.png
[image 4]: /proj/pix/image4.png

Here, I've separated the links and the images into separate blocks. We can put each block anywhere in our document that we'd like. We can put a block of links at the end of the document, or after the paragraph where the links appear. It will define all the links with those names in the document, wherever they may be.

If you put the block that defines image references at the end of your document, it's easy to locate and quickly redefine images without changing your main text. But it's even easier to split the image references into a separate text file. Pandoc can join the two parts for you and translate them into your final product. The command will look like this:

pandoc 01-stuff01.txt 01-stuff01-lo.txt -o stuff.html

Pandoc starts with 01-stuff01.txt and tack 01-stuff01-lo.txt on the end, then converts the combined document. 01-stuff01-lo.txt contains references like this:

[image 1]: /proj/pix/image1-lo.png
[image 2]: /proj/pix/image2-lo.png
[image 3]: /proj/pix/image3-lo.png
[image 4]: /proj/pix/image4-lo.png

An alternate file, 01-stuff01-hi.txt contains references like this:

[image 1]: /proj/pix/image1-hi.png
[image 2]: /proj/pix/image2-hi.png
[image 3]: /proj/pix/image3-hi.png
[image 4]: /proj/pix/image4-hi.png

Or, you can replace "lo" and "hi" in the image names with actual resolutions:

image1-72dpi.png or image1-300dpi.png.

Text Wrapped Around Graphics

Another reason to split your project into parts this way is to separate out images, tables, or other material with special layout needs. For example: so far, all our images have been inserted into the text without any tweaks to the layout. Either the image is completely separated from the text, or a small image is inserted like a character as part of the text. Compare that to the image at the beginning of this paragraph: the lantern is larger than one or two lines of text, but the text has been aligned with the top of the image, instead of the bottom, and the text is wrapped and flows along the side of the lantern.

The way you do this in a web page or EPUB isn't the same as the way you do it in a PDF or in print. The first requires raw HTML, the second requires raw LaTeX. Pandoc allows you to insert raw HTML or raw LaTeX into a Markdown document to get tighter control of the layout than Markdown allows; when making a PDF, HTML will be ignored, and when making a web page or EPUB, LaTeX will be ignored. I'm only going to talk about web pages and related output formats like EPUB this time; I'll deal with wrapped images in a PDF later.

You may remember in Part 4, I gave an example of creating shading for alternate rows of a table using a <style> block. You need the same trick to make text flow around an image. Here's your style block:

<style>
.floatleft
{
float: left;
margin: 0 10px 10px 0;
clear: left;
}

.floatright
{
float: right;
margin: 0 0 10px 10px;
clear: right;
}

.containingbox p { margin-top: 0;}
</style>

We could just insert that at the beginning of our document, but there's a better way to do this. You will be using this exact same style spec in any project that flows text around an image in a web page or ebook, so it's a prime candidate for something you can stick in the \proj\std\ folder. Save the style block to a file named something like wrap.txt. When you want to flow text around an image, first put DIV tags around one or two paragraphs of text you want to wrap, like this:

<div class="containingbox">
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aufidio,
praetorio, erudito homine, oculis capto, saepe audiebam, cum se
lucis magis quam utilitatis desiderio moveri diceret. Hoc est dicere:
Non reprehenderem asotos, si non essent asoti. Duo Reges: constructio
interrete. Is ita vivebat, ut nulla tam exquisita posset inveniri
voluptas, qua non abundaret. Quid ergo aliud intellegetur nisi uti
ne quae pars naturae neglegatur? Is ita vivebat, ut nulla tam
exquisita posset inveniri voluptas, qua non abundaret. Sin laboramus,
quis est, qui alienae modum statuat industriae? Ex quo intellegitur
officium medium quiddam esse, quod neque in bonis ponatur neque in
contrariis. Sed est forma eius disciplinae, sicut fere ceterarum,
triplex: una pars est naturae, disserendi altera, vivendi tertia.
</div>

The "containingbox" class makes sure that the top of the image starts at the top of the block of text. Next, add a line after the first DIV tag, but before the start of the text. This is the line where your actual image will go, same ![image] mark-up we've already used, but with DIV tags around the image:

<div class="containingbox">
<div class="floatleft">![lantern]</div>
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aufidio,
praetorio, erudito homine, oculis capto, saepe audiebam, cum se
lucis magis quam utilitatis desiderio moveri diceret. Hoc est dicere:
Non reprehenderem asotos, si non essent asoti. Duo Reges: constructio
interrete. Is ita vivebat, ut nulla tam exquisita posset inveniri
voluptas, qua non abundaret. Quid ergo aliud intellegetur nisi uti
ne quae pars naturae neglegatur? Is ita vivebat, ut nulla tam
exquisita posset inveniri voluptas, qua non abundaret. Sin laboramus,
quis est, qui alienae modum statuat industriae? Ex quo intellegitur
officium medium quiddam esse, quod neque in bonis ponatur neque in
contrariis. Sed est forma eius disciplinae, sicut fere ceterarum,
triplex: una pars est naturae, disserendi altera, vivendi tertia.
</div>

The image is contained in its own DIV box, which the text flows around. The "floatleft" class moves the image to the left margin of the containing box, so that the text in the containing box will flow along the image's right-hand side. Use "floatright" instead when you want an image on the right margin, with text flowing along the image's left-hand side.

Fixing the Filter

To convert our document, we're going to need to change the filter we've been using in TED Notepad. If you select Tools > Text Filters > Manage List.. from the menu, you can select your filter that creates a full web page and then click Edit. Change the filter command to:

pandoc --standalone -B \proj\%1 -o \proj\%2.html %F

What this does:

• the --standalone option just makes this a full web page, instead of just an HTML fragment.
• the -B option tells Pandoc what to insert Before the main body of the text. This file is inserted verbatim (in other words, it's not in Markdown format, but in this case is full HTML.)
• the \proj\%1 is the name of the file to insert. When you run the filter, you will change the %1 to something like std\wrap.txt, which will insert \proj\std\wrap.txt in after the header, but before the text in the body of your web page.
• -o \proj\%2.html is your output file, in HTML format.
• %F is the currently open file. Note that TED Notepad will save changes to your file before running the filter.

This command line is more complex than what we were using before. It has the potential to get even more complex, since there are many other options we haven't even looked at. However, I'm not tricking you into learning complex command-line syntax; I have a plan to simplify this later.

I'll cover wrapping text around an image in a PDF in a later installment of the tutorial.

Layout Interlude

I was planning on posting Part 6 of the Layout Tutorial today, but I'm way behind, partly because of family activities this past weekend, partly because I'm working out a simpler way to do the things I plan to cover in Parts 6 and 7. As I believe I already said in Part 5, we're running up against the limitations of what you can do for layout and design that applies to all kinds of products. Want to stick a PNG or JPEG image in between two paragraphs and let the web browser, ereader, or PDF creation software decide where it should go? That works fine. Want to use an SVG? Oops, can't directly include an SVG in a PDF using a LaTeX engine; you have to embed the SVG in a PDF, by itself, then include that as your image. Want to use that PDF image in your EPUB? Nope, you have to use the SVG. Want the text to wrap around the contour of the image? That's what I'm working on now. I can *do* it, I'm just looking for an easier way to do it that I can explain and not have people scream "What the hell are you doing to me?"

Sycarion had a question for me a while back, and I offered to help, but I haven't heard back. The issue is an error code when trying to make tables using Markdown and Pandoc. I can check your source file, Sycarion, if you get back to me. In the meantime, my best guess is that it's an issue I ran into myself: character encodings. Pandoc only reads UTF-8, which supports a lot of characters, including accented characters; however, occasionally I would put an é in my text, like when spelling "mêlée", and the text file would save as the wrong character encoding, so Pandoc would choke.

The Pandoc docs suggest using iconv in a pipe to change the encoding to UTF-8 before sending text to Pandoc, then piping it back to iconv to get your preferred character encoding. However, I believe TED Notepad will do the conversion for you, if you remember. It appears that it uses ANSI encoding instead of UTF-8 by default. A quick visit to Options > Settings.. > File will let you fix that.

Layout Tutorial: Graphics

The installments so far in the DIY layout tutorials for hobby press publishing:

• Part 1 --- Free programs and setting up an efficient workspace;
• Part 2 --- Basic blog posts, webpages, and draft EPUB/PDF;
• Part 3 --- Structuring documents, using links, using templates;
• Part 4 --- Creating tables.

Here's Part 5.

Layout Tutorial 5: Including Graphics

What we've been discussing so far have been simple projects: a blog post or webpage, a house rules document, a quick draft ebook or PDF. We haven't been discussing the more complex projects: semi-pro products for submission to zines or self-publication. When we get to the topic of graphics, we're at the transition point from simple project to complex projects. There are a couple uses for graphics in simple projects, which we can cover in this installment.

Let's say you're going to give your players a printed handout about the starting area for a new campaign. You want to list important names they would know, notes on prices and availability, and provide a quick map of the immediate area. You might also throw it up on a web page, to tell others about your campaign. You have a map in digital format.

Image Formats

First: make sure that the map is in either PNG or JPEG format. Technically, Pandoc doesn't know crap about image formats and will happily try to include anything you tell it to include as an image. The problem is that the three final products we're talking about -- web page, EPUB, and PDF/print -- have different expectations. It's the web browser or ereader that figures out how to display the listed image. It's the LaTeX engine that figures out how to insert a graphic into a PDF. They do not all allow the same kinds of image files. This is part of the reason why graphics mark the transition from simple projects to complex projects: if you try to step outside some very narrow boundaries, your document will not include all the graphics in both the web/ebook version and the PDF/print version.

For simple documents, PNG and JPEG will work in all output formats. PNG is best for cartoons, line drawings, and simple shading and color; JPEG is best for photographs and finely-shaded illustrations with a wide range of colors. Unless you have a photorealistic relief or overhead map, you will probably be using PNG for your map.

If your map is not in PNG format, you can use a program like The GIMP or Photoshop to convert it. I know a lot of people still use MS Paintbrush, but I haven't used that in a long time; I think by default it works with PCX format, which will need to be converted, but it probably can covert to PNG. I'm willing to bet that Hexographer, another popular tool for the RPG crowd, can save images in PNG.
You may also need to scale your image to 72 dpi, which is good for web pages and bearable in PDF or print for something that isn't meant to be widely distributed.

Move or copy your map to \proj\map\, once it's converted.

Including Images

It turns out that including a PNG or JPEG image isn't very hard to set up in Markdown. Remember the format for links?

Here is a [link].

[link]: http://somepage.com/

The [link] in the main text is the word that is turned into a hyperlink. The second line show the URL that the link references.

The image format is pretty much the same:

The Local Campaign
==================

![map]

Pictured in the map are the East Region,
the West Region, and the Middle Region.

[map]: /proj/map/localmap.png

The reference part is exactly the same: a path pointing to the location of the image. It can be a location on the web, if you are using something from WikiCommons or something like that. For a blog or a web page, it has to be a reference to an absolute URL or a relative location. For EPUB or PDF, the image is included in the final product, so we can just link to the location of the file on the hard drive or other local storage. Even on a Windows machine, though, it has to be forward slashes, not back slashes.

The difference between a regular link and an image is the exclamation mark in front of the link where it is supposed to appear in the text. ![map], in this case, tells us that our map will appear below the title ("The Local Campaign") and above the text describing the map. The word "map" in the link will appear in web pages as the "ALT text" that appears if the browser doesn't support images.

You can expand this by adding a title attribute. On some web pages, if you hover the mouse cursor over an image, a small rectangle will pop up with a description of the image. This "flyover text" is stored in a TITLE="foo" attribute added to the HTML code for the image. The web comic xkcd famously uses very long titles to make an extra joke or two about the topic of each strip. In the above example, we can add a title or flyover to our image by including the text in quotes or parentheses after the location of the image, like this:

[map]: /proj/map/localmap.png "Pictured in the map are the East Region,
       the West Region, and the Middle Region."

(Actually, you can do this to ordinary links as well, as I have to the xkcd link.)

Images with Captions

I didn't include a display example for the above Markdown code because Blogger is a little different in the way it wants you to upload images. So let's change our example to use a map I've already uploaded to Blogger.

![Map of Goskold]

The starting location for this campaign is Goskold,
a town in the principality of Pexequick.

[Map of Goskold]:     https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiU8aw63jPtC_LSnEA-74qXwgLGm30qdgMElFU78OdHxME50P5sQdVVvTX5QeDxbuF62AiiHB51ClZFHFdCRPhIf0StiAwQH5S019518y3dg8Ozonbad1XWU-5_z1xHALRJtKlxpuSPK9et/s320/hex_LMH2cu.png

(That horrible long thing is a typical Blogger image URL.)

Here's the result:

Map of Goskold

The starting location for this campaign is Goskold, a town in the principality of Pexequick.

You will notice that "Map of Goskold" appears below the image as a caption. The PDF output will also have a caption (although not with this example; that web URL seems to produce an error message when sent to pdflatex.) The image will be centered horizontally, and the caption will read "Fig. 1: Map of Goskold". If you have more than one image, MiKTeX or whatever pdflatex installation you are using will adjust the figure numbers accordingly.

The caption is taken from the link text. Any image that is in a line by itself will have a caption (and will be treated as a figure in LaTeX.) If you don't want a caption, you need to add something after the image, in the same line, such as:

![Map of Goskold]\

(The backslash at the end of the line, you may remember, includes a line break.)

Inline Images

If you have a small image (no higher than 1/6th of an inch, for 12 point fonts,) you can use it as an inline image. For example, you can start a paragraph about weapons available in a town with an image of a horizontal dagger. You do that by simply including the the image link in the same line as the text:

![weapons in town] You can find the following weapons in the local marketplace...

[weapons in town]: /proj/icon/dagger.png "Weapons Available in Town"

The reason why I specify the 1/6th of an inch height for the image is because the text will not wrap around the image. It will start at the baseline of the image, lining up with the bottom, and will have a blank horizontal space to the right of the image from the image top to the top of the text. 12-point type is 1/6th of an inch tall (more or less,) so an image 1/6th of an inch high will not create an unsightly gap in your text. It will be an even better fit if the image is shorter. It must be shorter if you use a smaller font (11 point or 10 point.) You could use a slightly taller image if the text is larger, for example with a large header.

You will notice that the supposed location of my dagger image is in the \proj\icon\ folder. I suggested this (back in Part 1) for exactly this kind of thing: replacement icons for bullet points, or icons to mark special sections of text.

Why can't we make the text wrap around the image? That's something I'll address in Part 6.

Fixed Tables

For those who read my blog via RSS, you may want to check out Part 4 of the Layout/Design tutorial again. There was a problem and I had to edit it.

The explanation: This part dealt a little bit with embedding CSS style information in a document that is otherwise in Markdown format. I marked the necessary code as "verbatim", and converted the document to a web page. This worked fine.

However, Blogger does not allow you to upload your blog posts (that I know of...) You have to type or paste stuff into the edit box. So, what I've been doing is starting a new post in Blogger in one tab, opening the web page version of my document in a second tab, and then copying the document and pasting it into Blogger.

This introduces occasional problems. Like, for example, it removes blank lines between paragraphs, so I have to add those again. It adds a blank line at the start of the document, which I have to remove. Sometimes, it removes a space between two words, if one of the words is in italics, boldface, or verbatim.

And, in this case, it turned some verbatim samples of code into actual HTML. This caused a couple references to disappear completely and also made the style sheet disappear, applying the styles to the tables in my document.

Bleh.

Layout: Text Tables

Layout Tutorial 4: Text Tables

If you are writing a lot of rules material for blog posts or zines, especially if you are creating new classes with their own experience/hit dice progressions, you're going to do a lot of tables. They're simple to set up in the TED/Pandoc process I'm describing. However, if you want fancier features, you need to be aware of your target product's format.

Let's start with a simple d6-based table for what a character sees when peering through a keyhole, under a door, or through a crack.

Peering Through Cracks and Keyholes

d6 Roll	What You See
0 or less	Bugs heading straight towards your eye! If you are surprised, they reach you before you can look away.
1	An eye looking back! Lose element of surprise.
2-4	Nothing, just darkness.
5	Light of some kind.
6	Light and a moving shadow. You can't be surprised by room's occupant.

The Markdown format for this table looks like this:

---------------------------------------------------
d6 Roll     What You See
---------   ---------------------------------------
0 or        Bugs heading straight towards your eye!
less        If you are surprised, they reach you
            before you can look away.

1           An eye looking back! Lose element of
            surprise.

2-4         Nothing, just darkness.

5           Light of some kind.

6           Light and a moving shadow. You can't
            be surprised by room's occupant.
---------------------------------------------------

Table: Peering Through Cracks and Keyholes

Here are the things to note:

1. The table must begin and end with a line of dashes.
2. The headers are underlined with dashes as well. Spaces separate columns.
3. This is a multi-line table, which requires blank lines between rows. If you miss a blank line, the rows won't look the way you expect.
4. There is no blank line after the last row, just the dashed line that indicates the end of the table.
5. There is a blank line after the last dashed line, followed by the table caption, which begins with the word "Table" followed by a colon and the caption. You can leave the caption out.

One potential trap: don't surround the line of dashes with blank lines, like this:

A

--------

B

Pandoc will not interpret that as the beginning of a table. It will treat it as a horizontal rule (dividing line) instead.

The headers and the dashes underneath the headers tell Pandoc how to align the columns. If the dashed line under a header is aligned flush with the left end of the header and is longer than the header, the column will be flush left, as you see here. If the header is aligned flush right, the column will be flush right. If the dashed line is longer than the header on both ends, the column will be centered. If the line and the header are the same length, the default alignment will be used, which may or may not be the same as flush left.

The number of spaces between the columns isn't important, as long as there are spaces, but the width of the dashed header lines determines the width of the columns. You may find, when you test a table, that one column is too narrow. Increase the length of a dashed line to change the column width; add spaces between column entries in each row to make the columns line up again.

Building a Table

Lining up columns in a table may seem pretty tedious, but TED Notepad has a feature that will simplify this a great deal. Let's set up a "dummy table". Like this:

d6,double,triple,quadruple
---,-------,-------,----------
1,2,3,4
2,3,6,8
3,6,9,12
4,8,12,16
5,10,15,20
6,12,18,24

The columns are not lined up, except accidentally. We're just using commas to separate columns. Some of you may recognize this as Comma-Separated Values (CSV) format. If we were doing table entries that included long text, we'd just include a snippet of text, not the whole thing. We can add more text later. The dashed lines are one hyphen longer than the text in the headers.

Now, use the Columns & Numbers tool to line things up better: select
 Tools > Lines > Columns, Numbers.. from the menu. A dialog box will open. Our first concern is the output mask. We need to make it look like this:

  %1 %2 %3 %4

Each percent/number pair is a marker for one column of your final output. Anything between the column markers in the output mask, such as blank spaces, will show up between the columns in the actual, final text. In this case, we have four columns, so we have %1 through %4, separated with spaces.

Each of the markers has a tab below which defines how to select text to put in each column. To convert a simple comma-separated list like the one above into something resembling a table:

1. Select Columns from __ to __ on each tab.
2. Change the column numbers to 1 to 1 for column %1, 2 to 2 for the second column, and so on.
3. Set the delimiter for each column to a comma.

You can look at the preview box to make sure that the result looks something like this:

1    2    3    4
2    3    6    8
3    6    9    12
4    8    12    16
5    10    15    20
6    12    18    24

Clicking the Cut button changes your selected text to the column shown.

Afterwards, trim or insert a few spaces to make the columns line up pretty, either left-justified or right-justified. It's so much easier to let TED do about half the work for this than to line it all up from scratch. Add a line of dashes at the start and end of the table, and put blank lines between the rows.

d6	double	triple	quadruple
1	2	3	4
2	3	6	8
3	6	9	12
4	8	12	16
5	10	15	20
6	12	18	24

A Word About Structure, Format, Layout and Design

You're probably anxious to find out how to do fancy tables with every other row shaded, as you see in many RPG books. And you're probably wondering about other pretty format tricks. However, this is where we have to take a detour and talk about four concepts I've been tossing around without really distinguishing them from each other very much: structure, format, layout, and design.

The structure of a document is the most important part. We start with raw information, we separate the information into chunks by inserting section headers, we turn some information into bullet or numbered lists. It organizes information in a way that makes it easier to grasp and easier to refer back to.

The format of a document is the low-level decisions about appearance that can support the structure. Putting strong emphasis on a word, as I did in the first sentence of this paragraph, does not strictly speaking define the structure, but it helps to draw attention to the main concept of this paragraph. Similarly, indenting a block quote helps separate the quote from the rest of the document, drawing attention to it.

Both structure and format affect the appearance of the final output, but they are not concerned with the specifics of that appearance. The Markdown block indent marker doesn't define how much to indent the block, or whether all block quotes should be in a different font size or typeface. Strong emphasis does not necessarily mean "bold", even though that is usually the default.

I define layout and design in terms of the physical appearance of the page and the product as a whole. They are intertwined, but I see layout as the position of elements and white space and the flow of text around those elements, while design is the elements of appearance that relate to how the product is used (things like page headers or using a unique font for chapter titles.)

When you are working on a document and trying to keep it uniform across multiple output formats, you have to forgo thinking about many layout and design elements. You can't control layout or design using just Markdown, not only because there aren't any layout or design commands built into the Markdown standard, but also because layout and design depend on what the actual product is, and how it's displayed. Page layout for web pages is handled by your web browser. Page layout for an EPUB is handled by your ereader. Page layout for a PDF or printed document is handled by the software that makes the PDF, which in this case is the pdflatex renderer in MiKTeX. These things don't work the same, so if you make layout and design decisions for one, it's not going to look the same in the others.

One example is the placement of tables on a page. When you use Pandoc to turn your plain text table into an HTML table for either your blog or an ebook, the table shows up right where it is relative to the whole text.

Blah blah blah see this table. 

[TABLE] 

Here's how to use the table.

The table appears between the two lines of text.

However, when you turn the same source text into a PDF via LaTeX, LaTeX decides the best place to put the table. This is called a float, and it's something that happens with images as well, unless you tell LaTeX otherwise. For tables, this doesn't matter; LaTeX will probably make a better decision than you will, unless you have years of layout experience. The only thing you need to be aware of is to avoid referring to the table by position, as in "See the table below" or "see this table:". What you want to do is reference it by name: "See the Experience Table."

Images can be a little easier. There's a simple trick to make sure they don't float. There's a simple way to guarantee they get a caption, so that you can refer to the figure by name. I'll get to that in the next part of the tutorial. However, there are other things about positioning images and tables that are going to require different methods for different forms of output.

Shaded Rows

One example is the shaded table rows we were talking about earlier. It's now pretty much standard practice to shade every other row of a table, or to shade them in groups of three. I'm not going to talk about how to do that in a PDF yet, because we're going to have to learn about a lot of other things first. It's possible to do it in HTML output, like a web page, but this requires using an HTML-specific method: style sheets, or CSS.

I'm not going to go into CSS too much, and certainly not now. It's best to ease into this. However, I will point out this important fact: Markdown doesn't mind if you insert raw HTML into your document. For some versions of Markdown other than Pandoc, this was the only way to get get a table.

Fortunately, we don't have to deal with that. However, we can insert a style sheet in the middle of our document, using a <style> ... >/style> block. And the good thing is: this style block won't show up in other formats that don't use CSS.

If you do a table in Pandoc and output to a web page or blog post, then look at the source, you'll see the rows of the table marked either  <tr class="odd">  and  <tr class="even"> . The class attribute tells the web browser to use the defined style for that class. In this case, no style has been defined, so it just puts out a bland table. However, if you know CSS, or look up tips on the web, you can insert a style block that defines what to do for the "odd" and "even" classes. Here's a sample style block:

<style>
.odd {
      background-color: whitesmoke;
     }
.even {
      background-color: white;
      }
</style>

Put this at the start of your document, for now, and it will give you a shaded table. This is not the best place to put the style block, but we'll talk about that later.

EDIT: Some of my examples got treated as actual CSS commands. Should be fixed now.

Schedule Change

I was planning on doing the next installment of the layout/design tutorials on graphics. However, I've decided that I should do tables next, because the graphics discussion will probably expand into more than one installment and leads naturally into other issues relating to larger projects.

I've only just barely started the tables installment, though, so it won't appear tomorrow. Thursday, maybe.

Layout Tutorial: Structures and Templates

Here's Part 3 of the DIY layout tutorials for hobby press publishing.

Layout Tutorial 3: Structures and Templates

Part 1 of the DIY layout and design tutorials covered free programs and setting up an efficient workspace; Part 2 covered using Markdown and Pandoc for blog posts and draft versions of EPUB and PDF. This time, I'm covering the structure of longer documents, links, and the use of templates and repeated blocks of text.

Layout for Spells

Let's talk about something RPG writers and designers are likely to do: spells and magic items. Or special equipment, for non-fantasy settings. Both are pretty much the same: a standard block of quick information, a paragraph or two of description. Doesn't matter which order these are in, but the name of the spell or item comes first and usually stands out. This might be a typical spell format for Swords & Wizardry:

Hunger
------
> **Spell Level**: Magic-User, 1st\
> **Range**: 240 feet\
> **Duration**: hour

Makes living creatures feel hungry, affecting
negotiations or morale and possibly distracting
creatures from other actions. Affects creatures
of up to 4+1 hit dice; use the Sleep spell for
numbers affected.

There's a couple new things in that bit of Markdown text. First, for the spell's "info block", each line begins with a right angle bracket (greater-than sign). In Markdown, this means "indent". It's great for creating block quotes, for example. By itself, though, each line in the block quote would be run together as a paragraph; the backslash on the end of two of the lines forces the line to break. That creates the following layout for the spell:

Hunger

Spell Level: Magic-User, 1st
Range: 240 feet
Duration: hour

Makes living creatures blah blah blah...

Templates and Standard Boilerplate

What you should do, once you've set up a sample of a particular thing (S&W spell, OSRIC spell, artifact, tech item) is make a quick copy-and-paste duplicate in whatever document you are working on, change the wording in the duplicate to something more generic, like this:

Spell Name
----------
> **Spell Level**: Class, Level\
> **Range**: feet, yards, touch\
> **Duration**: minute, turn, hour, day

blah blah blah...

... and then select the duplicate and use File > Exclude.. to cut out that section and save it to a separate file. Save this in\proj\template\. In this case, I saved it as sw-spell.txt.

The \proj\template\ folder, as I mentioned in Part 1, is for text that you insert into documents and then change to suit a specific need, exactly like this one. Rather than retype the repeated material again and again, possibly from memory if you haven't written a spell or item description for a while, you solve your layout problems once and save it for further use. Insert it using File > Include.. and navigating to the template folder to select the appropriate file.

The \proj\std\ ("standard") folder can also include pasteable Markdown-formatted snippets, but it is meant for stuff you might have to call from the command line, thus needing a path that's as short as possible. For example, Pandoc has its own templates and reference documents that you do not copy and paste into your master document, but instead use a command-line switch: pandoc --template=\proj\std\booklet \proj\blog\spell*.txt -o \proj\spellbooklet.pdf.

A lot of the files you would put in the std folder will not be in Markdown format; it will be CSS files for EPUBs, files to include in the headers of web pages, LaTeX macro definitions, or PDF formats. But what you might also want to put in std is any boilerplate text, stuff that doesn't really change from project to project. For example, most of the Open Game License is just a huge block of text, usually set up to be in small print. Only the last two paragraphs (copyright information for Open Game Content used and material excluded as Product Identity) ever change. Shorter examples would be a Creative Commons license notification, or contact info, or even a block of Lorem Ipsum text to paste into a test document when you're working on a layout.

Headers

But back to our spell example. The third new thing in that sample was the way the name was marked:

Hunger
------

That line of hyphens under the spell name marks it as a header. The superficial effect of marking text as a header is that headers usually are a different size, possibly a different font or even typeface. Level 1 headers are usually large print and used for chapter or article titles. Level 2 headers are a little smaller¹ They are best used for sections of a chapter or article. Level 3 headers are smaller still and can be used for subsections or for marking individual items you want to include in a PDF's bookmarks.

Level 1 headers can be marked with a row of equal signs, while Level 2 headers are marked with a row of dashes. In this case, I used a Level 2 header for the spell name, with the idea that after I've written several individual spells for blog posts, I could later bundle together the spells in an article or ebook. I would write an introduction explaining any background for the spells; the title of the article would be a Level 1 header, marked with equal signs. Each spell's name would then be a section of the article or ebook.

There's another way to mark headers, and that's by placing pound (#) signs and one space at the beginning of the line, like this:

## Hunger

The number of pound signs is the header's level (in this case, Level 2.) Since the underlining method looks nicer and is more distinctive when scrolling through long texts to find a section, I use that for my Level 1 and Level 2 headers exclusively. If I need a Level 3 header (or 4 or 5,) I have to use the pound signs for those. The advantage to using the pound signs is that header levels can be changed quickly. Also, in some cases (when setting up tables or horizontal rules, for example,) a line of hyphens might confuse Pandoc and produce the wrong layout.

Structure

Headers aren't just for appearance, however. They define the structure of your document, which is going to be important when designing larger projects. When you are composing text, you don't want to worry about how things are going to look, aside from a few superficial things like emphasizing text. You want to focus on what you are saying and how your ideas are organized. Level 1 headers represent a large chunk of ideas: an entire chapter, an entire article. This gets broken up into smaller chunks (sections.) For example, an article on "ten scary spells" would be broken up into ten sections, one for each spell, plus maybe a preface and a follow-up section.

Structuring a document can help in the planning phase. For example, let's say you are going to write an article about barbarian tribes in some setting. You only have vague ideas; you're making this all up from scratch. You start by listing general things you know you need to cover, one per line:

Introduction
Barbarians vs. Civilization
Barbarian Tribes
Role of Barbarians
Playing Barbarians

Then, under each line, add a line of hyphens and two blank lines. That turns each of those lines into Level 2 headers. Next, come up with some barbarian tribe names and insert them below the "Barbarian Tribes" header, one tribe per line; if you have a concept but no tribe name, use a place-holder name like "Short Stabbing-Sword People"² When you have enough, you can add three pound signs and a space in front of each tribe name. Now, you can fill in paragraphs of text in each section, in whatever order you wish. If you only have one phrase or sentence that pops into your mind, find a section it would fit in, then add it. You can add more or fix grammar later. Eventually, your barbarian article is finished and has a structure.

Structure in a document also matters for the table of contents and for PDF bookmarks. I'll have more to say about the table of contents when I get to EPUBs, but if you use the "make PDF" filter explained in Part 2 (or pandoc master.txt -o master.pdf from a command line,) Pandoc will create navigation bookmarks in your PDF for every Level 1, Level 2, and Level 3 header by default. That's also what will be included in the Table of Contents. The default "header depth" can be changed, if you you only want Level 1 and 2 headers, or if you want to include levels below Level 3.

Knowing this, you can leave the depth set to the default and use #### for text you want to set apart (as if it were a header,) but that you don't want to include in the Table of Contents. This may be important if you want a short ToC but have a ton of items, spells, or monsters you plan to include.

Linking

Headers also create spots that you can link to directly, which is how the Table of Contents in an EPUB works. You can also use it to include references, such as "See the Hunger spell". How? You need to set up a link to the header's identifier. Pandoc will automatically create identifiers for every header by default; the docs explain in detail how to figure out the identifiers, but the short answer is that they are plain lowercase letters, numbers, dots, hyphens and underscores, without formatting, starting with the first letter in the header, with white space turned into hyphens. So, the "Layout for Spells" section near the beginning of this document would have an identifier of "layout-for-spells", while the Hunger spell is "hunger".

To create the link, you need to insert a list of reference links directly into your master document. This can be anywhere, but it must be separated from the other paragraphs in your master document by blank lines. I usually put a block of link references after the paragraph the links appear in or at the end of the document. Start with the list of identifiers:

blah blah blah layout natter
natter natter Hunger spell blah
blah blah blah natter

: #layout-for-spells
: #hunger

Each identifier has a pound sign in front of it, but this has nothing to do with Markdown. It has to do with the way HTML anchors work. Pick the word or words in the paragraph you want to turn into a link, like "layout", and put square brackets around it: [layout]. Now, copy that word, including the brackets, and paste it in front of the first line in the link reference: [layout]: #layout-for-spells. Similarly, you would place brackets around "Hunger" and insert that in front of the second line, so now the text looks like:

blah blah blah [layout] natter
natter natter [Hunger] spell blah
blah blah blah natter

[layout]: #layout-for-spells
[Hunger]: #hunger

The link references block itself doesn't appear in your documents. It's just a way to list what a link in the actual text will link to.

This is the simplest way to handle links. There's actually other ways Pandoc and Markdown can handle links, but I like this way because the list of links stands out and it's easy to save a standard list of links as a template, for example.

To make external links (on the web,) you would use a full URL, like this link I used earlier:

[Lorem Ipsum]: http://loripsum.net

This is going to be important for inserting images, but that's going to have to wait for the next installment.

---

1. except for on Blogger, where they are a lot smaller, for some reason.(BACK)
2. That's Saxons, by the way...(BACK)

Layout Tutorial: Master of Content

Layout Tutorial 2: Master of Content

Part 1 of the Layout Tutorial focused on what to install and where. Part 2 introduces a basic workflow and format techniques for simple RPG projects like general blog posts or things like house rules, magic items, or spells.

The Plain Text Process

Using TED Notepad or some other plain text editor is good because it promotes the first two goals I listed in the last post: "Have one master, many slaves," and "Keep it separated". You only want to do your main work -- your content -- once, and only do minimal layout tweaks for each product you create from that content (blog post or web page, ebook, PDF or final print product.) That means your master document should be as product neutral as possible, to simplify production in different formats. And nothing is as product neutral as plain text. Nothing avoids distracting layout decisions like plain text, either.

The process I use involves doing your text in the Markdown format. Markdown is a way of indicating minimal format features like emphasized text, bullet or number lists, or section headings without making your text an unreadable piece of crap. It's based on the way people formatted text in the pre-HTML email days, or even the pre-computer typewriter days. You break text into paragraphs by skipping a line, and you emphasize text by putting *stars* or _underscores_ around it. **double stars** makes it strong emphasis. Emphasis usually shows up as italics and strong emphasis as bold in a web page or PDF, and triple stars in that case will be bold italics, but "emphasis" is a concept, not an appearance; how emphasis and strong emphasis are displayed can be changed at the output level.

A Typical House-Rule Post

Let's start with a simple example: posting a house rule to your blog. We'll use a compact version of the armor/encumbrance rule I mentioned recently. You would start preparing your content this way:

Base Move is based on armor worn. For Fighters and Clerics:

Light/No Armor = **Move 12**
any Metal Armor = **Move 6**
any armor + carrying maximum weight = **Move 3**

Any other class has the movement rate halved, minimum Move 3. Anyone with Move 3
is considered overburdened, always acts last each round, and must rest 2 turns out
of every 6 turns of activity, instead of just 1 turn.

The length of each line doesn't necessarily have to match what I typed; as long as there's no white space between lines or at the start of a line, the Pandoc Markdown conversion will join lines together in a paragraph. The stars around the Move scores were a design choice; I want the Move scores to stand out (strong emphasis.) I could have put the emphasis around the armor type instead.

We probably don't want the armor/move lines to be joined together, so in TED Notepad, we can select all three lines and use Tools > Lines > Quote to put * (a star and a space) at the beginning of each line. That's how you format a bullet list. If you wanted to number the steps in a process instead, you would just put 1. in front instead.

1. Type each step on a separate line.
2. Select all the lines.
3. Select `Tools > Lines > Quote` and put `1. ` in front
   of each line.

I changed the numbers in the above example, but I could have used "1. " for every line. Pandoc doesn't care what the other numbers are. It only cares what the first number is; it will start the list with that number and go in sequence. Notice also that I continued step 3 on the next line. I actually didn't need to put spaces at the beginning of the continued line, as long as it's all one paragraph. I only did that to make it look nice in the text file. Like I said: Markdown is based on the way you would format things on a typewriter.

(Also, not important, but: the backticks I used in Step 3 are one way of marking verbatim text; in other words, text that isn't interpreted as Markdown format. It's probably not something you would need, but it's good to know that there are many other things in Markdown I'm not even going to cover. It's all in the Pandoc docs, though.)

Save any text you are working on in the appropriate location, such as \proj\blog\house-move.txt or ~/proj/blog/house-move.txt on Mac/Unix, before converting it in Pandoc.

If you are typing the entire post in your notes.txt file using TED Notepad, you can select just the part you want and use File > Exclude..to save (and cut) part of your notes to a separate file.

Creating "Slaves" for a Master Document

You need to use a command line or terminal, or some kind of script or batch file or workflow, to make Pandoc convert your Markdown text to HTML or some other document. Pandoc is pretty smart about guessing file format based on the extension, and it assumes .txt files are Markdown unless told otherwise, so the command is pretty simple: pandoc filename.txt -o docname.html The -o stands for "output", so that command creates an HTML version of filename.txt and names it docname.html. We can actually set up TED Notepad to do this for us, without needing to open a terminal or command line.

1. Select Tools > Text Filters > Manage List..
2. The dialog should be open on the Filters tab. Click New.
3. The Name should be something like "make HTML". The Command is pandoc %F -o \proj\%1.html. The Description can be blank for now.

Once you save this filter, try it out. Make sure you have the house-move.txt file open and select Tools > Text Filters > make HTML. You'll see that Execute contains pandoc %F -o \proj\.html and the cursor should be in the box labeled %1. Type blog\house-move and you'll see that Execute now contains pandoc %F -o \proj\blog\house-move.html. Click OK.

The %F is the full path to the current open file, so what Pandoc does is create an HTML version and save it in the \proj\blog\ folder. It shouldn't take long; you'll see a brief pop-up. What you need to do next is open it in your web browser. An easy way to do this is: open your browser and go to this location: file:///C:/proj/blog/. Change the C: to the appropriate drive, if necessary, or ~/ on Mac/Unix. This should open an index page of that folder, in most browsers. Bookmark that location (you'll use it a lot) and look through the list for house-move.html or whatever you named it. Click it to view; it should look something like:

Base Move is based on armor worn. For Fighters and Clerics:

• Light/No Armor = Move 12
• any Metal Armor = Move 6
• any armor + carrying maximum weight = Move 3

Any other class has the movement rate halved, minimum Move 3. Anyone with Move 3 is considered overburdened, always acts last each round, and must rest 2 turns out of every 6 turns of activity, instead of just 1 turn.

You can copy and paste this into a Blogger edit box, for example. I will warn you that Blogger has a dumb tendency to remove the lines between paragraphs. If you are going to upload web opages to an actual website, you'll need another filter, because this file is actually an HTML fragment, without the proper header information. Call the new filter make web page. The correct command for that is: pandoc --standalone %F -o \proj\%1.html.

Let's set up a couple other quick output filters. Make one named make ebook with the command pandoc %F -o \proj\%1.epub. This will turn a single file into a simple EPUB format ebook that you can read on your ereader or tablet. We'll be coming back to ebooks later, but this is a handy thing to have right now.

Assuming you've installed MiKTeX, make another output filter named make PDF with the command pandoc %F -o \proj\%1.pdf. This filter will take a while the first time it is run, or at least it did for me, because MiKTeX will want to download additional components. Unless you installed the complete version of MiKTeX; I didn't, so I had that little delay. It's not that difficult, though, and will go much quicker the second time you use it. The output will be a PDF (with an invisible LaTeX step you won't see.)

Pandoc has lots of output possibilities, as well as many options to tweak, but these are going to be what we will focus on for now.

Part 3 will look at structuring documents, making things show up in an index, and using templates or standard "boilerplate" to simplify the job and create a unified look.

Layout Tutorial: Getting Ready

Finally finished Part I of the promised layout and design tutorial.

Layout Tutorial 1: Getting Ready

RPG hobbyist publishers, or any DIY publishers, need free, DIY solutions. Free software for layout and publishing certainly exists, but tutorials for free layout and publishing seem pretty scarce.

Maybe this will help.

Scope of the Tutorials

I want to focus on what amateur DIY RPG hobbyists typically write, which is mostly free downloadable mini-products distributed on a blog. A few may be writing articles for zines. A few of you may be writing longer products, to sell on Lulu or RPGNow, or under contract with one of the many small RPG publishers.

The creation process I'm promoting here is:

1. Do your content first, once, and keep it the same across all formats. One master, many slaves.
2. Avoid making design decisions, like where to place tables or what fonts to use, while working on content. Keep it separated.
3. When thinking of design, think of structure first: What are your ideas? What order should they be in? How do you divide them into sections? Make the design fit the form.
4. Don't clutter up the design with lots of font changes, tons of clipart, or micromanaging the position of page elements. Keep it clean and simple.

I'll Focus on widely portable formats: first HTML, then EPUB, then RTF, then PDF.

Step 1: Get Your Tools

Doing all your content first, in a single master document, means doing it in plain text. This keeps you focused on non-layout issues first; once you have something to lay out, you can do your layout.
And plain text means you need a plain text editor. Full-fledged word processors can save as plain text, but you have to remember to do so, and you must fight against yourself constantly to keep from fiddling with fonts, pagination, margins, or columns, as well as the horrible quirks of a word processor's invisible markup. It's safer to switch to a pure plain text editor.

I've used Linux and OS X, but my skills for those are years out of date, so I can't offer specific recommendations for a text editor. For Windows, though, I'm going to recommend TED Notepad, because it has a feature that's going to make some other steps much easier, closer to being fully automated.

The next tool in the layout and publication chain for all platforms is Pandoc, a command-line format translation tool. For Windows, TED Notepad will help you avoid the command prompt, as I'll explain later. For Linux or OS X, you can create shell scripts or workflows to handle specific Pandoc tasks. The Pandoc extras page includes several add-ons to make things easier for those not using TED Notepad, such as Droplets for OS X.

Pandoc can turn plain text into many things, including HTML and EPUB, but you will probably want an additional dedicated EPUB editor, Google's Sigil. It will make style sheet changes easier. A Windows alternative, SPAB, is supposed to make turning text and a cover image into PDF, EPUB, and Kindle books simultaneously into a one-click process, but I wasn't able to make it work because my version of Windows may be too old.

Pandoc will create a PDF for you, but only if you have a PDFLaTeX engine installed. The one I tried is MiKTeX, and I had absolutely no problems. It sets itself up, and the first time you use Pandoc to make a PDF, MiKTeX will download and install any additional components it needs from one of the TeX depositories. Linux people probably have a LaTeX installation that came with their distribution. For OS X TeX, I've seen recommendations for BasicTeX.

There may be additional tools that will be useful, but I'm going to focus on the TED > Pandoc > EPUB and TED > Pandoc > MiKTeX pipelines, with optional editing of ebooks in Sigil.

Step 2: Set Up Your Workspace

Install Pandoc, Sigil, and a TeX/LaTeX package onto any computer you plan to use for your work. Then, set up your workspace. Windows has that annoying habit of trying to get you to use C:\Documents and Settings\a whole bunch of other useless subfolders\ blahblah\username\My Documents for everything. That's going to be a problem when using a commandline tool like Pandoc, so I recommend going to the root/top level of the C: drive (or whatever you use for a data drive) and creating a new folder with a short name, such as \proj. On Linux and OS X, you create it in your home directory, so the path is ~/proj. Or, create a proj folder on a USB thumb drive and take your workspace from computer to computer.

In your workspace, I recommend the following folders to start:

proj/
    blog/
    books/
    icon/
    map/
    pix/
    std/
    template/

The /proj/blog/ subfolder is an example of a specific project: articles you want to post to your blog. If you plan to submit articles to a zine, like Fight On! (better hurry...), you would create a /proj/FO/ folder to save your work in. If you write a larger project, like a module, you'd create a folder with a short name that is easy for you to remember: if it's about an ogre citadel, call it /proj/ogre/.

The /proj/books/ folder is not where you store stuff you are working on; it's for book projects you've finished and already published. Just drag or move your working folder into the books folder when you done to archive it.

The icon, map and pix folders are for graphics. Icons are stuff you're going to use across several projects, like logos, custom bullets/markers, and the like. A map is exactly what you think it would be in an RPG product. Pix are other graphics, such as cover images.

The std and template folders are for text and other non-graphic stuff that gets reused in many projects. Templates specifically are files that you modify for each project, such as a standard monster stat block. std, on the other hand, means "standard" (stuff that doesn't change) and includes legal boilerplate, contact information, headers, and style sheets (once you've figured out some standard styles.)

I saved the TED Notepad installation for last because you have the option of using the Windows installer or just unzipping it into some folder and making a shortcut. I did the latter, but I didn't do the smart thing and put it in the \proj\ folder. On Windows, it will work fine there, and if you accidentally forget to include a full path when using Pandoc from inside TED Notepad (you will...), you won't have to go looking for the file (it will be saved in whatever folder TED Notepad is in.)

I haven't tried it, but according to the TED Notepad website, it works under Wine on Unix. That means if you put TED and your project folders on a USB thumbdrive, you could potentially use TED on any computer. You'll have to read the instructions for Wine to set that up, though, because I've never done it.

Whichever way you decide to set up TED Notepad, or another plain text editor, open the editor for a test run. Start a new document, type:

Notes
=====

blah blah blah

... And save that file as \proj\notes.txt (Windows) or ~/proj/notes.txt (OS X/Unix. Oh, how I hate Microsoft for inventing an alternative way to write directories...) Now, select from the TED Notepad menu Favourites > Add this File. If you select Favourites again, you'll see the file listed at the bottom. You can have up to 50 favorites, but you won't need that many, since you're really only going to need files you will be referring to a lot and all the files you're working on for a given long-term project. Once you've finished a project, you can prune the unnecessary favorites using Favourites > Manage List..

I think having a generic "Notes" document is a good idea. Since TED Notepad is a low-resources editor, you can keep it open to notes.txt while browsing websites, reading forums and blogs, or studying PDFs. Copy URLs and brief ideas to notes.txt, expand them as you think of more stuff, move snippets to separate files when they get longer, and delete stuff that's been finished. Originally, I was going to recommend creating a to-do.txt and progress.txt as well, setting up text filters to cut lines from one and append them to another file... but although that works, I found I never really followed those guidelines, so why should you?

In the next part of the tutorial, I'll cover working with Markdown and TED Notepad to produce the simpler RPG documents.

Hex Sheet Specfile

People seemed to like the tilted coordinates for the hex sheet I posted earlier. Below is the specfile I used with mkhexgrid to get the small hexes with the tilted coordinates. I'm not actually sure they are half-inch hexes, I just assumed "100 pixels per inch, therefore make hexes 50 pixels high." They seem to be about right, though.

mkhexgrid places the coordinates relative to the center of the hex using distance from the center in pixels and direction (bearing) relative to "due east". Bearing 90 degrees is the top of the hex. With half-inch, 50 pixels high hexes, 16 pixel coord-distance is a smidge more than an eighth of an inch from the center, and the 150 degree coord-bearing means the coordinate is aligned with the hex face to the left (counter-clockwise) of the top of the hex. To change the tilt of the text itself, I set coord-tilt to 60 degrees (measured counterclockwise from the horizontal.)

# specfile for .5in hexes

output = svg
hex-height = 50px
image-margin = 50px
image-width = 850px
image-height = 1100px
rows = 18
grid-color = 0808FF
grid-thickness = 1px
grid-grain = v
coord-color = 0808FF
coord-format = "%02c%02r"
coord-font = Courier
coord-size = 8px
coord-bearing = 150
coord-distance = 16px 
coord-tilt = 60
center-style = n

Layout Tutorials

So, I've been thinking about the no-cost layout tutorials I promised to write... woah, a year ago this month. And actually, I've been doing more than thinking. I've been writing the first part, which is just about getting the right tools and setting up your workspace. Maybe the first two parts; it's getting kind of long. I test things as I go along to make sure the process actually works and that I'm recommending the right tools. Sadly, a tool I found a couple months ago that looked great (Self Publish a Book) didn't actually work, at least not on my system, so I had to ditch that and go back to a more primitive process.

The focus is mainly on Windows how-tos. I don't have a way to test Linux or Mac OS X options, and my experience with either of those is years out of date, so I can't give full how-tos for them. I can talk about two of the tools, which are cross-platform, and a third has non-Windows equivalents that are also free.

But that leads to a question. Right now, I'm going to suggest a process that requires four tools. Oh, and some fonts. All free, all easy to get, all easy to install. But still: would people actually want a how-to for a workflow that involves that many downloads?

For the record, after the set-up tutorial(s), each tutorial focuses on types of RPG publications, in order ranging from simple to more complicated. Here's a tentative sequence:

1. General set-up (program advice, installation, folder suggestions;)
2. Additional set-up (filters and files;)
3. Spell and magic item write-ups/blog posts;
4. Monster write-ups and handling images;
5. Personal EPUB zines;
6. Character classes and tables;
7. Writing for others and RTF/ODT export;
8. One-Page Dungeons and PDF formating.

After that, if I get into LaTeX (which would improve PDF formatting,) I could either merge that with #8 or do it as a separate tutorial, depending on how it goes (haven't tried it myself, yet, so I'm putting it far in the future.) And then move on to some alternatives, eventually trying out Scribus so I can give some advice on that.

Tutorials would be spaced out, about every three days to every week. I don't want to swamp the blog with nothing but posts on one topic. And, like I said, I've got to have time to work these things out first, myself. Right now, I usually do Markdown to HTML with Pandoc (which *is* part of the tutorial series,) but I haven't tried EPUB yet and use a commercial app (InDesign) for PDF, which isn't going to help people looking for PDF on the cheap.

I want to approach this as "OK, I've never done this before, here are my specific tasks that I'm sure lots of RPG hobbyists share. How do we do these things, specifically?" I think that will give me a perspective that might actually be useful, because hey, *I'm YOU*.

The Secret of EPUB

I guess I should get my butt in gear before the New Years Eve party, but I'm feeling kind of worn out. I have, however, been thinking again about the publication/layout tutorials I promised, along with the EPUB zines. The zines are slowed because I'm tinkering with content. I'm tinkering with it so much, I think I'll do a simple EPUB beforehand, so I can use it as the basis of the tutorial. I'll grab some posts I should really collect together for ease of use, edit them, and use them as sample documents. I'm thinking the posts on traps would be a good start, plus I'll probably do some kind of dungeon module as another example.

Why the focus on EPUB? I plan on ranting about that some time in the future. I'll talk about layout for PDF, too, eventually, but unless I discover something in the next few days, I think I've decided to do all the ebook versions of stuff I distribute as EPUB. This will probably shock some people, because there's a huge unwarranted bias towards PDF in the RPG community. Among other things, I think a lot of people don't know that there are free EPUB readers for desktop computers, as well as for tablets and ereaders.

And a lot of people don't realize that an EPUB is actually just a ZIP file. The text content is XHTML, the formatting is CSS. It's not really that scary. Sure, there are some extra XML files in there, but if you are just trying to get at the content and don't want to get a free ereader like calibre, you could just unzip the EPUB and ignore the extras; they are just there for indexing and other features that make the ZIP behave like an EPUB.

In Before The Lock

Blogger is going into read-only mode sometime today (and who knows how long that may last?) And I have some errands to run during the scheduled down-time. And I don't have much to say at the moment, because I'm mulling over some longer topics. So I'll just point to a post a couple days ago on Places to Go, People to Be that included a short comment and link about formatting with troff. I've never done that, specifically, but I've done the equivalent, which is to use Markdown in a plaintext document and then pass it through Pandoc to create HTML, RTF, or an OpenOffice ODT file (and ultimately a PDF.) Markdown's a good option, because you can force yourself to think about content and avoid the distraction of format and fonts until after you've got some work done. The kind of formatting you might *have* to insert while writing is mainly italics and bold, which is easy and intuitive when using Markdown: put asterisks around the word, exactly as I did around the word "have", with double asterisks for stronger emphasis. The other kind of formatting you might absolutely need to do is headers, which can be done by underlining a line with hyphens or equal signs, like this:

Chapter Title
=============

...or bullet lists or numbered lists, which are done in plaintext exactly how you'd expect them to be done, with an asterisk or number at the beginning of each line. There are other features in Markdown, but you don't absolutely need them, especially during the writing phase. You may need to put together tables, though, which is easier to do with Pandoc's extensions to Markdown and mostly just involves spacing data manually and underlining each column header, so again it's pretty easy to get used to. However, after some experience with formatting quirks, I think it's best to do each table as a separate text file and wait until later to combine all the elements.

Useful links:

• Markdown's main site, in case you want to use it
  without using Pandoc.


• Showdown, a Javascript version of Markdown, in case
  you want to try it out without installing Perl. I'm
  directing you to GitHub instead of the official site,
  because it looks like attacklab.net has been hacked by
  spammers.


• Pandoc, for translating text files into other
  formats.
• Edit to add a link to try Pandoc online; the default mode translates Pandoc's extended Markdown into HTML, which is what Showdown does, so this page is a good substitute.