                Article Submission Guidelines
                          for EDM/2



Written by Larry Salomon Jr.
Last updated on Monday, February 13, 1995


Contents

Introduction ................................... 2
File Format .................................... 2
Deadlines ...................................... 2
Using Fonts .................................... 3
Highlighting, Quoting, Etc...................... 3
Structure ...................................... 3
Content ........................................ 4
Final Details .................................. 4

                                                                     Page 1
Introduction

The  purpose  of this document is to explain the  formatting
conventions  used  by the editors to allow  the  authors  to
better  format their articles before submission;  this  will
hopefully  eliminate a significant amount of work  currently
done  by the editors, allowing them to concentrate on  other
important production-related issues.


File Format

All  articles  should be submitted in Microsoft's  rich-text
format  (RTF).  Many word processors do support this  format
on export.  If yours does not or you do not have access to a
word  processor, contact the editors ahead of time  to  make
alternate arrangements.

All  graphics in your article must be included  in  separate
files  in  either OS/2 bitmap or OS/2 metafile format.   The
location in your article where the graphic is to be inserted
should be clearly marked by text in brackets, e.g.
____________________________________________________________

Blah blah blah blah blah.

[Insert graphic FOOBAR.BMP]

Blah blah blah blah blah.
____________________________________________________________

Figure 1)  Sample graphic inclusion

Similarly,  source  code snippets over  5  lines  in  length
should  be  included as a separate file instead of imbedding
the  source  code directly into the text body.   Again,  the
location  in  your article where the source code  is  to  be
inserted should be clearly marked by text in brackets.


Deadlines

The  following  deadlines must be  adhered  to.   Missing  a
deadline  may  result, at the editors' discretion,  in  your
article being delayed.

Item                Send by
Notification        As  soon  as  you decide  to  write  an
                    article
First draft         The 15th of the month
(optional)
Final draft         The 25th of the month

Table 1)  Deadlines

Notification  is intended to let us know that  you  will  be
writing  an article so that we do not receive any  surprises
on  the  25th.   Please include the subject  matter  of  the
article and a brief description of what you intend to  cover
in your article.

First  draft is optional and should contain a rough  outline
of  your  article and may be in "straight ASCII".   This  is
intended  to  be  an elaboration of the notification  rather
than  a prelude to the final draft. Remember that more  work
writing this item means less work for the next.

                                                                     Page 2
Final  draft  should contain the final text to be  submitted
for  any  necessary  editing and/or reformatting.   On  rare
occasions,  we  will  resubmit  the  text  back  to  you  if
significant  changes  have been  made  to  verify  that  the
original meaning of the text has been preserved.


Using Fonts

Please  use  the following table to determine the  font  and
size to use for each situation listed:

Situation             Font                  Size
Body text             Helvetica             10
Article title         Helvetica, bold       18
Section title         Helvetica, bold       14
Subsection title      Helvetica, bold       10
Quoted text           Times Roman           10
Captions              Helvetica             8
Pseudocode            Helvetica             10

Table 2)  Situations and associated fonts to be used.

Situations  not  listed should use the  Helvetica  font,  10
point size.


Highlighting, Quoting, Etc.

In  the  past  there  has  been quite  a  bit  of  confusion
regarding  the  use of highlights versus  single  or  double
quotes.  This section will hopefully clarify our position on
the matter.

Boldface  should be used to emphasize words or  phrases  and
also  to highlight the first occurrence of a word or  phrase
that  the  average  reader will not be  familiar  with.   To
elaborate, highlight any words or phrases that you would put
in  a  glossary, were you required to write one.   (You  are
not.)  Do not use italicized fonts.

Quoting,  when  used, should be restricted to double  quotes
only  and  should surround references to colloquialisms  and
any  other  phrasings  that  you  feel  do  not  consist  of
standard,  proper  English.  These  items  are  subjectively
defined;  use  your judgment when deciding  whether  or  not
something should be quoted.

Underlining should be used when referring to another body of
text.


Structure

Please  restrict  your use of structure in your  article  to
tables  and  lists, whether ordered or unordered.   If  your
document  creator  does  not  support  tables  as  a  native
operation, use tabs to separate columns.

                                                                     Page 3
Content

This  section  deals with the text itself.   While  everyone
from you (the authors) to us (the editors) is doing this  on
a  voluntary  basis, we would lose readers  if  we  did  not
strive for a high level of quality.  Since this magazine was
formed  with the intent of disseminating information to  the
multitude  of  programmers  unsatisfied  with  the   lacking
documentation provided by IBM, it would only serve to defeat
the  purpose of the magazine if we did not do so.  Thus,  we
humbly  request  that the following checklist  is  performed
before submission.

Check that all information is accurate

No  one  expects you to know everything about the topic  you
are  writing. However, what information you do  write  about
should be accurate and precise. Use correct terminology; use
clear sentence structure; use examples in the text that  you
know  work  (whether you "eyeball" them  or  compile  them);
document  any  exceptions that you know  about  when  making
generalizations.   The list could go  on  forever,  but  you
should understand what is spoken of here.

Check your spelling

Since  most word-processors have a spelling-checker, we  ask
that you use it.

Liberally comment your source code samples

As  it  has been said many times, a well-illustrated example
will  often  make up for any vagaries in the  text.   "Well-
illustrated" not only means well thought-out, but also well-
commented.   Do not forget these, or else your readers  will
not  be able to figure out what the sample does.  An example
of  this  would be the installation command file that  comes
with EDM/2.

Additionally,  insure that your source code samples  compile
and run properly.


Final Details

Before  your task is complete, make sure you write  a  short
"blurb" about yourself in a separate file; this will  go  in
the  "Contributors to this Issue" section.   Please  include
your electronic mail address and specify on what network  it
resides.

Zip  the  source file, the biography file, and any  graphics
files,  uuencode the zipped file and mail it to one  of  the
authors by the final draft deadline.

Finally,  we  thank  you  for your  cooperation  with  these
guidelines. Remember, you are doing a great service  to  the
OS/2 community by writing for EDM/2.  Be proud of it!

Sincerely,
The EDM/2 Editors

                                                                     Page 4
