...making Linux just a little more fun!

Last updated May 15 2005

  1. How do I become an author for LG?
  2. Acceptance policy
  3. Deadlines
  4. LG's "minimal HTML" guide
  5. Style guide
  6. After submission

1. How do I become an author for LG?

New authors are always welcome; the Linux Gazette is dependent on Readers Like You for its articles. Although we cannot offer financial compensation (the LG is purely a volunteer effort), you will earn the gratitude of Linuxers all over the world, and possibly an enhanced reputation for yourself and your company as well.

If you haven't written for LG before, the first thing you need to do is send a short bio to(for examples, see our authors list) along with a 200x200 picture of yourself. This bio will be reused for future articles until you submit an updated one.

(Note that your email address will not be exposed to spambots by LG: just like the addresses on this page, it will not be presented in text form, and thus will not be harvestable.)

Read the rest of this FAQ for topic suggestions and formatting requirements and submit your completed article to (Exception: "2-cent Tips", i.e., short bits of technical advice, should be sent to ). If you're unsure about the suitability of the topic to LG, e-mail an abstract of your proposed article to the above address, and we'll happily give you feedback.

2. Acceptance policy

If your piece is essentially a press release or an announcement of a new product or service, trim it down to a URL and a paragraph or two and submit it toas a News Bytes item rather than as an article.

The following types of articles are always welcome:

We have all levels of readers, from neophytes to gurus. In order to appeal to both, the "howto"-type articles should be centered around an interesting topic or task - even a complex one is fine - but should also contain clear, explicit instructions sufficient to replicate your results. If you see an article that is too technical or not detailed enough for your taste, feel free to submit another article that fills the gaps. Realize, as well, that articles age as time passes; the fact that we've had an article on, e.g., VMWare within the last couple of years should not discourage you from writing one yourself provided that you have new, updated, or different information to convey.

Authors retain the copyright to their articles, but readers are free to copy and distribute the articles as much as they please. Note: We'll happily accept articles previously published elsewhere, as long as the original copyright essentially amounts to the above, and does not prevent the article being re-released under the Open Publication License (OPL). LG's official copyright statement (in short, the OPL without the optional clauses) is at http://linuxgazette.net/copying.html.

Articles should be written in simple HTML, or even plain text; most other formats, including HTML created in FrontPage or MSWord, will be rejected unless they are easily convertable to the two acceptable formats. Please read the LG author's crash course in HTML and the LG author's style guide below.

The following was written in response to an author inquiry:

The article must be about Linux, about programming normally done on a Linux platform, etc. LG has a wide variety of readers, so technical articles, tutorial articles, human-interest stories and humor are all accepted. Rejected are mindless Linux advocacy and Microsoft-bashing that you can find plentifully in the advocacy newsgroups, and articles that appear to badmouth or slander a company unfairly.

The biggest criterion is, "Does the article provide new and interesting information?" An article may overlap a previous article in content, but is it a 100% overlap or is there any new information or a different perspective? We do ask that authors use the LG search engine to look for previous articles about the same topic and link to them if appropriate. This makes it easier for readers to find all the useful information LG has on a certain topic.

There is no specific word limit on article length. Most articles are 5-20 screenfulls of text, but they can be of whatever length necessary.

For their first article or two, new authors are encouraged to send a short summary or outline before writing it to verify that it will be acceptable.

3. Deadlines

The article submission deadline is seven days before the end of the month, unless US holidays interfere (these would move the date back by their own length.)

Since we're not a paper magazine, we don't have a certain amount of space to fill. If you miss a deadline, don't fret; just send your article in anyway and it will go into the following issue.

4. LG's "minimal HTML" guide

Create the file using any plaintext editor. Put a blank line between paragraphs and begin each paragraph with <p>.

An actual HTML document contains headers and footers - i.e. 

<html><head><title>...</title></head><body>
at the top and 
</body></html>
at the bottom. In a Linux Gazette article, however, these are neither used nor at all useful, and will be removed if sent; instead, the first two lines of the file should be 
author: your_last_name
title: Article Title
Note that there's no markup used around these lines: they are simply text, just as you see above. These will be used to generate the article and page title, as well as a link to your bio.

Place <h2>...</h2> around section titles, with a blank line above and below. You may use h3 for subsections, h4 for sub-subsections, etc, on up to h6. h1 is used by LG for the article title.

Place <pre>...</pre> around program listings, output, configuration file text, and anything else which must line up vertically. <pre> goes on its own line above the block, and </pre> on its own line below. Everything inside this block will appear in a monospaced font, and indentations and line breaks will be displayed verbatim.

To display a literal "<" in your article, type &lt; instead. For ">", type &gt;. For "&", type &amp;. Otherwise, the browser will try to interpret them as parts of HTML tags rather than displaying them. Look especially closely at program listings since these symbols are frequently used in shell commands or mathematical expressions.

There are other HTML tags (br, em, strong, ul, ol, dl, img) you may optionally use to jazz up the document; see any HTML tutorial for their syntax and meaning.

5. Style Guide

Keep the HTML as simple as possible. Linux Gazette is read on a wide variety of browsers and hardware, and we try to accomodate as many readers as possible. CSS markup, for example, will always get removed - so don't bother adding it in the first place.

Please bear in mind that the Linux Gazette is distributed as part of several CDROM/DVD collections, and that many people read it off-line; as a result, any off-site links become useless, and pointing to, e.g., sample code on your web site destroys the article's readability and usefulness. There is, however, a limiting factor from the other perspective as well: many of our readers pay for their connections by the kilobyte, and large article attachments, particularly those that are not of broad interest, represent an unfair load on them. Therefore, the LG policy is an attempt at a compromise between the two: if your referenced content does not exceed 250kB total, please include it as part of your article submission; otherwise, please post it somewhere accessible and provide a link.

Good
  • <p> before paragraphs (</p> after paragraphs optional).
  • Standard markup tags (<a>, <em>, <strong>, <code>, <blockquote>, <ul>, <ol>, <dl>, etc).
  • <h2> or <h3> around section headers.
  • <pre> around program listings and output. (Please also make a text file of any program listings that are longer than 20 lines or so; see below.)
  • Images. Include the alt=, width= and height= attributes in the <img> tag, i.e. 
    <img src="misc/author/file1.jpg" alt="Description of picture" width="140" height="80">
    If the image is > 600 pixels in width, either shrink it or link it. Use PNGs or JPGs, make the file size as small as possible - and definitely no GIFs!

OK, but don't overuse

  • Local style declarations (e.g., <p style="width='80%'">). These will mostly be deleted, or overridden by the LG stylesheet.
  • Tables. Use mainly for columns of data; avoid for layout unless it's absolutely necessary. Often, <dt> and <dd> are actually what you need.
  • Fonts and colors.

Bad
  • Stylesheets.
  • Underlining (<u></u>). This makes the text look like a link. Replace with <em>, and all will be fine with the world.
  • Decorations and doodads on section headers. Sometimes these are tolerated for variety; other times, they go "poof".
  • Extra <br>'s and &nbsp;'s to achieve precise indentation or vertical space. Much of that stuff will be lost anyway when people use a browser that is different from yours.
  • Platform-specific fonts. The only words you need are "helvetica" (sans serif) and "courier" (fixed-width). The default is roman (serif).
  • Javascript.

Name the article author.html (where "author" is the author's last name in lowercase). If you have images, program listings, or other companion files, place them in a subdirectory misc/[author]/ and have your hyperlinks point there.

If you have long program listings (e.g., longer than 20 lines or so) that do not require a line-by-line description, abstract them into a file called misc/[author]/[program].[language].txt and link to them in your article, thus: 

The code for this example may be found <a href="misc/jones/trip.sh.txt">here</a>.
The ".txt" extension ensures the browser will not try to interpret the contents. Since it's a text file rather than HTML, you should not escape the "<", ">" and "&" characters.

6. After Submission

So, you've submitted your article. At the time that you wrote it, it was the most wonderful bit of prose ever released into the wild, flights of fact and fancy unparallelled in history - but now that the end of the month (and actual publication) approaches, you can see... umm, certain improvements that could be made. Not that there's anything wrong with the original, of course, but - a bit of clarification never hurts, right? So, you set out to revise your brilliant treatise and resubmit it...

If this is what you were about to do, STOP! What you'd be doing is creating a fork: a second, divergent version of the material. You see, at this point, the article has probably been proof-read, possibly heavily corrected with regard to the HTML, maybe even had some of the material moved around a bit - and all of this work would have to be re-done if you were to resubmit your original version with corrections. As a result, your "new" submission may well be rejected.

So, what, is correction after submission not possible?

It is - in fact, it's very easy if you follow procedure. That is, simply contact the editor () and say that you want to add/change/correct something. If it's a minor change, just submit a diff (i.e., show what you want changed) and we'll apply it. If the changes are more comprehensive than that, and it's not too close to the publication date ("too close" being a constantly-changing variable; you'll just have to ask and find out), we'll 'freeze' your article and send you the working copy, which you can then correct and send back to us.

A good idea whose time has come

(thanks to Barry O'Donovan for setting a good example)
If you've written an article that mostly concerns or describes a specific piece of software, you may find it of benefit to notify the author of that software. Not only is it a pleasant and courteous thing to do, but they may have a salient comment - and you will have the security of having had your article vetted by the number-one expert. We will usually be happy to post the resulting exchange in the Mailbag section (assuming that you've asked your correspondent for permission to do so and had it granted.)
Tux