0023962: Moving OCCT documentation to sources
authoribs <ibs@opencascade.com>
Thu, 17 Oct 2013 08:47:29 +0000 (12:47 +0400)
committerbugmaster <bugmaster@opencascade.com>
Thu, 17 Oct 2013 10:50:43 +0000 (14:50 +0400)
OCCT documentation (Overview and User Guides) has been converted from MS Word files to text-based MarkDown format and added to OCCT sources, in the new subfolder 'dox'. The HTML and PDF articles can be generated from the sources using Doxygen and MiKTeX. See the file OCCT_Docs_HowTo.md for details on the new documentation system.

This branch includes:

- new folder structure for Open CASCADE documentation
- sources of almost all OCCT User Guides and Overview
- tcl and bat scripts, which allow to generate HTML and PDF articles

259 files changed:
.gitattributes
.gitignore
LICENSE
dox/DoxygenLayout.xml [new file with mode: 0644]
dox/FILES.txt [new file with mode: 0644]
dox/Overview/LICENSE.md [new file with mode: 0644]
dox/Overview/Overview.md [new file with mode: 0644]
dox/dev_guides/building/automake.md [new file with mode: 0644]
dox/dev_guides/building/cmake.md [new file with mode: 0644]
dox/dev_guides/building/code_blocks.md [new file with mode: 0644]
dox/dev_guides/building/msvc.md [new file with mode: 0644]
dox/dev_guides/building/xcode.md [new file with mode: 0644]
dox/dev_guides/cdl/cdl.md [new file with mode: 0644]
dox/dev_guides/cdl/images/cdl_image001.jpg [new file with mode: 0644]
dox/dev_guides/cdl/images/cdl_image002.jpg [new file with mode: 0644]
dox/dev_guides/cdl/images/cdl_image003.jpg [new file with mode: 0644]
dox/dev_guides/cdl/images/cdl_image004.jpg [new file with mode: 0644]
dox/dev_guides/cdl/images/cdl_image005.jpg [new file with mode: 0644]
dox/dev_guides/cdl/images/cdl_image006.jpg [new file with mode: 0644]
dox/dev_guides/cdl/images/cdl_image007.jpg [new file with mode: 0644]
dox/dev_guides/cdl/images/cdl_image008.jpg [new file with mode: 0644]
dox/dev_guides/cdl/images/cdl_image009.jpg [new file with mode: 0644]
dox/dev_guides/cdl/images/cdl_image010.jpg [new file with mode: 0644]
dox/dev_guides/cdl/images/cdl_image011.jpg [new file with mode: 0644]
dox/dev_guides/cdl/images/cdl_image012.jpg [new file with mode: 0644]
dox/dev_guides/dev_guides.md [new file with mode: 0644]
dox/dev_guides/documentation/documentation.md [new file with mode: 0644]
dox/dev_guides/documentation/images/documentation_image001.png [new file with mode: 0644]
dox/dev_guides/tests/images/tests_image001.png [new file with mode: 0644]
dox/dev_guides/tests/tests.md [new file with mode: 0644]
dox/dev_guides/wok/images/wok_image001.jpg [new file with mode: 0644]
dox/dev_guides/wok/images/wok_image002.jpg [new file with mode: 0644]
dox/dev_guides/wok/images/wok_image003.jpg [new file with mode: 0644]
dox/dev_guides/wok/images/wok_image004.jpg [new file with mode: 0644]
dox/dev_guides/wok/wok.md [new file with mode: 0644]
dox/occdoc.tcl [new file with mode: 0644]
dox/overview/images/overview_c__ie.png [new file with mode: 0644]
dox/overview/images/overview_draw.png [new file with mode: 0644]
dox/overview/images/overview_installation.png [new file with mode: 0644]
dox/overview/images/overview_mvc.png [new file with mode: 0644]
dox/overview/images/overview_occttransparent.png [new file with mode: 0644]
dox/overview/images/overview_qt.png [new file with mode: 0644]
dox/overview/tutorial/images/tutorial_image001.png [new file with mode: 0644]
dox/overview/tutorial/images/tutorial_image002.png [new file with mode: 0644]
dox/overview/tutorial/images/tutorial_image003.png [new file with mode: 0644]
dox/overview/tutorial/images/tutorial_image004.png [new file with mode: 0644]
dox/overview/tutorial/images/tutorial_image005.png [new file with mode: 0644]
dox/overview/tutorial/images/tutorial_image006.png [new file with mode: 0644]
dox/overview/tutorial/images/tutorial_image007.png [new file with mode: 0644]
dox/overview/tutorial/images/tutorial_image008.png [new file with mode: 0644]
dox/overview/tutorial/images/tutorial_image009.png [new file with mode: 0644]
dox/overview/tutorial/images/tutorial_image010.png [new file with mode: 0644]
dox/overview/tutorial/images/tutorial_image011.png [new file with mode: 0644]
dox/overview/tutorial/images/tutorial_image012.png [new file with mode: 0644]
dox/overview/tutorial/images/tutorial_image013.png [new file with mode: 0644]
dox/overview/tutorial/images/tutorial_image014.png [new file with mode: 0644]
dox/overview/tutorial/images/tutorial_image015.png [new file with mode: 0644]
dox/overview/tutorial/images/tutorial_image016.png [new file with mode: 0644]
dox/overview/tutorial/images/tutorial_image017.png [new file with mode: 0644]
dox/overview/tutorial/images/tutorial_image018.png [new file with mode: 0644]
dox/overview/tutorial/images/tutorial_image019.png [new file with mode: 0644]
dox/overview/tutorial/tutorial.md [new file with mode: 0644]
dox/resources/occt_logo.png [new file with mode: 0644]
dox/start.tcl [new file with mode: 0644]
dox/technical_overview/images/technical_overview_over.png [new file with mode: 0644]
dox/technical_overview/technical_overview.md [new file with mode: 0644]
dox/user_guides/draw_test_harness/draw_test_harness.md [new file with mode: 0644]
dox/user_guides/draw_test_harness/images/draw_test_harness_image001.jpg [new file with mode: 0644]
dox/user_guides/draw_test_harness/images/draw_test_harness_image002.jpg [new file with mode: 0644]
dox/user_guides/foundation_classes/foundation_classes.md [new file with mode: 0644]
dox/user_guides/foundation_classes/images/foundation_classes_image001.jpg [new file with mode: 0644]
dox/user_guides/foundation_classes/images/foundation_classes_image002.jpg [new file with mode: 0644]
dox/user_guides/foundation_classes/images/foundation_classes_image003.jpg [new file with mode: 0644]
dox/user_guides/foundation_classes/images/foundation_classes_image004.jpg [new file with mode: 0644]
dox/user_guides/foundation_classes/images/foundation_classes_image005.jpg [new file with mode: 0644]
dox/user_guides/foundation_classes/images/foundation_classes_image006.jpg [new file with mode: 0644]
dox/user_guides/foundation_classes/images/foundation_classes_image007.jpg [new file with mode: 0644]
dox/user_guides/foundation_classes/images/foundation_classes_image008.jpg [new file with mode: 0644]
dox/user_guides/iges/iges.md [new file with mode: 0644]
dox/user_guides/iges/images/iges_image001.jpg [new file with mode: 0644]
dox/user_guides/iges/images/iges_image002.jpg [new file with mode: 0644]
dox/user_guides/iges/images/iges_image003.jpg [new file with mode: 0644]
dox/user_guides/iges/images/iges_image004.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image001.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image002.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image003.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image004.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image005.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image006.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image007.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image008.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image009.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image010.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image011.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image012.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image013.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image014.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image015.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image016.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image017.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image018.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image019.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image020.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image021.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image022.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image023.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image024.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image025.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image026.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image027.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image028.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image029.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image030.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image031.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image032.png [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image033.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image034.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image035.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image036.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image037.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image038.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image039.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image040.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image041.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image042.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image043.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image044.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image045.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image046.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image047.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image048.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image049.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image050.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image051.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image052.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image053.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image054.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/images/modeling_algos_image055.jpg [new file with mode: 0644]
dox/user_guides/modeling_algos/modeling_algos.md [new file with mode: 0644]
dox/user_guides/modeling_data/images/modeling_data_image001.jpg [new file with mode: 0644]
dox/user_guides/modeling_data/images/modeling_data_image002.jpg [new file with mode: 0644]
dox/user_guides/modeling_data/images/modeling_data_image003.jpg [new file with mode: 0644]
dox/user_guides/modeling_data/images/modeling_data_image004.jpg [new file with mode: 0644]
dox/user_guides/modeling_data/images/modeling_data_image005.jpg [new file with mode: 0644]
dox/user_guides/modeling_data/images/modeling_data_image006.jpg [new file with mode: 0644]
dox/user_guides/modeling_data/images/modeling_data_image007.jpg [new file with mode: 0644]
dox/user_guides/modeling_data/images/modeling_data_image008.jpg [new file with mode: 0644]
dox/user_guides/modeling_data/images/modeling_data_image009.jpg [new file with mode: 0644]
dox/user_guides/modeling_data/images/modeling_data_image010.jpg [new file with mode: 0644]
dox/user_guides/modeling_data/images/modeling_data_image011.jpg [new file with mode: 0644]
dox/user_guides/modeling_data/images/modeling_data_image012.jpg [new file with mode: 0644]
dox/user_guides/modeling_data/images/modeling_data_image013.jpg [new file with mode: 0644]
dox/user_guides/modeling_data/images/modeling_data_image014.jpg [new file with mode: 0644]
dox/user_guides/modeling_data/modeling_data.md [new file with mode: 0644]
dox/user_guides/ocaf/images/ocaf_image001.png [new file with mode: 0644]
dox/user_guides/ocaf/images/ocaf_image002.png [new file with mode: 0644]
dox/user_guides/ocaf/images/ocaf_image003.png [new file with mode: 0644]
dox/user_guides/ocaf/images/ocaf_image004.png [new file with mode: 0644]
dox/user_guides/ocaf/images/ocaf_image005.png [new file with mode: 0644]
dox/user_guides/ocaf/images/ocaf_image006.png [new file with mode: 0644]
dox/user_guides/ocaf/images/ocaf_image007.png [new file with mode: 0644]
dox/user_guides/ocaf/images/ocaf_image008.png [new file with mode: 0644]
dox/user_guides/ocaf/images/ocaf_image009.png [new file with mode: 0644]
dox/user_guides/ocaf/images/ocaf_image010.png [new file with mode: 0644]
dox/user_guides/ocaf/images/ocaf_image011.png [new file with mode: 0644]
dox/user_guides/ocaf/images/ocaf_image012.png [new file with mode: 0644]
dox/user_guides/ocaf/images/ocaf_image013.png [new file with mode: 0644]
dox/user_guides/ocaf/images/ocaf_image014.png [new file with mode: 0644]
dox/user_guides/ocaf/images/ocaf_image015.png [new file with mode: 0644]
dox/user_guides/ocaf/images/ocaf_image016.png [new file with mode: 0644]
dox/user_guides/ocaf/images/ocaf_image017.png [new file with mode: 0644]
dox/user_guides/ocaf/ocaf.md [new file with mode: 0644]
dox/user_guides/shape_healing/images/shape_healing_image001.jpg [new file with mode: 0644]
dox/user_guides/shape_healing/images/shape_healing_image002.jpg [new file with mode: 0644]
dox/user_guides/shape_healing/images/shape_healing_image003.jpg [new file with mode: 0644]
dox/user_guides/shape_healing/images/shape_healing_image004.jpg [new file with mode: 0644]
dox/user_guides/shape_healing/images/shape_healing_image005.jpg [new file with mode: 0644]
dox/user_guides/shape_healing/images/shape_healing_image006.jpg [new file with mode: 0644]
dox/user_guides/shape_healing/images/shape_healing_image007.jpg [new file with mode: 0644]
dox/user_guides/shape_healing/images/shape_healing_image008.jpg [new file with mode: 0644]
dox/user_guides/shape_healing/images/shape_healing_image009.png [new file with mode: 0644]
dox/user_guides/shape_healing/images/shape_healing_image010.png [new file with mode: 0644]
dox/user_guides/shape_healing/images/shape_healing_image011.png [new file with mode: 0644]
dox/user_guides/shape_healing/images/shape_healing_image012.png [new file with mode: 0644]
dox/user_guides/shape_healing/images/shape_healing_image013.png [new file with mode: 0644]
dox/user_guides/shape_healing/images/shape_healing_image014.png [new file with mode: 0644]
dox/user_guides/shape_healing/shape_healing.md [new file with mode: 0644]
dox/user_guides/step/images/step_image001.jpg [new file with mode: 0644]
dox/user_guides/step/images/step_image002.jpg [new file with mode: 0644]
dox/user_guides/step/images/step_image003.jpg [new file with mode: 0644]
dox/user_guides/step/images/step_image004.jpg [new file with mode: 0644]
dox/user_guides/step/step.md [new file with mode: 0644]
dox/user_guides/tobj/images/tobj_image003.png [new file with mode: 0644]
dox/user_guides/tobj/images/tobj_image004.jpg [new file with mode: 0644]
dox/user_guides/tobj/images/tobj_image005.png [new file with mode: 0644]
dox/user_guides/tobj/images/tobj_image006.png [new file with mode: 0644]
dox/user_guides/tobj/images/tobj_image007.png [new file with mode: 0644]
dox/user_guides/tobj/images/tobj_image008.png [new file with mode: 0644]
dox/user_guides/tobj/tobj.md [new file with mode: 0644]
dox/user_guides/user_guides.md [new file with mode: 0644]
dox/user_guides/visualization/images/visualization_image001.jpg [new file with mode: 0644]
dox/user_guides/visualization/images/visualization_image002.jpg [new file with mode: 0644]
dox/user_guides/visualization/images/visualization_image003.jpg [new file with mode: 0644]
dox/user_guides/visualization/images/visualization_image004.png [new file with mode: 0644]
dox/user_guides/visualization/images/visualization_image005.png [new file with mode: 0644]
dox/user_guides/visualization/images/visualization_image006.jpg [new file with mode: 0644]
dox/user_guides/visualization/images/visualization_image007.jpg [new file with mode: 0644]
dox/user_guides/visualization/images/visualization_image008.jpg [new file with mode: 0644]
dox/user_guides/visualization/images/visualization_image009.jpg [new file with mode: 0644]
dox/user_guides/visualization/images/visualization_image010.jpg [new file with mode: 0644]
dox/user_guides/visualization/images/visualization_image011.jpg [new file with mode: 0644]
dox/user_guides/visualization/images/visualization_image012.jpg [new file with mode: 0644]
dox/user_guides/visualization/images/visualization_image013.jpg [new file with mode: 0644]
dox/user_guides/visualization/images/visualization_image014.jpg [new file with mode: 0644]
dox/user_guides/visualization/images/visualization_image015.jpg [new file with mode: 0644]
dox/user_guides/visualization/images/visualization_image016.jpg [new file with mode: 0644]
dox/user_guides/visualization/images/visualization_image017.jpg [new file with mode: 0644]
dox/user_guides/visualization/images/visualization_image018.jpg [new file with mode: 0644]
dox/user_guides/visualization/images/visualization_image019.jpg [new file with mode: 0644]
dox/user_guides/visualization/images/visualization_image020.jpg [new file with mode: 0644]
dox/user_guides/visualization/images/visualization_image021.jpg [new file with mode: 0644]
dox/user_guides/visualization/images/visualization_image022.jpg [new file with mode: 0644]
dox/user_guides/visualization/images/visualization_image023.png [new file with mode: 0644]
dox/user_guides/visualization/images/visualization_image024.png [new file with mode: 0644]
dox/user_guides/visualization/images/visualization_image025.jpg [new file with mode: 0644]
dox/user_guides/visualization/images/visualization_image026.jpg [new file with mode: 0644]
dox/user_guides/visualization/images/visualization_image027.jpg [new file with mode: 0644]
dox/user_guides/visualization/images/visualization_image028.jpg [new file with mode: 0644]
dox/user_guides/visualization/visualization.md [new file with mode: 0644]
dox/user_guides/wok/images/wok_image001.jpg [new file with mode: 0644]
dox/user_guides/wok/images/wok_image002.jpg [new file with mode: 0644]
dox/user_guides/wok/images/wok_image005.jpg [new file with mode: 0644]
dox/user_guides/wok/images/wok_image005.png [new file with mode: 0644]
dox/user_guides/wok/images/wok_image006.png [new file with mode: 0644]
dox/user_guides/wok/images/wok_image007.png [new file with mode: 0644]
dox/user_guides/wok/images/wok_image008.png [new file with mode: 0644]
dox/user_guides/wok/images/wok_image009.png [new file with mode: 0644]
dox/user_guides/wok/images/wok_image010.png [new file with mode: 0644]
dox/user_guides/wok/images/wok_image011.png [new file with mode: 0644]
dox/user_guides/wok/images/wok_image012.png [new file with mode: 0644]
dox/user_guides/wok/images/wok_image013.jpg [new file with mode: 0644]
dox/user_guides/wok/images/wok_image014.jpg [new file with mode: 0644]
dox/user_guides/wok/images/wok_image015.png [new file with mode: 0644]
dox/user_guides/wok/images/wok_image016.png [new file with mode: 0644]
dox/user_guides/wok/images/wok_image017.png [new file with mode: 0644]
dox/user_guides/wok/images/wok_image018.png [new file with mode: 0644]
dox/user_guides/wok/images/wok_image019.png [new file with mode: 0644]
dox/user_guides/wok/images/wok_image020.png [new file with mode: 0644]
dox/user_guides/wok/images/wok_image021.png [new file with mode: 0644]
dox/user_guides/wok/images/wok_image022.png [new file with mode: 0644]
dox/user_guides/wok/wok.md [new file with mode: 0644]
dox/user_guides/xde/images/xde_image001.jpg [new file with mode: 0644]
dox/user_guides/xde/images/xde_image002.jpg [new file with mode: 0644]
dox/user_guides/xde/images/xde_image003.jpg [new file with mode: 0644]
dox/user_guides/xde/images/xde_image004.jpg [new file with mode: 0644]
dox/user_guides/xde/images/xde_image005.jpg [new file with mode: 0644]
dox/user_guides/xde/images/xde_image006.jpg [new file with mode: 0644]
dox/user_guides/xde/xde.md [new file with mode: 0644]
gendoc.bat [new file with mode: 0644]

index 4c8bc7b..e805ec9 100644 (file)
@@ -34,6 +34,7 @@
 *.brep      eol=lf
 *.rle       eol=lf
 *.vrml      eol=lf
+*.md        eol=lf
 FILES       eol=lf
 PACKAGES    eol=lf
 EXTERNLIB   eol=lf
index 63daa70..d28e2ce 100644 (file)
@@ -7,6 +7,7 @@
 /ao1
 /sil
 /wnt
+/doc
 /drv
 /inc
 /work
@@ -45,8 +46,6 @@ Release
 /*.am
 /*.m4
 /*.ac
-/*.sh
-/*.bat
 /autom4te.cache
 /build_configure
 /configure
diff --git a/LICENSE b/LICENSE
index 0fe1d8b..77b310c 100644 (file)
--- a/LICENSE
+++ b/LICENSE
@@ -120,14 +120,16 @@ END OF THE TERMS AND
 CONDITIONS OF THIS LICENSE
 
 
-Open CASCADE S.A.S. is a French société par actions simplifiée having its   main offices at 1, place des Frères Montgolfier, 78280 Guyancourt, France. Its web site is located at the following address www.opencascade.com
+Open CASCADE S.A.S. is a French société par actions simplifiée having its main offices at 1, place in Frères Montgolfier, 78280 Guyancourt, France. Its web site is located at the following address www.opencascade.com
 
 
 Open CASCADE Technology Public License
 
 Schedule "A"
 
-The content of this file is subject to the Open CASCADE Technology Public License Version 6.5 (the "License"). You may not use the content of this file except in compliance with the License. Please obtain a copy of the License at http://www.opencascade.org and read it completely before using this file.
+The content of this file is subject to the Open CASCADE Technology Public License Version 6.5 (the "License"). 
+You may not use the content of this file except in compliance with the License. 
+Please obtain a copy of the License at http://www.opencascade.org and read it completely before using this file.
 
 The Initial Developer of the Original Code is Open CASCADE S.A.S., with main offices at  1, place des Frères Montgolfier, 78280 Guyancourt, France. The Original Code is copyright © Open CASCADE S.A.S., 2001. All rights reserved.
 
diff --git a/dox/DoxygenLayout.xml b/dox/DoxygenLayout.xml
new file mode 100644 (file)
index 0000000..21d15aa
--- /dev/null
@@ -0,0 +1,188 @@
+<doxygenlayout version="1.0">
+  <!-- Generated by doxygen 1.8.3.1 -->
+  <!-- Navigation index tabs for HTML output -->
+  <navindex>
+    <tab type="mainpage" visible="yes" title="Introduction"/>
+    <tab type="pages" visible="yes" title="Documents" intro="This section contains links to all OCCT documents that are available at the moment"/>
+    <tab type="modules" visible="yes" title="" intro=""/>
+    <tab type="namespaces" visible="yes" title="">
+      <tab type="namespacelist" visible="no" title="" intro=""/>
+      <tab type="namespacemembers" visible="yes" title="" intro=""/>
+    </tab>
+    <tab type="classes" visible="yes" title="Reference Manual">
+      <tab type="classlist" visible="no" title="" intro=""/>
+      <tab type="classindex" visible="$ALPHABETICAL_INDEX" title=""/> 
+      <tab type="hierarchy" visible="no" title="" intro=""/>
+      <tab type="classmembers" visible="no" title="" intro=""/>
+    </tab>
+    <tab type="files" visible="no" title="Files">
+      <tab type="filelist" visible="yes" title="" intro=""/>
+      <tab type="globals" visible="yes" title="" intro=""/>
+    </tab>
+    <tab type="examples" visible="no" title="" intro=""/>  
+  </navindex>
+
+  <!-- Layout definition for a class page -->
+  <class>
+    <briefdescription visible="yes"/>
+    <includes visible="$SHOW_INCLUDE_FILES"/>
+    <inheritancegraph visible="$CLASS_GRAPH"/>
+    <collaborationgraph visible="$COLLABORATION_GRAPH"/>
+    <memberdecl>
+      <nestedclasses visible="yes" title=""/>
+      <publictypes title=""/>
+      <publicslots title=""/>
+      <signals title=""/>
+      <publicmethods title=""/>
+      <publicstaticmethods title=""/>
+      <publicattributes title=""/>
+      <publicstaticattributes title=""/>
+      <protectedtypes title=""/>
+      <protectedslots title=""/>
+      <protectedmethods title=""/>
+      <protectedstaticmethods title=""/>
+      <protectedattributes title=""/>
+      <protectedstaticattributes title=""/>
+      <packagetypes title=""/>
+      <packagemethods title=""/>
+      <packagestaticmethods title=""/>
+      <packageattributes title=""/>
+      <packagestaticattributes title=""/>
+      <properties title=""/>
+      <events title=""/>
+      <privatetypes title=""/>
+      <privateslots title=""/>
+      <privatemethods title=""/>
+      <privatestaticmethods title=""/>
+      <privateattributes title=""/>
+      <privatestaticattributes title=""/>
+      <friends title=""/>
+      <related title="" subtitle=""/>
+      <membergroups visible="yes"/>
+    </memberdecl>
+    <detaileddescription title=""/>
+    <memberdef>
+      <inlineclasses title=""/>
+      <typedefs title=""/>
+      <enums title=""/>
+      <constructors title=""/>
+      <functions title=""/>
+      <related title=""/>
+      <variables title=""/>
+      <properties title=""/>
+      <events title=""/>
+    </memberdef>
+    <allmemberslink visible="yes"/>
+    <usedfiles visible="$SHOW_USED_FILES"/>
+    <authorsection visible="yes"/>
+  </class>
+
+  <!-- Layout definition for a namespace page -->
+  <namespace>
+    <briefdescription visible="yes"/>
+    <memberdecl>
+      <nestednamespaces visible="yes" title=""/>
+      <classes visible="yes" title=""/>
+      <typedefs title=""/>
+      <enums title=""/>
+      <functions title=""/>
+      <variables title=""/>
+      <membergroups visible="yes"/>
+    </memberdecl>
+    <detaileddescription title=""/>
+    <memberdef>
+      <inlineclasses title=""/>
+      <typedefs title=""/>
+      <enums title=""/>
+      <functions title=""/>
+      <variables title=""/>
+    </memberdef>
+    <authorsection visible="yes"/>
+  </namespace>
+
+  <!-- Layout definition for a file page -->
+  <file>
+    <briefdescription visible="yes"/>
+    <includes visible="$SHOW_INCLUDE_FILES"/>
+    <includegraph visible="$INCLUDE_GRAPH"/>
+    <includedbygraph visible="$INCLUDED_BY_GRAPH"/>
+    <sourcelink visible="yes"/>
+    <memberdecl>
+      <classes visible="yes" title=""/>
+      <namespaces visible="yes" title=""/>
+      <defines title=""/>
+      <typedefs title=""/>
+      <enums title=""/>
+      <functions title=""/>
+      <variables title=""/>
+      <membergroups visible="yes"/>
+    </memberdecl>
+    <detaileddescription title=""/>
+    <memberdef>
+      <inlineclasses title=""/>
+      <defines title=""/>
+      <typedefs title=""/>
+      <enums title=""/>
+      <functions title=""/>
+      <variables title=""/>
+    </memberdef>
+    <authorsection/>
+  </file>
+
+  <!-- Layout definition for a group page -->
+  <group>
+    <briefdescription visible="yes"/>
+    <groupgraph visible="$GROUP_GRAPHS"/>
+    <memberdecl>
+      <nestedgroups visible="yes" title=""/>
+      <dirs visible="yes" title=""/>
+      <files visible="yes" title=""/>
+      <namespaces visible="yes" title=""/>
+      <classes visible="yes" title=""/>
+      <defines title=""/>
+      <typedefs title=""/>
+      <enums title=""/>
+      <enumvalues title=""/>
+      <functions title=""/>
+      <variables title=""/>
+      <signals title=""/>
+      <publicslots title=""/>
+      <protectedslots title=""/>
+      <privateslots title=""/>
+      <events title=""/>
+      <properties title=""/>
+      <friends title=""/>
+      <membergroups visible="yes"/>
+    </memberdecl>
+    <detaileddescription title=""/>
+    <memberdef>
+      <pagedocs/>
+      <inlineclasses title=""/>
+      <defines title=""/>
+      <typedefs title=""/>
+      <enums title=""/>
+      <enumvalues title=""/>
+      <functions title=""/>
+      <variables title=""/>
+      <signals title=""/>
+      <publicslots title=""/>
+      <protectedslots title=""/>
+      <privateslots title=""/>
+      <events title=""/>
+      <properties title=""/>
+      <friends title=""/>
+    </memberdef>
+    <authorsection visible="yes"/>
+  </group>
+
+  <!-- Layout definition for a directory page -->
+  <directory>
+    <briefdescription visible="yes"/>
+    <directorygraph visible="yes"/>
+    <memberdecl>
+      <dirs visible="yes"/>
+      <files visible="yes"/>
+    </memberdecl>
+    <detaileddescription title=""/>
+  </directory>
+</doxygenlayout>
diff --git a/dox/FILES.txt b/dox/FILES.txt
new file mode 100644 (file)
index 0000000..0dbc6e0
--- /dev/null
@@ -0,0 +1,31 @@
+overview/overview.md
+overview/tutorial/tutorial.md
+technical_overview/technical_overview.md
+
+user_guides/user_guides.md
+user_guides/foundation_classes/foundation_classes.md
+user_guides/modeling_data/modeling_data.md
+user_guides/modeling_algos/modeling_algos.md
+user_guides/visualization/visualization.md
+user_guides/iges/iges.md
+user_guides/step/step.md
+user_guides/xde/xde.md
+user_guides/ocaf/ocaf.md
+user_guides/tobj/tobj.md
+user_guides/shape_healing/shape_healing.md
+user_guides/draw_test_harness/draw_test_harness.md
+user_guides/wok/wok.md
+
+dev_guides/dev_guides.md
+dev_guides/wok/wok.md
+dev_guides/cdl/cdl.md
+dev_guides/tests/tests.md
+dev_guides/documentation/documentation.md
+
+dev_guides/building/automake.md
+dev_guides/building/cmake.md
+dev_guides/building/code_blocks.md
+dev_guides/building/msvc.md
+dev_guides/building/xcode.md
+
+overview/license.md
\ No newline at end of file
diff --git a/dox/Overview/LICENSE.md b/dox/Overview/LICENSE.md
new file mode 100644 (file)
index 0000000..afb9b4b
--- /dev/null
@@ -0,0 +1,157 @@
+License {#occt_pubic_license}
+=======
+
+## Open CASCADE Technology Public License
+
+*License version: 6.6* @htmlonly<br />@endhtmlonly
+*March, 2013*
+
+Open CASCADE S.A.S. releases and makes publicly available the source code of the software Open CASCADE Technology to the free software development community under the terms and conditions of this license.
+
+It is not the purpose of this license to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this license has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice.
+
+
+Please read this license carefully and completely before downloading this software. By downloading, using, modifying, distributing and sublicensing this software, you indicate your acceptance to be bound by the terms and conditions of this license. If you do not want to accept or cannot accept for any reasons the terms and conditions of this license, please do not download or use in any manner this software.
+
+### 1. Definitions
+
+Unless there is something in the subject matter or in the context inconsistent therewith, the capitalized terms used in this License shall have the following meaning.
+
+"Applicable Intellectual Property Rights" means (a) with respect to the Initial Developer, any rights under patents or patents applications or other intellectual property rights that are now or hereafter acquired, owned by or assigned to the Initial Developer and that cover subject matter contained in the Original Code, but only to the extent necessary to use, reproduce, modify, distribute or sublicense the Original Code without infringement; and (b) with respect to You or any Contributor, any rights under patents or patents applications or other intellectual property rights that are now or hereafter acquired, owned by or assigned to You or to such Contributor and that cover subject matter contained in Your Modifications or in such Contributor's Modifications, taken alone or in combination with Original Code.
+
+"Contributor" means each individual or legal entity that creates or contributes to the creation of any Modification, including the Initial Developer.
+
+"Derivative Program": means a new program combining the Software or portions thereof with other source code not governed by the terms of this License.
+
+"Initial Developer": means Open CASCADE S.A.S., with main offices   at 1, place des Frères Montgolfier, 78280 Guyancourt, France.
+
+"Modifications": mean any addition to, deletion from or change to the substance or the structure of the Software. When source code of the Software is released as a series of files, a Modification is: (a) any addition to, deletion from or change to the contents of a file containing the Software or (b) any new file or other representation of computer program statements that contains any part of the Software. By way of example, Modifications include any debug of, or improvement to, the Original Code or any of its components or portions as well as its next versions or releases thereof.
+
+"Original Code": means (a) the source code of the software Open CASCADE Technology originally made available by the Initial Developer under this License, including the source code of any updates or upgrades of the Original Code and (b) the object code compiled from such source code and originally made available by Initial Developer under this License.
+
+"Software": means the Original Code, the Modifications, the combination of Original Code and any Modifications or any respective portions thereof.
+
+"You" or "Your": means an individual or a legal entity exercising rights under this License.
+
+
+### 2. Acceptance of license
+
+By using, reproducing, modifying, distributing or sublicensing the Software or any portion thereof, You expressly indicate Your acceptance of the terms and conditions of this License and undertake to act in accordance with all the provisions of this License applicable to You.
+
+
+### 3. Scope and purpose
+
+This License applies to the Software and You may not use, reproduce, modify, distribute, sublicense or circulate the Software, or any portion thereof, except as expressly provided under this License. Any attempt to otherwise use, reproduce, modify, distribute or sublicense the Software is void and will automatically terminate Your rights under this License.
+
+
+### 4. Contributor license
+
+Subject to the terms and conditions of this License, the Initial Developer and each of the Contributors hereby grant You a world-wide, royalty-free, irrevocable and non-exclusive license under the Applicable Intellectual Property Rights they own or control, to use, reproduce, modify, distribute and sublicense the Software provided that:
+
+You reproduce in all copies of the Software the copyright and other proprietary notices and disclaimers of the Initial Developer as they appear in the Original Code and attached hereto as Schedule "A" and any other notices or disclaimers attached to the Software and keep intact all notices in the Original Code that refer to this License and to the absence of any warranty;
+You include a copy of this License with every copy of the Software You distribute;
+If you distribute or sublicense the Software (as modified by You or on Your behalf as the case may be), You cause such Software to be licensed as a whole, at no charge, to all third parties, under the terms and conditions of the License, making in particular available to all third parties the source code of the Software;
+You document all Your Modifications, indicate the date of each such Modifications, designate the version of the Software You used, prominently include a file carrying such information with respect to the Modifications and duplicate the copyright and other proprietary notices and disclaimers attached hereto as Schedule "B" or any other notices or disclaimers attached to the Software with your Modifications.
+
+For greater certainty, it is expressly understood that You may freely create Derivative Programs (without any obligation to publish such Derivative Program) and distribute same as a single product. In such case, You must ensure that all the requirements of this License are fulfilled for the Software or any portion thereof.
+
+
+### 5. Your license
+
+You hereby grant all Contributors and anyone who becomes a party under this License a world-wide, non-exclusive, royalty-free and irrevocable license under the Applicable Intellectual Property Rights owned or controlled by You, to use, reproduce, modify, distribute and sublicense all Your Modifications under the terms and conditions of this License.
+
+
+### 6. Software subject to license
+
+Your Modifications shall be governed by the terms and conditions of this License. You are not authorized to impose any other terms or conditions than those prevailing under this License when You distribute and/or sublicense the Software, save and except as permitted under Section 7 hereof.
+
+
+### 7. Additional terms
+
+You may choose to offer, on a non-exclusive basis, and to charge a fee for any warranty, support, maintenance, liability obligations or other rights consistent with the scope of this License with respect to the Software (the "Additional Terms") to the recipients of the Software. However, You may do so only on Your own behalf and on Your sole and exclusive responsibility. You must obtain the recipient's agreement that any such Additional Terms are offered by You alone, and You hereby agree to indemnify, defend and hold the Initial Developer and any Contributor harmless for any liability incurred by or claims asserted against the Initial Developer or any Contributors with respect to any such Additional Terms.
+
+
+### 8. Disclaimer of warranty
+
+The Software is provided under this License on an "as is" basis, without warranty of any kind, including without limitation, warranties that the Software is free of defects, merchantable, fit for a particular purpose or non-infringing. The entire risk as to the quality and performance of the Software is with You.
+
+
+### 9. Liability
+
+Under no circumstances shall You, the Initial Developer or any Contributor be liable to any person for any direct or indirect damages of any kind including, without limitation, damages for loss of goodwill, loss of data, work stoppage, computer failure or malfunction or any and all other commercial damages or losses resulting from or relating to this License or indirectly to the use of the Software.
+
+
+### 10. Trademark
+
+This License does not grant any rights to use the trademarks, trade names and domain names "MATRA", "EADS Matra Datavision", "CAS.CADE", "Open CASCADE", "opencascade.com" and "opencascade.org" or any other trademarks, trade names or domain names used or owned by the Initial Developer.
+
+
+### 11. Copyright
+
+The Initial Developer retains all rights, title and interest in and to the Original Code. You may not remove the copyright © notice which appears when You download the Software.
+
+
+### 12. Term
+
+This License is granted to You for a term equal to the remaining period of protection covered by the intellectual property rights applicable to the Original Code.
+
+
+### 13. Termination
+
+In case of termination, as provided in Section 3 above, You agree to immediately stop any further use, reproduction, modification, distribution and sublicensing of the Software and to destroy all copies of the Software that are in Your possession or control. All sublicenses of the Software which have been properly granted prior to termination shall survive any termination of this License. In addition, Sections 5, 8 to 11, 13.2 and 15.2 of this License, in reason of their nature, shall survive the termination of this License for a period of fifteen (15) years.
+
+
+### 14. Versions of the license
+
+The Initial Developer may publish new versions of this License from time to time. Once Original Code has been published under a particular version of this License, You may choose to continue to use it under the terms and conditions of that version or use the Original Code under the terms of any subsequent version of this License published by the Initial Developer.
+
+
+### 15. Miscellaneous
+
+#### 15.1 Relationship of Parties
+
+This License will not be construed as creating an agency, partnership, joint venture or any other form of legal association between You and the Initial Developer, and You will not represent to the contrary, whether expressly, by implication or otherwise.
+
+#### 15.2 Independent Development
+
+Nothing in this License will impair the Initial Developer's right to acquire, license, develop, have others develop for it, market or distribute technology or products that perform the same or similar functions as, or otherwise compete with, Modifications, Derivative Programs, technology or products that You may develop, produce, market or distribute.
+
+#### 15.3 Severability
+
+If for any reason a court of competent jurisdiction finds any provision of this License, or portion thereof, to be unenforceable, that provision of the License will be enforced to the maximum extent permissible so as to effect the economic benefits and intent of the parties, and the remainder of this License will continue in full force and extent.
+
+
+@htmlonly<center>@endhtmlonly
+#### END OF THE TERMS AND CONDITIONS OF THIS LICENSE
+
+Open CASCADE S.A.S. is a French société par actions simplifiée having its main offices at 1, place in Frères Montgolfier, 78280 Guyancourt, France. Its web site is located at the following address  http://www.opencascade.com
+
+
+#### Open CASCADE Technology Public License
+
+#### Schedule "A"
+
+The content of this file is subject to the Open CASCADE Technology Public License Version 6.5 (the "License"). 
+You may not use the content of this file except in compliance with the License. 
+Please obtain a copy of the License at http://www.opencascade.org and read it completely before using this file. The Initial Developer of the Original Code is Open CASCADE S.A.S., with main offices at  1, place des Frères Montgolfier, 78280 Guyancourt, France. The Original Code is copyright © Open CASCADE S.A.S., 2001. All rights reserved.
+
+"The Original Code and all software distributed under the License are distributed on an "AS IS" basis, without warranty of any kind, and the Initial Developer hereby disclaims all such warranties, including without limitation, any warranties of merchantability, fitness for a particular purpose or non-infringement. 
+
+Please see the License for the specific terms and conditions governing rights and limitations under the License".
+
+#### End of Schedule "A"
+
+
+#### Open CASCADE Technology Public License
+
+#### Schedule "B"
+
+"The content of this file is subject to the Open CASCADE Technology Public License Version 6.5 (the "License"). You may not use the content of this file except in compliance with the License. Please obtain a copy of the License at http://www.opencascade.org and read it completely before using this file. The Initial Developer of the Original Code is Open CASCADE S.A.S., with main offices at  1, place des Frères Montgolfier, 78280 Guyancourt, France. The Original Code is copyright © Open CASCADE S.A.S., 2001. All rights reserved.
+
+Modifications to the Original Code have been made by ________________________. Modifications are copyright © [Year to be included]. All rights reserved.
+
+The software Open CASCADE Technology and all software distributed under the License are distributed on an "AS IS" basis, without warranty of any kind, and the Initial Developer hereby disclaims all such warranties, including without limitation, any warranties of merchantability, fitness for a particular purpose or non-infringement. Please see the License for the specific terms and conditions governing rights and limitations under the License".
+
+#### End of Schedule "B"
+
+@htmlonly</center>@endhtmlonly
\ No newline at end of file
diff --git a/dox/Overview/Overview.md b/dox/Overview/Overview.md
new file mode 100644 (file)
index 0000000..eb119f0
--- /dev/null
@@ -0,0 +1,604 @@
+Overview {#mainpage}
+========
+
+@section OCCT_OVW_SECTION_1 Welcome
+
+Welcome to Open CASCADE Technology version 6.6.0, a minor release, 
+which introduces a number of new features and improved traditional 
+functionality along with some changes over the previous maintenance release 6.5.5.
+
+This release makes Open CASCADE Technology even a more powerful and stable 
+development platform for 3D modeling and numerical simulation applications.
+
+Open CASCADE Technology 6.6.0 is a full-featured package that allows developing 
+applications on Windows and Linux platforms.
+
+@htmlonly<center>@endhtmlonly http://www.opencascade.org
+
+![](/overview/images/overview_occttransparent.png)
+
+Copyright © 2001-2013 OPEN CASCADE S.A.S.
+
+![](/resources/occt_logo.png)
+
+@htmlonly</center>@endhtmlonly
+
+@section OCCT_OVW_SECTION_2 Copyrights
+
+Copyright© 2001-2013 by OPEN CASCADE S.A.S. All rights reserved.
+
+ Trademark information
+----------------------
+
+You are hereby informed that all software is a property of its respective authors and is protected by 
+international and domestic laws on intellectual property and trademarks. 
+Should you need further information, please directly contact the authors.
+
+CAS.CADE and Open CASCADE are registered trademarks of OPEN CASCADE S.A.S.
+
+ Acknowledgement
+------------------
+
+The following parties are acknowledged for producing tools which are used within 
+Open CASCADE Technology libraries or for release preparation.
+
+You are hereby informed that all rights to the software listed below belong to its respective 
+authors and such software may not be freely available and/or be free of charge for any kind 
+of use or purpose. We strongly recommend that you carefully read the license of these products 
+and, in case you need any further information, directly contact their authors.
+
+**Qt** is a cross-platform application framework that is widely used for developing application software 
+with graphical user interface (GUI). Qt is free and open source software distributed under 
+the terms of the GNU Lesser General Public License. In OCCT Qt is used for programming samples. 
+If you need further information on Qt, please, refer to Qt Homepage (qt.digia.com).
+
+**Tcl** is a high-level programming language. Tk is a graphical user interface (GUI) toolkit, 
+with buttons, menus, listboxes, scrollbars, and so on. Taken together Tcl and Tk provide a solution 
+to develop cross-platform graphical user interfaces with a native look and feel. Tcl/Tk is under copyright by 
+Scriptics Corp., Sun Microsystems, and other companies. However, Tcl/Tk is an open source, and 
+the copyright allows you to use, modify, and redistribute Tcl/Tk for any purpose, without an 
+explicit license agreement and without paying any license fees or royalties. 
+To use Tcl/Tk, please refer to the Licensing Terms (http://www.tcl.tk/software/tcltk/license.html).
+
+**Robert Boehne** has developed **GNU Autoconf**, **Automake** and **Libtool** scripts and makefiles 
+for the Open CASCADE project http://sourceforge.net/projects/autoopencas/, 
+which became an initial groundwork for the build scripts based on respective GNU tools 
+(autoconf, automake and libtool) in Open CASCADE Technology version 4.0. 
+These scripts are now maintained by the OPEN CASCADE company.
+
+**GL2PS** is developed by Christophe Geuzaine and others. It is OpenGL to PostScript printing library. 
+The library is licensed under GL2PS LICENSE http://www.geuz.org/gl2ps/COPYING.GL2PS Version 2, November 2003.
+
+**FreeType 2** is developed by Antoine Leca, David Turner, Werner Lemberg and others. 
+It is a software font engine that is designed to be small, efficient, highly customizable and 
+portable while capable of producing high-quality output (glyph images). This product 
+can be used in graphic libraries, display servers, font conversion tools, 
+text image generation tools, and many other products.
+
+FreeType 2 is released under two open-source licenses: BSD-like FreeType License and the GPL.
+
+**Intel® Threading Building Blocks (TBB)** offers a rich and complete approach to expressing parallelism in a C++ program. 
+It is a library that helps you to take advantage of multi-core processor performance without having to be a threading expert. 
+Threading Building Blocks is not just a threads-replacement library. It represents a higher-level, task-based parallelism that 
+abstracts platform details and threading mechanisms for scalability and performance. 
+TBB is available under GPLv2 license with the runtime exception.
+
+Open CASCADE Technology WOK module on Windows also makes use of LGPL-licensed C routines   * regexp and getopt, taken from GNU C library.
+
+**Doxygen** (Copyright © 1997-2010 by Dimitri van Heesch) is open source documentation system for 
+C++, C, Java, Objective-C, Python, IDL, PHP and C#. This product is used in Open CASCADE Technology 
+for automatic creation of Technical Documentation from C++ header files. 
+If you need further information on Doxygen, please refer to http://www.stack.nl/~dimitri/doxygen/index.html.
+
+**Graphviz** is open source graph visualization software developed by John Ellson, Emden Gansner, Yifan Hu and Arif Bilgin. 
+Graph visualization is representiation of structured information as diagrams of abstract graphs and networks. 
+This product is used together with Doxygen in Open CASCADE Technology for automatic creation of Technical Documentation 
+(generation of dependency graphs). Current versions of Graphviz are licensed on an open source 
+basis only under The Eclipse Public License (EPL) (http://www.graphviz.org/License.php).
+
+**Inno Setup** is a free script-driven installation system created in CodeGear Delphi by Jordan Russell. 
+In OCCT Inno Setup is used to create Installation Wizard on Windows. 
+It is licensed under Inno Setup License (http://www.jrsoftware.org/files/is/license.txt).
+
+**FreeImage** is an Open Source library supporting popular graphics image formats, such as PNG, BMP, JPEG, TIFF 
+and others used by multimedia applications. This library is developed by Hervé Drolon and Floris van den Berg. 
+FreeImage is easy to use, fast, multithreading safe, compatible with all 32-bit or 64-bit versions of Windows, 
+and cross-platform (works both with Linux and Mac OS X). FreeImage is licensed under the 
+GNU General Public License, version 2.0 (GPLv2) and 
+the FreeImage Public License (FIPL) (http://freeimage.sourceforge.net/freeimage-license.txt).
+
+Adobe Systems, Inc. provides **Adobe Acrobat Professional**, which is a software to view, create, manipulate, 
+print and manage files in Portable Document Format (PDF). 
+This product is used in OCCT for the development and update of User's Guides.
+
+The same developer provides **Robohelp HTML** that allows developing online Help for applications that are run on the Web and on Intranets. 
+**Robohelp HTML X5.0.2** is used in OCCT for the development and update of OCCT Overview.
+
+**Linux** is a registered trademark of Linus Torvalds.
+
+**Windows** is a registered trademark of Microsoft Corporation in the United States and other countries.
+
+**Mac** and the Mac logo are trademarks of Apple Inc., registered in the U.S. and other countries.
+
+
+@section OCCT_OVW_SECTION_3 Introduction
+
+
+This document is just an introduction to Open CASCADE Technology (OCCT) dealing with 
+compatibility and installation issues and providing a general description of OCCT modules 
+and other features. All modules and development tools are described in User's Guides, available in 
+Adobe Portable Document Format (PDF). To read this format, you need Adobe Acrobat Reader, 
+which is a freeware and can be downloaded from the Adobe site. 
+All user guides can be accessed directly from this help.
+
+Alongside with PDF User Guides, OCCT suggests its users full reference documentation on all 
+implementation classes automatically generated by Doxygen software. 
+This Doxygen generated documentation is supplied  in the form of a separate package, 
+in a usual html file format.
+
+Reference documentation is presented in **Modules --> Toolkits --> Packages --> Classes** 
+logic structure with cross-references to all OCCT classes and complete in-browser search by all classes.
+
+**Recommendation for generation of reference documentation**
+
+Reference documentation can be generated by OCCT binary WOK package that 
+is available for downloading from www.opencascade.org and dev.opencascade.org sites.
+
+Prerequisites:
+
+  * Doxygen version 1.7.4 or higher
+  * Graphviz version 2.28.0 or higher
+
+Run WOK (cd \<WOK_INSTALL_DIR\>/site folder):
+
+* Using WOK TCL shell:
+      > wok_tclsh.sh
+
+* Using Emacs editor:
+      > wok_emacs.sh
+
+In the WOK prompt, step into your workbench:
+
+      >wokcd <your workbench>
+
+In your workbench, use **wgendoc** command with –h argument to get information about arguments of **wgendoc** command:
+
+      >wgendoc -h
+
+then run **wgendoc** command with required arguments
+
+e.g., wgendoc –output=d:/occt/doc {–m=Draw Visualization} -chm
+
+
+@section OCCT_OVW_SECTION_4 Installation
+
+Open CASCADE Technology can be installed with binaries precompiled by 
+Visual C++ 2008 using Installation Procedure under Windows platform only
+
+The source package and the building tools are available for self-dependent 
+preparation binary files on Unix and Windows platforms.
+
+@subsection OCCT_OVW_SECTION_4_1 Windows
+
+**Recommendation:**
+
+If you have a previous version of OCCT installed on your station, 
+and you do not plan to use it along with the new version, you might want to uninstall 
+the previous version (using Control Panel, Add/Remove Programs) before 
+the installation of this new version, to avoid possible problems 
+(conflict of system variables, paths, etc).
+
+**Attention:** For full installation OCCT requires approximately 650 Mb of disk space, 
+but during the installation process you will need 1,2 Gb of free disk space.
+
+OCCT installation with reference documentation requires 1,4 Gb on disk.
+
+  * Download the OCCT installer from OPEN CASCADE web site using the link. you have been provided
+  * Launch the installer and follow the instructions.
+
+### Third-party tools
+
+
+The includes and binaries of third-party libraries necessary for building and launching 
+OCCT are included into binary distribution (built with Visual C++ 2008). 
+To recompile OCCT libraries with other Visual C++ versions, 
+it is necessary to install headers and libraries of these third-party products.
+
+The recommended way to do this is to download each of the third-party tools from its web site 
+and build it using the relevant tools. For additional convenience of the users, 
+OPEN CASCADE also provides the documents with recommendations on building 
+third-party products from source files.
+
+When the installation is complete, you will find the following directories 
+(some might be absent in case of custom installation):
+
+![](/overview/images/overview_installation.png)
+
+### Description of directory tree
+
+
+  * **3rdparty** * This folder contains third-party products necessary to compile and use OCCT as well as start sample applications with Visual C++ 2008;
+  * **ros/adm**  * This folder contains administration files, which allow rebuilding OCCT;
+  * **ros/adm/cmake** * This folder contains files of CMake building procedure;
+  * **ros/adm/msvc** * This folder contains Visual Studio projects for Visual C++  2005, 2008 and 2010, which allow rebuilding OCCT under Windows platform in 32 and 64-bit mode;
+  * **ros/data** * This folder contains CAD files in different formats, which can be used to test the OCCT functionalities;
+  * **ros/doc** * This folder contains OCCT Overview documentation;
+  * **ros/drv** * This folder contains source files generated by WOK (private header files and instantiations of generic classes);
+  * **ros/inc** * This folder contains all OCCT header files;
+  * **ros/samples** * This folder contains sample applications.
+  * **ros/src** * This folder contains OCCT source files. They are organized in folders, one per development unit;
+  * **ros/tests** * This folder contains scripts for OCCT testing.
+  * **ros/win32/vc9** * This folder contains executable and library files built in optimize mode for Windows platform by Visual C++  2008;
+
+
+@subsection OCCT_OVW_SECTION_4_2 System Environment Variables
+
+To run any Open CASCADE Technology application you need to set the environment variables.
+
+### On Windows
+
+
+You can define the environment variables with env.bat script located in the 
+OpenCACADE<version_number>/ros folder. This script accepts two arguments to be used: 
+the version of Visual Studio (vc8, vc9, or vc10) and the architecture (win32 or win64).
+
+The additional environment settings necessary for compiling OCCT libraries and samples 
+by Microsoft Visual Studio can be set using script custom.bat located in the same folder. 
+You might need to edit this script to correct the paths to third-party libraries 
+if they are installed on your system in a non-default location.
+
+Script msvc.bat can be used with the same arguments for immediate launch of Visual Studio for (re)compiling OCCT.
+
+### On Unix
+
+
+  If OCCT was built by Code::Blocks, you can define the environment variables with env_cbp.sh or custom_cbp.sh script.
+
+  If OCCT was built by Automake, you can define the environment variables with env_amk.sh or custom_amk.sh script.
+
+The scripts are located in the OpenCACADE<version_number>/ros folder of the source package.
+
+### Description of system variables:
+
+
+  * **CASROOT** is used to define the root directory of Open CASCADE Technology;
+  * **PATH** is required to define the path to OCCT binaries and 3rdparty folder;
+  * **LD_LIBRARY_PATH** is required to define the path to OCCT libraries (on UNIX platforms only);
+  * **MMGT_OPT** if set to 1, the memory manager performs optimizations as described below; if set to 2, 
+  Intel ® TBB optimized memory manager is used; if 0 (default), every memory block is allocated 
+  in C memory heap directly (via malloc() and free() functions). 
+  In the latter case, all other options except MMGT_CLEAR  and MMGT_REENTRANT are ignored;
+  * **MMGT_CLEAR** if set to 1 (default), every allocated memory block is cleared by zeros; 
+  if set to 0, memory block is returned as it is;
+  * **MMGT_CELLSIZE** defines the maximal size of blocks allocated in large pools of memory. Default is 200;
+  * **MMGT_NBPAGES** defines the size of memory chunks allocated for small blocks in pages 
+  (operating-system dependent). Default is 10000;
+  * **MMGT_THRESHOLD** defines the maximal size of blocks that are recycled internally 
+  instead of being returned to the heap. Default is 40000;
+  * **MMGT_MMAP** when set to 1 (default), large memory blocks are allocated using 
+  memory mapping functions of the operating system; if set to 0, 
+  they will be allocated in the C heap by malloc();
+  * **MMGT_REENTRANT** when set to 1 (default), all calls to the 
+  optimized memory manager will be secured against possible simultaneous access from different execution threads. 
+
+This variable should be set in any multithreaded application that uses 
+an optimized memory manager (MMGT_OPT=1) and has more than one thread 
+potentially calling OCCT functions. If set to 0, OCCT memory management and 
+exception handling routines will skip the code protecting from possible concurrency 
+in multi-threaded environment. This can yield some performance gain in some applications, 
+but can lead to unpredictable results if used in a multithreaded application;
+
+**Special note:** for applications that use OCCT memory manager from more than one thread, 
+on multiprocessor hardware, it is recommended to use options MMGT_OPT=2 and MMGT_REENTRANT=1.
+
+  * **CSF_LANGUAGE** is required to define the default language of messages;
+  * **CSF_EXCEPTION_PROMPT** – if defined and set to 1 then a diagnostic message is displayed in case of an exception;
+  * **CSF_MDTVFontDirectory** accesses the fonts that can be used in OCCT;
+  * **CSF_MDTVTexturesDirectory** defines the directory for available textures when using texture mapping;
+  * **CSF_UnitsDefinition** and **CSF_UnitsLexicon** are required by programs considering units;
+  * **CSF_SHMessage** is required in order to define the path to the messages file for *ShapeHealing*;
+  * **CSF_XSMessage** is required in order to define the path to the messages file for **STEP** and **IGES** translators;
+  * **CSF_StandardDefaults** and **CSF_PluginDefaults** are required in order to maintain CASCADE Persistence mechanism to make possible   any open/save operations with OCAF documents;
+  * **CSF_StandardLiteDefaults** is required in order to maintain *OCCT Persistence mechanism* to make possible any open/save operations with Lite OCAF documents;
+  * **CSF_XCAFDefaults**  any open/save operations for **XDE** documents;
+  * **CSF_GraphicShr** is required to define the path to the *TKOpenGl* library;
+  * **CSF_IGESDefaults** and **CSF_STEPDefaults** are required for **IGES** and **STEP** translators correspondingly in order to define the path to the resource files;
+  * **CSF_XmlOcafResource** is required in order to set the path to **XSD** resources, which defines XML grammar.
+
+As part of XML persistence support, these definitions can be used by end users 
+in XML validators or editors, together with persistent XmlOcaf documents;
+
+* **CSF_MIGRATION_TYPES** is required in order to read documents that contain old data types, such as *TDataStd_Shape*;
+* **TCLLIBPATH**, **TCL_LIBRARY**, **TK_LIBRARY** and **TIX_LIBRARY** are required to allow work with **DRAW** and **WOK**.
+
+
+@section OCCT_OVW_SECTION_5 Requirements
+
+@subsection OCCT_OVW_SECTION_5_1 Linux Intel
+
+| Operating System                               | 32/64-bit:  Debian: 4.0, Mandriva: 2010*                                                           |
+| :--------------------------------------------- | :------------------------------------------------------------------------------------------------- |
+| Minimum memory                                 | 512 Mb, 1 Gb recommended                                                                           |
+| Free disk space (complete installation)        | For full installation Open CASCADE Technology requires 600 Mb of disk space.                       |
+| Minimum swap space                             | 500 Mb                                                                                             |
+| Video card                                     | GeForce,                                                                                           |
+|                                                | The following versions of GeForce drivers are recommended:                                         |
+|                                                | 64-bit Version: 100.14.19 or later http://www.nvidia.com/object/linux_display_amd64_100.14.19.html |
+|                                                | 32-bit Version: 100.14.19 or later http://www.nvidia.com/object/linux_display_ia32_100.14.19.html  |
+| Graphic library                                | OpenGL 1.1+ (OpenGL 1.5+ is recommended)                                                           |
+| C++                                            | GNU gcc 4.0.   * 4.3.2.                                                                            |
+| TCL (for testing tools)                        | Tcltk 8.5 or 8.6                                                                                   |
+|                                                | http://www.tcl.tk/software/tcltk/8.6.html                                                          |
+| Qt (for demonstration tools)                   | Qt 4.6.2 http://qt.digia.com/downloads                                                             |
+| Freetype (OCCT Text rendering)                 | freetype-2.4.10                                                                                    |
+|                                                | http://sourceforge.net/projects/freetype/files/                                                    |
+| FreeImage (Support of common graphic formats ) | FreeImage 3.14.1                                                                                   |
+|                                                | http://sourceforge.net/projects/freeimage/files/Source%20Distribution/                             |
+| gl2ps (Export contents of OCCT                 | gl2ps-1.3.5                                                                                        |
+|  viewer to vector graphic file)                | http://geuz.org/gl2ps/                                                                             |
+| TBB (optional tool for parallelized            | TBB 3.x or 4.x                                                                                     |
+| version of BRepMesh component)                 | http://www.threadingbuildingblocks.org/                                                            |
+
+@subsection OCCT_OVW_SECTION_5_2 Windows Intel
+
+| Operating System                               | 32/64-bit: 8/ 7 SP1 / VISTA SP2 /XP SP3                                                          |
+| :--------------------------------------------- | :----------------------------------------------------------------------------------------------- |
+| Minimum memory                                 | 512 Mb, 1 Gb recommended                                                                         |
+| Free disk space                                | For full installation Open CASCADE Technology requires 650 Mb of disk space.                     |
+| (complete installation)                        | but during the process of installation you will need 1,2 Gb of free disk space.                  |
+| Minimum swap space                             | 500 Mb                                                                                           |
+| Video card                                     | GeForce,                                                                                         |
+|                                                | Version 266.58 WHQL or later is recommended:http://www.nvidia.com/Download/index.aspx            |
+| Graphic library                                | OpenGL 1.1+ (OpenGL 1.5+ is recommended)                                                         |
+| C++                                            | Microsoft Visual Studio .NET 2005 SP1 with all security updates                                  |
+|                                                | Microsoft Visual Studio .NET 2008 SP1*                                                           |
+|                                                | Microsoft Visual Studio .NET 2010                                                                |
+|                                                | Microsoft Visual Studio .NET 2012                                                                |
+| TCL (for testing tools)                        | ActiveTcl 8.5 or 8.6                                                                             |
+|                                                | http://www.activestate.com/activetcl/downloads                                                   |
+| Qt (for demonstration tools)                   | Qt 4.6.2 http://qt.digia.com/downloads                                                           |
+| Freetype (OCCT Text rendering)                 | freetype-2.4.10                                                                                  |
+|                                                | http://sourceforge.net/projects/freetype/files/                                                  |
+| FreeImage (Support of common graphic formats ) | FreeImage 3.14.1                                                                                 |
+|                                                | http://sourceforge.net/projects/freeimage/files/Source%20Distribution/                           |
+| gl2ps (Export contents of OCCT                 | gl2ps-1.3.5                                                                                      |
+|  viewer to vector graphic file)                | http://geuz.org/gl2ps/                                                                           |
+| TBB (optional tool for parallelized            | TBB 3.x or 4.x                                                                                   |
+| version of BRepMesh component)                 | http://www.threadingbuildingblocks.org/                                                          |
+
+@subsection OCCT_OVW_SECTION_5_3 MAC OS X
+
+| Operating System                               | Requires Mac OS X 10.6.8 Snow Leopard / 10.7 Lion                                                |
+| :--------------------------------------------- | :----------------------------------------------------------------------------------------------- |
+| Minimum memory                                 | 512 Mb, 1 Gb recommended                                                                         |
+| Free disk space (complete installation)        | For full installation Open CASCADE Technology requires 600 Mb of disk space.                     |
+| Minimum swap space                             | 500 Mb                                                                                           |
+| Graphic library                                | OpenGL 1.1+ (OpenGL 1.5+ is recommended)                                                         |
+| C++                                            | XCode 3.2 or newer (4.x is recommended)                                                          |
+| TCL (for testing tools)                        | Tcltk 8.5 or 8.6                                                                                 |
+|                                                | http://www.tcl.tk/software/tcltk/8.6.html                                                        |
+| Qt (for demonstration tools)                   | Qt 4.6.2 http://qt.digia.com/downloads                                                           |
+| Freetype (OCCT Text rendering)                 | freetype-2.4.10                                                                                  |
+|                                                | http://sourceforge.net/projects/freetype/files/                                                  |
+| FreeImage (Support of common graphic formats ) | FreeImage 3.14.1                                                                                 |
+|                                                | http://sourceforge.net/projects/freeimage/files/Source%20Distribution/                           |
+| gl2ps (Export contents of OCCT                 | gl2ps-1.3.5                                                                                      |
+|  viewer to vector graphic file)                | http://geuz.org/gl2ps/                                                                           |
+| TBB (optional tool for parallelized            | TBB 3.x or 4.x                                                                                   |
+| version of BRepMesh component)                 | http://www.threadingbuildingblocks.org/                                                          |
+
+
+@section OCCT_OVW_SECTION_6 Release Notes
+
+
+Open CASCADE Technology latest version 
+@htmlonly 
+<a href="http://occtrel.nnov.opencascade.com/OpenCASCADE6.6.0/doc/release_notes.pdf">Release Notes</a>
+@endhtmlonly  (PDF)
+
+
+@section OCCT_OVW_SECTION_7 Getting Started
+
+
+@subsection OCCT_OVW_SECTION_7_1 Draw Test Harness
+
+Draw is a command interpreter based on TCL and a graphical system used for testing and demonstrating OCCT modeling libraries.
+
+Draw can be used interactively to create, display and modify objects such as curves, surfaces and topological shapes.
+
+![](/overview/images/overview_draw.png "")
+
+Scripts can be written to customize Draw and perform tests. 
+New types of objects and new commands can be added using C++ programming language.
+
+Draw contains:
+
+  * A command interpreter based on TCL command language.
+  * A 2D an 3D graphic viewer with support of operations such as zoom, pan, rotation and full-screen views.
+  * An optional set of geometric commands to create and modify curves and surfaces and to use OCCT geometry algorithms.
+  * A set of topological commands to create and modify BRep shapes and to use OCCT topology algorithms.
+  * A set of graphic commands for view and display operations including Mesh Visualization Service.
+  * A set of Application framework commands for handling of files and attributes.
+  * A set of Data Exchange commands for translation of files from various formats (IGES,STEP) into OCCT shapes.
+  * A set of Shape Healing commands: check of overlapping edges, approximation of a shape to BSpline, etc.  
+
+You can add new custom test harness commands to Draw in order to test 
+or demonstrate a new functionality, which you are developing.
+
+Currently DRAW Test Harness is a single executable called DRAWEXE.
+
+Commands grouped in toolkits can be loaded at run-time thereby implementing dynamically loaded plug-ins. 
+Thus you can work only with the commands that suit your needs adding 
+the commands dynamically without leaving the Test Harness session.
+
+Declaration of available plug-ins is done through special resource file(s). 
+The pload command loads the plug-in in accordance with 
+the specified resource file and activates the commands implemented in the plug-in.
+
+The whole process of using the plug-in mechanism as well as the instructions for extending Test Harness is described in the 
+@htmlonly 
+<a href="http://occtrel.nnov.opencascade.com/OpenCASCADE6.6.0/doc/OCCT_Tests.pdf">User's Guide/</a>
+@endhtmlonly
+
+Draw Test Harness provides an environment for OCCT automated testing system. Please, consult its 
+@htmlonly 
+<a href="http://occtrel.nnov.opencascade.com/OpenCASCADE6.6.0/doc/OCCT_Tests.pdf">User's Guide /</a>
+@endhtmlonly
+for details.
+
+Remarks:
+
+* The DRAWEXE executable is delivered with the installation procedure on Windows platform only.
+* To start it, launch DRAWEXE executable from Open CASCADE Technology//Draw Test Harness item of the Start\\Programs menu.
+
+@subsection OCCT_OVW_SECTION_7_2 Experimenting with Draw Test Harness
+
+ Running Draw
+------------
+
+**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;
+
+Draw[1]> prompt appears in the command window
+
+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.
+
+Draw[1]> prompt appears in the command window
+
+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
+
+**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
+
+**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:
+  * 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
+
+@subsection OCCT_OVW_SECTION_7_3 Programming Samples
+
+@subsubsection OCCT_OVW_SECTION_7_3_1 MFC 
+
+Visual C++ programming samples containing 10 Visual C++ projects 
+illustrating how to use a particular module or functionality.
+
+The list of MFC samples:
+
+  * Geometry
+  * Modeling
+  * Viewer2d
+  * Viewer3d
+  * ImportExport
+  * Ocaf
+  * Triangulation
+  * HLR
+  * Animation
+  * Convert
+
+![](/overview/images/overview_mvc.png "")
+
+**Remarks:**
+
+  * MFC samples are available only on Windows platform;
+  * To start a sample use Open CASCADE Technology\\Samples\\Mfc\\ item of the Start\\Programs menu;
+  * Read carefully readme.txt to learn about launching and compilation options.
+
+@subsubsection OCCT_OVW_SECTION_7_3_2 Qt
+
+OCCT contains three samples based on Qt application framework
+
+ Import Export
+-------------
+
+ Import Export programming sample contains 3D Viewer and Import // Export functionality.
+
+![](/overview/images/overview_qt.png "")
+
+ Tutorial
+---------
+
+The Qt programming tutorial teaches how to use Open CASCADE Technology services to model a 3D object. 
+The purpose of the tutorial is not to explain all OCCT classes but 
+to help start thinking in terms of the Open CASCADE Technology.
+
+This tutorial assumes that  the user has experience in using and setting up C++. 
+From the viewpoint of programming, Open CASCADE Technology is designed 
+to enhance user's C++ tools with high performance modeling classes, methods and functions. 
+The combination of these resources allows creating substantial applications.
+
+**See also:** @subpage overview__tutorial "3D Object Tutorial" 
+
+ Voxel
+------
+
+This is a demonstration application showing OCCT voxel models. 
+It also includes a set of non-regression tests and other commands 
+for testing this functionality (accessible only through TEST pre-processor definition).
+
+**See also:** 
+ @htmlonly 
+<a href="http://occtrel.nnov.opencascade.com/OpenCASCADE6.6.0/doc/voxels_wp.pdf">Voxels User's guide (PDF)</a>
+@endhtmlonly
+
+**Remarks:**
+
+  * Qt samples are available on all supported platforms;
+  * To start a sample on Windows use Open CASCADE Technology\\Samples\\Qt\\ item of the Start\\Programs menu.
+
+@subsubsection OCCT_OVW_SECTION_7_3_3 C#
+
+C# sample containing 3D Viewer and Import // Export functionality.
+
+![](/overview/images/overview_c__ie.png "")
+
+Import:
+
+  * BRep
+  * Iges
+  * Step
+
+Export: 
+
+  * Brep
+  * Iges
+  * Step
+  * Stl
+  * Vrml
+
+**Remarks:**
+
+  * C# sample is available only on Windows platform;
+  * It is delivered in source code only and must be built with Microsoft Visual C++ 2005.
diff --git a/dox/dev_guides/building/automake.md b/dox/dev_guides/building/automake.md
new file mode 100644 (file)
index 0000000..e03ceb7
--- /dev/null
@@ -0,0 +1,69 @@
+Building with Automake {#dev_guides__building__automake}
+======================
+
+This file describes steps to build OCCT libraries from complete source
+archive on Linux with GNU build system (Autotools).
+
+If you are building OCCT from bare sources (as in Git repository), or do some 
+changes affecting CDL files, you need to use WOK to re-generate header files
+and build scripts / projects. See file \ref wok "WOK" for instructions.
+
+Before building OCCT, you need to install required third-party libraries; see
+OCCT_Build3rdParty_Linux.pdf for instructions.
+
+Note that during compilation by makefiles on some Linux OS on a station with 
+NVIDIA video card you may experience problems because the installation 
+procedure of NVIDIA video driver removes library libGL.so included in package 
+libMesaGL from directory /usr/X11R6/lib and places this library libGL.so in 
+directory /usr/lib. However, libtool expects to find the library in directory 
+/usr/X11R6/lib, which causes compilation crash (See /usr/X11R6/lib/libGLU.la). 
+
+To prevent this, suggest making links: 
+
+ ln -s /usr/lib/libGL.so /usr/X11R6/lib/libGL.so 
+ ln -s /usr/lib/libGL.la /usr/X11R6/lib/libGL.la 
+
+  1.In OCCT root folder, launch build_configure script 
+
+   This will generate files configure and Makefile.in for your system.
+
+  2.Go to the directory where OCCT will be built, and run configure to generate
+   makefiles.
+
+   $CASROOT/configure \<FLAGS\>
+
+   Where \<FLAGS\> is a set of options.
+   The following flags are mandatory:
+
+   * --with-tcl=  defines location of tclConfig.sh
+   * --with-tk=  defines location of tkConfig.sh
+   * --with-freetype=  defines location of installed FreeType product
+   * --prefix= defines location for the installation of OCCT binaries
+
+   Additional flags:
+
+   * --with-gl2ps=  defines location of installed gl2ps product
+   * --with-freeimage=  defines location of installed FreeImage product
+   * --with-tbb-include= defines location of tbb.h
+   * --with-tbb-library=  defines location of libtbb.so
+   * --enable-debug=       yes: includes debug information, no: does not include debug information
+   * --enable-production=   yes: switches code optimization, no: switches off code optimization
+   * --disable-draw - allows OCCT building without Draw.
+
+   If location of FreeImage, TBB, and Gl2Ps is not specified, OCCT will be
+   built without these optional libraries.
+
+   
+   Attention: 64-bit platforms are detected automatically.
+
+   Example:
+
+   > ./configure -prefix=/PRODUCTS/occt-6.5.5 --with-tcl=/PRODUCTS/tcltk-8.5.8/lib --with-tk=/PRODUCTS/tcltk-8.5.8/lib --with-freetype=/PRODUCTS/freetype-2.4.10 --with-gl2ps=/PRODUCTS/gl2ps-1.3.5 --with-freeimage=/PRODUCTS/freeimage-3.14.1 --with-tbb-include=/PRODUCTS/tbb30_018oss/include --with-tbb-library=/PRODUCTS/tbb30_018oss/lib/ia32/cc4.1.0_libc2.4_kernel2.6.16.21
+
+  3.If configure exits successfully, you can build OCCT with make command.
+
+   > make -j8 install
+
+To start DRAW, launch
+
+   > draw.sh
diff --git a/dox/dev_guides/building/cmake.md b/dox/dev_guides/building/cmake.md
new file mode 100644 (file)
index 0000000..4f648e6
--- /dev/null
@@ -0,0 +1,77 @@
+Building with CMake {#dev_guides__building__cmake}
+===================
+
+This file describes steps to build OCCT libraries from complete source package
+with CMake. CMake is free software that can create GNU Makefiles, KDevelop, 
+XCode, and Visual Studio project files. Version 2.6 or above of CMake is 
+required.
+
+If you are building OCCT from bare sources (as in Git repository), or do some 
+changes affecting CDL files, you need to use WOK to re-generate header files
+and build scripts / projects. See file \ref wok "WOK" for instructions.
+
+Before building OCCT, you need to install required third-party libraries; see
+instructions for your platform on Resources page at http://dev.opencascade.org
+
+1.  Decide on location of build and install directories.
+    
+    The build directory is the one where intermediate files will be created 
+    (projects / makefiles, objects, binaries).
+    The install directory is the one where binaries will be installed after 
+    build, along with header files and resources required for OCCT use in 
+    applications.
+    
+    OCCT CMake scripts assume use of separate build and one install directories
+    for each configuration (Debug or Release).
+    
+    It is recommended to separate build and install directories from OCCT 
+    source directory, for example:
+    
+       /user/home/occt/ros - sources
+       /user/home/tmp/occt-build-release - intermediate files (release)
+       /user/home/occt-install-release - installed binaries (release)
+    
+2.  Run CMake indicating path to OCCT sources (ros subdirectory) and selected build directory. 
+    It is recommended to use GUI tools provided by CMake: cmake-gui on Windows
+    and Mac, ccmake on Linux.
+    
+    Example:
+    
+       Linux> cd /user/home/occt-install-release
+       Linux> ccmake /user/home/occt/ros
+    
+3. Run Configure
+    
+    You will likely get CMake errors due to missing paths to 3rd-party 
+    libraries. This is normal; proceed with configuration as follows.
+    
+4. Check parameters shown by CMake, set them in accordance with your 
+    environment, and repeat Configure until it runs without error:
+    
+    - 3RDPARTY_DIR: path to directory whethe 3rd-party libraries are installed
+      (for the cases when they are not in default locations, or on Windows)
+    - 3RDPARTY_USE_\<library\>: select to use optional libraries
+    - Other options in 3RDPARTY group can be used to fine-tune paths to 
+      3rd-party libraries
+    
+    - BUILD_TYPE: configuration to build (Debug or Release)
+    - BUILD_BITNESS: bitness (32 or 64)
+    - BUILD_TOOLKITS: optional string containing list of toolkits to be built
+      in addition to those included in completely built modueles
+    - BUILD_\<module\>: select to build corresponding OCCT module
+    
+    - INSTALL_DIR: directory to install OCCT
+    - INSTALL_\<library\>: select to copy corresponding 3rd-party library to OCCT
+      install dir
+
+5. Run Generate
+
+    This will create makefiles or project files for your build system.
+
+6. Build OCCT:
+
+    - on Windows with MSVC: open solution OCCT.sln and build it, when build project INSTALL_ALL explicitly to have binaries and headers installed
+    - on Linux with make files: run 'make install'
+
\ No newline at end of file
diff --git a/dox/dev_guides/building/code_blocks.md b/dox/dev_guides/building/code_blocks.md
new file mode 100644 (file)
index 0000000..919edc2
--- /dev/null
@@ -0,0 +1,64 @@
+Building with Code::Blocks on Mac OS X {#dev_guides__building__code_blocks}
+======================================
+
+This file describes steps to build OCCT libraries from complete source package
+on Mac OS X with Code::Blocks.
+
+If you are building OCCT from bare sources (as in Git repository), or do some 
+changes affecting CDL files, you need to use WOK to re-generate header files
+and build scripts / projects. See file \ref wok "WOK" for instructions.
+
+Before building OCCT, you need to install required third-party libraries; see
+OCCT_Build3rdParty_OSX.pdf for details.
+
+1. Add paths to the mandatory 3rd-party products (Tcl/Tk and FreeType) in file 
+   custom.sh located in \<OCCT_ROOT_DIR\>. For this:
+
+   1.1. Add paths to the includes in variable "CSF_OPT_INC";
+
+   1.2. Add paths to the binary libraries in variable  "CSF_OPT_LIB64";
+   
+   All paths should be separated by ":" symbol. 
+
+2. Add paths to the optional 3rd-party libraries (TBB, gl2ps and FreeImage) 
+   in the aforementioned environment variables "CSF_OPT_INC" and 
+   "CSF_OPT_LIB64" from file custom.sh.
+
+   If you want to build OCCT without the optional libraries perform the 
+   following steps:
+
+   2.1 Disable unnecessary library in custom.sh by setting the corresponding 
+       variable HAVE_\<LIBRARY_NAME\> to "false". 
+
+       export HAVE_GL2PS=false
+
+   2.2 Remove this library from Linker settings in Code::Blocks for each project 
+       that uses it: right click on the required project, choose "Build options", 
+       go to "Linker settings" tab in the opened window , select unnecessary 
+       libraries and click "Delete" button.
+
+3. Open Terminal application
+
+4. Enter \<OCCT_ROOT_DIR\>:
+
+   cd \<OCCT_ROOT_DIR\>
+
+5. To start Code::Blocks, run the command /codeblocks.sh
+
+6. To build all toolkits, click "Build->Build workspace" in the menu bar.
+
+
+To start DRAWEXE, which has been built with Code::Blocks on Mac OS X, perform 
+the following steps:
+
+1. Open Terminal application
+
+2. Enter \<OCCT_ROOT_DIR\>:
+
+   cd \<OCCT_ROOT_DIR\>
+
+3. Run script
+
+   ./draw_cbp.sh cbp [d]
+
+   Option "d" is used if OCCT has been built in Debug mode.
diff --git a/dox/dev_guides/building/msvc.md b/dox/dev_guides/building/msvc.md
new file mode 100644 (file)
index 0000000..3a84422
--- /dev/null
@@ -0,0 +1,31 @@
+Building with MS Visual C++ {#dev_guides__building__msvc}
+===========================
+
+This file describes steps to build OCCT libraries from complete source
+archive on Windows with MS Visual C++. 
+
+If you are building OCCT from bare sources (as in Git repository), or do some 
+changes affecting CDL files, you need to use WOK to re-generate header files
+and build scripts / projects. See file \ref wok "WOK" for instructions.
+
+Before building OCCT, you need to install required third-party libraries; see
+OCCT_Build3rdParty_Windows.pdf for instructions.
+
+1. Edit file custom.bat to define environment: 
+
+   - VCVER - version of Visual Studio (vc8, vc9, vc10 or vc11), 
+             and relevant VCVARS path
+   - ARCH - architecture (32 or 64), affects only PATH variable for execution
+   - HAVE_* - flags to enable or disable use of optional third-party products
+   - CSF_OPT_* - paths to search for includes and binaries of all used 
+                 third-party products
+
+2. Launch msvc.bat to start Visual Studio with all necessary environment 
+   variables defined.
+
+   Note: the MSVC project files are located in folders adm\\msvc\\vc[9-11].
+   Binaries are produced in win32 or win64 folders.
+
+3. Build with Visual Studio
+
+To start DRAW, launch draw.bat.
diff --git a/dox/dev_guides/building/xcode.md b/dox/dev_guides/building/xcode.md
new file mode 100644 (file)
index 0000000..e1ba093
--- /dev/null
@@ -0,0 +1,71 @@
+Building with Xcode {#dev_guides__building__xcode}
+===================
+
+This file describes steps to build OCCT libraries from complete source package
+on Mac OS X with Xcode.
+
+If you are building OCCT from bare sources (as in Git repository), or do some 
+changes affecting CDL files, you need to use WOK to re-generate header files
+and build scripts / projects. See file \ref wok "WOK" for instructions.
+
+Before building OCCT, you need to install required third-party libraries; see
+OCCT_Build3rdParty_OSX.pdf for details.
+
+1. Add paths to the mandatory 3rd-party products (Tcl/Tk and FreeType) 
+   in file custom.sh located in \<OCCT_ROOT_DIR\>. For this:
+
+   1.1. Add paths to the includes in variable "CSF_OPT_INC";
+
+   1.2. Add paths to the binary libraries in variable  "CSF_OPT_LIB64";
+
+   All paths should be separated by ":" symbol. 
+
+2. Add paths to the optional 3rd-party libraries (TBB, gl2ps and FreeImage) 
+   in the aforementioned environment variables "CSF_OPT_INC" and 
+   "CSF_OPT_LIB64" from file custom.sh.
+
+   If you want to build OCCT without the optional libraries perform the 
+   following steps:
+
+   2.1 Disable unnecessary library in custom.sh by setting the corresponding 
+       variable HAVE_<LIBRARY_NAME> to "false". 
+
+       export HAVE_GL2PS=false
+
+   2.2 Remove this library from Project navigator in Xcode for each project that 
+       uses it: choose the required project, right click on the unnecessary 
+       library and select "Delete" button.
+
+3. Open Terminal application.
+
+4. Enter \<OCCT_ROOT_DIR\>:
+
+   cd \<OCCT_ROOT_DIR\>
+
+5. To start Xcode, run the command  /xcode.sh
+
+6. To build a certain toolkit, select it in "Scheme" drop-down list in Xcode 
+   toolbar, press "Product" in the menu and click "Build" button. 
+
+   To build the entire OCCT, create a new empty project (select "File -> 
+   New -> Project -> "Empty project" in the menu. Input the project name, 
+   e.g. "OCCT", click "Next" and "Create" buttons). Drag and drop the "OCCT" 
+   folder in the created "OCCT" project in the Project navigator. Select 
+   "File -> New -> Target -> Aggregate" in the menu. Enter the project name 
+   (e.g. "OCCT") and click "Finish". The "Build Phases" tab will open.  
+   Click "+" button to add the necessary toolkits to the target project. 
+   It is possible to select all toolkits by pressing "Command+A" combination. 
+
+To start DRAWEXE, which has been built with Xcode on Mac OS X, perform the following steps:
+
+1. Open Terminal application
+
+2. Enter \<OCCT_ROOT_DIR\>:
+
+   cd \<OCCT_ROOT_DIR\>
+
+3. Run script
+
+   ./draw_cbp.sh xcd [d]
+
+   Option "d" is used if OCCT has been built in Debug mode.
diff --git a/dox/dev_guides/cdl/cdl.md b/dox/dev_guides/cdl/cdl.md
new file mode 100644 (file)
index 0000000..bde4975
--- /dev/null
@@ -0,0 +1,1876 @@
+ Component Definition Language (CDL)  {#dev_guides__cdl}
+==============================
+
+@section occt_1819379591_354121062 CDL and Application Architecture
+
+CDL is the component  definition language of the Open CASCADE Technology (**OCCT**) programming  platform. Some components, which CDL allows you to create, are specific to OCCT  application architecture. These and other components, which you can define  using CDL include the following: 
+
+  * Class (including enumeration,  exception)
+  * Package
+  * Schema
+  * Executable
+  * Client.
+A** class** is the  fundamental software component in object-oriented development. Because of a  very large number of resources used in large-scale applications, the **class **itself  is too small to be used as a basic management unit. 
+
+So, while the class is  the basic data component defined in CDL, this language also provides a way to  group classes, **enumerations**, and **exceptions **together – the **package**.  A package groups together a number of classes, which have semantic links. For  example, a geometry package would contain Point, Line, and Circle classes. A  package can also contain enumerations, exceptions, and package methods. In  practice, a class name is prefixed with the name of its package e.g.  Geom_Circle. 
+
+Using the services  described in the **packages**, you can construct an **executable**. You  can also group together services provided by **packages**.  
+
+To save data in a file,  you need to define persistent classes. Then, you group these classes in a  schema, which provides the necessary read/write tools. 
+
+    <table>
+       <tr>
+               <td>
+               
+               </td>
+       </tr>
+       <tr>
+               <td>
+               
+               </td>
+               <td>
+               ![](/devs_guide/cdl/images/cdl_image003.jpg)
+               </td>
+       </tr>
+</table>       
+Figure 1. Building  an Open CASCADE Technology application 
+@section occt_1819379591_986437237 2. Introduction to  CDL
+@subsection occt_1819379591_98643723721  Purposes of the Language
+You can use CDL to **define  data **in the Open CASCADE Technology environment. CDL allows you to define  various kinds of data types supporting the application architecture and  development methodology, which you envision. CDL is neither an analysis  formalism (e.g. Booch methodology) nor a data manipulation language (e.g. C++). 
+
+You use CDL in the **design  phase **of a development process to define a set of software components which  best model the concepts stated in the application specification. 
+
+    <table>
+       <tr>
+               <td>
+               
+               </td>
+       </tr>
+       <tr>
+               <td>
+               
+               </td>
+               <td>
+               ![](/devs_guide/cdl/images/cdl_image004.jpg)
+               </td>
+       </tr>
+</table>       
+
+Figure 2. The Development Process 
+
+From a structural point  of view, CDL is an object-oriented language. It is centered on the notion of  the **class **- a data type, which represents an elementary concept. CDL  offers various means of organizing classes, mostly under the fundamental form  of **packages**. A package contains a set of classes, which share some  semantic relationship. This greatly simplifies your task of managing individual  classes when confronted with a very large number of them. 
+
+Once you have defined  the classes and packages using CDL, you can implement their **methods **-  i.e., their functionality - in one of the data manipulation languages supported  by the OCCT environment (currently C++). 
+
+Even though you can describe classes directly in C++  and save them as header files (.hxx), to do so would forfeit all the advantages  of using CDL. These are: 
+
+  * Precise, complete, and  easy-to-read description of the software components.
+  * Creation of a link with the  database; object persistence forms part of the predefined environment of the  language.
+  * Multi-language access to the  services of an application engine – a specific architectural form created using  the CDL tools, which serves as the motor of an application.
+@subsection occt_1819379591_98643723722   Overview of CDL
+
+CDL is an object-oriented  language. In other words, it structures a system around data types rather than  around the actions carried out on them. In this context, an **object **is an  **instance **of a data type, and its definition determines how you can use  it. Each data type is implemented by one or more classes, which make up the  basic elements of the system. 
+@subsubsection occt_1819379591_986437237221    Classes
+
+A class is an  implementation of a **data type**. It defines its **behavior **and its **representation**. 
+
+The behavior of a class  is its programming interface - the services offered by its **methods**. The  representation of a class is its data structure - the **fields**,** **which  store its data. 
+
+Every object is an **instance  **of its class. For example, the object *p *of the data type *Point *is  an instance of the class Point. 
+
+The class Point could be  defined as in the example below: 
+
+@code
+class Point from  GeomPack
+@endcode
+@code
+    ---Purpose: represents a point in 3D space.
+@endcode
+@code
+   is
+@endcode
+@code
+    Create returns Point;
+@endcode
+@code
+fields
+@endcode
+@code
+    x, y, z : Real;
+@endcode
+@code
+end Point; 
+@endcode
+
+The definition of this class comprises two sections: 
+
+  * one starting with the  keywords **is**
+  * one starting with the keyword  **fields**.
+
+The first section  contains a list of methods available to the clients of the class. The second  section defines the way in which instances are represented. Once this class has  been compiled you could **instantiate **its data type in a C++ test program  as in the example below: 
+
+
+
+@code
+GeomPack_Point p;
+@endcode
+@subsubsection occt_1819379591_986437237222     Categories of Types
+
+You declare the  variables of a **data manipulation language **as being of certain data  types. These fall into two categories: 
+
+  * Data types manipulated by  handle (or reference)
+  * Data types manipulated by  value
+    <table>
+       <tr>
+               <td>
+               
+               </td>
+       </tr>
+       <tr>
+               <td>
+               
+               </td>
+               <td>
+               ![](/devs_guide/cdl/images/cdl_image005.jpg)
+               </td>
+       </tr>
+</table>       
+
+Figure 3. Manipulation of data types 
+
+
+As seen above, you  implement data types using classes. However, classes not only define their data  representation and methods available for their instances, but they also define  how the instances will be manipulated: 
+  * A data type manipulated by  value contains the instance itself.
+  * A data type manipulated by  handle contains a reference to the instance.
+
+The most obvious  examples of data types manipulated by value are the predefined **primitive  types**: Boolean, Character, Integer, Real ... 
+
+A variable of a data  type manipulated by handle, which is not attached to an object, is said to be **null**.  To reference an object, you need to instantiate the class with one of its  constructors. This is done in C++ as in the following syntax: 
+
+
+
+@subsubsection occt_1819379591_986437237223     Persistence
+
+An object is called **persistent  **if it can be permanently stored. In other words, you can use the object  again at a later date, both in the application, which created it, and in  another application. 
+
+In order to make an  object persistent, you need to declare it in CDL as inheriting from the **Persistent**  class, or to have one of its parent classes inheriting from the **Persistent **class. 
+
+Note that the classes  inheriting from the Persistent class are handled by reference. 
+
+**Example** 
+
+In this example,  building the application, you add the Watch class to the corresponding schema  of data types. 
+If, running the  application, you instantiate an object of the Watch class, you have the  possibility of storing it in a file. 
+You cannot store objects  instantiated from classes, which inherit from the **Storable** class.  However, you can store them as fields of an object, which inherits from  Persistent. 
+
+Note that the objects  inheriting from Storable are handled by value. 
+**Example** 
+
+If 
+class WatchSpring  inherits Storable 
+//then this could be  stored as a field of a Watch 
+//object: 
+class Watch inherits  Persistent 
+is...... 
+fields 
+name :  ConstructorName; 
+powersource :  WatchSpring; 
+end; 
+
+
+@subsubsection occt_1819379591_986437237224    Packages
+
+In large-scale long-term  development the task of marshalling potentially thousands of classes is likely  to quickly prove unmanageable. CDL introduces the notion of **package **of  classes containing a set of classes, which have some semantic or syntactic  relationship. For example, all classes representing a particular set of  electronic components might make up a package called Diode. 
+
+As the package name  prefixes the class name when implementing such class (in C++ for example),  classes belonging to different packages can have the same name. For example,  two packages, one dealing with finance and the other dealing with aircraft  maneuvers, might both contain a class called Bank, without any possibility of  confusion. 
+**Example** 
+
+Finance_Bank 
+Attitude_Bank 
+
+
+
+@subsubsection occt_1819379591_986437237225     Inheritance
+
+The purpose of  inheritance is to reduce development workload. The inheritance mechanisms allow  you to declare a new class as already containing the characteristics of an  existing class. This new class can then be rapidly specialized for a task at  hand. This eliminates the necessity of developing each component “from  scratch”. 
+
+For example, having  already developed a class BankAccount, you can quickly specialize new classes -  SavingsAccount, LongTermDepositAccount, MoneyMarketAccount,  RevolvingCreditAccount, etc.. 
+
+As a consequence, when  two or more classes inherit from a parent (or ancestor) class, all these  classes surely inherit the behavior of their parent (or ancestor). For example,  if the parent class BankAccount contains the method Print that tells it to  print itself out, then all its descendent classes offer the same service. 
+
+One way of ensuring the  use of inheritance is to declare classes at the top of a hierarchy as being **deferred**.  In such classes, the inherited methods are not implemented. This forces you to  create a new class used to redefine the methods. In this way, you guarantee a  certain minimum common behavior among descendent classes. 
+**Example** 
+
+deferred class BankAccount inherits Persistent 
+is 
+....... 
+fields 
+name :  AccountHolderName; 
+balance : CreditBalance; 
+end; 
+
+
+@subsubsection occt_1819379591_986437237226     Genericity
+
+You will often wish to  model a certain type of behavior as a class. For example, you will need a list  modeled as a class. 
+
+In order to be able to  list different objects, the class **List **must be able to accept different  data types as parameters. This is where genericity comes in: you first declare  a list declared as the generic class **List**, willing to accept any data  type (or only a particular set of acceptable data types). Then, when you want  to make a list of a certain type of object, you instantiate the class **List **with  the appropriate data type. 
+**Example** 
+
+generic class NewList (Item) 
+inherits OldList 
+is 
+..... 
+end ; 
+
+Items may be of any  type, an Integer or a Real for example. 
+
+When defining the  package, add the following line: 
+**Example** 
+
+class NewListOfInteger instantiates 
+NewList (Integer); 
+
+
+@subsubsection occt_1819379591_986437237227     Exceptions
+
+The behavior of any  object is implemented by methods, which you define in its class declaration.  The definition of these methods includes not only their signature (their  programming interface) but also their domain of validity. 
+
+In CDL, this domain is  expressed by **exceptions**. Exceptions are raised under various error  conditions. This mechanism is a safeguard of software quality. 
+@subsubsection occt_1819379591_986437237228     Completeness
+
+You use CDL to define  data types. Such definitions are not considered complete unless they contain  the required amount of structured commentary. 
+
+The compiler does not  enforce this required degree of completeness, so it is the responsibility of  the developer to ensure that all CDL codes are properly annotated. 
+
+Completeness is regarded  as an essential component of long-term viability of a software component. 
+
+
+@subsection occt_1819379591_98643723723   Lexical Conventions
+@subsubsection occt_1819379591_986437237231    Syntax  notation
+
+In this manual, CDL  declarations are described using a simple variant of the Backus-Naur formalism.  Note the following: 
+
+  * Italicized words, which may  also be hyphenated, denote syntactical categories, for example:
+
+*declaration-of-a-non-generic-class* 
+
+  * Keywords appear in bold type:
+
+**class** 
+
+  * Brackets enclose optional  elements:
+
+identifier [**from **package-name] 
+
+  * Curly braces enclose repeated  elements. The element may appear zero or many times:
+
+integer ::=  digit{digit} 
+
+  * Vertical bars separate  alternatives:
+
+passing-method ::=  [**in**] | **out **| **in out** 
+
+  * Two apostrophes enclose a  character or a string of characters, which must appear:
+
+exponent ::=  ’E’[’+’]integer | ’E-’ integer 
+
+NOTE 
+So as to introduce ideas progressively, the  examples presented in this manual may be incomplete, and thus not compilable by  the CDL compiler. 
+
+
+@subsubsection occt_1819379591_986437237232    Lexical  elements
+
+A CDL source is composed  of text from one or more compiled units. The text of each compiled unit is a  string of separate lexical elements: **identifiers**, **keywords**, **constants**,  and **separators**. The separators (blank spaces, end of line, format  characters) are ignored by the CDL compiler, but these are often necessary for  separating identifiers, keywords, and constants. 
+
+
+@subsubsection occt_1819379591_986437237233     Comments
+
+With CDL, you cannot use  the expression of all useful information about a development unit. In  particular, certain information is more easily expressed in natural language.  You can add such information to the CDL description of a data type. 
+
+Rubrics and free  comments are to be differentiated: 
+
+**Free comments **are preceded by the characters “--” (two  hyphens), and they terminate at the end of the line in which they appear. 
+**Example** 
+
+--This is a comment 
+
+Unlike rubrics, free  comments can appear before or after any lexical element. The first written  character of the comment itself *must not *be a hyphen. If a hyphen is  necessary make sure it is preceded by a blank. 
+**Example** 
+
+-- -List item 
+
+**Rubrics **are various types of comments attached to CDL components.  A rubric is a comment made up of three hyphens, name of the rubric (without any  intermediary space) and then a colon and a space. It is terminated by the  beginning of the following rubric, or by the end of the commentary. 
+**Example** 
+
+---Purpose:This is an example of a 
+--rubric composed of a 
+--comment which extends to 
+--four lines. 
+
+The different categories  of rubrics and the form of their content do not depend on the Component  Description Language, but on the tool for which it is intended.  
+
+The use of commentary is  generally governed by the internal programming standards of an enterprise. You  are encouraged to use various well-defined rubrics, such as Purpose, Warning,  Example, References, Keywords, etc. 
+
+These rubrics can be  attached to: 
+
+  * Packages
+  * Classes
+  * Methods
+  * Schemas
+  * Executables
+  * Clients
+
+@subsubsection occt_1819379591_986437237234     Identifiers
+
+An identifier is an  arbitrary chain of characters, either letters or digits, but it must begin with  a letter. 
+
+The underscore “_” is  considered to be a letter as long as it doesn’t appear at the beginning or the  end of an identifier. 
+Capital and small  letters are not equivalent (i.e. AB, Ab, aB, ab are four different  identifiers). 
+
+
+@subsubsection occt_1819379591_986437237235     Keywords
+
+The following is a list  of keywords. 
+
+alias                      any                    as                     asynchronous 
+class                     client                 deferred            end 
+enumeration           exception           executable        external 
+fields                     friends               from                 generic 
+immutable              imported            inherits              instantiates 
+is                          library                like                   me 
+mutable                 myclass             out                   package 
+pointer                   primitive             private              protected 
+raises                    redefined           returns              schema 
+static                     to                      uses                 virtual 
+
+In a CDL file, the  following characters are used as punctuation: 
+; : , = ( ) [ ] ‘ “ 
+
+@subsubsection occt_1819379591_986437237236     Constants
+
+There are three  categories of constants: 
+
+  * Numeric
+  * Literal
+  * Named
+
+***Numeric Constants*** 
+
+There are two types of  numeric constants: integer and real. 
+An **integer **constant  consists of a string of digits, which may or may not be preceded by a sign.  Integer constants express whole numbers. 
+**Examples** 
+
+1995         0            -273         +78 
+
+A **real **constant  may or may not be preceded by a sign, and consists of an integral part followed  by a decimal point and a fractional part (either one or both parts may be null,  but both parts must always be present). It may also be followed by the letter E  to indicate that the following figures represent the exponent (also optionally  signed). 
+**Examples** 
+
+5.0        0.0           -0.8E+3          5.67E-12 
+
+***Literal Constants*** 
+
+Literal constants  include individual characters and strings of characters. 
+
+An **individual  character **constant is a single printable character enclosed by two  apostrophes. (See the definition of the class Character in the Standard  Package). 
+**Examples** 
+
+ ‘B’       ‘y’      ‘&amp;’      ‘*’      ‘’’ ‘‘ 
+
+A **string **constant  is composed of printable characters enclosed by quotation marks. 
+**Examples** 
+
+’’G’’     ’’jjjj’’      ’’This is a character string, isn’t it?’’ 
+
+The **quotation mark **can  itself appear within a character string as long as it is preceded by a  backslash. 
+**Examples** 
+
+’’This film was  originally called \’’Gone with the Tide\’’.’’ 
+
+***Named Constants*** 
+
+Named constants are  sub-divided into two categories: Booleans and enumerations. 
+
+**Booleans **can be of two types: True or False. 
+
+An **enumeration **constant  is an identifier, which appears in the description of an enumeration. 
+
+@section occt_1819379591_1718435309 3. Software  Components
+
+
+
+@subsection occt_1819379591_171843530931   Predefined Resources
+@subsubsection occt_1819379591_1718435309311     Primitive types
+
+Primitive types are  predefined in the language and they are **manipulated by value**. 
+
+Four of these primitives  are known to the schema of the database because they inherit from the class **Storable**.  In other words, they can be used in the implementation of persistent objects,  either when contained in entities declared within the methods of the object, or  when they form part of the internal representation of the object. 
+
+The primitives inheriting  from Storable are the following: 
+
+**Boolean                **Is used to represent logical data. It has only  two values: 
+*True *and *False*. 
+**Byte                      **8-bit number. 
+**Character              **Designates any ASCII character. 
+**ExtCharacter         **Is an extended character. 
+**Integer                  **Is an integer number. 
+**Real                                  **Denotes a real number (i.e. one with a whole and  a fractional part, either of which may be null). 
+**ShortReal              **Real with a smaller choice of values and memory  size. 
+
+There are also  non-storable primitives. They are: 
+
+**CString                 **Is used for literal constants. 
+**ExtString              **Is an extended string. 
+**Address                **Represents a byte address of undetermined size. 
+
+The services offered by  each of these types are described in the Standard Package. 
+
+
+@subsubsection occt_1819379591_1718435309312     Manipulating types by reference (by handle)
+
+Two types are  manipulated by handle: 
+
+  * Types defined using classes  inheriting from the **Persistent **class are storable in a file.
+
+  * Types defined using classes  inheriting from the **Transient **class.
+These types are not storable as such in a file. 
+
+![](/devs_guide/cdl/images/cdl_image006.jpg)
+
+Figure 4. Manipulation of a data type by reference 
+
+
+@subsubsection occt_1819379591_1718435309313     Manipulating types by value
+
+Types, which are  manipulated by value, behave in a more direct fashion than those manipulated by  handle. As a consequence, they can be expected to perform operations faster,  but they cannot be stored independently in a file. 
+
+You can store types  known to the schema (i.e. either primitives or inheriting from Storable) and  manipulated by value inside a persistent object as part of the representation.  This is the only way for you to store objects “manipulated by value” in a file. 
+
+
+    <table>
+       <tr>
+               <td>
+               
+               </td>
+       </tr>
+       <tr>
+               <td>
+               
+               </td>
+               <td>
+               ![](/devs_guide/cdl/images/cdl_image007.jpg)
+               </td>
+       </tr>
+</table>       
+Figure 5. Manipulation of a data type by value 
+Three types are  manipulated by value: 
+
+  * Primitive types
+  * Enumerated types
+  * Types defined by classes not  inheriting from Persistent or Transient, whether directly or not
+
+@subsubsection occt_1819379591_1718435309314                                        Summary  of properties
+
+**Figure 6. Summary of the relationship for the  various data** 
+**types between how they are handled and their  storability.** 
+
+
+@subsection occt_1819379591_171843530932   Classes
+
+@subsubsection occt_1819379591_1718435309321    Class  declaration
+
+The class is the main  system for creating data types under CDL. By analyzing any CDL-based software,  you find that classes are the modular units that make up packages. When you  describe a new class, you introduce a new data type. 
+
+Whatever the category of  the described type (manipulated by value, Storable or not, manipulated by  handle, Persistent or not) the structure of the class definition remains the  same. The syntax below illustrates it: 
+**Example** 
+
+-- declaration-of-a-simple-class ::= 
+class class-name from package-name 
+[uses data-type {  ’,’ data-type } ] 
+[raises  exception-name { ’,’ exception-name} ] 
+is class-definition 
+end [ class-name ]  ’;’ 
+data-type ::=  enumeration-name | class-name | 
+exception-name | primitive-type 
+package-name ::=  identifier 
+class-name ::=  identifier 
+class-definition ::= 
+[{member-method}] 
+[declaration-of-fields] 
+[declaration-of-friends] 
+
+Class name becomes a new  data type, which you can use inside its own definition. Other types appearing  in the definition must either be primitive types, previously declared classes,  exceptions, or enumerations. 
+
+Apart from the types  defined in the Standard Package, which are **implicitly visible **everywhere,  you need to declare the data types after the keyword **uses**. This concerns  both the class behavior and its internal representation. 
+
+**Exceptions **are declared after the word **raises**. 
+**Example** 
+
+class Line from  GeomPack 
+usesPoint,  Direction, Transformation 
+raisesNullDirection,  IdenticalPoints 
+is-- class  definition follows here 
+-- using Point,  Direction and 
+-- Transformation  objects,and the 
+-- NullDirection and  Identical- 
+-- -Points  exceptions. 
+end Line; 
+
+The elements, which make  up the definition of a class, are divided into four parts: 
+
+  * the behavior
+  * the invariants
+  * the internal representation
+  * the friend methods and friend  classes.
+    <table>
+       <tr>
+               <td>
+               
+               </td>
+       </tr>
+       <tr>
+               <td>
+               
+               </td>
+               <td>
+               ![](/devs_guide/cdl/images/cdl_image009.jpg)
+               </td>
+       </tr>
+</table>       
+**Figure 7. Contents of a class** 
+*** a deferred class does not have to contain a  constructor** 
+
+
+@subsubsection occt_1819379591_1718435309322     Categories of classes
+
+Classes fall into three categories: 
+
+  * Ordinary classes
+  * Deferred classes
+  * Generic classes
+
+<h4>Deferred classes</h4>
+
+The principal  characteristic of a **deferred class **is that you cannot instantiate it.  Its purpose is to provide you with a given behavior shared by a hierarchy of  classes and dependent on the implementation of the descendents. This allows you  to guarantee a certain base of inherited behavior common to all classes based  on a particular deferred class. Deferred classes are declared as in the  following syntax: 
+**Example** 
+
+-- declaration-of-a-deferred-class ::= 
+deferred class  class-name 
+[inherits class-name  {’,’ class-name}] 
+[uses data-type {’,’  data-type}] 
+[raises exception-name  {’,’ exception-name}] 
+is class-definition 
+end [class-name]’;’ 
+
+
+<h4>Generic classes</h4>
+
+The principal  characteristic of a **generic class **is that it offers you a set of  functional behavior allowing you to manipulate other data types. To instantiate  a generic class you need to pass a data type in argument. Generic classes are  declared as in the following syntax: 
+**Example** 
+
+-- declaration-of-a-generic-class ::= 
+[deferred] generic  class class-name ’(’generic-type 
+{’,’ generic-type}’)’ 
+[inheritsclass-name {’,’ class-name}] 
+[usesdata-type {’,’  data-type}] 
+[raisesexception-name  {’,’ exception-name}] 
+[{[visibility]  declaration-of-a-class}] 
+is class-definition 
+end [class-name]’;’ 
+generic-type ::=  identifier as type-constraint 
+identifier ::=  letter{[underscore]alphanumeric} 
+type-constraint ::= any | class-name [’(’data-type {’,’ 
+data-type}’)’] 
+
+
+
+@subsection occt_1819379591_171843530933   Packages
+
+@subsubsection occt_1819379591_1718435309331    Package  declaration
+
+ **Packages** are  used to group   classes, which have some logical coherence. For example, the  Standard Package groups together all the predefined resources of the language.  In its simplest form, a package contains the declaration of all data types,  which it introduces. You may also use a package to offer public methods and  hide its internal classes by declaring them private. 
+**    ** 
+**Example** 
+
+-- package-declaration ::= 
+**package **package-name 
+[**uses **package-name {’,’ package-name}] 
+**is **package-definition 
+**end **[package-name]’;’ 
+-- package-name ::= 
+identifier 
+-- package-definition ::= 
+[{type-declaration}] 
+[{package-method}] 
+-- type-declaration ::= 
+[**private**] declaration-of-an-enumeration | 
+[**private**] declaration-of-a-class | 
+declaration-of-an-exception 
+-- package-method ::= 
+identifier [simple-formal-part][returned-type 
+-declaration] 
+[error-declaration] 
+[***is private***]’;’ 
+
+The data types described  in a package *may *include one or more of the following data types: 
+
+  * Enumerations
+  * Object classes
+  * Exceptions
+  * Pointers to other object  classes.
+
+Inside a package, two  data types *cannot *have the same name. 
+
+You declare data types  before using them in the definition of other data types. 
+
+When two classes are **mutually  recursive**, one of the two *must *be first declared in an incomplete  fashion. 
+
+Grouped behind the  keyword **uses **are the names of all the packages containing definitions of  classes of which the newly introduced data types are clients. 
+
+The methods you declare  in a package do not belong to any particular class. **Package methods ***must  *carry a name different from the data types contained in the package. Like  any other method, they can be overloaded. With the exception of the keyword **me  **and the visibility (a package method can *only *be either public or  private) package methods are described in the same way as **instance methods**. 
+
+![](/devs_guide/cdl/images/cdl_image010.jpg)
+Figure 8. Contents of a package 
+
+The example of the  package below includes some of the basic data structures: 
+**Example** 
+
+package Collection 
+uses 
+Standard 
+is 
+exception NoSuchObject inherits Failure; 
+exception NoMoreObject inherits Failure; 
+generic class SingleList; 
+generic class Set; 
+end Collection; 
+
+Note that the class Set  is declared after the declarations of the NoSuchObject and NoMoreObject  exceptions and the SingleList class of which Set is a client. In the same way, the classes Failure, Persistent,  and the exception NoSuchObject are defined before they are used. They are  defined in the Standard package, which appears after the keyword **uses**. 
+
+@subsubsection occt_1819379591_1718435309332    Name space
+
+The **name space **or  **scope **of a class extends from the beginning of its declaration up to the  end of the package in which it appears. 
+
+Sometimes, two classes,  which come from separate packages, are both visible to a third package and  carry the same name. For example, there might be two different classes both  called “Window” in a screen generator package and in an architectural package.  As a client of a data type, you can find yourself in the position of having to  remove the ambiguity over the origin of this type; you do this by means of the  keyword **from**. 
+**Example** 
+
+-- class-name ::= 
+identifier [**from **package-name] 
+-- exception-name ::= 
+identifier [**from **package-name] 
+-- enumeration-name ::= 
+identifier [**from **package-name] 
+
+You can use the keyword **from  **everywhere the name of a class, exception, or enumeration appears. As a  consequence, as a client of the class “Window” you could write wherever  necessary: 
+**Example** 
+
+Window from ScreenGenerator 
+-- or 
+Window from ArchitecturalFeatures 
+
+NOTES 
+***Within the description of a package the keyword *****from**** *must be used when referencing any data type  that is not defined in this package.*** 
+
+Here is a further  example: 
+**Example** 
+
+class Line from Geom 
+uses 
+Point from Geom2d, 
+Point from Geom3d 
+is 
+-- class definition  using 
+-- Point from  AppropriatePackage 
+-- wherever Point  appears 
+end; 
+
+
+@subsubsection occt_1819379591_1718435309333     Declaration of classes
+
+You cannot describe a  package in one single file. You need to describe it in different units and send  them separately to the CDL compiler. Each compilation unit can contain the  declaration of a class or of a package. When you describe a class in a unit  different than that, which describes its package, you need to specify which  package the class belongs to. You do this using the keyword **from**. 
+
+If the **from **clause  appears in the **uses **clause of the package, it does not need to be  repeated elsewhere. 
+
+The following example  takes the package “Collection” which was presented above, but this time it is  divided into three compilation units. 
+**Example** 
+
+-- First compilation unit, the package “Collection” : 
+package Collection 
+uses 
+Standard 
+is 
+exception  NoMoreObject inherits Failure from Standard; 
+exception NoSuchObject inherits Failure from Standard; 
+generic class SingleList; 
+generic class Set, Node, Iterator; 
+end Collection; 
+-- Second compilation unit, the class “SingleList” : 
+generic class SingleList from Collection (Item as 
+Storable) 
+inherits 
+Persistent from Standard 
+raises 
+NoSuchObject from  Collection 
+is 
+-- definition of the  SingleList class 
+end SingleList; 
+-- Third compilation unit, the class “Set” : 
+generic class Set from Collection (Item as Storable) 
+  inherits 
+Persistent from Standard; 
+raises 
+NoSuchObject from Collection, 
+NoMoreObject from  Collection 
+private class Node  instantiates SingleList 
+from Collection  (Item); 
+-- etc.... 
+ end Set; 
+
+
+NOTE 
+It is not explicitly stated that the “Node” class  belongs to the “Collection” package. In fact any nested class necessarily  belongs to the package of the class, which encompasses it. 
+
+Note that a package can  hide certain classes (just as it can hide methods) by declaring them **private**.  To make a class private, you prefix its description with the keyword **private**.  In the example of the “Collection” package, the “SingleList” class serves only  to implement the “Set” class. It is recommended to make it private. You write  this as in the following syntax: 
+**Example** 
+
+package Collection 
+uses 
+Standard 
+is 
+generic class Set,  Node, Iterator; 
+private generic class SingleList; 
+exception NoMoreObject inherits Failure from Standard; 
+end Collection; 
+
+
+
+
+@subsection occt_1819379591_171843530934   Other Data Types
+
+These are: 
+
+  * Enumerations
+  * Imports
+  * Aliases
+  * Exceptions
+  * Pointers
+
+@subsubsection occt_1819379591_1718435309341     Enumerations
+
+The **enumerated types **are  the second type, which is manipulated by value. Unlike the primitive types they  are extensible because they are defined by the user under the form of  enumerations. An enumeration is an ordered sequence of named whole constant  values called enumeration constants. 
+**Example** 
+
+declaration-of-an-enumeration ::= 
+**numeration **enumeration-name 
+**is **identifier {’,’ identifier} 
+[**end **[enumeration-name]]’;’ 
+enumeration-name ::= identifier 
+
+The declaration of an  enumeration creates an enumerated type. An object of this type can successively  take the value of any one of the constants cited in the list. 
+**Example** 
+
+enumeration MagnitudeSign is Negative, Null, Positive; 
+
+
+Inside a package, two  enumeration constants cannot have the same name, even if they belong to  different enumerated types. 
+**Example** 
+
+enumeration Cars is 
+Honda, 
+Ford, 
+Volkswagen, 
+Renault 
+end; 
+enumeration AmericanPresidents is 
+Nixon, 
+Reagan, 
+Ford, -- Error: ‘Ford’ already defined 
+Carter 
+end; 
+
+
+@subsubsection occt_1819379591_1718435309342    Imports
+
+An **imported type **is  one of which which has not been defined in CDL. It is up to the supplier of  this data type to ensure compatibility with the CDL language by providing  services which allow CDL to recognize the imported data type. 
+
+The CDL syntax for  declaring an imported type is: 
+
+declaration-of-an-imported-type::= 
+[**private**] **imported  **typename ; 
+**Example** 
+
+-- You can define an imported type as follows: 
+-- In the MyPack.cdl file, you declare the imported 
+type: 
+-- package MyPack 
+.... 
+imported MyImport; 
+.... 
+end Mypack; 
+-- In the MyPack_MyImport.hxx file, you write the 
+following 
+-- C++ code: 
+#ifndef _MyPack_MyImport_HeaderFile 
+#define _MyPack_MyImport_HeaderFile 
+#include Standard_Type.hxx 
+typedef unsigned long MyPack_MyImport; 
+extern const Handle(Standard_Type)&amp; TYPE 
+(MyPack_MyImport); 
+-- In the MyPack_MyImport.cxx file, you write the 
+following 
+-- C++ code: 
+#ifndef _MyPack_MyImport_HeaderFile 
+#include MyPack_MyImport.hxx 
+#endif 
+const Handle(Standard_Type)&amp; TYPE (MyPack_MyImport) 
+
+{ 
+static Handle(Standard_Type) _aType = 
+new Standard_Type  (“MyPack_MyImport”,sizeof 
+(MyPack_MyImport)) 
+ return _aType; 
+} 
+
+Then, add the names of  these two files (MyPack_MyImport.hxx, MyPack_MyImport.cxx) to a file called  FILES in the src subdirectory of the package. If the file does not exist you  must create it. 
+
+
+@subsubsection occt_1819379591_1718435309343    Aliases
+
+An **alias **is an  extra name for a type, which is already known. It is declared as in the  following syntax: 
+
+declaration-of-an-alias::= 
+[**private**] **alias **type1 **is **type2  [**from **apackage] ; 
+**Example** 
+
+alias Mass is Real; 
+---Purpose: 
+-- Defined as a quantity of matter. 
+-- Gives rise to the  inertial and 
+-- gravitational  properties of a body. 
+-- It is measured in  kilograms. 
+
+Having defined *Mass *as  a type of *Real*, you can use either *Mass *or *Real *to type an  argument when defining a method. 
+
+
+@subsubsection occt_1819379591_1718435309344     Exceptions
+
+In the model recommended  by CDL, the principal characteristic of errors is that they are treated in a  different place from the place where they appear. In other words, the methods  recovering and those raising a given exception are written independently from  each other. 
+
+Subsequently this poses  the problem of communication between the two programs. The principle adopted  consists in viewing the exception as both a class and an object. The exception  class (by means of one of its instances) is used to take control of an  exception, which has been raised. 
+
+Consequently, error conditions  are defined by means of **classes of exceptions**. Exception classes are  arranged hierarchically so as to be able to recover them in groups. They are  all descendents of a single root class called “Failure”, and it is at the level  of this class that the behavior linked to the raising of exceptions is  implemented. 
+
+declaration-of-an-exception ::= 
+**exception **exception-name **inherits **exception-name 
+
+All exceptions share identical behavior, that of the  class “Failure”. Here are some examples of exception classes: 
+exception NumericError inherits Failure; 
+exception Overflow inherits NumericError; 
+exception Underflow inherits NumericError; 
+
+The use of exceptions as  a means to interrupt the normal execution of one program and then take control  of another one depends on the programming language used to implement the  methods. See the following chapter <a href="#Defing_Software_Components">“Defining the Software Components”</a>  on page 32. 
+
+
+@subsection occt_1819379591_171843530935   Schemas
+
+The purpose of a **schema  **is to list persistent data types, which will be stored in files by the  application. A schema groups together persistent packages. A persistent package  is one, which contains at least one persistent class. 
+
+declaration-of-a-schema ::= 
+**schema **SchemaName 
+is 
+{**package **PackageName;} 
+{**class **ClassName;} 
+**end**; 
+**Example** 
+
+schema Bicycle 
+---Purpose: Defines the Bicycle schema. 
+is 
+package  FrameComponents; 
+package WheelComponents; 
+end; 
+
+***NOTE*** 
+Note that it is  unnecessary to specify all the dependencies of the packages. It is sufficient  to specify the highest level ones. The others on which they depend are  automatically supplied. 
+@subsection occt_1819379591_171843530936   Executables
+
+The purpose of an **executable  **is to make an executable program without a front-end. It can be used to  test more than one package at a time. An executable is written in a .cdl file  as a set of packages. 
+**Example** 
+
+definition-of-an-executable ::= 
+executable ExecutableName 
+is 
+{ 
+executable ExecutablePart 
+[uses  [Identifier as external] 
+[{’,’  Identifier as external}] 
+[UnitName as  library] 
+[{’,’  UnitName as library}] 
+is 
+{FileName  [as C++|c|fortran|object];} 
+end; 
+} 
+end; 
+**Example** 
+
+executable MyExecUnit 
+---Purpose: 
+-- Describes the  executable MyExecUnit 
+is 
+executable myexec 
+-- the binary file 
+uses 
+Tcl_Lib as external 
+is 
+myexec; 
+-- the C++ file 
+end; 
+-- several binaries can be specified in one .cdl file. 
+executable myex2 
+is 
+myex2; 
+end; 
+end; 
+
+@section occt_1819379591_1972310108 4. Defining the Software Components
+
+@subsection occt_1819379591_197231010841   Behavior
+
+The behavior of an  object class is defined by a list of **methods, **which are either **functions  **or **procedures**. Functions return an object, whereas procedures only  communicate by passing arguments. In both cases, when the transmitted object is  an instance manipulated by a handle, its identifier is passed. There are three  categories of methods: 
+
+**Object constructor            **Creates an instance of the described class. A  class will have one or more object constructors with various arguments or none. 
+
+**Instance method               **Operates on the instance which owns it. 
+
+**Class method                    **Does not work on individual instances, only on  the class                                                     itself. 
+
+@subsubsection occt_1819379591_1972310108411    Object  Constructors
+
+A constructor is a  function, which allows the **creation of instances **of the class it  describes. 
+**Example** 
+
+constructor-declaration ::= 
+Create [ simple-formal-part ] declaration-ofconstructed- 
+type 
+[ exception-declarations ] 
+simple-formal-part ::= 
+’(’  initialization-parameter {’;’ initialization parameter}’)’ 
+initialization-parameter ::= 
+identifier {’,’ identifier} ’:’ parameter-access  datatype 
+[ ’=’ initial-value ] 
+parameter-access ::= 
+**mutable **| [ **immutable **] 
+initial_value ::= 
+numeric-constant | literal-constant | named-constant 
+declaration-of-constructed-type ::= 
+**returns **[ **mutable **] class-name 
+
+The name of the  constructors is fixed: “Create”. The object returned by a constructor  is  always of the type of the described class. If that type is manipulated by a  handle, you *must *declare it as **mutable**, in which case the content  of the instance it references is accessible for further modification. 
+
+For example, the  constructor of the class “Point” 
+**Example** 
+
+Create (X, Y, Z : Real) 
+returns mutable  Point; 
+
+With the exception of  the types predefined by the language, all types of initialization parameters *must  *appear in the **uses **clause of the class of which the constructor is a  member. 
+
+When an initialization  parameter is of a type which is manipulated by a handle, an access right *must  *be associated with it so as to express if the internal representation of  the referenced object is modifiable (**mutable**) or not (**immutable**).  The default option is **immutable**. For example, the constructor of the  persistent class “Line”. 
+**Example** 
+
+Create (P : mutable Point; D : mutable Direction) 
+returns mutable  Line; 
+
+In the above example “P”  and “D” must be mutable because the constructor stores them in the internal  representation of the created line, which is mutable itself. An alternative  would be to accept immutable initialization parameters and then copy them into  the constructor in a mutable form. 
+
+The parameters of a  native type can have a default value: this is expressed by assigning a constant  of the same type to the parameter concerned. Parameters, which have a default  value, may not be present when the call to the constructor is made, in which  case they take the value specified in the declaration. For this reason, they  must all be grouped at the end of the list. For example, the constructor of the  persistent class “Vector”. 
+**Example** 
+
+Create (D : mutable Direction; M : Real = 1.0) 
+returns mutable  Vector; 
+
+A class can have many  constructors (in this case, you say they are **overloaded**) provided that  they differ in their syntax and that the presence of parameters having default  values does not create ambiguities. 
+
+The restrictions on  their use are expressed by a list of **exceptions **against which each  constructor is protected. 
+
+Each class must have at  least one constructor to be able to create objects of its type. 
+@subsubsection occt_1819379591_1972310108412     Instance Methods
+
+An instance method is a  function or procedure, which applies to any instance of the class, which  describes it. 
+**Example** 
+
+declaration-of-an-instance-method ::= 
+identifier formal-part-of-instance-method 
+[  declaration-of-returned-type ] 
+[  exception-declaration ] 
+formal-part-of-instance-method  ::= 
+ ’(’ me [’:’  passing-mode parameter-access ] {’;’ 
+parameter}’)’ 
+parameter ::= 
+identifier {’,’  identifier} ’:’ passing-mode 
+parameter-access 
+data-type [ ’=’ initial-value ] 
+passing-mode ::= 
+[ in ] | out | in  out 
+parameter-access ::= 
+mutable |  [immutable] 
+declaration-of-returned-type  ::= 
+returns  return-access data-type 
+return-access ::= 
+mutable |[ immutable  ]| any 
+
+The name **me **denotes  the object to which the method is applied: you call this the “principal object”  of the method. The passing mode expresses whether the direct content of the  principal object or a parameter is either: 
+
+  * read
+  * created and returned
+  * read then updated and  returned by the method.
+
+Remember that the direct  content of an argument of a type which is manipulated by value contains the  internal representation of the object itself. Thus, when the argument is of  this type, **out **and **in out **mean that the content of the object will  undergo a modification. When the method is a function (as is the case for  constructors), all the arguments must be **in **(read). This is the default  mode. 
+
+In case of an argument  of a type manipulated by a handle, the direct content being an object identifier,  the passing mode addresses itself to the handle, and no longer to the internal  representation of the object, the modification of which is controlled by the  access right. An argument of this type declared **mutable **may see its  internal representation modified. If declared **immutable**, it is  protected. When a parameter is both **in out **and **mutable**, the  identifiers passed and returned denote two distinct modifiable objects. 
+
+When the returned object  is manipulated by a handle it can be declared modifiable or not, or  indeterminate (**any**). To return an object with an indeterminate access  right means that the method transmits the identifier without changing its state  and that the method has no right to alter the access right. This functionality  is particularly useful in the case of collections; temporarily storing an  object in a structure and unable to modify its state. 
+
+With the exception of  the types predefined by the language, all types of parameters and returned  objects, whether manipulated by a handle or by value, *must *appear in the  **uses **clause of the class of which the method is a member. 
+As is the case for  constructors, some parameters can have a default value, provided that they are  of primitive or enumerated type. They are passed in the **in **mode, and  they are found at the end of the list of arguments. 
+
+Overloading of instance  methods and use of exceptions and post-conditions is allowed and respects the  same rules than constructors. 
+
+Note the overloading of  “Coord” in the following example of instance methods associated with the  persistent class “Point”: 
+**Example** 
+
+Coord (me; X, Y, Z : out Real); 
+---Purpose: returns the coordinates of me 
+
+Coord (me; i : Integer) returns Real; 
+---Purpose: returns the abscissa (i=1), the 
+-- ordinate (i=2) or the value (i=3) of  me 
+
+SetCoord (me : mutable; X, Y, Z : Real); 
+---Purpose: modifies the coordinates of me 
+
+Distance (me; P : Point) returns Real 
+---Purpose: returns the distance to a point 
+
+In all these cases, **me  **is implicitly an object of type Point. Only “SetCoord” is able to modify  the internal representation of a point. 
+
+@subsubsection occt_1819379591_1972310108413    Class  Methods
+
+A class method is a  function or procedure relative to the class it describes, but does not apply to  a particular instance of the class. 
+
+declaration-of-a-class-method ::= 
+identifier formal-part-of-class-method 
+[ declaration-of-returned-type ] 
+[ exception-declaration ] 
+formal-part-of-class-method ::= 
+’(’ **myclass **{’;’ parameter}’)’ 
+
+The first parameter **myclass  **indicates that the method does not apply to a previously created instance,  but to the class itself. The rest of the syntax is identical to that of the  instance methods. In particular, access rights (**mutable**, **immutable**,  **any**) and the argument passing mode (**in**, **out**, **in out**)  must remain unchanged. With the exception of the types predefined by the  language, all types of parameters must appear in the **uses **clause of the  class of which the method is a member. Overloading of class methods and the use  of exceptions and post-conditions is allowed, and it follows the same rules as  for constructors and instance methods. 
+Examples of class  methods associated with the class “Real”: 
+**Example** 
+
+First (myclass) returns Real; 
+---Purpose: returns lower limit of reals 
+
+Last (myclass) returns Real; 
+---Purpose: returns upper limit of reals 
+
+
+@subsubsection occt_1819379591_1972310108414    Package  Methods
+
+Package methods are  methods which are members of a package. They are frequently used for library or  application initialization, or for offering an application programming  interface to the sources to the package. They are sometimes methods used for  development purposes but which are not made available to final end-users of the  package. 
+
+package-method ::= 
+identifier  [simple-formal-part][returned-type-declaration] 
+[exception-declaration] 
+[**is private**]’;’ 
+
+
+@subsubsection occt_1819379591_1972310108415     Sensitivity to Overloading
+
+When there is more than  one method of a class, several methods share the same name but have different  syntax, you say the method is overloaded. 
+
+In order that the  methods can be considered distinct, they must differ either in the number of  parameters, or one of their parameters must be of a different type. In  particular, you *cannot *overload a method if you merely modify it as  follows: 
+
+  * The type of the returned  object when the method behaves as a function
+  * The name or the mode of  passing a parameter 
+(**in**, **out**, or **in out**) 
+  * The mutability of passed  objects 
+(**mutable**, **immutable**, **any**) 
+  * Default value of a parameter.
+@subsection occt_1819379591_197231010842   Internal Representation
+
+Each object contains its  own state in a private space in the memory. This state consists of a set of **fields**,**  **which include or reference other objects. 
+**Example** 
+
+declaration-of-the-internal-representation-of-a-class 
+::= 
+**fields **field {field} 
+field ::= 
+identifier {’,’ identifier} ’:’ data-type [’[’integer 
+{’,’integer}’]’]’;’ 
+
+A copy of all the  defined fields exists locally in each instance of the class. This group of  fields will be initialized by the class constructors when the object is  instantiated. 
+
+Fields *must not *have  the same name as any method of the class in which they appear. When the field  type is followed by a list of integer constants between square brackets, the  data will take the form of a multi-dimensional array containing objects of this  type. 
+
+The following example  shows two equivalent ways of describing three fields of the “Real” type: 
+**Example** 
+
+fields 
+x, y, z: Real; 
+coord: Real[3]; 
+
+Depending on their type,  Object fields have one of the two forms. When the field is of the “manipulated  by handle” type, it corresponds to an identifier. In this case, the contents of  the object can be shared by other objects or by a handle in a program. When the  field is of a “manipulated by value” type, it contains the value of the object.  In this case you say the object is **embedded**. 
+
+@subsection occt_1819379591_197231010843   Exceptions
+  
+Exceptions describe  exceptional situations, which can arise during the execution of a method. With  the raising of an exception, the normal course of program execution is  interrupted. The actions carried out in response to this situation are called   treatment of exception. 
+
+exception-treatment ::= **raises **exception-name  {’,’ 
+exception-name} 
+
+Each exception name  corresponds to a class of exceptions previously defined as being susceptible to  being raised by the method under which it appears. Exception classes must all  appear in the **raises **clause of the class of which the method is a member.  The class of exceptions is analogous to the class of objects described in this  manual. 
+
+Take for example the  method which returns the x, y, or z coordinate of a point. 
+**Example** 
+
+Coord (me; i : Integer) returns Real 
+---Purpose: 
+-- Returns the abscissa (i=1) 
+-- the ordinate (i=2) 
+-- or the value (i=3) 
+-- of me. 
+raises OutOfRange; 
+-- if i is not equal to 1, 2, or 3. 
+
+Instance methods are  likely to raise certain exceptions called **systematic exceptions **which do  not have to appear. They are: 
+
+**NullObject                         **Raised when the principal object does not exist. 
+
+**ImmutableObject                          **Raised when a method tries to modify an immutable  principal object. 
+
+**TypeMismatch                              **Raised if an argument typed by association is of  an unsuitable type. 
+
+These exceptions are described  in the Standard Package (System Toolkits). 
+
+
+@subsection occt_1819379591_197231010844   Inheritance
+
+@subsubsection occt_1819379591_1972310108441     Overview
+
+The notion of  inheritance comes from a development strategy according to which you begin by  modeling data in the most general fashion. Then you specialize it more and more  so as to correspond to more and more precise cases. 
+
+For example, to develop  a basic geometry, you can first of all consider the group of geometric objects,  and then differentiate the points, vectors, and curves. You can specialize the  latter into conic sections, and then decompose them into circles, ellipses, and  hyperbolae. Then, the class of conics is considered as a sub-class of curves,  and a super-class of circles. 
+
+A sub-class has at least  the behavior of its super-classes. Thus, a circle could be viewed as a conic, a  curve, or even as a geometric object. In each case, the applicable methods  belong to the level where you view the class. In this case, you say that the  sub-class inherits the behavior from its super-classes. 
+**Example** 
+
+declaration-of-a-sub-class ::= 
+**class **class-name 
+**inherits **class-name 
+[**uses **data-type {’,’ data-type}] 
+[**raises **exception-name {’,’ exception-name}] 
+**is **class-definition 
+**end **[class-name]’;’ 
+
+A class cannot inherit  one of its descendent classes; nor can it inherit a native type. All the  classes of a system can be described in a non-cyclic diagram called the **inheritance  graph**. 
+
+The definition of a  sub-class is identical to that of a simple class. Note that a super-class *must  not *appear in the **uses **clause of the sub-class, even if it appears  in the definition of the sub-class. The behavior of a sub-class includes as a  minimum all  instance methods and protected methods of its super-classes. 
+
+NOTE 
+Note that constructors and class methods are never  inherited. 
+
+
+@subsubsection occt_1819379591_1972310108442     Redefining methods
+
+Certain inherited  methods can be redefined. 
+**Example** 
+
+declaration-of-a-redefined-method ::= 
+identifier formal-part-of-instance-method [returnedtype- 
+declaration] 
+[declaration-of-exceptions] 
+**  is redefined **[visibility]’;’ 
+
+A redefined method must conform  to the syntax described in the super-class where it appears. The exceptions  contained in the super-class can be renewed, and others may be added as long as  they inherit from an ancestor class. 
+
+The **redefined **attribute  can be applied neither to a constructor, nor to a class method, since neither  of them can be inherited. If the redefined method is private or protected, the  visibility must be exactly repeated in the redefinition. For further details on  visibility, refer to <a href="#Visibility">“Visibility”</a> on page 48. 
+**Example** 
+
+SquareDistance (me; P : Point) returns Real 
+is redefined private; 
+
+With regards to the  internal representation, all fields defined in the super-classes are, by  default, inherited, but they can also be redefined. 
+
+@subsubsection occt_1819379591_1972310108443     Non-redefinable methods
+
+Instance methods, which  are declared virtual are redefinable in descendent classes, and you can force  this redefinition by making a method **deferred**. For more details, see the  next section. 
+**Example** 
+
+declaration-of-a-non-redefinable-method ::= 
+identifier formal-part-of-instance-method [returnedtype- 
+declaration] 
+[declaration-of-exceptions] 
+** is virtual **[visibility]’;’ 
+
+All methods are static  by default. To enable redefinition in all the child classes, add “**is virtual;**“ when declaring the method. 
+
+You must also be able to  forbid redefinition. A redefinable method can become non-redefinable if you  declare: **is redefined static**. 
+
+
+@subsubsection occt_1819379591_1972310108444     Deferred Classes and Methods
+
+The presence of certain  classes in the inheritance graph can be justified purely by their ability to  force certain behavior on other classes, in other words, to make other classes  provide various services. 
+
+The CDL language allows  you to describe a class, which introduces methods without implementing them, so  as to force its descendent classes to define them. These are called **deferred  classes**; the non-implemented methods are also termed **deferred methods**. 
+**Example** 
+
+declaration-of-a-deferred-class ::= 
+**deferred class **class-name 
+ [**inherits **class-name 
+[**uses **data-type {’,’ data-type}] 
+[**raises **exception-name {’,’ exception-name}] 
+**is **class-definition 
+**end **[class-name]’;’ 
+declaration-of-a-deferred-method ::= 
+identifier formal-part-of-instance-method [returnedtype- 
+declaration] 
+[declaration-of-exceptions] 
+**is deferred **[visibility]’;’ 
+
+Only instance methods  can be deferred. 
+
+It is sufficient for a class to contain one deferred  method for it to be a deferred class. It can contain any number of deferred  methods (or none). 
+
+A deferred class may  still have an internal representation but one or more **non-** **protected **constructors  would be necessary to initialize them. The constructors must be visible in the  sub-classes. 
+
+The constructors of a  deferred class are called **Initialize **(not **Create**). They are **protected  **by default, and do not return any object. You cannot create an object of a  deferred class type. 
+For example, consider  the class “Point”, and its declaration as deferred. 
+**Example** 
+
+deferred class Point inherits Geometry is 
+Initialize; 
+---Purpose: Initializes the point. 
+Coord (me; X, Y, Z : out Real) 
+---Purpose: Returns the coordinates 
+is deferred; 
+SetCoord (me : mutable; X, Y, Z : Real) 
+---Purpose: Modifies the coordinates 
+is deferred; 
+Distance (me; P : Point) returns Real; 
+---Purpose: Returns the distance from the point P 
+end Point; 
+
+Notice that the function  “Distance” is not deferred. Although this class contains no representation,  this method is programmable by calling “Coord”. 
+
+In a sub-class of a  deferred class, all deferred methods, which have been inherited, *must *be  implemented, then redeclared (the attribute **redefined **is useless for  this purpose), unless the sub-class is itself deferred. 
+
+A non-deferred method  can be redefined as a deferred one, in which case it will be declared as  follows: **is redefined deferred**. 
+
+The notion of deferred  class is very useful. The advantage of introducing it, as was previously shown  in the deferred class “Point”, is that the corresponding resources will be  available even before being implemented. Later, you can add different  representations to Point (for example, spherical or Cartesian coordinates)  without having to modify client programs. 
+
+Thanks to the  possibility of redefining methods, this approach does not have any negative  impact on performance: a method implemented at the level of a deferred class  can be reprogrammed in one of its sub-classes while taking into account the  data representation. 
+@subsubsection occt_1819379591_1972310108445     Declaration by Association
+
+At the heart of a class  hierarchy, object identifiers are compatible in the ascendant sense. Since the  Conic class is descended from the Curve class, an identifier of type Curve can  reference an object of type Conic (remember that the behavior of Curve is  applicable to Conic). In other words, you can assign a reference to a Conic to  an identifier of type Curve, but *not *vice versa. 
+
+For example, once the  classes have been compiled you could write a C++ test program in which you  instantiate a Conic but reference it with a handle to a Curve: 
+
+**Example** 
+
+Handle(Curve) c = new Conic 
+
+This same rule applies  to parameters of methods; that is to say, you can call a method with  identifiers corresponding to a sub-type of that specified in its declaration.  To illustrate this, you go back to the “Distance” method of the “Point” class: 
+**Example** 
+
+Distance (me; P : point) returns Real; 
+
+Conforming to the rule  of type compatibility, you could make a call to the method “Distance” with  reference to an object from a class descended from “Point”. Consequently, if  “SphericPoint” is a sub-class of “Point” and therefore inherits this method, it  will be possible to calculate the distance between two “SphericPoint”, or  between a “SphericPoint” and a “Point”, without having to redefine the method. 
+
+On the other hand,  sometimes you may want to force two parameters to be exactly of the same type,  and thus not apply the rule of type compatibility. To do this, you need to  associate the type of the concerned parameters in the method declaration. 
+**Example** 
+
+association-typing ::= 
+**like **associated-parameter 
+associated-parameter ::= 
+**me **| identifier 
+
+
+NOTE 
+***Note that identifier is the name of a parameter, which appears*** 
+***first in the formal part of the declaration of the method.*** 
+
+
+You can use this  technique, which consists in declaring by association, to declare a method that  will exchange the content of two objects, or a method, which copies another  object: 
+**Example** 
+
+Swap (me : mutable; With : mutable like me); 
+DeepCopy (me) returns mutable like me; 
+
+Make sure *not *to  write the Swap method as in the syntax below: 
+
+**Example** 
+
+Swap (me : mutable; With : mutable Point); 
+
+In this case **me **may  be a CartesianPoint or a SphericalPoint, while “With” can only be a Point. 
+@subsubsection occt_1819379591_1972310108446     Redefinition of Fields
+
+The creation of a  hierarchy of classes should be viewed as a means to specialize their behavior,  (e.g. a circle is more specialized than a conic section). The more you  specialize the object classes, the more it is justified to call into question  the inherited fields in order to obtain greater optimization. So, in the  description of the internal representation of a sub-class, it is possible not  to inherit all of the fields of the super-classes. You then say the fields have  been redefined. 
+**Example** 
+
+redefinition-of-the-representation-of-a-class ::= 
+**redefined **redefinition-of-a-field {’,’ redefinition-of-a- 
+field}’,’ 
+redefinition-of-a-field ::= 
+[field-name] **from **[**class**] class-name 
+
+Redefinition of fields  can *only *be done in classes manipulated by a handle. 
+
+This declaration appears  at the beginning of the definition of the internal representation of the  sub-class, which breaks the field inheritance. The non-inherited fields are all  those which come from the class specified behind the rubric **from**. 
+
+
+@subsection occt_1819379591_197231010845   Genericity
+
+@subsubsection occt_1819379591_1972310108451     Overview
+
+Inheritance is a  powerful mechanism for extending a system, but it does not always allow you to  avoid code duplication, particularly in the case where two classes differ only  in the type of objects they manipulate (you certainly encounter this phenomenon  in all basic structures). In such cases, it is convenient to send arbitrary  parameters representing types to a class. Such a class is called a **generic  class**. Its parameters are the generic types of the class. 
+
+Generic classes are  implemented in two steps. You first declare the generic class to establish the  model, and then instantiate this class by giving information about the generic  types. 
+
+@subsubsection occt_1819379591_1972310108452     Declaration of a Generic Class
+
+The syntax is as  follows: 
+**Example** 
+
+declaration-of-a-generic-class ::= 
+[**deferred**] **generic class **class-name  ’(’generic-type 
+{’,’generic-type}’)’ 
+[**inherits **class-name 
+[**uses **data-type {’,’ data-type}] 
+[**raises **exception-name {’,’ exception-name}] 
+**is **class-definition 
+**end **[class-name]’;’ 
+generic-type ::= 
+identifier **as **type-constraint 
+type-constraint ::= 
+**any **| class-name [’(’data-type {’,’data-type}’)’] 
+
+The names of generic  types become new types, which are usable in the definition of a class, both in  its behavior (methods) and its representation (fields). The generic type is  only visible inside the generic class introducing it. As a result, it is  possible to have another generic class using the same generic type within the  same package. 
+When you specify the  type constraint under the form of a class name, you impose a minimum set of  behavior on the manipulated object.  
+
+This shows that the  generic type has as a minimum the services defined in the class. This can be  any kind of a previously defined class, including another generic class, in  which case you state exactly with what types they are instantiated. 
+
+When the generic type is  constrained by the attribute **any**, the generic class is intended to be  used for any type at all, and thus corresponds to classes whether manipulated  by a handle or by value. 
+
+No class can inherit  from a generic class. 
+
+A generic class can be a  deferred class. A generic class can also accept a deferred class as its  argument. In both these cases any class instantiated from it will also be  deferred. The resulting class can then be inherited by another class. 
+
+Below is a partial  example of a generic class: a persistent singly linked list. 
+**Example** 
+
+generic class SingleList (Item as Storable) 
+inherits Persistent 
+raises NoSuchObject 
+is 
+Create returns mutable SingleList; 
+    ---Purpose: Creates an empty list 
+IsEmpty (me) returns  Boolean; 
+    ---Purpose: Returns true if the list me is  empty 
+SwapTail (me :  mutable; S : in out mutable 
+SingleList) 
+    ---Purpose: Exchanges the tail of list me  with S 
+-- Exception  NoSuchObject raised when me is 
+empty 
+raises NoSuchObject; 
+   Value (me) returns Item 
+   ---Purpose: Returns first element of the list  me 
+-- Exception NoSuchObject  raised when me is 
+empty 
+raises NoSuchObject; 
+   Tail (me) returns mutable SingleList 
+---Purpose: Returns  the tail of the list me 
+-- Exception  NoSuchObject raised when me is 
+empty 
+raises NoSuchObject; 
+   fields 
+Data : Item; 
+   Next : SingleList; 
+   end SingleList; 
+
+Even though no object of  the type “SingleList” IS created, the class contains a constructor. This class  constitutes a model, which will be recopied at instantiation time to create a  new class which will generate objects. The constructor will then be required. 
+**Example** 
+
+generic class Sequence(Item as any, Node as 
+SingleList(Item)) 
+inherits Object 
+. . . 
+end Sequence 
+
+In the above example,  there are two generic types: Item &amp; Node. The first imposes no restriction.  The second must at least have available the services of the class SingleList  instantiated with the type with which Sequence will itself be instantiated. 
+
+In the **incomplete  declaration of a generic class**, the keyword **generic **must appear. 
+**Example** 
+
+generic class SingleList; 
+generic class Sequence; 
+@subsubsection occt_1819379591_1972310108453     Instantiation of a Generic Class
+
+The syntax is as  follows: 
+**Example** 
+
+instantiation-of-a-generic-class ::= 
+[**deferred**] **class  **class-name 
+**     instantiates **class-name ’(’data-type {’,’ 
+data-type}’);’ 
+
+Instantiation is said to  be **static**. In other words, it must take place before any use can be made  of the type of the instantiated class. Each data type is associated term by  term with those declared at the definition of the generic class. These latter  ones, when they are not of the type **any**, restrict instantiation to those  classes, which have a behavior at least equal to that of the class specified in  the type constraint, including constructors. Note that this is not guaranteed  by inheritance itself. 
+
+For example, let’s  instantiate the class “Sequence” for the type “Point”: 
+**Example** 
+
+class SingleListOfPoint instantiates SingleList(Point); 
+class Sequence instantiates 
+Sequence(Point,SingleListOfPoint); 
+
+The instantiation of a  generic deferred class is a deferred class (the **deferred **attribute must  be present during instantiation). An instantiated class cannot be declared in  an incomplete fashion. 
+
+@subsubsection occt_1819379591_1972310108454    Nested  Generic Classes
+
+It often happens that  many classes are linked by a common generic type. This is the case when a base  structure provides an iterator, for example, in the class “Graph”. A graph is  made up of arcs, which join together the nodes, which reference objects of any  type. This type is generic both for the graph and for the node. In this  context, it is necessary to make sure that the group of linked generic classes  is indeed instantiated for the same type of object. So as to group the  instantiation, CDL allows the declaration of certain classes to be nested. 
+**Example** 
+
+declaration-of-a-generic-class ::= 
+   [**deferred**] **generic class **class-name  ’(’generic- 
+type{’,’generic-type}’)’ 
+   [**inherits **class-name {’,’ class-name}] 
+   [**uses **data-type {’,’ data-type}] 
+   [**raises **exception-name {’,’ exception-name}] 
+   [{[visibility] class-declaration}] 
+**   is **class-definition 
+**end **[class-name]’;’ 
+   class-declaration ::= 
+   incomplete-declaration-of-a-class | 
+   declaration-of-a-non-generic-class | 
+  instantiation-of-a-generic-class 
+
+**Nested classes**, even though they are described as non-generic  classes, are generic by construction, being inside the class of which they are  a part. As a consequence, the generic types introduced by the **encompassing  class **can be used in the definition of the nested class. This is true even  if the generic type is only used in a nested class. The generic types still* must  *appear as an argument of the encompassing class. All other types used by a  nested class *must *appear in its **uses **or **raises **clauses,  just as if it were an independent class. 
+
+Nested classes are, by  default, **public**. In other words, they can be used by the clients of the  encompassing class. On the other hand, when one of the nested classes is  declared **private **or **protected**, this class *must not *appear  in any of the public methods of the other classes. It cannot be used in a  protected field because then it could be used in a sub-class, which implies it  would not be private. 
+
+The following example  shows how to write the Set class with its iterator. 
+**Example** 
+
+generic class Set (Item as Storable) 
+inherits Persistent 
+private class Node  instantiates SingleList (Item); 
+class Iterator 
+   uses Set, Node 
+   raises  NoSuchObject, NoMoreObject 
+   is 
+   Create (S : Set)  returns mutable Iterator; 
+---Purpose: Creates  an iterator on the group S 
+   More (me) returns  Boolean; 
+---Purpose: Returns  true if there are still elements 
+   -- to explore 
+   Next (me) raises  NoMoreObject; 
+---Purpose: Passes  to the following element 
+   Value (me)  returns any Item raises NoSuchObject; 
+---Purpose: Returns  the current element 
+   fields 
+   Current : Node; 
+end Iterator; 
+is 
+   Create returns  mutable Set; 
+---Purpose: Creates  an empty group 
+   IsEmpty (me)  returns Boolean; 
+---Purpose: Returns  true if the group is empty 
+   Add (me :  mutable; T : Item); 
+---Purpose: Adds an  item to the group me 
+   Remove (me :  mutable; T : item) raises 
+NoSuchObject; 
+---Purpose: Removes  an item from the group me 
+   etc. 
+   fields 
+   Head : Node; 
+end Set; 
+
+Note that in their  fields, both “Set” and “Iterator” are clients of another class, “Node”. This  last can be effectively declared **private **for it only appears in fields  which are themselves private. 
+
+The instantiation of a  generic class containing nested classes remains unchanged. The same declaration  is used to instantiate the encompassing class and the nested classes. These  latter will have their name suffixed by the name supplied at instantiation,  separated by “Of”. For example, you instantiate the class “Set” described above  for the type “Point” as follows: 
+**Example** 
+
+class SetOfPoint instantiates Set(Point); 
+
+In doing so, you  implicitly describe the classes “NodeOfSetOfPoint” and “IteratorOfSetOfPoint”,  which are respectively the result of the concatenation of “Node” and “Iterator”  with “Of” then “SetOfPoint”. 
+
+Note that in the  incomplete declaration of an encompassing class, all the names of the nested  classes *must *appear behind that of the encompassing class. 
+
+incomplete-declaration-of-a-generic-class ::= 
+[**deferred**] **generic **class-name {’,’  class-name}; 
+
+For example, an incomplete declaration of the above  class “Set” would be as in the example below: 
+**Example** 
+
+generic class Set, Node, Iterator; 
+
+Only the encompassing  class can be deferred. In the above example only the class “Set” can be  deferred. 
+
+
+
+@subsection occt_1819379591_197231010846   Visibility
+
+@subsubsection occt_1819379591_1972310108461     Overview
+
+A field, method, class,  or package method is only available for use if it is **visible**. 
+Each of these components  has a default visibility, which can be explicitly modified during class or  package declaration. The three possible states of visibility are: 
+
+  * Public
+  * Private
+  * Protected
+
+@subsubsection occt_1819379591_1972310108462     Visibility of Fields
+
+A field is **private**.  It can never be public - this would destroy the whole concept of data  encapsulation. The attribute **private **is redundant when it is applied to  a field. This means that a field is only visible to methods within its own  class. 
+A field can be declared **protected  **which means that it becomes visible in subclasses of its own class. Its  contents can be modified by methods in subclasses. 
+
+field ::= 
+identifier {’,’ identifier} ’:’ data-type 
+[’[’integer{’,’integer}’]’] 
+[**is protected**]’;’ 
+Example 
+
+fields 
+   Phi, Delta, Gamma : AngularMomenta [3] 
+   is protected ; 
+
+
+@subsubsection occt_1819379591_1972310108463     Visibility of Methods
+
+Methods act on fields.  Only methods belonging to a class can act on the fields of the class; this  stems from the principle of object encapsulation. Methods can be characterized  in three ways: by default, methods are **public**. Methods can be declared **private  **or **protected **to restrict their usage. 
+
+**Public methods                            **Are the default and are generally the most  common. They describe the behavior of a class or a package, and they are  callable by any part of a program. 
+
+**Private methods                            **Exist only for the internal structuring of their  class or their package. Private class methods can only be called by methods  belonging to the same class. Private package methods can only be called by all  methods belonging to the same package and its classes. 
+
+**Protected methods            **Are private methods, which are also callable from  the interior of descendent classes.  
+
+If you want to restrict  the usage of a method, you associate with it a visibility as follows : 
+
+-- declaration-of-the-visibility ::= 
+**is **visibility 
+visibility ::= **private **| **protected** 
+
+The declaration of the  visibility of a method appears at the end of its definition, before the final  semi-colon. The attribute **private **indicates that the method will only be  visible to the behavior of the class of which the method is a member; **protected  **will propagate the visibility among the sub-classes of this class. 
+
+For example, add to the  class “Line” an internal method allowing the calculation of the perpendicular  distance to the power of two, from the line to a point. 
+**Example** 
+
+SquareDistance (me; P : Point) returns Real 
+@subsubsection occt_1819379591_1972310108464     Visibility of Classes, Exceptions, &amp; Enumerations
+
+The visibility of a  class is the facility to be able to use this class in the definition of another  class. The visibility of a class extends from the beginning of its declaration  up to the end of the package in which it appears. You have seen that the  keyword **uses **allows extension of this visibility to other packages. 
+
+As was explained in the  section on “<a href="#Name_Space">Name Space</a>”, any ambiguity, which arises from having two classes  with the same name coming from different packages, is dealt with by the use of  the keyword **from**. 
+
+A class declared **private  **is only available within its own package. 
+
+@subsubsection occt_1819379591_1972310108465    Friend  Classes &amp; Methods
+
+In certain cases,  methods need to have direct access to the private or protected parts of classes  of which they are clients. Such a method is called a **friend **of the  class, which is accessed. For example, you declare a method to be a friend when  a service can only be obtained via the use of another non-descendent class, or  perhaps when this will help to improve performance. 
+
+Classes can also be  declared friends of other classes. In this case all the methods of the friend  class will have access to the fields and methods of the host class. The right  is **not reciprocal**. 
+
+Friend classes or  methods are declared inside the class, which reveals its private and protected  data or methods to them. This helps in managing the continuing evolution of a  class, helping to recognize and to avoid the creation of side effects. 
+**Example** 
+
+declaration-of-friends ::= 
+**friends **friend {’,’friend} 
+   friend ::= 
+   identifier **from **[**class**] class-name  [formal-part] | 
+**Defining the Software Components 67** 
+identifier **from **[**package**] package-name  [formal-part] | 
+**   class**] class-name 
+   formal-part ::= 
+   simple-formal-part | 
+   formal-part-of-instance-method | 
+   formal-part-of-class-method 
+
+The formal part *must *be  presented if the method contains one; thus this can be overloaded without  necessarily propagating the friend relationship among its homonyms. The keyword  **class **allows you to avoid certain ambiguities. For example, it removes  any confusion between “method M from class C” and “method M from package P”. 
+
+As an example, take a  method, which calculates the perpendicular distance between a line and a point.  Suppose this method needs to access the fields of the point. In the class  “Point” you would write: 
+**Example** 
+
+friends Distance from Line (me; P : Point) 
+
+A method can be a friend  to many classes. The class to which the method belongs does *not *need to  appear in the **uses **clause of other classes of which it is a friend. 
+    <table>
+       <tr>
+               <td>
+               
+               </td>
+       </tr>
+       <tr>
+               <td>
+               
+               </td>
+               <td>
+               ![](/devs_guide/cdl/images/cdl_image011.jpg)
+               </td>
+       </tr>
+</table>      When the methods of a class are all friends  of another class, you can establish the friendship at the level of the class. 
+
+
+
+Figure 9. Visibility of various components 
+@section occt_1819379591_858765726 Appendix A. Syntax  Summary
+
+
+
+This summary of the CDL  syntax will aid in the comprehension of the language, but does *not *constitute  an exact definition thereof. In particular, the grammar described here accepts  a super-set of CDL constructors semantically validated. 
+
+(1) capital ::= 
+’A’ | ’B’ | ’C’ | ’D’ | ’E’ | ’F’ | ’G’ | ’H’ | 
+’I’ | ’J’ | ’K’ | ’L’ | ’M’ | ’N’ | 
+’O’ | ’P’ | ’Q’ | ’R’ | ’S’ | ’T’ | ’U’ | ’V’ | 
+’W’ | ’X’ | ’Y’ | ’Z’ 
+
+(2) non-capital ::= 
+’a’ | ’b’ | ’c’ | ’d’ | ’e’ | ’f’ | ’g’ | ’h’ | 
+’i’ | ’j’ | ’k’ | ’l’ | ’m’ | ’n’ | 
+’o’ | ’p’ | ’q’ | ’r’ | ’s’ | ’t’ | ’u’ | ’v’ | 
+’w’ | ’x’ | ’y’ | ’z’ 
+
+(3) digit ::= 
+’0’ | ’1’ | ’2’ | ’3’ | ’4’ | ’5’ | ’6’ | ’7’ | 
+’8’ | ’9’ 
+
+(4) underscore ::= 
+’_’ 
+
+(5) special character  ::= 
+’ ’ | ’!’ | ’”’ | ’#’ | ’$’ | ’%’ | ’&amp;’ | ’’’ | 
+’(’ | ’)’ | ’*’ | ’+’ | ’,’ | ’-’ | 
+’.’ | ’/’ | ’:’ | ’;’ | ’’ | ’=’ | ’’ | ’?’ | 
+’@’ | ’[’ | ’\’ | ’]’ | ’^’ | ’‘’ | 
+’{’ | ’|’ | ’}’ | ’~’ 
+
+(6) printable  character::= 
+capitals | non-capitals | digits | underscore | 
+special characters 
+
+(7) letter ::= 
+capital |  non-capital 
+
+(8) alphanumeric ::= 
+letter | digit 
+
+(9) identifier ::= 
+letter{[underscore]alphanumeric} 
+
+(10) integer ::= 
+digit{digit} 
+
+(11) exponent ::= 
+’E’[’+’]integer |  ’E-’integer 
+
+(12) numeric-constant  ::= 
+[’+’]integer ’.’ integer[exponent] | ’-’integer 
+’.’ integer[exponent] 
+
+
+(13) literal-constant  ::= 
+’’’printable character’’’ | ’~’{printable 
+character}’~’ 
+
+(14) package-name ::= 
+identifier 
+
+(15) enumeration-name  ::= 
+identifier [**from**** **package-name] 
+
+(16) class-name ::= 
+identifier [**from**** **package-name] 
+
+(17) exception-name ::= 
+identifier [**from**** **package-name] 
+
+(18) constructor-name  ::= 
+’Create’ |  ’Initialize’ 
+
+(19) primitive-type ::= 
+’Boolean’ |  ’Character’ | ’Integer’ | ’Real’ 
+
+(20) data-type ::= 
+enumeration-name | class-name | exception-name 
+| primitive-type 
+
+(21) passed-type ::= 
+data-type | **like me**** **| **like**** **identifier 
+
+(22) passing-mode ::= 
+[**in**] | **out**** **| **in out** 
+
+(23) parameter-access ::= 
+**mutable**** **| [**immutable**] 
+
+(23A) return-access ::= 
+**mutable**** **| [**immutable**]| **any** 
+
+(24) value ::= 
+numeric-constant | literal-constant | 
+identifier 
+
+(25) parameter ::= 
+identifier {’,’ identifier} ’:’ passing-mode 
+access-right passed-type [’=’ value] 
+
+(26) simple-formal-part  ::= 
+’(’parameter {’;’  parameter}’)’ 
+
+(27)  formal-part-of-instance-method ::= 
+’(’**me**** **[’:’ passing-mode access-right] {’;’ 
+parameter}’)’ 
+
+(28)  formal-part-of-class-method ::= 
+’(’**myclass**** **{’;’ parameter}’)’ 
+
+(29) visibility ::= 
+**private**** **| **protected** 
+(30) redefinition ::= 
+**static**** **| **deferred** 
+(31) definition-level  ::= 
+redefinition |** ****redefined**** **[redefinition] 
+
+(32)  declaration-of-constructed-type ::= 
+**returns**** **[**mutable**] class-name 
+
+(33)  declaration-of-returned-type ::= 
+**returns**** **return-access  passed-type 
+
+(34)  declaration-of-errors ::= 
+**raises**** **exception-name {’,’  exception-name} 
+
+(35)  declaration-of-visibility ::= 
+**is****  **visibility 
+
+(36)  declaration-of-attributes-of-instance-method ::= 
+**is**** **visibility | **is **definition-of-level 
+[visibility] 
+
+(37) constructor ::= 
+constructor-name [simple-formal-part] 
+[declaration-of-constructed-type] 
+[declaration-of-errors] 
+[declaration-of-visibility]’;’ 
+
+(38) instance-method ::= 
+identifier formal-part-of-instance-method 
+[declaration of returned type] 
+[declaration-of-errors] 
+[declaration-of-attributes-of-instancemethod]’;’ 
+
+(39) class-method ::= 
+identifier formal-part-of-the-class-method 
+[declaration of returned type] 
+[declaration-of-errors] 
+[declaration-of-visibility]’;’ 
+
+(40) package-method ::= 
+identifier [simple-formal-part] 
+[declaration-of-returned-type] 
+[declaration-of-errors] 
+[**is private**]’;’ 
+
+(41) member-method ::= 
+constructor |  instance-method | class-method 
+
+(42) formal-part ::= 
+simple-formal-part | 
+formal-part-of-instance-method| 
+formal-part-of-class-method 
+
+(43) friend ::= 
+identifier **from**** **[**class**] class-name  [formal-part] 
+| 
+identifier **from**** **[**package**] package-name [formal- 
+part] | 
+[**class**] class-name 
+
+(44) field ::= 
+identifier {’,’ identifier} ’:’ data-type 
+[’[’integer {’,’ integer}’]’] 
+[**is protected**]’;’ 
+
+45)  redefinition-of-field ::= 
+[field-name] **from**** **[**class**] class-name 
+
+(46)  declaration-of-fields ::= 
+**fields**** **[**redefined**** **redefinition-of-field  {’,’ 
+redefinition-of-field}’;’] 
+field {field} 
+
+(47)  declaration-of-an-alias::= 
+[**private**] **alias**** **class-name1 **is**** **class-name2  [**from** 
+package-name] 
+
+(48)  declaration-of-friends ::= 
+**friends**** **friend {’,’ friend} 
+
+(49) class-definition  ::= 
+[{member-method}] 
+[declaration-of-fields] 
+[declaration-of-friends] 
+
+(50)  declaration-of-an-exception ::= 
+**exception**** **exception-name 
+**inherits**** **exception-name 
+
+(51) declaration-of-an-enumeration  ::= 
+**enumeration**** **enumeration-name 
+**is**** **identifier {’,’  identifier} 
+[**end**** **[enumeration-name]]’;’ 
+
+(52)  incomplete-declaration-of-a-non-generic-class ::= 
+[**deferred**] **class**** **class-name’;’ 
+
+(53)  incomplete-declaration-of-a-generic-class ::= 
+[**deferred**] **generic class**** **class-name {’,’ class-name}’;’ 
+
+(54)  declaration-of-a-non-generic-class ::= 
+[**deferred**] **class**** **class-name 
+[**inherits**** **class-name 
+[**uses**** **data-type {’,’ data-type}] 
+[**raises**** **exception-name {’,’ exception-name}] 
+**   is **definition-of-a-class 
+**end **[class-name]’;’ 
+
+(55) type-constraint ::= 
+**any**** **| class-name  [’(’data-type {’,’ data-type}’)’] 
+
+(56) generic-type ::= 
+identifier **as**** **type-constraint 
+@section occt_1819379591_2139552861 Appendix B.
+
+
+
+@subsection occt_1819379591_213955286151   Comparison  of CDL &amp; C++ Syntax for Data Types manipulated by Handle and by Value
+
+    <table>
+       <tr>
+               <td>
+               
+               </td>
+       </tr>
+       <tr>
+               <td>
+               
+               </td>
+               <td>
+               ![](/devs_guide/cdl/images/cdl_image012.jpg)
+               </td>
+       </tr>
+</table>       
+
diff --git a/dox/dev_guides/cdl/images/cdl_image001.jpg b/dox/dev_guides/cdl/images/cdl_image001.jpg
new file mode 100644 (file)
index 0000000..0e782ca
Binary files /dev/null and b/dox/dev_guides/cdl/images/cdl_image001.jpg differ
diff --git a/dox/dev_guides/cdl/images/cdl_image002.jpg b/dox/dev_guides/cdl/images/cdl_image002.jpg
new file mode 100644 (file)
index 0000000..5f87a33
Binary files /dev/null and b/dox/dev_guides/cdl/images/cdl_image002.jpg differ
diff --git a/dox/dev_guides/cdl/images/cdl_image003.jpg b/dox/dev_guides/cdl/images/cdl_image003.jpg
new file mode 100644 (file)
index 0000000..15de92c
Binary files /dev/null and b/dox/dev_guides/cdl/images/cdl_image003.jpg differ
diff --git a/dox/dev_guides/cdl/images/cdl_image004.jpg b/dox/dev_guides/cdl/images/cdl_image004.jpg
new file mode 100644 (file)
index 0000000..87a293d
Binary files /dev/null and b/dox/dev_guides/cdl/images/cdl_image004.jpg differ
diff --git a/dox/dev_guides/cdl/images/cdl_image005.jpg b/dox/dev_guides/cdl/images/cdl_image005.jpg
new file mode 100644 (file)
index 0000000..04f85ee
Binary files /dev/null and b/dox/dev_guides/cdl/images/cdl_image005.jpg differ
diff --git a/dox/dev_guides/cdl/images/cdl_image006.jpg b/dox/dev_guides/cdl/images/cdl_image006.jpg
new file mode 100644 (file)
index 0000000..7573c61
Binary files /dev/null and b/dox/dev_guides/cdl/images/cdl_image006.jpg differ
diff --git a/dox/dev_guides/cdl/images/cdl_image007.jpg b/dox/dev_guides/cdl/images/cdl_image007.jpg
new file mode 100644 (file)
index 0000000..370ed26
Binary files /dev/null and b/dox/dev_guides/cdl/images/cdl_image007.jpg differ
diff --git a/dox/dev_guides/cdl/images/cdl_image008.jpg b/dox/dev_guides/cdl/images/cdl_image008.jpg
new file mode 100644 (file)
index 0000000..6648804
Binary files /dev/null and b/dox/dev_guides/cdl/images/cdl_image008.jpg differ
diff --git a/dox/dev_guides/cdl/images/cdl_image009.jpg b/dox/dev_guides/cdl/images/cdl_image009.jpg
new file mode 100644 (file)
index 0000000..b07ee6c
Binary files /dev/null and b/dox/dev_guides/cdl/images/cdl_image009.jpg differ
diff --git a/dox/dev_guides/cdl/images/cdl_image010.jpg b/dox/dev_guides/cdl/images/cdl_image010.jpg
new file mode 100644 (file)
index 0000000..b471c0a
Binary files /dev/null and b/dox/dev_guides/cdl/images/cdl_image010.jpg differ
diff --git a/dox/dev_guides/cdl/images/cdl_image011.jpg b/dox/dev_guides/cdl/images/cdl_image011.jpg
new file mode 100644 (file)
index 0000000..d67dff7
Binary files /dev/null and b/dox/dev_guides/cdl/images/cdl_image011.jpg differ
diff --git a/dox/dev_guides/cdl/images/cdl_image012.jpg b/dox/dev_guides/cdl/images/cdl_image012.jpg
new file mode 100644 (file)
index 0000000..e60fdd6
Binary files /dev/null and b/dox/dev_guides/cdl/images/cdl_image012.jpg differ
diff --git a/dox/dev_guides/dev_guides.md b/dox/dev_guides/dev_guides.md
new file mode 100644 (file)
index 0000000..e72a1dc
--- /dev/null
@@ -0,0 +1,102 @@
+ Developer Guides {#dev_guides}
+================
+
+@section OCCT_OVW_SECTION1 Source Repository
+
+This directory contains sources of Open CASCADE Technology (OCCT), a collection
+of C++ libraries providing services for 3D surface and solid modeling, CAD data
+exchange, and visualization. OCCT can be best applied in development of
+software dealing with 3D modeling (CAD), manufacturing / measuring (CAM) or
+numerical simulation (CAE).
+
+The OCCT code is subject to the Open CASCADE Technology Public License Version
+6.6 (the "License"). You may not use the content of the relevant files except in
+compliance with the License. Please see the LICENSE file or obtain a copy of the
+License at http://www.opencascade.org and read it completely before using this
+software.
+
+@section OCCT_OVW_SECTION11 Building OCCT Libraries
+
+The source package of the Open CASCADE Technology including the source files of samples
+and tools and the set of building procedures is available for self-dependent preparation
+binary files on UNIX and Windows platforms. 
+
+In order to build OCCT libraries from these sources for use in your program, 
+you need to:
+
+1. Install the required third-party libraries.
+
+   Follow the instructions provided in the documents titled "Building 3rd party
+   products for OCCT" on http://dev.opencascade.org/?q=home/resources for
+   choice of the needed libraries, their installation and building.
+
+2. If you use OCCT sources from Git repository or do come changes affecting
+   CDL files or dependencies of OCCT toolkit, update header files generated 
+   from CDL, and regenerate build scripts for your environment using WOK.
+   See \subpage dev_guides__wok "WOK" for details.
+
+   Skip to step 3 if you use complete source package (e.g. official OCCT 
+   release) without changes in CDL.
+
+3. Build using your preferred build tool.
+   - \subpage dev_guides__building__automake "Building on Linux with Autotools"
+   - \subpage dev_guides__building__cmake "Building with CMake (cross-platform)"
+   - \subpage dev_guides__building__code_blocks "Building on Mac OS X with Code::Blocks"
+   - \subpage dev_guides__building__msvc "Building on Windows with MS Visual Studio 2005-2012"
+   - \subpage dev_guides__building__xcode "Building on Mac OS X with Xcode"
+
+The current version of OCCT can be consulted in the file src/Standard/Standard_Version.hxx
+
+@section OCCT_OVW_SECTION111 Automatic tests
+
+OCCT automatic testing system is integrated with @ref draw "DRAW Test Harness",
+a console application based on Tcl (a scripting language).
+All tests are run from DRAW command prompt (run **draw.bat** or 
+**draw.sh** to start it).
+
+Standard OCCT tests are located in subdirectory **tests** of the OCCT root 
+folder. This location is set as default at DRAW start (see environment variable 
+_CSF_TestScriptsPath_ defined in **src/DrawResources/DrawDefaults**).
+
+The tests are organized in three levels:
+- Group: a group of related test grids, usually testing a particular subset of OCCT functionality (e.g. *blend*). 
+- Grid: a set of test cases within a group, usually aimed at testing a particular aspect or mode of execution of the relevant functionality (e.g. *buildevol*).
+- Test case: a script implementing an individual test (e.g. *K4*).
+
+To run all tests, type command *testgrid*:
+
+    Draw[]\> testgrid
+
+For running only a group or a grid of tests, give additional arguments indicating the group and (if needed) the grid name:
+
+    Draw[]\> testgrid blend simple
+
+As the tests progress, the result of each test case is reported. 
+At the end of the log a summary of test cases is output, including the list of 
+detected regressions and improvements, if any.
+The tests are considered as non-regressive if only OK, BAD (i.e. known problem), 
+and SKIPPED (i.e. not executed, typically because of lack of a data file) 
+statuses are reported. 
+
+To run a single test, type command 'test' followed by the names of 
+group, grid, and test case. 
+
+    Draw[1]\> test blend simple A1
+    CASE blend simple A1: OK
+
+To see intermediate commands and their output during the test execution, 
+add one more argument '-echo' at the end of the command line, or type 'dlog get'
+after test completion. 
+
+For more information consult \subpage dev_guides__tests "Automatic Testing System"
+
+@section OCCT_OVW_SECTION1112 CDL Overview
+
+CDL is the component definition language of the Open CASCADE Technology (OCCT) programming platform. 
+Some components, which CDL allows you to create, are specific to OCCT application architecture. 
+
+For more information consult \subpage dev_guides__cdl "Component Definition Language Developer's Guide"
+
+@section OCCT_OVW_SECTION1113 Documentation Overview
+
+\subpage dev_guides__documentation "Documentation Developer's Guide"
diff --git a/dox/dev_guides/documentation/documentation.md b/dox/dev_guides/documentation/documentation.md
new file mode 100644 (file)
index 0000000..d8965dd
--- /dev/null
@@ -0,0 +1,531 @@
+ Documentation  {#dev_guides__documentation}
+=================
+
+@section  OCCT_DM_SECTION_1 Introduction
+
+This document provides practical guidenes for generation and editing of OCCT user documentation.
+
+@section  OCCT_DM_SECTION_2 Prerequisites
+
+<b>Tcl/Tk</b>
+The lates version: http://www.tcl.tk/software/tcltk/download.html
+
+<b>Doxygen</b> ( >= 1.8.4 ) 
+The latest version: http://www.stack.nl/~dimitri/doxygen/download.html
+
+<b>MathJax</b> (used for rendering math formulas in browser). Download it for local installation or use the MathJax Content Delivery Network.  \(read 
+@htmlonly <a href="#OCCT_DM_SECTION_A_9">Formulas</a> @endhtmlonly paragraph for more detailed description\). 
+The latest version: http://www.mathjax.org/download/
+
+<b>MiKTeX</b> or equivalent tool (used for PDF document creation)
+Latest version: http://miktex.org/download
+
+@section OCCT_DM_SECTION_2_1 Documentation Generation
+
+Run gendoc.bat from OCCT directory to generate all articles are defined in FILES.txt:
+
+gendoc.bat options:
+
+  * -html                : To generate HTML files (cannot be used with -pdf);
+  * -pdf                 : To generate PDF files (cannot be used with -html);
+  * -m=<modules_list>    : Specifies list of articles to generate. If it is not specified, all files, mentioned in FILES.txt are processed;
+  * -l=<document_name>   : Specifies the article caption for a single document;
+  * -h                   : Prints help message;
+  * -v                   : Specifies the Verbose mode (info on all script actions is shown).
+
+If you run the command without arguments (like example above) it will generate HTML documentation 
+for all articles are defined into FILES.txt.
+
+**Note**: the generation process generates PDF files for each article, 
+but in html case it generates common Html page with references to the ones.
+
+For generation of specific article you need:
+  * have it's name with relative path (from \%OCCDIR\%/dox/ to the file) contained in FILES.txt 
+  (is located into \%OCCDIR\%/dox/ directory).
+
+@verbatim
+devs_guid/documentation/documentation.md
+@endverbatim
+
+where documentation .md is name of article and devs_guid/documentation/ is relative path of it
+
+  * use this name with -m option in the generation process:
+
+@verbatim
+% gen.bat -html -m=devs_guid/documentation/documentation.md
+@endverbatim
+
+Multiple files are separated with comma:
+
+@verbatim
+% gen.bat -html -m=MD_FILE_1,MD_FILE_2
+@endverbatim
+
+To sepcify a article name with -l option, use tcl list to prevent whitespaces incorrect interpretation:
+
+@verbatim
+% gen.bat -pdf -m=MD_FILE_1 -l=[list MD File 1 Label]
+@endverbatim
+
+@section  OCCT_DM_SECTION_3 Documentation Conventions
+
+This section contains information about conventions in the field of OCCT documentation file format, 
+structure of documentation directories, etc.
+
+@subsection  OCCT_DM_SECTION_3_1 File Format
+
+It is proposed to use MarkDown file format for easy maintainance of generic text documents. 
+The MarkDown files have a "*.md" extension and are based on rules desribed in 
+@htmlonly <a href="#OCCT_DM_SECTION_A">Document Syntax</a> @endhtmlonly section.
+
+@subsection  OCCT_DM_SECTION_3_2 Directory Structure
+
+![](/devs_guide/documentation/images/documentation_image001.png)
+
+Every separate article has own folder if images are used in it. These images 
+are stored into "images" subfolder.
+
+If you want to use the same image for several articles, you can place the one into "dox/resources" folder.
+
+**Note**: Every article can use any image that is used by others articles. To avoid incorrect image
+displaying, use relative path to the image (starting from dox folder). For instance
+@verbatim
+![](/devs_guide/snv/images/snv_image001.svg)
+@endverbatim
+
+Result of generation of the documentation is:
+
+%OCCT_DIR% / doc         - a folder for generated articles;
+            * html/             - a directory for generated HTML pages;
+            * pdf/              - a directory for generated PDF files.
+
+@section  OCCT_DM_SECTION_4 Adding a New Article
+
+ - Place a new article into folder that is chosen taking into account the place of the article 
+at the hierarchy of the documentation. For instance the article about "using SVN working with OCCT 
+source code" (svn.md - the file of the article) might be placed into /dox/devs_guide/ . If the article has images then you may create
+the own folder of the article and subfolder in it for images. For instance
+*/dox/devs_guide/svn/ - for svn.md file
+*/dox/devs_guide/svn/images/ - for images
+
+ - Update dox/FILES.txt to add relative path to svn.md. For instance
+@verbatim
+devs_guide/snv/svn.md
+@endverbatim
+
+**Note**: the place of the relative path to an article is connected with the place
+into treeview of html version.
+
+
+Note, that you should specify a file tag, not the document name. 
+See <a href="#OCCT_DM_SECTION_A_1">Header section</a> for details.
+
+@section  OCCT_DOC_SECTION_5 Additional Resources
+
+More information about OCCT can be found at http://www.opencascade.org
+
+The information on formula syntax can be found at: 
+http://en.wikipedia.org/wiki/Help:Displaying_a_formula
+
+More information on MarkDown and Doxygen syntax can be found at:
+http://www.stack.nl/~dimitri/doxygen/manual
+
+
+@section  OCCT_DM_SECTION_A Appendix 1: Document Syntax
+
+Each OCCT document file in *.md format has a simple structure.
+It can contain: 
+
+| Content type      | Obligation            |
+| :---------------- | :-------------------: |
+| Header            | M                     |
+| Footer            | M                     |
+| Plain text        | O                     |
+| List              | O                     |
+| Table             | O                     |
+| Code              | O                     |
+| Formula           | O                     |
+| Image             | O                     |
+| Page numbers      | M (auto generation)   |
+| Table of contents | M (auto generation)   |
+
+The legend:
+
+  * M is for Mandatory
+  * O is for Optional
+
+@subsection  OCCT_DM_SECTION_A_1 Text Caption (a header)
+
+headings of different levels can be specified with the following code:
+
+@verbatim
+Header 1  {#header1}
+=======
+@endverbatim
+
+  to get
+
+ Header 1
+=========
+
+  and with the following code:
+
+@verbatim
+Header 2 {#header2}
+--------
+@endverbatim
+
+to get 
+
+Header 2
+---------
+
+Where a word in curly braces is a MarkDown-style reference, which can be used in table of contents.
+If you would like to have the table of contents, it is recommended to use \@section, 
+\@subsection and \@subsubsection pages instead of MarkDown headers as follows:
+
+@verbatim
+  @section Section_Name Section Header
+  @subsection SubSection_Name SubSection Header
+  @subsubsection SubSubSection_Name SubSubSection Header
+@endverbatim
+
+@subsection OCCT_DM_SECTION_A_2 Plain Text
+
+Plain text is a text in a notepad-like format. To insert special symbols, 
+like \< , \> or \\, prepend them with \\ character: \\\<, \\\>, \\\\ 
+To emphasize some words, write one pair of asterisks ( * ) or underscores ( _ ) across the word 
+to make it *italic* and two pairs of these symbols to make a word **Bold**.
+
+@subsection OCCT_DM_SECTION_A_3 Lists
+
+To create a bulleted list, start each line with a hyphen or an asterisk, 
+followed by a space. List items can be nested. This code:
+
+@verbatim
+  * Bullet 1
+  * Bullet 2
+    * Bullet 2a
+    * Bullet 2b
+  * Bullet 3
+@endverbatim
+
+  produces this list:
+
+  * Bullet 1
+  * Bullet 2
+    * Bullet 2a
+    * Bullet 2b
+  * Bullet 3  
+
+To create a numbered list, start each line with number and a period, then a space. Thus this code 
+
+@verbatim
+  1. ListItem_1
+  2. ListItem_2
+  3. ListItem_3
+@endverbatim
+
+  produces this list:
+
+  1. ListItem_1
+  2. ListItem_2
+  3. ListItem_3
+
+It is recommended to indent lists with 2 spaces.
+
+@subsection  OCCT_DM_SECTION_A_4 Tables
+
+A table consists of a header line, a separator line, and at least one row line. 
+Table columns are separated by the pipe (|) character. The following example: 
+
+@verbatim
+First Header  | Second Header
+------------- | -------------
+Content Cell  | Content Cell 
+Content Cell  | Content Cell 
+@endverbatim
+
+  will produce the following table:
+
+First Header | Second Header
+------------ | -------------
+Content Cell | Content Cell 
+Content Cell | Content Cell 
+
+Column alignment can be controlled via one or two colons at the header separator line: 
+
+@verbatim
+| Right | Center | Left  |
+| ----: | :----: | :---- |
+| 10    | 10     | 10    |
+| 1000  | 1000   | 1000  |
+@endverbatim
+
+which will looks as follows:
+
+| Right | Center | Left  |
+| ----: | :----: | :---- |
+| 10    | 10     | 10    |
+| 1000  | 1000   | 1000  |
+
+@subsection  OCCT_DM_SECTION_A_5 Code Blocks
+
+It is recommended to indent a code lines with 4 spaces.
+A fenced code block does not require indentation, and is defined by a pair of "fence lines". 
+Such line consists of 3 or more tilde (~) characters on a line. 
+The end of the block should have the same number of tildes. Here is an example:
+
+~~~~~~~~~~~~~~~~~~~~~~~
+  a one-line code block
+~~~~~~~~~~~~~~~~~~~~~~~
+
+By default the output is the same as for a normal code block.
+To highlight the code, the developer has to indicate the typical file extension, 
+which corresponds to the programming language, after the opening fence. 
+For highlighting according to the C++ language, for instance,  write the following code (the curly braces and dot are optional): 
+
+@verbatim
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+    int func(int a,int b) { return a*b; }
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+@endverbatim
+
+which will produce:
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} 
+    int func(int a,int b) { return a*b; }
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Verbatim content can be written by using framing \@verbatim \@endverbatim . For instance
+
+@verbatim
+  verbatim text
+@endverbatim
+
+@subsection  OCCT_DM_SECTION_A_6 References
+
+To insert a reference to a website, it is proposed to write a URL. For example: http://en.wikipedia.org
+To insert a reference to another part of the same document, the developer can write:
+
+@verbatim
+  @htmlonly 
+    <a href="#OCCT_DOC_SECTION_5">Doxygen Configuration file</a>
+  @endhtmlonly 
+@endverbatim
+
+to get a link to paragraph : @htmlonly <a href="#OCCT_DOC_SECTION_5">Doxygen configuration</a> @endhtmlonly 
+
+@subsection  OCCT_DM_SECTION_A_7 Images
+
+To insert image into document the developer can write the following code(in Doxygen-style):
+@verbatim
+![alt-caption](relative/path/to/image/image001.svg "Image Caption")
+@endverbatim
+
+This code tells Doxygen to insert a picture right in the place this code was written. Like this:
+@verbatim
+![](/resources/occt_logo.png "OCCT logo")
+@endverbatim
+
+![](/resources/occt_logo.png "OCCT logo")
+@subsection  OCCT_DM_SECTION_A_8 Table Of Contents
+
+To get the table of contents at the beginning of the document, write \@tableofcontents tag. 
+But it is not needed now because TreeView option for HTML is used.
+The TOC in the PDF document will be generated automatically.
+
+@subsection  OCCT_DM_SECTION_A_9 Formulas
+
+Formulas within documents will be generated using MathJax tool.
+
+A developer has to specify these parameters in Doxyfile to enable support of MathJax in Doxygen:
+
+    USE_MATHJAX         = YES
+    MATHJAX_FORMAT      = HTML-CSS
+    MATHJAX_RELPATH     = http://cdn.mathjax.org/mathjax/latest
+    MATHJAX_EXTENSIONS  = TeX/AMSmath TeX/AMSsymbols
+
+To use MathJax tool with the HTML page, it's \<head\> block has to contain 
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.html}
+    <script type="text/x-mathjax-config">
+      MathJax.Hub.Config({
+        tex2jax: {inlineMath: [["$","$"],["\\(","\\)"]]},
+        displayAlign: "left"
+      });
+    </script>
+
+    <script type="text/javascript"
+      src="http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML">
+    </script>
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+First script configures MathJax to understand separator types and to left allign formulas. 
+The second script inserts reference to MathJax tool. 
+This tool will always be used when the HTML output will be shown.
+
+Equations can be written by several ways:
+
+1.Unnumbered displayed formulas that are centered on a separate line. 
+These formulas should be put between \@f\[ and \@f\] tags. An example: 
+
+@verbatim
+@f$[
+    |I_2|=\left| \int_{0}^T \psi(t)
+            \left\{ 
+                u(a,t)-
+                \int_{\gamma(t)}^a 
+                \frac{d\theta}{k(\theta,t)}
+                \int_{a}^\theta c(\xi)u_t(\xi,t)\,d\xi
+            \right\} dt
+        \right|
+@f$]
+@endverbatim
+
+gives the following result:
+
+   @f$
+       |I_2|=\left| \int_{0}^T \psi(t)
+               \left\{ 
+                   u(a,t)-
+                   \int_{\gamma(t)}^a 
+                   \frac{d\theta}{k(\theta,t)}
+                   \int_{a}^\theta c(\xi)u_t(\xi,t)\,d\xi
+               \right\} dt
+           \right|
+   @f$
+   
+2.Formulas can also be put between @verbatim \begin{align} @endverbatim and @verbatim \end{align} @endverbatim tags. An example: 
+
+@verbatim
+  \begin{align}
+  \dot{x} & = \sigma(y-x) \\
+  \dot{y} & = \rho x - y - xz \\
+  \dot{z} & = -\beta z + xy
+  \end{align}
+@endverbatim
+
+  gives the following result:
+@latexonly
+  \begin{align}
+  \dot{x} & = \sigma(y-x) \\
+  \dot{y} & = \rho x - y - xz \\
+  \dot{z} & = -\beta z + xy
+  \end{align}
+@endlatexonly
+
+@htmlonly
+  \begin{align}
+  \dot{x} & = \sigma(y-x) \\
+  \dot{y} & = \rho x - y - xz \\
+  \dot{z} & = -\beta z + xy
+  \end{align}
+@endhtmlonly
+
+3.Inline formulas can be specified using this syntax:
+
+@verbatim
+  @f$ \sqrt{3x-1}+(1+x)^2 @f$
+@endverbatim
+
+  that leads to the following result: @f$ \sqrt{3x-1}+(1+x)^2 @f$
+  
+@section  OCCT_DM_SECTION_B Appendix 2: Doxygen Configuration
+
+@subsection OCCT_DM_SECTION_B_1 Doxygen Configuration File
+
+To generate documentation from "source" *.md files a developer can use file OCCT.doxyfile, 
+which is located in /docs directory of OCCT (more information can be found at @htmlonly 
+<a href="#OCCT_DM_SECTION_X_X_X">Directory Structure</a> @endhtmlonly paragraph)
+or create his own configuration file, called "Doxyfile". The configuration file may look as follows: 
+
+@verbatim
+  DOXYFILE_ENCODING      = UTF-8
+  PROJECT_NAME           = "OCCT User's Guides"
+  PROJECT_NUMBER         = 1.0.1
+  PROJECT_LOGO           = "D:/OS/OCCT/docs/OCCT_logo.png"
+  OUTPUT_LANGUAGE        = English
+  TAB_SIZE               = 4
+  MARKDOWN_SUPPORT       = YES
+  AUTOLINK_SUPPORT       = NO
+  SHOW_FILES             = NO
+  WARNINGS               = YES
+  WARN_IF_UNDOCUMENTED   = YES
+  WARN_IF_DOC_ERROR      = YES
+  WARN_NO_PARAMDOC       = NO
+  WARN_FORMAT            = "$file:$line: $text"
+  INPUT                  = "D:/OS/OCCT/docs/"
+  INPUT_ENCODING         = UTF-8
+  FILE_PATTERNS          = *.md
+  RECURSIVE              = YES
+  IMAGE_PATH             = tmp
+  GENERATE_HTML          = YES
+  SEARCHENGINE           = NO
+  HTML_OUTPUT            = html
+  HTML_FILE_EXTENSION    = .html
+  HTML_HEADER            = "static/header.html"
+  HTML_FOOTER            = "static/footer.html"
+  HTML_STYLESHEET        = "static/general.css"
+  HTML_EXTRA_STYLESHEET  = "static/styles.css"
+  HTML_COLORSTYLE_HUE    = 220
+  HTML_COLORSTYLE_SAT    = 100
+  HTML_COLORSTYLE_GAMMA  = 80
+  HTML_TIMESTAMP         = YES
+  HTML_DYNAMIC_SECTIONS  = NO
+  HTML_INDEX_NUM_ENTRIES = 100
+  GENERATE_LATEX         = YES
+  GENERATE_RTF           = YES
+@endverbatim
+
+@subsection OCCT_DM_SECTION_B_2 Doxygen Output Customization
+
+The customization of the output files, produced by Doxygen, can be made by using different Doxyfile parameters,
+like HTML_COLORSTYLE_SAT, which specifies one of HSV color component of HTML page header, and also by using DoxygenLayout xml file.
+A developer can use default file from /docs directory or generate his own with doxygen -l command. It may looks as follows:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.xml}
+<doxygenlayout version="1.0">
+  <!-- Generated by doxygen 1.8.3.1 -->
+  <!-- Navigation index tabs for HTML output -->
+  <navindex>
+    <tab type="mainpage" visible="yes" title="Introduction"/>
+    <tab type="pages" visible="yes" title="Documents" intro=
+    "This section contains links to all OCCT documents that are available at the moment"/>
+    <tab type="modules" visible="no" title="" intro=""/>
+    <tab type="namespaces" visible="no" title="">
+      <tab type="namespacelist" visible="no" title="" intro=""/>
+      <tab type="namespacemembers" visible="no" title="" intro=""/>
+    </tab>
+    <tab type="classes" visible="no" title="">
+      <tab type="classlist" visible="no" title="" intro=""/>
+      <tab type="classindex" visible="$ALPHABETICAL_INDEX" title=""/> 
+      <tab type="hierarchy" visible="no" title="" intro=""/>
+      <tab type="classmembers" visible="no" title="" intro=""/>
+    </tab>
+    <tab type="files" visible="yes" title="Files">
+      <tab type="filelist" visible="yes" title="" intro=""/>
+      <tab type="globals" visible="yes" title="" intro=""/>
+    </tab>
+    <tab type="examples" visible="no" title="" intro=""/>  
+  </navindex>
+    ...
+</doxygenlayout>
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The tag \<tab\> specifies tabs which appear at the head of each html page. For the OCCT user documentation
+ "mainpage" and "pages" tabs are usually needed and their visible parameter should always be "yes". 
+The visibility of other tabs should be set to "no".
+
+Developers can find more information about Doxygen configuration in the help file 
+or at http://www.stack.nl/~dimitri/doxygen/manual/
+
+@subsection OCCT_DM_SECTION_B_3 Doxywizard Usage
+
+The easiest way of applying and modification of Doxyfile is to use a Doxywizard application, 
+which is usually a part of the Doxygen tool. To apply a configuration file, the developer should 
+select "Open..." item of the File menu or press Ctrl + O. Modification of Doxyfile can be made
+using "Wizard" or "Expert" tabs of Doxywizard application. 
+
+Developers can find more information about Doxywizard usage in the help file or at 
+http://www.stack.nl/~dimitri/doxygen/manual/doxywizard_usage.html.
diff --git a/dox/dev_guides/documentation/images/documentation_image001.png b/dox/dev_guides/documentation/images/documentation_image001.png
new file mode 100644 (file)
index 0000000..770587e
Binary files /dev/null and b/dox/dev_guides/documentation/images/documentation_image001.png differ
diff --git a/dox/dev_guides/tests/images/tests_image001.png b/dox/dev_guides/tests/images/tests_image001.png
new file mode 100644 (file)
index 0000000..e571732
Binary files /dev/null and b/dox/dev_guides/tests/images/tests_image001.png differ
diff --git a/dox/dev_guides/tests/tests.md b/dox/dev_guides/tests/tests.md
new file mode 100644 (file)
index 0000000..731e2a6
--- /dev/null
@@ -0,0 +1,593 @@
+ Automated Testing System  {#dev_guides__tests}
+======================================
+
+@section testmanual_1 Introduction
+
+This document provides overview and practical guidelines for work with OCCT automatic testing system.
+Reading this section *Introduction* should be sufficient for OCCT developers to use the test system 
+to control non-regression of the modifications they implement in OCCT. Other sections provide 
+more in-depth description of the test system, required for modifying the tests and adding new test cases. 
+
+@subsection testmanual_1_1 Basic Information
+
+OCCT automatic testing system is organized around DRAW Test Harness [1], 
+a console application based on Tcl (a scripting language) interpreter extended by OCCT-related commands.
+Standard OCCT tests are included with OCCT sources and are located in subdirectory *tests*
+ of the OCCT root folder. Other test folders can be included in the scope of the test system, 
+ e.g. for testing applications based on OCCT.
+Logically the tests are organized in three levels:
+
+  * Group: group of related test grids, usually relating to some part of OCCT functionality (e.g. blend)
+  * Grid: set of test cases within a group, usually aimed at testing some particular aspect or mode of execution of the relevant functionality (e.g. buildevol)
+  * Test case: script implementing individual test (e.g. K4)
+
+Some tests involve data files (typically CAD models) which are located separately
+ and are not included with OCCT code. The archive with publicly available 
+ test data files should be downloaded and installed independently on OCCT code from dev.opencascade.org.
+
+@subsection testmanual_1_2 Intended Use of Automatic Tests
+
+Each modification made in OCCT code must be checked for non-regression 
+by running the whole set of tests. The developer who does the modification 
+is responsible for running and ensuring non-regression on the tests that are available to him.
+Note that many tests are based on data files that are confidential and thus available only at OPEN CASCADE. 
+Thus official certification testing of the changes before integration to master branch 
+of official OCCT Git repository (and finally to the official release) is performed by OPEN CASCADE in any case.
+
+Each new non-trivial modification (improvement, bug fix, new feature) in OCCT 
+should be accompanied by a relevant test case suitable for verifying that modification. 
+This test case is to be added by developer who provides the modification.
+If a modification affects result of some test case(s), 
+either the modification should be corrected (if it causes regression) 
+or affected test cases should be updated to account for the modification. 
+
+The modifications made in the OCCT code and related test scripts 
+should be included in the same integration to master branch.
+
+@subsection testmanual_1_3 Quick Start
+
+@subsubsection testmanual_1_3_1 Setup
+
+Before running tests, make sure to define environment variable CSF_TestDataPath 
+pointing to the directory containing test data files. 
+(The publicly available data files can be downloaded 
+from http://dev.opencascade.org separately from OCCT code.) 
+The recommended way for that is adding a file *DrawInitAppli* 
+in the directory which is current at the moment of starting DRAWEXE (normally it is $CASROOT). 
+This file is evaluated automatically at the DRAW start. Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+set env(CSF_TestDataPath) d:/occt/tests_data
+return ;# this is to avoid an echo of the last command above in cout
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+All tests are run from DRAW command prompt, thus first run draw.tcl or draw.sh to start DRAW.
+
+@subsubsection testmanual_1_3_2 Running Tests
+
+To run all tests, type command *testgrid* followed by path 
+to the new directory where results will be saved. 
+It is recommended that this directory should be new or empty; 
+use option –overwrite to allow writing logs in existing non-empty directory. 
+
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+    Draw[]> testgrid d:/occt/results-2012-02-27
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If empty string is given as log directory name, the name will be generated automatically 
+using current date and time, prefixed by *results_*. Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+    Draw[]> testgrid {}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+For running only some group or a grid of tests, 
+give additional arguments indicating group and (if needed) grid. Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+    Draw[]> testgrid d:/occt/results-2012-02-28 blend simple
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+As the tests progress, the result of each test case is reported. 
+At the end of the log summary of test cases is output, 
+including list of detected regressions and improvements, if any. Example:
+
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+    Tests summary
+
+    CASE 3rdparty export A1: OK 
+    ...
+    CASE pipe standard B1: BAD (known problem)
+    CASE pipe standard C1: OK
+    No regressions 
+    Total cases: 208 BAD, 31 SKIPPED, 3 IMPROVEMENT, 1791 OK
+    Elapsed time: 1 Hours 14 Minutes 33.7384512019 Seconds
+    Detailed logs are saved in D:/occt/results_2012-06-04T0919
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The tests are considered as non-regressive if only OK, BAD (i.e. known problem), 
+and SKIPPED (i.e. not executed, e.g. because of lack of data file) statuses are reported. 
+See <a href="#testmanual_3_4">Grid’s *cases.list* file</a> chapter for details.
+
+The detailed logs of running tests are saved in the specified directory and its sub-directories. 
+Cumulative HTML report summary.html provides links to reports on each test case. 
+An additional report TESTS-summary.xml is output in JUnit-style XML format 
+that can be used for integration with Jenkins or other continuous integration system.
+Type *help testgrid* in DRAW prompt to get help on additional options supported by testgrid command.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+    Draw[3]> help testgrid
+    testgrid: Run all tests, or specified group, or one grid
+        Use: testgrid logdir [group [grid]] [options...]
+        Allowed options are:
+        -verbose {0-2}: verbose level, 0 by default, can be set to 1 or 2
+        -parallel N: run in parallel with up to N processes (default 0)
+        -refresh N: save summary logs every N seconds (default 60)
+        -overwrite: force writing logs in existing non-empty directory
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@subsubsection testmanual_1_3_3 Running Single Test
+
+To run single test, type command *test*’ followed by names of group, grid, and test case. 
+
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+    Draw[1]> test blend simple A1
+    CASE blend simple A1: OK
+    Draw[2]>
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Note that normally intermediate output of the script is not shown. 
+To see intermediate commands and their output, type command *decho on* 
+before running the test case. (Type ‘decho off’ to disable echoing when not needed.) 
+The detailed log of the test can also be obtained after the test execution by command *dlog get*.
+
+@section testmanual_2 Organization of Test Scripts
+
+@subsection testmanual_2_1 General Layout
+
+Standard OCCT tests are located in subdirectory tests of the OCCT root folder ($CASROOT).
+Additional test folders can be added to the test system 
+by defining environment variable CSF_TestScriptsPath. 
+This should be list of paths separated by semicolons (*;*) on Windows 
+or colons (*:*) on Linux or Mac. Upon DRAW launch, 
+path to tests sub-folder of OCCT is added at the end of this variable automatically.
+Each test folder is expected to contain:
+
+  * Optional file parse.rules defining patterns for interpretation of test results, common for all groups in this folder
+  * One or several test group directories. 
+
+Each group directory contains:
+
+  * File grids.list that identifies this test group and defines list of test grids in it.
+  * Test grids (sub-directories), each containing set of scripts for test cases, and optional files cases.list, parse.rules, begin, and end.
+  * Optional sub-directory data
+  * Optional file parse.rules
+  * Optional files begin and end
+
+By convention, names of test groups, grids, and cases should contain no spaces and be lowercase. 
+Names begin, end, data, parse.rules, grids.list, cases.list are reserved. 
+General layout of test scripts is shown on Figure 1.
+
+![](/devs_guide/tests/images/tests_image001.png "")
+
+Figure 1. Layout of tests folder
+
+@subsection testmanual_2_2 Test Groups
+
+@subsubsection testmanual_2_2_1 Group Names
+
+Test folder usually contains several directories representing test groups (Group 1, Group N). 
+Each directory contains test grids for certain OCCT functionality. 
+The name of directory corresponds to this functionality.
+Example:
+
+@verbatim
+  caf
+  mesh
+  offset
+@endverbatim
+
+@subsubsection testmanual_2_2_2 Group's *grids.list* File
+
+The test group must contain file *grids.list* file 
+which defines ordered list of grids in this group in the following format:
+
+~~~~~~~~~~~~~~~~~
+001 gridname1
+002 gridname2
+...
+NNN gridnameN
+~~~~~~~~~~~~~~~~~
+
+Example:
+
+~~~~~~~~~~~~~~~~~
+    001 basic
+    002 advanced
+~~~~~~~~~~~~~~~~~
+
+@subsubsection testmanual_2_2_3 Group's *begin* File
+
+The file *begin* is a Tcl script. It is executed before every test in current group. 
+Usually it loads necessary Draw commands, sets common parameters and defines 
+additional Tcl functions used in test scripts.
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+    pload TOPTEST ;# load topological command
+    set cpulimit 300 ;# set maximum time allowed for script execution
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@subsubsection testmanual_2_2_4 Group's *end* File
+
+The file end is a TCL script. It is executed after every test in current group. 
+Usually it checks the results of script work, makes a snap-shot 
+of the viewer and writes *TEST COMPLETED* to the output.
+Note: *TEST COMPLETED* string should be presented in output 
+in order to signal that test is finished without crash. 
+See <a href="#testmanual_3">Creation And Modification Of Tests</a> chapter for more information.
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+    if { [isdraw result] } {
+        checkshape result
+    } else {
+        puts *Error: The result shape can not be built*
+    }
+    puts *TEST COMPLETED*
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@subsubsection testmanual_2_2_5 Group’s *parse.rules* File
+
+The test group may contain *parse.rules* file. 
+This file defines patterns used for analysis of the test execution log 
+and deciding the status of the test run. 
+Each line in the file should specify a status (single word), 
+followed by a regular expression delimited by slashes (*/*) 
+that will be matched against lines in the test output log to check if it corresponds to this status.
+The regular expressions support subset of the Perl re syntax.
+The rest of the line can contain a comment message 
+which will be added to the test report when this status is detected.
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+    FAILED /\b[Ee]xception\b/ exception
+    FAILED /\bError\b/ error
+    SKIPPED /Cannot open file for reading/ data file is missing
+    SKIPPED /Could not read file .*, abandon/ data file is missing
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Lines starting with a *#* character and blank lines are ignored to allow comments and spacing.
+See <a href="#testmanual_2_3_4">Interpretation of test results</a> chapter for details.
+
+If a line matches several rules, the first one applies. 
+Rules defined in the grid are checked first, then rules in group, 
+then rules in the test root directory. This allows defining some rules on the grid level 
+with status IGNORE to ignore messages that would otherwise be treated as errors due to the group level rules.
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+    FAILED /\bFaulty\b/ bad shape
+    IGNORE /^Error [23]d = [\d.-]+/ debug output of blend command
+    IGNORE /^Tcl Exception: tolerance ang : [\d.-]+/ blend failure
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@subsection testmanual_2_3 Test Grids
+
+@subsubsection testmanual_2_3_1 Grid Names
+
+Group folder can have several sub-directories (Grid 1… Grid N) defining test grids. 
+Each test grid directory contains a set of related test cases. 
+The name of directory should correspond to its contents.
+
+Example:
+
+caf
+   basic
+   bugs
+   presentation
+
+Where **caf** is the name of test group and *basic*, *bugs*, *presentation*, etc are the names of grids.
+
+@subsubsection testmanual_2_3_2 Grid’s *begin* File
+
+The file *begin* is a TCL script. It is executed before every test in current grid. 
+Usually it sets variables specific for the current grid.
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+    set command bopfuse ;# command tested in this grid
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@subsubsection testmanual_2_3_3 Grid’s *end* File
+
+The file *end* is a TCL script. It is executed after every test in current grid. 
+Usually it executes specific sequence of commands common for all tests in the grid.
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+    vdump $logdir/${casename}.gif ;# makes a snap-shot of AIS viewer
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@subsubsection testmanual_2_3_4 Grid’s *cases.list* File
+
+The grid directory can contain an optional file cases.list 
+defining alternative location of the test cases. 
+This file should contain singe line defining the relative path to collection of test cases.
+
+Example:
+
+../data/simple
+
+This option is used for creation of several grids of tests with the same data files 
+and operations but performed with differing parameters. 
+The common scripts are usually located place in common 
+subdirectory of the test group (data/simple as in example).
+If cases.list file exists then grid directory should not contain any test cases. 
+The specific parameters and pre- and post-processing commands 
+for the tests execution in this grid should be defined in the begin and end files.
+
+@subsection testmanual_2_4 Test Cases
+
+The test case is TCL script which performs some operations using DRAW commands 
+and produces meaningful messages that can be used to check the result for being valid.
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+    pcylinder c1 10 20 ;# create first cylinder
+    pcylinder c2 5 20 ;# create second cylinder
+    ttranslate c2 5 0 10 ;# translate second cylinder to x,y,z
+    bsection result c1 c2 ;# create a section of two cylinders
+    checksection result ;# will output error message if result is bad
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The test case can have any name (except reserved names begin, end, data, cases.list, parse.rules). 
+For systematic grids it is usually a capital English letter followed by a number.
+
+Example:
+
+@verbatim
+    A1
+    A2
+    B1
+    B2
+@endverbatim
+
+Such naming facilitates compact representation of results 
+of tests execution in tabular format within HTML reports.
+
+@subsection testmanual_2_5 Directory *data*
+
+The test group may contain subdirectory data. 
+Usually it contains data files used in tests (BREP, IGES, STEP, etc.) 
+and / or test scripts shared by different test grids 
+(in subdirectories, see <a href="#testmanual_2_3_4">Grid’s *cases.list* file</a> chapter).
+
+@section testmanual_3 Creation And Modification Of Tests
+
+This section describes how to add new tests and update existing ones.
+
+@subsection testmanual_3_1 Choosing Group, Grid, and Test Case Name
+
+The new tests are usually added in context of processing some bugs. 
+Such tests in general should be added to group bugs, in the grid 
+corresponding to the affected OCCT functionality. 
+New grids can be added as necessary to contain tests on functionality not yet covered by existing test grids. 
+The test case name in the bugs group should be prefixed by ID 
+of the corresponding issue in Mantis (without leading zeroes). 
+It is recommended to add a suffix providing a hint on the situation being tested. 
+If more than one test is added for a bug, they should be distinguished by suffixes; 
+either meaningful or just ordinal numbers.
+
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+    12345_coaxial
+    12345_orthogonal_1
+    12345_orthogonal_2
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In the case if new test corresponds to functionality for which 
+specific group of tests exists (e.g. group mesh for BRepMesh issues), 
+this test can be added (or moved later by OCC team) to this group. 
+
+@subsection testmanual_3_2 Adding Data Files Required for a Test
+
+It is advisable that tests scripts should be made self-contained whenever possible, 
+so as to be usable in environments where data files are not available. 
+For that simple geometric objects and shapes can be created using DRAW commands in the test script itself.
+If test requires some data file, it should be put to subdirectory data of the test grid. 
+Note that when test is integrated to master branch, 
+OCC team can move data file to data files repository, 
+so as to keep OCCT sources repository clean from big data files.
+When preparing a test script, try to minimize size of involved data model. 
+For instance, if problem detected on a big shape can be reproduced on a single face 
+extracted from that shape, use only this face in the test.
+
+@subsection testmanual_3_3 Implementation of the Script
+
+Test should run commands necessary to perform the operations being tested, 
+in a clean DRAW session. This includes loading necessary functionality by *pload* command, 
+if this is not done by *begin* script. The messages produced by commands in standard output 
+should include identifiable messages on the discovered problems if any. 
+Usually the script represents a set of commands that a person would run interactively 
+to perform the operation and see its results, with additional comments to explain what happens.
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+    # Simple test of fusing box and sphere
+    box b 10 10 10 
+    sphere s 5
+    bfuse result b s
+    checkshape result
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Make sure that file parse.rules in the grid or group directory contains 
+regular expression to catch possible messages indicating failure of the test. 
+For instance, for catching errors reported by *checkshape* command 
+relevant grids define a rule to recognize its report by the word *Faulty*: FAILED /\bFaulty\b/ bad shape
+For the messages generated in the script the most natural way is to use the word *Error* in the message.
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+    set expected_length 11
+    if { [expr $actual_length - $expected_length] > 0.001 } {
+        puts *Error: The length of the edge should be $expected_length*
+    }
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+At the end, the test script should output *TEST COMPLETED* string 
+to mark successful completion of the script. 
+This is often done by the end script in the grid.
+When test script requires data file, use Tcl procedure *locate_data_file* 
+to get path to the data file, rather than explicit path. 
+This will allow easy move of the data file from OCCT repository 
+to the data files repository without a need to update test script.
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+    stepread [locate_data_file CAROSKI_COUPELLE.step] a *
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+When test needs to produce some snapshots or other artifacts, 
+use Tcl variable logdir as location where such files should be put. 
+Command *testgrid* sets this variable to the subdirectory of the results folder 
+corresponding to the grid. Command *test* sets it to $CASROOT/tmp unless it is already defined. 
+Use Tcl variable casename to prefix all the files produced by the test. 
+This variable is set to the name of the test case. 
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+    xwd $logdir/${casename}.gif
+    vdisplay result; vfit
+    vdump $logdir/${casename}-axo.gif
+    vfront; vfit
+    vdump $logdir/${casename}-front.gif
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+could produce:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+    A1.gif
+    A1-axo.gif
+    A1-front.gif
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@subsection testmanual_3_4 Interpretation of Test Results
+
+The result of the test is evaluated by checking its output against patterns 
+defined in the files parse.rules of the grid and group.
+The OCCT test system recognizes five statuses of the test execution:
+
+  * SKIPPED: reported if line matching SKIPPED pattern is found (prior to any FAILED pattern). This indicates that the test cannot be run in the current environment; most typical case is absence of the required data file.
+  * FAILED: reported if some line matching pattern with status FAILED is found (unless it is masked by preceding IGNORE pattern or a TODO statement, see below), or if message TEST COMPLETED is not found at the end. This indicates that test produces bad or unexpected result, and usually highlights a regression.
+  * BAD: reported if test script output contains one or several TODO statements and corresponding number of matching lines in the log. This indicates a known problem (see 3.5). The lines matching TODO statements are not checked against other patterns and thus will not cause a FAILED status.  
+  * IMPROVEMENT: reported if test script output contains TODO statement for which no corresponding line is found. This is possible indication of improvement (known problem disappeared).
+  * OK: If none of the above statuses have been assigned. This means test passed without problems.
+
+Other statuses can be specified in the parse.rules files, these will be classified as FAILED.
+Before integration of the change to OCCT repository, all tests should return either OK or BAD status.
+The new test created for unsolved problem should return BAD. 
+The new test created for a fixed problem should return FAILED without the fix, and OK with the fix.
+
+@subsection testmanual_3_5 Marking BAD Cases
+
+If the test produces invalid result at a certain moment then the corresponding bug 
+should be created in the OCCT issue tracker [3], and the problem should be marked as TODO in the test script.
+The following statement should be added to such test script:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+    puts *TODO BugNumber ListOfPlatforms: RegularExpression* 
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+where:
+
+  * BugNumber is an ID of the bug in the tracker. For example: #12345
+  * ListOfPlatform is a list of platforms at which the bug is reproduced (e.g. Mandriva2008, Windows or All). 
+  
+*Note: the platform name is custom for the OCCT test system;* 
+*it can be consulted as value of environment variable os_type defined in DRAW.*
+
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+    Draw[2]> puts $env(os_type)
+    windows
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+
+  * RegularExpression is a regular expression which should be matched against the line indicating the problem in the script output. 
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+    puts *TODO #22622 Mandriva2008: Abort .* an exception was raised*
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Parser checks the output of the test and if an output line matches 
+the RegularExpression then it will be assigned a BAD status instead of FAILED.
+For each output line matching to an error expression a separate TODO line 
+must be added to mark the test as BAD. 
+If not all the TODO statements are found in the test log, 
+the test will be considered as possible improvement.
+To mark the test as BAD for an incomplete case 
+(when final TEST COMPLETE message is missing) 
+the expression *TEST INCOMPLETE* should be used instead of regular expression. 
+
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+    puts *TODO OCC22817 All: exception.+There are no suitable edges*
+    puts *TODO OCC22817 All: \\*\\* Exception \\*\\**
+    puts *TODO OCC22817 All: TEST INCOMPLETE*
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@section testmanual_4 Extended Use
+
+@subsection testmanual_4_1 Running Tests on Older Versions of OCCT
+
+Sometimes it might be necessary to run tests on previous versions of OCCT (up to to 6.5.3) 
+that do not include this test system. This can be done by adding DRAW configuration file DrawAppliInit 
+in the directory which is current by the moment of DRAW startup, 
+to load test commands and define necessary environment. Example 
+(assume that d:/occt contains up-to-date version of OCCT sources 
+with tests, and test data archive is unpacked to d:/test-data):
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+    set env(CASROOT) d:/occt
+    set env(CSF_TestScriptsPath) $env(CASROOT)/tests
+    source $env(CASROOT)/src/DrawResources/TestCommands.tcl
+    set env(CSF_TestDataPath) d:/test-data
+    return
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Note that on older versions of OCCT the tests are run in compatibility mode 
+and not all output of the test command can be captured; 
+this can lead to absence of some error messages (can be reported as improvement).
+
+@subsection testmanual_4_2 Adding Custom Tests
+
+You can extend the test system by adding your own tests. 
+For that it is necessary to add paths to the directory where these tests are located, 
+and additional data directory(ies), to the environment variables CSF_TestScriptsPath and CSF_TestDataPath. 
+The recommended way for doing this is using DRAW configuration file DrawAppliInit 
+located in the directory which is current by the moment of DRAW startup.
+
+Use Tcl command *_path_separator* to insert platform-dependent separator to the path list.
+Example:
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+    set env(CSF_TestScriptsPath) \
+      $env(TestScriptsPath)[_path_separator]d:/MyOCCTProject/tests
+    set env(CSF_TestDataPath) \
+      d:/occt/test-data[_path_separator]d:/MyOCCTProject/tests
+    return ;# this is to avoid an echo of the last command above in cout
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@section testmanual_5 References
+
+-# DRAW Test Harness User’s Guide
+-# Perl regular expressions, http://perldoc.perl.org/perlre.html 
+-# OCCT MantisBT issue tracker, http://tracker.dev.opencascade.org 
diff --git a/dox/dev_guides/wok/images/wok_image001.jpg b/dox/dev_guides/wok/images/wok_image001.jpg
new file mode 100644 (file)
index 0000000..37fd735
Binary files /dev/null and b/dox/dev_guides/wok/images/wok_image001.jpg differ
diff --git a/dox/dev_guides/wok/images/wok_image002.jpg b/dox/dev_guides/wok/images/wok_image002.jpg
new file mode 100644 (file)
index 0000000..b805c9b
Binary files /dev/null and b/dox/dev_guides/wok/images/wok_image002.jpg differ
diff --git a/dox/dev_guides/wok/images/wok_image003.jpg b/dox/dev_guides/wok/images/wok_image003.jpg
new file mode 100644 (file)
index 0000000..bc3844a
Binary files /dev/null and b/dox/dev_guides/wok/images/wok_image003.jpg differ
diff --git a/dox/dev_guides/wok/images/wok_image004.jpg b/dox/dev_guides/wok/images/wok_image004.jpg
new file mode 100644 (file)
index 0000000..260d032
Binary files /dev/null and b/dox/dev_guides/wok/images/wok_image004.jpg differ
diff --git a/dox/dev_guides/wok/wok.md b/dox/dev_guides/wok/wok.md
new file mode 100644 (file)
index 0000000..808868d
--- /dev/null
@@ -0,0 +1,153 @@
+WOK {#dev_guides__wok}
+=========
+
+WOK is a legacy build environment for Open CASCADE Technology. It is required 
+for generation of header files for classes defined with @ref ug_cdl "CDL"
+("Cascade Definition Language"). Also tools for generation of project files
+for other build systems, and OCCT documentation, are integrated to WOK.
+
+WOK thus is needed in the following situations:
+- Building from OCCT sources from Git repository (do not contain generated files)
+- Building after some changes made in CDL files
+
+Before installing and using WOK, make sure that you have installed a compiler (it is assumed that it is Visual Studio on Windows or gcc on Linux and MacOS) and third-party components required for building OCCT.
+
+@section wok1 Installing WOK
+
+  Download the latest version of binary distribution WOK from http://dev.opencascade.org/index.php?q=home/resources
+
+@subsection wok11 Windows
+
+  Run the installer. You will be prompted to read and accept the OCCT Public License to proceed:
+  
+  ![](/devs_guide/wok/images/wok_image001.jpg "")
+  Click Next and proceed with the installation.
+  At the end of the installation you will be prompted to specify the version and the location of Visual Studio to be used, and the location of third-party libraries:
+  
+  ![](/devs_guide/wok/images/wok_image002.jpg "")
+  You can change these settings at any time later. For this click on the item "Customize environment (GUI tool)" in the WOK group in the Windows Start menu.
+  
+  The shortcuts from this group provide two ways to run WOK: 
+  * In command prompt window ("WOK TCL shell"). 
+  * In Emacs editor ("WOK Emacs"). Using Emacs is convenient if you need to work within WOK environment. 
+
+  By default WOK installer creates a WOK factory with name "LOC" within workshop "dev" (WOK path :LOC:dev). 
+
+@subsection wok12 Linux
+
+  * Unpack the .tgz archive containing WOK distributive into an installation directory <WOK_INSTALL_DIR>.
+
+  * Perform the following commands assuming that you have unpacked WOK distributive archive into <WOK_INSTALL_DIR>:
+  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+  cd <WOK_INSTALL_DIR>/site
+  wok_confgui.sh
+  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+  
+  Define all necessary paths to third-party products in the dialog window:
+  
+  ![](/devs_guide/wok/images/wok_image003.jpg "")
+  * Run the following commands to create WOK LOC factory:
+  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+  cd <WOK_INSTALL_DIR>/site
+  wok_init.sh
+  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+  
+  * Your installation procedure is over. To run WOK use one the following commands:
+  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+  cd <WOK_INSTALL_DIR>/site
+  wok_emacs.sh
+  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+  or
+  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+  cd <WOK_INSTALL_DIR>/site
+  wok_tclsh.sh
+  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@subsection wok13 Mac OS X
+
+  * In the Finder double click on wokSetup.dmg file. This will open a new window. Drag and drop "wokSetup" folder from this window at the location in the Finder where you want to install WOK, i.e. <WOK_INSTALL_DIR>.
+  
+  * Browse in the Finder to the folder <WOK_INSTALL_DIR>/site and double click on WokConfig. This will open a window with additional search path settings. Define all necessary paths to third-party products in the dialog window:
+  
+  ![](/devs_guide/wok/images/wok_image004.jpg "")
+  * Run the following commands to create WOK LOC factory:
+  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+  cd <WOK_INSTALL_DIR>/site
+  wok_init.sh
+  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+  
+  * Your installation procedure is over. To run WOK in Emacs navigate in the Finder to the folder <WOK_INSTALL_DIR>/site and double click on WokEmacs.
+
+
+@section wok2 Initialization of Workbench
+
+  To start working with OCCT, clone the OCCT Git repository from the server (see http://dev.opencascade.org/index.php?q=home/resources for details) or unpack the source archive. 
+  
+  Then create a WOK workbench (command wcreate) setting its Home to the directory, where the repository is created ($CASROOT variable). The workbench should have the same name as that directory. 
+  
+  For example, assuming that OCCT repository has been cloned into D:/occt folder: 
+  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+  LOC:dev> wcreate occt -DHome=D:/occt
+  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+  Note: $CASROOT is equal to D:/occt now
+
+  Then you can work with this workbench using normal WOK functionality (wprocess, umake, etc.; see WOK User’s Guide for details) or use it only for generation of derived sources and project files, and build OCCT with Visual Studio on Windows or make command on Linux, as described below.
+  
+@section wok3 Generation of building projects
+
+  Use command wgenproj in WOK to generate derived headers, source and building projects files: 
+  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+  LOC:dev> wokcd occt
+  LOC:dev:occt> wgenproj [ -target=<TARGET> ] [ -no_wprocess ]
+  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+TARGET:
+  * vc8 - Visual Studio 2005
+  * vc9 - Visual Studio 2008
+  * vc10 - Visual Studio 2010
+  * vc11 - Visual Studio 2012
+  * cbp - CodeBlocks
+  * cmake - CMake
+  * amk - AutoMake
+  * xcd - Xcode
+-no_wprocess - skip generation of derived headers and source files
+
+Note that this command takes several minutes to complete at the first call. 
+
+Re-execute this step to generate derived headers, source and building projects files if some CDL files in OCCT have been modified (either by you directly, or due to updates in the repository). Note that in some cases WOK may fail to update correctly; in such case remove sub-directories drv and .adm and repeat the command. 
+
+To regenerate derived headers and source files without regeneration of projects use command:
+  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+  LOC:dev> wokcd occt
+  LOC:dev:occt> wprocess -DGroups=Src,Xcpp
+  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The generated building project has been placed into $CASROOT/adm folder:
+  * for vc8 - $CASROOT/adm/msvc/vc8
+  * for vc9 - $CASROOT/adm/msvc/vc9
+  * for vc10 - $CASROOT/adm/msvc/vc10
+  * for vc11 - $CASROOT/adm/msvc/vc11
+  * for cbp - $CASROOT/adm/<OS> /cbp
+  * for cmake - $CASROOT/adm/cmake
+  * for amk - $CASROOT/adm/lin/amk
+  * xcd - $CASROOT/adm/<OS>/xcd
+
+@section wok4  Generation of documentation
+
+  Use command wgendoc in WOK to generate reference documentation: 
+  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+  :LOC:dev> wokcd occt
+  :LOC:dev:occt> wgendoc 
+  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The following options can be used: 
+  * -wb=< workbench name >  the name of OCCT workbench (the current one by default);
+  * -m=< list of modules > the list of modules that will be contained in the documentation;
+  * -outdir=< path > the output directory for the documentation;
+  * -chm  the option to generate CHM file;
+  * -hhc=< path > the path to HTML Help Compiler (hhc.exe) or equivalent;
+  * -qthelp=< path > the option to generate Qt Help file, it is necessary to specify the path to qthelpgenerator executable;
+  * -doxygen=< path > the path to Doxygen executable
+  * -dot=< path > the path to GraphViz dot executable
\ No newline at end of file
diff --git a/dox/occdoc.tcl b/dox/occdoc.tcl
new file mode 100644 (file)
index 0000000..2d493f8
--- /dev/null
@@ -0,0 +1,690 @@
+# -----------------------------------------------------------------------
+#  Script name: CompileDocs.tcl
+#  This script compiles OCCT documents from *.md files to HTML pages
+#  Author: omy
+# -----------------------------------------------------------------------
+
+# Generates Doxygen configuration file for Overview documentation
+proc OverviewDoc_MakeDoxyfile {casDir outDir tagFileDir {doxyFileName} {generatorMode ""} DocFilesList verboseMode} {
+
+    if {$verboseMode == "YES"} {
+        puts "INFO: Doxygen is now generating Doxyfile..."
+    }
+
+    set doxyFile [open $doxyFileName "w"]
+    set casroot  $casDir
+    set inputDir $casDir/dox
+
+    # Common configs
+    puts $doxyFile "DOXYFILE_ENCODING      = UTF-8"
+    puts $doxyFile "PROJECT_NAME           = \"Open CASCADE Technology\""
+    puts $doxyFile "PROJECT_NUMBER         = 6.6.0"
+    puts $doxyFile "PROJECT_BRIEF          = "
+    puts $doxyFile "PROJECT_LOGO           = $inputDir/resources/occt_logo.png"
+
+    puts $doxyFile "OUTPUT_DIRECTORY       = $outDir"
+    puts $doxyFile "CREATE_SUBDIRS         = NO"
+    puts $doxyFile "OUTPUT_LANGUAGE        = English"
+    puts $doxyFile "ABBREVIATE_BRIEF       = \"The \$name class\" \
+                                             \"The \$name widget\" \
+                                             \"The \$name file\" \
+                                             is \
+                                             provides \
+                                             specifies \
+                                             contains \
+                                             represents \
+                                             a \
+                                             an \
+                                             the"
+
+    puts $doxyFile "FULL_PATH_NAMES        = YES"
+    puts $doxyFile "INHERIT_DOCS           = YES"
+    puts $doxyFile "TAB_SIZE               = 4"
+    puts $doxyFile "MARKDOWN_SUPPORT       = YES"
+    puts $doxyFile "EXTRACT_ALL            = YES"
+    puts $doxyFile "CASE_SENSE_NAMES       = NO"
+    puts $doxyFile "INLINE_INFO            = YES"
+    puts $doxyFile "SORT_MEMBER_DOCS       = YES"
+    puts $doxyFile "WARNINGS               = YES"
+    puts $doxyFile "WARN_IF_UNDOCUMENTED   = YES"
+    puts $doxyFile "WARN_IF_DOC_ERROR      = YES"
+    puts $doxyFile "WARN_NO_PARAMDOC       = NO"
+    puts $doxyFile "WARN_FORMAT            = \"\$file:\$line: \$text\""
+    puts $doxyFile "INPUT_ENCODING         = UTF-8"
+    puts $doxyFile "FILE_PATTERNS          = *.md *.dox "
+    puts $doxyFile "RECURSIVE              = YES"
+    puts $doxyFile "SOURCE_BROWSER         = NO"
+    puts $doxyFile "INLINE_SOURCES         = YES"
+    puts $doxyFile "COLS_IN_ALPHA_INDEX    = 5"
+    
+    # Generation options
+    puts $doxyFile "GENERATE_DOCSET        = NO"
+    puts $doxyFile "GENERATE_HTMLHELP      = NO"
+    puts $doxyFile "GENERATE_CHI           = NO"
+    puts $doxyFile "GENERATE_QHP           = NO"
+    puts $doxyFile "GENERATE_ECLIPSEHELP   = NO"
+    puts $doxyFile "GENERATE_RTF           = NO"
+    puts $doxyFile "GENERATE_MAN           = NO"
+    puts $doxyFile "GENERATE_XML           = NO"
+    puts $doxyFile "GENERATE_DOCBOOK       = NO"
+    puts $doxyFile "GENERATE_AUTOGEN_DEF   = NO"
+    puts $doxyFile "GENERATE_PERLMOD       = NO"
+
+    set PARAM_INPUT "INPUT                  = "
+    set PARAM_IMAGEPATH "IMAGE_PATH         = $inputDir/resources/ "
+
+    foreach docFile $DocFilesList {
+        set NEW_IMG_PATH [file normalize [file dirname "$inputDir/$docFile"]]
+        if { [string compare $NEW_IMG_PATH $casroot] != 0 } {
+          if {[file isdirectory "$NEW_IMG_PATH/images"]} {
+            append PARAM_IMAGEPATH " " "$NEW_IMG_PATH/images"
+          }
+        }
+        append PARAM_INPUT " " $inputDir/$docFile
+    }
+    puts $doxyFile $PARAM_INPUT
+    puts $doxyFile $PARAM_IMAGEPATH
+    
+    if { $generatorMode == "PDF_ONLY"} {
+        set PARAM_LATEX_EF "LATEX_EXTRA_FILES      ="
+        foreach docFile $DocFilesList {
+            set NEW_LEF_PATH [file normalize [file dirname "$inputDir/$docFile"]]
+            if { [string compare $NEW_LEF_PATH $casroot] != 0 } {
+                append PARAM_LATEX_EF " " "$NEW_LEF_PATH/images"
+            }
+        }
+        puts $doxyFile $PARAM_LATEX_EF
+    }
+
+    if { $generatorMode == "HTML_ONLY"} {
+        # Set a reference to a TAGFILE
+        if { $tagFileDir != "" } {
+            if {[file exists $tagFileDir/OCCT.tag] == 1} {
+                set tagPath [OverviewDoc_GetRelPath $tagFileDir $outDir/html]
+                puts $doxyFile "TAGFILES               = $tagFileDir/OCCT.tag=$tagPath/html"
+            }
+        }
+
+        # HTML Output
+        puts $doxyFile "GENERATE_LATEX         = NO"
+        puts $doxyFile "GENERATE_HTML          = YES"
+        puts $doxyFile "HTML_COLORSTYLE_HUE    = 220"
+        puts $doxyFile "HTML_COLORSTYLE_SAT    = 100"
+        puts $doxyFile "HTML_COLORSTYLE_GAMMA  = 80"
+        puts $doxyFile "HTML_TIMESTAMP         = YES"
+        puts $doxyFile "HTML_DYNAMIC_SECTIONS  = YES"
+        puts $doxyFile "HTML_INDEX_NUM_ENTRIES = 100"
+        puts $doxyFile "DISABLE_INDEX          = YES"
+        puts $doxyFile "GENERATE_TREEVIEW      = YES"
+        puts $doxyFile "ENUM_VALUES_PER_LINE   = 8"
+        puts $doxyFile "TREEVIEW_WIDTH         = 250"
+        puts $doxyFile "EXTERNAL_PAGES         = NO"
+        puts $doxyFile "SEARCHENGINE           = YES"
+        puts $doxyFile "SERVER_BASED_SEARCH    = NO"
+        puts $doxyFile "EXTERNAL_SEARCH        = NO"
+        puts $doxyFile "SEARCHDATA_FILE        = searchdata.xml"
+        puts $doxyFile "SKIP_FUNCTION_MACROS   = YES"
+        # Formula options
+        puts $doxyFile "FORMULA_FONTSIZE       = 12"
+        puts $doxyFile "FORMULA_TRANSPARENT    = YES"
+        puts $doxyFile "USE_MATHJAX            = YES"
+        puts $doxyFile "MATHJAX_FORMAT         = HTML-CSS"
+        puts $doxyFile "MATHJAX_RELPATH        = http://cdn.mathjax.org/mathjax/latest"
+        
+    } elseif { $generatorMode == "PDF_ONLY"} {
+        
+        puts $doxyFile "GENERATE_HTML          = NO"
+        puts $doxyFile "DISABLE_INDEX          = YES"
+        puts $doxyFile "GENERATE_TREEVIEW      = NO"
+        puts $doxyFile "PREDEFINED             = PDF_ONLY"
+        puts $doxyFile "GENERATE_LATEX         = YES"
+        puts $doxyFile "COMPACT_LATEX          = YES"
+        puts $doxyFile "PDF_HYPERLINKS         = YES"
+        puts $doxyFile "USE_PDFLATEX           = YES"
+        puts $doxyFile "LATEX_BATCHMODE        = YES"
+        puts $doxyFile "LATEX_OUTPUT           = latex"
+        puts $doxyFile "LATEX_CMD_NAME         = latex"
+        puts $doxyFile "MAKEINDEX_CMD_NAME     = makeindex"
+    }
+
+    close $doxyFile 
+}
+
+# Returns the relative path between two directories
+proc OverviewDoc_GetRelPath {targetFile currentpath} {
+  set cc [file split [file normalize $currentpath]]
+  set tt [file split [file normalize $targetFile]]
+  
+  if {![string equal [lindex $cc 0] [lindex $tt 0]]} {
+      # not on *n*x then
+      return -code error "$targetFile not on same volume as $currentpath"
+  }
+  while {[string equal [lindex $cc 0] [lindex $tt 0]] && [llength $cc] > 0} {
+      # discard matching components from the front
+      set cc [lreplace $cc 0 0]
+      set tt [lreplace $tt 0 0]
+  }
+  set prefix ""
+  if {[llength $cc] == 0} {
+      # just the file name, so targetFile is lower down (or in same place)
+      set prefix "."
+  }
+  # step up the tree
+  for {set i 0} {$i < [llength $cc]} {incr i} {
+      append prefix " .."
+  }
+  # stick it all together (the eval is to flatten the targetFile list)
+  return [eval file join $prefix $tt]
+}
+
+# Prints Help message
+proc OverviewDoc_PrintHelpMessage {} {
+    puts "\nUsage : occdoc \[-h\] \[-html\] \[-pdf\] \[-m=<list of files>\] \[-l=<document name>\] \[-v\]"
+    puts ""
+    puts " Options are : "
+    puts "    -html                : To generate HTML files"
+    puts "                           (cannot be used with -pdf)"
+    puts "    -pdf                 : To generate PDF files"
+    puts "                           (cannot be used with -html)"
+    puts "    -m=<modules_list>    : Specifies list of documents to generate."
+    puts "                           If it is not specified, all files, "
+    puts "                           mentioned in FILES.txt are processed."
+    puts "    -l=<document_name>   : Specifies the document caption "
+    puts "                           for a single document"
+    puts "    -h                   : Prints help message"
+    puts "    -v                   : Specifies the Verbose mode"
+    puts "                           (info on all script actions is shown)"
+}
+
+# Parses command line arguments
+proc OverviewDoc_ParseArguments {arguments} {
+    global args_names
+    global args_values
+    set args_names {}
+    array set args_values {}
+
+    foreach arg $arguments {
+        if {[regexp {^(-)[a-z]+$} $arg] == 1} {
+            set name [string range $arg 1 [string length $arg]-1]
+            lappend args_names $name
+            set args_values($name) "NULL"
+            continue
+        } elseif {[regexp {^(-)[a-z]+=.+$} $arg] == 1} {
+            set equal_symbol_position [string first "=" $arg]
+            set name [string range $arg 1 $equal_symbol_position-1]
+            lappend args_names $name
+            set value [string range $arg $equal_symbol_position+1 [string length $arguments]-1]
+            
+            # To parse a list of values for -m parameter
+            if { [string first "," $value] != -1 } {
+                set value [split $value ","];
+            }
+            set args_values($name) $value
+        } else {
+            puts "Error in argument $arg"
+            return 1
+        }
+    }
+    return 0
+}
+
+# Loads a list of docfiles from file FILES.txt
+proc OverviewDoc_LoadFilesList {} {
+
+    set INPUTDIR [file normalize [file dirname [info script]]]
+    
+    global available_docfiles
+    set available_docfiles {}
+
+    # Read data from file
+    if { [file exists "$INPUTDIR/FILES.txt"] == 1 } {
+        set FILE [open "$INPUTDIR/FILES.txt" r]
+        while {1} {
+            set line [gets $FILE]
+            if {$line != ""} {
+              lappend available_docfiles $line
+            }
+
+            if {[eof $FILE]} {
+                close $FILE
+                break
+            }
+        }
+    } else {
+        return -1
+    }
+    return 0
+}
+
+# Writes new tex file for conversion from tex to pdf for a specific doc
+proc OverviewDoc_MakeRefmanTex {fileName latexDir docLabel verboseMode} {
+
+    if {$verboseMode == "YES"} {
+        puts "INFO: Making refman.tex file for $fileName"
+    }
+    set DOCNAME "$latexDir/refman.tex"
+    if {[file exists $DOCNAME] == 1} {
+        file delete -force $DOCNAME
+    }
+    set texfile [open $DOCNAME w]
+
+    puts $texfile "\\batchmode"
+    puts $texfile "\\nonstopmode"
+    puts $texfile "\\documentclass\[oneside\]{article}"
+    puts $texfile "\n% Packages required by doxygen"
+    puts $texfile "\\usepackage{calc}"
+    puts $texfile "\\usepackage{doxygen}"
+    puts $texfile "\\usepackage{graphicx}"
+    puts $texfile "\\usepackage\[utf8\]{inputenc}"
+    puts $texfile "\\usepackage{makeidx}"
+    puts $texfile "\\usepackage{multicol}"
+    puts $texfile "\\usepackage{multirow}"
+    puts $texfile "\\usepackage{textcomp}"
+    puts $texfile "\\usepackage{amsmath}"
+    puts $texfile "\\usepackage\[table\]{xcolor}"
+    puts $texfile "\\usepackage{indentfirst}"
+    puts $texfile ""
+    puts $texfile "% Font selection"
+    puts $texfile "\\usepackage\[T1\]{fontenc}"
+    puts $texfile "\\usepackage{mathptmx}"
+    puts $texfile "\\usepackage\[scaled=.90\]{helvet}"
+    puts $texfile "\\usepackage{courier}"
+    puts $texfile "\\usepackage{amssymb}"
+    puts $texfile "\\usepackage{sectsty}"
+    puts $texfile "\\renewcommand{\\familydefault}{\\sfdefault}"
+    puts $texfile "\\allsectionsfont{%"
+    puts $texfile "  \\fontseries{bc}\\selectfont%"
+    puts $texfile "  \\color{darkgray}%"
+    puts $texfile "}"
+    puts $texfile "\\renewcommand{\\DoxyLabelFont}{%"
+    puts $texfile "  \\fontseries{bc}\\selectfont%"
+    puts $texfile "  \\color{darkgray}%"
+    puts $texfile "}"
+    puts $texfile ""
+    puts $texfile "% Page & text layout"
+    puts $texfile "\\usepackage{geometry}"
+    puts $texfile "\\geometry{%"
+    puts $texfile "  a4paper,%"
+    puts $texfile "  top=2.5cm,%"
+    puts $texfile "  bottom=2.5cm,%"
+    puts $texfile "  left=2.5cm,%"
+    puts $texfile "  right=2.5cm%"
+    puts $texfile "}"
+    puts $texfile "\\tolerance=750"
+    puts $texfile "\\hfuzz=15pt"
+    puts $texfile "\\hbadness=750"
+    puts $texfile "\\setlength{\\emergencystretch}{15pt}"
+    puts $texfile "\\setlength{\\parindent}{0.75cm}"
+    puts $texfile "\\setlength{\\parskip}{0.2cm}"
+    puts $texfile "\\makeatletter"
+    puts $texfile "\\renewcommand{\\paragraph}{%"
+    puts $texfile "  \@startsection{paragraph}{4}{0ex}{-1.0ex}{1.0ex}{%"
+    puts $texfile "\\normalfont\\normalsize\\bfseries\\SS@parafont%"
+    puts $texfile "  }%"
+    puts $texfile "}"
+    puts $texfile "\\renewcommand{\\subparagraph}{%"
+    puts $texfile "  \\@startsection{subparagraph}{5}{0ex}{-1.0ex}{1.0ex}{%"
+    puts $texfile "\\normalfont\\normalsize\\bfseries\\SS@subparafont%"
+    puts $texfile "  }%"
+    puts $texfile "}"
+    puts $texfile "\\makeatother"
+    puts $texfile ""
+    puts $texfile "% Headers & footers"
+    puts $texfile "\\usepackage{fancyhdr}"
+    puts $texfile "\\pagestyle{fancyplain}"
+    puts $texfile "\\fancyhead\[LE\]{\\fancyplain{}{\\bfseries\\thepage}}"
+    puts $texfile "\\fancyhead\[CE\]{\\fancyplain{}{}}"
+    puts $texfile "\\fancyhead\[RE\]{\\fancyplain{}{\\bfseries\\leftmark}}"
+    puts $texfile "\\fancyhead\[LO\]{\\fancyplain{}{\\bfseries\\rightmark}}"
+    puts $texfile "\\fancyhead\[CO\]{\\fancyplain{}{}}"
+    puts $texfile "\\fancyhead\[RO\]{\\fancyplain{}{\\bfseries\\thepage}}"
+    puts $texfile "\\fancyfoot\[LE\]{\\fancyplain{}{}}"
+    puts $texfile "\\fancyfoot\[CE\]{\\fancyplain{}{}}"
+    puts $texfile "\\fancyfoot\[RE\]{\\fancyplain{}{\\bfseries\\scriptsize © Open CASCADE Technology 2001\-2013}}"
+    puts $texfile "\\fancyfoot\[LO\]{\\fancyplain{}{\\bfseries\\scriptsize © Open CASCADE Technology 2001\-2013}}"
+    puts $texfile "\\fancyfoot\[CO\]{\\fancyplain{}{}}"
+    puts $texfile "\\fancyfoot\[RO\]{\\fancyplain{}{}}"
+    puts $texfile "\\renewcommand{\\footrulewidth}{0.4pt}"
+    puts $texfile "\\renewcommand{\\sectionmark}\[1\]{%"
+    puts $texfile "  \\markright{\\thesection\\ #1}%"
+    puts $texfile "}"
+    puts $texfile ""
+    puts $texfile "% Indices & bibliography"
+    puts $texfile "\\usepackage{natbib}"
+    puts $texfile "\\usepackage\[titles\]{tocloft}"
+    puts $texfile "\\renewcommand{\\cftsecleader}{\\cftdotfill{\\cftdotsep}}"
+    puts $texfile "\\setcounter{tocdepth}{3}"
+    puts $texfile "\\setcounter{secnumdepth}{5}"
+    puts $texfile "\\makeindex"
+    puts $texfile ""
+    puts $texfile "% Hyperlinks (required, but should be loaded last)"
+    puts $texfile "\\usepackage{ifpdf}"
+    puts $texfile "\\ifpdf"
+    puts $texfile "  \\usepackage\[pdftex,pagebackref=true\]{hyperref}"
+    puts $texfile "\\else"
+    puts $texfile "  \\usepackage\[ps2pdf,pagebackref=true\]{hyperref}"
+    puts $texfile "\\fi"
+    puts $texfile "\\hypersetup{%"
+    puts $texfile "  colorlinks=true,%"
+    puts $texfile "  linkcolor=black,%"
+    puts $texfile "  citecolor=black,%"
+    puts $texfile "  urlcolor=blue,%"
+    puts $texfile "  unicode%"
+    puts $texfile "}"
+    puts $texfile ""
+    puts $texfile "% Custom commands"
+    puts $texfile "\\newcommand{\\clearemptydoublepage}{%"
+    puts $texfile "  \\newpage{\\pagestyle{empty}\\cleardoublepage}%"
+    puts $texfile "}"
+    puts $texfile "\n"
+    puts $texfile "%===== C O N T E N T S =====\n"
+    puts $texfile "\\begin{document}"
+    puts $texfile ""
+    puts $texfile "% Titlepage & ToC"
+    puts $texfile "\\hypersetup{pageanchor=false}"
+    puts $texfile "\\pagenumbering{roman}"
+    puts $texfile "\\begin{titlepage}"
+    puts $texfile "\\vspace*{7cm}"
+    puts $texfile "\\begin{center}%"
+    puts $texfile "\\includegraphics\[width=0.75\\textwidth, height=0.2\\textheight\]{occttransparent.png}\\\\\\\\"
+    puts $texfile "{\\Large Open C\\-A\\-S\\-C\\-A\\-D\\-E Technology \\\\\[1ex\]\\Large 6.\\-6.\\-0 }\\\\"
+    puts $texfile "\\vspace*{1cm}"
+    puts $texfile "{\\Large $docLabel}\\\\"
+    puts $texfile "\\vspace*{1cm}"
+    puts $texfile "{\\large Generated by Doxygen 1.8.4}\\\\"
+    puts $texfile "\\vspace*{0.5cm}"
+    puts $texfile "{\\small \\today}\\"
+    puts $texfile "\\end{center}"
+    puts $texfile "\\end{titlepage}"
+    puts $texfile "\\clearpage"
+    puts $texfile "\\pagenumbering{roman}"
+    puts $texfile "\\tableofcontents"
+    puts $texfile "\\newpage"
+    puts $texfile "\\pagenumbering{arabic}"
+    puts $texfile "\\hypersetup{pageanchor=true}"
+    puts $texfile ""
+    puts $texfile "\\hypertarget{$fileName}{}"
+    puts $texfile "\\input{$fileName}"
+    puts $texfile ""
+    puts $texfile "% Index"
+    puts $texfile "\\newpage"
+    puts $texfile "\\phantomsection"
+    puts $texfile "\\addcontentsline{toc}{part}{Index}"
+    puts $texfile "\\printindex\n"
+    puts $texfile "\\end{document}"
+
+    close $texfile
+}
+
+# Postprocesses generated TeX files
+proc OverviewDoc_ProcessTex {{texFiles {}} {latexDir} verboseMode} {
+
+    foreach TEX $texFiles {
+        if {$verboseMode == "YES"} {
+            puts "INFO: Preprocessing file $TEX"
+        }
+        set IN_F  [open "$TEX" r]
+        set TMPFILENAME "$latexDir/temp.tex"
+        set OUT_F [open $TMPFILENAME w]
+        
+        while {1} {
+            set line [gets $IN_F]
+            if { [string first "\\includegraphics" $line] != -1 } {
+                # Center images in TeX files
+                set line "\\begin{center}\n $line\n\\end{center}"
+            } elseif { [string first "\\subsection" $line] != -1 } {
+                # Replace \subsection with \section tag
+                regsub -all "\\\\subsection" $line "\\\\section" line
+            } elseif { [string first "\\subsubsection" $line] != -1 } {
+                # Replace \subsubsection with \subsection tag
+                regsub -all "\\\\subsubsection" $line "\\\\subsection" line
+            } elseif { [string first "\\paragraph" $line] != -1 } {
+                # Replace \paragraph with \subsubsection tag
+                regsub -all "\\\\paragraph" $line "\\\\subsubsection" line
+            }
+            puts $OUT_F $line
+            
+            if {[eof $IN_F]} {
+                close $IN_F
+                close $OUT_F
+                break
+            }
+        }
+        file delete -force $TEX
+        file rename $TMPFILENAME $TEX
+    }
+}
+
+# Main procedure for documents compilation
+proc OverviewDoc_Main { {docfiles {}} generatorMode docLabel verboseMode} {
+
+    set INDIR      [file normalize [file dirname [info script]]]
+    set CASROOT    [file normalize [file dirname "$INDIR/../../"]]
+    set OUTDIR     $CASROOT/doc
+    set PDFDIR     $OUTDIR/overview/pdf
+    set HTMLDIR    $OUTDIR/overview/html
+    set LATEXDIR   $OUTDIR/overview/latex
+    set TAGFILEDIR $OUTDIR/refman
+    set DOXYFILE   $OUTDIR/OCCT.cfg
+
+    # Create or clean the output folders
+    if {[file exists $OUTDIR] == 0} {
+        file mkdir $OUTDIR
+    } 
+    if {[file exists $HTMLDIR] == 0} {
+        file mkdir $HTMLDIR
+    }
+    if {[file exists $LATEXDIR] == 0} {
+        file mkdir $LATEXDIR
+    }
+    if {[file exists $PDFDIR] == 0} {
+        file mkdir $PDFDIR
+    }
+
+    # Run tools to compile documents
+    puts ""
+    puts " [clock format [clock seconds] -format {%Y.%m.%d %H:%M}] Generation process started..."
+    puts ""
+    puts " Please, wait while Doxygen finishes it\'s work"
+    OverviewDoc_MakeDoxyfile $CASROOT "$OUTDIR/overview" $TAGFILEDIR $DOXYFILE $generatorMode $docfiles $verboseMode
+
+    # Run doxygen tool
+    if { $generatorMode == "HTML_ONLY"} {
+        puts " [clock format [clock seconds] -format {%Y.%m.%d %H:%M}] Doxygen is now generating HTML files...\n"
+    }
+    set RESULT [catch {exec doxygen $DOXYFILE > $OUTDIR/doxygen_out.log} DOX_ERROR] 
+    if {$RESULT != 0} {
+        if {[llength [split $DOX_ERROR "\n"]] > 1} {
+            if {$verboseMode == "YES"} {
+                puts "INFO: See Doxygen messages in $OUTDIR/doxygen_warnings_and_errors.log"
+            }
+            set DOX_ERROR_FILE [open "$OUTDIR/doxygen_warnings_and_errors.log" "w"]
+            puts $DOX_ERROR_FILE $DOX_ERROR
+            close $DOX_ERROR_FILE
+        } else {
+            puts $DOX_ERROR
+        }
+    }
+    # Close the Doxygen application
+    after 300
+
+    # Start PDF generation routine
+    if { $generatorMode == "PDF_ONLY" } {
+        puts ""
+        puts " [clock format [clock seconds] -format {%Y.%m.%d %H:%M}] Doxygen is now generating PDF files...\n"
+
+        set OS $::tcl_platform(platform)
+        if { $OS == "unix" } {
+            set PREFIX ".sh"
+        } elseif { $OS == "windows" } {
+            set PREFIX ".bat"
+        }
+
+        # Prepare a list of TeX files, generated by Doxygen
+        cd $LATEXDIR
+        
+        set TEXFILES [glob $LATEXDIR -type f -directory $LATEXDIR -tails "*.tex" ]
+        set REFMAN_IDX [lsearch $TEXFILES "refman.tex"]
+        set TEXFILES [lreplace $TEXFILES $REFMAN_IDX $REFMAN_IDX]
+        set REFMAN_IDX [lsearch $TEXFILES "index.tex"]
+        set TEXFILES [lreplace $TEXFILES $REFMAN_IDX $REFMAN_IDX]
+
+        set IDX [lsearch $TEXFILES "$LATEXDIR"]
+        while { $IDX != -1} {
+            set TEXFILES [lreplace $TEXFILES $IDX $IDX]
+            set IDX [lsearch $TEXFILES "$LATEXDIR"]
+        }
+
+        # Preprocess generated TeX files
+        OverviewDoc_ProcessTex $TEXFILES $LATEXDIR $verboseMode
+
+        # Generate PDF files from 
+        foreach TEX $TEXFILES {
+            # Rewrite existing REFMAN.tex file...
+            set TEX [string range $TEX 0 [ expr "[string length $TEX] - 5"]]
+            OverviewDoc_MakeRefmanTex $TEX $LATEXDIR $docLabel $verboseMode
+            
+            if {$verboseMode == "YES"} {
+                puts "INFO: Generating PDF file from $TEX"
+            }
+            # ...and use it to generate PDF from TeX...
+            set RESULT [catch {eval exec [auto_execok $LATEXDIR/make$PREFIX] > "$OUTDIR/pdflatex_out.log"} LaTeX_ERROR]
+            if {$RESULT != 0} {
+                if {[llength [split $LaTeX_ERROR "\n"]] > 1} {
+                    set LaTeX_ERROR_FILE [open "$OUTDIR/pdflatex_warnings_and_errors.log" "w"]
+                    puts $LaTeX_ERROR_FILE $LaTeX_ERROR
+                    close $LaTeX_ERROR_FILE
+                } else {
+                    puts $DOX_ERROR
+                }
+            }
+
+            # ...and place it to the specific folder
+            if { [file exists $PDFDIR/$TEX.pdf] == 1 } {
+                file delete -force $PDFDIR/$TEX.pdf
+            }
+            file rename $LATEXDIR/refman.pdf "$PDFDIR/$TEX.pdf"
+        }
+        if {$verboseMode == "YES"} {
+            puts "INFO: See LaTeX messages in $OUTDIR/pdflatex_warnings_and_errors.log"
+        }
+    }
+
+    cd $INDIR
+    puts " [clock format [clock seconds] -format {%Y.%m.%d %H:%M}] Generation process finished..."
+    puts ""
+    puts "--------------------------------------------------------------------"
+    if { $generatorMode == "HTML_ONLY" } {
+        puts " You can look at generated HTML pages by opening: "
+        set RESFILE $OUTDIR/overview/html/index.html
+        puts " $RESFILE"
+    }
+    if { $generatorMode == "PDF_ONLY" } {
+        puts " You can look at generated PDF files in: "
+        puts " $OUTDIR/overview/pdf folder"
+    }
+    puts ""
+    puts " Copyright \u00a9 Open CASCADE Technology 2001-2013"
+    puts "--------------------------------------------------------------------\n"
+}
+
+# A command for User Documentation compilation
+proc occdoc {args} {
+    # Programm options
+    set GEN_HTML  "NO"
+    set GEN_PDF   "NO"
+    set DOCFILES  {}
+    set DOCLABEL  "Default OCCT Document"
+    set VERB_MODE "NO"
+    set GEN_MODE  "DEFAULT"
+    global available_docfiles
+    global args_names
+    global args_values
+
+    # Load list of docfiles
+    if { [OverviewDoc_LoadFilesList] != 0 } {
+        puts "ERROR: File FILES.txt was not found"
+        return
+    }
+
+    # Parse CL arguments
+    if {[OverviewDoc_ParseArguments $args] == 1} {
+        return
+    }
+    if {$args_names == {}} {
+        set GEN_HTML "YES"
+        set VERB_MODE "YES"
+    } else {
+        foreach arg_n $args_names {
+            if {$arg_n == "h"} {
+              OverviewDoc_PrintHelpMessage
+              return
+            } elseif {$arg_n == "html"} {
+                set GEN_HTML "YES"
+            } elseif {$arg_n == "pdf"} {
+                set GEN_PDF "YES"
+            } elseif {$arg_n == "v"} {
+                set VERB_MODE "YES"
+            } elseif {$arg_n == "m"} {
+                if {$args_values(m) != "NULL"} {
+                    set DOCFILES $args_values(m)
+                } else {
+                    puts "Error in argument m"
+                    return
+                }
+                # Check if all chosen docfiles are correct
+                foreach docfile $DOCFILES {
+                    if { [lsearch $available_docfiles $docfile] == -1 } {
+                        puts "File \"$docfile\" is not presented in the list of available docfiles"
+                        puts "Please, specify the correct docfile name"
+                        return
+                    } else {
+                        puts "File $docfile is presented in FILES.TXT"
+                    }
+                }
+            } elseif {$arg_n == "l"} {
+                if { [llength $DOCFILES] <= 1 } {
+                    if {$args_values(l) != "NULL"} {
+                        set DOCLABEL $args_values(l)
+                    } else {
+                        puts "Error in argument l"
+                        return
+                    }
+                }
+            } else {
+                puts "\nWrong argument: $arg_n"
+                OverviewDoc_PrintHelpMessage
+                return
+            }
+        }
+    }
+
+    # Specify generation mode
+    if {$GEN_HTML == "YES" && $GEN_PDF == "NO"} {
+        set GEN_MODE "HTML_ONLY"
+    } elseif {$GEN_PDF == "YES"} {
+        set GEN_MODE "PDF_ONLY"
+    }
+    # Check if -v is the only option
+    if {$GEN_MODE == "DEFAULT"} {
+        if { $VERB_MODE == "YES" } {
+            puts "\nArgument -v can't be used without -pdf or -html argument"
+            OverviewDoc_PrintHelpMessage
+        }
+        return
+    }
+    
+    # Specify verbose mode
+    if { $GEN_PDF != "YES" && [llength $DOCFILES] > 1 } {
+        set DOCLABEL ""
+    }
+    
+    # If we don't specify list for docfiles with -m argument,
+    # we assume that we have to generate all docfiles
+    if { [llength $DOCFILES] == 0 } {
+        set DOCFILES $available_docfiles
+    }
+
+    # Start main activities
+    OverviewDoc_Main $DOCFILES $GEN_MODE $DOCLABEL $VERB_MODE
+}
diff --git a/dox/overview/images/overview_c__ie.png b/dox/overview/images/overview_c__ie.png
new file mode 100644 (file)
index 0000000..3cfc12e
Binary files /dev/null and b/dox/overview/images/overview_c__ie.png differ
diff --git a/dox/overview/images/overview_draw.png b/dox/overview/images/overview_draw.png
new file mode 100644 (file)
index 0000000..27cd5cd
Binary files /dev/null and b/dox/overview/images/overview_draw.png differ
diff --git a/dox/overview/images/overview_installation.png b/dox/overview/images/overview_installation.png
new file mode 100644 (file)
index 0000000..cd01944
Binary files /dev/null and b/dox/overview/images/overview_installation.png differ
diff --git a/dox/overview/images/overview_mvc.png b/dox/overview/images/overview_mvc.png
new file mode 100644 (file)
index 0000000..f410483
Binary files /dev/null and b/dox/overview/images/overview_mvc.png differ
diff --git a/dox/overview/images/overview_occttransparent.png b/dox/overview/images/overview_occttransparent.png
new file mode 100644 (file)
index 0000000..ce18b6e
Binary files /dev/null and b/dox/overview/images/overview_occttransparent.png differ
diff --git a/dox/overview/images/overview_qt.png b/dox/overview/images/overview_qt.png
new file mode 100644 (file)
index 0000000..e4c6885
Binary files /dev/null and b/dox/overview/images/overview_qt.png differ
diff --git a/dox/overview/tutorial/images/tutorial_image001.png b/dox/overview/tutorial/images/tutorial_image001.png
new file mode 100644 (file)
index 0000000..5fd0189
Binary files /dev/null and b/dox/overview/tutorial/images/tutorial_image001.png differ
diff --git a/dox/overview/tutorial/images/tutorial_image002.png b/dox/overview/tutorial/images/tutorial_image002.png
new file mode 100644 (file)
index 0000000..801c5ea
Binary files /dev/null and b/dox/overview/tutorial/images/tutorial_image002.png differ
diff --git a/dox/overview/tutorial/images/tutorial_image003.png b/dox/overview/tutorial/images/tutorial_image003.png
new file mode 100644 (file)
index 0000000..b08eeb8
Binary files /dev/null and b/dox/overview/tutorial/images/tutorial_image003.png differ
diff --git a/dox/overview/tutorial/images/tutorial_image004.png b/dox/overview/tutorial/images/tutorial_image004.png
new file mode 100644 (file)
index 0000000..b10ce22
Binary files /dev/null and b/dox/overview/tutorial/images/tutorial_image004.png differ
diff --git a/dox/overview/tutorial/images/tutorial_image005.png b/dox/overview/tutorial/images/tutorial_image005.png
new file mode 100644 (file)
index 0000000..bfbe42c
Binary files /dev/null and b/dox/overview/tutorial/images/tutorial_image005.png differ
diff --git a/dox/overview/tutorial/images/tutorial_image006.png b/dox/overview/tutorial/images/tutorial_image006.png
new file mode 100644 (file)
index 0000000..d5a119f
Binary files /dev/null and b/dox/overview/tutorial/images/tutorial_image006.png differ
diff --git a/dox/overview/tutorial/images/tutorial_image007.png b/dox/overview/tutorial/images/tutorial_image007.png
new file mode 100644 (file)
index 0000000..1391895
Binary files /dev/null and b/dox/overview/tutorial/images/tutorial_image007.png differ
diff --git a/dox/overview/tutorial/images/tutorial_image008.png b/dox/overview/tutorial/images/tutorial_image008.png
new file mode 100644 (file)
index 0000000..85efc0e
Binary files /dev/null and b/dox/overview/tutorial/images/tutorial_image008.png differ
diff --git a/dox/overview/tutorial/images/tutorial_image009.png b/dox/overview/tutorial/images/tutorial_image009.png
new file mode 100644 (file)
index 0000000..3fb60f5
Binary files /dev/null and b/dox/overview/tutorial/images/tutorial_image009.png differ
diff --git a/dox/overview/tutorial/images/tutorial_image010.png b/dox/overview/tutorial/images/tutorial_image010.png
new file mode 100644 (file)
index 0000000..899e224
Binary files /dev/null and b/dox/overview/tutorial/images/tutorial_image010.png differ
diff --git a/dox/overview/tutorial/images/tutorial_image011.png b/dox/overview/tutorial/images/tutorial_image011.png
new file mode 100644 (file)
index 0000000..741a671
Binary files /dev/null and b/dox/overview/tutorial/images/tutorial_image011.png differ
diff --git a/dox/overview/tutorial/images/tutorial_image012.png b/dox/overview/tutorial/images/tutorial_image012.png
new file mode 100644 (file)
index 0000000..4d68528
Binary files /dev/null and b/dox/overview/tutorial/images/tutorial_image012.png differ
diff --git a/dox/overview/tutorial/images/tutorial_image013.png b/dox/overview/tutorial/images/tutorial_image013.png
new file mode 100644 (file)
index 0000000..af84d79
Binary files /dev/null and b/dox/overview/tutorial/images/tutorial_image013.png differ
diff --git a/dox/overview/tutorial/images/tutorial_image014.png b/dox/overview/tutorial/images/tutorial_image014.png
new file mode 100644 (file)
index 0000000..f963517
Binary files /dev/null and b/dox/overview/tutorial/images/tutorial_image014.png differ
diff --git a/dox/overview/tutorial/images/tutorial_image015.png b/dox/overview/tutorial/images/tutorial_image015.png
new file mode 100644 (file)
index 0000000..5dc55b9
Binary files /dev/null and b/dox/overview/tutorial/images/tutorial_image015.png differ
diff --git a/dox/overview/tutorial/images/tutorial_image016.png b/dox/overview/tutorial/images/tutorial_image016.png
new file mode 100644 (file)
index 0000000..8ea559a
Binary files /dev/null and b/dox/overview/tutorial/images/tutorial_image016.png differ
diff --git a/dox/overview/tutorial/images/tutorial_image017.png b/dox/overview/tutorial/images/tutorial_image017.png
new file mode 100644 (file)
index 0000000..5beaf94
Binary files /dev/null and b/dox/overview/tutorial/images/tutorial_image017.png differ
diff --git a/dox/overview/tutorial/images/tutorial_image018.png b/dox/overview/tutorial/images/tutorial_image018.png
new file mode 100644 (file)
index 0000000..0ac10c9
Binary files /dev/null and b/dox/overview/tutorial/images/tutorial_image018.png differ
diff --git a/dox/overview/tutorial/images/tutorial_image019.png b/dox/overview/tutorial/images/tutorial_image019.png
new file mode 100644 (file)
index 0000000..c5e2eed
Binary files /dev/null and b/dox/overview/tutorial/images/tutorial_image019.png differ
diff --git a/dox/overview/tutorial/tutorial.md b/dox/overview/tutorial/tutorial.md
new file mode 100644 (file)
index 0000000..ea2a9cf
--- /dev/null
@@ -0,0 +1,843 @@
+ Tutorial {#overview__tutorial}
+=======
+
+@section sec1 Overview 
+
+
+This tutorial will teach you how to use Open CASCADE Technology services to model a 3D object. The purpose of this tutorial is not to describe all Open CASCADE Technology classes but to help you start thinking in terms of Open CASCADE Technology as a tool. 
+
+
+@subsection OCCT_TUTORIAL_SUB1_1 Prerequisites 
+
+This tutorial assumes that you have experience in using and setting up C++.
+From a programming standpoint, Open CASCADE Technology is designed to enhance your C++ tools with 3D modeling classes, methods and functions. The combination of all these resources will allow you to create substantial applications.
+
+@subsection OCCT_TUTORIAL_SUB1_2 The Model
+
+To illustrate the use of classes provided in the 3D geometric modeling toolkits, you will create a bottle as shown:
+
+![](/overview/tutorial/images/tutorial_image001.png "")
+
+In the tutorial we will create, step-by-step, a function that will model a bottle as shown above. You will find the complete source code of this tutorial, including the very function *MakeBottle* in the distribution of Open CASCADE Technology. The function body is provided in the file samples/qt/Tutorial/src/MakeBottle.cxx.
+
+@subsection OCCT_TUTORIAL_SUB1_3 Model Specifications
+
+We first define the bottle specifications as follows:
+
+| Object Parameter | Parameter Name | Parameter Value |
+| :--------------: | :------------: | :-------------: |
+| Bottle height    | MyHeight       |         70mm    |
+| Bottle width     | MyWidth        |         50mm    |
+| Bottle thickness | MyThickness    |         30mm    |
+
+In addition, we decide that the bottle's profile (base) will be centered on the origin of the global Cartesian coordinate system.
+
+![](/overview/tutorial/images/tutorial_image002.png "")
+
+This modeling requires four steps:
+
+  * build the bottle's Profile
+  * build the bottle's Body
+  * build the Threading on the bottle's neck
+  * build the result compound
+
+  
+@section sec2 Building the Profile 
+
+@subsection OCCT_TUTORIAL_SUB2_1 Defining Support Points
+
+To create the bottle's profile, you first create characteristic points with their coordinates as shown below in the (XOY) plane. These points will be the supports that define the geometry of the profile.
+
+![](/overview/tutorial/images/tutorial_image003.png "")
+
+There are two classes to describe a 3D Cartesian point from its X, Y and Z coordinates in Open CASCADE Technology:
+
+  * the primitive geometric *gp_Pnt* class
+  * the transient *Geom_CartesianPoint* class manipulated by handle
+    
+A handle is a type of smart pointer that provides automatic memory management.
+To choose the best class for this application, consider the following:
+
+  * *gp_Pnt* is manipulated by value. Like all objects of its kind, it will have a limited lifetime.
+  * *Geom_CartesianPoint* is manipulated by handle and may have multiple references and a long lifetime.
+    
+Since all the points you will define are only used to create the profile's curves, an object with a limited lifetime will do. Choose the *gp_Pnt* class.
+To instantiate a *gp_Pnt* object, just specify the X, Y, and Z coordinates of the points in the global cartesian coordinate system:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+    gp_Pnt aPnt1(-myWidth / 2., 0, 0);
+    gp_Pnt aPnt2(-myWidth / 2., -myThickness / 4., 0);
+    gp_Pnt aPnt3(0, -myThickness / 2., 0);
+    gp_Pnt aPnt4(myWidth / 2., -myThickness / 4., 0);
+    gp_Pnt aPnt5(myWidth / 2., 0, 0);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Once your objects are instantiated, you can use methods provided by the class to access and modify its data. For example, to get the X coordinate of a point:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+Standard_Real xValue1 = aPnt1.X();
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@subsection OCCT_TUTORIAL_SUB2_2 Profile: Defining the Geometry
+With the help of the previously defined points, you can compute a part of the bottle's profile geometry. As shown in the figure below, it will consist of two segments and one arc.
+
+![](/overview/tutorial/images/tutorial_image004.png "")
+
+To create such entities, you need a specific data structure, which implements 3D geometric objects. This can be found in the Geom package of Open CASCADE Technology.
+In Open CASCADE Technology a package is a group of classes providing related functionality. The classes have names that start with the name of a package they belong to. For example, *Geom_Line* and *Geom_Circle* classes belong to the *Geom* package. The *Geom* package implements 3D geometric objects: elementary curves and surfaces are provided as well as more complex ones (such as *Bezier* and *BSpline*).
+However, the *Geom* package provides only the data structure of geometric entities. You can directly instantiate classes belonging to *Geom*, but it is easier to compute elementary curves and surfaces by using the *GC* package. 
+This is because the *GC* provides two algorithm classes which are exactly what is required for our profile:
+
+  * Class *GC_MakeSegment* to create a segment. One of its constructors allows you to define a segment by two end points P1 and P2
+  * Class *GC_MakeArcOfCircle* to create an arc of a circle. A useful constructor creates an arc from two end points P1 and P3 and going through P2.
+
+Both of these classes return a *Geom_TrimmedCurve* manipulated by handle. This entity represents a base curve (line or circle, in our case), limited between two of its parameter values. For example, circle C is parameterized between 0 and 2PI. If you need to create a quarter of a circle, you create a *Geom_TrimmedCurve* on C limited between 0 and M_PI/2.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+    Handle(Geom_TrimmedCurve) aArcOfCircle = GC_MakeArcOfCircle(aPnt2,aPnt3,aPnt4);
+    Handle(Geom_TrimmedCurve) aSegment1    = GC_MakeSegment(aPnt1, aPnt2);
+    Handle(Geom_TrimmedCurve) aSegment2    = GC_MakeSegment(aPnt4, aPnt5);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+All *GC* classes provide a casting method to obtain a result automatically with a function-like call. Note that this method will raise an exception if construction has failed. To handle possible errors more explicitly, you may use the *IsDone* and *Value* methods. For example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+    GC_MakeSegment mkSeg (aPnt1, aPnt2);
+    Handle(Geom_TrimmedCurve) aSegment1;
+    if(mkSegment.IsDone()){
+        aSegment1 = mkSeg.Value();
+    }
+    else {
+    // handle error
+    }
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+@subsection OCCT_TUTORIAL_SUB2_3 Profile: Defining the Topology
+
+
+You have created the support geometry of one part of the profile but these curves are independent with no relations between each other.
+To simplify the modeling, it would be right to manipulate these three curves as a single entity.
+This can be done by using the topological data structure of Open CASCADE Technology defined in the *TopoDS* package: it defines relationships between geometric entities which can be linked together to represent complex shapes.
+Each object of the *TopoDS* package, inheriting from the *TopoDS_Shape* class, describes a topological shape as described below:
+
+| Shape     | Open CASCADE Technology Class |                      Description                              |
+| :-------- | :---------------------------- | :------------------------------------------------------------ |
+| Vertex    | TopoDS_Vertex                 | Zero dimensional shape corresponding to a point in geometry.  |
+| Edge      | TopoDS_Edge                   | One-dimensional shape corresponding to a curve and bounded by a vertex at each extremity.|
+| Wire      | TopoDS_Wire                   | Sequence of edges connected by vertices.                      |
+| Face      | TopoDS_Face                   | Part of a surface bounded by a closed wire(s).                |
+| Shell     | TopoDS_Shell                  | Set of faces connected by edges.                              |
+| Solid     | TopoDS_Solid                  | Part of 3D space bounded by Shells.                           |
+| CompSolid | TopoDS_CompSolid              | Set of solids connected by their faces.                       |
+| Compound  | TopoDS_Compound               | Set of any other shapes described above.                      |
+
+Referring to the previous table, to build the profile, you will create:
+
+  * Three edges out of the previously computed curves.
+  * One wire with these edges.
+
+![](/overview/tutorial/images/tutorial_image005.png "")
+    
+However, the *TopoDS* package provides only the data structure of the topological entities. Algorithm classes available to compute standard topological objects can be found in the *BRepBuilderAPI* package.
+To create an edge, you use the BRepBuilderAPI_MakeEdge class with the previously computed curves:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+    TopoDS_Edge aEdge1 = BRepBuilderAPI_MakeEdge(aSegment1);
+    TopoDS_Edge aEdge2 = BRepBuilderAPI_MakeEdge(aArcOfCircle);
+    TopoDS_Edge aEdge3 = BRepBuilderAPI_MakeEdge(aSegment2);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In Open CASCADE Technology, you can create edges in several ways. One possibility is to create an edge directly from two points, in which case the underlying geometry of this edge is a line, bounded by two vertices being automatically computed from the two input points. For example, aEdge1 and aEdge3 could have been computed in a simpler way:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+    TopoDS_Edge aEdge1 = BRepBuilderAPI_MakeEdge(aPnt1, aPnt3);
+    TopoDS_Edge aEdge2 = BRepBuilderAPI_MakeEdge(aPnt4, aPnt5);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To connect the edges, you need to create a wire with the *BRepBuilderAPI_MakeWire* class. There are two ways of building a wire with this class:
+
+  * directly from one to four edges
+  * by adding other wire(s) or edge(s) to an existing wire (this is explained later in this tutorial)
+
+When building a wire from less than four edges, as in the present case, you can use the constructor directly as follows:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+    TopoDS_Wire aWire = BRepBuilderAPI_MakeWire(aEdge1, aEdge2, aEdge3);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+@subsection OCCT_TUTORIAL_SUB2_4 Profile: Completing the Profile
+
+
+Once the first part of your wire is created you need to compute the complete profile. A simple way to do this is to:
+
+  * compute a new wire by reflecting the existing one.
+  * add the reflected wire to the initial one.
+
+![](/overview/tutorial/images/tutorial_image006.png "")
+
+To apply a transformation on shapes (including wires), you first need to define the properties of a 3D geometric transformation by using the gp_Trsf class. This transformation can be a translation, a rotation, a scale, a reflection, or a combination of these.
+In our case, we need to define a reflection with respect to the X axis of the global coordinate system. An axis, defined with the gp_Ax1 class, is built out of a point and has a direction (3D unitary vector). There are two ways to define this axis.
+The first way is to define it from scratch, using its geometric definition:
+
+  * X axis is located at (0, 0, 0) - use the *gp_Pnt* class.
+  * X axis direction is (1, 0, 0) - use the *gp_Dir* class. A *gp_Dir* instance is created out of its X, Y and Z coordinates.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+    gp_Pnt aOrigin(0, 0, 0);
+    gp_Dir xDir(1, 0, 0);
+    gp_Ax1 xAxis(aOrigin, xDir);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The second and simplest way is to use the geometric constants defined in the gp package (origin, main directions and axis of the global coordinate system). To get the X axis, just call the *gp::OX* method:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+    gp_Ax1 xAxis = gp::OX();
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+As previously explained, the 3D geometric transformation is defined with the *gp_Trsf* class. There are two different ways to use this class:
+
+  * by defining a transformation matrix by all its values
+  * by using the appropriate methods corresponding to the required transformation (SetTranslation for a translation, SetMirror for a reflection, etc.): the matrix is automatically computed.
+    
+Since the simplest approach is always the best one, you should use the SetMirror method with the axis as the center of symmetry.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+    gp_Trsf aTrsf;
+    aTrsf.SetMirror(xAxis);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You now have all necessary data to apply the transformation with the BRepBuilderAPI_Transform class by specifying:
+
+  * the shape on which the transformation must be applied.
+  * the geometric transformation
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+    BRepBuilderAPI_Transform aBRepTrsf(aWire, aTrsf);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+*BRepBuilderAPI_Transform* does not modify the nature of the shape: the result of the reflected wire remains a wire. But the function-like call or the *BRepBuilderAPI_Transform::Shape* method returns a *TopoDS_Shape* object:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+    TopoDS_Shape aMirroredShape = aBRepTrsf.Shape();
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+What you need is a method to consider the resulting reflected shape as a wire. The *TopoDS* global functions provide this kind of service by casting a shape into its real type. To cast the transformed wire, use the *TopoDS::Wire* method.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+    TopoDS_Wire aMirroredWire = TopoDS::Wire(aMirroredShape);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The bottle's profile is almost finished. You have created two wires: *aWire* and *aMirroredWire*. You need to concatenate them to compute a single shape. To do this, you use the *BRepBuilderAPI_MakeWire* class as follows:
+
+  * create an instance of *BRepBuilderAPI_MakeWire*.
+  * add all edges of the two wires by using the *Add* method on this object.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+    BRepBuilderAPI_MakeWire mkWire;
+    mkWire.Add(aWire);
+    mkWire.Add(aMirroredWire);
+    TopoDS_Wire myWireProfile = mkWire.Wire();
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+@section sec3 Building the Body
+
+
+@subsection OCCT_TUTORIAL_SUB3_1 Prism the Profile
+
+
+To compute the main body of the bottle, you need to create a solid shape. The simplest way is to use the previously created profile and to sweep it along a direction. The *Prism* functionality of Open CASCADE Technology is the most appropriate for that task. It accepts a shape and a direction as input and generates a new shape according to the following rules:
+
+| Shape  | Generates          |
+| :----- | :----------------- |
+| Vertex | Edge               |
+| Edge   | Face               |
+| Wire   | Shell              |
+| Face   | Solid              |
+| Shell  | Compound of Solids |
+
+![](/overview/tutorial/images/tutorial_image007.png "")
+
+Your current profile is a wire. Referring to the Shape/Generates table, you need to compute a face out of its wire to generate a solid.
+To create a face, use the *BRepBuilderAPI_MakeFace* class. As previously explained, a face is a part of a surface bounded by a closed wire. Generally, *BRepBuilderAPI_MakeFace* computes a face out of a surface and one or more wires.
+When the wire lies on a plane, the surface is automatically computed.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+    TopoDS_Face myFaceProfile = BRepBuilderAPI_MakeFace(myWireProfile);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The *BRepPrimAPI* package provides all the classes to create topological primitive constructions: boxes, cones, cylinders, spheres, etc. Among them is the *BRepPrimAPI_MakePrism* class. As specified above, the prism is defined by:
+
+  * the basis shape to sweep;
+  * a vector for a finite prism or a direction for finite and infinite prisms.
+
+You want the solid to be finite, swept along the Z axis and to be myHeight height. The vector, defined with the *gp_Vec* class on its X, Y and Z coordinates, is:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+    gp_Vec aPrismVec(0, 0, myHeight);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+All the necessary data to create the main body of your bottle is now available. Just apply the *BRepPrimAPI_MakePrism* class to compute the solid:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+    TopoDS_Shape myBody = BRepPrimAPI_MakePrism(myFaceProfile, aPrismVec);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+@subsection OCCT_TUTORIAL_SUB3_2 Applying Fillets
+
+
+The edges of the bottle's body are very sharp. To replace them by rounded faces, you use the *Fillet* functionality of Open CASCADE Technology.
+For our purposes, we will specify that fillets must be:
+
+  * applied on all edges of the shape
+  * have a radius of *myThickness* / 12
+
+![](/overview/tutorial/images/tutorial_image008.png "")
+
+To apply fillets on the edges of a shape, you use the *BRepFilletAPI_MakeFillet* class. This class is normally used as follows:
+
+  * Specify the shape to be filleted in the *BRepFilletAPI_MakeFillet* constructor.
+  * Add the fillet descriptions (an edge and a radius) using the *Add* method (you can add as many edges as you need).
+  * Ask for the resulting filleted shape with the *Shape* method.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+BRepFilletAPI_MakeFillet mkFillet(myBody);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To add the fillet description, you need to know the edges belonging to your shape. The best solution is to explore your solid to retrieve its edges. This kind of functionality is provided with the *TopExp_Explorer* class, which explores the data structure described in a *TopoDS_Shape* and extracts the sub-shapes you specifically need. 
+Generally, this explorer is created by providing the following information:
+
+  * the shape to explore
+  * the type of sub-shapes to be found. This information is given with the *TopAbs_ShapeEnum* enumeration.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+TopExp_Explorer anEdgeExplorer(myBody, TopAbs_EDGE);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+An explorer is usually applied in a loop by using its three main methods:
+
+  * *More()* to know if there are more sub-shapes to explore.
+  * *Current()* to know which is the currently explored sub-shape (used only if the *More()* method returns true).
+  * *Next()* to move onto the next sub-shape to explore.
+
+  
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+    while(anEdgeExplorer.More()){
+        TopoDS_Edge anEdge = TopoDS::Edge(anEdgeExplorer.Current());
+        //Add edge to fillet algorithm
+        ...
+        anEdgeExplorer.Next();
+    }
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In the explorer loop, you have found all the edges of the bottle shape. Each one must then be added in the *BRepFilletAPI_MakeFillet* instance with the *Add()* method. Do not forget to specify the radius of the fillet along with it.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+    mkFillet.Add(myThickness / 12., anEdge);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Once this is done, you perform the last step of the procedure by asking for the filleted shape.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+    myBody = mkFillet.Shape();
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+@subsection OCCT_TUTORIAL_SUB3_3 Adding the Neck
+
+
+To add a neck to the bottle, you will create a cylinder and fuse it to the body. The cylinder is to be positioned on the top face of the body with a radius of *myThickness* / 4. and a height of *myHeight* / 10.
+
+![](/overview/tutorial/images/tutorial_image009.png "")
+
+To position the cylinder, you need to define a coordinate system with the *gp_Ax2* class defining a right-handed coordinate system from a point and two directions - the main (Z) axis direction and the X direction (the Y direction is computed from these two).
+To align the neck with the center of the top face, being in the global coordinate system (0, 0, *myHeight*), with its normal on the global Z axis, your local coordinate system can be defined as follows:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+    gp_Pnt neckLocation(0, 0, myHeight);
+    gp_Dir neckAxis = gp::DZ();
+    gp_Ax2 neckAx2(neckLocation, neckAxis);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To create a cylinder, use another class from the primitives construction package: the *BRepPrimAPI_MakeCylinder* class. The information you must provide is:
+
+  * the coordinate system where the cylinder will be located;
+  * the radius and height.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+    Standard_Real myNeckRadius = myThickness / 4.;
+    Standard_Real myNeckHeight = myHeight / 10;
+    BRepPrimAPI_MakeCylinder MKCylinder(neckAx2, myNeckRadius, myNeckHeight);
+    TopoDS_Shape myNeck = MKCylinder.Shape();
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You now have two separate parts: a main body and a neck that you need to fuse together.
+The *BRepAlgoAPI* package provides services to perform Boolean operations between shapes, and especially: *common* (Boolean intersection), *cut* (Boolean subtraction) and *fuse* (Boolean union).
+Use *BRepAlgoAPI_Fuse* to fuse the two shapes:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+    myBody = BRepAlgoAPI_Fuse(myBody, myNeck);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+@subsection OCCT_TUTORIAL_SUB3_4 Creating a Hollowed Solid
+
+
+Since a real bottle is used to contain liquid material, you should now create a hollowed solid from the bottle's top face.
+In Open CASCADE Technology, a hollowed solid is called a *Thick* *Solid* and is internally computed as follows:
+
+  * Remove one or more faces from the initial solid to obtain the first wall W1 of the hollowed solid.
+  * Create a parallel wall W2 from W1 at a distance D. If D is positive, W2 will be outside the initial solid, otherwise it will be inside.
+  * Compute a solid from the two walls W1 and W2.
+
+![](/overview/tutorial/images/tutorial_image010.png "")
+    
+To compute a thick solid, you create an instance of the *BRepOffsetAPI_MakeThickSolid* class by giving the following information:
+    
+  * The shape, which must be hollowed.
+  * The tolerance used for the computation (tolerance criterion for coincidence in generated shapes).
+  * The thickness between the two walls W1 and W2 (distance D).
+  * The face(s) to be removed from the original solid to compute the first wall W1.
+    
+The challenging part in this procedure is to find the face to remove from your shape - the top face of the neck, which:
+    
+  * has a plane (planar surface) as underlying geometry;
+  * is the highest face (in Z coordinates) of the bottle.
+    
+To find the face with such characteristics, you will once again use an explorer to iterate on all the bottle's faces to find the appropriate one.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+    for(TopExp_Explorer aFaceExplorer(myBody, TopAbs_FACE) ; aFaceExplorer.More() ; aFaceExplorer.Next()){
+        TopoDS_Face aFace = TopoDS::Face(aFaceExplorer.Current());
+    }
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+For each detected face, you need to access the geometric properties of the shape: use the *BRep_Tool* class for that. The most commonly used methods of this class are:
+    
+  * *Surface* to access the surface of a face;
+  * *Curve* to access the 3D curve of an edge;
+  * *Point* to access the 3D point of a vertex.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+Handle(Geom_Surface) aSurface = BRep_Tool::Surface(aFace);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+As you can see, the *BRep_Tool::Surface* method returns an instance of the *Geom_Surface* class manipulated by handle. However, the *Geom_Surface* class does not provide information about the real type of the object *aSurface*, which could be an instance of *Geom_Plane*, *Geom_CylindricalSurface*, etc.
+All objects manipulated by handle, like *Geom_Surface*, inherit from the *Standard_Transient* class which provides two very useful methods concerning types:
+
+  * *DynamicType* to know the real type of the object
+  * *IsKind* to know if the object inherits from one particular type
+
+DynamicType returns the real type of the object, but you need to compare it with the existing known types to determine whether *aSurface* is a plane, a cylindrical surface or some other type.
+To compare a given type with the type you seek, use the *STANDARD_TYPE* macro, which returns the type of a class:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+    if(aSurface->DynamicType() == STANDARD_TYPE(Geom_Plane)){
+    //
+    }
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If this comparison is true, you know that the *aSurface* real type is *Geom_Plane*. You can then convert it from *Geom_Surface* to *Geom_Plane* by using the *DownCast()* method provided by each class inheriting *Standard_Transient*. As its name implies, this static method is used to downcast objects to a given type with the following syntax:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+    Handle(Geom_Plane) aPlane = Handle(Geom_Plane)::DownCast(aSurface);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Remember that the goal of all these conversions is to find the highest face of the bottle lying on a plane. Suppose that you have these two global variables:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+    TopoDS_Face faceToRemove;
+    Standard_Real zMax = -1;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You can easily find the plane whose origin is the biggest in Z knowing that the location of the plane is given with the *Geom_Plane::Location* method. For example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+    gp_Pnt aPnt = aPlane->Location();
+    Standard_Real aZ = aPnt.Z();
+    if(aZ > zMax){
+        zMax = aZ;
+        faceToRemove = aFace;
+    }
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You have now found the top face of the neck. Your final step before creating the hollowed solid is to put this face in a list. Since more than one face can be removed from the initial solid, the *BRepOffsetAPI_MakeThickSolid* constructor takes a list of faces as arguments.
+Open CASCADE Technology provides many collections for different kinds of objects: see *TColGeom* package for collections of objects from *Geom* package, *TColgp* package for collections of objects from gp package, etc.
+The collection for shapes can be found in the *TopTools* package. As *BRepOffsetAPI_MakeThickSolid* requires a list, use the *TopTools_ListOfShape* class.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+    TopTools_ListOfShape facesToRemove;
+    facesToRemove.Append(faceToRemove);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+All the necessary data are now available so you can create your hollowed solid by calling the *BRepOffsetAPI_MakeThickSolid* constructor:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+    MyBody = BRepOffsetAPI_MakeThickSolid(myBody, facesToRemove, -myThickness / 50, 1.e-3);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+@section sec4 Building the Threading
+
+
+@subsection OCCT_TUTORIAL_SUB4_1 Creating Surfaces
+
+
+Up to now, you have learned how to create edges out of 3D curves.
+You will now learn how to create an edge out of a 2D curve and a surface.
+To learn this aspect of Open CASCADE Technology, you will build helicoidal profiles out of 2D curves on cylindrical surfaces. The theory is more complex than in previous steps, but applying it is very simple.
+As a first step, you compute these cylindrical surfaces. You are already familiar with curves of the *Geom* package. Now you can create a cylindrical surface (*Geom_CylindricalSurface*) using:
+
+  * a coordinate system;
+  * a radius.
+
+Using the same coordinate system *neckAx2* used to position the neck, you create two cylindrical surfaces *Geom_CylindricalSurface* with the following radii:
+
+![](/overview/tutorial/images/tutorial_image011.png "")
+
+Notice that one of the cylindrical surfaces is smaller than the neck. There is a good reason for this: after the thread creation, you will fuse it with the neck. So, we must make sure that the two shapes remain in contact.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+    Handle(Geom_CylindricalSurface) aCyl1 = new Geom_CylindricalSurface(neckAx2, myNeckRadius * 0.99);
+
+    Handle(Geom_CylindricalSurface) aCyl2 = new Geom_CylindricalSurface(neckAx2, myNeckRadius * 1.05);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+@subsection OCCT_TUTORIAL_SUB4_2 Defining 2D Curves
+
+
+To create the neck of the bottle, you made a solid cylinder based on a cylindrical surface. You will create the profile of threading by creating 2D curves on such a surface.
+All geometries defined in the *Geom* package are parameterized. This means that each curve or surface from Geom is computed with a parametric equation.
+A *Geom_CylindricalSurface* surface is defined with the following parametric equation:
+
+P(U, V) = O + R * (cos(U) * xDir + sin(U) * yDir) + V * zDir, where :
+
+  * P is the point defined by parameters (U, V).
+  * O, *Dir, yDir and zDir are respectively the origin, the X direction, Y direction and Z direction of the cylindrical surface local coordinate system.
+  * R is the radius of the cylindrical surface.
+  * U range is [0, 2PI] and V is infinite.
+
+![](/overview/tutorial/images/tutorial_image012.png "")
+
+The advantage of having such parameterized geometries is that you can compute, for any (U, V) parameters of the surface:
+
+  * the 3D point;
+  * the derivative vectors of order 1, 2 to N at this point.
+
+There is another advantage of these parametric equations: you can consider a surface as a 2D parametric space defined with a (U, V) coordinate system. For example, consider the parametric ranges of the neck's surface:
+
+![](/overview/tutorial/images/tutorial_image013.png "")
+
+Suppose that you create a 2D line on this parametric (U, V) space and compute its 3D parametric curve. Depending on the line definition, results are as follows:
+
+| Case          | Parametric Equation                                          | Parametric Curve                                                              |
+| :------------ | :----------------------------------------------------------- | :---------------------------------------------------------------------------- |
+| U = 0         | P(V) = O + V * zDir                                          | Line parallel to the Z direction                                              |
+| V = 0         | P(U) = O + R * (cos(U) * xDir + sin(U) * yDir)               | Circle parallel to the (O, X, Y) plane                                        |
+| U != 0 V != 0 | P(U, V) = O + R * (cos(U) * xDir + sin(U) * yDir) + V * zDir | Helicoidal curve describing the evolution of height and angle on the cylinder |
+
+The helicoidal curve type is exactly what you need. On the neck's surface, the evolution laws of this curve will be:
+
+  * In V parameter: between 0 and myHeighNeck for the height description
+  * In U parameter: between 0 and 2PI for the angle description. But, since a cylindrical surface is U periodic, you can decide to extend this angle evolution to 4PI as shown in the following drawing:
+
+![](/overview/tutorial/images/tutorial_image014.png "")
+
+In this (U, V) parametric space, you will create a local (X, Y) coordinate system to position the curves to be created. This coordinate system will be defined with:
+
+  * A center located in the middle of the neck's cylinder parametric space at (2*PI, myNeckHeight / 2) in U, V coordinates.
+  * A X direction defined with the (2*PI, myNeckHeight/4) vector in U, V coordinates, so that the curves occupy half of the neck's surfaces.
+  
+![](/overview/tutorial/images/tutorial_image015.png "")
+  
+To use 2D primitive geometry types of Open CASCADE Technology for defining a point and a coordinate system, you will once again instantiate classes from gp:
+
+  * To define a 2D point from its X and Y coordinates, use the *gp_Pnt2d* class.
+  * To define a 2D direction (unit vector) from its X and Y coordinates, use the gp_Dir2d class. The coordinates will automatically be normalized.
+  * To define a 2D right-handed coordinate system, use the *gp_Ax2d* class, which is computed from a point (origin of the coordinate system) and a direction - the X direction of the coordinate system. The Y direction will be automatically computed.
+  
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+    gp_Pnt2d aPnt(2. * M_PI, myNeckHeight / 2.);
+    gp_Dir2d aDir(2. * M_PI, myNeckHeight / 4.);
+    gp_Ax2d anAx2d(aPnt, aDir);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You will now define the curves. As previously mentioned, these thread profiles are computed on two cylindrical surfaces. In the following figure, curves on the left define the base (on *aCyl1* surface) and the curves on the right define the top of the thread's shape (on *aCyl2* surface).
+
+![](/overview/tutorial/images/tutorial_image016.png "")
+
+You have already used the *Geom* package to define 3D geometric entities. For 2D, you will use the *Geom2d* package. As for *Geom*, all geometries are parameterized. For example, a *Geom2d_Ellipse* ellipse is defined from:
+
+  * a coordinate system whose origin is the ellipse center;
+  * a major radius on the major axis defined by the X direction of the coordinate system;
+  * a minor radius on the minor axis defined by the Y direction of the coordinate system.
+
+Supposing that:
+
+  * Both ellipses have the same major radius of 2*PI,
+  * Minor radius of the first ellipse is myNeckHeight / 10,
+  * And the minor radius value of the second ellipse is a fourth of the first one,
+
+Your ellipses are defined as follows:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+    Standard_Real aMajor = 2. * M_PI;
+    Standard_Real aMinor = myNeckHeight / 10;
+    Handle(Geom2d_Ellipse) anEllipse1 = new Geom2d_Ellipse(anAx2d, aMajor, aMinor);
+    Handle(Geom2d_Ellipse) anEllipse2 = new Geom2d_Ellipse(anAx2d, aMajor, aMinor / 4);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To describe portions of curves for the arcs drawn above, you define *Geom2d_TrimmedCurve* trimmed curves out of the created ellipses and two parameters to limit them.
+As the parametric equation of an ellipse is P(U) = O + (MajorRadius * cos(U) * XDirection) + (MinorRadius * sin(U) * YDirection), the ellipses need to be limited between 0 and M_PI.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+    Handle(Geom2d_TrimmedCurve) anArc1 = new Geom2d_TrimmedCurve(anEllipse1, 0, M_PI);
+    Handle(Geom2d_TrimmedCurve) anArc2 = new Geom2d_TrimmedCurve(anEllipse2, 0, M_PI);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The last step consists in defining the segment, which is the same for the two profiles: a line limited by the first and the last point of one of the arcs.
+To access the point corresponding to the parameter of a curve or a surface, you use the Value or D0 method (meaning 0th derivative), D1 method is for first derivative, D2 for the second one.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+    gp_Pnt2d anEllipsePnt1 = anEllipse1->Value(0);
+    gp_Pnt2d anEllipsePnt2;
+    anEllipse1->D0(M_PI, anEllipsePnt2);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+When creating the bottle's profile, you used classes from the *GC* package, providing algorithms to create elementary geometries.
+In 2D geometry, this kind of algorithms is found in the *GCE2d* package. Class names and behaviors are similar to those in *GC*. For example, to create a 2D segment out of two points:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+    Handle(Geom2d_TrimmedCurve) aSegment = GCE2d_MakeSegment(anEllipsePnt1, anEllipsePnt2);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+@subsection OCCT_TUTORIAL_SUB4_3 Building Edges and Wires
+
+
+As you did when creating the base profile of the bottle, you can now:
+
+  * compute the edges of the neck's threading.
+  * compute two wires out of these edges.
+
+![](/overview/tutorial/images/tutorial_image017.png "")
+
+Previously, you have built:
+
+  * two cylindrical surfaces of the threading
+  * three 2D curves defining the base geometry of the threading
+
+To compute the edges out of these curves, once again use the *BRepBuilderAPI_MakeEdge* class. One of its constructors allows you to build an edge out of a curve described in the 2D parametric space of a surface.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+    TopoDS_Edge anEdge1OnSurf1 = BRepBuilderAPI_MakeEdge(anArc1, aCyl1);
+    TopoDS_Edge anEdge2OnSurf1 = BRepBuilderAPI_MakeEdge(aSegment, aCyl1);
+    TopoDS_Edge anEdge1OnSurf2 = BRepBuilderAPI_MakeEdge(anArc2, aCyl2);
+    TopoDS_Edge anEdge2OnSurf2 = BRepBuilderAPI_MakeEdge(aSegment, aCyl2);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Now, you can create the two profiles of the threading, lying on each surface.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+    TopoDS_Wire threadingWire1 = BRepBuilderAPI_MakeWire(anEdge1OnSurf1, anEdge2OnSurf1);
+    TopoDS_Wire threadingWire2 = BRepBuilderAPI_MakeWire(anEdge1OnSurf2, anEdge2OnSurf2);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Remember that these wires were built out of a surface and 2D curves.
+One important data item is missing as far as these wires are concerned: there is no information on the 3D curves. Fortunately, you do not need to compute this yourself, which can be a difficult task since the mathematics can be quite complex.
+When a shape contains all the necessary information except 3D curves, Open CASCADE Technology provides a tool to build them automatically. In the BRepLib tool package, you can use the *BuildCurves3d* method to compute 3D curves for all the edges of a shape.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} 
+    BRepLib::BuildCurves3d(threadingWire1);
+    BRepLib::BuildCurves3d(threadingWire2);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+@subsection OCCT_TUTORIAL_SUB4_4 Creating Threading
+
+
+You have computed the wires of the threading. The threading will be a solid shape, so you must now compute the faces of the wires, the faces allowing you to join the wires, the shell out of these faces and then the solid itself. This can be a lengthy operation.
+There are always faster ways to build a solid when the base topology is defined. You would like to create a solid out of two wires. Open CASCADE Technology provides a quick way to do this by building a loft: a shell or a solid passing through a set of wires in a given sequence.   
+The loft function is implemented in the *BRepOffsetAPI_ThruSections* class, which you use as follows:
+  
+![](/overview/tutorial/images/tutorial_image018.png "")
+  
+  * Initialize the algorithm by creating an instance of the class. The first parameter of this constructor must be specified if you want to create a solid. By default, *BRepOffsetAPI_ThruSections* builds a shell.
+  * Add the successive wires using the AddWire method.
+  * Use the *CheckCompatibility* method to activate (or deactivate) the option that checks whether the wires have the same number of edges. In this case, wires have two edges each, so you can deactivate this option.
+  * Ask for the resulting loft shape with the Shape method.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} 
+    BRepOffsetAPI_ThruSections aTool(Standard_True);
+    aTool.AddWire(threadingWire1); aTool.AddWire(threadingWire2);
+    aTool.CheckCompatibility(Standard_False);
+    TopoDS_Shape myThreading = aTool.Shape();
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+@section sec5 Building the Resulting Compound
+
+
+You are almost done building the bottle. Use the *TopoDS_Compound* and *BRep_Builder* classes to build single shape from *myBody* and *myThreading*:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} 
+    TopoDS_Compound aRes;
+    BRep_Builder aBuilder;
+    aBuilder.MakeCompound (aRes);
+    aBuilder.Add (aRes, myBody);
+    aBuilder.Add (aRes, myThreading);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Congratulations! Your bottle is complete. Here is the result snapshot of the Tutorial application:
+
+![](/overview/tutorial/images/tutorial_image019.png "")
+
+We hope that this tutorial has provided you with a feel for the industrial strength power of Open CASCADE Technology.
+If you want to know more and develop major projects using Open CASCADE Technology, we invite you to study our training, support, and consulting services on our site at http://www.opencascade.org/support. Our professional services can maximize the power of your Open CASCADE Technology applications.
+
+
+@section sec6 Appendix
+
+
+Complete definition of MakeBottle function (defined in the file src/MakeBottle.cxx of the Tutorial):
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} 
+    TopoDS_Shape MakeBottle(const Standard_Real myWidth, const Standard_Real myHeight,
+                            const Standard_Real myThickness)
+    {
+        // Profile : Define Support Points
+        gp_Pnt aPnt1(-myWidth / 2., 0, 0);        
+        gp_Pnt aPnt2(-myWidth / 2., -myThickness / 4., 0);
+        gp_Pnt aPnt3(0, -myThickness / 2., 0);
+        gp_Pnt aPnt4(myWidth / 2., -myThickness / 4., 0);
+        gp_Pnt aPnt5(myWidth / 2., 0, 0);
+
+        // Profile : Define the Geometry
+        Handle(Geom_TrimmedCurve) anArcOfCircle = GC_MakeArcOfCircle(aPnt2,aPnt3,aPnt4);
+        Handle(Geom_TrimmedCurve) aSegment1 = GC_MakeSegment(aPnt1, aPnt2);
+        Handle(Geom_TrimmedCurve) aSegment2 = GC_MakeSegment(aPnt4, aPnt5);
+
+        // Profile : Define the Topology
+        TopoDS_Edge anEdge1 = BRepBuilderAPI_MakeEdge(aSegment1);
+        TopoDS_Edge anEdge2 = BRepBuilderAPI_MakeEdge(anArcOfCircle);
+        TopoDS_Edge anEdge3 = BRepBuilderAPI_MakeEdge(aSegment2);
+        TopoDS_Wire aWire  = BRepBuilderAPI_MakeWire(anEdge1, anEdge2, anEdge3);
+
+        // Complete Profile
+        gp_Ax1 xAxis = gp::OX();
+        gp_Trsf aTrsf;
+
+        aTrsf.SetMirror(xAxis);
+        BRepBuilderAPI_Transform aBRepTrsf(aWire, aTrsf);
+        TopoDS_Shape aMirroredShape = aBRepTrsf.Shape();
+        TopoDS_Wire aMirroredWire = TopoDS::Wire(aMirroredShape);
+
+        BRepBuilderAPI_MakeWire mkWire;
+        mkWire.Add(aWire);
+        mkWire.Add(aMirroredWire);
+        TopoDS_Wire myWireProfile = mkWire.Wire();
+
+        // Body : Prism the Profile
+        TopoDS_Face myFaceProfile = BRepBuilderAPI_MakeFace(myWireProfile);
+        gp_Vec aPrismVec(0, 0, myHeight);
+        TopoDS_Shape myBody = BRepPrimAPI_MakePrism(myFaceProfile, aPrismVec);
+
+        // Body : Apply Fillets
+        BRepFilletAPI_MakeFillet mkFillet(myBody);
+        TopExp_Explorer anEdgeExplorer(myBody, TopAbs_EDGE);
+        while(anEdgeExplorer.More()){
+            TopoDS_Edge anEdge = TopoDS::Edge(anEdgeExplorer.Current());
+            //Add edge to fillet algorithm
+            mkFillet.Add(myThickness / 12., anEdge);
+            anEdgeExplorer.Next();
+        }
+
+        myBody = mkFillet.Shape();
+
+        // Body : Add the Neck
+        gp_Pnt neckLocation(0, 0, myHeight);
+        gp_Dir neckAxis = gp::DZ();
+        gp_Ax2 neckAx2(neckLocation, neckAxis);
+
+        Standard_Real myNeckRadius = myThickness / 4.;
+        Standard_Real myNeckHeight = myHeight / 10.;
+
+        BRepPrimAPI_MakeCylinder MKCylinder(neckAx2, myNeckRadius, myNeckHeight);
+        TopoDS_Shape myNeck = MKCylinder.Shape();
+
+        myBody = BRepAlgoAPI_Fuse(myBody, myNeck);
+
+        // Body : Create a Hollowed Solid
+        TopoDS_Face   faceToRemove;
+        Standard_Real zMax = -1;
+
+        for(TopExp_Explorer aFaceExplorer(myBody, TopAbs_FACE); aFaceExplorer.More(); aFaceExplorer.Next()){
+            TopoDS_Face aFace = TopoDS::Face(aFaceExplorer.Current());
+            // Check if <aFace> is the top face of the bottle's neck 
+            Handle(Geom_Surface) aSurface = BRep_Tool::Surface(aFace);
+            if(aSurface->DynamicType() == STANDARD_TYPE(Geom_Plane)){
+                Handle(Geom_Plane) aPlane = Handle(Geom_Plane)::DownCast(aSurface);
+                gp_Pnt aPnt = aPlane->Location();
+                Standard_Real aZ   = aPnt.Z();
+                if(aZ > zMax){
+                    zMax = aZ;
+                    faceToRemove = aFace;
+                }
+            }
+        }
+
+        TopTools_ListOfShape facesToRemove;
+        facesToRemove.Append(faceToRemove);
+        myBody = BRepOffsetAPI_MakeThickSolid(myBody, facesToRemove, -myThickness / 50, 1.e-3);
+        // Threading : Create Surfaces
+        Handle(Geom_CylindricalSurface) aCyl1 = new Geom_CylindricalSurface(neckAx2, myNeckRadius * 0.99);
+        Handle(Geom_CylindricalSurface) aCyl2 = new Geom_CylindricalSurface(neckAx2, myNeckRadius * 1.05);
+
+        // Threading : Define 2D Curves
+        gp_Pnt2d aPnt(2. * M_PI, myNeckHeight / 2.);
+        gp_Dir2d aDir(2. * M_PI, myNeckHeight / 4.);
+        gp_Ax2d anAx2d(aPnt, aDir);
+
+        Standard_Real aMajor = 2. * M_PI;
+        Standard_Real aMinor = myNeckHeight / 10;
+
+        Handle(Geom2d_Ellipse) anEllipse1 = new Geom2d_Ellipse(anAx2d, aMajor, aMinor);
+        Handle(Geom2d_Ellipse) anEllipse2 = new Geom2d_Ellipse(anAx2d, aMajor, aMinor / 4);
+        Handle(Geom2d_TrimmedCurve) anArc1 = new Geom2d_TrimmedCurve(anEllipse1, 0, M_PI);
+        Handle(Geom2d_TrimmedCurve) anArc2 = new Geom2d_TrimmedCurve(anEllipse2, 0, M_PI);
+        gp_Pnt2d anEllipsePnt1 = anEllipse1->Value(0);
+        gp_Pnt2d anEllipsePnt2 = anEllipse1->Value(M_PI);
+
+        Handle(Geom2d_TrimmedCurve) aSegment = GCE2d_MakeSegment(anEllipsePnt1, anEllipsePnt2);
+        // Threading : Build Edges and Wires
+        TopoDS_Edge anEdge1OnSurf1 = BRepBuilderAPI_MakeEdge(anArc1, aCyl1);
+        TopoDS_Edge anEdge2OnSurf1 = BRepBuilderAPI_MakeEdge(aSegment, aCyl1);
+        TopoDS_Edge anEdge1OnSurf2 = BRepBuilderAPI_MakeEdge(anArc2, aCyl2);
+        TopoDS_Edge anEdge2OnSurf2 = BRepBuilderAPI_MakeEdge(aSegment, aCyl2);
+        TopoDS_Wire threadingWire1 = BRepBuilderAPI_MakeWire(anEdge1OnSurf1, anEdge2OnSurf1);
+        TopoDS_Wire threadingWire2 = BRepBuilderAPI_MakeWire(anEdge1OnSurf2, anEdge2OnSurf2);
+        BRepLib::BuildCurves3d(threadingWire1);
+        BRepLib::BuildCurves3d(threadingWire2);
+
+        // Create Threading 
+        BRepOffsetAPI_ThruSections aTool(Standard_True);
+        aTool.AddWire(threadingWire1);
+        aTool.AddWire(threadingWire2);
+        aTool.CheckCompatibility(Standard_False);
+
+        TopoDS_Shape myThreading = aTool.Shape();
+
+        // Building the Resulting Compound 
+        TopoDS_Compound aRes;
+        BRep_Builder aBuilder;
+        aBuilder.MakeCompound (aRes);
+        aBuilder.Add (aRes, myBody);
+        aBuilder.Add (aRes, myThreading);
+
+        return aRes;
+    }
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/dox/resources/occt_logo.png b/dox/resources/occt_logo.png
new file mode 100644 (file)
index 0000000..0e5a04c
Binary files /dev/null and b/dox/resources/occt_logo.png differ
diff --git a/dox/start.tcl b/dox/start.tcl
new file mode 100644 (file)
index 0000000..c44be9f
--- /dev/null
@@ -0,0 +1,5 @@
+# Command-line starter for occdoc command, use it as follows:
+# tclsh> source dox/start.tcl [arguments]
+
+source [file join [file dirname [info script]] occdoc.tcl]
+occdoc {*}$argv
\ No newline at end of file
diff --git a/dox/technical_overview/images/technical_overview_over.png b/dox/technical_overview/images/technical_overview_over.png
new file mode 100644 (file)
index 0000000..a24710a
Binary files /dev/null and b/dox/technical_overview/images/technical_overview_over.png differ
diff --git a/dox/technical_overview/technical_overview.md b/dox/technical_overview/technical_overview.md
new file mode 100644 (file)
index 0000000..dbe751f
--- /dev/null
@@ -0,0 +1,3017 @@
+Technical Overview {#technical_overview}
+========================================
+
+@section OCCT_TOVW_SECTION_1 Product Overview
+
+Open CASCADE Technology is an object-oriented C++ class librarLzlz ljky designed for rapid
+production of sophisticated domain-specific design applications. A typical application
+developed using OCCT deals with two or three-dimensional (2D or 3D) geometric modeling
+in general-purpose or specialized Computer Aided Design (CAD) systems, manufacturing
+or analysis applications, simulation applications, or illustration tools. OCCT Object
+Libraries help you to develop your applications significantly faster.
+
+![](/technical_overview/images/technical_overview_over.png "")
+
+The OCCT Library provides the following services:
+
+
+  * 2D and 3D geometric modeling toolkits which allow you to model any type of object:
+    * Creating primitives such as prism, cylinder, cone and torus 
+    * Performing Boolean operations (addition, subtraction and intersection) 
+    * Tweaking constructions using fillets, chamfers and drafts 
+    * Modeling constructions using offsets, shelling, hollowing and sweeps 
+    * Computing properties such as surface, volume, center of gravity, curvature 
+    * Computing geometry using projection, interpolation, approximation 
+  * Visualization services that allow you to manage object display and manipulate views, for example:
+    * 3D rotation 
+    * Zoom 
+    * Shading 
+  * The application framework features: 
+    * Association between non-geometric application data and geometry 
+    * Parameterization of models 
+    * Java Application Desktop (JAD), a framework for creating your Graphical User Interfaces (GUI) 
+  * Data exchange providing import and export functions of OCCT models to and from standard formats such as IGES and STEP 
+
+OCCT Library is developed and marketed by OPEN CASCADE Company. The library is designed
+to be truly modular and extensible. As such, they separate C++ classes for:
+
+  * Defining data structures (geometric modeling, display and graphic selection) 
+  * Implementing complex algorithms 
+  * Providing Application Programming Interfaces (APIs) 
+
+
+Related classes are grouped into packages to prevent any class-name conflicts; 
+C++ class-names are prefixed by a package name. For example, all classes defining 
+3D geometric objects belong to the Geompackage. 
+In Geom, the class implementing Bezier surfaces is called BezierSurface, and its full name is <i> Geom_BezierSurface</i>.
+
+Packages are then archived into libraries, to which you can link your application.
+
+Finally, libraries are grouped into six modules: Foundation Classes, 
+Modeling Data, Modeling Algorithms, Visualization, Data Exchange and Application Framework. 
+
+In addition Draw Test Harness (Draw) provides testing tools for the Visualization, 
+Modeling Algorithms, Application Framework and Data Exchange modules. 
+These tools include a wide range of interpreted commands which allow experimenting with OCCT.
+
+Refer to the Technical Overview and OCCT documentation for details about the services provided in each module. 
+
+@section OCCT_TOVW_SECTION_2 Foundation Classes
+
+
+Foundation Classes provide a variety of general-purpose services such as:
+
+  * Primitive types, strings and various types of quantities 
+  * Automated management of heap memory 
+  * Exception handling 
+  * Classes for manipulating data collections
+  * Math tools such as vectors, matrices and primitive geometric types 
+  * Basic services for saving data in ASCII files 
+
+These services are organized into the following libraries:
+
+  * Kernel Classes 
+  * Math Utilities 
+  * Basic Persistence  
+
+The technical overview provides only a basic description of the libraries. Please, refer for more details to Foundation Classes User's guide
+
+See also: our web site at E-learning and Training.
+
+@subsection OCCT_TOVW_SECTION_2_1 Kernel Classes
+
+
+Root Classes
+------------
+
+Root Classes, primarily implemented in the Standard package, are the predefined classes on which
+all other Open CASCADE Technology classes are built. They provide:
+
+  * Primitive types such as Boolean, Character, Integer or Real 
+  * Memory manager based on reference counting for optimizing the allocation and deallocation of large numbers of small C++ objects 
+  * <i>Standard_Transient</i> class automating memory management through smart pointers
+  * OCCT <i>Handle</i>; most of OCCT classes inherit from this base class.
+  * Management of exceptions,
+  * Encapsulation of C++ streams.
+
+Quantities
+-----------
+
+Quantity classes provide the following services:
+
+  * Definition of primitive types representing most of mathematical and physical quantities
+  * Unit conversion tools.    
+  * Resources to manage time information such as dates and time periods 
+  * Resources to manage color definition 
+
+A mathematical quantity is characterized by the name and the value (real).
+A physical quantity is characterized by the name, the value (real) and the unit. 
+The unit may be either an international unit complying with the International Unit System (SI) 
+or a user defined unit. The unit is managed by the physical quantity user.
+
+The fact that both physical and mathematical quantities are manipulated as real
+values means that :
+
+  * They are defined as aliases of real values, so all functions provided by the <i>Standard_Real</i> class are available on each quantity.
+  * It is possible to mix several physical quantities in a mathematical or physical formula involving real values.
+
+<i>Quantity</i> package includes all commonly used basic physical quantities. 
+
+Exceptions
+----------
+
+Exception classes list all the exceptions, which can be raised by any OCCT function.
+
+Each exception inherits from Standard_Failure either directly or by inheriting from
+another exception.
+
+Exceptions describe anomalies which can occur during the execution of a method. With
+the raising of an exception, the normal course of program execution is abandoned.
+The execution of actions in response to this situation is called the treatment of
+the exception.
+
+
+The methods try & catch are redefined in OCCT to work properly on any platform. Nevertheless
+they call native mechanisms each time it is possible. The only reason not to use
+native exceptions is that they may not work properly on some compilers. In this case,
+a specific OCCT code is used instead. 
+
+
+Strings
+-------
+
+Strings are classes that handle dynamically sized sequences of characters based on
+ASCII/Unicode UTF-8 (normal 8-bit character type)
+and UTF-16/UCS-2 (16-bit character type). They provide editing operations with built-in
+memory management which make the relative objects easier to use than ordinary character
+arrays.
+
+String classes provide the following services to manipulate character strings:
+ * Editing operations on string objects, using a built-in string manager 
+ * Handling of dynamically-sized sequences of characters 
+ * Conversion from/to ASCII and UTF-8 strings. 
+
+Strings may also be manipulated by handles and therefore, can be shared.
+
+These classes are implemented in <i>TCollection</i> and <i>NCollection</i> packages.
+
+
+Collections
+-----------
+
+Apart from strings, the <i> TCollection</i> package contains classes of dynamically sized
+aggregates of data. They include a wide range of collections.
+
+  * Arrays (unidimensional and bidimensional) are generally used for quick access to an item.
+  Note that an array is a fixed-sized aggregate. 
+  * Sequences are ordered collections of non-unique objects. 
+  A sequence item is longer to access than an array item: only an exploration in sequence 
+  is efficient (but sequences are not adapted for numerous explorations). 
+  Arrays and sequences are commonly used as data structures for more complex objects.
+  * Maps are dynamic structures where the size is constantly adapted to the number of inserted
+  items and access to an item is the fastest. Maps structures are commonly used in
+  cases of numerous explorations: they are typically internal data structures for complex
+  algorithms. Sets generate the same results as maps but computation time is considerable.
+  * Lists, queues and stacks, which are minor structures similar to sequences but with different
+  algorithms to explore them 
+  * Specific iterators for sequences, maps, and stacks.
+
+Most collections follow value semantics: their instances are the actual collections,
+not handles to a collection. Only arrays, sequences and sets may also be manipulated
+by handle, and therefore shared.
+
+
+Collection classes are generic (C++ template-like), so they can contain 
+a variety of objects which do not necessarily inherit from
+a unique root class. When you need to use a collection of a given object type, you
+must instantiate the collection for this specific type. Once the code for this declaration
+is compiled, all functions available on the generic collection are available on your
+instantiated class.
+
+Each collection directly used as an argument in Open CASCADE Technology public syntax
+is instantiated in an OCCT component using the corresponding generic class in package
+<i> TCollection</i>, by means of compiling the CDL declaration of the instance. 
+Thus OCCT generic classes require compilation of definitions in the CDL language and therefore
+can only be instantiated in WOK.
+
+If you are not using CDL in your project (CDL compilation under WOK is necessary
+to instantiate any generic Collection from package <i>TCollection</i>), then you should
+use the Collections defined in <i> NCollection</i> package. It contains definitions of the
+same generic collection classes described above, but in a form of C++ templates.
+Therefore, to instantiate any collection type no additional support is required beyond
+the ANSI C++ compiler.
+
+@subsection OCCT_TOVW_SECTION_2_2 Math Utilities
+
+
+Vectors and Matrices
+--------------------
+
+The <i> Vector</i> and <i> Matrix </i> classes provide commonly used mathematical algorithms which
+include:
+
+  * Basic calculations involving vectors and matrices; 
+  * Computation of eigenvalues and eigenvectors of a square matrix; 
+  * Solvers for a set of linear algebraic equations; 
+  * Algorithms to find the roots of a set of non-linear equations; 
+  * Algorithms to find the minimum function of one or more independent variables. 
+
+These classes also provide a data structure to represent any expression,
+relation, or function used in mathematics, including the assignment of variables.
+
+Vectors and matrices have arbitrary ranges which must be defined at declaration time
+and cannot be changed after declaration. 
+
+~~~
+    math_Vector v(1, 3);
+    // a vector of dimension 3 with range (1..3)
+
+    math_Matrix m(0, 2, 0, 2);
+    // a matrix of dimension 3x3 with range (0..2, 0..2)
+
+    math_Vector v(N1, N2);
+    // a vector of dimension N2-N1+1 with range (N1..N2)
+~~~
+
+Vector and Matrix objects follow "value semantics", that is, they cannot be shared
+and are copied though assignment.
+
+~~~
+    math_Vector v1(1, 3), v2(0, 2);
+
+    v2 = v1; // v1 is copied into v2
+              // a modification of v1 does not affect v2
+~~~
+
+Vector and Matrix elements can be retrieved using indexes, which must be in the range
+defined upon Vector/Matrix creation. The elements can be initialized with some numerical
+value upon creation as well.
+
+~~~
+    math_Vector v(1, 3);
+    math_Matrix m(1, 3, 1, 3);
+    Standard_Real value;
+
+    v(2) = 1.0;
+    value = v(1);
+    m(1, 3) = 1.0;
+    value = m(2, 2);
+~~~
+
+Some operations on Vector and Matrix objects may not be legal. In this case an exception
+is raised. Two standard exceptions are used:
+ * <i> Standard_DimensionError </i> exception is raised when two matrices or vectors involved
+in an operation are of incompatible dimensions.
+ * <i> Standard_RangeError </i>exception is raised if an attempt to access outside the range
+defined upon creation of a vector or a matrix is made.
+
+~~~
+    math_Vector v1(1, 3), v2(1, 2), v3(0, 2);
+
+    v1 = v2;    // error:
+                // Standard_DimensionError is raised
+
+    v1 = v3;    // OK: ranges are not equal
+                // but dimensions are compatible
+
+    v1(0) = 2.0; // error:
+                 // Standard_RangeError is raised
+~~~
+
+
+Fundamental Geometry Types
+-------------------------
+
+The Fundamental Geometry Types component groups the following packages:
+
+  * geometric processor package <i> gp</i>;
+  * <i>GeomAbs</i> package, which provides enumerations generally used in geometry.
+
+<i>gp</i> package is a STEP-compliant implementation of basic geometric and algebraic
+entities, used to define and manipulate elementary data structures.
+
+In particular, <i>gp</i> provides:
+
+  * descriptions of primitive geometric shapes, such as:
+  * Points; 
+  * Vectors; 
+  * Lines; 
+  * Circles and conics; 
+  * Planes and elementary surfaces;
+  * positioning of these shapes in space or in a plane by means of an axis or a coordinate system;
+  * definition and application of geometric transformations to these shapes:
+  * Translations; 
+  * Rotations; 
+  * Symmetries; 
+  * Scaling transformations; 
+  * Composed transformations;
+  * Tools (coordinates and matrices) for algebraic computation.
+
+These functions are defined in 3D space and in the plane.
+
+<i> gp</i> curves and surfaces are analytic: there is no parameterization and no orientation 
+on <i>gp</i> entities, i.e. these entities do not provide functions which work with these properties. 
+If you need, you may use more evolved data structures provided by <i> Geom</i> 
+(in 3D space) and <i> Geom2d</i> (in the plane). However, the definition of <i> gp</i> entities 
+is identical to the one of equivalent <i> Geom</i> and <i> Geom2d</i> entities, and they are located
+in the plane or in space with the same kind of positioning systems. 
+They implicitly contain the orientation, which they express 
+on the <i> Geom </i> and <i> Geom2d </i> entities, and they induce the definition of their parameterization.
+
+
+Therefore, it is easy to give an implicit parameterization to <i> gp</i> curves and surfaces,
+which is the parametarization of the equivalent <i> Geom</i> or <i> Geom2d</i> entity. This property
+is particularly useful when computing projections or intersections, or for operations
+involving complex algorithms where it is particularly important to manipulate the
+simplest data structures, i.e. those of <i> gp</i>. Thus, the <i> ElCLib</i> and <i> ElSLib</i> packages
+provide functions to compute:
+
+  * the point of parameter u on a 2D or 3D gp curve,
+  * the point of parameter (u,v) on a gp elementary surface, and
+  * any derivative vector at this point.
+
+Note: the <i> gp</i> entities cannot be shared when they are inside more complex data structures.
+
+
+Common Mathematical Algorithms
+----------------------
+
+Common mathematical algorithms provided in OCCT include:
+
+  * Algorithms to solve a set of linear algebraic equations, 
+  * Algorithms to find the minimum of a function of one or more independent variables,
+  * Algorithms to find roots of one or of a set of non-linear equations, 
+  * An algorithm to find the eigenvalues and eigenvectors of a square matrix.
+
+
+@section OCCT_TOVW_SECTION_3 Modeling Data
+
+Modeling Data supplies data structures to represent 2D and 3D geometric models.
+
+![](/technical_overview/images/technical_overview_md.png "")
+
+These services are organized into the following libraries:
+
+  * 2D Geometry 
+  * 3D Geometry 
+  * Geometry Utilities 
+  * Topology 
+
+The technical overview provides only a basic description of the libraries. Please,
+refer for more details to Modeling Data User's guide 
+
+3D geometric models are stored in OCCT native BREP format. It is possible to learn
+more about it in BREP Format Description White Paper
+
+See also: our web site at E-learning and Training.
+
+@subsection OCCT_TOVW_SECTION_3_1 2D Geometry Types
+
+<i> Geom2d</i> package provides an implementation of 2D geometric objects complying with
+STEP, part 42. In particular, it provides functions for:
+
+  * description of points, vectors and curves,
+  * their positioning in the plane using coordinate systems,
+  * their geometric transformation, by applying translations, rotations, symmetries, scaling transformations and combinations thereof.
+
+The key characteristic of <i> Geom2d </i> curves is that they are parameterized. 
+Each class provides functions to work with the parametric equation of the curve, 
+and, in particular, to compute the point of parameter u on a curve and the derivative vectors of order 1, 2.., N at this point.
+
+As a consequence of the parameterization, a <i> Geom2d </i> curve is naturally oriented.
+
+Parameterization and orientation differentiate elementary <i>Geom2d </i>curves from their
+equivalent as provided by <i> gp</i> package. <i>  Geom2d</i> package provides conversion
+functions to transform a <i> Geom2d</i> object into a <i> gp</i> object, and vice-versa, when this is possible.
+
+Moreover, <i> Geom2d</i> package provides more complex curves, including Bezier curves,
+BSpline curves, trimmed curves and offset curves.
+
+<i> Geom2d </i> objects are organized according to an inheritance structure over several levels.
+Thus, an ellipse (specific class <i> Geom2d_Ellipse</i>) is also a conical curve and inherits
+from the abstract class <i> Geom2d_Conic</i>, while a Bezier curve (concrete class <i> Geom2d_BezierCurve</i>)
+is also a bounded curve and inherits from the abstract class <i> Geom2d_BoundedCurve</i>;
+both these examples are also curves (abstract class <i>Geom2d_Curve</i>). Curves, points
+and vectors inherit from the abstract class <i> Geom2d_Geometry,<i> which describes the properties
+common to any geometric object from the <i>Geom2d</i> package.
+
+This inheritance structure is open and it is possible to describe new objects which
+inherit from those provided in the <i>Geom2d</i> package, provided that they respect the
+behavior of the classes from which they are to inherit.
+
+Finally, <i> Geom2d</i> objects can be shared within more complex data structures. 
+This is why they are used within topological data structures, for example.
+
+<i> Geom2d </i>package uses the services of the <i> gp</i> package to:
+
+  * implement elementary algebraic calculus and basic analytic geometry,
+  * describe geometric transformations which can be applied to <i> Geom2d</i> objects,
+  * describe the elementary data structures of <i>Geom2d</i> objects.
+
+However, the <i> Geom2d</i> package essentially provides data structures and not algorithms.
+You can refer to the <i> GCE2d </i> package to find more evolved construction algorithms for <i> Geom2d </i> objects.
+
+@subsection OCCT_TOVW_SECTION_3_2 3D Geometry Types
+
+The <i> Geom</i> package provides an implementation of 3D geometric objects complying with
+STEP, part 42. In particular, it provides functions for:
+
+  * description of points, vectors, curves and surfaces,
+    * their positioning in 3D space using axis or coordinate systems, and
+    * their geometric transformation, by applying translations, rotations, symmetries, scaling transformations and combinations thereof.
+
+The key characteristic of Geom curves and surfaces is that they are parameterized.
+Each class provides functions to work with the parametric equation of the curve or
+surface, and, in particular, to compute:
+
+   * the point of parameter u on a curve, or
+   * the point of parameters (u, v) on a surface.
+
+together with the derivative vectors of order 1, 2, ... N at this point.
+
+As a consequence of this parameterization, a Geom curve or surface is naturally oriented.
+
+Parameterization and orientation differentiate elementary Geom curves and surfaces from the classes of the same (or similar) names found in the <i> gp</i> package. 
+The <i>Geom</i> package also provides conversion functions to transform a Geom object into a <i> gp</i> object, and vice-versa, when such transformation is possible.
+
+Moreover, the <i> Geom </i>package provides more complex curves and surfaces, including:
+  * Bezier and BSpline curves and surfaces,
+  * swept surfaces, for example surfaces of revolution and surfaces of linear extrusion,
+  * trimmed curves and surfaces, and
+  * offset curves and surfaces.
+
+Geom objects are organized according to an inheritance structure over several levels.
+Thus, a sphere (concrete class <i> Geom_SphericalSurface</i>) is also an elementary surface and inherits from the abstract class <i> Geom_ElementarySurface</i>, while a Bezier surface (concrete class <i> Geom_BezierSurface</i>) is also a bounded surface and inherits from the abstract class <i> Geom_BoundedSurface</i>; both these examples are also surfaces (abstract class <i> Geom_Surface</i>). Curves, points and vectors inherit from the abstract class <i> Geom_Geometry,</i> which describes the properties common to any geometric object from the <i>Geom</i> package.
+
+This inheritance structure is open and it is possible to describe new objects, which inherit from those provided in the Geom package, on the condition that they respect the behavior of the classes from which they are to inherit.
+
+Finally, Geom objects can be shared within more complex data structures. This is why they are used within topological data structures, for example.
+
+The <i> Geom</i> package uses the services of the <i> gp</i> package to:
+  * implement elementary algebraic calculus and basic analytic geometry,
+  * describe geometric transformations which can be applied to Geom objects,
+  * describe the elementary data structures of Geom objects.
+
+However, the Geom package essentially provides data structures and not algorithms.
+You can refer to the <i> GC</i> package to find more evolved construction algorithms for
+Geom objects.
+
+
+Adaptors for Curves and Surfaces
+-----------------
+
+Some Open CASCADE Technology general algorithms may work theoretically on numerous types of curves or surfaces. 
+To do this, they simply get the services required of the analysed  curve or surface through an interface so as to a single API,  whatever the type of curve or surface. These interfaces are called adaptors.
+For example, <i> Adaptor3d_Curve </i> is the abstract class which provides  the required services by an algorithm which uses any 3d curve.
+
+<i> GeomAdaptor </i>package provides interfaces:
+
+  * On a Geom curve;
+  * On a curve lying on a Geom surface;
+  * On a Geom surface;
+
+<i> Geom2dAdaptor</i> package provides interfaces :
+
+  * On a <i>Geom2d</i> curve.
+
+<i> BRepAdaptor </i> package provides interfaces:
+
+  * On a Face
+  * On an Edge
+
+When you write an algorithm which operates on geometric objects, use <i> Adaptor3d</i> (or <i> Adaptor2d</i>) objects. 
+As a result, you can use the algorithm with any kind of object, 
+if you provide for this object, an interface derived from Adaptor3d or Adaptor2d.
+These interfaces are easy to use: simply create an adapted curve or surface from a Geom2d curve, 
+and then use this adapted curve as an argument for the algorithm which requires it.
+
+
+@subsection OCCT_TOVW_SECTION_3_3 Geometry Utilities
+
+This library provides standard high-level functions in 2D and 3D geometry such as:
+
+  * Direct construction of algorithms; 
+  * Approximation of curves and surfaces from points; 
+  * Conversion of more elementary geometry to BSpline curves and surfaces; 
+  * Calculation of points on a 2D or 3D curve; 
+  * Calculation of extrema between two geometries. 
+
+Direct Construction
+-------
+
+The <i> gp</i>, <i> Geom2d</i> and <i> Geom</i> packages describe elementary data structures of simple geometric
+objects. The constructors of these objects are elementary: the construction arguments
+are fields by which the objects are represented in their data structure.
+
+
+On the other hand, the <i> gce</i>, <i> GCE2d</i> and <i> GC</i> packages provided 
+by the Direct Construction component construct the same types of objects 
+as <i> gp</i>, <i> Geom2d </i>and <i> Geom</i> respectively.
+However, the former implement geometric construction algorithms that translate the
+constructor's arguments into the data structure specific to each object.
+
+
+Algorithms implemented by these packages are simple: there is no creation of objects
+defined by advanced positional constraints (for more information on this subject,
+see <i> Geom2dGcc</i> and <i> GccAna</i> which describe geometry by constraints).
+
+
+<i> gce</i>, <i> GCE2d</i> and <i> GC </i>each offer a series of classes of construction algorithms.
+
+
+For example, the class <i> gce_MakeCirc</i> provides a framework 
+for defining eight problems encountered in the geometric construction of circles, 
+and implementing the eight related construction algorithms.
+
+The object created (or implemented) is an algorithm which can be consulted to find out, in particular:
+
+  * its result, which is a </i>gp_Circ</i>, and
+  * its status. Here, the status indicates whether or not the construction was successful.
+
+If it was unsuccessful, the status gives the reason for the failure.
+
+~~~~
+    gp_Pnt P1 (0.,0.,0.);
+    gp_Pnt P2 (0.,10.,0.);
+    gp_Pnt P3 (10.,0.,0.);
+    gce_MakeCirc MC (P1,P2,P3);
+    if (MC.IsDone()) {
+        const gp_Circ& C = MC.Value();
+    }
+~~~~
+
+In addition, <i> gce</i>, <i> GCE2d</i> and <i> GC</i> each have a <i>Root</i> class. This class is the root of
+all the classes in the package which return a status. The returned status (successful
+construction or construction error) is described by the enumeration <i> gce_ErrorType</i>.
+
+Note: classes which construct geometric transformations do not return a status, and
+therefore do not inherit from Root.
+
+Approximations
+-----------
+
+Approximation of Curves and Surfaces groups together a variety of functions used in 2D and 3D geometry for:
+
+  * the interpolation of a set of 2D points using a 2D BSpline or Bezier curve;
+  * the approximation of a set of 2D points using a 2D BSpline or Bezier curve;
+  * the interpolation of a set of 3D points using a 3D BSpline or Bezier curve, or a BSpline surface;
+  * the approximation of a set of 3D points using a 3D BSpline or Bezier curve, or a BSpline surface.
+
+You can program approximations in two ways:
+
+  * Using high-level functions, designed to provide a simple method for obtaining approximations with minimal programming,
+  * Using low-level functions, designed for users requiring more control over the approximations.
+
+The low-level functions provide a second API with functions to:
+
+  * Define compulsory tangents for an approximation. These tangents have origins and extremities.
+  * Approximate a set of curves in parallel to respect identical parameterization.
+  * Smooth approximations. This is to produce a faired curve.
+
+The classes <i> AppDef_MultiPointConstraints</i> and <i> AppDef_MultiLines </i> allow organizing the data.
+The classes <i> AppDef_Compute</i>, <i> AppDef_BSplineCompute</i> and <i> AppDef_TheVariational </i> 
+classes perform the approximation itself using Bezier curves, BSpline curves, and smooth BSpline curves, respectively.
+
+You can also find functions to compute:
+
+  * The minimal box which includes a set of points
+  * The mean plane, line or point of a set of coplanar, collinear or coincident points.
+
+Conversion to and from BSplines
+----------------------------
+The Conversion to and from BSplines component has the following two distinct purposes:
+  * Firstly, it provides a homogenous formulation which can be used to describe any curve or surface. 
+  This is useful for writing algorithms for a single data structure model. 
+  The BSpline formulation can be used to represent most basic geometric objects provided 
+  by the components which describe geometric data structures ("Fundamental Geometry Types", "2D Geometry Types" and "3D Geometry Types" components).
+  * Secondly, it can be used to divide a BSpline curve or surface into a series of curves or surfaces, 
+  thereby providing a higher degree of continuity. This is useful for writing algorithms 
+  which require a specific degree of continuity in the objects to which they are applied. 
+  Discontinuities are situated on the boundaries of objects only.
+
+The "Conversion to and from BSplines" component is composed of three packages.
+
+The <i> Convert </i> package provides algorithms to convert the following into a BSpline curve or surface:
+
+  * a bounded curve based on an elementary 2D curve (line, circle or conic) from the <i> gp </i> package,
+  * a bounded surface based on an elementary surface (cylinder, cone, sphere or torus) from the <i> gp</i> package,
+  * a series of adjacent 2D or 3D Bezier curves defined by their poles.
+
+These algorithms compute the data needed to define the resulting BSpline curve or surface. 
+This elementary data (degrees, periodic characteristics, poles and weights, knots and multiplicities) 
+may then be used directly in an algorithm, or can be used to construct the curve or the surface 
+by calling the appropriate constructor provided by the classes <i>Geom2d_BSplineCurve, Geom_BSplineCurve </i> or <i>Geom_BSplineSurface</i>.
+
+The <i>Geom2dConvert</i> package provides the following:
+
+  * a global function which is used to construct a BSpline curve from a bounded curve based on a 2D curve from the Geom2d package,
+  * a splitting algorithm which computes the points at which a 2D BSpline curve should be cut in order to obtain arcs with the same degree of continuity,
+  * global functions used to construct the BSpline curves created by this splitting algorithm, or by other types of segmentation of the BSpline curve,
+  * an algorithm which converts a 2D BSpline curve into a series of adjacent Bezier curves.
+
+The <i> GeomConvert</i> package also provides the following:
+
+  * a global function used to construct a BSpline curve from a bounded curve based on a curve from the Geom package,
+  * a splitting algorithm, which computes the points at which a BSpline curve should be cut in order to obtain arcs with the same degree of continuity,
+  * global functions to construct BSpline curves created by this splitting algorithm, or by other types of BSpline curve segmentation,
+  * an algorithm, which converts a BSpline curve into a series of adjacent Bezier curves,
+  * a global function to construct a BSpline surface from a bounded surface based on a surface from the Geom package,
+  * a splitting algorithm, which determines the curves along which a BSpline surface should be cut in order to obtain patches with the same degree of continuity,
+  * global functions to construct BSpline surfaces created by this splitting algorithm, or by other types of BSpline surface segmentation,
+  * an algorithm, which converts a BSpline surface into a series of adjacent Bezier surfaces,
+  * an algorithm, which converts a grid of adjacent Bezier surfaces into a BSpline surface.
+
+Points on Curves
+--------
+
+The Making Points on Curves component comprises high level functions providing an Application Programming Interface for complex algorithms that compute points on a 2D or 3D curve. The functions use various methods.
+
+The algorithms result in the following:
+
+  * a point on a curve, situated at a given curvilinear distance from another point on the curve
+  * a distribution of points situated at constant curvilinear intervals along a curve
+  * a distribution of points at a constant rise (i.e. respecting a criterion of maximum rise between the curve and the polygon that results from the computed points) along a curve
+  * the length of a curve.
+
+@subsection OCCT_TOVW_SECTION_3_4 Topology
+
+Topological library allows you to build pure topological data structures..
+
+Topology defines relationships between simple geometric entities. In this way, 
+you can model complex shapes as assemblies of simpler entities. 
+Due to a built-in non-manifold (or mixed-dimensional) feature, you can build models mixing:
+
+  * 0D entities such as points; 
+  * 1D entities such as curves; 
+  * 2D entities such as surfaces;&n