home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 14 Text / 14-Text.zip / os2posub.zip / os2posub.inf (.txt) next >
OS/2 Help File  |  1995-01-26  |  33KB  |  201 lines
  1.  
  2. ΓòÉΓòÉΓòÉ 1. OS/2 Power submission guidelines ΓòÉΓòÉΓòÉ
  3.  
  4.                         OS/2 Power Submission Guidelines
  5.  
  6. OS/2 Power, the number one OS/2 information guide to be, needs your articles! 
  7. It isn't possible for me to fill an issue everyone month and still have time to 
  8. have a life(TM). Below are outlined what you can offer if you are a potential 
  9. reader of the magazine, a potential writer, a shareware author or a commercial 
  10. developer. 
  11.  
  12. The Potential Reader 
  13.  
  14. If you want to read about all aspects of OS/2, aimed at all levels. From 
  15. reviews to tutorials, clever tricks, interviews etc. This magazine is for you. 
  16. You may not have the time or inclination to write for this - thats OK, but if 
  17. you want something covered mail me! OS/2 Power actively promotes reader 
  18. feedback 
  19.  
  20. The Potential Writer 
  21.  
  22. So, you want to aid the OS/2 community, pooling knowledge to generate the 
  23. source of OS/2 information - great. 
  24.  
  25. So what does the magazine need? 
  26.  
  27.        Tutorials of OS/2 applets, shareware utilities etc 
  28.  
  29.        Reviews of Shareware and commercial programs 
  30.  
  31.        Communication info, surfing the net 
  32.  
  33.        Reaching into the depths of OS/2 
  34.  
  35.        How OS/2 works 
  36.  
  37.        How to configure OS/2 and other applications 
  38.  
  39.        Clever tricks OS/2 can do 
  40.  
  41.        News, interesting snippets and anything else you can think of! 
  42.  
  43.  Shareware Authors 
  44.  
  45.  Shareware authors, OS/2 Power will be running regular reviews of shareware 
  46.  products. If you want to highlight your product, or find out what utilities 
  47.  OS/2 users want - we will be running tallies on needed utilities. 
  48.  
  49.  Commercial Developers 
  50.  
  51.  If you are a commercial developer and want to find out what the OS/2 market 
  52.  needs or wants, this is the place to ask. 
  53.  
  54.  Reviews of commercial software may be carried out if you supply software to a 
  55.  writer or if they already own the package. Packages must be OS/2 native or 
  56.  have at the minimum a good set of integration tools. 
  57.  
  58.  British pricing is preferred where possible, and contacts in Britain are 
  59.  appreciated. 
  60.  
  61.  
  62. ΓòÉΓòÉΓòÉ 1.1. Writing of articles ΓòÉΓòÉΓòÉ
  63.  
  64. Writing articles 
  65.  
  66. Some basic guidelines have to be followed when writing reviews. 
  67.  
  68. All articles should be as accurate and unbiased as you can make them. They 
  69. should be clear, easy to read and grammatically correct. British spelling is 
  70. recommended, as this is a British publication. 
  71.  
  72. Dates should be in the European format of date/month/year. Other measurements 
  73. are OK 
  74.  
  75. Articles may be written in one of three formats - IPF format, Ami Pro Format or 
  76. ASCII text. 
  77.  
  78. IPF Format 
  79.  
  80. IPF (Information Presentation Facility) allows you to write OS/2 INF and HLP 
  81. files via embedding 'codes' in your text - for instance :p. generates a new 
  82. paragraph. The IPF compiler (IPFC) is included within the OS/2 toolkit, 
  83. contained also in the Devcon disks and OS/2 beta II cdrom in the beta toolkit - 
  84. it comes with full instructions for writing in IPFC. 
  85.  
  86. This is the preferred format, as it involves very little work for me (other 
  87. than my own articles, graphics and editorial...). 
  88.  
  89. Ami Pro Format 
  90.  
  91. This format is included since I might be writing an Ami Pro-->IPF converter 
  92. soon. This will allow you to set fonts, bold, paragraphs etc, but not hypertext 
  93. links. Links will have to be done by informing me - please remember not to 
  94. include too many if you do it this way. Use Arial Bold 30 for the overall 
  95. column heading, Arial Bold 25 for sections and Arial Bold 16 for general text. 
  96. Subsections should be in bold. 
  97.  
  98. ASCII Text 
  99.  
  100. If you have neither of the above two formats, use plain ASCII text and indicate 
  101. where you want different fonts, graphics, hypertext links etc. As before, 
  102. minimise these since I have to convert your document manually. 
  103.  
  104. Required format for articles 
  105.  
  106. Even if you don't know IPF. I would really appreciate it if you could carry out 
  107. the following items 
  108.  
  109.        Place a :p. on a blank line by itself after each paragraph 
  110.  
  111.        Head new sections with :p2. 
  112.  
  113.  For those people who do know ipf, the text of this submission guide is 
  114.  provided as an example of the style used. Also observe the formatting codes 
  115.  below: 
  116.  
  117.        Your overall column heading should  be in Bold Helv 30x14 ie :font 
  118.       facename=Helv size=30x14 :hp2.  text :ehp2. 
  119.  
  120.        Headings should be in Helv 25x14 ie :font facename=Helv size=25x14 :hp2. 
  121.       text :ehp2. 
  122.  
  123.        Sub-headings should be in general text size (Helv 16x14), in bold 
  124.  
  125.        General text is in Helv 16x14 ie  :font facename=Helv size=16x14 
  126.  
  127.        Important points should be emphasised in bold ie :hp2. bold :ehp2. 
  128.  
  129.  Your column will be in header level 1 (:h1.), whilst sub-pages within the 
  130.  column should be header level 2 (:h2.). 
  131.  
  132.  Hypertext links can be in any format you want, but must be visible when 
  133.  activated on a 640x480 screen. 
  134.  
  135.  Each paragraph must be denoted by :p. on a blank line by itself - if placed at 
  136.  the end of the line, it occasionally ruins the layout of the following line. 
  137.  Paragraph tags should also be used in the normal font height, otherwise line 
  138.  spacing is uneven. Before and after lists (:ul. ,  :li. & :eul.) you should 
  139.  not have a paragraph tag, as this gap is wider than usual. 
  140.  
  141.  Graphics 
  142.  
  143.  All graphics to be included with the article should be in .BMP (non RLE) 
  144.  format in no more than 256 colours unless you have a good reason otherwise. 
  145.  You should also use an image manipulation utility to 'map to System colours'. 
  146.  Bitmap files must not be wider than 605 pixels (thats the maximum for a 
  147.  640x480 screen), and I'd appreciate it if you could grab them at 640x480 or 
  148.  800x600 resolution (as the resources such as icons and fonts are smaller). The 
  149.  maximum bitmap that can fit on a 640x480 screen and still be seen in its 
  150.  entirety is 605x265 pixels.
  151.  
  152.  I don't consider it the writer's responsibility to create a bitmap to head 
  153.  their article - I can handle that, however, graphics included within the 
  154.  article should be created or screengrabbed by the writer. If you're more 
  155.  artistic than myself (not difficult), then I'd be grateful if you generate the 
  156.  bitmap to head your column, preferably raytraced, but not really that 
  157.  important. 
  158.  
  159.  Submission dates for articles 
  160.  
  161.  These are the guidelines for the first issue, which is not yet complete, but 
  162.  these dates roughly stand : 
  163.  
  164.       Ideas for an article should be sent to me straight away  - I can then 
  165.       confirm if someone else is writing on the same subject 
  166.  
  167.       Preliminary drafts (need only be ASCII) must be mailed  to me on or 
  168.       before the 10th of each month 
  169.  
  170.       Finished work should be sent no later than the 20th. It should be written 
  171.       in a format described above,zipped, uuencoded and mailed to me. 
  172.  
  173.       The finished magazine should be out on the 25th,  to allow for editing 
  174.       and last minute changes. 
  175.  
  176.  Mailing me and uuencoding data 
  177.  
  178.  I can be mailed at P.J.KAY@ITI.SALFORD.AC.UK. I use the cc:mail package if you 
  179.  want to send coloured messages. I can be snail mailed at Peter Kay, OS/2 
  180.  Power, ITI Institute, University of Salford, Salford, M5 4WT, Great Britain. 
  181.  
  182.  UUencoding 
  183.  
  184.  UUencoding, for the uninitiated, turns a binary file into an ASCII text file 
  185.  that can be sent via the mail system. At the other end the file is UUdecoded 
  186.  to recreate the binary file. 
  187.  
  188.  The easiest way to UUencode is to get pmuue from ftp.cdrom.com in 
  189.  pub/os2/32bit/archiver/PMuue11.zip. Or, use a command line util, also in 
  190.  archiver, any file starting with U. 
  191.  
  192.  
  193. ΓòÉΓòÉΓòÉ <hidden> About this picture. ΓòÉΓòÉΓòÉ
  194.  
  195. This picture, here demonstrating the use of a hypertext link, was created in 
  196. Moray, a DOS modelling package that interfaces to Povray (a freeware renderer). 
  197. The planet texture is a plasma cloud created  in Fractint for DOS, (a free 
  198. fractal generator) using blue.map and then edited with Paintbrush. The word 
  199. 'OS/2 Power' is made up of over 168 objects as Povray has no text capability. 
  200. Things got so bad that Moray only had 2K of base memory left! It wouldn't even 
  201. run under DOS with all memory management on - just OS/2.