0024336: Content of OCCT documentation should be updated. Iter 2

CDL guide finalized.
Brep WP added
Added white-papers and 2 dev guides in the generated documentation structure.
White-papers + 2 developer guides + Draw UG finalized.
Visualization guide finalized.
Fixes for bugs 24205, 23737 and 24021

dox/FILES.txt

@@ -21,6 +21,11 @@ user_guides/ocaf/ocaf.md
 user_guides/tobj/tobj.md
 user_guides/shape_healing/shape_healing.md
 user_guides/draw_test_harness.md
+user_guides/brep_wp/brep_wp.md
+user_guides/ocaf_functionmechanism_wp/ocaf_functionmechanism_wp.md
+user_guides/ocaf_tree_wp/ocaf_tree_wp.md
+user_guides/ocaf_wp/ocaf_wp.md
+user_guides/voxels_wp/voxels_wp.md
 
 dev_guides/dev_guides.md
 dev_guides/contribution/coding_rules.md
@@ -28,6 +33,9 @@ dev_guides/cdl/cdl.md
 dev_guides/tests/tests.md
 dev_guides/documentation/documentation.md
 dev_guides/wok/wok.md
+dev_guides/contribution_workflow/contribution_workflow.md
+dev_guides/git_guide/git_guide.md
+
 
 dev_guides/building/building.md
 dev_guides/building/3rdparty/3rdparty_windows.md

dox/dev_guides/contribution_workflow/contribution_workflow.md

@@ -0,0 +1,283 @@
+Contribution Workflow {#dev_guides_contribution_workflow}
+====================================
+@tableofcontents 
+
+@section occt_contribution_workflow_1 Introduction
+
+The purpose of this document is to describe standard workflow for processing contributions to certified version of OCCT. 
+
+@subsection occt_contribution_workflow_1_1 Use of issue tracker system
+
+Each contribution should have corresponding issue (bug, or feature, or integration request) 
+registered in the MantisBT issue tracker system accessible by URL 
+http://tracker.dev.opencascade.org. 
+The issue is processed further according to the described workflow.
+
+@subsection occt_contribution_workflow_1_2 Access Levels 
+
+  Access level defines the permissions of the user to view, 
+  register and modify issues in a Mantis bugtracker. 
+  The correspondence of access level and user permissions 
+  is defined in accordance with the table below.
+
+| Access level  | Granted to       | Permissions       | Can set statuses         |
+|:------------- | :--------- | :-------------- | :----------------------- |
+| Viewer        | Everyone (anonymous access)   | View public issues only    | No     |
+| Reporter | Users registered on dev.opencascade.com  | View, report, and comment issues  | New, Resolved   |
+| Updater       | Users of dev.opencascade.com in publicly visible projects | View  and comment issues | New, Resolved  |
+| Developer     | OCC developers and external contributors who signed the CLA  | View, report, modify, and handle issues | New, Assigned, Resolved, Reviewed  |
+| Tester        | OCC engineer devoted to certification testing | View, report, modify, and handle issues | Assigned, Tested         |
+| Manager       | Person responsible for a project or OCCT component | View, report, modify, and handle issues | New, Resolved, Reviewed, Tested, Closed  |
+
+According to his access level, the user can participate in the issue handling process under different roles, as described below.
+
+@section occt_contribution_workflow_2 Typical workflow for an issue
+
+@subsection occt_contribution_workflow_2_1 General scheme
+
+@image html OCCT_ContributionWorkflow_V3_image001.png "Standard life cycle of an issue"
+@image latex OCCT_ContributionWorkflow_V3_image001.png "Standard life cycle of an issue"
+  
+@subsection occt_contribution_workflow_2_2 Issue registration
+
+An issue is registered in Mantis bugtracker by the Reporter with definition of the necessary attributes. 
+The definition of the following attributes is obligatory:
+
+  * **Category** - indicates component of OCCT to which the issue relates. If in doubt, assign OCCT:Foundation Classes.
+  * **Reproducibility** 
+  * **Severity** 
+  * **Priority**
+  * **Profile** - allows defining the platform on which the problem was detected   from the list of predefined platforms. If a platform is absent in the list of predefined platforms it is possible to use Or Fill In option to define the platform manually.
+    * **Platform**
+    * **OS**
+    * **OS Version**
+  * **Products Version** - defines the version of Open CASCADE on which the problem has been detected.
+  * **Summary** - a short, one sentence description of the issue. It has a limit of 128 characters. It should be informative and useful for the developers. It is advisable to avoid vague or misleading phrases, such as "it doesn't work" or "it crashed". It is not allowed to mention the issue originator, and in particular the customer, in the name of the registered issue.
+  * **Description** - should contain a detailed definition of the nature of the registered issue depending on its type. For a bug it is required to submit a detailed description of the incorrect behavior, including the indication of the cause of the problem (if possible at this stage) or any inputs from the originator. For a feature or integration request it is recommended to describe the proposed feature in details (as possible at that stage), including the changes required for its implementation and the main features of the new functionality. Filling the bug description is obligatory. 
+  * **Steps To Reproduce** - in this field it is possible to describe in detail how to reproduce the issue.  This field considerably helps to find the cause of the problem, to eliminate it and to create the test case.
+  * *Upload File* field allows attaching the shapes, scripts or modified source files of OCCT. It is recommended to attach a prototype test case in form of a Tcl script for DRAW,   using either existing DRAW commands, or a C++ code which can be organized in DRAW commands,   as well as sample shapes or other input data (if applicable), immediately after the issue registration. 
+  
+  The newly registered issue gets status **NEW** and is assigned to the developer responsible for the OCCT component indicated in the Category field (Maintainer). 
+
+@subsection occt_contribution_workflow_2_3 Assigning the issue
+
+  The description of the new issue is checked by the **Maintainer** and if it is feasible, 
+  he may assign the issue to a **Developer**. Alternatively, any user with **Developer** access level  
+  or higher can assign the issue to himself if he wants to provide a solution. 
+  
+  The recommended way to handle contributions is that the **Reporter** assigns the issue to himself and provides a solution.
+
+  The **Maintainer, Technical Project Manager,** or **Bugmaster** can close or reassign the issue 
+  (in **FEEDBACK** state) to the **Reporter** after it has been registered, if its description does not contain sufficient details to reproduce the bug or explain the purpose of the new feature. 
+  That decision shall be documented in the comments to the issue in the Bugtracker.
+
+  The assigned issue should have state **ASSIGNED**.
+
+@subsection occt_contribution_workflow_2_4 Resolving the issue
+
+  The **Developer** responsible for the issue assigned to him provides a solution 
+  as a change on the version of OCCT indicated in the issue attributes, or the last development version. 
+
+  The modified sources should be submitted for review and testing to the dedicated branch of the official OCCT Git repository:
+
+  * Branch should be created for the issue with name composed of letters ‘CR’ followed by issue ID number (without leading zeroes). 
+   Optional suffix can be added to the branch name after issue ID, 
+   e.g. to distinguish between several version of the fix.
+  * The branch should be based on recent version of the master branch 
+   (not later than commit tagged as last OCCT release).
+  * The first line of the first commit message should contain 
+   the Summary of the issue (starting with its ID followed by colon, e.g. "0022943: Bug TDataXtd_PatternStd"). 
+   The consequent lines should contain a description of the changes made. 
+   If more than one commit has been made, the commit messages should contain description of the changes made.
+  * The amount of the code affected by the change should be limited 
+   to only the changes required for the bug fix or improvement. 
+   Change of layout or re-formatting of the existing code is allowed 
+   only in the parts where meaningful changes related to the issue have been made.
+  * The name of the branch where the fix is submitted should be given 
+   in the note to the Mantis issue 
+   (providing the direct link to relevant branch view in GitWeb is encouraged).
+  * The description of the changes made should be put to the field 
+   "Additional information and documentation updates" of the Mantis issue.
+
+  In some cases (if Git is not accessible for the contributor), 
+  external contributions can be submitted as patch (diff) files or sources 
+  attached to the Mantis issue, with indication of OCCT version on which the fix is made. 
+  Such contributions should be put to Git for processing by someone else,
+  and hence they have less priority in processing than the ones submitted directly through Git.
+
+  The issue for which solution is provided should be switched to **RESOLVED** state 
+  and assigned to the developer who is expected to make a code review 
+  (the **Reviewer**; by default, can be set to the **Maintainer** of the component).
+
+@subsection occt_contribution_workflow_2_5 Code review
+
+  The **Reviewer** analyzes the proposed solution for applicability in accordance with OCCT Code reviewing rules and examines all changes in the sources to detect obvious and possible errors, misprints, conformity to coding style.
+  
+    * If Reviewer detects some problems, he can either:
+      * Fix these issues and provide new solution, reassigning the issue (in **RESOLVED** state) to the **Developer**, who then becomes a **Reviewer**. 
+       Possible disagreements should be resolved through discussion, which is done normally within issue notes (or on the OCCT developer’s forum if necessary).
+      * Reassign the issue back to the **Developer**,  providing detailed list of remarks. The issue then gets status **ASSIGNED** and a new solution should be provided.
+    * If Reviewer does not detect any problems, he changes status to **REVIEWED**.
+
+@subsection occt_contribution_workflow_2_6 Testing
+
+  The issues that are in **REVIEWED** state are subject of certification (non-regression) testing. 
+  The issue is assigned to OCC **Tester** when he starts processing it.
+  The results of tests are checked by the **Tester**: 
+    * If the **Tester** detects build problems or regressions, he changes the status to **ASSIGNED** and reassigns the issue to the **Developer** with a detailed description of the problem. The **Developer** should produce a new solution.
+    * If the **Tester** does not detect build problems or regressions, he changes the status to **TESTED** for further integration.
+
+@subsection occt_contribution_workflow_2_7 Integration of a solution
+
+  Before integration into the master branch of the repository the **Integrator** checks the following conditions:
+    * the change has been reviewed;
+    * the change has been tested without regressions (or with regressions treated properly);
+    * the test case has been created for this issue (when applicable), and the change has been rechecked on this test case;
+    * "Additional information and documentation updates" field is filled by the developer;
+    * the change does not conflict with other changes integrated previously.
+  
+  If the result of check is successful the Integrator integrates solution 
+  into the master branch of the repository. Each change is integrated into the master branch 
+  as a single commit without preserving the history of changes made in the branch 
+  (by rebase, squashing all intermediate commits), however, preserving the author when possible. 
+  This is done to have the master branch history plain and clean. 
+  The following picture illustrates the process:
+  
+@image html OCCT_ContributionWorkflow_V3_image002.jpg "Integration of several branches"
+@image latex OCCT_ContributionWorkflow_V3_image002.jpg "Integration of several branches"
+  
+  The new master branch is tested against possible regressions that might appear due to interference between separate changes. When the tests are Ok, the new master is pushed to the official repository 
+  and the original branches are removed from it.
+  The issue status is set then to **VERIFIED** and is assigned to the **Reporter** so that he could check the fix as-integrated.
+
+@subsection occt_contribution_workflow_2_8 Closing a bug
+
+  The **Bugmaster** closes the issue after regular OCCT Release provided that the issue status is **VERIFIED** and that issue was really solved in that release, by rechecking the corresponding test case. The final issue state is **CLOSED**.
+
+@subsection occt_contribution_workflow_2_9 Reopening a bug
+
+  If a regression is detected, the **Bugmaster** may reopen and reassign the **CLOSED** issue to the appropriate developer with comprehensive comments about the reason of reopening. The issue then becomes **ASSIGNED** again. 
+
+@section occt_contribution_workflow_3 Appendix
+
+@subsection occt_contribution_workflow_3_1 Issue attributes
+
+@subsubsection occt_contribution_workflow_3_1_1 Severity
+
+  Severity shows at which extent the issue affects the product. 
+  The list of used severities is given in the table below in the descending order.
+  
+  | Severity    |                  Description                      | Weight for Bug Score |
+  | :---------- | :------------------------------------------------ | :------------------: |
+  | crash       | Crash of the application or OS, loss of data      |          5           |
+  | block       | Regression corresponding to the previously  delivered official version. Impossible  operation of a function on any data with no work-around. Missing function previously requested in software requirements specification.   Destroyed data.     |        4            |
+  | major       | Impossible operation of a function with existing work-around. Incorrect operation of a function on a particular dataset. Impossible operation of a function after intentional input of incorrect data. Incorrect behavior of a function   after intentional input of incorrect data.  | 3 |
+  | minor       | Incorrect behavior of a function corresponding  to the description in software requirements specification. Insufficient performance  of a function.          |   2     |
+  | tweak       | Ergonomic inconvenience, need of light updates.   |          1           |
+  | text        | Inconsistence of program code to the Coding Standard. Errors in source text  (e.g.  unnecessary variable declarations, missing   comments, grammatical errors in user manuals). | 1 |
+  | trivial     | Cosmetic bugs.                                    |          1           |
+  | feature     | Bug fix, new feature, improvement that requires workload estimation and validation. | 1 |   
+  | integration request | Requested integration of an existing feature into the product.               |          0           |
+  | Just a question       | A question to be processed, without need   of any changes in the product.        |         0                |
+
+@subsubsection occt_contribution_workflow_3_1_2 Statuses of issues
+
+  The bug statuses that can be applied to the issues are listed in the table below. 
+  
+  | Status               |  Description                                                        |
+  | :------------------- | :----------------------------------------- |
+  | New                  | New just registered issue. Testing case should be created by Reporter. |
+  | Feedback             | The issue requires more information; the original posters should pay attention. |
+  | Assigned             | Assigned to a developer.  |
+  | Resolved + a resolution  |    The issue has been fixed, and now is waiting for revision.  |
+  |Revised  + a resolution   | The issue has been revised, and now is waiting for testing. |
+  | Tested               | The fix has been internally tested by the tester with success on the full non-regression database or its part and a test case has been created for this issue. |
+  | Verified             | The fix has been integrated into the master of the corresponding repository |
+  | Closed               | The fix has been integrated to the master. The corresponding test case has been executed successfully. The issue is no longer reproduced. |
+
+@subsubsection occt_contribution_workflow_3_1_3 Resolutions
+
+  **Resolution** is set when the bug is resolved. "Reopen" resolution is added automatically when the bug is reopened.
+
+  | Resolution            |                               Description                                    |
+  |:--------------------- | :--------------------------------------------------------------------------- |
+  | Open                  | The issue is being processed.                                                |
+  | Fixed                 | The issue has been successfully fixed.                                       |
+  | Reopened              | The bug has been reopened because of insufficient fix or regression.         |
+  |                       | Unable to reproduceThe bug is not reproduced.                                |
+  | Not fixable           | The bug cannot be fixed because it is a bug of third party software, or because it requires more workload than it can be allowed.        |
+  | Duplicate             | The bug for the same issue already exists in the tracker.                    |
+  | Not a bug             | It is a normal behavior in accordance with the specification of the product  |
+  | No change required    | The issue didn’t require any change of the product, such as a question issue |
+  | Suspended             | This resolution is set for Acknowledged status only. It means that the issue is waiting for fix until a special administrative decision is taken (e.g. a budget is not yet set in accordance with the contract)       | 
+  | Documentation updated | The issue was a normal behavior of the product, but the actions of the user  were wrong. The specification and the user manual have been updated  to reflect this issue.    |
+  | Won’t fix             | An administrative/contractual decision has been taken to not fix the bug     |
+
+@subsection occt_contribution_workflow_3_2 Update and evolution of documentation
+
+  The documentation on Open CASCADE Technology currently exists in three forms:
+  
+  * OCCT Technical Documentation generated automatically with Doxygen tool on the basis of comments in CDL or HXX files.    
+  * User’s Reference Documentation on OCCT packages and Products supplied in the form of PDF User’s guides
+  * OCCT Release Documentation supplied in the form of Release Notes with each release.
+  
+  It is strictly required to properly report the improvements and changes introduced in OCCT in all three forms of Documentation.
+  
+@subsubsection occt_contribution_workflow_3_2_1 Maintenance of CDL files
+
+  Every developer providing a contribution to the source code of OCC 
+  should make a relevant change in the corresponding header file, including CDL.
+
+  Making the appropriate comments is mandatory in the following cases:
+  
+  * Development of a new package / class / method / enumeration;
+  * Modification of an existing package / class / method / enumeration that changes its behavior;
+  * Modification / new development impacts at other packages / classes / methods / enumerations, the documentation  which of should be modified correspondingly.  
+
+  The only case when the comments may be not required is introducing 
+  a modification that does not change the existing behavior in any noticeable way
+  or brings the behavior in accordance with the existing description.
+  
+  CDL description must be in good English, containing as much relevant 
+  information and as clear as possible. If the developer is unable to properly formulate 
+  his ideas in English or suspects that his description can be misunderstood, 
+  he should address to the Documentation Engineer for language assistance. 
+  Such action is completely subject to the discretion of the developer; however, 
+  the Documentation Engineer can require that the developer should provide a relevant 
+  technical documentation and reopen a bug until all documentation satisfies the requirements above.
+
+@subsubsection occt_contribution_workflow_3_2_2 Maintenance of the User’s Reference Documentation
+
+  The User’s Reference Documentation is distributed among a number of User’s Guides, 
+  each describing a certain module of OCCT. 
+  The User's Guides do not cover the entire functionality of OCCT; 
+  however, they describe most widely used and important packages.
+  
+  In most aspects the User's Guides present the information that is contained in CDL descriptions for methods, classes, etc., only from a different point of view. Thus, it is required that any developer who implements a new or modifies an existing package / class / method / enumeration and adds a description of new development or changes in the corresponding CDL file should also check if this class  package / class / method / enumeration or the package / class, to which the added class / method belongs is already described in the documentation and update the User’s Reference Documentation correspondingly.
+
+3.2.3. Preparation of the Release Documentation
+
+  Before changing the bug Status to RESOLVED, the developer should provide a description of the implemented work using the "Additional information and documentation updates" field of Mantis bugtracker. 
+  
+  This description is used for the Release Documentation and has the following purposes:
+  
+  * to inform the OCCT users about the main features and improvements implemented in the platform in the release;
+  * to give a complete and useable list of changes introduced into the OCCT since the latest version. 
+
+  The changes should be described from the user’s viewpoint so that the text 
+  could be comprehensible even for beginners having a very vague idea about OCCT. 
+  If the developer is unable to properly formulate his ideas in English or suspects 
+  that his description can be misunderstood, he should address to the Documentation Engineer 
+  for language assistance. Such action is completely subject to the discretion of the developer; 
+  however, the Documentation Engineer can require that the developer 
+  should provide a relevant technical documentation and reopen a bug 
+  until all documentation satisfies the requirements.
+
+  **Note**, that it is required to single out the changes in the OCCT behavior as compared to the previous versions and especially the changes to be considered when porting from the previous version of OCCT.
+
+For example: 
+*  If global macros XXX() was used in the code of your application, revise it for direct use of the argument stream object. 
+*  You might need to revise the code related to text display in 3d viewer to take into account new approach of using system fonts via XXX library. 
+
+  The **Documentation Engineer** is responsible for preparation of the version Release Notes 
+  and update of the User’s Guides. If the **Documentation Engineer** considers that the description currently provided by the **Developer** is somehow inadequate or unsatisfactory he can demand the **Developer** to rewrite the documentation with the **Documentation Engineer’s** assistance.

dox/dev_guides/dev_guides.md

@@ -8,7 +8,7 @@ The following documents provide information on OCCT building, development and te
 * @subpage dev_guides__coding_rules "Coding Rules"
 * Contribution Workflow
 * Guide to installing and using Git for OCCT development
-* @subpage dev_guides__tests "Automatic Testing system"
+ @subpage dev_guides__tests "Automatic Testing system"
 
 Two other documents provide details on obsolete technologies used by OCCT, 
 to be removed in future releases:

dox/dev_guides/git_guide/git_guide.md

@@ -0,0 +1,602 @@
+Guide to installing and using Git for OCCT development {#dev_guides_git_guide}
+=================================
+
+@tableofcontents 
+
+@section occt_gitguide_1 Overview
+
+@subsection occt_gitguide_1_1 Purpose
+
+  The purpose of this document is to provide a practical introduction to Git 
+  to OCCT developers who are not familiar with this tool 
+  and to facilitate the use of the official OCCT Git repository for code contribution to OCCT.
+
+  Reading this document does not exempt from the need to learn Git concepts and tools. 
+  Please consult a book or manual describing Git to get acquainted with this tool. 
+  Many good books on Git can be found at http://git-scm.com/documentation 
+  
+  For the experienced Git users it can be enough to read sections 1 and 3
+   of this document to start working with the repository.
+   
+  Please make sure to get familiar with the Contribution Workflow document 
+  that describes how Git is used for processing contributions to OCCT.
+  
+  This and related documents are available at the Resources page 
+  of the OCCT development portal at http://dev.opencascade.org/index.php?q=home/resources. 
+
+@subsection occt_gitguide_1_2 Git URL
+
+  URL of the official OCCT source code Git repository (accessed by SSH protocol) is:
+  
+   gitolite@git.dev.opencascade.org:occt
+  
+  or 
+  
+   ssh://gitolite@git.opencascade.org/occt.git
+
+@subsection occt_gitguide_1_3 Content
+
+The official repository contains:
+
+  * The current certified version of OCCT: the "master" branch. This branch is updated by the Bugmaster only. Official OCCT releases are marked by tags.
+  * Topic branches created by contributors to submit changes for review / testing or for collaborative development.    The topic branches should be named by the pattern "CR12345" where 12345    is the ID of the relevant issue registered in Mantis (without leading zeroes),    and "CR" stands for "Change Request". The name can have an additional postfix used if more than    one branch was created for the same issue.
+  * Occasionally topic branches with non-standard names can be created by the Bugmaster for special needs.
+
+@subsection occt_gitguide_1_4 Short rules of use
+
+  The name specified in the user.name field in Git configuration should correspond 
+  to your login name on the OCCT development portal. 
+  This is important to clearly identify the authorship of commits. 
+  (The full real name can be used as well; in this case add the login username in parentheses.)
+  
+  By default, contributors are allowed to push branches only with the names starting with CR 
+  (followed by the relevant Mantis issue ID). 
+  Possibility to work with other branches can be enabled by the Bugmaster on request.
+  
+  The branch is created by the developer in his local repository when the development of a contribution starts. 
+  The branch for new developments is to be created from the current master. 
+  The branch for integration of patches or developments based on an obsolete version 
+  is created from a relevant tag or commit. The branch should be pushed to the official repo 
+  only when sharing with other people (for collaborative work or review / testing) is needed. 
+  
+  Rebasing the local branch to the current master is encouraged before the first submission 
+  to the official repository. If rebasing was needed after the branch is pushed to the official repo, 
+  the rebased branch should have a different name (use suffix).
+  
+  Integration of contributions that have passed certification testing is made exclusively by the Bugmaster. 
+  Normally this is made by rebasing the contribution branch on the current master 
+  and squashing it into a single commit. This is made to have the master branch history plain and clean, 
+  following the general rule “one issue – one commit”. 
+  The description of the commit integrated to the master branch is taken from the Mantis issue 
+  (ID, 'Summary', followed by the information from 'Documentation' field if present).
+  
+  In special cases when it is important to save the  commits history in the branch 
+  (e.g. in case of  a long-term development integration) it can be integrated by merge (no fast-forward).
+  
+  The authorship of the contribution is respected by preserving the Author field of the commit when integrating.
+  Branches are removed from the official repository when integrated to the master. 
+  The Bugmaster can also remove branches which have no commits during one-month period.
+  
+  The Bugmaster may ask the developer (normally the one who produced the contribution) 
+  to rebase a branch on the current master, in the case if merge conflicts appear during integration.
+
+@subsection occt_gitguide_1_5 Version of Git
+
+  The repository is tested to work with Git 1.7.6 to 1.7.9. 
+  Please do not use versions below 1.7.1 as they are known to cause troubles.
+
+@section occt_gitguide_2 Installing Tools for Work with Git
+
+@subsection occt_gitguide_2_1 Windows platform
+
+  Installation of Git for Windows (provided by MSysGit project) is required. 
+  
+  In addition, it is recommended to install TortoiseGit to work with Git on Windows. 
+  If you do not install TortoiseGit or any other GUI tool, 
+  you can use GitGui and Gitk GUI tools delivered with Git and available on all platforms.
+
+@subsubsection occt_gitguide_2_1_1 Installation of Git for Windows
+
+  Download Git for Windows distributive from http://code.google.com/p/msysgit/downloads/list.
+  During the installation:
+
+  * Select Windows Explorer integration options:
+    * Git Bash Here
+    * Git GUI Here
+    
+@image html OCCT_GitGuide_V2_image001.png
+@image latex OCCT_GitGuide_V2_image001.png
+
+  * To avoid a mess in your PATH, we recommend selecting ‘Run Git from Windows Prompt’ in the environment settings dialog: 
+  
+@image html OCCT_GitGuide_V2_image002.png
+@image latex OCCT_GitGuide_V2_image002.png
+
+  * In "Configuring the line ending conversions" dialog, select "Checkout Windows-style, commit Unix style endings".
+  
+@image html OCCT_GitGuide_V2_image003.png
+@image latex OCCT_GitGuide_V2_image003.png
+ 
+  Note that by default Git user interface is localized to the system default language. 
+  If you prefer to work with the English interface, remove or rename .msg localization file 
+  in subdirectories *share/git-gui/lib/msgs* and *share/gitk/lib/msgs* of the Git installation directory.
+  
+  Before the first commit to the OCCT repository, make sure that your User Name in the Git configuration file (file *.gitconfig* in the $HOME directory) is equal to your username on the OCCT development portal. 
+
+@subsubsection occt_gitguide_2_1_2 Installation and configuration of TortoiseGit
+
+  Download TortoiseGit distributive from http://code.google.com/p/tortoisegit/downloads/list. 
+  Launch the installation.
+
+  * Select your SSH client. Choose OpenSSH if you prefer to use command-line tools 
+   for SSH keys generation, or TortoisePLink if you prefer to use GUI tool (PuttyGen, see 3.2):
+   
+@image html OCCT_GitGuide_V2_image004.png
+@image latex OCCT_GitGuide_V2_image004.png
+
+  * Complete the installation.
+  
+@image html OCCT_GitGuide_V2_image005.png
+@image latex OCCT_GitGuide_V2_image005.png
+  
+  TortoiseGit integrates to Windows Explorer, thus it is possible to use popup menu in Windows Explorer to access its functionality:
+ 
+  Note that if you have installed MSysGit or have Git installed in non-default path, 
+  on the first time you use TortoiseGit you may get the message demanding to define path to Git. 
+  In such case, click on **Set MSysGit path** button and add the path to git.exe 
+  and path to MigGW libraries in the Settings dialog.
+
+  * After the installation  select Start -> Programs -> TortoiseGit Settings to configure TortoiseGit.
+  
+  Select Git->Config to add your user name and Email address to the local .gitconfig file
+  
+  @image html OCCT_GitGuide_V2_image006.png
+  @image latex OCCT_GitGuide_V2_image006.png
+
+@subsection occt_gitguide_2_2 Linux platform
+
+  We assume that Linux users have Git already installed and available in the PATH.
+  
+  Make sure to configure Git so that the user name is equal to your username 
+  on the OCCT development portal, and set SafeCrLf option to true:
+
+~~~~~
+    > git config --global user.name "Your User Name"
+    > git config --global user.email your@mail.address
+    > git config --global your@mail.address
+~~~~~
+
+@section occt_gitguide_3 Getting access to the repository
+
+@subsection occt_gitguide_3_1 Prerequisites
+
+  Access to the repository is granted to the users who have signed the Contributor License Agreement.
+  
+  The repository is accessed by SSH protocol, thus you need to register your public SSH key 
+  on the development portal to get access to the repository.
+  
+  SSH keys are used for secure authentication of the user when accessing the Git server. 
+  Private key is the one stored on the user workstation (optionally encrypted). 
+  Open (or public) key is stored in the user account page on the web site. 
+  When Git client accesses the remote repository through SSH, 
+  it uses this key pair to identify the user and acquire relevant access rights.
+  
+  Normally when you have Git installed, you should have also SSH client available. 
+  On Unix/Linux it is installed by default in the system. 
+  On Windows it is typical to have several SSH clients installed; 
+  in particular they are included with Cygwin, Git, TortoiseGit.
+  
+  It is highly recommended to use the tools that come 
+  with the chosen Git client for generation of SSH keys. 
+  Using incompatible tools (e.g. ssh-keygen.exe from Cygwin for code generation, 
+  and TortoiseGit GUI with a default Putty client for connection to server) 
+  may lead to authentication problems.
+
+@subsection occt_gitguide_3_2 How to generate a key
+
+@subsubsection occt_gitguide_3_2_1 Generating key with Putty
+
+  Use this option if you have installed TortoiseGit (or other GUI Git client on Windows) 
+  and have chosen “TortoisePLink” (or other Putty client) as SSH client during installation.
+  
+  To generate the key with this client, run Puttygen (e.g. from Start menu -> TortoiseGit -> Puttygen), 
+  then click Generate and move mouse cursor over the blank area until the key is generated. 
+  
+@image html OCCT_GitGuide_V2_image007.png "Putty key generator"
+@image latex OCCT_GitGuide_V2_image007.png "Putty key generator"
+
+  After the key is generated, you will see GUI controls to define the public key comment 
+  and / or specify the password for the private key protection. 
+  When done, save both the public and the private key to the files of your choice 
+  (make sure to store your private key in a secure place!).
+  
+  Copy the public key as shown by Puttygen to the clipboard to add it in your account. 
+  Do not copy the Putty public key file content -- it is formatted in a way not suitable for the web site.
+
+@subsubsection occt_gitguide_3_2_2 Generating key with command-line tools
+
+  Use this option if you work on Linux or if you have chosen “OpenSSH” as SSH client 
+  during installation of TortoiseGit (or other Windows tool).
+  
+  Make sure that you have *ssh* and *ssh-keygen* commands in the path. 
+  On Windows, you might need to start 'Git Bash' command prompt window provided by Git for Windows.
+  
+  Use the following command to generate SSH keys:
+~~~~~  
+    > ssh-keygen -t rsa -C "your@mail.address"
+~~~~~  
+
+  The last argument is an optional comment, which can be included with the public key and used to distinguish between different keys (if you have many).  The common practice is to put here your mail address or workstation name.
+  
+  The command will ask you where to store the keys. It is recommended to accept the default path *$HOME/.ssh/id_rsa*. Just press Enter for that. You will be warned if a key is already present in the specified file; you can either overwrite it by the new one, or stop generation and use the old key.
+    
+  If you want to be on the safe side, enter password to encrypt the private key. You will be asked to enter this password each time you use that key (e.g. access a remote Git repository), unless you use the tool that caches the key (like TortoiseGit). If you do not want to bother, enter an empty string.  
+  
+  On Windows, make sure to note the complete path to the generated files (the location of your $HOME might be not obvious). Two key files will be created in the specified location (by default in $HOME/.ssh/):
+  
+  * *id_rsa* - private key
+  * id_rsa.pub - public key
+  
+  The content of the public key file (one text line) is the key to be added to the user account on the site (see below).
+
+@subsubsection occt_gitguide_3_2_3 Generating key with Git GUI
+
+  GitGUI (standard GUI interface included with Git) provides the option 
+  to either generate the SSH key (if not present yet) or show the existing one. 
+  Click Help/Show SSH key and copy the public key content for adding to the user account page (see below).
+
+@subsection occt_gitguide_3_3 Adding public key in your account
+
+  Log in on the portal http://dev.opencascade.org and click on 'My account' link to the right. 
+  If you have a Contributor status, you will see 'SSH keys' tab to the right. 
+  Click on that tab, then click 'Add a public key', and paste the text of the public key 
+  (see above sections on how to generate the key) into the text box. 
+  Click "Save" to input the key to the system. 
+  
+  Note that a user can have several SSH keys. 
+  You can distinguish between these keys by the Title field ID; by default it is taken from SSH key comment. 
+  It is typical to use your e-mail address or workstation name for this field; no restrictions are set by the portal.
+  
+@image html OCCT_GitGuide_V2_image008.png
+@image latex OCCT_GitGuide_V2_image008.png
+
+  Please note that some time (5-10 min) is needed for the system 
+  to update the configuration after the new key is added. 
+  After that time, you can try accessing Git.
+
+@section occt_gitguide_4 WORK WITH REPOSITORY: DEVELOPER OPERATIONS
+
+@subsection occt_gitguide_4_1 General workflow
+
+  To start working with OCCT source repository, you need to create its clone in your local system. 
+  This cloned repository will manage your working copy of the sources 
+  and provide you the means to exchange code between your clone and the origin. 
+  
+  In most cases it is sufficient to have one clone of the repository; 
+  your working copy will be updated automatically by Git when you switch branches.
+  
+  The typical development cycle for an issue is as follows:
+
+  * Create a new branch for your development, basing on the selected version of the sources 
+   (usually the current master) and switch your working copy to it
+  * Develop and test your change. Note that for the first time, and after any changes 
+   made in CDL files you will have to re-generate build scripts or Visual Studio projects using WOK. 
+  * Do as many commits in your branch as you feel convenient; 
+   the general recommendation is to commit every stable state (even incomplete), to record the history of your development.
+  * Push your branch to the repository when your development is complete or when you need to share it with other people (e.g. for review)
+  * Before the first push, rebase your local branch on the latest master; 
+   consider collapsing the history in one commit unless you think the history of your commits is interesting for others. 
+   Make sure to provide a good commit message.
+  * Do not amend the commits that have been already pushed in the remote repository, 
+   If you need to rebase your branch, commit the rebased branch under a different name, and remove the old branch.
+  
+  You can switch to another branch at any moment 
+  (unless you have some uncommitted changes in the working copy) 
+  and return back to the branch when necessary (e.g. to take into account review remarks). 
+  Note that only the sources that are different between the switched branches will be modified, 
+  thus required recompilation should be reasonably small in most cases.
+
+@subsection occt_gitguide_4_2 Cloning official repository
+
+  Clone the official OCCT repository in one of following ways:
+
+  * From command line by command: 
+
+~~~~~  
+    > git clone gitolite@git.dev.opencascade.org:occt <path>
+~~~~~
+
+  where <i><path></i> is the path to the new folder which will be created for the repository.
+    
+  * In TortoiseGit: right-click in the Explorer window, then choose "Git Clone":
+ 
+@image html OCCT_GitGuide_V2_image009.png
+@image latex OCCT_GitGuide_V2_image009.png
+
+  If you have chosen Putty as SSH client during TortoiseGit installation, check the “Load Putty Key” option and specify the location of the private key file saved by PuttyGen (see 3.2.1). This shall be done for the first time only.   
+  
+  Note that on the first connection to the repository server you may be requested to enter a password for your private SSH key; further you can get a message that the authenticity of the host cannot be established and will be asked if you want to continue connecting or not:
+
+@image html OCCT_GitGuide_V2_image010.png
+@image latex OCCT_GitGuide_V2_image010.png
+
+  Choose “Yes” to continue. Then the host’s key will be stored in $HOME/.ssh/known_hosts file.
+
+@subsection occt_gitguide_4_3 Branch creation
+
+  You need to create a branch when you are going to start development of a new change, 
+  apply a patch, etc. It is recommended to fetch updates from the remote repository 
+  before this operation, to make sure you work with the up-to-date version.
+  
+  Create a branch from the current master branch unless you need to base your development on a particular version or revision. 
+
+In the console:
+
+~~~~~
+    > git checkout -b CR12345 origin/master
+~~~~~
+  
+In TortoiseGit: 
+  * Go to the local copy of the repository. 
+  * Right-click in the Explorer window, then choose "Git Create Branch".
+  
+@image html OCCT_GitGuide_V2_image011.png
+@image latex OCCT_GitGuide_V2_image011.png
+
+  * Select “Base On” Branch remotes/origin/master 
+
+@image html OCCT_GitGuide_V2_image012.png
+@image latex OCCT_GitGuide_V2_image012.png
+
+  Check option ‘Switch to new branch’ if you are going to start working with the newly created branch immediately.
+
+@subsection occt_gitguide_4_4 Branch switching
+
+  If you need to switch to another branch, use Git command checkout for that.
+  In the console:
+
+~~~~~
+    > git checkout CR12345
+~~~~~
+  
+  In TortoiseGit: right-click, TortoiseGit -> Checkout/switch
+ 
+@image html OCCT_GitGuide_V2_image013.png
+@image latex OCCT_GitGuide_V2_image013.png
+
+  Note that in order to work with the branch locally you need to set option 
+  “Create new branch” when you checkout the branch from the remote repository for the first time. 
+  Option “Track” stores association between the local branch and the original branch in a remote repository.
+
+@subsection occt_gitguide_4_5 Committing branch changes
+
+  Commit your changes locally as soon as a stable status of the work is reached. 
+  Make sure to review carefully the committed changes beforehand to avoid unintentional commit of a wrong code. 
+  
+  * In the console:
+  
+~~~~~
+    > git diff
+    …
+    > git commit -a -m "Write meaningful commit message here"
+~~~~~
+
+  Option –a tells the command to automatically include (stage) files 
+  that have been modified or deleted, but it will omit the new files that might have been added by you. 
+  To commit such new files, you must add (stage) them before commit command.
+
+  To find new unstaged files and them to commit, use commands:
+
+~~~~~
+    > git status -s
+      ?? file1.hxx 
+      ?? file2.cxx
+    > git add file1.hxx file2.cxx
+~~~~~
+
+  * In TortoiseGit: right-click, choose “Git Commit -> CR…”:
+ 
+@image html OCCT_GitGuide_V2_image014.png
+@image latex OCCT_GitGuide_V2_image014.png
+
+  Unstaged files will be shown if you check the option ‘Show Unversioned Files’. 
+  Double-clock on each modified file to see the changes to be committed (as a difference vs. the base version). 
+
+@subsection occt_gitguide_4_6 Pushing branch to the remote repository
+
+  When the code developed in your local branch is ready for review, 
+  or you need to share it with others, push your local changes to the remote repository.
+  
+  * In the console:
+
+~~~~~  
+    > git push "origin" CR12345:CR12345
+~~~~~
+
+  * In TortoiseGit: right-click, TortoiseGit -> Push
+
+@image html OCCT_GitGuide_V2_image015.png
+@image latex OCCT_GitGuide_V2_image015.png
+
+Note that Git will forbid pushing a branch if the corresponding remote branch already exists and has some changes, which are not in the history of your local branch. This may happen in different situations:
+  * You have amended the last commit which is already in the remote repository. 
+   If you are sure that nobody else uses your branch, push again with ‘force’ option. 
+  * You have rebased your branch, so that now it is completely different 
+   from the branch in the remote repository. In this case, push it under a different name (add a suffix): 
+ 
+@image html OCCT_GitGuide_V2_image016.png
+@image latex OCCT_GitGuide_V2_image016.png
+
+  Then remove the original remote branch so that other people recognize that it has been replaced by the new one. For that, select TortoiseGit -> Push again, then select an empty line for your local branch name, 
+  and enter the name of the branch to be removed in ‘Remote’ field:
+
+@image html OCCT_GitGuide_V2_image017.png
+@image latex OCCT_GitGuide_V2_image017.png
+
+  * The other developer has committed some changes in the remote branch. 
+   In this case, pull changes from the remote repository to have them merged 
+   with your version, and push your branch after it is successfully merged.
+
+@subsection occt_gitguide_4_7 Synchronizing with remote repository
+
+  Maintain your repository synchronized with the remote one and clean unnecessary stuff regularly.
+  Use Git command fetch with option prune to get update of all branches 
+  from the remote repository and to clean your local repository from the remote branches that have been deleted.
+  
+  * In the console:
+
+~~~~~  
+    > git fetch --prune 
+~~~~~
+    
+  * In TortoiseGit:
+  
+@image html OCCT_GitGuide_V2_image018.png
+@image latex OCCT_GitGuide_V2_image018.png
+
+  If some changes have been made to the branch you are working with in the remote repository, 
+  use Git command pull to get the remote changes and merge them with your local branch. 
+  This operation is required in particular to update your local master branch when the remote master changes.
+  
+  * In console:
+~~~~~  
+    > git pull
+~~~~~    
+  * In TortoiseGit:
+
+@image html OCCT_GitGuide_V2_image019.png
+@image latex OCCT_GitGuide_V2_image019.png
+
+  Note that the local branches of your repository are the primary place 
+  where your changes are stored until they get integrated to the official version 
+  of OCCT (master branch). The branches submitted to official repository 
+  are for collaborative work, review, and integration; 
+  that repository should not be used for long-term storage of incomplete changes. 
+  
+Remove the local branches that you do not need any more. Note that you cannot delete the current branch, thus you need to switch to another one (e.g. master) if the branch you are going to delete is the current one.
+  
+  * In the console:
+~~~~~ 
+    > git branch -d CR12345
+~~~~~
+    
+  * In TortoiseGit: right-click, select TortoiseGit -> Show log
+
+@image html OCCT_GitGuide_V2_image020.png
+@image latex OCCT_GitGuide_V2_image020.png
+
+  Select “All branches” to view all branches.
+  Right-click on the branch you want to delete and select Delete… menu item corresponding to this branch. 
+ 
+  Note that the log view in TortoiseGit is a convenient tool 
+  to visualize and manage branches; it provides short-cuts to many functions described above.
+
+@subsection occt_gitguide_4_8 Applying a fix made on older version of OCCT
+
+  If you have a fix made on a previous version of OCCT, 
+  perform the following sequence of operations to prepare it 
+  for testing and integration to the current development version.
+
+  * Identify the version of OCCT on which the fix has been made. 
+   In most cases, this will be an OCCT release, e.g. OCCT 6.7.0.; 
+   then just find a tag or a commit corresponding to this version in the Git history log of the master branch.
+  * Create a branch basing on this tag or commit. In TortoiseGit history log: right-click on the base commit, then select **Create branch at this version**.
+  
+@image html OCCT_GitGuide_V2_image021.png
+@image latex OCCT_GitGuide_V2_image021.png
+
+  Check option **Switch to the new branch** to start working within the new branch immediately, or switch to it separately afterwards.
+
+  * Put your fix in the working copy, build and check that it works, then commit to the branch.
+  * Rebase the branch on the current master.
+  
+  In TortoiseGit: right-click on the working directory, 
+  then choose TortoiseGit->Rebase; then select *remotes/origin/master* as UpStream revision, and click **Start**:
+ 
+@image html OCCT_GitGuide_V2_image022.png
+@image latex OCCT_GitGuide_V2_image022.png
+
+  Note that you can get some conflicts during rebase. 
+  To resolve the conflicts double-click on each conflicted file 
+  (highlighted by red in the file list) to open visual merge tool. 
+  Switch between conflicting fragments by red arrows, and for each one 
+  decide if the code of one or both conflicting versions is to be taken. 
+  Use the toolbar.
+
+@subsection occt_gitguide_4_9 Rebasing with history clean-up
+
+  At some moments you might need to rebase your branch on the latest version of the master. 
+  
+  We recommend rebasing before the first submission of the branch 
+  for review or when the master has diverged substantially from your branch. 
+  
+  Rebasing is a good occasion to clean-up the history of commits in the branch. 
+  Consider collapsing (squashing, in terms of Git) the history of your branch 
+  into a single commit unless you deem that having separate commits is important 
+  for your future work with the branch or its code reviewing. 
+  Git also allows you to change the order of commits, edit commit contents and messages, etc. 
+  
+  Here is the sequence of actions to rebase your branch into a single commit:
+  
+  * Switch to your branch (e.g. “CR12345”)
+  * In TortoiseGit history log, select a branch to rebase on (usually remotes/origin/master) 
+   and in the context menu choose **Rebase “CR12345” onto this**.
+  * In the Rebase dialog, check **Squash All**.
+
+@image html OCCT_GitGuide_V2_image023.png
+@image latex OCCT_GitGuide_V2_image023.png
+
+  **Note** that you can also change the order of commits and define for each commit 
+  whether it should be kept (“pick”), edited, or just skipped.
+  
+  * Click **Start**.
+  * The process will stop if a conflict is detected. 
+   In such case, find files with status ‘Conflicted’ in the list (marked by red), 
+   and double-click on them to resolve the conflict. 
+   When all conflicts are resolved, click ‘Continue’.
+   
+@image html OCCT_GitGuide_V2_image024.png
+@image latex OCCT_GitGuide_V2_image024.png
+ 
+  * At the end of the process, edit the final commit message (it should start from the issue ID and  a description from Mantis in the first line, followed by a summary of actual changes), and click **Commit**.
+   
+@image html OCCT_GitGuide_V2_image025.png
+@image latex OCCT_GitGuide_V2_image025.png
+
+@section occt_gitguide_5 Work with repository: Reviewer operations
+
+@subsection occt_gitguide_5_1 Review branch changes using GitWeb
+
+  The changes made in the branch can be reviewed without direct access to Git, using GitWeb interface:
+
+  * Open GitWeb in your web browser: http://git.dev.opencascade.org/gitweb/?p=occt.git 
+  * Locate the branch you want to review among heads (click ‘…’ at the bottom of the page to see the full list).
+  * Click log (or shortlog) to see the history of the branch. 
+    
+  **Note** that the branch can contain more than one commit, and you need to distinguish commits 
+  that belong to that branch (those to be reviewed) from the commits 
+  corresponding to the previous state of the master branch. 
+  Normally the first commit in the list that starts from the ID 
+  of the other issue indicates the branching point; 
+  commits above it are the ones to be reviewed.
+  
+  * Click *commitdiff* on each log entry to review the changes (highlighted with color format).
+
+@subsection occt_gitguide_5_2 Review branch changes with TortoiseGit 
+
+  Use of TortoiseGit is recommended for convenient code review:
+
+  * Fetch the changes from the remote repository as described in 4.7;
+  * Right-click on the repository, choose TortoiseGit -> Show log;
+  * Locate the remote branch you need to review;
+  * To review commits one-by-one, select each commit in the log. 
+   The list of changed files is shown at the bottom of the window; 
+   double-click on the file will open visual compare tool.
+  * To review all changes made in the branch at once, or to compare 
+   two arbitrary revisions, select the corresponding commits in the log 
+   (e.g. the last commit in the branch and the branching point), 
+   right-click for the context menu, and choose **Compare revisions**.
+
+@image html OCCT_GitGuide_V2_image026.png
+@image latex OCCT_GitGuide_V2_image026.png
+

dox/overview/Overview.md

@@ -456,17 +456,17 @@ Remarks:
 
 **On Linux:**
 
-1. If OCCT was built by Code::Blocks   * use $CASROOT/draw_cbp.sh file to launch DRAWEXE executable;
-2. If OCCT was built by Automake    * use $CASROOT/draw_amk.sh file to launch DRAWEXE executable;
+1. If OCCT was built by Code::Blocks  use <i>$CASROOT/draw_cbp.sh</i> file to launch *DRAWEXE* executable;
+2. If OCCT was built by Automake    use <i>$CASROOT/draw_amk.sh</i> file to launch *DRAWEXE* executable;
 
 Draw[1]> prompt appears in the command window
 
-Type pload ALL
+Type *pload ALL*
 
 **On Windows:**
 
 Launch Draw executable from Open CASCADE Technology\\Test Harness\\Draw Test Harness 
-item of the Start\\Programs menu or Use $CASROOT\\draw.bat file to launch DRAWEXE executable.
+item of the Start\\Programs menu or Use <i>$CASROOT\\draw.bat</i> file to launch *DRAWEXE* executable.
 
 Draw[1]> prompt appears in the command window
 
@@ -474,36 +474,33 @@ Type pload ALL
 
 **Creating your first geometric objects**
 
-1. In the command window, type axo to create an axonometric view
-2. Type box b -10 -10 -10 20 20 20 to create a cube b of size 20, 
-   parallel to the X Y Z axis and centered on the origin. 
-   The cube will be displayed in the axonometric view in wireframe mode
-3. Type fit to fill the viewer with the cube
-4. Type pcylinder c 2 30 to create a cylinder c of radius 2 and height 30.
-   The cylinder will be displayed in addition to the cube
+1. In the command window, type *axo* to create an axonometric view
+2. Type *box b -10 -10 -10 20 20 20* to create a cube *b* of size 20, parallel to the X Y Z axis and centered on the origin. The cube will be displayed in the axonometric view in wireframe mode.
+3. Type *fit* to fill the viewer with the cube
+4. Type *pcylinder c 2 30* to create a cylinder *c* of radius 2 and height 30. The cylinder will be displayed in addition to the cube
 
 **Manipulating the view**
 
-1. Type clear to erase the view
-2. Type donly c to display the cylinder only
-3. Type donly b to display the cube only
-4. Type hlr hlr b to display the cube in the hidden line removal mode
+1. Type *clear* to erase the view
+2. Type *donly c* to display the cylinder only
+3. Type *donly b* to display the cube only
+4. Type *hlr hlr b* to display the cube in the hidden line removal mode
 
 **Running demonstration files**
 
-1. Type cd ../.. to return to the root directory
-2. Type cd src/DrawResources to reach the DrawResources directory
-3. Type source "Available Demo File" to run the demonstration provided with Open CASCADE
-4. The following demonstration files are available:
+1. Type *cd ../..* to return to the root directory
+2. Type *cd samples/tcl* to reach the *DrawResources* directory
+3. Type *source <demo_file>* to run the demonstration file provided with Open CASCADE. The following demonstration files are available:
+  * bottle.tcl
+  * challenge.tcl  
   * DataExchangeDemo.tcl
   * ModelingDemo.tcl
-  * OCAFDemo.tcl
   * VisualizationDemo.tcl
 
 **Getting Help**
 
-1. Type help to see all available commands
-2. Type help command-name to find out the arguments for a given command
+1. Type *help* to see all available commands
+2. Type *help <command_name>* to find out the arguments for a given command
 
 @subsection OCCT_OVW_SECTION_7_3 Programming Samples