Image will be floated onto the nearest dedicated image page, where they will be placed in order, two per page, with captions below each image.  Use even multiples of floating images per chapter; generally two is plenty.

Floating images have a fixed width of 3.25".  Width:height ratios may be between 4:3 and 3:2 (which covers the vast majority of consumer digital cameras), as long as the ratio selected is used consistently.

Minimum permissible resolution: 1024x768 (3:4) to 1024x683 (3:2)
Maximum recommended resolution: 2048x1536 (3:4) to 2048x1365 (3:2)

Vertical floated images are not recommended, use fullpage instead.  Square images are presently not supported in any meaningful way and should not be used, since fullpage will distort them into rectangles and floated images will grab their own page.

The image is laid out so it covers an entire page, with no caption.  Particularly useful for maps.  If the width is greater than the height, it will be rotated 90 degrees counterclockwise (by default; see below).

Despite the name, a fullpage image is sized only 4.15"x7.31", as 0.4" width must be reserved for the gutter (inner fold) and 0.25" for the bleed (spare to account for cutting errors).   For maps, width:height ratio should be 0.568:1; for photographs, up to 0.666:1 (2:3) is tolerable.  Images that do not fit the ratio will be stretched to fit automatically, which reduces quality and may look awkward.  Sample sizes:

	Exact dimensions	Maximum allowed dimensions
Minimum permissible resolution	1245x2193	1280x1920
Maximum recommended resolution	1709x3008	2000x3008

If necessary, you can force an image to be rotated by an arbitrary number of degrees by adding the optional argument angle:

[[Image:filename|print=fullpage|angle=-90|description]]

The angle can be any value, positive or negative, although -90 (rotated one quarter clockwise) and 180 (rotated upside down) are probably the most useful options.

See the split command to split an image across two adjacent pages.

NOTE: Use of this tag forces a pagebreak: if placed after a header, the pagebreak goes right before the header, otherwise the break is inserted then and there.  For most articles with lead images, this means that fullpage images are best placed after Understand, in the Get in/Get around sections.

Inline images are placed into text at (almost) the precise spot where ordered, and should be used only for small diagrams that correspond directly to the text, eg. itinerary routes or maps of archaeological sites.  Image layout is automatically selected by Yucca:

• If the image is wide (horizontal), it will be laid out across two columns (width 3.5").
• If the image is tall (vertical), it will be laid out in one column (width 1.6").

Image width in pixels should be as follows:

Wide (two-column) image: 1050 to 2000 pixels wide
Tall (one-column) image: 480 to 900 pixels wide

Image height is flexible, but the maximum height of an inline image is 5.5", exceeding which will cause the image to be scaled down.   Some sample inline image minimum sizes:

Description	Type	Dimensions (pixels)	Dimensions (inches)
Half a single column	One column	480x675	1.6"x2.25"
One third of a page	Two columns	1050x577	3.5"x1.83"
One half of a page	Two columns	1050x675	3.5"x2.25"

And yes, those are very small -- take care to ensure that the end result is still legible at that size!

The image is printed at the beginning of a chapter, with no caption.   This tag can only be used once per chapter and should only be used with horizontal images.  Lead images are always 3.25" wide and the same sizing restrictions as for float apply.

Having a lead image is recommended, but not obligatory.  Often, though, a single lead image (and maybe a map) suffices to illustrate the chapter.

Takes a large image and splits it into two horizontal halves, pasting them on adjacent pages.  Handy for double-page city maps. The recommended size is 3418x3008 (= two fullpage images). While any size is now accepted, don't stray too far from the ideal ratio of 1.14:1 or use images with vertical sizes of under 2000 px.
The rarely used vsplit does the same, only splitting a long, skinny image into two vertical halves. Occasionally used for long, skinny maps; the recommended size is 1709x6016 (0.39:1).
Note: Use of this command forces a pagebreak or double pagebreak to ensure that the split image starts on a left page.  As the second page of a chapter is always left, placing the image at the end of Understand or Get in usually works nicely.

Maps

Transforming a "normal" map into a printable one is probably the most time-consuming part of creating a printable guide.

Wikitravel Press strongly recommends using OpenStreetMap for creating maps, see Wikitravel: How to create a map. If you are stuck with a legacy map, you must use the high contrast version of the standard Wikitravel map template.  In particular, ensure that you have the Bitstream Vera Sans font installed (it can be downloaded for free from here if you don't have it). For both OSM and handmade maps, any exported files must follow the image size and restrictions above.   It is highly recommended, in fact nearly obligatory, that you print out any maps at correct size in order to judge whether they are usable in a guidebook.

Maps should generally be formatted as fullpage images.  Very small or highly topical maps should be placed inline instead, with two-page maps can be used with splut.
Tip: when creating maps in Inkscape, note that the height ("H") and ("W") are visible and editable if you have an object selected.  Select an appropriate ratio in pixels, do not trust the "DPI" or "inches" values (unless you've calibrated your map accordingly).  Instead, after exporting to the correct pixel count, you can use Gimp's "Image > Print Size..." command to set size in inches correctly.  (This is not necessary for Yucca, but is handy for your own test prints.)

Special tags

The followed special tags for Yucca use are currently defined.

<!--PRINT
content
PRINT-->

Note: You must use the exact strings "<!--PRINT" and "PRINT-->", no whitespace or lowercase letters allowed.

Any content placed in the <!--PRINT block will not be displayed by the website, but will be imported as is into the printed guide.  This is somewhat obsolete now that print=split has been implemented.

{{pagebreak}}

Forces a page break at the current location.  Should be used sparingly, ideally not at all.

{{web|...}}, or

<!--WEB-START-->
...
<!--WEB-END-->


The opposite of PRINT: anything placed in the "web" template or WEB-START/END block is displayed online, but not in printed guides.  A typical usage would be to remove references to articles that are not included in the book:

...and that's how you get in.  {{web|See the [[Outer Bongoland]] article for further details.}}

This shows up like this online:

...and that's how you get in.  See the [[Outer Bongoland]] article for further details.

but like this printed:

...and that's how you get in.

Quirks

Some of these straddle the line between bugs and features, and could probably be fixed with a suitable application of elbow grease.  If one of these is really bugging you, let me know, and I'll see what I can do.  See also the Yucca master bug list.

Infoboxes

Images within infoboxes may fail randomly.

Listings

All listings should be formatted with listings tags.  It is recommended that listings be in one single line, without carriage returns, although multiline listings are now corrected with a warning. Markup within the listing description is OK, but markup in the attributes (address etc) will be ignored or cause random flakiness.  (This is not a major problem, as Wikitravel the site doesn't support such markup very well either.)   Unknown attributes are ignored with a warning message, while mismatched quotation marks mess up listings very effectively.

Lists

Due to the narrow columns of the printed guide, bulleted lists are flattened out (un-bulleted) automatically.  If you absolutely must have a visible list, use a double bullet (**), or a numbered list (#).  Triple bullets or higher should be avoided.

Tables

Only limited table support has been implemented. Style, colspan, and rowspan attributes are ignored. At present, any tables get automatically rotated sideways and packed into one column.

Back to the Handbook