Linux Magazine uses a simple scheme for marking up text. The scheme allows for emphasis of words, phrases, and product names; delineates blocks of code; and creates simple tables, among other things.
The marked-up text that you submit is then edited and ultimately processed by tools that produce the printed page (with the help of Quark) and HTML for the web site.
The Linux Magazine scheme is similar in spirit to the Plain Old Documentation (POD) format used in Perl documentation, and like POD, the intent is simplicity, not power. You need not learn an extensive vocabulary to write for Linux Magazine.
All articles have headers, sections of text separated by subheads, and may include special elements such as listings, figures, screen shots, and tables. All articles must end with a bio of you, the author.
Headers
All articles must start with four headers: HEAD, DECK, TOC_LINE, and AUTHOR.
HEAD. This is the title of the piece. For columns, this is the name of the column. For features, this can be slightly humourous. Since this is a title, the HEAD should use title case.
DECK. This is a short subtitle of less than ten words. For features, if the HEAD was humorous, then the DECK should be more serious and “academic.” The DECK should be written in sentence case and should omit the trailing period.
TOC_LINE. This is a 25-40 word blurb that describes the article. It’s best if this is catchy to draw the attention of the reader.
AUTHOR. Your name goes here.
Here’s an example:
HEAD: XML Schema Languages
DECK: Why and how to validate your XML documents
TOC_LINE: Validating XML documents reduces stress. Here are four different ways to do it.
AUTHOR: Norman Walsh
Subheads
An article is composed of sections, and each section has its own title called a subhead. The purpose of the subhead is to divide the article into thematic sections. If you’d like, subheads can be clever.
Here is an example:
SUBHEAD: Framebuffer Kernel Options
To use framebuffer support, you must enable it in your kernel. Many distributions ship with this support active, but it’s easy to disable it when you recompile your kernel. In fact, if you don’t know what the options do, it’s often safer to disable the framebuffer support when you recompile your kernel. Incorrect configurations can easily result in completely black displays when you boot.
Linux Magazine does not use second-level subheads.
Text Effects
You can use three text properties: bold, italic, and monospace. Use B<>, I<>, and C<> for bold, italic, and monospace, respectively.
Use bold very sparingly. It’s good to use in bullet lists to emphasize some text. For example:
* B Choose the fastest processor you can afford.
* B With disk prices dropping to less than $1 per gigabyte, stock up on hard disk space.
Italics should be used to introduce new terms appearing for the first time (typically where you define the term). Italics should also be used for file names and directory names (including Linux, Unix, Mac, and Windows file and directory names).
Also use italics for Linux command names, hostnames, user names, group names, and references to buttons in a graphical user interface. Italics should also highlight the names of documents, such as the GNU Public License or the Digital Millenium Copyright Act.
By convention, please use italics to highlight the first occurrence of any product name or a specific version of a product. You can also use italics to refer to the names of open source projects.
Use mono-spaced text to show specific Unix commands that the reader should repeat. You should also use monospace for all code listings and the contents of any files. For example:
Doing C< sort | uniq -c> would work, but do you want to do this? The following code accomplishes the same thing.
The monospace mark-up element is special in that it also has a multi-line form that you can use for code samples. Here’s a sample:
There are often times where you want to discuss something, but doing so would totally disrupt the flow of your text. Sidebars allow you to present some tangential information, and put it off to the side in a box. They should usually be referenced by the sidebar’s title.
< BEGIN Sidebar One -- “Scheme vs. Lisp” >
To the uninitiated, Scheme and Lisp look a lot alike, but looks can be deceiving. There are actually quite a few differences between these two languages.
< END >
You should refer to the sidebar by its name, not its number (e.g., ‘for more information, see the sidebar on “Scheme vs. Lisp”’).
Code Listings
Code that is short enough to be inserted “inline” (within the text of the article) should be properly marked within C< > sections. Each line of code should be no longer than 41 characters, 45 at the absolute most. Inline code listings should not exceed 6-8 lines.
Longer listings or code with long lines should be set in their own listing section. Each listing is required to have a title, but may be referred to in the text by its listing number. These longer code listings should have line numbers prepended (you can use cat- n).
Each indent in code should be exactly two spaces.
When referencing functions in your text, append a set of parentheses after the function name to help the reader.
The canonical “Hello, world!” program can be seen in Listing 1.
< BEGIN Listing One -- The “Hello, world!” program in Ruby >
C< 1 blah blah blah blah blah 2 blah blah blah blah blah 3 blah blah blah blah blah 4 blah blah blah blah blah … 10 blah blah blah blah blah >
< END >
Figures
If you want to include some images, screenshots (or even ASCII art to be converted into an illustration), they should be referenced by number (spelled out).
A screen shot of this amazing thing can be seen in I
< BEGIN Figure One -- Screen shot of something > < INSERT FILE: screenshot.png > < END Figure One >
Command Sequences
A sequence of commands should follow the same guidelines as for inline code listings. If they are too long or wide to set inline, they should be broken out as separate listings and/or figures.
Use the “# ” and “$ ” characters as prompts to represent commands that should be run as root, or do not need to be run as root.
Now run the following commands:
C< $ su2 Password: xxxxxx # wall ‘Hello, everybody!’ >
Tables
Tables are set off in separate boxes just as listings and figures are. You can refer to a table either by its name or its number.
The notation for tables is as follows:
< BEGIN Table One -- Tomcat environment variables >
Environment variable|Value
C|Your Java installation directory.
C|The Tomcat installation directory.
C|Command line switches to pass to the Java Runtime Environment.
< END >
The first row of the table is used as the table header. Subsequent rows are used as table rows. Each column is separated by the| (“pipe”) symbol.
Biography
At the end of your articles, include a very brief autobiography of about 25 words. You should include an email address for readers to contact you.
BIO: Glenn McAllister is a part-time committer on the Jakarta Ant project. He can be reached at glenn@somanetworks.com.
Comments
During the article writing process, drafts are exchanged back and forth between writers and editors. These drafts have feedback added to them in the form of comments. They have the following form.
[MS: this is a comment from Martin Streicher ]
[Ed.: This is a different comment notation ]
Miscellaneous
Lists that are embedded in the main text should have a comma separating each element in a list, even between the penultimate and final elements. For example, “apples, oranges, and lemons”.
Quotation marks should be used when refering to titles of articles, columns, web pages, or subheads in the article itself. References to the name of magazine itself should be italicized.
Quotation marks should be used when referring to GUI items that are not buttons (e.g., labels, checkboxes, tabs, menu items)
If punctuation immediately follows a word that is in italics, include the punctuation in the italicized text. For example,
You can use I or
When you refer to the labels of figures, listings, and tables, put the names in italics.
In general, when using the term “open source” as an adjective, the phrase should appear in lowercase. When referring to “open source” as a movement, community, or philosophy, it should be capitalized.
Spell out each acronym the first time it appears in your article and follow that immediately with the acronym in paretheses. Then use the acronym in the rest of the article.
Gotchas and Suggestions
The only special characters to watch out for are < (“less than”), > (“greater than”), and | (“pipe”). If you need to use < or > anywhere in your article, use their HTML equivalents. Pipe may be used anywhere except in tables. Again, if you need to use a pipe in your table, use the HTML equivalent.
Use active voice and present tense. For example, instead of “Clicking on the button will open a window,” use “Click the button to open the window.”
Use contractions to keep the article informal.
Address the reader as “you.” Avoid refererring to “we.”
If you have questions, please send email to
class="emailaddress">mstreicher@linux-mag.com. You can always embed a note in your article to request special formatting. When in doubt, your editor will do the right thing.
Linux Magazine uses a simple scheme for marking up text. The scheme allows for emphasis of words, phrases, and product names; delineates blocks of code; and creates simple tables, among other things.
The marked-up text that you submit is then edited and ultimately processed by tools that produce the printed page (with the help of Quark) and HTML for the web site.
The Linux Magazine scheme is similar in spirit to the Plain Old Documentation (POD) format used in Perl documentation, and like POD, the intent is simplicity, not power. You need not learn an extensive vocabulary to write for Linux Magazine.
All articles have headers, sections of text separated by subheads, and may include special elements such as listings, figures, screen shots, and tables. All articles must end with a bio of you, the author.
Headers
All articles must start with four headers: HEAD, DECK, TOC_LINE, and AUTHOR.
HEAD. This is the title of the piece. For columns, this is the name of the column. For features, this can be slightly humourous. Since this is a title, the HEAD should use title case.
DECK. This is a short subtitle of less than ten words. For features, if the HEAD was humorous, then the DECK should be more serious and “academic.” The DECK should be written in sentence case and should omit the trailing period.
TOC_LINE. This is a 25-40 word blurb that describes the article. It’s best if this is catchy to draw the attention of the reader.
AUTHOR. Your name goes here.
Here’s an example:
HEAD: XML Schema Languages
DECK: Why and how to validate your XML documents
TOC_LINE: Validating XML documents reduces stress. Here are four different ways to do it.
AUTHOR: Norman Walsh
Subheads
An article is composed of sections, and each section has its own title called a subhead. The purpose of the subhead is to divide the article into thematic sections. If you’d like, subheads can be clever.
Here is an example:
SUBHEAD: Framebuffer Kernel Options
To use framebuffer support, you must enable it in your kernel. Many distributions ship with this support active, but it’s easy to disable it when you recompile your kernel. In fact, if you don’t know what the options do, it’s often safer to disable the framebuffer support when you recompile your kernel. Incorrect configurations can easily result in completely black displays when you boot.
Linux Magazine does not use second-level subheads.
Text Effects
You can use three text properties: bold, italic, and monospace. Use B<>, I<>, and C<> for bold, italic, and monospace, respectively.
Use bold very sparingly. It’s good to use in bullet lists to emphasize some text. For example:
* B Choose the fastest processor you can afford.
* B With disk prices dropping to less than $1 per gigabyte, stock up on hard disk space.
Italics should be used to introduce new terms appearing for the first time (typically where you define the term). Italics should also be used for file names and directory names (including Linux, Unix, Mac, and Windows file and directory names).
Also use italics for Linux command names, hostnames, user names, group names, and references to buttons in a graphical user interface. Italics should also highlight the names of documents, such as the GNU Public License or the Digital Millenium Copyright Act.
By convention, please use italics to highlight the first occurrence of any product name or a specific version of a product. You can also use italics to refer to the names of open source projects.
Use mono-spaced text to show specific Unix commands that the reader should repeat. You should also use monospace for all code listings and the contents of any files. For example:
Doing C< sort | uniq -c> would work, but do you want to do this? The following code accomplishes the same thing.
The monospace mark-up element is special in that it also has a multi-line form that you can use for code samples. Here’s a sample:
There are often times where you want to discuss something, but doing so would totally disrupt the flow of your text. Sidebars allow you to present some tangential information, and put it off to the side in a box. They should usually be referenced by the sidebar’s title.
< BEGIN Sidebar One -- “Scheme vs. Lisp” >
To the uninitiated, Scheme and Lisp look a lot alike, but looks can be deceiving. There are actually quite a few differences between these two languages.
< END >
You should refer to the sidebar by its name, not its number (e.g., ‘for more information, see the sidebar on “Scheme vs. Lisp”’).
Code Listings
Code that is short enough to be inserted “inline” (within the text of the article) should be properly marked within C< > sections. Each line of code should be no longer than 41 characters, 45 at the absolute most. Inline code listings should not exceed 6-8 lines.
Longer listings or code with long lines should be set in their own listing section. Each listing is required to have a title, but may be referred to in the text by its listing number. These longer code listings should have line numbers prepended (you can use cat- n).
Each indent in code should be exactly two spaces.
When referencing functions in your text, append a set of parentheses after the function name to help the reader.
The canonical “Hello, world!” program can be seen in Listing 1.
< BEGIN Listing One -- The “Hello, world!” program in Ruby >
C< 1 blah blah blah blah blah 2 blah blah blah blah blah 3 blah blah blah blah blah 4 blah blah blah blah blah … 10 blah blah blah blah blah >
< END >
Figures
If you want to include some images, screenshots (or even ASCII art to be converted into an illustration), they should be referenced by number (spelled out).
A screen shot of this amazing thing can be seen in I
< BEGIN Figure One -- Screen shot of something > < INSERT FILE: screenshot.png > < END Figure One >
Command Sequences
A sequence of commands should follow the same guidelines as for inline code listings. If they are too long or wide to set inline, they should be broken out as separate listings and/or figures.
Use the “# ” and “$ ” characters as prompts to represent commands that should be run as root, or do not need to be run as root.
Now run the following commands:
C< $ su2 Password: xxxxxx # wall ‘Hello, everybody!’ >
Tables
Tables are set off in separate boxes just as listings and figures are. You can refer to a table either by its name or its number.
The notation for tables is as follows:
< BEGIN Table One -- Tomcat environment variables >
Environment variable|Value
C|Your Java installation directory.
C|The Tomcat installation directory.
C|Command line switches to pass to the Java Runtime Environment.
< END >
The first row of the table is used as the table header. Subsequent rows are used as table rows. Each column is separated by the| (“pipe”) symbol.
Biography
At the end of your articles, include a very brief autobiography of about 25 words. You should include an email address for readers to contact you.
BIO: Glenn McAllister is a part-time committer on the Jakarta Ant project. He can be reached at glenn@somanetworks.com.
Comments
During the article writing process, drafts are exchanged back and forth between writers and editors. These drafts have feedback added to them in the form of comments. They have the following form.
[MS: this is a comment from Martin Streicher ]
[Ed.: This is a different comment notation ]
Miscellaneous
Lists that are embedded in the main text should have a comma separating each element in a list, even between the penultimate and final elements. For example, “apples, oranges, and lemons”.
Quotation marks should be used when refering to titles of articles, columns, web pages, or subheads in the article itself. References to the name of magazine itself should be italicized.
Quotation marks should be used when referring to GUI items that are not buttons (e.g., labels, checkboxes, tabs, menu items)
If punctuation immediately follows a word that is in italics, include the punctuation in the italicized text. For example,
You can use I or
When you refer to the labels of figures, listings, and tables, put the names in italics.
In general, when using the term “open source” as an adjective, the phrase should appear in lowercase. When referring to “open source” as a movement, community, or philosophy, it should be capitalized.
Spell out each acronym the first time it appears in your article and follow that immediately with the acronym in paretheses. Then use the acronym in the rest of the article.
Gotchas and Suggestions
The only special characters to watch out for are < (“less than”), > (“greater than”), and | (“pipe”). If you need to use < or > anywhere in your article, use their HTML equivalents. Pipe may be used anywhere except in tables. Again, if you need to use a pipe in your table, use the HTML equivalent.
Use active voice and present tense. For example, instead of “Clicking on the button will open a window,” use “Click the button to open the window.”
Use contractions to keep the article informal.
Address the reader as “you.” Avoid refererring to “we.”
If you have questions, please send email to
class="emailaddress">mstreicher@linux-mag.com. You can always embed a note in your article to request special formatting. When in doubt, your editor will do the right thing.
Now entering its eighth year of continuous publication, Linux Magazine presents the broadest and most in-depth coverage of all things Linux — from the Linux operating system, to desktop and server hardware, to open source software in the enterprise.
Written by experts and open source community leaders, each month’s Linux Magazine offers Linux professionals — programmers, system administrators, webmasters, IT managers, and business leaders — pragmatic, insightful, and solutions-oriented information.
Linux Magazine provides an information resource for a diverse open source community.
For more information about the magazine and its readership, please download the the PDF version of the 2007 Linux Magazine Media Kit. The Media Kit includes the 2007 Editorial Calendar.
Please contact Robert Wells, Vice President of Business Development for online and print advertising programs, a current rate card, outreach campaigns, and other marketing opportunities.