Published by Linux Journal

Front Page  |  Contents  |  FAQ  |  Archives  |  Mirror Sites

1. How can I become an author? How can I submit my article for publication?
2. Upcoming article deadlines
3. The LG authors' crash course in HTML
4. The LG authors' style guide

1. How can I become an author? How can I submit my article for publication?

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

New authors are always welcome. Read the rest of this FAQ for topic and format suggestions and submit your completed work to articlesubmission@linuxgazette.com. If you're unsure whether the topic is appropriate, email a short description of your proposed topic, an abstract, to the same address and you will be informed of its suitability. The goal of Linux Gazette is to be an open community of contributors. There is no editor as such and we're relying on authors to be self-editing. You know as well as anybody what topics are interesting to the community. Additionaly, assume that your article is publishable, at most we'll take a cursory glance at it, spell-checking and grammar are the author's responsibility.

The following types of articles are always welcome:

• technical articles of a HOWTO nature. (How to set up a program, how to maintain it, my experience running a program even if I'm not an expert, etc.) For ideas about possible articles, look in the Mailbag for questions that keep recurring. Explicit requests for articles appear at the top of the "Help Wanted -- Article Ideas" section. Even if you're not an "expert", an article discussing how you arrived at a solution by trial and error, and what problems you encountered along the way, will be of interest to many readers. These real-life experiences are one of the unique things LG can offer, because it's missing in most standard documentation.
• Articles demonstrating the use of Linux in an industry or environment where it might not be commonly expected.
• Software reviews, as long as it is a balanced review and not simply an advertisement. Comparing the pros and cons of this program with similar programs is a plus.
• Reports from conferences, etc.
• Anecdotes, lighthearted stuff, etc.
• Other areas I haven't thought of.

We have all levels of readers, from newbies to gurus, so articles aiming at any level are fine. 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.

Articles not acceptable include one-sided product reviews that are basically advertisements. Mentioning your company is fine, but please write your article from the viewpoint of a Linux user rather than as a company spokesperson.

If your piece is essentially a press release or an announcement of a new product or service, submit it as a News Bytes item rather than as an article. Better yet, submit a URL and a 1-2 paragraph summary (free of unnecessary marketoid verbiage, please) rather than a press release, because you can write a better summary about your product than the NewsBytes Editor can. The submission address for News Bytes is: bytes@linuxgazette.com.

Articles not specifically about Linux are generally not acceptable, although an article about free/open-source software in general may occasionally be published on a case-by-case basis.

Authors retain the copyright to their articles, but readers are free to copy and distribute the articles as much as they please. LG's official copyright statement is at http://www.linuxgazette.com/copying.html.

Articles should be written in simple HTML. 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. (Occasionally we may accept an article about a non-Linux open-source topic.) 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 criteria is, "Does the article provide new information, something that hasn't been published in LG in the past year?" 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 and Index of All Issues to search for previous articles about the same topic and link to them. This makes it easier for readers to find all the useful information LG has on a certain topic.

There is no word limit. Most articles are 2-12 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 it will be accepted.

2. Upcoming article deadlines

Issue	Deadline for Articles	Comments
#89 April 2003	Monday, March 10, 2003	Early due to Editor's schedule
#90 May 2003	Wednesday, April 23, 2003
#91 June 2003	Monday, May 19, 2003	Early due to Editor's schedule
#92 July 2003	Monday, June 23, 2003
#93 August 2003	Monday, July 28, 2003
#94 September 2003	Monday, August 25, 2003
#95 October 2003	Monday, September 22, 2003

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

3. The LG Author's Crash Course in HTML

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

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 < instead. For ">", type >. For "&", type &. Otherwise, the browser will try to interpret them as parts of HTML tags rather than displaying them. Look especially in 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.

A complete HTML document requires

<HTML><HEAD><TITLE>...</TITLE></HEAD><BODY>

</BODY></HTML>

4. The LG Author's Style Guide

Keep the HTML as simple as possible. Linux Gazette is read on a wide variety of graphical and text browsers, on new and old hardware.

Word processors (StarOffice, Microsoft Office) and HTML editors are notorious for doing the "bad" things below, in an attempt to make the HTML document look exactly like the word-processing document. Readers care about your text, not about your fancy formatting. If your word processor has an option to produce simple HTML without styles, please use it. Or save the document as text and add the simple HTML tags by hand. (The <P> before paragraphs and <PRE>...</PRE> around program listings are the only tags that are vital.)

Good

• <P> before paragraphs (</P> after paragraphs optional).
• Standard markup tags (<A>, <EM>, <STRONG>, <CODE>, <BLOCKQUOTE>, <UL>, <OL>, <DL>, etc).
• <H1> around section headers. Use this instead of a bold paragraph--that's what it's for!
• <PRE> around program listings and output. (Please also make a text file of the program listing; see below.)

OK, but don't overuse

• Images. Include the ALT=, WIDTH= and HEIGHT= attributes in the <IMG> tag. If the image is > 600 pixels wide, link to it rather than using an <IMG> tag. PNG or JPG only, no GIFs.
• Tables. Use mainly for columns of data, not for layout.
• Fonts & colors.

Bad

• Styles.
• Decorations and doodads on section headers. Sometimes these are tolerated for variety; other times they are removed by the Editor.
• Extra <BR>'s and  's to achieve precise indentation or vertical space. The reader cares about your text, not about your fancy formatting.
• Platform-specific fonts. The only words you need are "helvetica" (sans serif) and "courier" (fixed-width). The default is roman (serif).
• Javascript.

Articles may be of whatever length necessary. 2-15 screenfuls is typical.

At the top of the article or in the accompanying e-mail, clearly state: title, author's name, author's email (as it should be published) and bio. The bio is a few sentances about you for readers who are curious. It may be professional or personal, funny or serious, whatever you wish. See the bios at the bottom of most articles for examples.) The same bio will be reused for future articles until you submit an updated one.

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

If you have images, please include the ALT text, WIDTH and HEIGHT in your IMG tags. Proper form is:

<IMG ALT="Alterate text" SRC="misc/author/file1.jpg" WIDTH="140" HEIGHT="80">

If you have inline program listings a user might want to run without having to type them all in by hand, please place a second copy of each listing in a text file called called misc/author/program.language.txt and put a hyperlink before the PRE block, thus:

bla bla bla this listing:  (<A HREF="misc/author/trip.sh.txt">text version of this listing>)