Outdated version of the documentation. Find the latest one here.

문서 작성 지침

소개

QGIS Documentation will be built automatically on the server at 0, 8am, 4pm US/Pacific (Pacific Time). The current status is available at http://docs.qgis.org.

QGIS Documentation is mainly written using the reStructuredText (reST) format syntax, coupled with some scripts from the Sphinx toolset to post-process the HTML output. See http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html or http://sphinx.pocoo.org/markup/inline.html.

In general, when creating rst documentation for the QGIS project, please follow the Python documentation style guidelines. Below are exposed some general guidelines to follow when using reST for the QGIS documentation writing.

If you are looking for general rules on contributing to QGIS project or managing repositories, you may find help at Get Involved in the QGIS Community.

문서 작성

표제

문서의 .rst 파일 하나가 웹페이지 하나와 대응합니다.

밑줄(1단계 제목의 경우 윗줄도 포함) 그어진 제목을 통해 텍스트의 구조를 구성하는 절(section)을 식별합니다. 동일한 단계의 제목은 반드시 동일한 특수문자로 밑줄을 작성해야 합니다. QGIS 문서의 경우, 장(chapter), 절(section), 항(subsection), 목(minisec)에 대해 다음과 같은 스타일을 사용해야 합니다.

********
Chapter
********

Section
=======

Subsection
----------

Minisec
.......

Subminisec
^^^^^^^^^^

Inline tags

일부 항목을 강조하기 위해 텍스트 내부에서 몇몇 태그를 사용할 수 있습니다.

  • Menu gui: to mark a complete sequence of menu selections, including selecting submenus and choosing a specific operation, or any subsequence of such a sequence.

    :menuselection:`menu --> submenu`

  • Dialog and Tab title: Labels presented as part of an interactive user interface including window title, tab title and option labels.

    :guilabel:`title`

  • Button labels

    **[Apply]**

  • 파일명 또는 디렉터리

    :file:`README.rst`

  • 팝업 텍스트를 보유한 아이콘

    |icon| :sup:`popup_text`

    (다음 image 를 참조하십시오)

  • Shorcut keyboard

    :kbd:`ctrl B`

    will show Ctrl B

  • 사용자 텍스트

    ``label``

라벨/참조

텍스트 내부에 앵커(anchor)를 삽입하는 데 참조를 이용합니다. 이 앵커를 통해 절 또는 페이지 사이의 하이퍼링크를 생성하고 호출할 수 있습니다.

다음은 절(예: 라벨/참조 제목)의 앵커를 생성하는 예시입니다.

.. _my_anchor:

Label/reference
---------------

동일 페이지 안에서 참조를 호출하려면 다음과 같이 작성합니다.

see my_anchor_ for more information.

다음과 같은 내용을 반환할 것입니다.

see my_anchor for more information.

Notice how it will jump to the following line/thing following the ‘anchor’. Normally to declare this label you do not need to use apastroph’s but you do need to use empty lines before and after the anchor.

문서 어디에서든 동일한 장소로 넘어가는 또다른 방법은 :ref: 기능을 이용하는 것입니다.

see :ref:`my_anchor` for more information.

앵커 대신 캡션을 (이 경우 현재 절의 제목을) 표시할 것입니다.

see 라벨/참조 for more information.

이렇게 참조 1(my_anchor)과 참조 2(라벨/참조)라는 방법이 있습니다. 참조가 완전한 캡션을 표시하는 경우가 많기 때문에, 절 이라는 단어를 따로 작성할 필요는 없습니다. 또한 참조를 설명하는 데 사용자 지정 캡션을 쓸 수도 있습니다.

see :ref:`Label and reference <my_anchor>` for more information.

다음과 같이 반환됩니다.

see Label and reference for more information.

Figure and image

그림

다음은 이미지를 삽입하는 예시입니다.

.. image:: /static/common/qgislogo.png
   :width: 10 em

다음과 같은 그림을 반환합니다.

../../_images/qgislogo.png

별명

You can put an image inside text or add an alias to use everywhere. To use an image inside a paragraph, just create an alias somewhere.

.. |nice_logo| image:: /static/common/qgislogo.png
               :width: 2 em

and call it in your paragraph:

my paragraph begins here with a nice logo |nice_logo|.

Here is how this example become:

my paragraph begins here with a nice logo nice_logo.

주석

Currently, to ensure consistency and help in the use of QGIS icons a list of alias is built and available in 별명 chapter.

도형

.. _figure_logo:

.. figure:: /static/common/qgislogo.png
   :width: 20 em
   :align: center

   A caption: A logo I like

결과는 다음과 같습니다.

To avoid possible conflict with another references, always begin figures anchor with _figure_ and prefer using terms that can easily refer to the figure caption. While only the centered alignment is mandatory for the image, feel free to use any other options for figure (such as width, height, scale...) if needed.

The scripts will insert an automatical generated number before the caption of the figure in pdf.

To use a caption (see My caption) just insert indented text after a blank line in the figure block.

도형에 대한 참조는 다음과 같이 참조 라벨을 사용해서 작성할 수 있습니다.

(see Figure_logo_).

It will show the anchor Figure_logo. You can use uppercase if you want. It can be used in the same .rst document but not in others. You can still use the :ref: role for reference from other files, but keep in mind that this returns the full caption of the image.

see :ref:`figure_logo`

returns:

see A caption: A logo I like

도표

다음은 단순한 표를 생성하는 예시입니다.

=======  =======  =======
x        y        z
=======  =======  =======
1        2        3
2        4
=======  =======  =======

공백을 남기려면 \ 뒤에 공백을 삽입하십시오.

참조 등을 이용, 표를 직접 그려서 좀 더 복잡한 표를 작성할 수도 있습니다.

.. _my_drawn_table:

+---------------+--------------------+
| Windows       | macOS              |
+---------------+--------------------+
| |win|         | |osx|              |
+---------------+--------------------+
| and of course not to forget |nix|  |
+------------------------------------+

My drawn table, mind you this is unfortunately not regarded a caption

You can reference to it like this my_drawn_table_.

결과물은 다음과 같습니다.

Windows macOS
win osx
and of course not to forget nix

My drawn table, mind you this is unfortunately not regarded a caption

You can reference to it like this my_drawn_table.

색인

An index is a handy way to help the reader easily find an information in a doc. QGIS documentation provides some essential indices. There are few rules to follow in order to keep a set of indices that are really useful (coherent, consistent and really connected to each other):

  • Index should be human readable, understandable and translatable; an index can be made from many words but you should avoid any unneeded _, -... characters to link them i.e., Loading layers instead of loading_layers or loadingLayers.
  • Always capitalize only the first letter of the index unless the word has a particular spelling, in which case keep using its spelling e.g., Loading layers, Atlas generation, WMS, pgsql2shp
  • Keep an eye on the existing Index list in order to reuse the most convenient expression with the right spelling and avoid wrong duplicates.

Several index tags exist in RST. You can either use the inline :index: tag within the normal text.

QGIS allows to load several :index:`Vector formats` supported by GDAL/OGR ...

Or you can use the .. index:: block-level markup which links to the beginning of the next paragraph. Because of the rules mentioned above, it’s advised to use this latter tag as it’s easier to fulfill them.

.. index:: WMS, WFS, Loading layers

It’s also recommanded to use index parameters such as single, pair, see... in order to build a more structured and interconnected table of index. See http://www.sphinx-doc.org/en/stable/markup/misc.html#index-generating-markup for more information on index creation.

Special Comments

Sometimes, you may want to emphasize some points of the description, either to warn, remind or give some hints to the user. In QGIS Documentation, we use reST special directives such as .. warning::, .. note:: and .. tip:: generating particular frames that highlight your comments. See http://www.sphinx-doc.org/en/stable/markup/para.html#paragraph-level-markup for more information. A clear and appropriate title is required for both warnings and tips.

.. tip:: **Always use a meaningful title for tips**

 Begin tips with a title that summarizes what it is about. This helps
 users to quickly overview the message you want to give them, and
 decide on its relevance.

Code snippets

You may also want to give examples and insert a code snippet. In this case, write the comment below a line with the :: directive inserted. However, for a better rendering, especially to apply color highlighting to code according to its language, use the code-block directive, e.g. .. code-block:: xml. By default, Python code snippets do not need this reST directive. More details at http://www.sphinx-doc.org/en/stable/markup/code.html.

주석

While texts in note, tip and warning frames are translatable, be aware that code block frames do not allow translation. So avoid comments not related to code sample and keep this just as short as needed.

주석

어떤 번역 소프트웨어도 주석을 식별하지 못 하며, 또 주석은 PDF 포맷으로 제대로 변환되지도 않습니다. 따라서 가능하다면 어떤 문서에도 주석을 쓰지 마십시오.

This is for creating a footnote

blabla [1]_

다음을 가리키게 됩니다.

[1]Updates of core plugins

Managing Screenshots

새 스크린샷 추가

Here are some hints to create new, nice looking screenshots. For the user guide they go into ./resources/en/user_manual/

  • same environment for all the screen caps (same OS, same decoration, same font size). We have used Ubuntu with Unity and the default “ambience” theme. For screenshots of QGIS main window and composer we have set it to show menus on the window (not the default in unity).
  • reduce the window to the minimal space needed to show the feature (taking the all screen for a small modal window > overkill)
  • the less clutter, the better (no need to activate all the toolbars)
  • don’t resize them in an image editor, the size will be set into the rst files if necessary (downscaling the dimensions without properly upping the resolution > ugly)
  • cut the background
  • make the top corners transparent if the background is not white
  • Set print size resolution to 135 dpi (e.g. in Gimp set the print resolution image ‣ print size and save). This way, images will be at original size in html and at a good print resolution in the PDF. You can also use ImageMagick convert command to do a batch of images
convert -units PixelsPerInch input.png -density 135 output.png
  • save them in png (no jpeg artifacts)
  • the screenshot should show the content according to what is described in the text
  • you can find some prepared QGIS-projects that were used before to create screenshots in ./qgis-projects. This makes it easier to reproduce screenshots for the next version of QGIS. These projects use the QGIS Sample Data (aka Alaska Dataset), which should be placed in the same folder as the QGIS-Documentation Repository.

  • 우분투에서 글로벌 메뉴 기능을 제거해서 더 작은 응용 프로그램 스크린샷을 생성하려면 다음 명령어를 사용하십시오.

sudo apt-get autoremove appmenu-gtk appmenu-gtk3 appmenu-qt

스크린샷 번역

Here are some hints to create screenshots for your translated user guide. They will go into ./resources/<your language>/user_manual/

  • same environment for all the screen caps (same OS, same decoration, same font size)
  • use the QGIS -projects included in QGIS-Documentation repository (in ./qgis_projects ). These were used to produce the ‘original’ screenshots in the manual. The QGIS Sample Data (aka Alaska Dataset) should be placed in the same folder as the QGIS-Documentation Repository.
  • same size as the english ‘original’ screenshots, otherwise they will be stretched and look ugly. If you need to have a different size due to longer ui strings, don’t forget to change the dimension in the rst code of your language.
  • reduce the window to the minimal space needed to show the feature (taking all the screen for a small modal window > overkill)
  • the less clutter, the better (no need to activate all the toolbars)
  • don’t resize them in an image editor, the size will be set into the rst files (downscaling the dimensions without properly upping the resolution > ugly)
  • cut the background
  • save them in png (no jpeg artifacts)
  • the screenshot should show the content according to what is described in the text

공간 처리 알고리즘 문서 작성

공간 처리 알고리즘을 위한 문서를 작성하고자 할 경우, 다음과 같은 지침들을 고려하십시오.

  • don’t overwrite existing help files by files from other sources (e.g. QGIS source tree or Processing-Help repository), this files have different formats
  • Processing algorithm help files are part of QGIS User Guide, so use same formatting as User Guide and other documentation
  • avoid use “This algoritm does this and that...” as first sentence in algorithm description. Try to use more general words like in TauDEM or GRASS algoritms help
  • add images if needed. Use PNG format and follow general guidelines for documentation.
  • if necessary add links to additional information (e.g. publications or web-pages) to the “See also” section
  • give clear explanation for algorithm parameters and outputs (again GRASS and TauDEM are good examples).
  • don’t edit parameter or output names. If you found typo or wrong spelling — report this in bugracker, so developers can fix this in Processing code too
  • don’t list available options in algorithm description, options already listed in parameter description.
  • don’t add information vector geometry type in algorithm or parameter description without compelling reason as this information already available in parameter description