[[TOC]] = Submitting Documentation = There are three types of documentation * '''Library programmer's manual''': we [http://grass.osgeo.org/programming8/ use doxygen and document the functions] directly in the source code. See lib/gis/*.c and lib/gis/gislib.dox for examples * '''User manual''': each command ("module") comes with its own page. We write it in simple HTML, storing the manual in a file '.html' within the subdirectory of the module. See below for details on the structure. * '''Python documentation''': written in Markdown which is compiled with Sphinx (see [http://grass.osgeo.org/grass-stable/manuals/libpython/pygrass_index.html PyGRASS documentation]) == HTML Pages == The manual pages are not only fundamental for the users but also the "business card" of the respective module. An ideal page comes with clear descriptions, hints on the implemented algorithm and example(s). * Note: Do not upload broken or even empty HTML manual pages. This breaks things in various places. * To avoid the insertion of overly complicated HTML tags (see also below), we strongly suggest to use a plain text editor rather than a HTML editor for editing. Important: The HTML file contains '''no header nor footer'''. The complete HTML file is autogenerated during the compilation process (indeed, it is generated in a virtual session directly after compilation of the module). In this virtual session the module is called internally with --html-description which generates the parameters/flags list in HTML format, along with '.html', HTML header and footer the final HTML manual page is created and stored in the target binaries directory. In a separate process, the MAN format is generated from the complete HTML files. In order to make sure that manuals build without issues, it can be useful to validate the HTML before submitting, e.g. here: [https://validator.w3.org/] === Module Manual Pages === Place the documentation in HTML format into '.html', where is the name of the module. E.g. if the module is named r.example, the documentation file should be named r.example.html. The easiest way to do this is to study an existing HTML page (to get the page style, e.g. [https://github.com/OSGeo/grass/blob/main/vector/v.to.db/v.to.db.html vector/v.to.db/v.to.db.html] - [https://grass.osgeo.org/grass-stable/manuals/v.to.db.html manual]). With a few exceptions, header and footer are NOT allowed. You can add figures (PNG format); the figure name prefix should be the module name. See [https://github.com/OSGeo/grass/blob/main/raster/r.terraflow/r.terraflow.html raster/r.terraflow/r.terraflow.html] ([https://grass.osgeo.org/grass-stable/manuals/r.terraflow.html manual]) for an example. A number of major sections should be present in each help page. R = Required [[br]] S = Suggested [[br]] O = Optional [[br]] In recommended order (in bold the required entries): '''R:

DESCRIPTION

'''[[br]] S:

NOTE

,

NOTES

[[br]] S:

EXAMPLE

,

EXAMPLES

[[br]] O:

TODO

[[br]] O:

KNOWN ISSUES

[[br]] O:

REFERENCE

,

REFERENCES

[[br]] '''R:

SEE ALSO

'''[[br]] '''R:

AUTHOR

,

AUTHORS

'''[[br]] Note that the parameter manual section is auto-generated upon compilation. This is done by running the module in a virtual session after compilation (see the output of 'make'). To subsequently verify the final HTML page, check the resulting HTML pages which will be stored with the name of the module. Examples (please add some more) should be coded like this: {{{ 
v.to.db map=soils type=area option=area column=area_size unit=h
}}} The [http://grass.osgeo.org/grass-stable/manuals/ online WWW manual pages] are updated every Saturday (from !GitHub repository). === Supported HTML Tags === Since the MAN conversion of g.html2man is limited, please use no other HTML tags than: {{{ 

    •   
       
         <tr> <ul>
}}}
   
 * Note that all tags have a closing tag except for <hr>, <br> and <p>.
 * Use lower case forms.
 * Do not insert <p> after <h2>...</h2> or <h3>...</h3>

Note that HTML is converted to MAN pages by [source:grass/trunk/tools/g.html2man/ tools/g.html2man/]

=== Markup style guide ===

 * Module names (i.e., v.category) should be emphasized with <em>module</em>.
 * Flags and parameter names written in boldface like <b>-f</b> and <b>input</b>.
 * Shell commands, names, values, etc. should use <tt>42</tt>.
 * Emphasized phrases <i>should use italics</i>.

The <h2>SEE ALSO</h2> section of each page should also be alphabetized.

=== Footer ===

Change in 2019: no longer useful after migration to git:

~~
The last line of the page should be the date of the last modification of the page which is updated automatically by Subversion (during `svn commit`). In other words, include the following example line as is. It will be updated to the correct date automatically.

{{{
#!text/html
<p><i>Last changed: $Date: 2014-08-14 11:34:43 -0400 (Thu, 14 Aug 2014) $</i>
}}}
~~
=== Break long lines ===

To avoid git merge conflicts, please break a line at approximately 70-80 chars.

Hints:
 * "geany" editor can format a paragraph with CTRL-j
 * "atom" can do that as well
 * "kate": activate it in Settings -> Kate -> Editing -> General -> enable static word-wrap, set 72

== Images ==

Naming convention: `module_name.png` or `module_name_keyword.png` (in both cases, dots in module name are replaced by underscores)

Examples:

 * `d_geodesic.png`
 * `r_resamp_stats_6m_20m.png`
 * `g_gui_rlisetup_8.png`
 * `v_clean_rmsa.png`

Image size: ideally '''600 pixel width''' (height depends on that), use e.g. !ImageMagic:

{{{
mogrify -resize 600x file.png
}}}

Smaller images are also possible when appropriate, e.g. when a lot of images are included or they are something special, e.g. equations, icons or simple diagrams.
Larger images are supported, too, see below for an optimal inclusion into the HTML page.

Please '''compress''' PNG images with:

{{{
# color quantization
# optional, but usually worth it
# note: may change colors
pngnq -n 128 -s 3 file.png

# shuffle original and quantitized image names
mv file.png file_ORIG.png
mv file-nq8.png file.png

# compress better (lossless)
optipng -o5 file.png
}}}

See helper script source:grass-addons/tools/svn-image.sh.

Format: Images should be ideally in PNG (well, JPG and GIF is allowed as well when appropriate but usually it is not!). Vector graphics should be included in pages as raster images (i.e. PNGs) for portability but the original format (preferably SVG) should be committed to the repository as well.

Adding the image to the HTML page (r.viewshed example, the screenshot is shown with a width of 600 pixel but it is clickable in the manual page). If a larger image is displayed as shrinked, both **width** and **height** HTML parameters (values must be calculated according to the picture size!) should be set:
{{{
<div align="center" style="margin: 10px">
<a href="r_viewshed.png">
<img src="r_viewshed.png" width="600" height="600" alt="r.viewshed example" border="0">
</a><br>
<i>Figure: Viewshed shown on shaded terrain (observer position in the north-east quadrant with white dot; 5m above ground)</i>
</div>
}}}

== Wording ==

When writing documentation, honor existing terminologies, names, and wording as they are used in GRASS GIS. Obviously, the current state is not perfect or completely consistent, so if you identify problems, discuss them with the community and provide suggestions and reasoning for the new wording. If you are an experienced GRASS GIS user, keep in mind new users and their first-time experience with GRASS GIS and their experience with other software. If you are a new user of GRASS GIS, keep in mind current users and stability of "GRASS GIS approach." If new terminologies, not used in GRASS GIS before are needed, please refer first to OGC and OSGeo projects, especially GDAL and PROJ.

For example, use "module" not "function" (means something different in programming), "tool" (OK, but too general), "program" (does not cover usage from GUI where it is a dialog), "script" (implementation detail), or "procedure" (uncommon in this context and similar to workflow) when talking about the individual executables. The word "command" is applicable when talking about what is being executed in the command line. 

To applicable extent, this applies also to source code comments, user-visible messages and strings, debug messages, APIs, and naming of concepts in general.