0024269: Content of occt documentation should be formated
authorysn <ysn@opencascade.com>
Fri, 1 Nov 2013 12:47:47 +0000 (16:47 +0400)
committerbugmaster <bugmaster@opencascade.com>
Fri, 1 Nov 2013 12:50:34 +0000 (16:50 +0400)
building subsection introduced; wok moved to dev guides section;
Requirements and Installation sections were interchanged;
some Unicode characters removed from .md files; \DeclareUnicodeCharacter{00A0}{ } instruction added into refman file
images insertion rolled back to dual html,latex insertion; mainpage now is processed (index.tex);
surplus part of overview has been removed
foundation_classes.md and technical_overview.md updated;
Reviewed step, tobj, xde and partly iges; Corrections in other guides.
Overview installation and requirements changes updated

54 files changed:
dox/FILES.txt
dox/Overview/LICENSE.md
dox/Overview/Overview.md
dox/dev_guides/building/building.md [new file with mode: 0644]
dox/dev_guides/building/wok/images/wok_image001.jpg [new file with mode: 0644]
dox/dev_guides/building/wok/images/wok_image002.jpg [new file with mode: 0644]
dox/dev_guides/building/wok/images/wok_image003.jpg [moved from dox/dev_guides/wok/images/wok_image003.jpg with 100% similarity]
dox/dev_guides/building/wok/images/wok_image004.jpg [moved from dox/dev_guides/wok/images/wok_image004.jpg with 100% similarity]
dox/dev_guides/building/wok/wok.md [new file with mode: 0644]
dox/dev_guides/cdl/cdl.md
dox/dev_guides/dev_guides.md
dox/dev_guides/documentation/documentation.md
dox/dev_guides/tests/tests.md
dox/dev_guides/wok/images/wok_image001.jpg
dox/dev_guides/wok/images/wok_image002.jpg
dox/dev_guides/wok/images/wok_image005.jpg [moved from dox/user_guides/wok/images/wok_image005.jpg with 100% similarity]
dox/dev_guides/wok/images/wok_image005.png [moved from dox/user_guides/wok/images/wok_image005.png with 100% similarity]
dox/dev_guides/wok/images/wok_image006.png [moved from dox/user_guides/wok/images/wok_image006.png with 100% similarity]
dox/dev_guides/wok/images/wok_image007.png [moved from dox/user_guides/wok/images/wok_image007.png with 100% similarity]
dox/dev_guides/wok/images/wok_image008.png [moved from dox/user_guides/wok/images/wok_image008.png with 100% similarity]
dox/dev_guides/wok/images/wok_image009.png [moved from dox/user_guides/wok/images/wok_image009.png with 100% similarity]
dox/dev_guides/wok/images/wok_image010.png [moved from dox/user_guides/wok/images/wok_image010.png with 100% similarity]
dox/dev_guides/wok/images/wok_image011.png [moved from dox/user_guides/wok/images/wok_image011.png with 100% similarity]
dox/dev_guides/wok/images/wok_image012.png [moved from dox/user_guides/wok/images/wok_image012.png with 100% similarity]
dox/dev_guides/wok/images/wok_image013.jpg [moved from dox/user_guides/wok/images/wok_image013.jpg with 100% similarity]
dox/dev_guides/wok/images/wok_image014.jpg [moved from dox/user_guides/wok/images/wok_image014.jpg with 100% similarity]
dox/dev_guides/wok/images/wok_image015.png [moved from dox/user_guides/wok/images/wok_image015.png with 100% similarity]
dox/dev_guides/wok/images/wok_image016.png [moved from dox/user_guides/wok/images/wok_image016.png with 100% similarity]
dox/dev_guides/wok/images/wok_image017.png [moved from dox/user_guides/wok/images/wok_image017.png with 100% similarity]
dox/dev_guides/wok/images/wok_image018.png [moved from dox/user_guides/wok/images/wok_image018.png with 100% similarity]
dox/dev_guides/wok/images/wok_image019.png [moved from dox/user_guides/wok/images/wok_image019.png with 100% similarity]
dox/dev_guides/wok/images/wok_image020.png [moved from dox/user_guides/wok/images/wok_image020.png with 100% similarity]
dox/dev_guides/wok/images/wok_image021.png [moved from dox/user_guides/wok/images/wok_image021.png with 100% similarity]
dox/dev_guides/wok/images/wok_image022.png [moved from dox/user_guides/wok/images/wok_image022.png with 100% similarity]
dox/dev_guides/wok/wok.md
dox/occdoc.tcl
dox/overview/images/overview_installation.png
dox/overview/tutorial/tutorial.md
dox/technical_overview/technical_overview.md
dox/user_guides/draw_test_harness/draw_test_harness.md
dox/user_guides/foundation_classes/foundation_classes.md
dox/user_guides/iges/iges.md
dox/user_guides/modeling_algos/modeling_algos.md
dox/user_guides/modeling_data/modeling_data.md
dox/user_guides/ocaf/ocaf.md
dox/user_guides/shape_healing/shape_healing.md
dox/user_guides/step/step.md
dox/user_guides/tobj/tobj.md
dox/user_guides/user_guides.md
dox/user_guides/visualization/visualization.md
dox/user_guides/wok/images/wok_image001.jpg [deleted file]
dox/user_guides/wok/images/wok_image002.jpg [deleted file]
dox/user_guides/wok/wok.md [deleted file]
dox/user_guides/xde/xde.md

index 0dbc6e0..b816e36 100644 (file)
@@ -14,14 +14,15 @@ 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/wok/wok.md
 
+dev_guides/building/building.md
+dev_guides/building/wok/wok.md
 dev_guides/building/automake.md
 dev_guides/building/cmake.md
 dev_guides/building/code_blocks.md
index afb9b4b..1358286 100644 (file)
@@ -88,7 +88,7 @@ This License does not grant any rights to use the trademarks, trade names and do
 
 ### 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.
+The Initial Developer retains all rights, title and interest in and to the Original Code. You may not remove the copyright (c) notice which appears when You download the Software.
 
 
 ### 12. Term
@@ -133,7 +133,7 @@ Open CASCADE S.A.S. is a French société par actions simplifiée having its mai
 
 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.
+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 (c) 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. 
 
@@ -146,9 +146,9 @@ Please see the License for the specific terms and conditions governing rights an
 
 #### 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.
+"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 (c) 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.
+Modifications to the Original Code have been made by ________________________. Modifications are copyright (c) [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".
 
index eb119f0..7e34d0a 100644 (file)
@@ -3,29 +3,31 @@ Overview {#mainpage}
 
 @section OCCT_OVW_SECTION_1 Welcome
 
-Welcome to Open CASCADE Technology version 6.6.0, a minor release, 
+Welcome to Open CASCADE Technology version 6.7.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.
+functionality along with some changes over the previous release 6.6.0.
 
 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 
+Open CASCADE Technology 6.7.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)
+@image html /overview/images/overview_occttransparent.png
+@image latex /overview/images/overview_occttransparent.png
 
-Copyright © 2001-2013 OPEN CASCADE S.A.S.
+Copyright (c) 2001-2013 OPEN CASCADE S.A.S.
 
-![](/resources/occt_logo.png)
+@image html /resources/occt_logo.png
+@image latex /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.
+Copyright(c) 2001-2013 by OPEN CASCADE S.A.S. All rights reserved.
 
  Trademark information
 ----------------------
@@ -77,7 +79,7 @@ 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. 
+**Intel(R) 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. 
@@ -85,7 +87,7 @@ 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 
+**Doxygen** (Copyright (c) 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.
@@ -169,6 +171,74 @@ then run **wgendoc** command with required arguments
 
 e.g., wgendoc –output=d:/occt/doc {–m=Draw Visualization} -chm
 
+@section OCCT_OVW_SECTION_5 Requirements
+
+@subsection OCCT_OVW_SECTION_5_1 Linux Intel
+<table>
+<tr> <th>Operating System  </th> <th> 64-bit:  Mandriva 2010, CentOS 5. 5, CentOS 6.3, Fedora 17, Fedora 18, Ubuntu-1304, Debian 6.0 *  </th> </tr>
+<tr> <td> Minimum memory </td> <td> 512 Mb, 1 Gb recommended </td > </tr> 
+<tr> <td> Free disk space (complete installation)  </td> <td> For full installation Open CASCADE Technology requires 600 Mb of disk space.  </td > </tr> 
+<tr> <td>Minimum swap space  </td> <td> 500 Mb </td > </tr> 
+<tr> <td> Video card   </td> <td> **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  </td > </tr> 
+<tr> <td> Graphic library     </td> <td> OpenGL 1.1+ (OpenGL 1.5+ is recommended) </td > </tr> 
+<tr> <td>C++      </td> <td>GNU gcc 4.0.  - 4.7.3.  </td > </tr> 
+<tr> <td> TCL (for testing tools)    </td> <td> Tcltk 8.5 or 8.6 http://www.tcl.tk/software/tcltk/8.6.html</td > </tr> 
+<tr> <td> Qt (for demonstration tools)  </td> <td> Qt 4.6.2 http://qt.nokia.com/downloads </td > </tr> 
+<tr> <td> Freetype (OCCT Text rendering) </td> <td> freetype-2.4.11 http://sourceforge.net/projects/freetype/files/ </td > </tr> 
+<tr> <td> FreeImage (Support of common graphic formats) </td> <td>FreeImage 3.15.4 http://sourceforge.net/projects/freeimage/files/Source%20Distribution/     </td > </tr> 
+<tr> <td> gl2ps (Export contents of OCCT viewer to vector graphic file)      </td> <td> gl2ps-1.3.8  http://geuz.org/gl2ps/ </td > </tr> 
+<tr> <td>TBB (optional tool for parallelized version of BRepMesh component)  </td> <td> TBB 3.x or 4.x http://www.threadingbuildingblocks.org/    </td > </tr> 
+<tr> <td> OpenCL (optional for providing ray tracing visualization core </td> <td>http://developer.amd.com/tools-and-sdks/heterogeneous-computing/amd-accelerated-parallel-processing-app-sdk/downloads/          </td>  </tr> 
+</table>
+\* Debian 60 64 bit is a permanently tested platform. 
+
+@subsection OCCT_OVW_SECTION_5_2 Windows Intel
+
+<table>
+<tr> <th>Operating System  </th> <th> 32/64-bit: 8/ 7 SP1 / VISTA SP2 /XP SP3    </th> </tr>
+<tr> <td> Minimum memory </td> <td> 512 Mb, 1 Gb recommended </td > </tr> 
+<tr> <td> Free disk space (complete installation)  </td> <td> For full installation Open CASCADE Technology requires 650 Mb of disk space but during the process of installation you will need 1,2 Gb of free disk space.  </td > </tr> 
+<tr> <td>Minimum swap space  </td> <td> 500 Mb </td > </tr> 
+<tr> <td> Video card   </td> <td> **GeForce** Version 266.58 WHQL or later is recommended: http://www.nvidia.com/Download/index.aspx  
+ </td > </tr> 
+<tr> <td> Graphic library     </td> <td> OpenGL 1.1+ (OpenGL 1.5+ is recommended) </td > </tr> 
+<tr> <td>C++      </td> <td>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
+Microsoft Visual Studio .NET 2013
+  </td > </tr> 
+<tr> <td> TCL (for testing tools)    </td> <td> TActiveTcl 8.5 or 8.6
+http://www.activestate.com/activetcl/downloads  </td > </tr> 
+<tr> <td> Qt (for demonstration tools)  </td> <td> Qt 4.6.2 http://qt.digia.com/downloads </td > </tr> 
+<tr> <td> Freetype (OCCT Text rendering) </td> <td> freetype-2.4.11 http://sourceforge.net/projects/freetype/files/ </td > </tr> 
+<tr> <td> FreeImage (Support of common graphic formats )</td> <td>FreeImage 3.15.4 http://sourceforge.net/projects/freeimage/files/Source%20Distribution/     </td > </tr> 
+<tr> <td> gl2ps (Export contents of OCCT viewer to vector graphic file)      </td> <td> gl2ps-1.3.8  http://geuz.org/gl2ps/ </td > </tr> 
+<tr> <td>TBB (optional tool for parallelized version of BRepMesh component)  </td> <td> TBB 3.x or 4.x http://www.threadingbuildingblocks.org/    </td > </tr> 
+<tr> <td> OpenCL (optional for providing ray tracing visualization core </td> <td>http://developer.amd.com/tools-and-sdks/heterogeneous-computing/amd-accelerated-parallel-processing-app-sdk/downloads/          </td>  </tr> 
+</table>
+
+* The official release of OCCT for Windows contains libraries built with VC++ 2008. 
+
+
+@subsection OCCT_OVW_SECTION_5_3 MAC OS X
+
+<table>
+<tr> <th>Operating System  </th> <th> Mac OS X 10.6.8 Snow Leopard / 10.7 Lion    </th> </tr>
+<tr> <td> Minimum memory </td> <td> 512 Mb, 1 Gb recommended </td > </tr> 
+<tr> <td> Free disk space (complete installation)  </td> <td> For full installation Open CASCADE Technology requires 600 Mb of disk space. </td > </tr> 
+<tr> <td>Minimum swap space  </td> <td> 500 Mb </td > </tr> 
+<tr> <td> Video card   </td> <td> **GeForce** Version 266.58 WHQL or later is recommended: http://www.nvidia.com/Download/index.aspx  
+ </td > </tr> 
+<tr> <td> Graphic library     </td> <td> OpenGL 1.1+ (OpenGL 1.5+ is recommended) </td > </tr> 
+<tr> <td>C++      </td> <td>XCode 3.2 or newer (4.x is recommended)  </td > </tr> 
+<tr> <td> Qt (for demonstration tools)  </td> <td> Qt 4.6.2 http://qt.digia.com/downloads </td > </tr> 
+<tr> <td> Freetype (OCCT Text rendering) </td> <td> freetype-2.4.11 http://sourceforge.net/projects/freetype/files/ </td > </tr> 
+<tr> <td> FreeImage (Support of common graphic formats )</td> <td>FreeImage 3.15.4 http://sourceforge.net/projects/freeimage/files/Source%20Distribution/     </td > </tr> 
+<tr> <td> gl2ps (Export contents of OCCT viewer to vector graphic file)      </td> <td> gl2ps-1.3.8  http://geuz.org/gl2ps/ </td > </tr> 
+<tr> <td>TBB (optional tool for parallelized version of BRepMesh component)  </td> <td> TBB 3.x or 4.x http://www.threadingbuildingblocks.org/    </td > </tr> 
+<tr> <td> OpenCL (optional for providing ray tracing visualization core </td> <td> OpenCL 1.2.8 native </td>  </tr> 
+</table>
 
 @section OCCT_OVW_SECTION_4 Installation
 
@@ -209,26 +279,32 @@ 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)
+@image html /overview/images/overview_installation.png "The directory tree"
+@image latex /overview/images/overview_installation.png "The directory tree"
+
+
 
-### Description of directory tree
+  * **adm**   This folder contains administration files, which allow rebuilding OCCT;
+  * **adm/cmake**  This folder contains files of CMake building procedure;
+  * **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;
+  * **data**  This folder contains CAD files in different formats, which can be used to test the OCCT functionalities;
+  * **doc**  This folder contains OCCT Overview documentation;
+  * **drv**  This folder contains source files generated by WOK (private header files and instantiations of generic classes);
+  * **inc**  This folder contains all OCCT header files;
+  * **samples**  This folder contains sample applications.
+  * **src**  This folder contains OCCT source files. They are organized in folders, one per development unit;
+  * **tests**  This folder contains scripts for OCCT testing.
+  * **win32/vc9**  This folder contains executable and library files built in optimize mode for Windows platform by Visual C++  2008;
 
+3rd party products have been moved to the root of Open CASCADE installation.
 
-  * **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;
+@image html /overview/images/overview_3rdparty.png "The third-party products"
+@image latex /overview/images/overview_3rdparty.png "The third-party products"
 
 
 @subsection OCCT_OVW_SECTION_4_2 System Environment Variables
@@ -266,7 +342,7 @@ The scripts are located in the OpenCACADE<version_number>/ros folder of the sour
   * **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 
+  Intel (R) 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; 
@@ -312,89 +388,12 @@ 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>
+<a href="http://occtrel.nnov.opencascade.com/OpenCASCADE6.7.0/doc/release_notes.pdf">Release Notes</a>
 @endhtmlonly  (PDF)
 
 
@@ -407,7 +406,8 @@ Draw is a command interpreter based on TCL and a graphical system used for testi
 
 Draw can be used interactively to create, display and modify objects such as curves, surfaces and topological shapes.
 
-![](/overview/images/overview_draw.png "")
+@image html /overview/images/overview_draw.png
+@image latex /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.
@@ -528,7 +528,8 @@ The list of MFC samples:
   * Animation
   * Convert
 
-![](/overview/images/overview_mvc.png "")
+@image html /overview/images/overview_mvc.png
+@image latex /overview/images/overview_mvc.png
 
 **Remarks:**
 
@@ -545,7 +546,8 @@ OCCT contains three samples based on Qt application framework
 
  Import Export programming sample contains 3D Viewer and Import // Export functionality.
 
-![](/overview/images/overview_qt.png "")
+@image html /overview/images/overview_qt.png
+@image latex /overview/images/overview_qt.png
 
  Tutorial
 ---------
@@ -582,7 +584,8 @@ for testing this functionality (accessible only through TEST pre-processor defin
 
 C# sample containing 3D Viewer and Import // Export functionality.
 
-![](/overview/images/overview_c__ie.png "")
+@image html /overview/images/overview_c__ie.png
+@image latex /overview/images/overview_c__ie.png
 
 Import:
 
@@ -602,3 +605,7 @@ Export:
 
   * 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/building.md b/dox/dev_guides/building/building.md
new file mode 100644 (file)
index 0000000..25ef343
--- /dev/null
@@ -0,0 +1,32 @@
+Building OCCT Libraries {#dev_guides__building}
+=========
+
+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__building__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
\ No newline at end of file
diff --git a/dox/dev_guides/building/wok/images/wok_image001.jpg b/dox/dev_guides/building/wok/images/wok_image001.jpg
new file mode 100644 (file)
index 0000000..37fd735
Binary files /dev/null and b/dox/dev_guides/building/wok/images/wok_image001.jpg differ
diff --git a/dox/dev_guides/building/wok/images/wok_image002.jpg b/dox/dev_guides/building/wok/images/wok_image002.jpg
new file mode 100644 (file)
index 0000000..b805c9b
Binary files /dev/null and b/dox/dev_guides/building/wok/images/wok_image002.jpg differ
diff --git a/dox/dev_guides/building/wok/wok.md b/dox/dev_guides/building/wok/wok.md
new file mode 100644 (file)
index 0000000..784936f
--- /dev/null
@@ -0,0 +1,157 @@
+WOK {#dev_guides__building__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:
+  
+  @image html /dev_guides/building/wok/images/wok_image001.jpg
+  @image latex /dev_guides/building/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:
+  
+  @image html /dev_guides/building/wok/images/wok_image002.jpg
+  @image latex /dev_guides/building/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:
+  
+  @image html /dev_guides/building/wok/images/wok_image003.jpg
+  @image latex /dev_guides/building/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:
+  
+  @image html /dev_guides/building/wok/images/wok_image004.jpg
+  @image latex /dev_guides/building/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
index bde4975..279e2db 100644 (file)
@@ -18,21 +18,10 @@ Using the services  described in the **packages**, you can construct an **execut
 
 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>       
+
+               @image html /dev_guides/cdl/images/cdl_image003.jpg
+    @image latex /dev_guides/cdl/images/cdl_image003.jpg
+     
 Figure 1. Building  an Open CASCADE Technology application 
 @section occt_1819379591_986437237 2. Introduction to  CDL
 @subsection occt_1819379591_98643723721  Purposes of the Language
@@ -40,21 +29,8 @@ You can use CDL to **define  data **in the Open CASCADE Technology environment.
 
 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>       
+               @image html /dev_guides/cdl/images/cdl_image004.jpg
+    @image latex /dev_guides/cdl/images/cdl_image004.jpg     
 
 Figure 2. The Development Process 
 
@@ -120,21 +96,9 @@ You declare the  variables of a **data manipulation language **as being of certa
 
   * 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>       
+  
+               @image html /dev_guides/cdl/images/cdl_image005.jpg
+    @image latex /dev_guides/cdl/images/cdl_image005.jpg      
 
 Figure 3. Manipulation of data types 
 
@@ -333,16 +297,16 @@ Capital and small  letters are not equivalent (i.e. AB, Ab, aB, ab are four diff
 
 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 
+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: 
 ; : , = ( ) [ ] ‘ “ 
@@ -361,12 +325,12 @@ 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 
+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 
+5.0        0.0           -0.8E+3          5.67E-12 
 
 ***Literal Constants*** 
 
@@ -375,12 +339,12 @@ 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;’      ‘*’      ‘’’ ‘‘ 
+ ‘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?’’ 
+’’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** 
@@ -408,20 +372,20 @@ Four of these primitives  are known to the schema of the database because they i
 
 The primitives inheriting  from Storable are the following: 
 
-**Boolean                **Is used to represent logical data. It has only  two values: 
+**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. 
+**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. 
+**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. 
 
@@ -435,7 +399,8 @@ Two types are  manipulated by handle:
   * 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)
+@image html /dev_guides/cdl/images/cdl_image006.jpg
+@image latex /dev_guides/cdl/images/cdl_image006.jpg
 
 Figure 4. Manipulation of a data type by reference 
 
@@ -446,22 +411,9 @@ Types, which are  manipulated by value, behave in a more direct fashion than tho
 
 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>       
+               @image html /dev_guides/cdl/images/cdl_image007.jpg
+    @image latex /dev_guides/cdl/images/cdl_image007.jpg
+      
 Figure 5. Manipulation of a data type by value 
 Three types are  manipulated by value: 
 
@@ -522,21 +474,10 @@ The elements, which make  up the definition of a class, are divided into four pa
   * 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>       
+
+               @image html /dev_guides/cdl/images/cdl_image009.jpg
+    @image latex /dev_guides/cdl/images/cdl_image009.jpg
+    
 **Figure 7. Contents of a class** 
 *** a deferred class does not have to contain a  constructor** 
 
@@ -588,7 +529,7 @@ data-type}’)’]
 
 @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. 
+ **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** 
 
@@ -629,7 +570,8 @@ Grouped behind the  keyword **uses **are the names of all the packages containin
 
 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)
+@image html /dev_guides/cdl/images/cdl_image010.jpg
+@image latex /dev_guides/cdl/images/cdl_image010.jpg
 Figure 8. Contents of a package 
 
 The example of the  package below includes some of the basic data structures: 
@@ -716,7 +658,7 @@ is
 end SingleList; 
 -- Third compilation unit, the class “Set” : 
 generic class Set from Collection (Item as Storable) 
-  inherits 
+  inherits 
 Persistent from Standard; 
 raises 
 NoSuchObject from Collection, 
@@ -724,7 +666,7 @@ NoMoreObject from  Collection
 private class Node  instantiates SingleList 
 from Collection  (Item); 
 -- etc.... 
- end Set; 
+ end Set; 
 
 
 NOTE 
@@ -828,7 +770,7 @@ const Handle(Standard_Type)&amp; TYPE (MyPack_MyImport)
 static Handle(Standard_Type) _aType = 
 new Standard_Type  (“MyPack_MyImport”,sizeof 
 (MyPack_MyImport)) 
- return _aType; 
+ 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. 
@@ -938,11 +880,11 @@ end;
 
 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. 
+**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. 
+**Instance method               **Operates on the instance which owns it. 
 
-**Class method                    **Does not work on individual instances, only on  the class                                                     itself. 
+**Class method                    **Does not work on individual instances, only on  the class                                                     itself. 
 
 @subsubsection occt_1819379591_1972310108411    Object  Constructors
 
@@ -965,7 +907,7 @@ 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. 
+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** 
@@ -1004,7 +946,7 @@ identifier formal-part-of-instance-method
 [  declaration-of-returned-type ] 
 [  exception-declaration ] 
 formal-part-of-instance-method  ::= 
- ’(’ me [’:’  passing-mode parameter-access ] {’;’ 
+ ’(’ me [’:’  passing-mode parameter-access ] {’;’ 
 parameter}’)’ 
 parameter ::= 
 identifier {’,’  identifier} ’:’ passing-mode 
@@ -1124,8 +1066,8 @@ 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. 
+  
+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} 
@@ -1146,11 +1088,11 @@ raises OutOfRange;
 
 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. 
+**NullObject                         **Raised when the principal object does not exist. 
 
-**ImmutableObject                          **Raised when a method tries to modify an immutable  principal object. 
+**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. 
+**TypeMismatch                              **Raised if an argument typed by association is of  an unsuitable type. 
 
 These exceptions are described  in the Standard Package (System Toolkits). 
 
@@ -1176,7 +1118,7 @@ declaration-of-a-sub-class ::=
 
 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. 
+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. 
@@ -1191,7 +1133,7 @@ declaration-of-a-redefined-method ::=
 identifier formal-part-of-instance-method [returnedtype- 
 declaration] 
 [declaration-of-exceptions] 
-**  is redefined **[visibility]’;’ 
+**  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. 
 
@@ -1212,7 +1154,7 @@ declaration-of-a-non-redefinable-method ::=
 identifier formal-part-of-instance-method [returnedtype- 
 declaration] 
 [declaration-of-exceptions] 
-** is virtual **[visibility]’;’ 
+** is virtual **[visibility]’;’ 
 
 All methods are static  by default. To enable redefinition in all the child classes, add “**is virtual;**“ when declaring the method. 
 
@@ -1228,7 +1170,7 @@ The CDL language allows  you to describe a class, which introduces methods witho
 
 declaration-of-a-deferred-class ::= 
 **deferred class **class-name 
- [**inherits **class-name 
+ [**inherits **class-name 
 [**uses **data-type {’,’ data-type}] 
 [**raises **exception-name {’,’ exception-name}] 
 **is **class-definition 
@@ -1376,29 +1318,29 @@ inherits Persistent
 raises NoSuchObject 
 is 
 Create returns mutable SingleList; 
-    ---Purpose: Creates an empty list 
+    ---Purpose: Creates an empty list 
 IsEmpty (me) returns  Boolean; 
-    ---Purpose: Returns true if the list me is  empty 
+    ---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 
+    ---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 
+   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 
+   Tail (me) returns mutable SingleList 
 ---Purpose: Returns  the tail of the list me 
 -- Exception  NoSuchObject raised when me is 
 empty 
 raises NoSuchObject; 
-   fields 
+   fields 
 Data : Item; 
-   Next : SingleList; 
-   end SingleList; 
+   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** 
@@ -1423,7 +1365,7 @@ The syntax is as  follows:
 
 instantiation-of-a-generic-class ::= 
 [**deferred**] **class  **class-name 
-**     instantiates **class-name ’(’data-type {’,’ 
+**     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. 
@@ -1443,18 +1385,18 @@ It often happens that  many classes are linked by a common generic type. This is
 **Example** 
 
 declaration-of-a-generic-class ::= 
-   [**deferred**] **generic class **class-name  ’(’generic- 
+   [**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 
+   [**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 
+   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. 
 
@@ -1467,34 +1409,34 @@ 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; 
+   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; 
+   More (me) returns  Boolean; 
 ---Purpose: Returns  true if there are still elements 
-   -- to explore 
-   Next (me) raises  NoMoreObject; 
+   -- to explore 
+   Next (me) raises  NoMoreObject; 
 ---Purpose: Passes  to the following element 
-   Value (me)  returns any Item raises NoSuchObject; 
+   Value (me)  returns any Item raises NoSuchObject; 
 ---Purpose: Returns  the current element 
-   fields 
-   Current : Node; 
+   fields 
+   Current : Node; 
 end Iterator; 
 is 
-   Create returns  mutable Set; 
+   Create returns  mutable Set; 
 ---Purpose: Creates  an empty group 
-   IsEmpty (me)  returns Boolean; 
+   IsEmpty (me)  returns Boolean; 
 ---Purpose: Returns  true if the group is empty 
-   Add (me :  mutable; T : Item); 
+   Add (me :  mutable; T : Item); 
 ---Purpose: Adds an  item to the group me 
-   Remove (me :  mutable; T : item) raises 
+   Remove (me :  mutable; T : item) raises 
 NoSuchObject; 
 ---Purpose: Removes  an item from the group me 
-   etc. 
-   fields 
-   Head : Node; 
+   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. 
@@ -1543,19 +1485,19 @@ identifier {’,’ identifier} ’:’ data-type
 Example 
 
 fields 
-   Phi, Delta, Gamma : AngularMomenta [3] 
-   is protected ; 
+   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. 
+**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. 
+**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.  
+**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 : 
 
@@ -1588,15 +1530,15 @@ Friend classes or  methods are declared inside the class, which reveals its priv
 
 declaration-of-friends ::= 
 **friends **friend {’,’friend} 
-   friend ::= 
-   identifier **from **[**class**] class-name  [formal-part] | 
+   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 
+**   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”. 
 
@@ -1606,23 +1548,11 @@ As an example, take a  method, which calculates the perpendicular distance betwe
 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. 
 
+               @image html /dev_guides/cdl/images/cdl_image011.jpg
+    @image latex /dev_guides/cdl/images/cdl_image011.jpg
 
+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
@@ -1754,7 +1684,7 @@ redefinition |** ****redefined**** **[redefinition]
 **raises**** **exception-name {’,’  exception-name} 
 
 (35)  declaration-of-visibility ::= 
-**is****  **visibility 
+**is****  **visibility 
 
 (36)  declaration-of-attributes-of-instance-method ::= 
 **is**** **visibility | **is **definition-of-level 
@@ -1844,7 +1774,7 @@ package-name]
 [**inherits**** **class-name 
 [**uses**** **data-type {’,’ data-type}] 
 [**raises**** **exception-name {’,’ exception-name}] 
-**   is **definition-of-a-class 
+**   is **definition-of-a-class 
 **end **[class-name]’;’ 
 
 (55) type-constraint ::= 
@@ -1858,19 +1788,6 @@ identifier **as**** **type-constraint
 
 @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>       
-
+               @image html /dev_guides/cdl/images/cdl_image012.jpg
+    @image latex /dev_guides/cdl/images/cdl_image012.jpg
+    
\ No newline at end of file
index e72a1dc..5e88b4f 100644 (file)
@@ -1,7 +1,7 @@
  Developer Guides {#dev_guides}
 ================
 
-@section OCCT_OVW_SECTION1 Source Repository
+## 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
@@ -15,39 +15,7 @@ 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
+## Automatic tests
 
 OCCT automatic testing system is integrated with @ref draw "DRAW Test Harness",
 a console application based on Tcl (a scripting language).
@@ -88,15 +56,24 @@ 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"
+For more information consult \subpage dev_guides__tests
+
+## docs
+**short description**
+
+\subpage dev_guides__documentation
+
+## wok
+**short description**
 
-@section OCCT_OVW_SECTION1112 CDL Overview
+\subpage dev_guides__wok
 
-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. 
+## building
+**short description**
 
-For more information consult \subpage dev_guides__cdl "Component Definition Language Developer's Guide"
+\subpage dev_guides__building
 
-@section OCCT_OVW_SECTION1113 Documentation Overview
+## cdl
+**short description**
 
-\subpage dev_guides__documentation "Documentation Developer's Guide"
+\subpage dev_guides__cdl
\ No newline at end of file
index d8965dd..69cf2e6 100644 (file)
@@ -20,6 +20,9 @@ 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
 
+**Note**: to generate pdf documentation with MiKTeX you should execute gen.bat with MiKTeX environment 
+(e.g. into MiKTeX command promt)
+
 @section OCCT_DM_SECTION_2_1 Documentation Generation
 
 Run gendoc.bat from OCCT directory to generate all articles are defined in FILES.txt:
@@ -80,7 +83,8 @@ The MarkDown files have a "*.md" extension and are based on rules desribed in
 
 @subsection  OCCT_DM_SECTION_3_2 Directory Structure
 
-![](/devs_guide/documentation/images/documentation_image001.png)
+@image html /dev_guides/documentation/images/documentation_image001.png
+@image latex /dev_guides/documentation/images/documentation_image001.png
 
 Every separate article has own folder if images are used in it. These images 
 are stored into "images" subfolder.
@@ -90,7 +94,7 @@ If you want to use the same image for several articles, you can place the one in
 **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)
+@image html /dev_guides/snv/images/snv_image001.svg
 @endverbatim
 
 Result of generation of the documentation is:
@@ -103,14 +107,14 @@ Result of generation of the documentation is:
 
  - 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
+source code" (svn.md - the file of the article) might be placed into /dox/dev_guides/ . 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
+*/dox/dev_guides/svn/ - for svn.md file
+*/dox/dev_guides/svn/images/ - for images
 
  - Update dox/FILES.txt to add relative path to svn.md. For instance
 @verbatim
-devs_guide/snv/svn.md
+dev_guides/snv/svn.md
 @endverbatim
 
 **Note**: the place of the relative path to an article is connected with the place
@@ -129,403 +133,3 @@ 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.
index 731e2a6..2282f23 100644 (file)
@@ -173,7 +173,8 @@ By convention, names of test groups, grids, and cases should contain no spaces a
 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 "")
+@image html /dev_guides/tests/images/tests_image001.png
+@image latex /dev_guides/tests/images/tests_image001.png
 
 Figure 1. Layout of tests folder
 
index 37fd735..0e782ca 100644 (file)
Binary files a/dox/dev_guides/wok/images/wok_image001.jpg and b/dox/dev_guides/wok/images/wok_image001.jpg differ
index b805c9b..5f87a33 100644 (file)
Binary files a/dox/dev_guides/wok/images/wok_image002.jpg and b/dox/dev_guides/wok/images/wok_image002.jpg differ
index 808868d..4d9b9ee 100644 (file)
-WOK {#dev_guides__wok}
-=========
+Workshop Organisation Toolkit  {#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.
+@section occt_wok_1_ Introduction Glossary
 
-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
+@subsection occt_wok_1_1 About the Development Environment
 
-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.
+Open CASCADE Technology (**OCCT**) development environment is able to accommodate large numbers of developers working on a variety of products. Within this environment developers can produce multiple versions of products for various hardware and software platforms, including versions corresponding to particular marketing requirements. At the same time, OCCT development environment enables the maximum possible reuse of software components. In other words, OCCT development environment is designed to facilitate industrial scale development.  
+@subsection occt_wok_1_2 Brief Overview of Open CASCADE Technology Development Environment
+The following diagram shows OPEN CASCADE tools and resources, the development method, and the architecture of applications that you can develop with Open CASCADE Technology.   
 
-@section wok1 Installing WOK
+@image html /dev_guides/wok/images/wok_image005.png "Schematic View of OCCT Development Platform"
+@image latex /dev_guides/wok/images/wok_image005.png "Schematic View of OCCT Development Platform"
 
-  Download the latest version of binary distribution WOK from http://dev.opencascade.org/index.php?q=home/resources
+The application developer goes about creating his application by editing his source code and producing the final application using a set of intelligent construction tools. These tools are available within a structured development environment called the **software factory**.  
 
-@subsection wok11 Windows
+The developer defines new software components in CDL, Component Description Language, and uses a CDL compiler to derive their C++ implementations. These components are then compiled into packages.  
+@subsection occt_wok_1_3 WOK Components
+@subsubsection occt_wok_1_3_1 Entities
+The WOK environment is made up of entities, for example software factories and development units. A full list of WOK entities is provided in the <a href="#occt_wok_1_4">Glossary</a> section. 
+@subsubsection occt_wok_1_3_2 Files
+WOK manages two different types of files: user source files and WOK administration files. To support this, each entity has a home directory, which contains its administration directory. This is called *adm* and stores the administration files that WOK needs. In addition development units have a source directory called *src*, which contains both .cdl and .cxx source files, and a header file directory called *inc*, which contains .hxx files.  
 
-  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 "")
+@subsection occt_wok_1_4 Glossary
+@subsubsection occt_wok_1_4_1 Development Units
+A **development unit** is the smallest unit that can be subject to basic development operations such as modifying, compiling, linking and building.  
+The following list contains all types of development units. The letter in parentheses indicates the letter key by commands such as *ucreate* and *umake*. In the rest of the manual, this letter key is referred to as the *short key*. 
+* package (p) A set of related classes and methods along with their CDL definitions. 
+* schema (s) A set of persistent data types. 
+* executable (x) An executable is used for unit and integration test purposes. It is based on one or more packages. 
+* nocdlpack (n) A package without a CDL definition. Used for low-level programming or for incorporating foreign resources. 
+* interface (i) A specific set of services available for wrapping (an interface contains packages, classes, and methods). 
+* jni (j) A development unit used to wrap C++ classes to Java. It is based on one or more interfaces. 
+* toolkit (t) A set of packages. Useful in grouping packages together when there is a large number of packages based around a particular subject. 
+* delivery (d) A development unit for publishing development units. 
+* resource (r) A development unit containing miscellaneous files. 
+
+@subsubsection occt_wok_1_4_2 Workbenches
+A workbench is a specialized directory structure where the user creates, modifies, and uses development units. A workbench is likely to be the personal property of one user or at most a small team of developers. 
+@image html /dev_guides/wok/images/wok_image006.png "Schema of a Workbench Containing three Development Units"
+@image latex /dev_guides/wok/images/wok_image006.png "Schema of a Workbench Containing three Development Units"
+
+@subsubsection occt_wok_1_4_3 Workshops
+A workshop is a tree of workbenches. It provides the development team with an independent workspace inside which the complete cycle of software production can be carried out. 
+The root workbench is in a valid state and contains the working versions of the development units. 
+Development units in a root workbench are visible in its child workbenches. 
+
+For example, the schema below shows a workshop containing three workbenches. Workbenches B and C are the children of workbench A. Development units in A are visible in both B and C
+@image html /dev_guides/wok/images/wok_image007.png "Workbenches"
+@image latex /dev_guides/wok/images/wok_image007.png "Workbenches"
+
+Workshops are fully independent of each other. They are organized in such a way that development units can be grouped into a delivery and placed in a warehouse. Communication between workshops is carried out by means of these deliveries. A warehouse belongs to a factory and is visible from all workshops in that factory. In this way, development units can be shared between a group of development teams. 
+
+@image html /dev_guides/wok/images/wok_image008.png "Two Workshops Delivering and Borrowing Parcels"
+@image latex /dev_guides/wok/images/wok_image008.png "Two Workshops Delivering and Borrowing Parcels"
+
+@subsubsection occt_wok_1_4_4 Factories
+A factory is a set of workshops and their corresponding warehouse. There is a single warehouse in any factory. The continuous upgrading and improvement of a product is carried out in a specific factory. 
+To create a new version of an application within the factory, you establish a new workshop dedicated to creation and support of the new version. 
+
+@image html /dev_guides/wok/images/wok_image009.png "Factory Contains Workshops and Warehouse"
+@image latex /dev_guides/wok/images/wok_image009.png "Factory Contains Workshops and Warehouse"
+
+@section occt_wok_2_ Elements of the Platform
+@subsection occt_wok_2_1 Development Units
+A **development unit** is the basic element of WOK development. It includes the following three entities: 
+  *  A directory structure (a minor component) 
+  *  Source files, also called primary files 
+  *  The result of the build process (compilation, etc.), also called derived files. 
+
+@subsubsection occt_wok_2_1_1 Directory Structure of a Development Unit
+The directory structure of a development unit consists of a tree of directories, which are created when the development unit is initialized. Refer to the <a href="#occt_wok_2_2">Workbenches</a> section for further details on the workbench structure. 
+@subsubsection occt_wok_2_1_2 Files in a Development Unit
+
+#### Source Files
  
-  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.
+Source files are written by the developer in the source section (the *src* directory) of the development unit. 
+Each development unit maintains the description of its own source files, and this description is stored in one or more files within the *src* directory. The details of how the description is stored vary according to development unit type as shown below: 
+* package (p) The names of all source files are worked out from the CDL description, following the conventions described in the *C++ Programming Guide*. This list of files can be supplemented by additional files listed in the file called FILES. This file must be stored in the unit’s src directory. Whenever header files are included in the *src* directory of a development unit, they must be specified in FILES so that the C++ preprocessor will take them into account. This reduces compilation time by 10 to 40 percent. 
+* schema (s) No description of the source files is needed. There is a single source file: *schema.cdl*. 
+* executable (x) The names of all source files are worked out from the CDL description. The format of this file is described in the <a href="#occt_wok_3_5">Building an Executable</a> section. 
+* nocdlpack (n) The list of source files is contained in the FILES file stored in the unit’s src directory. 
+interface (i). No description of the source files is needed. There is a single source file: *interface.cdl*. 
+* jni (j). No description of the source files is needed. There is a single source file: *jni.cdl*. 
+* toolkit (t) The description is given by the file called PACKAGES which is stored in the unit’s src directory. FILES must also exist in this directory, and must include PACKAGES in its list of files. 
+* delivery (d) The description is given by two files stored in the unit’s src directory: FILES and a file called COMPONENTS. FILES must include COMPONENTS in its list of files. 
+* resource (r) A resource unit is used in a delivery. FILES contains a list of the unit’s files, one per line in the following format: *atype:::afilename*  Here, *filename* is the name of a file, which the compiler will look for in the src directory of the unit, and *atype* is a WOK type. To display a list of all available WOK types, use the command: *wokinfo -T*. 
+
+#### Derived files
+
+Derived files created by compilation are automatically placed in the derived section of the development unit. These may be executable files or archives of compilation results. 
+
+@subsubsection occt_wok_2_1_3 Package
+A package is a development unit that defines a set of classes, which share a number of common features such as similar data structure or a set of complementary algorithmic services. Packages help to manage creation and the use of large hierarchies of software components.  
+To create a package, you write a .cdl file describing it in the src directory of the package development unit. The description includes classes and global methods, which comprise it. Each class is also described in a separate .cdl file. The package .cdl file also lists the packages used in the specification of its classes and methods. 
+C++ implementation files are also stored in the src subdirectory of the package development unit. These implementation files are: 
+  *  .cxx for an ordinary class 
+  *  .lxx for any inline methods 
+  *  .pxx for any private declarations 
+  *  .gxx for a generic class 
   
-  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. 
+To create the Development Unit structure for a package use the following syntax:
+~~~~~
+ucreate –p MyPackage 
+~~~~~
 
-  By default WOK installer creates a WOK factory with name "LOC" within workshop "dev" (WOK path :LOC:dev). 
+The package description has the following CDL syntax: 
+~~~~~
+package PackageName 
+[uses AnotherPackage {‘,’ YetAnotherPackage}] 
+is 
+[{type-declaration}] 
+[{package-method}] 
+end [PackageName]’:’ 
+~~~~~
 
-@subsection wok12 Linux
+For example:
+~~~~~
+package CycleModel 
+uses 
+Pcollection 
+Tcollection 
+BREpPrimAPI 
+TopExp 
+Geom 
+Pgeom 
+is 
+deferred class Element; 
+class Wheel; 
+class Frame; 
+class LocalReference; 
+Adjust(awheel: wheel from CycleModel; 
+  aframe: Frame from CycleModel); 
+end CycleModel; 
+~~~~~
+For full details on the CDL syntax, refer to the *CDL User’s Guide*. 
 
-  * Unpack the .tgz archive containing WOK distributive into an installation directory <WOK_INSTALL_DIR>.
+@subsubsection occt_wok_2_1_4 Schema
 
-  * 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:
+A schema is a development unit that defines the set of all data types, which your application is likely to need in order to read and write files. Such data types are **persistent**. 
+
+To create a schema, write a .cdl file that lists all the packages, which contain all persistent data types used by the application. Note that only persistent classes are taken into account during compilation; transient classes are ignored. 
+
+Note that you don’t have to put dependencies in all packages and classes. You only have to write the highest level dependencies. In other words, the *uses* keyword in the schema file allows you to list packages. Any package similarly listed in the package files for these packages are also incorporated into the schema. 
+
+To create the Development Unit structure for a schema use the syntax below: 
+~~~~~
+ucreate –s MySchema 
+~~~~~
+
+The schema description has the following CDL syntax : 
+
+~~~~~
+schema SchemaName 
+is 
+ListOfPackagesContainingPersistentClasses; 
+ListOfPersistentClasses; 
+end; 
+~~~~~
+
+For example:
+~~~~~ 
+schema MyCycleSchema 
+is 
+class Wheel from package CycleModel; 
+class Frame from package CycleModel; 
+.. 
+class Spanner from package CycleTools; 
+end; 
+~~~~~
+For full details on the CDL syntax, refer to the *CDL User’s Guide*. 
+
+@subsubsection occt_wok_2_1_5 Executable
+The purpose of an executable is to make executable programs. The executable can use services from one or more packages and is described in a .cdl file as a set of packages. 
+
+To create an executable, you write one or more MyExe.cxx files in the src subdirectory of the unit. This file will contain the main function. Then it is possible to compile the executable. 
+
+To create the Development Unit structure for an executable, use the syntax below: 
+~~~~~
+ucreate –x MyExec 
+~~~~~
+
+The executable description has the following CDL syntax: 
+~~~~~
+executable ExecName 
+is 
+executable BinaryFile 
+uses 
+LibFile as external 
+is 
+C++File; 
+end; 
+end; 
+~~~~~
+
+For example:
+~~~~~
+executable MyExecUnit’ 
+is 
+executable myexec 
+uses 
+Tcl_Lib as external 
+is 
+myexec; 
+end; 
+executable myex2 
+is 
+myex2; 
+end; 
+end; 
+~~~~~
+For full details on the CDL syntax, refer to the *CDL Reference Manual*. 
+
+@subsubsection occt_wok_2_1_6 Toolkit
+A toolkit is a development unit that groups a set of packages to create a shareable library. An example of a toolkit is the ModelingData module. Toolkits serve for the following purposes: 
+  *  Linking of large numbers of packages 
+  *  Faster loading of executable files that use toolkits such as test files. 
   
-  ![](/devs_guide/wok/images/wok_image003.jpg "")
+A toolkit has no CDL definition. Creating a toolkit involves writing a PACKAGES file in the src subdirectory of its development unit. This file lists all the packages needed in the toolkit. You then create a definition of this file to the FILES. 
+
+You then compile the toolkit to create a shareable library. 
+
+@subsubsection occt_wok_2_1_7 Nocdlpack
+A nocdlpack is a development unit that has no CDL definition. It is compiled directly from source files written in C, C++, Fortran, or in sources to be treated by the lex or yacc tools. A nocdlpack is useful when you write a low-level interface with another product, for example, a network application. 
+
+To define a nocdlpack, you create a file called FILES in the src subdirectory of the nocdlpack development unit. In this file, you list the Fortran, C, C++, lex, and yacc files that compose the pack. You list the files one per line. 
+
+On compilation, the result is a shareable library. 
+
+@subsubsection occt_wok_2_1_8 Interface
+An interface is a development unit that defines a set of services available for wrapping into Java. 
+An interface is defined in a .cdl file as a list of packages, package methods, classes, and methods. It makes these available to a jni unit. 
+
+To create the Development Unit structure for an interface, use the syntax below: 
+~~~~~
+ucreate -i MyInterface 
+~~~~~
+
+The interface description has the following CDL syntax: 
+
+~~~~~
+interface InterfaceName 
+is 
+ListOfPackages 
+ListOfClasses 
+ListOfMethods 
+end; 
+~~~~~
+
+For example:
+~~~~~
+interface MyInterface 
+is 
+        package TopoDS; 
+        class Shape from ShapeFix; 
+end ; 
+~~~~~
+
+@subsubsection occt_wok_2_1_9 Jni
+A jni is a development unit that wraps declared services into Java using JNI (Java Native Interface). 
+
+A jni creates Java classes that are used as C++ counterparts when developing in Java. 
+
+To create the Development Unit structure for an Jni, use the syntax below: 
+ucreate -j MyJni 
+
+The interface description has the following CDL syntax: 
+~~~~~
+client JniName 
+is 
+{interface InterfaceName;} 
+end; 
+~~~~~
+
+For example :
+~~~~~
+client MyJni 
+is 
+        interface MyInterface; 
+        interface MyAnotherInterface; 
+end ; 
+~~~~~
+
+@subsubsection occt_wok_2_1_10 Delivering Parcels
+The delivery process allows creating parcels. These parcels group together the development work done within a given workshop. You can ship these parcels to other workshops called client workshops. 
+
+A delivery is autonomous. Once the delivery development unit is compiled, a parcel is stored in the factory warehouse and has no more connection with the workshop where it was created. A parcel has its own directory structure. 
+
+All Open CASCADE Technology resources are seen as parcels. 
+
+@image html /dev_guides/wok/images/wok_image010.png "Parcels"
+@image latex /dev_guides/wok/images/wok_image010.png "Parcels"
+   
+You create a delivery unit under a specified workbench. 
+
+You are **strongly advised** to create delivery units under the *root* workbench of the workshop. Child workbenches could be deleted in the future, whereas the root workbench is likely to remain untouched. In other words, you safeguard the delivery by creating it in the root workbench. 
+
+**Note** If you do not specify a workbench when you make a delivery, it is created under the current workbench.
  
-  * 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 "")
+@subsection occt_wok_2_2  Workbenches
+A workbench is generally the place where one particular developer or a team of developers works on a particular development. A workbench is composed of a public part and a private part. 
+
+@subsubsection occt_wok_2_2_1  Roots
+The following roots are used in the structure of a workbench: 
+* **Home** Workbench root containing various administration files of the workbench. 
+* **Src** Root of the workbench sources, which facilitates the integration into WOK of version management software such as CVS. 
+* **DBMS** Root of the derived files dependent on the extraction profile (.hxx, _0.cxx files, etc.). 
+* **DBMS_Station** Roots of the derived files dependent on the extraction profile and on the platform (.o, .so files, etc.). 
+
+Roots are defined for each profile and platform supported by the workbench. For example, a workbench supporting the DFLT profile on Sun and SGI platforms has the following roots: 
+* **Home** Workbench root, 
+* **Src** Root of the source files, 
+* **DFLT** Root of the derived files, 
+* **DFLT_sun** Root of the files built on Sun platforms, 
+* **DFLT_sil** Root of the files built on SGI platforms, 
+
+For a workbench additionally supporting *ObjectStore*, the following additional roots are also found: *OBJS, OBJS_sun, OBJS_sil*.
+These roots are defined in the workbench definition file *MyWorkbench.edl* as the parameter <i>\%MyWorkbench_RootName</i>. 
+
+**Note** that default values help to define various roots.
  
-  * Run the following commands to create WOK LOC factory:
-  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
-  cd <WOK_INSTALL_DIR>/site
-  wok_init.sh
-  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+@subsubsection occt_wok_2_2_2  Directories
+Under each root, a hierarchy of directories allows to store various files. 
+* Under the Home root are found: 
+       *  *work*, the private workbench directory reserved for the developer 
+       *  *Adm*, the directory reserved for administration files. 
+* Src contains: 
+       *  *src/MyUD*, the directory containing the source files of the development unit MyUD. 
+* DBMS contains: 
+       *  *inc*, containing the public header files of the workbench UDs 
+       *  *drv/MyUD*, containing the private extracted files of MyUD 
+       *  *drv/MyUD/.adm*, containing the administration files dependent on the extraction profile 
+       *  *drv/MyUD/.tmp*, containing the temporary files dependent on the extraction profile. 
+* DBMS_Station contains: 
+       * *<station>/lib* with all the libraries produced in the workbench
+       * *<station>/bin* with all the binaries produced in the workbench
+       * *<station>/MyUD* with all the station dependent files which are private to the development unit such as objects
+       * *<station>/MyUD/.adm* with all the station dependent administration files
+       * *<station>/MyUD/.tmp* with all the temporary files constructed in the development unit.
+
   
-  * 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.
+@image html /dev_guides/wok/images/wok_image011.png "Structure of the workbench Mywb"
+@image latex /dev_guides/wok/images/wok_image011.png "Structure of the workbench Mywb"
 
+@subsection occt_wok_2_2_3  Workshops
+A **workshop** is an independent workspace inside which the complete cycle of software production is carried out. Workbenches inside a workshop are organized so that development units can be shared either by being published in a father workbench or by being placed in reference in the root workbench.
+@image html /dev_guides/wok/images/wok_image012.png "Visibility between Workbenches in a Workshop"
+@image latex /dev_guides/wok/images/wok_image012.png "Visibility between Workbenches in a Workshop"
 
-@section wok2 Initialization of Workbench
+In this image:
+ * **A** is the development unit A from Grandchild 11  placed in reference in root. It is visible throughout the workshop. 
+ * **B** is the development unit B from Grandchild 12 published in ancestor Child 1. It is visible to Child 1, Grandchild 11 and  Grandchild 12.
 
-  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. 
+
+In a large-scale development that involves one or more teams of developers, you should decide how you are going to structure a workshop right at the beginning. If need be, you can review your decision later. 
+
+An existing workshop can be duplicated and the original workshop can be used as the basis for maintaining the present version of a product. The new workshop can then be used to develop and maintain a new version of the product. 
+
+When creating a new workshop, you specify - in the form of parcels – which resources are to be available within the workshop. 
+
+@subsection occt_wok_2_2_4  Factories
+A factory contains a number of workshops and a warehouse. When Open CASCADE Technology is installed, the system administrator creates a single factory. This contains a single workshop as well as the warehouse containing OCCT resources in the form of parcels. 
+
+There is no theoretical limit to the number of workshops that can be added to a factory. However, a single factory should be enough. 
+
+@section occt_wok_3 Development Process
+@subsection occt_wok_3_1  WOK Environment
+The WOK interface is based on tcl, a command language provided by the Regents of the University of California and Sun Microsystems, Inc. The WOK development environment is in fact a tcl session.
+
+
+Before you run a tcl session you must make sure that your account is configured for using tcl, see the <a href="#occt_wok_8_3">Configuring Your Account for Tcl and WOK</a> section. 
+
+To start a tcl session use the command: 
+~~~~~
+% tclsh 
+~~~~~
+Within this session, all WOK commands are available as well as standard tcl commands. You can also use tcl language extensions, if these are installed. 
+To exit from a tcl session use the command: 
+~~~~~ 
+> exit
+~~~~~ 
+Online help is provided with tcl. To access this, use the following command: 
+~~~~~
+% tclhelp  
+~~~~~
+Online help is also available for all WOK commands. To display help on a particular WOK command, give the command name followed by the -h flag, as in the following example: 
+~~~~~
+> wokcd -h
+~~~~~
+
+@subsection occt_wok_3_2  Steps
+Implementation of an application is based on the following steps: 
+1. Enter the software factory using the command wokcd MyFactory 
+2. Enter a workshop using the command wokcd MyWorkshop 
+3. Open a workbench using the command wokcd MyWorkbench 
+4. Search for the data types required among the existing OCCT libraries 
+5. Define one or more packages which will contain the classes 
+6. Define new data types as classes 
+7. Implement the methods of those classes in C++ 
+8. Implement any package methods in C++ 
+9. Unite the test packages 
+10. Define any nocdlpacks (if any) 
+11. Test the components 
+
+**Note:** Steps 1-3 can be performed with a single WOK command: 
+~~~~~
+> wokcd MyFactory:MyWorkshop:MyWorkbench
+~~~~~
+@subsection occt_wok_3_3  Getting Started
+@subsubsection occt_wok_3_3_1  Entity Names
+Before you start, the following restrictions on WOK entity names must be noted: 
+  *  Entity names may only contain alphanumeric characters and dashes. 
+  *  Entity names must be unique within a hierarchy. For example, you must not have two workbenches called MyBench in the same Workshop. Likewise, you may not have a workshop called CSF in a factory of the same name. 
+  *  Do not use upper and lower case characters to distinguish between two entity names, for example ENT1 and eNt1. This restriction is for reasons of portability. 
+  *  Parcel names must be unique. 
   
-  For example, assuming that OCCT repository has been cloned into D:/occt folder: 
-  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
-  LOC:dev> wcreate occt -DHome=D:/occt
-  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+@subsubsection occt_wok_3_3_2  Entering the Factory
+When you start work you go to the factory using the following command: 
+~~~~~
+> wokcd <MyFactory>
+~~~~~ 
+@subsubsection occt_wok_3_3_3  Creating a New Workshop
+If you don’t want to work in a workshop already present in the factory, you can create a new one. To do this, use the following command: 
+~~~~~
+> screate –d <MyWorkshop> 
+~~~~~
+This creates the new workshop **MyWorkshop** in the current factory. To create the same workshop in a different factory use the syntax below: 
+~~~~~
+> screate –d <MyFactory:MyWorkshp>
+~~~~~
+
+When you create a new workshop, it is empty. 
+
+@subsubsection occt_wok_3_3_4  Selecting Parcels
+When you create a workshop, you select existing OCCT resources, for example, parcels, to use in it. To do this, you create the workshop and add the parcels using the following syntax: 
+~~~~~
+> screate –d <MyWorkshop> -DparcelConfig=Parcel1,Parcel2…
+~~~~~
+To display available OCCT resources, in other words, to see what parcels are available, you use the following command: 
+~~~~~
+Winfo –p <WarehouseName>
+~~~~~
+**Note:** parcel configuration rarely needs to change. If it does, only the workshop administrator should make them. 
+@subsubsection occt_wok_3_3_5  Opening a Workshop
+To open a workshop, you use the following command: 
+~~~~~
+> wokcd <MyWorkshop>
+~~~~~
+@subsubsection occt_wok_3_3_6  Creating a New Workbench
+When you create a new workshop, it is empty. In other words, it does not contain any workbenches. 
+To create the root workbench of a new workshop, you use the following command: 
+~~~~~
+> wcreate -d <MyWorkbench>
+~~~~~
+This creates a tree of workbench subdirectories. 
+If workbenches already exist in your workshop, but you do not want to work in any of these, create a new workbench as a child of an existing one. You do this using the following syntax: 
+~~~~~
+> wcreate –d <MyWorkbench> -f <ParentWorkbench>
+~~~~~
+@subsubsection occt_wok_3_3_7  Opening a Workbench
+To open a workbench, you use the command below: 
+~~~~~
+> wokcd <MyWorkbench>
+~~~~~
+This automatically takes you to the root directory of the workbench 
+
+@subsubsection occt_wok_3_3_8  Using Existing Resources
+Before creating new data types, you should look for existing components that you can reuse. In particular, you should look through the existing resources of your Open CASCADE Technology platform to see if any of the required components already exist, or if any existing generic components can be suitably implemented. This search can be conducted using the online documentation. You should note the packages and classes, which you can reuse. 
+@subsection occt_wok_3_4  Creating Software Components
+@subsubsection occt_wok_3_4_1  Creating a Package
+To develop new software components, you usually need to create one or more packages. You do this, by using the following command: 
+~~~~~
+> ucreate –p <MyPackage> 
+~~~~~
+Because the key -p defines the default value for the *ucreate* command, you do not need to specify it. The following syntax, for example, will also create a package: 
+~~~~~
+ > ucreate <MyPackage> 
+~~~~~
+#### Enter a Package or other Development Unit Structure
+
+Enter the package or any other development unit structure using the *wokcd* command as in the syntax below: 
+~~~~~
+> wokcd MyPackage 
+~~~~~
+The current directory is now: 
+~~~~~
+MyWorkbenchRoot/src/MyPackage 
+~~~~~
+
+#### Writing the Package and Class Specifications in CDL 
+
+Write the descriptions of the software components in CDL using an editor of your choice. Write each class in its own .cdl file and write one .cdl file (MyPackage.cdl) to specify the package that contains those classes. 
+
+#### CDL Compilation of the Package
+
+Compile and check the package and its classes using: 
+~~~~~
+ > umake –e xcpp 
+~~~~~
+This command also extracts the C++ header files (.hxx) and stores them in the derived files directory. 
+
+#### Implementing Methods in C++ 
+
+A package will contain methods, which may be: 
+  *  Instance methods 
+  *  Class methods 
+  *  Package methods. 
+Extract **prototypes** for the C++ methods using the following command: 
+~~~~~ 
+ > umake -o xcpp.fill -o xcpp.template 
+~~~~~
+
+You should not confuse this syntax with the template feature of C++ used to implement the genericity. 
+The *umake -o xcpp.template* command creates a skeleton C++ file for: 
+  *  Each class 
+  *  All the package methods. 
+The packages methods will be created in a file called *package.cxx.template*. This command is not included in the umbrella command *MyPackage*. 
+You will need to use an editor to implement these methods in C++. 
+
+
+#### Compiling the Package
+
+To compile the package, use the command: 
+~~~~~
+       > umake -o obj <MyPackage>
+~~~~~  
+If you do not specify a package, the current development unit is compiled. 
+
+#### Sample Construction of a Package
+
+In the following example a workbench named **MyWb** is created as a child of an existing workbench **Topo**. MyWb is used for working on the package **MyPack**. Commands preceded by an asterisk below are used only once per session: 
+1. Create the MyWb workbench as a child of Topo. 
+~~~~~
+       > wcreate MyWb -f Topo -d
+~~~~~
+2. Create MyPack in MyWb. 
+~~~~~
+       > ucreate MyPack     
+~~~~~
+3. Move to the source directory of MyPack. 
+~~~~~
+       > wokcd MyPack 
+~~~~~
+4. Edit the source files (MyPack.cdl etc.). You do this outside tcl, using the editor of your choice. 
+5. Start the extraction of MyPack. 
+~~~~~
+        >  umake -e xcpp 
+~~~~~
+6. Generate the .cxx templates for MyPack: MyPack.cxx.template 
+~~~~~
+   > umake -o xcpp.fill -o xcpp.template -t 
+~~~~~
+7. Edit the source files (MyPack.cxx etc). You do this outside tcl, using the editor of your choice. 
+
+**Note** that *umake* command used without arguments will carry out all the above *umake* steps. You can also use it with specific arguments as above to go through the development process step by step. 
+
+#### Package Files
+
+* Primary Files for a Package 
+       + <Package>.cdl                         Primary package file.
+       + <Package>_<Class>.cdl         Primary class file.
+* C++ Files for a Package
+       + <Package>.cxx                         Primary package source file.
+       + <Package>_[1..9[0..9]*].cxx   Secondary package source files.
+       + <Package>.lxx                         Inline package methods source file.
+       + <Package>.pxx                         Private instructions source file.
+* C++ Files for a Class
+       + <Package>_<Class>.cxx         Primary class source file.
+       + <Package>_<Class>_[1..9[0..9]*].cxx
+* Secondary class source files.
+       + <Package>_<Class>.gxx         Generic class methods source file. This is an alternative to the .cxx file(s), you do not have both.
+       + <Package>_<Class>.lxx         Inline methods source file.
+       + <Package>_<Class>.pxx         Private instructions source file.
+* Derived C++ Files for a Package
+       + <Package>.hxx                         User header file.
+       + <Package>.ixx                         User header file included in <Package>.cxx.
+       + <Package>.jxx                         User header file included in <Package>_[1-9].cxx.
+* Derived C++ files for a class
+       + <Package>_<Class>.hxx         User header file.
+       + <Package>_<Class>.ixx         User header file included in <Package>_<Class>.cxx.
+       + <Package>_<Class>.jxx         User header file in <Package>_<Class>_[1..9[0..9]*].cxx.
+       + Handle_<Package>_<Class>.hxx Persistent or Transient class header file.
+       + <Package>_<Class>_0.cxx       For instantiated classes.
+
+Umake Steps for a Package 
+-------------------------
+The umake steps for development units of package type are explained below. 
+* *src*                        Processes the file *MyPackage.cdl* to generate a list of all the CDL files in the development unit. Processes FILES to list source files. 
+* *xcpp.fill*  Compiles the internal data structure to prepare for subsequent extractions. 
+* *xcpp.src*           Lists the source files (.cxx, .gxx, .lxx) deduced from the CDL files. 
+* *xcpp.header*        Extracts header files for the classes in the development unit. 
+* *xcpp.template* Extracts a template for implementation of methods. (Hidden step.)
+* *obj.inc*         Based on the list of source files generated by the src and xcpp.src steps, this step publishes the include files for the development unit so that other units can use them. 
+* *obj.cgen*           Processes the source files to generate code. 
+* *obj.comp*          Compiles each file that can be compiled. 
+* *obj.idep*        Generates dependency information for the unit. This comprises: 
+       + Includes performed by unit compilation (Unit.MakeState) 
+       + Implementation dependencies in terms of the unit suppliers (Unit.ImplDep) 
+* *obj.lib*          Generates the shared library for the development unit. 
+
+@subsubsection occt_wok_3_4_2  Creating a Nocdlpack
+If your executable requires the use of a nocdlpack, create a development unit of nocdlpack type and move to its structure using the commands below: 
+~~~~~
+       > ucreate -n <MyNoCDLPack>
+       > wokcd <MyNoCDLPack> 
+~~~~~
+Use an editor to write *FILES*, which is a nomenclature file for a nocdlpack. This file must list all the C, C++, Fortran, lex, and yacc sourcs files (one per line). 
+Build the nocdlpack using the following command: 
+~~~~~
+       > umake [<MyNoCDLPack>]
+~~~~~
+**Note** that a nocdlpack unit is not intended to perform tests. Use an executable unit instead.
+
+
+#### Sample Construction of a Nocdlpack
+
+In the following example a nocdlpack *MyNocdlpack*, is created. Commands preceded by an asterisk below are used only once per session: 
+1. \*Create MyNocdlpack in MyWb. 
+~~~~~
+> ucreate -n <MyNoCDLPack>
+~~~~~
+2. Move to the source directory of MyNocdlpack. 
+~~~~~
+> wokcd <MyNoCDLPack>
+~~~~~
+3. Write the FILES list. You do this outside tcl, using the editor of your choice. 
+4. Write the source code. 
+5. Build MyNocdlpack. 
+~~~~~
+> umake [<MyNoCDLPack>]
+~~~~~ 
+
+#### Umake Steps for a Nocdlpack 
+
+The *umake* steps for development units of *nocdlpack* type are explained below. 
+* *src*               Processes FILES to list source files. 
+* *obj.cgen*   Processes the source files to generate code. 
+* *obj.inc*    Based on the list of source files, this step publishes the header files for the unit so that other units can use them. 
+* *obj.comp*   Compiles each file that can be compiled. 
+* *obj.idep*   Generates dependency information for the unit. This comprises: 
+       + Includes performed by unit compilation. (Unit.MakeState) 
+       + Implementation dependencies in terms of the unit suppliers. (Unit.ImplDep) 
+* *obj.lib*    Generates the shared library for the unit. 
+
+@subsubsection occt_wok_3_3_3  Creating a Schema
+If the application, which you intend to build, stores data in a file, you need to define a schema for the persistent data types that are known. 
+
+You create a schema and go to its root directory using the commands: 
+~~~~~
+> ucreate -n <MySchema>
+> wokcd <MySchema>
+~~~~~ 
+Using the editor of your choice, write a .cdl file to define the schema. This schema file lists all the packages that contain persistent data types used in the implementation of your application. It has the following format: 
+~~~~~
+       schema MySchema
+       is
+class <MyClass> from <Package>;
+       end;
+~~~~~
+       
+#### Building a Schema 
+
+Compile and check the coherence of the CDL specification for the schema: 
+~~~~~
+> umake -e xcpp.fill
+~~~~~
+Extract the C++ description: 
+~~~~~
+> umake -o xcpp
+~~~~~
+Compile the C++ description of the schema: 
+~~~~~
+> umake -o obj
+~~~~~
+Alternatively, the above three steps can all be carried out by one command: 
+~~~~~
+> umake
+~~~~~
+#### Sample Construction of a Schema 
+
+In the following example the schema *MySchema* is created. It contains all the schemas of the persistent classes of your own packages and the packages they depend on. Commands preceded by an asterisk below are used only once per session: 
+1. Create MySchema in MyWb. 
+~~~~~
+ > ucreate -s MySchema
+~~~~~
+2. Move to the source directory of MySchema. 
+~~~~~
+> wokcd MySchema
+~~~~~
+3. Edit the source file MySchema.cdl. You do this outside tcl, using the editor of your choice. 
+4. Derive implementation files. 
+~~~~~
+       > umake -e xcpp.sch
+~~~~~
+5. Derive application schema files. 
+~~~~~
+       > umake -o xcpp.ossg
+~~~~~
+6. Compile the schema. 
+~~~~~
+       > umake -o obj
+~~~~~
+
+#### Schema Files
+
+* Primary Files for a Schema
+       + *<Schema>.cdl* Primary schema file.
+* Derived C++ Files for a Schema
+       + *<Schema>.hxx* User header files.
+       + *<Schema>.cxx* Schema implementation files.
+       + *<Sch_MyPack_MyClass>.cxx* Schema implementation files.
+
+#### Umake Steps for a Schema 
+
+The umake steps for development units of schema type are explained below. 
+* *src*        Processes MySchema.cdl to generate a list of CDL files for the development unit. Processes the FILES file to list source files. 
+* *xcpp.fill*  Compiles the internal data structure to prepare for subsequent extractions. 
+* *xcpp.sch*   Extracts the schema implementation code. 
+* *obj.comp*   Compiles the extracted files that can be compiled. 
+* *obj.lib*    Generates the shared library for the unit. 
+* *obj.idep*   Generates dependency information for the schema. 
+
+@subsection occt_wok_3_5  Building an Executable
+@subsubsection occt_wok_3_5_1  Creating an Executable
+To make an executable from one or more of the packages, which you have created, write a .cdl file to specify the packages to use. 
+
+#### Writing an Executable
+
+Refer to the **CDL User’s Guide** for full details. A simple example is given below. 
+
+~~~~~
+       executable <MyExec> // the executable unit
+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;
+~~~~~  
+       
+Write the C++ file(s). For the example above you write two files: *myexec.cxx* and *myex2.cxx*.
+#### Building the Executable 
+
+To build the executable, use the command *umake*
+
+#### Construction of an Executable 
+
+In the following example an executable, *MyExec*, is created in the workbench *MyWb*. Commands preceded by an asterisk below are used only once per session: 
+1. \*Create MyExec in MyWb. 
+~~~~~
+       > ucreate -x MyExec
+~~~~~
+2. Move to the source directory of *MyExec*. 
+~~~~~
+       > wokcd MyExec
+~~~~~  
+3. Edit the cdl source file *MyExec.cdl*. You do this outside tcl, using the editor of your choice. 
+4. Edit the C++ files *AnExe.cxx*, etc. You do this outside tcl, using the editor of your choice. 
+5. Build MyExec. 
+~~~~~
+       > umake
+~~~~~  
+6. Run the executable file. 
+~~~~~
+       > wokcd -PLib
+               > MyExec
+~~~~~
+
+#### Executable Files 
+
+| <Exec>.cdl | primary executable file |
+| <AnExe>.cxx |                Source C++ file |
+| <AnExe>_[1-9].cxx |  Other source C++ files |
+
+#### Umake Steps for an Executable
+
+The umake steps for development units of executable type are explained below. 
+* *src* Processes MyExe.cdl to generate a list of CDL files for the development unit. Processes FILES to list source files. 
+* *src.list* Based on MyExe.cdl, works out the list of parts and the source files involved for each part. 
+* *exec.comp* Compiles the files that can be compiled for each part of the executable. 
+* *exec.idep* Generates dependency information for each part of the executable. 
+* *exec.libs* Computes full implementation dependency to prepare for linking for each part of the executable. 
+* *exec.tks* Performs toolkit substitution according to TOOLKITS for each part of the executable. 
+* *exec.link* Links each part of the executable. 
+
+@subsection occt_wok_3_6  Test Environments
+@subsubsection occt_wok_3_3_1  Testing an Executable
+To test an executable, you create an executable development unit and move to its structure.
+
+When you write the .cdl file for your test executable, specify the packages to test, for example: 
+~~~~~
+executable MyTest // the executable unit 
+       is 
+executable mytest1 // the binary file 
+is 
+       mytest1; //the C++ file 
+end; // several binaries can be specified in one .cdl file. 
+executable mytest2 
+is 
+       mytest2; 
+end; 
+       end; 
+~~~~~
+Write the C++ test file(s), in the example, *mytest1.cxx* and *mytest2.cxx*. 
+#### Building the Executable 
+
+To build the executable use the command: 
+~~~~~
+> umake
+~~~~~
+
+#### Setting up a Test Environment
 
-  Note: $CASROOT is equal to D:/occt now
+To set up a test environment, move to the <i>/drv</i> subdirectory that corresponds to the current profile (e.g. <i>/MyExec/drv/DFLT/sun</i>) and run the executable test file.  
+~~~~~
+> wokcd -PLib
+> wokenv -s
+> myApp
+~~~~~
+The command *wokenv* is used with -s option to configure the test environment.  
+The command *wokenv –s* uses the current workbench to decide what actions are needed to configure the tcl shell for use as your test environment.  
+WOK sets the following environment variables: 
 
-  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.
+* <i>$STATION</i>  - The current station. 
+* <i>$TARGET_DBMS</i> - The current database platform. 
+* <i>$PATH</i> - The current path, plus the bin directories of the parcels. 
+* <i>$LD_LIBRARY_PATH</i> The current path, plus the lib directories of the parcels. 
+WOK then sets a variable for each parcel listed in the parcel configuration of the current workshop. This variable is the original name of the delivery unit in the uppercase, with the suffix *HOME*.  
+* <i>$ORIGDELIVUNITHOME</i> is set as the root directory of the parcel. 
+WOK then sources the following files: 
+  *  MyFactory.tcl, found in the admin directory of the factory. 
+  *  MyWorkshop.tcl found in the admin directory of the workshop. 
+Then for each Workbench, WOK sources according to the hierarchy of the workbenches: 
+  *  Workbench.tcl, found in the /Adm directory of the workbench.  
   
-@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
+After the environment is set up, you are at a C shell prompt and can run the executable. 
+
+**Note** Environment variables are only set when the command is used with the option <i>-s</i>. Thus, if you change a workbench or a factory within WOK and then return to the test environment you must use *wokenv -s* to ensure that the set environment variables configuration is correct for the current WOK state.  
+The configuration actions that WOK performs can be written to a file and saved as a script. You can then edit this script to suit it to your own needs, and generate a personalized test environment. 
+
+To create the script file use the following command: 
+~~~~~
+ > wokenv -f <ScriptFile> -t csh
+~~~~~ 
+This command generates a file, ScriptFile, which configures a C shell to mirror the current WOK environment. An example script file is given below. 
+~~~~~
+setenv STATION *sil* 
+setenv TARGET_DBMS *DFLT* 
+setenv KERNELHOME */adv_22/WOK/BAG/KERNEL-K1-2-WOK* 
+setenv LD_LIBRARY_PATH */adv_22/WOK/BAG/wok-K1-2/lib/sil:/adv_22/WOK/BAG/KERNEL-K1-2-WOK/sil/lib/* 
+setenv PATH */usr/tcltk/bin:/usr/bin:/bin:/usr/bin/X11:/lib:.:/SGI_SYSTEM/util_MDTV/factory_proc:/adv_22/WOK/BAG/KERNEL-K1-2-WOK/sil/bin/* 
+source /adv_22/WOK/BAG/KERNEL-K1-2-WOK/adm/Kernel.csh 
+~~~~~
+
+@subsection occt_wok_3_7  Building a Toolkit
+@subsubsection occt_wok_3_7_1  Creating a Toolkit
+
+You create and enter a toolkit development unit using the following commands: 
+~~~~~
+       > ucreate -t <TKMyToolkit>
+       > wokcd <TKMyToolkit>
+~~~~~
+
+#### Write the Nomenclature File for the Toolkit 
+
+Using an editor, write a nomenclature file called PACKAGES which lists all the packages, one per line, that make up the toolkit. Add PACKAGES to FILES. 
+Build the shareable library for this toolkit as follows: 
+~~~~~
+\> umake [<TKMyToolkit>]
+~~~~~
+**Note:** when one of the packages in the toolkit is modified, recompile the toolkit. A package should belong to one toolkit only.
+
+#### Sample Construction of a Toolkit 
+
+In the following example, the toolkit **TKMyToolkit** is created. Commands preceded by an asterisk are used only once per session: 
+1. \*Create MyToolkit in MyWb. 
+~~~~~
+\> ucreate -t TKMyToolkit
+~~~~~
+2. Move to the source directory of MyToolkit. 
+~~~~~
+\> wokcd TKMyToolkit
+~~~~~
+3. Edit the nomenclature files, PACKAGES and FILES. You do this outside tcl, using the editor of your choice. 
+4. \*Create the library for MyToolkit 
+~~~~~
+\> umake TKMyToolkit
+~~~~~
+
+#### Umake Steps for a Toolkit 
+
+The umake steps for development units of toolkit type are explained below. 
+* *src*  Processes FILES to list source files. 
+* *lib.list* Works out the objects and archive library to add to the toolkit shared library. 
+* *lib.limit* Manages the build process strategy within the limitations of a particular platform. 
+* *lib.arch* Builds archives according to the building strategy. 
+* *lib.uncomp* Decompresses third party archives. 
+* *lib.arx* Extracts object files from archives. 
+* *lib.build* Generates the shared library for the toolkit.  
+
+Building strategy depends on the platform. The following step sequences apply: 
+  *  On Sun (Solaris): 
+~~~~~
+src 
+lib.list 
+lib.arx 
+lib.build 
+~~~~~  
+  *  On sil (IRIX): 
+~~~~~
+src 
+lib.list 
+lib.uncomp 
+lib.build 
+~~~~~
+
+#### The TOOLKITS File
+When executables are compiled, a TOOLKITS file is used to determine which toolkits are included. This file is located in the src directory of the entity being compiled. The process is as follows: 
+* If no TOOLKITS file has been found, all toolkits are candidates for substitution. To find out which toolkits are candidates, use the command  *w_info -k*. 
+* If an empty TOOLKITS file has been found, there is no toolkit candidate for substitution. 
+* If a non-empty TOOLKITS file has been found, only the toolkits listed in this file are candidates for substitution. 
+
+#### Toolkit Substitution
+
+Toolkit substitution is performed as follows: 
+1. MyEngine uses A, B and C; 
+2. The toolkit TK provides     A and D; D uses E; 
+3. Compilation of *MyEngine* includes TK, B C and E.
+Here, for simplicity, assume that additional toolkits are not substituted for B, C and E. 
+
+@subsection occt_wok_3_8  Building a Delivery Unit
+@subsubsection occt_wok_3_8_1  Creating a Delivery Unit
+~~~~~
+\> ucreate -d <MyDeliveryUnit>
+~~~~~
+
+#### Writing the COMPONENTS File
+
+Create a file named COMPONENTS in the src subdirectory of the delivery development unit. List in this file the prerequisites of the delivery and the components that are part of the delivery. Use the syntax shown below. 
+Note that keywords and default options are shown in bold. 
+
+| **Name** | ParcelName |
+| Put path | |
+| Put include ||
+|Put lib ||
+| **Requires** | DeliveryName\* |
+| **Package** | MyPack **[CDL][LIBRARY][INCLUDES][SOURCES]** |
+| **Nocdlpack** | MyNcdl **[LIBRARY][INCLUDES][SOURCES]** |
+| **Executable** | MyExec **[CDL][DYNAMIC][SOURCES]** |
+| **Interface** | MyIntf **[CDL][STUB_SERVER][SOURCES]** |
+| **Client** | MyClient **[CDL]**[STUB_CLIENT][SOURCES] |
+| **Engine** | MyEng **[CDL][DYNAMIC][SOURCES]** | 
+| **Schema** | MyShma **[CDL][LIBRARY][SOURCES][DOC]** |
+| **Toolkit** |MyTk **[LIBRARY][SOURCES]** |
+| **Get** | DevelopmentUnitName::Type:::File |
+
+\* Without mention of the version 
+
+If no keywords are specified then all default arguments shown in bold are taken into account. To select arguments, list the ones required explicitly. The arguments are explained below: 
+* **Name** The full name of the current delivery, including a version number. This is the name of the parcel. 
+* **Put path** Requires that the delivery be inserted in the user path (bin directory). 
+* **\[CDL\]** Copy the cdl files to the delivery. 
+* **\[LIBRARY\]** Generate the static library. Copy the shareable library to the delivery. Copy the list of objects of the library. 
+* **\[INCLUDES\]** Generate includes.origin. Copy the includes to the delivery. Copy the ddl to the delivery. 
+* **\[DYNAMIC\]** Select to copy the static or dynamic executable file. 
+* **\[SOURCES\]** Copy the source files. 
+
+#### Build the Delivery
+
+To build the delivery unit, use the command: 
+~~~~~
+\> umake <MyDeliveryUnit>
+~~~~~
+The result of building a delivery unit is a **parcel**, which can be installed in a warehouse and used by other workbenches. 
+
+#### Sample Delivery of a Parcel
+
+In the following example a delivery is created, compiled and made into a parcel. Commands preceded by an asterisk below are used only once per session: 
+1. Move to the root workbench under which the parcel is to be made.
+~~~~~
+> wokcd MyRootWb
+~~~~~
+2. \*Create MyDelivery in MyRootwb.
+~~~~~
+> ucreate -d MyDelivery
+~~~~~
+3. Move to the source directory of MyDelivery.
+~~~~~
+> wokcd MyDelivery
+~~~~~
+4. Use an editor to list all the prerequisites and components of the delivery in the COMPONENTS files using the appropriate syntax.
+5. Build MyDelivery.
+~~~~~
+> umake MyDelivery 
+~~~~~
+The output of the umake process is a parcel
+#### Umake Steps for a Delivery Unit
+
+The umake steps for development units of type delivery are explained below. 
+* *src*                                Processes FILES to list source files. 
+* *base*                            Creates directories, defines the list of units, copies the parcels and the release notes. 
+* *get.list*                    Lists files to get (using Get, Resource). 
+* *get.copy*                   Copy the files listed by get.list. 
+* *cdl.list*                         Lists CDL files to copy. 
+* *cdl.copy*                          Copies the files listed by cdl.list. 
+* *source.list*                Lists units from which sources are to be copied. 
+* *source.build*             Creates a file for sources (in the format: unit.type.Z). 
+* *inc.list*            Lists includes to copy. 
+* *inc.copy*                         Copies files listed by inc.list. 
+* *lib.shared*                         Works out the inputs for building or copying shareable libraries. 
+* *lib.shared.build*   Copies or builds (depending on the platform) the shareable libraries. 
+* *lib.server.list*           Lists interface files to copy. 
+* *exec.list*                Lists inputs for executable delivery. 
+* *exec.build*                 Creates executable in the parcel. 
+* *files*                             Works out the list of files delivered in the parcel. 
+
+@subsubsection occt_wok_3_8_2  Installing a Parcel
+You open the root workbench of the workshop where you want to install the parcel using the following command: 
+~~~~~
+\> wokcd <MyWorkshop> 
+~~~~~
+To install the parcel, use the following syntax: 
+~~~~~
+\> pinstall <MyParcel>
+~~~~~
+
+@subsection occt_wok_3_9  Working with Resource
+
+### Building a Resource 
+
+There is a single umake step for development units of resource type. 
+* *src*                 Processes FILES to list source files. 
+
+@subsection occt_wok_3_10  Java wrapping
+@subsubsection occt_wok_3_10_1  Creating an interface
+
+To create an interface development unit and move to its structure, use commands: 
+~~~~~
+\> ucreate -i <MyInterface>
+\> wokcd <MyInterface>
+~~~~~
+
+### Writing an Interface 
+
+Having created the interface, you select the classes and packages that you wish to make available for Java wrapping in the jni units. Use an editor of your choice to write a .cdl interface file that specifies these exported services. This file has the format: 
+
+~~~~~
+interface MyInterface 
+uses 
+  ListOfPackages; 
+is 
+  ListOfPackages; 
+  ListOfClasses; 
+  ListOfMethods; 
+end; 
+~~~~~
+
+### Building an Interface
+
+To make the services of the interface available for further wrapping, build the interface, using the command: 
+~~~~~
+> umake [<MyInterface>] -o src
+~~~~~
+
+### Sample Construction of an Interface
+
+In the following example a workbench, *MyWb*, is used for working on the interface *MyInterface*. Commands preceded by  \* (asterisk) are used only once during a session. 
+
+1. \*Create MyInterface in MyWb. 
+~~~~~
+>ucreate -i MyInterface 
+~~~~~
+2. Move to the source directory of MyInterface. 
+~~~~~
+>wokcd MyInterface 
+~~~~~
+3. Edit the source file MyInterface.cdl. You do this outside tcl, using an editor of your choice. 
+4. Build the interface. 
+~~~~~
+> umake -o src 
+~~~~~
+
+### Interface Files
+
+_<Interface>.cdl_ is the primary interface file. 
+
+### Umake Steps for an Interface
+
+The umake steps for development units of type interface are explained below. 
+
+* *src* - processes *MyInt.cdl* to list the CDL files for the development unit. Processes the FILES file to list source files. 
+
+**Note** Make sure you only use the *src* step of umake. Using umake without arguments will lead to an attempt of launching other steps relevant to the interface unit. However these steps will fail and anyway are not required for use in Java wrapping. 
+
+@subsubsection occt_wok_3_10_2  Creating a jni
+To create a development unit of type jni and move to its structure, use commands: 
+~~~~~
+> ucreate -j <MyJni>
+> wokcd <MyJni>
+~~~~~
+
+### Writing a Jni 
+
+Use an editor to write a .cdl file that specifies the interface or interfaces required by the jni. This file has the following format: 
+~~~~~
+client MyJni 
+is 
+{interface MyInterface;} 
+{interface YourInterface;} 
+end; 
+~~~~~
+
+### Building a Jni
+
+To wrap services exported by the interfaces to Java, build the jni, using the command: 
+~~~~~
+ > umake [MyJni] 
+~~~~~
+
+### Sample Construction of a Jni
+
+In the following example a workbench, *MyWb*, is used for working on the jni, *MyJni*. Commands preceded by  \* (asterisk) are used only once during a session. 
+
+1. \*Create MyJni in MyWb. 
+~~~~~
+> ucreate -j MyJni  
+~~~~~
+2. Move to the source directory of *MyJni*. 
+~~~~~
+> wokcd MyJni  
+~~~~~
+3. Edit the source file *MyJni.cdl*. You do this outside tcl, using an editor of your choice. 
+4. Derive Java files (.java and .class files) and C++ files (.h and .cxx) used for wrapping. 
+~~~~~
+ > umake -e xcpp 
+~~~~~
+5. Compile the sources. 
+~~~~~ 
+> umake -o obj 
+~~~~~
+6. Link the object files. 
+~~~~~
+> umake -o exec
+~~~~~
+
+Primary jni file is *Jni.cdl*
+
+Derived Java files for a Jni are:
+* <Package>_<Class>.java - Java source file of the class to be wrapped. 
+* <Package>_<Class>.class - Compiled java source file. 
+
+Derived C++ files for a Jni are:
+* <Jni>_<Package>_<Class>_java.h       - Include file for the C++ implementation of JNI. 
+* <Jni>_<Package>_<Class>_java.cxx     - C++ implementation of JNI.
+
+### Umake Steps for a Jni
+
+The umake steps for development units of type jni are explained below. 
+* *src*          Processes MyJni.cdl to list the CDL files for the development unit. Processes the FILES file to list source files. 
+* *xcpp.fill*     Compiles the internal data structure to prepare for subsequent extractions. 
+* *xcpp.client*        Extracts the services declared in included interface unit(s) into Java and creates .java and \*_java.cxx files. 
+* *xcpp.javac*         Compiles .java files into .class files. 
+* *xcpp.javah*         Creates .h header files. 
+* *obj.comp* Compiles generated C++ files. 
+* *obj.idep*         Generates dependency information for the unit. 
+* *exec.libs*  Computes full implementation dependency to prepare for linking. 
+* *exec.tks*         Performs toolkit substitution. 
+* *exec.link*        Generates the shared library for the development unit. 
+
+@subsection occt_wok_3_11  More Advanced Use
+@subsubsection occt_wok_3_11_1  Default User Profile
+There is a default user profile. If you wish to change this profile the command *wokprofile* is available. 
+
+An example profile is given below. 
+~~~~~
+       Info : Profile in : WOK:k1dev:ref 
+       Info : Extractor : DFLT 
+       Info : Compile Mode : Optimized 
+       Info : Station Type : sil 
+~~~~~
+@subsubsection occt_wok_3_11_2  Changing Parcel Configuration
+Parcel configuration rarely needs changes. However, if you do need to modify the list of resources, you can do so by editing the admin parameter file of the factory. This file is found in the admin directory of the factory and is named after the workshop. It has the suffix .edl. Its full name has the following format: 
+~~~~~
+<MyWorkshop>.edl.
+~~~~~
+
+Move to the admin directory of the factory: 
+~~~~~
+\> wokcd <MyFactory> -PAdm
+~~~~~
+
+Then use the editor of your choice to edit the admin parameter file, MyWorkshop.edl. 
+In this file, the parcel configuration is defined by an entry of the form: 
+~~~~~
+\@set %<MyWorkshop>_ParcelConfig = “Parcel1 Parcel2...Parceln”;
+~~~~~
+The resources are listed within quotation marks. They are separated by spaces. 
+Edit this list as required. Save the file and close it. 
+To validate and take into account your changes use the command: 
+~~~~~
+\> wokclose -a 
+~~~~~
+This command closes and reopens all the entities. Without the -a option, *wokclose* only applies to the current entity. 
+
+@section occt_wok_4_ Available Services
+@subsection occt_wok_4_1  Synopsis
+WOK provides sets of services, which can be grouped according to the entity they apply to: 
+  *  General Services 
+  *  Factories 
+  *  Warehouses 
+  *  Parcels 
+  *  Workshops 
+  *  Workbenches 
+  *  Development Units 
+  *  Source Management Services 
+  *  Session Services 
+@subsubsection occt_wok_4_1_1  Common Command Syntax
+
+#### Command Names 
+
+All WOK commands follow a common naming convention. This is based on a set of common command names and a group of prefixes, which denote entity type. The command name takes a prefix representing the entity to which it applies. 
+The following prefixes exist: 
+  *  f: for factories 
+  *  s: for workshops 
+  *  w: for workbenches 
+  *  u: for development units 
+  *  W: for warehouses 
+  *  p: for parcels 
+  *  wok: for commands that apply to any type of entity 
+These prefixes are followed by a command that determines the action to be executed. Examples of such commands are: 
+  *  create: create an entity 
+  *  rm: delete an entity 
+  *  info: request information 
+Consequently, the command ucreate creates a development unit. The command wrm removes a workbench. 
+
+#### Command Options
+
+All command options are expressed using a dash (-) followed by one or more key letters and, if applicable, an argument. For example: 
+~~~~~
+> umake -f -o <argument> MyUnit
+~~~~~
+The compact version of this syntax is also valid: 
+~~~~~
+ umake -fo argument MyUnit 
+~~~~~
+This syntax conforms to the POSIX recommendations for UNIX commands. 
+For all commands, there is a –h option, which displays help on usage. 
+
+#### Presentation of Commands
+
+The general syntax of the commands is presented in this document as follows: 
+~~~~~
+CommandName [option(s) [<argument(s)>] [<Entity>]]
+~~~~~
+Consequently, there are four general cases for a command: 
+~~~~~
+CommandName <Entity>
+CommandName <option(s)> [<argument(s)>] <Entity>
+CommandName <option(s)> [<argument(s)>]
+CommandName
+~~~~~
+**Note** a few commands described in this chapter do not completely respect this syntax; for example, *create* and *rm*. 
+
+As a rule, where an _<EntityPath>_ is given as an argument it specifies which entity the command applies to. Where no _<EntityPath>_ is specified, the command applies to the nearest appropriate entity. The *create* and *rm* commands are notable exceptions: you **must** specify an entity path with these commands. 
+
+@subsection occt_wok_4_2  General Services
+General services are commands that apply to any entity manipulated by WOK. They are used for: 
+  *  Navigation 
+  *  Managing parameters 
+  *  Managing profiles. 
+
+@subsubsection occt_wok_4_2_1  wokcd
+~~~~~
+wokcd
+wokcd <EntityPath>
+wokcd -P <ParamSuffix> [<EntityPath>]
+~~~~~
+
+Navigates between different WOK entities and changes the current working directory. Without any arguments wokcd lists the current position (the WOK equivalent of ‘pwd’). With an argument, wokcd moves to the specified location. 
+Options: 
+* _<EntityPath>_       Moves to the home directory of the entity specified by <EntityPath>, i.e. moves to the location given by the parameter: %wokcd <EntityPath>_Home.
+* _-P <ParamSuffix> [<EntityPath>]_ Moves to the <ParamSuffix> directory of the entity specified by <EntityPath>. i.e. moves to the location given by the parameter: %<EntityPath>_<ParamSuffix>. If no entity path is specified, this command moves to the <ParamSuffix> directory of the current entity.
+
+Possible values for <ParamSuffix> are: Home, Adm and Src.
+Use the following commands to change directories within a development unit: 
+* **wsrc** To access the source files. 
+* **winc** To access the include files. 
+* **wobj** To access objects. 
+* **wlib** To access shareable libraries. 
+* **wbin** To access executables. 
+* **wadm** To access the workbench administration files. 
+
+#### Examples 
+
+*wokcd* - Lists the current position. 
+
+*wokcd MODEL:GTI:gti:gp* - Moves to the home directory of the gp package of the gti workbench in the GTI workshop in the MODEL factory. 
+
+*wokcd -P Adm* - Moves to the administration directory of the current entity. 
+
+
+@subsubsection occt_wok_4_2_2  wokclose
+~~~~~
+wokclose [-a] 
+~~~~~
+Closes and reopens entities, i.e. reloads them into memory thus taking any changes into account. 
+Option <i>-a</i> closes and reloads all entities. 
+
+#### Examples
+
+~~~~~
+wokclose 
+~~~~~
+Closes and reopens the current entity. 
+~~~~~
+wokclose -a 
+~~~~~
+Closes and reopens all the entities. 
+@subsubsection occt_wok_4_2_3  wokenv
+~~~~~
+wokenv -f <ScriptFile> -t csh
+~~~~~
+Creates the file <ScriptFile>. This file is a script, which configures a C shell to mirror the current WOK environment. See the <a href="#occt_wok_3_6">Test Environments</a> section for more details. 
+Options: 
+* -f <ScriptFile> - Specifies the name of the file to produce. 
+* -t csh - Produces a file for configuring a C shell. 
+* -s - Sets up environment variables for application launching. 
+Example
+------- 
+~~~~~
+> wokenv -f MyTestEnvScript -t csh
+~~~~~
+Generates the shell script *MyTestEnvScript* to configure a C shell so that it mirrors the current WOK environment. 
+@subsubsection occt_wok_4_2_4  wokinfo
+~~~~~
+wokinfo -<option> [<EntityPath>]
+wokinfo -<option> <argument> [<EntityPath>]
+~~~~~
+Displays information about _<EntityPath>_. The information displayed is common to all the entities. If no _<EntityPath>_ is specified, information about the current entity is returned. 
+This command can be used to find the path of a file. 
+Options: 
+* -t - Returns the type of entity (factory, warehouse, parcel, workbench, development unit). 
+* -T - Lists the types of files known in the entity. 
+* -f - Gets factory from path. 
+* -N - Gets the nesting path, i.e. where the current entity is nested. 
+* -n - Gets entity name. 
+* -P - Gets parcel from path. 
+* -s - Gets workshop from path. 
+* -u - Gets development unit from path. 
+* -W - Gets warehouse from path. 
+* -w - Gets workbench from path. 
+* -x - Tests if entity exists. 
+* -d <type> - Gets type definition. 
+* -a <type> - Gets type arguments. 
+* -p <type>:<filename> - Gets the path for a file, which is of the type type that depends on %File. In other words, the path for a file of this type depends on the file name, <filename>. 
+* -p <type> - Gets the path for a file, which is of the type <type> that is not %File dependent, for example EXTERNLIB. 
+
+#### Examples
+
+~~~~~
+wokinfo -p source:gp.cdl MODEL:GTI:gti:gp 
+~~~~~
+Returns the path of the source file gp.cdl in the MODEL:GTI:gti:gp. 
+~~~~~
+wokinfo -t MODEL:GTI:gti:gp 
+~~~~~
+Returns the development unit. 
+
+@subsubsection occt_wok_4_2_5  woklocate
+~~~~~
+woklocate -<option> <argument> [<WorkbenchPath>]
+woklocate -P [<WorkbenchPath>]
+~~~~~ 
+Using WorkbenchPath as the starting point, this command locates files associated with the development unit and specified by the argument argument. 
+Options are: 
+* -f <Unit:Type:File> - Locates a file and gives its ID. 
+* -p <Unit:Type:File> - Locates a file and gives its path. 
+* -u <Unit> - Locates a development unit. 
+* -P - Displays all available WOK public types. 
+
+#### Example
+
+~~~~~
+woklocate <MyFile> 
+~~~~~
+Displays the location of the file, MyFile. 
+
+@subsubsection occt_wok_4_2_6  wokparam
+~~~~~
+wokparam -<option> [<EntityPath>]
+wokparam -<option> <argument> [<EntityPath>]
+~~~~~
+Queries system parameters such as variables and templates. For more information about parameters refer to the appendix *Parameters and EDL Files* at the end of this User’s Guide. If an <EntityPath> is specified this indicates the entity to which the command applies. 
+Options: 
+* -L - Lists the directories used to search for the parameter files. 
+* -C - Displays the subclasses list. 
+* -a <TemplateName> - Gets arguments for the template TemplateName. 
+* -e <ParamName> - Evaluates the parameter ParamName. 
+* -F <ClassName> - Displays the files comprising the definition of the class *ClassName*. 
+* -l <Class> - Lists parameters concerning class (prefix) class. 
+* -S <FileName> - Finds the first file FileName in the list of directories cited afterwards. 
+* -t <Name> - Tests if the variable Name is set. 
+* -v <ParamName> - Displays the value of the parameter *ParamName*. 
+* -s <Name>=\<Value> Reserved for advanced use. Sets the variable *Name* to value *Value*. 
+* -u <Name> Reserved for advanced use. Unsets the variable Name. 
+
+#### Examples 
+
+~~~~~
+wokparam -L MODEL:GTI:gti 
+~~~~~
+Returns a list of directories used for parameters by the gti workbench. 
+~~~~~
+wokparam -S CSF.edl 
+~~~~~
+Locates the nearest CSF.edl file used by the current entity. 
+~~~~~
+wokparam MODEL:GTI:gti:gp -e %WOKUMake_Steps 
+~~~~~
+Displays the value of the _\%WOKUMake_Steps_ parameter in the *gp* package. The _\%WOKUMake_Steps_ parameter contains a description of the steps used by umake. 
+@subsubsection occt_wok_4_2_7  wokprofile
+~~~~~
+wokprofile
+wokprofile -<option> [<argument>]
+~~~~~
+Modifies session parameters. This command changes the mode of the current compilation and the profile of the current database. It also displays the current value of the session parameters. If no argument is specified, it displays the values of different parameters in the current session as well as the current position *wokprofile -v*. 
+Options: 
+* -b - Returns the current database profile (OBJS, DFLT). 
+* -d -  Switches to compilation with debug. 
+* -m - Returns the current compilation mode. 
+* -o - Switches to optimized compilation. 
+* -s - Returns the current station type 
+* -v - Switches to wokprofile verbose mode. In this mode all the parameters of the session are displayed. Running this command displays the current/changed profile. 
+
+#### Examples 
+
+~~~~~
+wokprofile 
+~~~~~
+Displays all the session parameters. 
+~~~~~
+wokprofile -b 
+~~~~~
+Displays the current database profile. 
+~~~~~
+wokprofile -v -o 
+~~~~~
+Switches to optimized compilation and displays the parameters of the current session after the change has been made. 
+~~~~~
+wokprofile -o -v 
+~~~~~
+Switches to optimized compilation and displays the parameters of the current session after the change has been made. Note that the order in which these options are specified does not affect the result. 
+
+@subsection occt_wok_4_3  Services Associated with Factories
+There is a dedicated list of commands for the management of factories. The commands to create and destroy factories are reserved for the exclusive use of the site administrator. 
+* *fcreate* Creates a factory. 
+* *finfo* Displays information about the factory. 
+* *frm* Deletes a factory if it is empty. 
+
+@subsubsection occt_wok_4_3_1  fcreate
+*Reserved for administrator’s use* 
+~~~~~
+fcreate -<option> [-D <Suffix>=<Value>]* <EntityPath>
+~~~~~
+Creates a factory. The name of the factory to create is specified by EntityPath. You can also specify the entity that will contain the entity to be created. 
+
+Once the creation is completed, a file containing the parameters of the creation of the factory is created in the administration directory of the container to which the factory belongs. 
+
+Parameters: 
+The following parameters are mandatory when a factory is created: 
+* **Adm** - Path name for administration directory 
+* **Home** - Path name for home directory 
+* **Stations** - List of supported stations 
+* **DBMSystems** - List of supported dbms 
+* **Warehouse** - Name of factory warehouse. 
+
+Options: 
+* -P - Propose defaults. Returns a list of default values for the parameters necessary for the creation of the factory. No entity is created if this option is used. 
+* -d Use default. Uses default values to create the factory. 
+* -D<Suffix>=\<Value> - Defines parameter(s). Specifies the value to use for the given parameter(s) explicitly. This option can be used in conjunction with the –d option to take default values for all the mandatory parameters except the parameter(s) explicitly specified here. 
+
+#### Examples 
+
+~~~~~
+fcreate -P NewFactoryName 
+~~~~~
+Returns a list of default values for the parameters that are mandatory when creating a factory. 
+~~~~~
+fcreate MyFactory -d -DHome=/fred/myfactory 
+~~~~~
+Creates the factory MyFactory using default values for all mandatory parameters, except for Home, which is set to: /fred/myfactory 
+
+@subsubsection occt_wok_4_3_2  finfo
+~~~~~
+finfo -<option> [<EntityPath>]
+~~~~~
+Displays details about the factory. If an EntityPath is specified this determines the factory to apply to. If no entity path is given, the command applies to the nearest factory. 
+Options: 
+* -s - Displays a list of workshops in the factory. 
+* -W - Displays the name of the warehouse in the factory. 
+* -S - Displays the name of the source repository. 
+
+#### Examples
+
+~~~~~
+finfo -s 
+~~~~~
+Displays a list of workshops in the nearest factory. 
+~~~~~
+finfo MyFactory -W 
+~~~~~
+Displays the name of the warehouse in MyFactory. 
+
+@subsubsection occt_wok_4_3_3  frm
+*Reserved for administrator’s use* 
+~~~~~
+frm <EntityPath>
+~~~~~
+Deletes the factory specified by EntityPath if it is empty. 
+
+Note, that you must not be in the factory you intend to destroy. 
+
+#### Example
+
+~~~~~
+frm MyFactory 
+~~~~~
+Deletes the factory MyFactory provided that it is empty. 
+
+@subsection occt_wok_4_4  Services Associated with Warehouses
+A warehouse contains the parcels that are available in a factory. There is a dedicated list of commands for management of warehouses. 
+The commands you use to create and destroy the warehouses are reserved for the exclusive use of the site administrator. 
+* *Wcreate*   - creates a warehouse. 
+* *Winfo* - displays information about the warehouse 
+* *Wrm* - deletes a warehouse if it is empty. 
+* *Wdeclare* - declares a parcel in the warehouse. 
+
+@subsubsection occt_wok_4_4_1  Wcreate
+*Reserved for administrator’s use.* 
+~~~~~
+Wcreate [-<option>] -D<Suffix>=<Value>* <WarehouseName>
+Wcreate -<option> [-D <Suffix>=<Value>]* <WarehouseName>
+~~~~~
+Creates a warehouse. The name of the warehouse to create is given by *<WarehouseName>*. You can also specify the factory that will contain the warehouse. 
+Once the creation is completed, a file containing the parameters of warehouse creation is in its turn created in the administration directory of the factory to which the warehouse belongs. 
+
+Parameters: 
+The following parameters are mandatory when a warehouse is created: 
+* **Adm** - Path name for administration directory. 
+* **Home** - Path name for home directory. 
+* **Stations** - List of supported stations. 
+* **DBMSystems** - List of supported dbms. 
+
+Options: 
+* -P - (Propose defaults.) Returns a list of default values for the parameters necessary for the creation of a warehouse. No entity is created if this option is used. 
+* -d - (Use defaults.) Uses default values to create the warehouse. 
+* -D <Suffix>=\<Value> (Define parameter.) Explicitly specifies the value to use for this parameter. This option can be used in conjunction with the –d option to take default values for all the mandatory parameters except the parameter(s) explicitly specified here. 
+
+#### Examples
+
+~~~~~
+Wcreate -P MyWarehouse 
+~~~~~
+Returns a list of default values for the parameters that are mandatory when creating a warehouse. 
+~~~~~
+Wcreate MyWarehouse -d 
+~~~~~
+Creates the warehouse *MyWarehouse* using default values for all mandatory parameters. 
+@subsubsection occt_wok_4_4_2  Winfo
+~~~~~
+Winfo -p [<EntityPath>]
+~~~~~
+Displays details about the warehouse and its contents. If an EntityPath is specified, this determines the warehouse to apply to. 
+Option -p displays the parcels in the warehouse. 
+
+#### Example
+
+~~~~~
+Winfo -p 
+~~~~~
+Displays a list of parcels in the current warehouse. 
+@subsubsection occt_wok_4_4_3  Wrm
+*Reserved for Administrator’s Use.* 
+~~~~~
+Wrm <EntityPath> 
+~~~~~
+Deletes the warehouse specified by EntityPath if it is empty. You should not be in the warehouse you intend to destroy. 
+#### Example
+
+~~~~~
+Wrm MyWarehouse 
+~~~~~
+Deletes the warehouse *MyWarehouse* provided that it is empty. 
+@subsubsection occt_wok_4_4_4  Wdeclare
+*Reserved for administrator’s use* 
+~~~~~
+Wdeclare -p<Parcel> [-d] [-D<ParamName>=<Value>]* <House>
+~~~~~
+Declares the *Parcel*. This command adds the parcel to the list of parcels available in the warehouse House. 
+Note that a factory has a default list of deliveries (which are represented by parcels) available to it. This list only needs to be modified when moving to a new version of the delivery. This is done using the *Wdeclare* command, and then by editing the .edl file of the appropriate workshop. 
+
+The following parameters are mandatory when declaring parcels: 
+* **Adm** - Path name for administration directory of a parcel. 
+* **Home**  - Path name for home directory of a parcel. 
+* **Stations** - List of available stations. 
+* **DBMSystems**  - List of available dbms. 
+* **Delivery** - Delivery name. 
+
+Options: 
+* -p <Parcel> Defines the name of the parcel to declare. This name must be given with the option. 
+* -d Creates a parcel using defaults. 
+* -P Proposes defaults. 
+
+#### Example
+
+~~~~~
+Wdeclare -pMyParcel -d MyWarehouse 
+~~~~~
+Adds the parcel MyParcel to the warehouse MyWarehouse. 
+
+@subsection occt_wok_4_5  Services Associated with Parcels
+A parcel is a receptacle for development units. You use it to group together the units, which comprise a delivery unit. There is a dedicated list of commands for management of parcels. Only the site administrator should perform installation of parcels in a warehouse. 
+* *pinfo* - displays information about the contents of the parcel 
+* *pinstall* - installs the parcel in a Warehouse. 
+
+@subsubsection occt_wok_4_5_1  pinfo
+
+pinfo -<option> [<ParcelPath>] - displays details about the contents of the parcel. If *ParcelPath* is specified this determines the parcel to apply to. If no parcel path is specified the command applies to the nearest parcel. 
+
+Options: 
+* -d - Displays the delivery contained in the parcel. 
+* -l - Displays the development units in the parcel. 
+* -a - Lists the development units in the parcel together with their types. 
+
+#### Examples 
+
+~~~~~
+pinfo -l MyParcel 
+~~~~~
+Displays a list of units in the parcel MyParcel. 
+
+@subsubsection occt_wok_4_5_2  pinstall
+*Reserved for administrator’s use* 
+~~~~~
+pinstall <ParcelName> 
+~~~~~
+Installs the parcel <ParcelName> in the current warehouse. The process of installing a parcel sets up various paths and variables to ensure that the application can locate necessary resources and so on. 
+The administrator must perform *pinstall* for each platform used. 
+
+#### Example
+
+~~~~~ 
+pinstall MyParcel 
+~~~~~
+Installs the parcel *MyParcel* in the current warehouse. 
+
+@subsection occt_wok_4_6  Services Associated with Workshops
+A workshop is a tree of workbenches using the same parcel configuration. There is a dedicated list of commands for management of workshops. The commands to create and destroy workshops are reserved for the exclusive use of the site administrator. 
+* *screate* - creates a workshop. 
+* *sinfo* - displays information about the workshop 
+* *srm* - deletes a workshop if it is empty. 
+
+@subsubsection occt_wok_4_6_1  screate
+*Reserved for administrator’s use* 
+~~~~~
+screate [-<option>] {-D<Suffix>=<Value>}* <WorkshopName>
+screate -<option> <WorkshopName>
+~~~~~
+Creates a workshop, <WorkshopName>. You can also specify the factory that contains this workshop. 
+Once the creation is completed, a file containing the parameters for the creation of the workshop is generated in the administration directory of the factory to which it belongs. 
+
+The following parameters are mandatory when creating a workshop: 
+* **Adm** - Path name for administration directory. 
+* **Home** - Path name for home directory. 
+* **Stations** - List of supported stations. 
+* **DBMSystems** - List of supported dbms. 
+* **ParcelConfig** - List of parcels used. 
+* **Workbenchlist** - Path name for the list of workbenches. 
+
+Options: 
+* -P (Propose defaults.) Returns a list of default values for the parameters necessary for the creation of a workshop. No entity is created if this option is used. 
+* -d (Use defaults.) Uses default values to create the workshop. 
+* -D <Suffix>=\<Value> (Define parameter.) Specifies the value to use for this parameter explicitly. This option can be used in conjunction with the –d option to accept default values for all the mandatory parameters except the parameter(s) explicitly specified here. 
+
+
+#### Examples
+
+~~~~~
+screate -P <WorkshopName>
+~~~~~
+Returns a list of default values for the parameters that are mandatory for creating a workshop. 
+~~~~~
+screate MyFactory:MyWorkshop -d 
+~~~~~
+Creates the workshop *MyWorkshop* in the factory *MyFactory*, using default values for all mandatory parameters. 
+~~~~~
+screate -DParcelConfig=Parcel1,Parcel2 MyFactory:MyWorkshop -d 
+~~~~~
+Creates the workshop *MyWorkshop* in the factory *MyFactory*, using default values for all mandatory parameters except for *ParcelConfig*, which is set to *Parcel1 Parcel2*. 
+
+@subsubsection occt_wok_4_6_2  sinfo
+~~~~~
+sinfo -<option> [WorkshopName] 
+~~~~~
+Displays details about the workshop. If *WorkshopName* is specified this determines the workshop this command is applied to. If no workshop is specified the command applies to the nearest workshop. 
+Options: 
+* -w - Displays a list of workbenches in the workshop. 
+* -p - Displays the parcel configuration of the workshop. 
+
+#### Example 
+
+~~~~~
+sinfo -w 
+~~~~~
+Displays a list of workbenches in the nearest workshop. 
+
+@subsubsection occt_wok_4_6_3  srm
+*Reserved for administrator’s use* 
+~~~~~
+srm WorkshopName 
+~~~~~
+Deletes the workshop <WorkshopName> if it is empty. You must not be in the workshop you intend to destroy.
+
+#### Example
+
+~~~~~
+srm MyWorkshop 
+~~~~~
+Deletes the *MyWorkshop* provided that it is empty. 
+
+@subsection occt_wok_4_7  Services Associated with Workbenches
+A workbench is the place where a developer (or a team of developers) works on a particular product. There is a dedicated list of commands for management of workbenches. 
+
+* *wcreate* - creates a workbench. 
+* *w_info* - displays information about a workbench. 
+* *wrm* - deletes a workbench if it is empty. 
+* *wmove* - moves a workbench to a new location. 
+
+@subsubsection occt_wok_4_7_1 wcreate
+~~~~~
+wcreate -f <ParentWB> [-D <Suffix>=<Value>]* <WBName>
+wcreate -f <ParentWB> -P|d [-D <Suffix>=<Value>]* <WBName>
+wcreate -f <ParentWB> -P|d <WBName>
+~~~~~
+Creates the workbench <WBName> as a child of the workbench <ParentWB>. The result of this creation is a directory structure. 
+Compared to the creation of other entities, creating a workbench requires an additional piece of information: you must specify the parent of the workbench to create. 
+Once the creation is completed, a file containing the parameters of the creation of this workbench is created in the administration directory of the workshop that contains it. 
+Parameters: 
+The following parameters are mandatory when creating a workbench: 
+* **Adm**              Path name for administration directory. 
+* **Home**             Path name for home directory. 
+* **Stations**         List of supported stations. 
+* **DBMSystems**       List of supported dbms. 
+
+Options: 
+* -f - Specifies the parent workbench. 
+* -P - (Propose defaults.) Returns a list of default values for the parameters necessary for the creation of the workbench. No entity is created if this option is used. 
+* -d - (Use defaults.) Uses default values to create the workbench. 
+* -D <Suffix>=\<Value> - (Define parameter.) Specifies the value to use for this parameter explicitly. This option can be used in conjunction with the –d option to take default values for all the mandatory parameters except the parameter(s) explicitly specified here. 
+
+#### Example
+
+~~~~~
+wcreate -P WorkBenchName 
+~~~~~
+Returns a list of default values for the mandatory parameters to create a workbench. 
+~~~~~
+wcreate MyWorkbench -d 
+~~~~~
+Creates the workbench MyWorkbench using default values for all mandatory parameters. 
+**Note** The –f option of this command is not obligatory. The system administrator can create the root workbench of a workshop without specifying a parent workbench.
+@subsubsection occt_wok_4_7_2  w_info
+~~~~~
+w_info -option[Workbench] 
+w_info -option argument[Workbench] 
+~~~~~
+The *w_info* command is the exception to the common command syntax. The form w_info is used instead of winfo because the latter already exists as a tcl/tk command and cannot be reused as a name by WOK. If <Workbench> is specified, this determines the workbench to apply to. If no <Workbench> is specified, the nearest workbench is used. 
+
+Using the tcl winfo command by mistake generates an error message, but does not cause any damage. 
+
+Options: 
+* -l - Lists the development units in the workbench. 
+* -a - Lists the development units in the workbench along with their respective types. 
+* -f - Displays the parent workbench. 
+* -A - Lists all the ancestors of the workbench. 
+* -k - Lists visible toolkits. 
+* -S <arg> - Lists suppliers of the unit <arg> within the visibility of the workbench. 
+* -S <execname:partname> - Lists the suppliers of the component executable partname within an executable development unit execname. 
+* -I <arg1, arg2 ... argN> - Lists the development units, sorted by order of implementation dependency. 
+
+#### Example
+
+~~~~~
+w_info -S MyDevUnit 
+~~~~~
+
+Returns a list of suppliers of the development unit MyDevUnit within the visibility of the current workbench. 
+
+@subsubsection occt_wok_4_7_3  wrm
+~~~~~
+wrm Workbench 
+~~~~~
+Deletes the workbench, provided that it is empty and has no children. You must not be in a workbench you intend to destroy. 
+
+#### Example
+~~~~~
+wrm MyWorkbench 
+~~~~~
+Deletes *MyWorkbench*, provided that it is empty and has no children. 
+
+@subsubsection occt_wok_4_7_4  wmove
+*Reserved for advanced use* 
+wmove -f <NewParentWorkbench> <Workbench>
+Moves the <Workbench> (and its children), to a different parent *NewParentWorkbench* within the same workshop. 
+Option  -f <argument> specifies the new parent workbench. 
+
+#### Example
+
+~~~~~
+wmove -f MyOtherWorkbench MyWorkbench 
+~~~~~
+Moves the *MyWorkbench* under *MyOtherWorkbench*. 
+
+@subsubsection occt_wok_4_7_5  wprocess
+~~~~~
+wprocess <WorkbenchName> <options>
+~~~~~
+Allows automatic reconstruction of a workbench. 
+
+Options: 
+* -DGroups =Obj,Lib,Exec               - Selects groups Obj, Lib and Exec. 
+* -DUnits = MyUd1,MyUd2,...    - Selects the development units MyUd1, MyUd2 etc. 
+* -DXGroups =Src,Deliv                         - Excludes groups Obj and Deliv. 
+* -DXUnits=MyUd1,MyUd2,...             - Excludes units MyUd1, MyUd2 etc. 
+* -B <Profile>                                         - Selects the extraction profile. 
+* -f                                                   - Forces all selected steps. 
+* -d | -o                                              - Switches between debug and optimized modes. 
+* -P                                                   - Prints out the selected steps. 
+* -S                                                   - Silent mode (no print of the banner). 
+* -L                                                   - Logs output to MyUD_<step code>. Log in step administration directory. Valid group names are: Src, Xcpp, Obj, Dep, Lib, Exec, Deliv. 
+
+#### Example
+
+~~~~~
+wprocess -DGroups=Src,Xcpp,Obj,Lib,Exec 
+~~~~~
+Compiles the whole workbench 
+
+@subsection occt_wok_4_8  Services Associated with Development Units
+The development unit is the basic building block of development work in the WOK environment. It is the base component of Open CASCADE Technology architecture. For a list of available types of development units refer to the <a href="#occt_wok_2_1">Development Units</a> section. There is a dedicated list of commands for management of development units. 
+
+* *ucreate* **Creates** a development unit. 
+* *uinfo* **Displays** information about the development unit. 
+* *urm* **Deletes** a development unit. 
+* *umake* **Builds** a development unit. 
+
+@subsubsection occt_wok_4_8_1  ucreate
+~~~~~
+ucreate [-<TypeCode>] <UnitName>
+ucreate -P 
+~~~~~
+Creates a development unit named <UnitName> of type <TypeCode>. 
+
+Once the creation is completed, a file containing the parameters of the creation of the development unit is generated in the administration directory of the workbench to which the development unit belongs. 
+
+TypeCodes: 
+* -p - Creates a development unit of type package. This is the default option. Where no option is specified, a development unit of type package is created. 
+* -n - Creates a development unit of type nocdlpack. 
+* -s - Creates a development unit of type schema. 
+* -t - Creates a development unit of type toolkit. 
+* -d - Creates a development unit of type delivery. 
+* -x - Creates a development unit of type executable. 
+* -f - Creates a development unit of type frontal. 
+* -r - Creates a development unit of type resource. 
+* -P - Displays ucreate creation possibilities in format: <TypeCode> <TypeName>. 
+
+#### Examples
+
+~~~~~
+ucreate -p MyWorkbench:MyPackage 
+~~~~~
+Creates the development unit *MyPackage* in *MyWorkbench*. The unit is of package type. 
+
+@subsubsection occt_wok_4_8_2  uinfo
+
+~~~~~
+uinfo -t|c [<UnitPath>]
+uinfo -f|F|p [-<FilterOption> [<Type>]]* [<UnitPath>]
+~~~~~
+
+Displays details about the development unit. Where no <UnitPath> is specified, details of the current unit are displayed. Filter options are available for use in conjunction with the options -f, -F, -p to filter the file list. Combinations of filter options can be used.
+Note that the uinfo command is based on the results of construction using umake. As a consequence, the list of files displayed by uinfo is only valid if the construction has completed normally. Similarly, the list of files derived from the CDL is only valid if the CDLs of the unit have been translated successfully. 
+
+Options: 
+* -t - Displays the type of the development unit as a string. 
+* -c - Displays the typecode of the development unit, i.e. a single character, as used by *ucreate* to indicate package (p), schema (s) and so on. 
+* -f - Displays a list of file names associated with the unit. 
+* -F - Displays a list of file names associated with the unit, together with their respective types. Types of files include for example: *source*, *library*, *executable*, and *pubinclude*. To display a full list of file types, use the command *ucreate*. 
+* -p - Displays the full paths of the files associated with the unit. 
+Filter Options: 
+* -T - <Type> Displays files of type <Type> only. 
+* -i - Displays only *independent* files, i.e. files that are not specific to a DBMS, for example sources. 
+* -s - Displays only station dependent files. 
+* -b - Displays only DBMS dependent files. 
+* -B - Displays only files that are dependent on *both *DBMS and Station. 
+* -l - Displays only files that are local to the workbench. 
+* -m - Displays only missing files, i.e. files that are listed, but not found. 
+* -e - Displays only existing files, i.e. files that are listed and found. 
+
+#### Examples
+
+~~~~~
+uinfo -Fp 
+~~~~~
+Displays the types, paths and names of all files associated with the unit. 
+~~~~~
+uinfo -f -Tpubinclude MyWorkbench:MyUnit 
+~~~~~
+Lists the names of the header files associated with the unit MyUnit which is in MyWorkbench. 
+
+@subsubsection occt_wok_4_8_3  urm
+~~~~~
+urm <UnitPath> 
+~~~~~
+Deletes the development unit <UnitPath> with its directory structure and its files, even if the unit is referenced by another one. 
+
+#### Example
+~~~~~ 
+urm MyWorkBench:MyPack 
+~~~~~
+Deletes the development unit *MyPack* found in *MyWorkBench*. 
+
+@subsubsection occt_wok_4_8_4  umake
+~~~~~
+umake -S [<UnitPath>]
+umake [-f][<UnitPath>]
+umake [-f]-o<step> [-t<target>]* [-o<step> [-t<target>]*]*[<UnitPath>]
+umake [-f][-s <step>] [-e <step>][<UnitPath>]
+umake
+~~~~~
+Builds a development unit. The build process includes compilations, links, and various other actions, which make the development unit usable. The build process is specific for each type of development unit, refer to chapter 3 for details. 
+The following properties apply: 
+1. There are steps identified by a keyword. 
+2. The steps involved and their content depends on the type of development unit being treated. 
+3. You can ask for single step execution using the -o option. 
+4. Unless explicitly requested using the –f option, the operations are carried out in those steps where necessary. 
+5. Only the processed development unit is modified. 
+
+Used without any arguments the *umake* command carries out all of the steps appropriate for the development unit to be constructed. Using keywords and arguments you can perform the build process step by step. 
+
+Options: 
+* -S                   - Displays the list of steps. 
+* -s <step>    - Starts the build process at the step specified. 
+* -e <step>    - Ends the build process at the step specified. 
+* -o <step>    - Only executes the step specified. 
+* -t <target>  - Specifies the target to build. 
+* -f                   - Forces the build process, skipping the verification of dependencies. 
+
+#### Example
+
+~~~~~
+umake gp 
+~~~~~
+Builds the gp package. 
+
+@subsubsection occt_wok_4_8_5 Specifying Targets (-t) for umake
+
+The umake command is also used to specify build targets and extract C++ method prototypes. src, xcpp and obj units can be targeted. The syntax is explained below. 
+For delivery units (for all options apart from *.list) the syntax is as follows: 
+~~~~~
+-\*.\* -t MyDU 
+umake MyDeliv -olib.shared.build -tMyUD. 
+~~~~~
+
+#### src
+
+This target computes a source file list as in the example below: 
+~~~~~
+umake -o src MyUnit 
+~~~~~
+
+#### xcpp
+
+Extracts C++ header files. For -xcpp.\* (with the exception of \*.fill), the syntax is as follows: 
+~~~~~
+umake -o -xcpp.* -t MyPack_MyClass 
+~~~~~
+You extract the method prototypes using the following command: 
+~~~~~
+umake -o xcpp.template [-t<class>|-t<package>]
+~~~~~
+This syntax of  *umake* command is only used with packages. It extracts the C++ prototypes of the methods of the classes contained in the package. 
+The generated files are placed in the src directory of the current package. These files always have a .template suffix. With each extraction of a class, these files will contain all the methods of the class. 
+Prototypes are extracted for: 
+  *  Ordinary classes (non-instantiated) 
+  *  Generic classes (including nested generic classes) 
+  *  Package methods 
+Classes, which are instantiations of generic classes, are not extracted. Nor are other CDL types (exceptions, alias, etc.) which have no user implementation. 
+For each class, we extract the prototypes of: 
+  *  Instance methods 
+  *  Class methods 
+  *  Constructors 
+The extracted files are the following: 
+  *  for an ordinary class C 
+         +  C.cxx.template for the non-inline class methods. 
+         +  C.lxx.template for the inline class methods. 
+  *  for a generic class G 
+         *  G.gxx.template for the non-inline class methods. 
+         *  G.lxx.template for the inline class methods. 
+  *  for a package method P 
+         *  P.cxx.template for the non-inline package methods. 
+         *  P.lxx.template for the inline package methods. 
+         
+         
+#### obj
+
+Specifying the target, *obj* compiles the object files for one or more files. The syntax for -obj.* is as follows: 
+~~~~~
+umake -o -obj.* -t MyPack_MyClass.cxx 
+~~~~~
+In a package, the following command executes all construction steps up to and including obj, doing for each of them only what is strictly necessary: 
+~~~~~
+umake -s obj 
+~~~~~
+The following command will recompile all the primary sources of a package which are out of date: 
+~~~~~
+umake -o obj 
+~~~~~
+
+@subsubsection occt_wok_4_8_6  Customizing umake
+You can use three levels of umake customization for a development unit. 
+  *  Compiler and link options, EXTERNLIB 
+  *  Step definition 
+  *  Tcl umake step implementation 
+These different levels of complexity correspond to the needs of regular users and more advanced users. 
+
+#### Modification of Compiler and Link Options and EXTERNLIB
+
+Customization at this level involves setting parameters of existing umake steps using an .edl file. This file is taken into account each time umake is performed. It contains a series of assignments or appended variables used when creating the development unit. These commands can be preceded by instructions dedicated to the preprocessor in order to adjust its behavior within the actual context. 
+
+EXTERNLIB uses resources contained in Open CASCADE Technology prerequisites. To avoid referencing the path of these resources more than one time, the user may use the component EXTERNLIB to include these resources automatically via the link. The file contains the name of parameters, which are set independently. 
+
+The umake command does not generate actual dependencies. To avoid any cumbersome dependencies, for example, if you do not want the shareable library file for a package but the package enumeration only, use the INTERNLIB component listed in FILES, to get only the given dependencies. 
+
+In practice, the generated file, <myUD>.ImplDep, in the /drv/adm directory, is copied into INTERNLIB. INTERNLIB contains lines of enumerations, as below: 
+~~~~~
+Dependence 1 
+Dependence 2 
+... 
+~~~~~
+The example below illustrates how you can modify your WOK compiler options. Refer to *Using EDL to Define WOK Parameters* for an example of how to set link options as well as for more details about available parameters and .edl files. 
+~~~~~ 
+-- File Name: Kernel_CMPLRS.edl 
+-- Copyright: Matra Datavision 1996 
+#--------------------------------- 
+#// First, ensure that we only execute this file once 
+\@ifnotdefined ( %Kernel_CMPLRS_EDL ) then 
+       \@set %Kernel_CMPLRS_EDL = **; 
+#// Then set C++ compilation options, based on workstation type: 
+       \@if( %Station == *sil* ) then 
+\@set %ModeOpt =  * *; 
+       \@endif; 
+       \@if( %Station == *ao1* ) then 
+\@set %ModeOpt = *-g *; 
+       \@endif; 
+       \@if( %Station == *hp* ) then 
+\@string %CMPLRS_C_Options +=  * -Aa -D_HPUX_SOURCE +e*; 
+       \@endif; 
+\@endif; 
+~~~~~
+
+#### Step Definition
+
+The WOK umake command uses a dependency tree. This dependency tree is a graph that shows the umake steps, their inputs and their dependencies. You use it to perform the build, for example to ensure that only files, which have changed, and the files, which depend on these modified files, are recompiled. 
+
+This dependency tree is defined in an .edl file. The steps are listed in an order. Each is assigned a name and has its inputs specified. The output of one or more steps is the input to another step. 
+
+The following steps are standard for WOK umakes: src, src.list, exec.comp and exec.link. Any new step that you insert into the tree must be associated with a tcl program, which will be responsible for performing the step. You supply these tcl programs. For more details of tcl programming refer to the examples below and also to the <a href="#occt_wok_8">Tcl Overview</a> section. 
+
+The following example defines a umake dependency tree and introduces two new steps: exec.kerobj and exec.core. Each of these steps is then associated with a tcl program. 
+~~~~~
+-- File Name: DCube_WOKSteps.edl 
+
+\@ifnotdefined (%DCube_WOKSteps_EDL) then 
+       \@set %DCube_WOKSteps_EDL = **; 
+       \@string %WOKSteps_ObjGroup += *obj.libs obj.arx obj.objs *; 
+---\@set %WOKUmake_Steps =**src obj.inc(src) objc.cgen(src) obj.comp(src, obj.cgen) obj.libs(src) obj.arx(obj.libs) obj.objs(obj.arx) obj.lib(obj.comp, obj.objs) obj.idep(obj.comp,src)*; 
+       \@set %WOKSteps_obj_libs = *DCube_Libs(src)*; 
+       \@set %WOKSteps_obj_arx = *WOKStep_LibExtract(obj.libs)*; 
+       \@set %WOKSteps_obj_objs = *DCube_Objs(obj.arx)*; 
+\@set %WOKSteps_obj_lib = *WOKStep_DynamicLibrary(obj.comp, obj.objs)*; 
+       \@set %WOKSteps_toolkit_ListWith = *obj.comp obj.objs*; 
+\@endif; 
+~~~~~
+
+#### Tcl Step Implementation
+
+Customization at the tcl step level requires an understanding of the build process and the WOK dependency tree. Modification at this level is generally used to add elements to the build which are not described in the CDL. For example one possible use is to include external libraries or files into the final shareable library. Refer to <a href="#occt_wok_8_3_4">Writing Tcl Steps for a WOK Build</a> for more details.
+@subsection occt_wok_4_9  Source Management Services
+You use the source management services to integrate source files between a root workbench and one of its children. The services are related to a particular workshop. 
+
+* *wprepare* - displays a report of the files state in the current workbench (as compared with the files in the root workbench). 
+* *wstore* - queues a report for further integration and stores the related files. 
+* *wintegre* - performs check-in operations for requested files and updates the root workbench. 
+* *wnews* - allows management and use of data stored in the integration journal. 
+* *wget* - imports source files to the current workbench. 
+
+@subsubsection occt_wok_4_9_1  wprepare
+~~~~~
+wprepare –wb <father workbench> [-ud <ud1,ud2,...,udN>] -o [<filename>]
+wprepare –wb <father workbench> [-ref][-ud <ud1,ud2,...,udN>] -o [<filename>]
+~~~~~
+Prepares a report for integration to a reference (root) Workbench. This command prints a comparison of the state of source files contained in the specified units, <ud1,ud2,...,udN,> of the current workbench. 
+
+This workbench must be a direct descendant of the root workbench. If no unit names are specified, all the units in the workbench are processed. By default, the results of the comparison are printed to the standard output. The differences are computed in relation to the root workbench. 
+
+For each file, the status is indicated as follows: 
+* \# The file has been modified. 
+* \= The file was found in the current workbench but was not modified. 
+* \- The file has been removed. In other words, the entry was deleted from FILES). 
+* \+ The file has been added. In other words, the entry has been added in FILES). 
+
+Options: 
+* -ref - Creates a report that is used to initialize a base of source files. This report is used with the *wintegre -ref* command. 
+* -ud <ud1>, <ud2>, ..., <udN> - Specifies the list of development units to prepare for integration. Separate the unit names with a comma. If no unit names are specified, all the units in the workbench are processed. 
+* -o <fileName> - Writes the integration report to the specified file. By default, the report is displayed (i.e. written to standard output). 
+* -wb <The name of target workbench> - Specifies the name of target workbench. It should be one of father workbenches with attached integration queue. 
+
+@subsubsection occt_wok_4_9_2  wstore
+~~~~~
+wstore –ls –wb <MasterWb>
+wstore -cat <ID>
+wstore [-trig] -rm <ID> [-f] –wb <MasterWb>
+wstore –create –wb <MasterWb>
+wstore [<FileName>]
+~~~~~
+This command manages the queue of pending reports. When a report is queued it is given a unique number also called a report-ID. 
+
+Options: 
+* <FileName> - Adds a report from the file FileName to the report queue. 
+* -trig - Calls a tcl procedure after the report has been processed. This tcl procedure must be located in the admin directory of the workshop and the file must be named wstore_trigger.tcl. An example of a trigger can be found in the file <i>$env(WOK_LIBRARY)/wstore_trigger.example</i>. 
+* -ls - Lists pending reports, together with their owners and their IDs. This is a default option. If two files are found with the same name in the same development unit in two different reports the full path of each of these files is displayed. 
+* -cat <Report_ID> - Displays the contents of the report <i><Report_ID></i>. 
+* -rm - Removes a report from the report queue. 
+* -f - Forces deletion. This option must be used with the -rm option when you delete a report that you do not own. 
+* -param - Lists queue parameters associated with the workbench. 
+* -create –wb <MasterWb> -queue <any/dir> -type SCCS - Creates an integration queue associated with MasterWb workbench, queue should be located at any/dir and specify SCCS type of database. 
+
+Possible options for –create are: 
+* -queue - Specify the name of directory under which queue is created 
+* -type - Specify the type of database (can be SCCS or RSC, SCCS by default) 
+* -base - Specify the location where to put the repository (only for SCCS database). Default behavior: creates repository in the adm directory of the master workbench. 
+* -counter - Specify the name of directory where the integration counter is located. Default behavior: creates subdirectory adm in directory created using –base option 
+* -journal - Specify the location of integration journal. Default behavior: : creates subdirectory adm in directory created using –base option 
+* -welcome - If increment contains new development units, by default store will refuse such increment. If you want to be able to add new units to MasterWb through integration mechanism use – welcome option. 
+
+#### Example 
+
+~~~~~
+wstore ReportName –wb MasterWb 
+~~~~~
+Queues the report ReportName and saves a copy of the files mentioned in the report. This copy will be used when the report is actually processed by the command *wintegre*.
+~~~~~
+wstore –wb MasterWb -f -rm Report_ID 
+~~~~~
+Removes the report Report_ID from the queue, even if you do not own it. 
+
+@subsubsection occt_wok_4_9_3  wintegre
+~~~~~
+wintegre [<reportID>] –wb <MasterWb> 
+~~~~~
+Processes a report and removes it from the queue in the current workshop. 
+
+Parameters: 
+* <reportID> - Number indicating the rank of the report in the integration queue. Use the command *wstore –l* to get this number. 
+
+Options: 
+* -ref <BaseNumber> - Initializes the version of the elements in the repository. 
+* -all - Processes all the reports in the integration queue. 
+* -wb - Specify the integration queue of which workbench should be used 
+* -norefcopy - Updates the repository but not the target workbench. 
+* -nobase - Updates the target workbench but not the repository. This option is rather useful when copying a set of UDs from a workbench into another. 
+* -param - Shows the parameters’ current value. 
+
+**Note** that the -nobase and -norefcopy options are mutually exclusive.
+
+#### Examples
+
+~~~~~
+wintegre -ref 2 1 –wb ref 
+~~~~~
+Uses the report whose ID is 1 to initialize the ref workbench with BaseNumber equal to 2. 
+~~~~~
+wintegre 1 –wb ref 
+~~~~~
+Integrates the report whose ID is 1 to ref workbench. 
+~~~~~
+wintegre -f 8 –wb ref 
+~~~~~
+Forces the integration of report 8. Use the –f option if you want report 8 to be processed first. 
+
+
+~~~~~
+wprepare -MyWb -o/tmp/MyReport 
+wstore /tmp/MyReport (GetID say 3) –wb ref 
+wintegre –wb ref -nobase 3 
+~~~~~
+Edit the comment and modify <i>/tmp/MyReport</i> if required with current workbench accessed from ref workbench. 
+You may use the -nobase option adding the following line in the VC.edl file (Adm of the concerned file): 
+~~~~~
+\@set %VC_TYPE = *NOBASE*; 
+~~~~~
+@subsubsection occt_wok_4_9_4  wnews
+
+The command has the following syntax: 
+~~~~~
+wnews [-x] [-from p1 -to p2] [-headers|-units|-comments|- all] [-command TclCmd] 
+wnews -set markname [ -at p ] 
+wnews -ls [-bydate] 
+wnews -rm markname 
+wnews -admin 
+wnews -purge 
+~~~~~
+
+The *wnews* command allows managing and using the data stored in the integration journal. 
+The integration journal is updated via the command *wintegre* each time an integration is performed; it contains all the UDs and files concerned with the integration, as well as the comments provided by the developers (reports). 
+
+Every integration is numbered and the associated files are archived with a specific version number. 
+Marks can be set on specific zones of the integrations via the wnews command. A mark is a character string which does not contain any dash character (-) and is associated with an integration number. Several marks may point to the same number, but one mark may only point to one number. 
+
+**Note** that *BEGIN* and *END* are reserved mark names. You cannot use them. 
+
+Options: 
+* -from p1 -to p2 - Extracts a portion of the journal file between index p1 and p2, with p1 and p2 integration numbers or marks. If p1 is not specified, reports are extracted from the beginning of the journal file. If p2 is not specified, reports are extracted up to the end of the journal file. 
+* -at p - Places a mark at index p, with p being an integration number. If p is not specified, the mark is placed at the end of the journal. 
+* -ls [-bydate] - Lists the marks. If -bydate is specified, the marks are listed in the order they were created. Otherwise, they are listed according to their place in the journal file. 
+* -rm <markname> - Removes the mark *markname*. 
+* -admin - Displays the journal location, date and other information. 
+* -purge - Saves the journal file and creates a new empty one. 
+
+Additional options: 
+* -o file <name> - Redirects output in file. This option is ignored if -command is specified. 
+* -ws <shop> - Uses journal of shop instead of the current one. shop must belong to the current factory. 
+* -command <MyCommand> - Runs the command *Tcl MyComm* on the specified part of the journal. The syntax is the following: *proc MyComm { comments table args } { ...}*, where *comments* is a string containing all the comments on the integration between n1 and n2, and *table* is a table indexed with the names of the concerned *uds* (each element of the table is a list of UD files with definition of their status and version). Additional arguments may be passed using *userdata* with the argument *args* containing *mydata1, mydata2*. 
+
+Wok provides a similar procedure *wnews:cpwb*, which allows to copy UDs from one workbench into another. 
+
+**Note** that you may access the associated code of this command by typing *tclsh>cat $env(WOK_LIBRARY)/news_cpwb.tcl*
+For example, we can add the following to the file *Me.tcl*: 
+~~~~~
+proc MyComm {comments table args} { 
+puts *comments = $comments* 
+parray table 
+puts *args = $args* 
+return 
+} 
+~~~~~
+Then type the following commands: 
+~~~~~
+\> source Me.tcl 
+\> wnews -x -from n1 -to n2 -command MyComm -userdata wb1 wb2 
+~~~~~
+
+Examples
+--------
+~~~~~
+wnews -set BETA_V1.1 -at 345 
+~~~~~
+Sets a mark on integration number 345 
+~~~~~
+wnews -set RELEASED_V1.1_CLOSED 
+~~~~~
+Sets a mark after the last integration performed 
+~~~~~
+wnews -ls 
+~~~~~
+Lists all the marks set in the journal 
+~~~~~
+wnews -x -from INT_DEB -to INT_END -units 
+~~~~~
+Gets all the UDs modified between integrations INT_DEB and INT_END. Integration numbers and marks may be mixed as in the following: 
+~~~~~
+wnews -x -from INT_DEB -to 856 -comments 
+wnews -x -from INT_DEB -to INT_END -comments 
+~~~~~
+Gets all the comments from the integrations between *INT_DEB* and *INT_END* 
+~~~~~
+source Mycommand.tcl 
+wnews -x -from INT_DEB -to INT_END -command Mycommand 
+~~~~~
+In a more elaborate way, a Tcl process may be called to get all information on the reports between *INT_DEB* and *INT_END*.
+~~~~~ 
+wnews -x -from n1 -to n2 -command wnews:cpwb –userdata w1,w2,[ulist, notes] 
+~~~~~
+All modified files between n1 and n2 are copied from workbench w1 into workbench w2. New UDs are created in w2 if required If *ulist* is specified, only the UDs contained in this list are Processed. If notes is specified, all comments between n1 and n2 are written into this file. 
+
+@subsubsection occt_wok_4_9_5  wget
+~~~~~
+wget [-l] –wh <MasterWb>
+wget [-f] –wb <MasterWb> [-ud <UnitName>] <SourceFile> [-v <Version>]
+wget [-f] –wb <MasterWb> [-ud <UnitName>] <SourceFile1>...<SourceFileN>
+~~~~~
+The *wget* command allows importing source files into the workbench. The files are fetched from the SCCS database of the factory. This operation is known as a check-out operation. You can specify one or more files or a unit name. By default, the latest version of the files is fetched.
+Options: 
+* <SourceFile> - Fetches a copy of the specified file. 
+* -ud <UnitName> Fetches all the source files of the development unit you specified. 
+* -f Forces existing files to be overwritten. 
+* -v <Version> Fetches <Version> of the file you specified. 
+* -l Lists the files of the development unit that can be copied (i.e. that you can **get**). This is a default option. 
+
+#### Example
+
+~~~~~
+wget –wb MasteWb –ud MyUd File1.cxx File2.hxx 
+~~~~~
+Fetches the latest version of *File1.cxx* and *File2.hxx*.
+@subsubsection occt_wok_4_9_6  Installation Procedure
+
+In the new WOK model: 
+  *  each workbench can have its own database 
+  *  the version control environment variables are relative to the workbench. 
+@image html /dev_guides/wok/images/wok_image014.jpg "Workshop Installation Model"
+@image latex /dev_guides/wok/images/wok_image014.jpg "Workshop Installation Model"
+
+The following procedure explains how to set up the source management environment for a workshop. 
+1. Open the factory and the workshop. 
+~~~~~
+\> wokcd <factory:workshop> -P Adm
+~~~~~
+2. Define the environment variables for version control by editing the file *VC.edl*. Your entries should respect the following syntax: 
+~~~~~
+\@set %VC_TYPE=”SCCS”
+\@set %VC_ROOT=”/dirA/dirB/.../<MyDir>”
+~~~~~
+3. Reopen the workbench that you want to connect to the database. 
+~~~~~
+\> wokcd <factory:workshop:workbench>
+~~~~~ 
+4. Create SCCS database associated with workbench. 
+~~~~~
+\> wstore –create –wb <factory:workshop:workbench> -queue <PathToQueue>
+~~~~~
+5. Create a report associated with the root workbench. 
+~~~~~
+\> wprepare –wb <workbench> -o ref.report
+~~~~~
+6. Queue this report. 
+~~~~~
+\> wstore –wb <workbench> ref.report
+~~~~~
+7. Perform the actual creation of the SCCS database. 
+~~~~~
+> wintegre –wb <workbench> < BaseNumber >
+~~~~~
+Here <BaseNumber> is the first digit of the SCCS version numbers. 
+
+@subsubsection occt_wok_4_9_7  Integration Procedure
+
+To integrate, proceed as follows: 
+1. Create the report for the current workbench.
+~~~~~ 
+ \> wprepare –wb MasterWb -o MyReport 
+~~~~~
+2. If necessary, edit this report to remove lines and append comments. Comments should begin with -- (double hyphen). 
+3. Queue the report and store the files. 
+~~~~~
+\> wstore –wb MasterWb MyReport
+~~~~~
+By this step, all the files you have modified have been stored and the report has been queued. You can continue with modifying these files. 
+4. Examine the state of the integration queue to get the ID of your report. 
+~~~~~
+\> wstore –wb MasterWb -ls
+~~~~~
+5. Perform the integration and be sure you can write in the root workbench. This operation is usually reserved for the workshop administrator. 
+~~~~~
+\> wintegre –wb MasterWb [ID]
+~~~~~
+
+@subsection occt_wok_4_10 Session Services
+
+A single session service is also available to allow you to query WOK. 
+*Sinfo* command returns details of the WOK session. 
+~~~~~
+Sinfo -option 
+~~~~~
+
+Options: 
+* -F Gets factory list 
+* -f Gets current factory 
+* -s Gets current workshop 
+* -w Gets current workbench 
+* -u Gets current development unit 
+* -t <entity_path> Gets the entity type 
+* -E Reserved for internal use. Gets known Entity List 
+* -N Reserved for internal use. Gets known Entity Names 
+
+#### Example
+
+~~~~~ 
+Sinfo -F 
+~~~~~
+Returns a list of WOK factories. 
+
+@subsubsection occt_wok_4_10_2  Convenience Aliases
+
+To ease the upgrade to the new version of WOK a number of aliases, compatible with the old version, have been set up. These convenience aliases include: 
+* **fcd** - Moves to the specified factory. 
+* **scd** - Moves to the specified workshop. 
+* **wcd** - Moves to the *src* directory of the specified development unit. 
+* **wdrv** - Moves to the *drv/DBMS/Station* directory of the current development unit. 
+* **wls** - Lists the development units in the current workbench. 
+* **wsrc** - Moves to the *src* directory of the current development unit. 
+
+@section occt_wok_5 Using the Graphic Interface
+The following is an overall description of the IWOK main menu bar. Please, refer to the on-line help to get more detailed information on the various applications accessed via the graphic interface. 
+@subsection occt_wok_5_1  Main menu bar
+@image html /dev_guides/wok/images/wok_image015.png
+@image latex /dev_guides/wok/images/wok_image015.png
+@subsubsection occt_wok_5_1_1  Menus
+The main menu bar contains three menus: 
+  *  **File** to exit the iwok session, 
+  *  **Windows** to display all windows created in the session, 
+  *  **Help** to display the associated on-line help. 
+
+@subsubsection occt_wok_5_1_2  Application icons
+The four icons on the left are used to access applications: 
+  *  **wprepare**, allows preparing the integration queue being associated with a given workshop, 
+@image html /dev_guides/wok/images/wok_image016.png
+@image latex /dev_guides/wok/images/wok_image016.png
+  *  **umake**, gives access to all available umake options plus compilation options, 
+@image html /dev_guides/wok/images/wok_image017.png
+@image latex /dev_guides/wok/images/wok_image017.png
+  *  **CDL browser**, provides information on the class structure or translated classes, 
+@image html /dev_guides/wok/images/wok_image018.png
+@image latex /dev_guides/wok/images/wok_image018.png
+
+ *  **parameters**, allows displaying and editing all EDL files. 
+@image html /dev_guides/wok/images/wok_image019.png
+@image latex /dev_guides/wok/images/wok_image019.png
+
+
+**Note:** for further information on CDL, refer to the CDL Reference Manual. 
+
+@subsubsection occt_wok_5_1_3  Display management
+Click on the logo to either display or not the session in a window just below the main menu bar. 
+
+You may choose to display icons in the window, either in **columns**, with the **last modified first**, by **date and size**, or in **rows**. 
+
+Use the **go up** icon to navigate through the session and **wokcd** to update the window where the session was started. 
+@image html /dev_guides/wok/images/wok_image020.png
+@image latex /dev_guides/wok/images/wok_image020.png
+
+The field **Location** gives the exact address of the item in the session. Use the arrow on the right to select already visited addresses. 
+
+@subsection occt_wok_5_2  Popup menus
+Two types of popup menus may be accessed according to the context. Just click MB3 to display the popup menu. 
+
+Click on an item in the left window to get the popup menu providing access to applications. 
+
+@image html /dev_guides/wok/images/wok_image021.png
+@image latex /dev_guides/wok/images/wok_image021.png
+
+In the right window you get the selection popup menu for the item types: 
+
+@image html /dev_guides/wok/images/wok_image022.png
+@image latex /dev_guides/wok/images/wok_image022.png
+
+@section occt_wok_6 Appendix A. Using the Emacs Editor
+
+WOK is operated using the editor Emacs. Emacs is not provided in the Open CASCADE Technology distribution but is available from http://www.gnu.org/software/emacs/#Releases
+
+A CDL mode has been created for Emacs. The .el file for this mode is not provided in the distribution, but is available on request from OPEN CASCADE. 
+
+List of Keys and their Bindings in cdl Mode
+-------------------------------------------
+
+|C-c |Command prefix |
+|TAB | cdl-tab |
+|DEL | backward-delete-character-untabify |
+|ESC | Command prefix |
+|C-c C-x | cdl-new-exception |
+|C-c C-e | cdl-new-enumeration |
+|C-c C-b | cdl-new-buffer |
+|C-c C-p | cdl-new-package |
+|C-c C-r | cdl-new-rubric |
+|C-c C-c | cdl-new-class |
+|C-c f | cdl-fill-mode |
+|C-c s | cdl-structure |
+|C-c t | cdl-tabsize |
+|C-c e | cdl-comment-end |
+|ESC k | cdl-find-class |
+|ESC q | cdl-comment-fill |
+|ESC TAB | cdl-untab |
+|ESC-RET | cdl-raw-newline |
+
+@section occt_wok_7 Appendix B. Parameters and EDL Files
+@subsection occt_wok_7_1 EDL language
+@subsection occt_wok_7_1_1 Key Concepts
+
+EDL is a script-like programming language.
+
+**Comment** - text, preceded by two hyphens. 
+~~~~~
+-- Comment text.... 
+~~~~~
+* **Identifier** - any combination of characters in the ranges A-Z, az, 0-9 and _ (underscore). 
+* **Variable** - an identifier preceded by % (percent sign). 
+* **Actions** The following actions are available: 
+~~~~~
+\@string 
+\@set 
+\@apply 
+~~~~~
+* **Execution**  <i>@uses</i> is an execution operator.
+* **Input/Output** The following input/output operators are provided: 
+~~~~~
+\@file 
+\@write 
+\@close 
+\@cout
+~~~~~ 
+* **Conditional Operators** The following conditional operators are provided: 
+~~~~~
+\@iffile 
+\@ifdefined 
+\@ifnotdefined 
+\@ifnotfile 
+\@if 
+then 
+\@else 
+\@endif
+~~~~~
+* **Operators** The following operators are available: 
+<code>
+== 
+!= 
+|| 
+&& 
+file 
+notfile 
+defined 
+notdefined 
+</code>
+
+**Templates** The following template commands/keywords are available: 
+~~~~~
+\@template 
+is 
+\@end 
+\@addtotemplate 
+\@cleartemplate 
+~~~~~
+**Miscellaneous** The following miscellaneous commands exist: 
+~~~~~
+\@verboseon 
+\@verboseoff 
+~~~~~
+
+@subsubsection occt_wok_7_1_2  Syntax
+The following conventions are used in the explanations below: 
+
+| *<Variable>*         | refers to a variable, for example: *%myvariable* |
+| *<Id>*               | refers to an identifier, for example: *myidentifier* |
+| *“String”*       | refers to a string of characters, for example: *“my string of characters”* |
+| *<Condition>* | refers to a condition, for example: *(%mytest == “ok”) || (%mytest == “good”)* |
+| *<Template>*         | refers to the name of a template, for example: mytemplate. |
+|{}            | indicates possible repetition of what is within the curly brackets. |
+
+@subsubsection occt_wok_7_1_3  EDL Actions
+\@string 
+--------
+~~~~~
+\@string <Variable> = {<Variable> or “String”} ;
+\@string <Variable> += {<Variable> or “String”} ;
+~~~~~
+Concatenates the contents of the variables and strings on the right of the equals sign and assigns the result to the variable situated on the left. Using the operator ‘+=’ instead of ‘=’ adds the concatenation to the current contents of the variable on the left. 
+
+\@set
+---- 
+~~~~~
+\@set <Variable> = “ String” ;
+~~~~~
+Sets <Variable> to the value “String”
+
+\@apply
+------ 
+~~~~~
+\@apply <Variable> = <Template> ;
+~~~~~
+Evaluates the template, <Template>, and sets <Variable> equal to this.
+
+
+\@uses
+-----
+~~~~~
+\@uses <Variable>;
+\@uses “ String”;
+~~~~~
+Runs an EDL file. The name of this file is either contained in the variable <Variable> or is given as a string, <String>.
+
+\@file
+-----
+~~~~~
+\@file <Id> <Variable> ;
+\@file <Id> “String” ;
+~~~~~
+Opens a file and associates it with the identifier <Id>. This <Id> identifies the file until it is closed. The name of the file is given as a string <String>, or using a variable <Variable>.
+
+\@write
+------
+~~~~~
+\@write <Id> <Variable> ;
+~~~~~
+Writes the contents of the variable out to a file indicated by the file <Id>. This <Id> is the identifier allocated to the file when is opened using \@file.
+
+\@close
+------
+~~~~~
+\@close <Id> ;
+~~~~~
+Closes the file identified by <Id>. This <Id> is the identifier allocated to the file when is opened using \@file.
+
+\@cout
+-----
+~~~~~
+\@cout {<Variable> or “String”} ;
+~~~~~
+Concatenates the contents of the variables and strings and displays the result on standard out.
+
+\@iffile
+-------
+~~~~~
+\@iffile ( <Variable> or “String”) then
+\@endif ;
+\@iffile ( <Variable> or “String”) then
+\@else
+\@endif ;
+~~~~~
+Checks for the existence of a file, the name of which is given in the string  ‘String”, or else contained in the variable <Variable>.
+If the file exists, the instructions contained in the ‘then’ loop are executed up to the *\@endif*, (or an \@else if one is found before the \@endif ).
+If the files do not exist, the ‘else’ loop is executed (if one exists).
+
+\@ifnotfile
+----------
+~~~~~
+\@ifnotfile ( <Variable> or “String”) then
+\@endif ;
+\@ifnotfile ( <Variable> or “String”) then
+\@else
+\@endif ;
+~~~~~
+Checks for the existence of a file, the name of which is given in the string ‘String”, or else contained in the variable <Variable>.
+If the file does not exist, the instructions contained in the ‘then’ loop are executed up to the \@endif, (or an \@else if one is found before the \@endif).
+If the file does exist, the ‘else’ loop is executed (if one exists).
+
+\@ifdefined 
+----------
+~~~~~
+\@ifnotdefined ( <Variable> or <Template>) then
+\@endif ;
+\@ifnotdefined ( <Variable> or <Template>) then
+\@else
+\@endif ;
+~~~~~
+Checks for the existence of a variable or template, the name of which is given by <Template>, or else contained in the variable <Variable>.
+If a variable or a template by this name exists the instructions contained in the ‘then’ loop are executed up to the \@endif, (or an \@else if one is found before the \@endif).
+If neither a variable nor a template exists, the ‘else’ loop is executed (if one exists).
+
+
+\@ifnotdefined
+-------------
+~~~~~
+\@ifnotdefined ( <Variable> or <Template>) then
+\@endif ;
+\@ifnotdefined ( <Variable> or <Template>) then
+\@else
+\@endif ;
+~~~~~
+Checks for the existence of a variable or template, the name of which is given by <Template>, or else contained in the variable <Variable>.
+If neither a variable nor a template by this name exists the instructions contained in the ‘then’ loop are executed up to the \@endif, (or an \@else if one is found before the \@endif).
+If a variable or a template does exist, the ‘else’ loop is executed (if one exists).
+
+\@if 
+-----
+~~~~~
+\@if (<Condition>) then
+\@endif ;
+\@if (<Condition>) then
+\@else
+\@endif ;
+~~~~~
+Tests a condition.
+If the condition is true the instructions in the ‘then’ loop are executed up to the \@endif, (or an \@else if one is found before the \@endif).
+If the condition is false, the ‘else’ loop is executed (if one exists).
+
+\@template
+---------
+~~~~~
+\@template <Template> (<Variable>, ... , <Variable>) is
+       $ text...
+       .
+       .
+       $ text...
+\@end;
+~~~~~
+Creates a template, which is a definition that contains variables. The variables on which a template relies are given in parentheses, following the name of the template. These variables are used to evaluate the template, and are referred to as ‘variables of evaluation’. When a template is evaluated (see \@apply) the variables in its definition are replaced by the current values of the ‘variables of evaluation’.
+A template is re-evaluated each time it is used.
+
+\@addtotemplate
+--------------
+~~~~~
+\@addtotemplate <Template> is
+       $ text
+       .
+       .
+       $ text
+\@end;
+~~~~~
+
+Adds the specified lines to an existing template.
+
+\@cleartemplate
+--------------
+~~~~~
+\@cleartemplate <Template> ;
+~~~~~
+Removes all the lines of a template. 
+
+\@verboseon
+----------
+~~~~~
+\@verboseon ; 
+~~~~~
+Turns on the verbose mode, such that lines of text are displayed on standard out when you run EDL files. 
+
+\@verboseoff
+-----------
+~~~~~
+\@verboseoff ; 
+~~~~~
+Turns off the verbose mode, such that lines of text are not displayed on standard out when you run EDL files. 
+
+@subsubsection occt_wok_7_1_4  EDL Conditions
+Conditions are used with *\@if* commands. Complex and simple conditions are available. The syntax is similar to C++. 
+
+#### Simple Conditions
+Simple conditions test for equality, the existence of a particular file and so on. The general format is: 
+~~~~~
+\@if(<Condition>) then 
+... 
+~~~~~
+The syntax of simple conditions is given below. 
+~~~~~
+<Variable> == “String” -- (equals)
+<Variable> != “String” -- (does not equal)
+defined(<Variable>) -- (see \@ifdefined)
+defined(<Template>) -- (see \@ifdefined)
+notdefined(<Variable>) -- (see \@ifnotdefined)
+notdefined(<Template>) -- (see \@ifnotdefined)
+file(<Variable>) -- (see \@iffile)
+file(“String”) -- (see \@iffile)
+notfile(<Variable>) -- (see \@ifnotfile)
+notfile(“String”) -- (see \@ifnotfile)
+~~~~~
+
+#### Complex conditions
+
+Complex conditions take into account the results of other conditions. Complex conditions use the operators || (logical OR) or the operator  (logical AND). There are no restrictions on the formulation of these conditions: 
+* (Simple condition) operator (Simple condition) 
+* (Complex condition) operator (Simple condition) 
+* (Simple condition) operator (Complex condition) 
+* (Complex condition) operator (Complex condition) 
+
+For example,
+~~~~~
+\@if ((%a == “0” && %b == “1” && %c == “1”) || %d == “1” && ((%a == “1”) && %b == “1”)) then
+       \@cout “CONDITION TRUE”;
+\@else
+       \@cout “CONDITION FALSE”;
+\@endif;
+~~~~~
+
+@subsection occt_wok_7_2  WOK Parameters
+WOK parameters are defined using EDL. There are two types of EDL parameters: Variables and Templates. 
+
+Variables have a ‘fixed’ value. By contrast a template relies on the values of other variables, and must re-evaluate itself each time it is used. 
+
+@subsubsection occt_wok_7_2_1  Classes of WOK Parameters
+WOK parameters are grouped according to their class. The following classes exist: 
+| CODEGEN  | Code generator options, for example options for lex and yacc. |
+| CMPLRS   | Compiler options. |
+| LDAR     | Archive creation options. |
+| ARX      | Archive extraction options. |
+| LDEXE    | Executable linker options. |
+| LDSHR    |  Shared linker options. |
+
+@subsubsection occt_wok_7_2_2  Defining WOK Parameters
+The WOK distribution includes a base configuration for each class of parameters. This base configuration is provided in the form of EDL files, one file per a class of parameters. Each file is named according to the parameter class: 
+~~~~~
+<ParamClassName>.edl
+~~~~~
+This configuration file sets the values of all the parameters in the class. 
+
+For example, consider a parameter class FOO. There are two variable parameters in this class: FOO_Shared and FOO_Name. These two parameters are assigned a value in the FOO.edl file. The file is given as an example below: 
+~~~~~
+-- standard protection against multiple execution 
+\@ifnotdefined ( %FOO_EDL) then 
+\@set %FOO_EDL = **; 
+
+-- set %FOO_Shared according to the platform 
+\@if ( %LocalArch != *hp* ) then 
+\@set %FOO_Shared = *libCPPExt.so*; 
+\@endif; 
+\@if ( %LocalArch == *hp* ) then 
+\@set %FOO_Shared = *libCPPExt.sl*; 
+\@endif; 
+
+-- set the FOO_Name parameter to FOO 
+\@set %FOO_Name = *FOO*; 
+\@endif; 
+~~~~~
+
+Note that all the parameters in a class take the name of the class as a prefix to their own name. Parameters of type variable are also prefixed by % (percent symbol): 
+~~~~~
+%ClassName_VariableParamName 
+ClassName_TemplateParamName 
+~~~~~
+A simplified template definition is given as an example below. This definition is based on the FOO parameters set in the previous example above. 
+
+Let us define the variable parameter(s) to be used in the template and then the template itself:
+~~~~~
+\@set %FOO_Shared = *libCPPExt.so*; 
+\@set %FOO_Name = *FOO*; 
+
+\@template FOO_Load ( %FOO_Shared, %FOO_Name) is 
+$ %FOO_Load_%FOO_Shared %FOO_Name 
+\@end; 
+~~~~~
+
+@subsubsection occt_wok_7_2_3  Redefining Parameters
+Occasionally you may want to redefine WOK parameters. For example, you can change the compiler options to force ANSI mode compilation, or redefine how external libraries are referenced. 
+Before redefining anything, decide on the scope of the redefinition. Is the redefinition to apply to the whole factory, a single workshop, a workbench, or just a development unit? In some cases you may want to redefine parameters within a delivery unit, so that a parcel is delivered with particular options. 
+
+The order in which redefinitions are applied (order of precedence) may mean your options are overwritten by subsequent redefinitions.
+
+#### Redefinition Files
+
+Each entity can have an associated redefinition file for each class of parameters. A redefinition file is an EDL file. It always takes the name of the entity to which it belongs, followed by the name of the class of parameters that it applies to: 
+~~~~~
+<EntityName>_<ParamClassName>.edl
+~~~~~
+For example, the file MyFactory_CMPLRS.edl redefines one of more of the parameters in the CMPLRS class. The scope of this redefinition is MyFactory. To be taken into account by WOK, this redefinition file must be created in the administration directory of the entity to which it belongs. To find out the pathname of this directory, use the command: 
+~~~~~
+wokinfo -p admfile:<EntityName>_<ParamClassName>.edl <EntityPath>
+~~~~~
+To test whether the file exists actually, use the command: 
+~~~~~
+wokinfo -p adminfile:WOK_LDAR.edl WOK=> /adv22/wok/adm
+~~~~~
+There is one exception to this rule for file placement. For a development unit, the redefinition file is treated as a *source *file, and consequently it must be located in the src directory of the unit. To find out the path of this directory, use the command: 
+~~~~~
+wokinfo -p source:<UnitName>_<ParamClassName>.edl <UnitPath>
+~~~~~
+
+One of the most common reasons to redefine WOK parameters is to modify compiler options. To do this, for example to add a compile option to the package *MyPack*: 
+* In the source directory of MyPk, create file *MyPk_CMPLRS.edl* 
+* In this file add the definition: 
+~~~~~
+\@string %CMPLRS_CXX_Options +=  * -DMyDefine=string *; 
+~~~~~
+
+Order of Precedence for Parameter Redefinitions 
+-----------------------------------------------
+WOK takes parameter (re)definitions into account in the following order. 
+* WOK 
+* Factory 
+* Workshop 
+* Parcels (within the Workshop configuration, in the order in which they are declared in the parcel configuration). 
+* Workbench (in order of inheritance) 
+* Development unit 
+WOK provides commands to find out what parameter definitions (and redefinitions) are used, and in what order. You can see what compiler parameters are used by WOK in *CMPLRS.edl* file. To find this file, use the command: 
+~~~~~
+ wokparam -S CMPLRS.edl 
+~~~~~
+Then run the command. 
+~~~~~
+wokparam -F CMPLRS EntityPath 
+~~~~~
+This command displays a list of all the definition files, for parameters of type compiler, that are taken into account for EntityPath. These file are listed in the order in which they are taken into account. The last definition is the one that is used. 
+
+@subsection occt_wok_7_3  Using EDL to Define WOK Parameters
+@subsubsection occt_wok_7_3_1  Modification of Link Options - Example
+
+#### How to add a define to the compilation
+
+To add a define for all C++ files compiled in the package *MyPackage*, *MyPackage_CMPLRS.edl* is declared in the development unit *MyPackage* This file contains: 
+~~~~~
+\@string %CMPLRS_CXX_Options = 
+%CMPLRS_CXX_Options  * -DMYDEFINE*; 
+~~~~~
+
+#### How to use a code generator
+
+In this example, a C code generator is used, which takes the input <i><file>.mygen</i> and generates a <i><file>.c</i>. The step *obj.cgen* automatically recognizes all files with the extension mygen and uses the generator on these files. The resulting .c files are compiled by the step *obj.comp*. 
+The file *MyUnit_CODEGEN.edl* is written in a nocdlpack development unit *MyUnit*. This file contains the following code: 
+
+~~~~~
+-- list of tools recognized by the step obj.cgen 
+-- the tool MYGEN is added 
+\@ string %CODEGEN_Tools = %CODEGEN_Tools  * CODEGEN_MYGEN*; 
+
+-- the tool MYGEN is called via the template CODEGEN_MYGEN_CmdLine 
+
+\@set %CODEGEN_MYGEN_Template = *CODEGEN_MYGEN_CmdLine*; 
+
+-- the extension of files processed by MYGEN is mygen 
+
+\@set %CODEGEN_MYGEN_Extensions = *foo.mygen*; 
+
+-- the tool MYGEN is the executable /usr/local/bin/mygen 
+
+\@set %CODEGEN_MYGEN_Tool =  * /usr/local/bin/mygen*; 
+
+-- the tool MYGEN produces a .c file 
+
+\@template CODEGEN_MYGEN_Production ( %BaseName ) is 
+$%BaseName.c 
+\@end; 
+
+-- the command executed to construct the .c file is: 
+
+\@template CODEGEN_MYGEN_CmdLine ( %CODEGEN_MYGEN_Tool, 
+%Source, %BaseName, %OutputDir ) is 
+$cd %OutputDir 
+$%CODEGEN_MYGEN_Tool -f %Source -o %BaseName.c 
+\@end; 
+~~~~~
+
+@section occt_wok_8 Appendix C. Tcl
+@subsection occt_wok_8_1  Tcl Overview
+Tcl stands for ‘‘tool command language* and is pronounced ‘‘tickle*. It is actually two things: a language and a library. 
+
+As a simple textual language, tcl is intended primarily for issuing commands to interactive programs such as text editors, debuggers, illustrators, and shells. It has a simple syntax and is also programmable, so tcl users can write command procedures to provide more powerful commands than those in the built-in set. 
+
+As a library package, tcl can be embedded in application programs. The tcl library consists of a parser for the cl language, routines to implement the tcl builtin commands, and procedures that allow each application to extend tcl with additional commands specific to that application. The application program generates tcl commands and passes them to the tcl parser for execution. Commands may be generated by reading characters from an input source, or by associating command strings with elements of the application's user interface, such as menu entries, buttons, or keystrokes.
+
+For Linux platform it is possible to download Tcltk 8.5 or 8.6 from http://www.tcl.tk/software/tcltk/8.6.html
+For Windows platforn it is possible to download ActiveTcl 8.5 or 8.6 from http://www.activestate.com/activetcl/downloads
+
+A help application, tclhelp, is also provided with tcl and can be activated by command *tclhelp*.  
+
+@subsection occt_wok_8_2  Tcl and WOK
+The tcl interpreter offers WOK the following advantages: 
+* an environment in which both WOK and UNIX commands are available, 
+* dynamic loading of WOK as it is needed, 
+* a high performance portable environment, in which the user can write customized procedures. 
+
+The following tcl commands are most commonly used with WOK: *expr, foreach, glob, if, package, proc, puts, set, source* and *unlink*. 
+
+Refer to the tcl documentation, or the tcl help application, for details of these and other tcl commands. 
+
+@subsection occt_wok_8_3  Configuring Your Account for Tcl and WOK
+To have access to WOK you must modify the configuration files of your account as described below. 
+@subsubsection occt_wok_8_3_1  The cshrc File
+To allow the C shell session to configure tcl add the following line to your .chsrc file: 
+~~~~~
+source/<sun|ao1|sgi|hp>_SYSTEM/util_LOG/cshrc_TCL
+~~~~~
+To configure your account to allow access to WOK add the following line to your .cshrc file: 
+~~~~~
+if(!$?WOKHOME) then
+setenv WOKHOME /YOURCONTAINER/wok-<version of wok>
+source /<sun|ao1|sgi|hp>_SYSTEM/util_LOG/cshrc_Wok
+~~~~~
+@subsubsection occt_wok_8_3_2  The tclshrc File
+To enable configuration of the tcl interpreter, add the following line to your .tclshrc if it exists (if not create one): 
+~~~~~
+source $env(WOKHOME)/site/tclshrc_Wok 
+~~~~~
+
+@subsubsection occt_wok_8_3_3  The WOK_SESSIONID Variable
+The *WOK_SESSIONID* environment variable ensures that you start a new WOK session in the same state and with the same parameter values as your previous WOK session. This continuity is provided by using the same WOK_SESSIONID. Note that your *WOK_SESSIONID* does not change, unless you change it manually. 
+
+Make sure that *WOK_SESSIONID* points to (a subdirectory of) your home directory. 
+
+@subsubsection occt_wok_8_3_4  Writing Tcl Steps for a WOK Build
+There are three advanced WOK commands available for writing umake steps in tcl: 
+  *  *msgprint* 
+  *  *stepoutputadd* 
+  *  *stepaddexecdepitem* 
+*msgprint [-i|-w|-e|-v|-V Class]* prints a message. The output is directed to a WOK internal process that is in charge of printing messages. 
+
+The following options are available:  
+| -i  | Prints an information message. |
+| -w  | Prints a warning message. |
+| -e  | Prints an error message. |
+| -v  | Prints a verbose message. |
+| -V<Class> | Prints a verbose message for class <Class>. |
+| -c  | Prints context of message, i.e. the procedure that called it. |
+
+For example, 
+~~~~~
+msgprint -e -c *CCLKernel_GetObjects::Execute* *Cannot locate object file :  * $file; 
+~~~~~
+Writes an error message, in format: 
+~~~~~
+ERROR: CCLKernel_GetObjects::Execute - Cannot locate object file : MyFile 
+~~~~~
+*stepoutputadd <options> <OutputFileID> [<filepath>]* adds an output file to the outputs of the step. This file is treated by subsequent steps in the same way as all the other output files of the step. The following options are available:  
+
+| -p<path> |  Specifies the path where the file is located. |
+| -L | Output can be located (default). |
+| -N | Not a WOK file. Cannot be located. |
+| -F | Physical file (i.e. resides on a disk somewhere). |
+| -M | File is a member of the unit being built (default). |
+| -X | File is not a member of the unit being built. Not a WOK file. Cannot be located. |
+| -P | File is produced by this umake step (i.e. WOK can delete it because it will be regenerated). |
+| -R | File is not produced by this umake step (i.e. WOK must not delete it because it can not be regenerated). 
+| -S<StepID> | Reserved for advanced use. Specifies stepID. |
+| -V | Reserved for advanced use. Virtual ‘file’ (i.e. an MSEntity). This option is used for passing keywords between steps for example. | 
+
+For example, 
+~~~~~ 
+stepoutputadd -X -R -N -F /usr/myfiles/res.o -p /usr/myfiles/res.o 
+~~~~~
+Adds the file */usr/myfiles/res.o* to the outputs of this step. Specifies that this file is not a WOK file, cannot be located automatically by WOK, and is not generated by this step. Here the full file path is used as the unique file identifier. This appears to be duplicated when it is also given as the physical location of the file. 
+
+*stepaddexecdepitem <options> <InputFileID> <OutputFileID>* adds a dependency between one file and another. Typically when introducing external object libraries the files are set to be dependent on the CDL file. We do this because the CDL file changes rarely, so the external files are not needlessly reprocessed, but they are always included in the final executable. The following options are available:  
+
+| -d  | Adds a direct dependency (default). |
+| -i  | Adds an indirect dependency. |
+
+For example, 
+~~~~~
+stepaddexecdepitem -d MyInFile MyOutFile 
+~~~~~
+States that the file *MyOutFile* depends directly on the file *MyInFile*. 
+
+@subsubsection occt_wok_8_3_5  Components of a Tcl UMake Step
+
+Each tcl umake step has the following components: 
+* *HandleInputFile* - a filter: for each input file this component decides whether or not to accept the file. 
+* *OutputDirTypeName* returns one of three strings, according to the dependency of the file: 
+       * *tmpfile* = the file is independent (i.e. dependent only on its source);
+       * *dbtmpdir* = the file is dependent on the database profile;
+       * *sttmpdir* = the file is dependent on the station profile. 
+* *AdmFileType* returns one of three strings, according to the dependency of the file: 
+       * *admfile* = the file is independent (i.e. dependent only on its source); 
+       * *Dbadmfile* = the file is dependent on the database profile; 
+       * *stadmfile* = the file is dependent on the station profile. 
+
+*Execute* processes each input file that is out of date (i.e. has changed since it was last processed, or depends on a file that has changed since it was last processed). Typically this procedure takes the form of a *foreach* loop. Argument: a development unit to process and a list of one or more arguments. 
+
+@subsubsection occt_wok_8_3_6  Sample Tcl Steps
+
+#### Sample 1
+
+~~~~~
+# CCLKernel_GetObjects.tcl 
+proc CCLKernel_GetObjects::AdmFileType {} { 
+       return stadmfile; 
+} 
+proc CCLKernel_GetObjects::OutputDirTypeName {} { 
+       return sttmpdir; 
+} 
+proc CCLKernel_GetObjects::HandleInputFile { ID } { 
+       scan $ID *%\[^:\]:%\[^:\]:%\[^:\]* unit type name 
+       return 1; 
+       switch [file extension $name] { 
+.cdl { 
+               return 1; 
+               } 
+       default { 
+               return 0; 
+               } 
+       } 
+} 
+proc CCLKernel_GetObjects::Execute { unit args } { 
+       msgprint -i -c *CCLKernel_GetObjects::Execute* 
+       *Processing unit : $unit*; 
+       msgprint -i -c *CCLKernel_GetObjects::Execute* 
+       set failed 0; 
+       set inid [lindex $args 0] 
+       foreach file { Frontal_Ccal_Init_Request.o Frontal_Ccal_Send_Request.o \ 
+Frontal_Ccal_sd.o Frontal_Get_Response.o Frontal_Ccal_Connect.o } { 
+set resid *Frontal:object:$file* 
+set path [woklocate -p $resid] 
+if { $path == ** } { 
+       msgprint -e -c *CCLKernel_GetObjects::Execute* 
+*Cannot locate object file :  * $file; 
+       set failed 1; 
+} else { 
+       msgprint -i -c *CCLKernel_GetObjects::Execute* *Add 
+object $file at  * $path 
+       stepoutputadd -X -R -L -F $resid 
+       stepaddexecdepitem -d $inid $resid 
+       } 
+} 
+if { [wokparam -e %Station] == *sun* } { 
+       set file *risc_return.o* 
+       set resid *CCLKernel:source:$file* 
+       set path [woklocate -p $resid] 
+## set path */adv_23/wb/kl/Kernel7/prod/EngineStarter/ 
+src/risc_return.o* 
+       msgprint -i -c *CCLKernel_GetObjects::Execute* *Add 
+object $file at  * $path 
+       stepoutputadd -X -R -N -F $path -p $path 
+       stepaddexecdepitem -d $inid $path 
+} 
+set home [wokparam -e %Ilog_Home] 
+if { $home == ** } { 
+       msprint -c *CCLKernel_GetObjects::Execute* -e *Cannot 
+evaluate parameter : %Ilog_Home 
+       return 1; 
+} 
+foreach file { llstdio.o llfloat.o llfloat31.o cfix.o 
+lelisp.o getgloba.o cload.o } { 
+       set path *$home/o/$file* 
+       msgprint -i -c *CCLKernel_GetObjects::Execute* *Add 
+object $file at  * $path 
+       stepoutputadd -X -R -N -F $path -p $path 
+       stepaddexecdepitem -d $inid $path 
+} 
+set file *lelisp31bin.o* 
+set path *$home/lelisp31bin.o* 
+msgprint -i -c *CCLKernel_GetObjects::Execute* *Add 
+object $file at  * $path 
+stepoutputadd -X -R -N -F $path -p $path 
+stepaddexecdepitem -d $inid $path 
+if { $failed } {return 1;} 
+return 0; 
+} 
+~~~~~
+Sample 2
+--------
+# File Name: CCLKernel_core.tcl 
+proc CCLKernel_core::AdmFileType {} { 
+       return stadmfile; 
+} 
+proc CCLKernel_core::OutputDirTypeName {} { 
+       return sttmpdir; 
+} 
+proc CCLKernel_core::HandleInputFile { ID } { 
+       scan $ID *%\[^:\]:%\[^:\]:%\[^:\]* unit type name 
+       switch $type { 
+executable { 
+       return 1; 
+} 
+       } 
+       switch $name { 
+CCL_lelisp.ll { 
+       return 1; 
+       } 
+} 
+       return 0; 
+       } 
+proc CCLKernel_core::Execute { unit args } { 
+       global WOK_GLOBALS env 
+msgprint -i -c *CCLKernel_core::Execute* *Processing unit : $unit*; 
+       msgprint -i -c *CCLKernel_core::Execute* 
+       set workbench [wokinfo -N $unit] 
+       set unitname [wokinfo -n $unit] 
+       set failed 0; 
+       set lispbin ** 
+       set lispfile ** 
+       set lispbinid ** 
+       set lispfileid ** 
+       foreach ID $args { 
+scan $ID *%\[^:\]:%\[^:\]:%\[^:\]* Unit type name 
+switch $type { 
+       executable { 
+               set lispbinid $ID 
+               set lispbin [stepinputinfo -p $ID] 
+       } 
+} 
+switch $name { 
+CCL_lelisp.ll { 
+set lispfileid $ID 
+set lispfile [stepinputinfo -p $ID] 
+} 
+} 
+} 
+if { $lispfile == **} { 
+set lispfileid *CCLKernel:source:CCL_lelisp.ll*; 
+set lispfile [woklocate -p $lispfileid $workbench] 
+} 
+if { $lispbin == **} { 
+msgprint -e -c *CCLKernel_core::Execute* *Cannot find lelispbin in input* 
+return 1; 
+} 
+msgprint -i -c *CCLKernel_core::Execute* *Using lelisp.bin at  * $lispbin 
+msgprint -i -c *CCLKernel_core::Execute* 
+set config *[wokparam -e %Ilog_Home]/config* 
+set tmpdir [wokinfo -p sttmpdir:. $unit] 
+set output [wokinfo -p executable:. $unit] 
+set lelisppointbin [wokinfo -p executable:lelisp.bin $unit] 
+unlink -nocomplain $lelisppointbin 
+link -sym $lispbin $lelisppointbin 
+msgprint -i -c *CCLKernel_core::Execute* *Setting Environment* 
+set WOK_GLOBALS(setenv_proc,tcl) 1 
+wokenv -s 
+set WOK_GLOBALS(setenv_proc,tcl) 0 
+set olddir [pwd] 
+cd [wokinfo -p source:. $unit] 
+set FrontSIZE *-stack 12 -code 1500 -heap 2048 -number 0 -vector 32 -string 50 -symbol 30 -float 0 -cons  * 
+msgprint -i -c *CCLKernel_core::Execute* *Exec : $config $tmpdir $lispbin $lispfile $output $FrontSIZE 8* 
+puts *exec /bin/env \\ 
+COREDIR=$output \\ 
+WBPACKAGE=[wokinfo -n $unit] ILOG_LICENSE_FILE=[wokparam -e %Ilog_LicenseFile] \\ 
+CSF_EngineStarterList=/usr/local/etc/ 
+EngineStarter.Hosts \\ 
+ILOG_LICENSE_FILE=[wokparam -e %Ilog_LicenseFile] \\ 
+\*FrontSIZE=$FrontSIZE\* \\ 
+$config $tmpdir $lispbin $lispfile $output $FrontSIZE 8* 
+msgprint -i -c *CCLKernel_core::Execute* [eval *exec /bin/env \\ 
+       COREDIR=$output \\ 
+       WBPACKAGE=[wokinfo -n $unit] \\ 
+       ILOG_LICENSE_FILE=[wokparam -e %Ilog_LicenseFile] \\ 
+       CSF_EngineStarterList=/usr/local/etc/ EngineStarter.Hosts \\ 
+       \*FrontSIZE=$FrontSIZE\* \\ 
+$config $tmpdir $lispbin $lispfile $output $FrontSIZE 8*] 
+       stepoutputadd -P $unitname:corelisp:$unitname.core 
+       stepaddexecdepitem -d $lispbinid 
+$unitname:corelisp:$unitname.core 
+       stepaddexecdepitem -d $lispfileid 
+$unitname:corelisp:$unitname.core 
+       cd $olddir 
+       return 0; 
+}
+~~~~~
\ No newline at end of file
index 2d493f8..75c9732 100644 (file)
@@ -340,8 +340,8 @@ proc OverviewDoc_MakeRefmanTex {fileName latexDir docLabel verboseMode} {
     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\[RE\]{\\fancyplain{}{\\bfseries\\scriptsize (c) Open CASCADE Technology 2001\-2013}}"
+    puts $texfile "\\fancyfoot\[LO\]{\\fancyplain{}{\\bfseries\\scriptsize (c) Open CASCADE Technology 2001\-2013}}"
     puts $texfile "\\fancyfoot\[CO\]{\\fancyplain{}{}}"
     puts $texfile "\\fancyfoot\[RO\]{\\fancyplain{}{}}"
     puts $texfile "\\renewcommand{\\footrulewidth}{0.4pt}"
@@ -378,6 +378,7 @@ proc OverviewDoc_MakeRefmanTex {fileName latexDir docLabel verboseMode} {
     puts $texfile "}"
     puts $texfile "\n"
     puts $texfile "%===== C O N T E N T S =====\n"
+#    puts $texfile "\\DeclareUnicodeCharacter{00A0}{ }"
     puts $texfile "\\begin{document}"
     puts $texfile ""
     puts $texfile "% Titlepage & ToC"
@@ -386,7 +387,7 @@ proc OverviewDoc_MakeRefmanTex {fileName latexDir docLabel verboseMode} {
     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 "\\includegraphics\[width=0.75\\textwidth, height=0.2\\textheight\]{overview_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}\\\\"
@@ -423,8 +424,15 @@ proc OverviewDoc_ProcessTex {{texFiles {}} {latexDir} verboseMode} {
         if {$verboseMode == "YES"} {
             puts "INFO: Preprocessing file $TEX"
         }
+
+         if {![file exists $TEX]} {
+          puts "file $TEX doesn't exist"
+          return
+        }
+
         set IN_F  [open "$TEX" r]
         set TMPFILENAME "$latexDir/temp.tex"
+
         set OUT_F [open $TMPFILENAME w]
         
         while {1} {
@@ -521,13 +529,13 @@ proc OverviewDoc_Main { {docfiles {}} generatorMode docLabel verboseMode} {
         }
 
         # Prepare a list of TeX files, generated by Doxygen
+        puts "go to $LATEXDIR"
         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} {
@@ -535,10 +543,10 @@ proc OverviewDoc_Main { {docfiles {}} generatorMode docLabel verboseMode} {
             set IDX [lsearch $TEXFILES "$LATEXDIR"]
         }
 
-        # Preprocess generated TeX files
+        puts "Preprocess generated TeX files"
         OverviewDoc_ProcessTex $TEXFILES $LATEXDIR $verboseMode
 
-        # Generate PDF files from 
+        puts "Generate PDF files from"
         foreach TEX $TEXFILES {
             # Rewrite existing REFMAN.tex file...
             set TEX [string range $TEX 0 [ expr "[string length $TEX] - 5"]]
@@ -548,6 +556,7 @@ proc OverviewDoc_Main { {docfiles {}} generatorMode docLabel verboseMode} {
                 puts "INFO: Generating PDF file from $TEX"
             }
             # ...and use it to generate PDF from TeX...
+            puts "execute $LATEXDIR/make$PREFIX"
             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} {
@@ -563,6 +572,12 @@ proc OverviewDoc_Main { {docfiles {}} generatorMode docLabel verboseMode} {
             if { [file exists $PDFDIR/$TEX.pdf] == 1 } {
                 file delete -force $PDFDIR/$TEX.pdf
             }
+            
+            if {![file exists "$LATEXDIR/refman.pdf"]} {
+              puts "file $LATEXDIR/refman.pdf doesn't exist"
+              return
+            }
+            
             file rename $LATEXDIR/refman.pdf "$PDFDIR/$TEX.pdf"
         }
         if {$verboseMode == "YES"} {
index cd01944..96394c5 100644 (file)
Binary files a/dox/overview/images/overview_installation.png and b/dox/overview/images/overview_installation.png differ
index ea2a9cf..fda8026 100644 (file)
@@ -16,7 +16,8 @@ From a programming standpoint, Open CASCADE Technology is designed to enhance yo
 
 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 "")
+@image html /overview/tutorial/images/tutorial_image001.png
+@image latex /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.
 
@@ -32,7 +33,8 @@ We first define the bottle specifications as follows:
 
 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 "")
+@image html /overview/tutorial/images/tutorial_image002.png
+@image latex /overview/tutorial/images/tutorial_image002.png
 
 This modeling requires four steps:
 
@@ -48,7 +50,8 @@ This modeling requires four steps:
 
 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 "")
+@image html /overview/tutorial/images/tutorial_image003.png
+@image latex /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:
 
@@ -81,7 +84,8 @@ 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 "")
+@image html /overview/tutorial/images/tutorial_image004.png
+@image latex /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*).
@@ -137,7 +141,8 @@ 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 "")
+@image html /overview/tutorial/images/tutorial_image005.png
+@image latex /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:
@@ -175,7 +180,8 @@ Once the first part of your wire is created you need to compute the complete pro
   * compute a new wire by reflecting the existing one.
   * add the reflected wire to the initial one.
 
-![](/overview/tutorial/images/tutorial_image006.png "")
+@image html /overview/tutorial/images/tutorial_image006.png
+@image latex /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.
@@ -258,7 +264,8 @@ To compute the main body of the bottle, you need to create a solid shape. The si
 | Face   | Solid              |
 | Shell  | Compound of Solids |
 
-![](/overview/tutorial/images/tutorial_image007.png "")
+@image html /overview/tutorial/images/tutorial_image007.png
+@image latex /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.
@@ -295,7 +302,8 @@ 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 "")
+@image html /overview/tutorial/images/tutorial_image008.png
+@image latex /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:
 
@@ -351,7 +359,8 @@ Once this is done, you perform the last step of the procedure by asking for the
 
 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 "")
+@image html /overview/tutorial/images/tutorial_image009.png
+@image latex /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:
@@ -393,7 +402,8 @@ In Open CASCADE Technology, a hollowed solid is called a *Thick* *Solid* and is
   * 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 "")
+@image html /overview/tutorial/images/tutorial_image010.png
+@image latex /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:
     
@@ -496,7 +506,8 @@ As a first step, you compute these cylindrical surfaces. You are already familia
 
 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 "")
+@image html /overview/tutorial/images/tutorial_image011.png
+@image latex /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.
 
@@ -521,7 +532,8 @@ P(U, V) = O + R * (cos(U) * xDir + sin(U) * yDir) + V * zDir, where :
   * R is the radius of the cylindrical surface.
   * U range is [0, 2PI] and V is infinite.
 
-![](/overview/tutorial/images/tutorial_image012.png "")
+@image html /overview/tutorial/images/tutorial_image012.png
+@image latex /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:
 
@@ -530,7 +542,8 @@ The advantage of having such parameterized geometries is that you can compute, f
 
 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 "")
+@image html /overview/tutorial/images/tutorial_image013.png
+@image latex /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:
 
@@ -545,14 +558,16 @@ The helicoidal curve type is exactly what you need. On the neck's surface, the e
   * 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 "")
+@image html /overview/tutorial/images/tutorial_image014.png
+@image latex /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 "")
+@image html /overview/tutorial/images/tutorial_image015.png
+@image latex /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:
 
@@ -568,7 +583,8 @@ To use 2D primitive geometry types of Open CASCADE Technology for defining a poi
 
 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 "")
+@image html /overview/tutorial/images/tutorial_image016.png
+@image latex /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:
 
@@ -624,7 +640,8 @@ 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 "")
+@image html /overview/tutorial/images/tutorial_image017.png
+@image latex /overview/tutorial/images/tutorial_image017.png
 
 Previously, you have built:
 
@@ -664,7 +681,8 @@ You have computed the wires of the threading. The threading will be a solid shap
 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 "")
+@image html /overview/tutorial/images/tutorial_image018.png
+@image latex /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.
@@ -694,7 +712,8 @@ You are almost done building the bottle. Use the *TopoDS_Compound* and *BRep_Bui
 
 Congratulations! Your bottle is complete. Here is the result snapshot of the Tutorial application:
 
-![](/overview/tutorial/images/tutorial_image019.png "")
+@image html /overview/tutorial/images/tutorial_image019.png
+@image latex /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.
index dbe751f..2aff1fb 100644 (file)
@@ -3,14 +3,13 @@ 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
+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 "")
+@image html /technical_overview/images/technical_overview_over.png
+@image latex /technical_overview/images/technical_overview_over.png
 
 The OCCT Library provides the following services:
 
@@ -72,7 +71,7 @@ These services are organized into the following libraries:
 
   * Kernel Classes 
   * Math Utilities 
-  * Basic Persistence  
+  * Basic Persistence
 
 The technical overview provides only a basic description of the libraries. Please, refer for more details to Foundation Classes User's guide
 
@@ -81,8 +80,8 @@ See also: our web site at E-learning and Training.
 @subsection OCCT_TOVW_SECTION_2_1 Kernel Classes
 
 
-Root 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:
@@ -94,8 +93,7 @@ all other Open CASCADE Technology classes are built. They provide:
   * Management of exceptions,
   * Encapsulation of C++ streams.
 
-Quantities
------------
+### Quantities
 
 Quantity classes provide the following services:
 
@@ -105,7 +103,7 @@ Quantity classes provide the following services:
   * 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. 
+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.
 
@@ -117,8 +115,7 @@ values means that :
 
 <i>Quantity</i> package includes all commonly used basic physical quantities. 
 
-Exceptions
-----------
+### Exceptions
 
 Exception classes list all the exceptions, which can be raised by any OCCT function.
 
@@ -137,8 +134,7 @@ native exceptions is that they may not work properly on some compilers. In this
 a specific OCCT code is used instead. 
 
 
-Strings
--------
+### Strings
 
 Strings are classes that handle dynamically sized sequences of characters based on
 ASCII/Unicode UTF-8 (normal 8-bit character type)
@@ -156,8 +152,7 @@ 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
------------
+### Collections
 
 Apart from strings, the <i> TCollection</i> package contains classes of dynamically sized
 aggregates of data. They include a wide range of collections.
@@ -204,8 +199,8 @@ the ANSI C++ compiler.
 @subsection OCCT_TOVW_SECTION_2_2 Math Utilities
 
 
-Vectors and Matrices
---------------------
+### Vectors and Matrices
+
 
 The <i> Vector</i> and <i> Matrix </i> classes provide commonly used mathematical algorithms which
 include:
@@ -240,7 +235,7 @@ 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
+               // a modification of v1 does not affect v2
 ~~~
 
 Vector and Matrix elements can be retrieved using indexes, which must be in the range
@@ -260,32 +255,25 @@ value upon creation as well.
 
 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
+ *<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
+ *<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
+    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
--------------------------
+### 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.
+* 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.
@@ -293,19 +281,19 @@ 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.
+         * 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.
 
@@ -326,15 +314,14 @@ involving complex algorithms where it is particularly important to manipulate th
 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.
+  * 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
 
 Common mathematical algorithms provided in OCCT include:
 
@@ -343,12 +330,12 @@ Common mathematical algorithms provided in OCCT include:
   * 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 "")
+@image html /technical_overview/images/technical_overview_md.png
+@image latex /technical_overview/images/technical_overview_md.png
 
 These services are organized into the following libraries:
 
@@ -369,10 +356,9 @@ See also: our web site at E-learning and Training.
 
 <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.
+* 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, 
@@ -392,7 +378,7 @@ Thus, an ellipse (specific class <i> Geom2d_Ellipse</i>) is also a conical curve
 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
+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
@@ -418,14 +404,14 @@ 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.
+    * 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.
+   * 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.
 
@@ -457,8 +443,7 @@ You can refer to the <i> GC</i> package to find more evolved construction algori
 Geom objects.
 
 
-Adaptors for Curves and Surfaces
------------------
+### 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.
@@ -481,8 +466,8 @@ For example, <i> Adaptor3d_Curve </i> is the abstract class which provides  the
 
 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, 
+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.
 
 
@@ -496,8 +481,7 @@ This library provides standard high-level functions in 2D and 3D geometry such a
   * Calculation of points on a 2D or 3D curve; 
   * Calculation of extrema between two geometries. 
 
-Direct Construction
--------
+### 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
@@ -519,14 +503,14 @@ 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 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.
+  * 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.
 
@@ -536,7 +520,7 @@ If it was unsuccessful, the status gives the reason for the failure.
     gp_Pnt P3 (10.,0.,0.);
     gce_MakeCirc MC (P1,P2,P3);
     if (MC.IsDone()) {
-        const gp_Circ& C = MC.Value();
+               const gp_Circ& C = MC.Value();
     }
 ~~~~
 
@@ -547,8 +531,7 @@ construction or construction error) is described by the enumeration <i> gce_Erro
 Note: classes which construct geometric transformations do not return a status, and
 therefore do not inherit from Root.
 
-Approximations
------------
+### Approximations
 
 Approximation of Curves and Surfaces groups together a variety of functions used in 2D and 3D geometry for:
 
@@ -577,8 +560,7 @@ 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
-----------------------------
+### 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. 
@@ -622,8 +604,7 @@ The <i> GeomConvert</i> package also provides the following:
   * 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
---------
+### 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.
 
@@ -653,13 +634,13 @@ containing embedded curves and surfaces connected or non-connected to an outer b
 Abstract topological data structure describes a basic entity - a shape, 
 which can be divided into the following component topologies:
 
-  * Vertex   * a zero-dimensional shape corresponding to a point in geometry; 
-  * Edge   * a shape corresponding to a curve, and bound by a vertex at each extremity;
-  * Wire   * a sequence of edges connected by their vertices; 
-  * Face   * part of a plane (in 2D geometry) or a surface (in 3D geometry) bounded by a closed wire;
-  * Shell   * a collection of faces connected by some edges of their wire boundaries; 
-  * Solid   * a part of 3D space bound by a shell; 
-  * Compound solid   * a collection of solids. 
+  * Vertex - a zero-dimensional shape corresponding to a point in geometry; 
+  * Edge - a shape corresponding to a curve, and bound by a vertex at each extremity;
+  * Wire - a sequence of edges connected by their vertices; 
+  * Face - part of a plane (in 2D geometry) or a surface (in 3D geometry) bounded by a closed wire;
+  * Shell - a collection of faces connected by some edges of their wire boundaries; 
+  * Solid - a part of 3D space bound by a shell; 
+  * Compound solid - a collection of solids. 
 
 The wire and the solid can be either infinite or closed.
 
@@ -685,8 +666,7 @@ Three additional packages provide tools to access and manipulate this abstract t
 
 @subsection OCCT_TOVW_SECTION_3_5 Properties of Shapes
 
-Local Properties of Shapes
-----------------------
+### Local Properties of Shapes
 
 <i>BRepLProp</i> package provides the Local Properties of Shapes component, 
 which contains algorithms computing various local properties on edges and faces in a BRep model.
@@ -711,8 +691,8 @@ Analyzed edges and faces are described as <i> BRepAdaptor</i> curves and surface
 which provide shapes with an interface for the description of their geometric support. 
 The base point for local properties is defined by its u parameter value on a curve, or its (u, v) parameter values on a surface.
 
-Local Properties of Curves and Surfaces
-------------------------------------
+### Local Properties of Curves and Surfaces
+
 
 The "Local Properties of Curves and Surfaces" component provides algorithms for computing various local 
 properties on a Geom curve (in 2D or 3D space) or a surface. It is composed of:
@@ -730,8 +710,8 @@ It is possible to query the same local properties for points as mentioned above,
   * the points corresponding to a minimum or a maximum of curvature;
   * the inflection points.
 
-Global Properties of Shapes
-------------------
+### Global Properties of Shapes
+
 The Global Properties of Shapes component provides algorithms for computing the global 
 properties of a composite geometric system in 3D space, and frameworks to query the computed results.
 
@@ -752,18 +732,14 @@ Geometric systems are generally defined as shapes. Depending on the way they are
 
 The global properties of several systems may be brought together to give the global properties of the system composed of the sum of all individual systems.
 
-The Global Properties of Shapes component is composed of :
-
-    * seven functions for computing global properties of a shape: one function for lines, two functions for surfaces and four functions for volumes. The choice of functions depends on input parameters and algorithms used for computation (<i> BRepGProp</i> global functions),
-    * a framework for computing global properties for a set of points (<i> GProp_PGProps</i>),
-    * and a general framework to :
-      * bring together the global properties retained by several more elementary frameworks, and
-      * provide a general programming interface to consult computed global properties.
+The Global Properties of Shapes component is composed of:
+* seven functions for computing global properties of a shape: one function for lines, two functions for surfaces and four functions for volumes. The choice of functions depends on input parameters and algorithms used for computation (<i>BRepGProp</i> global functions),
+* a framework for computing global properties for a set of points (<i>GProp_PGProps</i>),
+* and a general framework to bring together the global properties retained by several more elementary frameworks, and provide a general programming interface to consult computed global properties.
     
 @subsection OCCT_TOVW_SECTION_3_6 Examples
 
-How to compute the curve length
-----------------------
+### How to compute the curve length
 
 To compute curve length, use the method <i>AbscissaPoint::Length</i> from <i> GCPnts</i>.
 
@@ -798,8 +774,7 @@ The length of the curve is then computed using this curve object:
     Standard_Real L = myAlgo.Length( C ) ;
 ~~~~~~~~
 
-How to check the surface concavity
---------------------------------
+### How to check the surface concavity
 
 To check the concavity of a surface, proceed as follows:
 
@@ -807,8 +782,8 @@ To check the concavity of a surface, proceed as follows:
   2. If the value of the curvature changes of sign, the surface is concave or convex depending on the point of view.
   3. To compute a Gaussian curvature, use the class <i> SLprops</i> from <i> GeomLProp</i>, which instantiates the generic class <i> SLProps </i>from <i> LProp</i> and use the method <i> GaussianCurvature</i>.
 
-How to approximate a curve with respect to tangencies
---------------------------------------------
+### How to approximate a curve with respect to tangencies
+
 
 To approximate a curve with respect to tangencies, follow these steps:
 
@@ -816,8 +791,8 @@ To approximate a curve with respect to tangencies, follow these steps:
   2. Create an object of type <i> AppDef_MultiLine </i>from the <i> AppDef_MultiPointConstraint</i>.
   3. Use <i> AppDef_BSplineCompute</i>, which instantiates <i>Approx_BSplineComputeLine</i> to perform the approximation.
 
-How to extract the underlying geometry from shapes
---------------------------------------
+### How to extract the underlying geometry from shapes
+
 
 To extract the underlying geometry from a Shape, use the following methods:
 
@@ -847,15 +822,15 @@ With the second method, you get a copy of the surface on which the location has
 Note: you can use also a topological object directly just as if it 
 were a geometric one by using the services of <i> BRepAdaptor </i>classes.
 
-How to get the coordinates of a vertex
------------------------------------
+### How to get the coordinates of a vertex
+
 
 To recover the UV coordinates of vertices, 
 use <i> BRep_Tool::Parameters const TopoDS_Vertex& V,const TopoDS_Face& F), </i> 
 which returns the U and V parameters of the vertex V on the face F as a <i> gp_Pnt2d</i>. 
 
-How to explore a Wire
----------------------
+### How to explore a Wire
+
 
 To explore the edges of a wire in a contiguous order, use <i> BrepTools_WireExplorer</i> class.
 
@@ -868,8 +843,8 @@ To explore the edges of a wire in a contiguous order, use <i> BrepTools_WireExpl
     }
 ~~~~
 
-How to merge bspline curves
---------------------------
+### How to merge bspline curves
+
 
 To merge joined bspline curves use the following methods:
 
@@ -972,7 +947,8 @@ These services are organized into the following libraries:
   * Hidden Line Removal
   * Shape Healing 
 
-![](/technical_overview/images/technical_overview_ma.png "")
+@image html /technical_overview/images/technical_overview_ma.png
+@image latex /technical_overview/images/technical_overview_ma.png
 
 The technical overview provides only a basic description of the libraries. 
 Please, refer for more details to Modeling Algorithms User's guide 
@@ -1015,7 +991,7 @@ The Projections component provides functionality for 2D and 3D geometry objects
   * the projections of a 3D point onto a 3D curve or surface
   * the projection of a 3D curve onto a surface.
   * the planar curve transposition from the 3D to the 2D parametric space of an underlying plane and v. s.
-  * the positioning of a 2D gp object in the 3D geometric space. 
+  * the positioning of a 2D gp object in the 3D geometric space.
 
 @subsubsection OCCT_TOVW_SECTION_4_1_3 Lines and Circles from Constraints
 
@@ -1023,11 +999,11 @@ The Lines and Circles from Constraints component provides numerous
 construction algorithms for 2D circles or lines described with numeric or 
 geometric constraints in relation to other curves. These constraints enable the following to be imposed:
 
-  * the radius of a circle,
-  * the angle that a straight line makes with another straight line,
-  * the tangency of a straight line or circle in relation to a curve,
+  * the radius of a circle,
+  * the angle that a straight line makes with another straight line,
+  * the tangency of a straight line or circle in relation to a curve,
   * the passage of a straight line or circle through a point,
-  * the centering of a circle on a point or curve.
+  * the circle with center in a point or curve.
 
 For example, these algorithms enable to easily construct a circle of a given radius,
 centered on a straight line and tangential to another circle.
@@ -1041,7 +1017,8 @@ to which the tangency constraints are expressed. For example, consider the follo
 case of a circle of a given radius (a small one) which is tangential to two secant
 circles C1 and C2:
 
-![](/technical_overview/images/technical_overview_occ_0005.png "Example of a Tangency Constraint")
+@image html /technical_overview/images/technical_overview_occ_0005.png "Example of a Tangency Constraint"
+@image latex /technical_overview/images/technical_overview_occ_0005.png "Example of a Tangency Constraint"
 
 This diagram clearly shows that there are 8 possible solutions.
 
@@ -1055,10 +1032,10 @@ This technique of qualification of a solution, in relation to the curves to whic
 it is tangential, can be used in all algorithms for constructing a circle or a straight
 line by geometric constraints. Four qualifiers are used, which specify the following:
 
-  * the solution(s) must enclose the argument, or
-  * the solution(s) must be enclosed by the argument, or
-  * the solution(s) and the argument must be external to one another, or
-  * the relative position is not qualified, i.e. all solutions apply.
+  * the solution(s) must enclose the argument, or
+  * the solution(s) must be enclosed by the argument, or
+  * the solution(s) and the argument must be external to one another, or
+  * the relative position is not qualified, i.e. all solutions apply.
 
 These definitions are very easy to interpret on a circle, where it is easy to identify
 the interior and exterior sides. In fact, for any kind of curve the interior is defined
@@ -1066,15 +1043,15 @@ as the left-hand side of the curve in relation to its orientation.
 
 OCCT implements several categories of algorithms:
 
-  * analytic algorithms, where solutions are obtained by the resolution of an equation, such algorithms are used when the geometries which are worked on (tangency arguments,   position of the center, etc.) are points, lines or circles;
-  * geometric algorithms, where the solution is generally obtained by calculating the intersection of parallel or bisecting curves built from geometric arguments;
-  * iterative algorithms, where the solution is obtained by a process of iteration.
+  * analytic algorithms, where solutions are obtained by the resolution of an equation, such algorithms are used when the geometries which are worked on (tangency arguments,   position of the center, etc.) are points, lines or circles;
+  * geometric algorithms, where the solution is generally obtained by calculating the intersection of parallel or bisecting curves built from geometric arguments;
+  * iterative algorithms, where the solution is obtained by a process of iteration.
 
 For each kind of geometric construction of a constrained line or circle, OCCT provides
 two types of access to the user:
 
-  * algorithms from the package <i> Geom2dGcc </i> automatically select the algorithm best suited to the problem to be treated, both in the general case and in all types of specific cases; the arguments used are Geom2d objects; the solutions computed are <i> gp </i> objects;
-  * algorithms from the package <i> GccAna</i> resolve the problem analytically, and can only be used when the geometries to be worked on are lines or circles; the arguments used and solutions computed are <i> gp </i> objects.
+  * algorithms from the package <i> Geom2dGcc </i> automatically select the algorithm best suited to the problem to be treated, both in the general case and in all types of specific cases; the arguments used are Geom2d objects; the solutions computed are <i> gp </i> objects;
+  * algorithms from the package <i> GccAna</i> resolve the problem analytically, and can only be used when the geometries to be worked on are lines or circles; the arguments used and solutions computed are <i> gp </i> objects.
 
 The provided algorithms compute all solutions, which correspond to the stated geometric
 problem, unless the solution is found by an iterative algorithm.
@@ -1082,15 +1059,15 @@ problem, unless the solution is found by an iterative algorithm.
 Iterative algorithms compute only one solution, closest to an initial
 position. They can be used in the following cases:
 
-  * to build a circle, when an argument is more complex than a line or a circle, and where 
+  * to build a circle, when an argument is more complex than a line or a circle, and where 
   the radius is not known or difficult to determine: this is the case for a circle tangential 
   to three geometric elements, or tangential to two geometric elements and centered on a curve;
-  * to build a line, when a tangency argument is more complex than a line or a circle.
+  * to build a line, when a tangency argument is more complex than a line or a circle.
 
 Qualified curves (for tangency arguments) are provided either by:
 
   * the <i> GccEnt</i> package, for direct use by <i> GccAna</i> algorithms, or
-  * the <i> Geom2dGcc </i> package, for general use by <i> Geom2dGcc </i> algorithms.
+  * the <i> Geom2dGcc </i> package, for general use by <i> Geom2dGcc </i> algorithms.
 
 The <i> GccEnt</i> and <i> Geom2dGcc</i> packages also provide simple functions for building qualified curves in a very efficient way.
 
@@ -1114,15 +1091,15 @@ by construction algorithms from the <i> GccAna </i> or <i> Geom2dGcc</i> package
 The Curves and Surfaces from Constraints component groups together high level functions
 used in 2D and 3D geometry for:
 
-  * creation of faired and minimal variation 2D curves
+  * creation of faired and minimal variation 2D curves
   * construction of ruled surfaces
-  * construction of pipe surfaces
-  * filling of surfaces
+  * construction of pipe surfaces
+  * filling of surfaces
   * construction of plate surfaces
-  * extension of a 3D curve or surface beyond its original bounds.
+  * extension of a 3D curve or surface beyond its original bounds.
+
+#### 2D Curves from constraints
 
-2D Curves from constraints
-----------------------
 
 Elastic beam curves have their origin in traditional methods of modeling applied 
 in boat-building, where a long thin piece of wood, a lathe, was forced to pass
@@ -1140,12 +1117,12 @@ on each of the two reference points. These include point and angle of tangency s
 The class <i> MinimalVariation</i> produces curves with minimal variation in curvature. 
 The exact degree of variation is provided by curvature settings.
 
-Ruled Surfaces
-----------------
+#### Ruled Surfaces
+
 A ruled surface is built by ruling a line along the length of two curves.
 
-Pipe Surfaces
---------------
+#### Pipe Surfaces
+
 
 A pipe is built by sweeping a curve (the section) along another curve (the path).
 
@@ -1155,8 +1132,7 @@ The following types of construction are available:
   * pipes with a section evolving between two given curves.
 
 
-Surface filling
---------------
+#### Surface filling
 
 It is often convenient to create a surface from two or more curves which will form
 the boundaries that define the new surface.
@@ -1166,7 +1142,8 @@ the fillet on one edge is different from that of the fillet on another, it becom
 impossible to sew together all the edges of the resulting surfaces. This leaves a
 gap in the overall surface of the object which you are constructing.
 
-![](/technical_overview/images/technical_overview_occ_0006.png "Intersecting filleted edges with differing radiuses")
+@image html /technical_overview/images/technical_overview_occ_0006.png "Intersecting filleted edges with differing radiuses"
+@image latex /technical_overview/images/technical_overview_occ_0006.png "Intersecting filleted edges with differing radiuses"
 
 These algorithms allow you to fill this gap from two, three or four curves. This
 can be done with or without constraints, and the resulting surface will be either
@@ -1176,8 +1153,8 @@ a Bezier or a BSpline surface in one of a range of filling styles.
 This package was designed with a view to handling gaps produced during fillet construction.
 Satisfactory results cannot be guaranteed for other uses.
 
-Plate surfaces
-------------------
+#### Plate surfaces
+
 
 In CAD, it is often necessary to generate a surface which has no exact mathematical
 definition, but which is defined by respective constraints. These can be of a mathematical,
@@ -1197,18 +1174,19 @@ in the input, an initial surface is calculated. This corresponds to the plate pr
 to deformation. Then, the algorithm is called to calculate the final surface. It
 looks for a solution satisfying constraints and minimizing energy input.
 
-![](/technical_overview/images/technical_overview_occ_0007.png "Surface generated from four curves and a point")
+@image html /technical_overview/images/technical_overview_occ_0007.png "Surface generated from four curves and a point"
+@image latex /technical_overview/images/technical_overview_occ_0007.png "Surface generated from four curves and a point"
 
-![](/technical_overview/images/technical_overview_occ_0008.png "Surface generated from two curves and a point")
+@image html /technical_overview/images/technical_overview_occ_0008.png "Surface generated from two curves and a point"
+@image latex /technical_overview/images/technical_overview_occ_0008.png "Surface generated from two curves and a point"
 
-Extension of a 3D curve or surface beyond its original bounds
-----------------------------------------
+#### Extension of a 3D curve or surface beyond its original bounds
 
 The extension is performed according to a geometric requirement and a continuity
 constraint. It should be a small extension with respect to the size of the original
 curve or surface.
 
-@sub?ubsection OCCT_TOVW_SECTION_4_1_5 Interpolation
+@subsubsection OCCT_TOVW_SECTION_4_1_5 Interpolation
 
 The Interpolation Laws component provides definitions of functions: <i> y=f(x) </i>.
 
@@ -1220,8 +1198,6 @@ In particular, it provides definitions of:
 
 Such functions can be used to define, for example, the evolution law of a fillet along the edge of a shape.
 
-Warning
--------
 The validity of the function built is never checked: the Law package does not know for what 
 application or to what end the function will be used. In particular, if the function is used 
 as the evolution law of a fillet, it is important that the function is always positive. The user must check this.
@@ -1316,39 +1292,21 @@ There are two libraries for Boolean Operations:
   * Old Boolean Operations (BOA) provided by <i>BRepAlgo</i> package designed and developed in Open CASCADE 6x in 2000; its architecture and content are out of date.
   * New Boolean Operations (NBOA) provided by <i>BRepAlgoAPI</i> package designed and developed in 2009 and completely revised in 2013.
 
-Major benefits of New Boolean Operations
-------------------------------------------
+New Boolean Operations provide the following major benefits:
 
-  * The NBOA has an expandable architecture of inner sub-algorithms, which  allows to create specific algorithms for the Customers using existing inner sub-algorithms as root algorithms and to reduce the time for the development. 
+  * The NBOA have an expandable architecture of inner sub-algorithms, which  allows to create specific algorithms for the Customers using existing inner sub-algorithms as root algorithms and to reduce the time for the development. 
   * The architecture of inner sub-algorithms of NBOA provides their reusability with maximal independence from the environment of NBOA. The fact allows to create specific algorithms for the Customers using these sub-algorithms as they are or as root classes and thus to reduce the time for the development. 
   * The architecture of NBOA is history-based. The implementation of NBOA internally sets up a correspondence between any sub-shape of the argument and its image in the result. The history is not imposed and thus it is not error-prone as it was in BOA. The fact allows direct and safely usage of the algorithm in parametric modeling.   
-  * NBOA is a general algorithm. It correctly processes without using the workarounds even the cases that cannot be properly processed by BOA.
+  * NBOA provide a general algorithm. It correctly processes without using the workarounds even the cases that cannot be properly processed by BOA.
   * The implementation of NBOA is based on NCollection classes. The usage of opportunities given by local memory allocators ( <i> NCollection_IncAllocator</i>) allows improving memory management and saving memory resources. 
-  * NBOA uses modern algorithms of OCC as auxiliary tools. For e.g. the algorithm of unbalanced binary tree of overlapped bounding boxes <i> NCollection_UBTree</i>. The usage of the algorithm allows to improve the performance of NBOA if there is a big number of sub-shapes in the arguments.
-
-The shape type of a Boolean Operation result and types of the arguments
--------------------------------------------------
-
-For arguments having the same shape type (e.g. SOLID / SOLID) 
-the type of the resulting shape will be a COMPOUND, containing shapes of this type;
-
-For arguments having different shape types (e.g. SHELL / SOLID) 
-the type of the resulting shape will be a COMPOUND, 
-containing shapes of the type that is the same as that 
-of the low type of the argument. Example: For SHELL/SOLID the result is a COMPOUND of SHELLs. 
-
-For arguments with different shape types some of Boolean Operations 
-can not be done using the default implementation, because of a non-manifold type 
-of the result. Example: the FUSE operation for SHELL and SOLID can not be done, 
-but the CUT operation can be done, where SHELL is the object and SOLID is the tool.
+  * NBOA use modern algorithms of OCC as auxiliary tools. For e.g. the algorithm of unbalanced binary tree of overlapped bounding boxes <i> NCollection_UBTree</i>. The usage of the algorithm allows to improve the performance of NBOA if there is a big number of sub-shapes in the arguments.
 
-It is possible to perform Boolean Operations on arguments of the COMPOUND shape type. 
-In this case each compound must not be heterogeneous, i.e. 
-it must contain equidimensional shapes (EDGEs or/and WIREs, FACEs or/and SHELLs, SOLIDs). 
-SOLIDs inside the COMPOUND must not contact (intersect or touch) each other. 
-The same condition should be respected for SHELLs or FACEs, WIREs or EDGEs.
-
-It does not support Boolean Operations for COMPSOLID type of shape.
+Boolean Operations have the following types of the arguments and produce the following results:
+* For arguments having the same shape type (e.g. SOLID / SOLID) the type of the resulting shape will be a COMPOUND, containing shapes of this type;
+* For arguments having different shape types (e.g. SHELL / SOLID) the type of the resulting shape will be a COMPOUND, containing shapes of the type that is the same as that of the low type of the argument. Example: For SHELL/SOLID the result is a COMPOUND of SHELLs. 
+* For arguments with different shape types some of Boolean Operations can not be done using the default implementation, because of a non-manifold type of the result. Example: the FUSE operation for SHELL and SOLID can not be done, but the CUT operation can be done, where SHELL is the object and SOLID is the tool.
+* It is possible to perform Boolean Operations on arguments of the COMPOUND shape type. In this case each compound must not be heterogeneous, i.e. it must contain equidimensional shapes (EDGEs or/and WIREs, FACEs or/and SHELLs, SOLIDs). SOLIDs inside the COMPOUND must not contact (intersect or touch) each other. The same condition should be respected for SHELLs or FACEs, WIREs or EDGEs.
+* Boolean Operations for COMPSOLID type of shape are not supported.
 
 @subsection OCCT_TOVW_SECTION_4_5 Features
 
@@ -1442,8 +1400,7 @@ See also: our web site at E-learning and Training.
 
 @subsection OCCT_TOVW_SECTION_4_8 Miscellaneous modelling algorithms. 
 
-Fillets and Chamfers
----------------------
+### Fillets and Chamfers
 
 This library provides algorithms to make fillets and chamfers on shape edges.
 The following cases are addressed:
@@ -1453,8 +1410,7 @@ The following cases are addressed:
 
 If there is a concavity, both surfaces that need to be extended and those, which do not, are processed.
 
-Offsets, Drafts, Sewing and Sweeps
-----------------------------------
+### Offsets, Drafts, Sewing and Sweeps
 
 These classes provide the following services:
 
@@ -1469,8 +1425,8 @@ These classes provide the following services:
 
 @subsection OCCT_TOVW_SECTION_4_9 Examples
 
-How to compute the state of a point on a face:
----------------------------------------------
+### How to compute the state of a point on a face:
+
 
 Use <i> BRepTools::Pnt </i> to get the point from your vertex.
 Your shape must be of the <i> TopoDS_Shape </i>type.
@@ -1483,8 +1439,8 @@ If it is, you can use <i> BRepTopAdaptor_FClass2d </i>class. For example:
 ~~~~~
 
 
-How to compute the state of a point in a solid:
----------------------------------------
+### How to compute the state of a point in a solid:
+
 
 Use <i>BRepTools::Pnt </i> to get the point from your vertex.
 Your shape must be of the <i> TopoDS_Solid</i> type.
@@ -1498,8 +1454,8 @@ If it is, you can use the <i> BRepClass3d_SolidClassifier </i> class, for exampl
     BRepClass3d_SolidClassifier inherits BRepclass3d_SClassifier
 ~~~~~
 
-How to connect a set of contiguous but independent faces
-------------------------------------------
+### How to connect a set of contiguous but independent faces
+
 
 A unique topological object can be obtained in this way using the class 
 <i> Sewing</i> from the <i> BRepOffsetAPI </i>package which produces a shell as a result.
@@ -1520,8 +1476,7 @@ If all faces have been sewed correctly, the result is a shell. Otherwise, it is
 
 For more information, refer to the entry for this class in reference documentation.
 
-How to check the orientation of a solid
---------------------------------------
+### How to check the orientation of a solid
 
 If you want to create a solid from a closed shell, you must first check the orientation to determine if you have to reverse the shell or not (for example after creating a closed shell from a sewing operation). To do this, use the <i> PerformInfinitePoint</i> method from the <i> BrepClass3D_SolidClassifier</i> class.
 
@@ -1547,11 +1502,12 @@ Please, refer for more details to Visualization User's guide
 
 See also: our web site at E-learning and Training.
 
-![](/technical_overview/images/technical_overview_viz.png "")
+@image html /technical_overview/images/technical_overview_viz.png
+@image latex /technical_overview/images/technical_overview_viz.png
 
 @subsection OCCT_TOVW_SECTION_5_1 3D Graphics
 
-3D Graphics provided by  <i> Graphic3d </i> package supports three-dimensional manipulation  of 3d graphic objects called structures. Structures, are made up of groups that unite primitives, such as polylines, planar polygons with or without holes, text and markers, and attributes,  such as color, transparency, reflection, line type, line width, and text font. 
+3D Graphics provided by  <i>Graphic3d</i> package supports three-dimensional manipulation  of 3d graphic objects called structures. Structures, are made up of groups that unite primitives, such as polylines, planar polygons with or without holes, text and markers, and attributes,  such as color, transparency, reflection, line type, line width, and text font.
 A group is the smallest editable element of a structure.
 
 A structure can be displayed, erased, highlighted and transformed.
@@ -1562,7 +1518,7 @@ The viewer can perform global manipulation of structures.
 
 Most types of primitives supported by <i> Graphic3d</i> can be dumped to a vector file format such as PDF and PostScript. Export to vector formats is implemented with help of <i> GL2PS</i> library.
 
-@subsection OCCT_TOVW_SECTION_5_2  3D Visualization
+@subsection OCCT_TOVW_SECTION_5_2 3D Visualization
 
 This library provides services for:
 
@@ -1578,8 +1534,7 @@ AIS expand this underlying functionality with standard 3D selection attributes,
   * A graphic attributes manager 
   * Selection filters 
 
-Interactive Context
--------------------
+### Interactive Context
 
 Interactive context pilots 3D visualizations and selections. 
 The interactive context allows you to manage, in a transparent way, graphic and "selectable" behavior of interactive objects which is not yet defined in the predefined types of these objects.
@@ -1587,13 +1542,11 @@ The interactive context allows you to manage, in a transparent way, graphic and
 AIS have two operating context types. The default neutral point type allows easily visualizing and selecting entire interactive objects, which have been loaded into the context. 
 Opening a local context allows preparing and using a temporary selection environment to select a part of an interactive object.
 
-Interactive Objects
--------------------
+### Interactive Objects
 
 Entities which are visualized and selected in the AIS viewer are objects.  They connect the underlying reference geometry of a model to its graphic representation in AIS. You can use predefined OCCT classes of standard interactive objects for which all necessary functions have already been programmed, or, in case you are an advanced user, you can implement your own classes of interactive objects.
 
-Graphic Attributes Manager
---------------------------
+### Graphic Attributes Manager
 
 Graphic attributes manager, or AIS Drawer, stores graphic attributes  for specific interactive objects and for interactive objects controlled by interactive context.
 
@@ -1601,8 +1554,7 @@ Initially, all drawer attributes are filled out with the predefined  values whic
 
 When an interactive object is visualized, the required graphic attributes are first taken from its own drawer if one exists, or from the context drawer if no specific drawer for that type of object exists.
 
-Selection Filters
------------------
+### Selection Filters
 
 An important aspect in selection is the filtering of entities you to select. 
 Selection filters allow you to refine the dynamic detection context, which you want to put into effect. Some of these filters can be used at the Neutral Point, others in an open local context only. You can also program your own filters and load them into the context.
@@ -1670,44 +1622,41 @@ When an interactive object is visualized, the required graphic attributes are fi
 
 @subsection OCCT_TOVW_SECTION_5_4 Presentation
 
-Presentation Management
-----------------------   
-
+### Presentation Management
+   
 <i> PrsMgr</i> package provides low level services and is only to be used when you do not want to use the services provided by AIS. It manages the display through the following services:
   * supplying a graphic structure for the object to be presented
   * recalculating presentations when required, e.g. by moving the object or changing its color
-  * defining the display mode of the object to be presented; in the case of <i> AIS_Shape</i>, for example, this determines whether the object is to be displayed in:
-                        wireframe 0
-                        shading 1.
+  * defining the display mode of the object to be presented; in the case of <i> AIS_Shape</i>, for example, this determines whether the object is to be displayed in wireframe (0) or shading (1) mode.
 
 Note that each new Interactive Object must have all its display modes defined.
 
-Presentations of Geometry
--------------------------
+### Presentations of Geometry
+
 The Presentations of Geometry component provides services for advanced programmers to extend the Application Interactive Services component, AIS. 
 This would prove necessary in situations where new Interactive Objects were required.
 
 The <i> StdPrs </i>package provides standard display tools for specific geometries and topologies whereas <i> Prs3d</i> provides those for generic objects. 
 Among these classes are definitions of the display of the specific geometry or topology in various display modes such as wireframe, shading or hidden line removal mode.
 
-Presentation of Dimensions
---------------------------
+### Presentation of Dimensions
+
  <i> DsgPrs </i> package provides tools for display of dimensions, relations and XYZ trihedrons.
 
 @subsection OCCT_TOVW_SECTION_5_5 Selection
 
 Selection of 3D data structures is provided using various algorithms. 
   
-Basic Selection
----------------
+### Basic Selection
+
 
 The <i> SelectBasics </i>package provides the following services:
 
   * the root definition of the sensitive primitive, a selectable entity in a view
   * the definition of the owner of a sensitive primitive; this entity relates the primitive to the application entity which is to be selected in the view.
 
-Standard Selections
--------------------
+### Standard Selections
+
  
 The <i> StdSelect</i> package provides the following services:
 
@@ -1722,8 +1671,8 @@ The <i>Select3D</i> package provides the following services:
   * recovery of the bounding boxes in the 2D graphic selection space, if required;
   * a 3D-2D projector.
 
-Selection Management
---------------------
+### Selection Management
+
  
 The <i> SelectMgr</i> package provides low level services and the classes 
 <i> SelectMgr_SelectionManager</i> and <i> SelectMgr_ViewerSelector </i>
@@ -1920,16 +1869,15 @@ from <i> AIS_InteractiveObject</i> and it should be used accordingly
 
 @subsection OCCT_TOVW_SECTION_5_8 Images and Drivers
 
-Images
---------
+### Images
 
 The <i> Image</i> package provides <i> PseudoColorImage</i> 
 and <i> ColorImage</i> definitions, and a set of key functions from the image fields. 
 
 The <i> AlienImage</i> package allows importing images from other formats into OCCT format.
 
-Drivers
----------
+### Drivers
+
 The <i> Xw </i>package contains the common X graphic interface. It uses <i> XWindow </i> bitmap fonts that cannot be modified.
 
 The <i> WNT</i> package contains the common Windows NT graphic interface.
@@ -1968,8 +1916,8 @@ Please, see for more information Voxels User's Guide white paper.
 
 @subsection OCCT_TOVW_SECTION_5_11 Examples
 
-How to change graphic attributes of an interactive object
-------------------------------------------------
+### How to change graphic attributes of an interactive object
+
 The set of graphic attributes of an interactive object is defined in AIS_Drawer. 
 Each interactive object can have its own visualization attributes.
 
@@ -1992,8 +1940,7 @@ To get the <i> AIS_Drawer</i> of an object, call method <i> AIS_InteractiveObjec
 
 To set the <i> AIS_Drawer</i> of an object, call method <i> AIS_InteractiveObject::SetLocalAttributes </i>. 
 
-How to dump a scene from the viewer
-----------------------------
+### How to dump a scene from the viewer
 
 You can dump the contents of a <i> V3D_View</i> in a file with the same scale or 
 with a different scale according to the required paper size (format) 
@@ -2014,8 +1961,8 @@ Please, note:
   * The time to generate these files is very short with the XWD format but 2 to 4 times longer for the other formats.
   * After getting an image file of your view, you can use any standard application for editing or sending the image file to a printer (i.e.: Microsoft Photo Editor on Windows or Image Viewer on SUN system)
 
-How to add and remove objects from Selections
----------------------------------------------
+### How to add and remove objects from Selections
+
 
 You can add or remove an object from a selection in one of two ways. You can use:
 
@@ -2023,8 +1970,8 @@ You can add or remove an object from a selection in one of two ways. You can use
   * <i> AddOrRemoveCurrent </i> method if a local context is opened.
 
  
-How to detect overlapped objects
---------------------------------
+### How to detect overlapped objects
+
 
 When objects overlap each other and cause difficulties in selection, 
 you can use the mechanism provided with the <i> AIS_InteractiveContext</i> 
@@ -2045,8 +1992,8 @@ This allows you to choose and validate the required object.
 
 
 
-Get mouse coordinates in 3D view
---------------------------------
+### Get mouse coordinates in 3D view
+
 
 To switch from pixel mouse position on the screen to 3D coordinates 
 in <i> V3d_View</i>, use <i>V3d_View::Convert</i> method.
@@ -2058,9 +2005,8 @@ in <i> V3d_View</i>, use <i>V3d_View::Convert</i> method.
 
 Where <i> Xp</i>, <i> Yp</i> are the mouse coordinates in pixels and X,Y,Z the real coordinates in 3D space.
 
-3D Viewer Objects
------------------
+### 3D Viewer Objects
+
 The <i> V3d </i>  package contains the set of commands and services of the 3D Viewer. 
 It provides a set of high level commands to control views and viewing modes. 
 This package is complementary to the <i> Visual3D</i> graphic package.
@@ -2084,7 +2030,8 @@ in particular in respect of allowed data types and arrangements between them, ac
 
 This matter is addressed by Data Exchange Module, which is organized in a modular way.
 
-![](/technical_overview/images/technical_overview_de.png "")
+@image html /technical_overview/images/technical_overview_de.png
+@image latex /technical_overview/images/technical_overview_de.png
 
 Data Exchange interfaces in OCCT allow software based on OCCT 
 to exchange data with various CAD software, thus ensuring a good level of interoperability.
@@ -2092,8 +2039,8 @@ to exchange data with various CAD software, thus ensuring a good level of intero
 Data Exchange interfaces function either in accordance with the standards (IGES, STEP), 
 which can be used by various software packages for CAD, PDM etc., or as direct connectors to proprietary formats.
 
-Standardized Data Exchange
---------------------------
+### Standardized Data Exchange
+
 
 * STEP (AP203 : Mechanical Design, this covers General 3D CAD; AP214: Automotive Design) 
 * IGES (up to 5.3) 
@@ -2103,8 +2050,8 @@ Standardized Data Exchange
 Data Exchange interfaces (STEP, IGES) allow to query and examine a file, 
 results of conversion and its validity. They are designed to support extensions (like new standards) in a common modular architecture.
 
-Extended data exchange
-----------------------
+### Extended data exchange
+
 
 Extended data exchange (XDE) allows you to extend the scope of exchange by translating
  additional data attached to geometric ("BREP") data, thereby improving the interoperability with external software.
@@ -2112,8 +2059,7 @@ Data types such as colors, assembly descriptions and validation properties
 (i.e. center of gravity, etc.) are supported. These data are stored together with shapes in an OCAF (XCAF) document.
 
 
-Proprietary Data Exchange
-------------------------
+### Proprietary Data Exchange
 
 In addition to standard Data Exchange interfaces, separate components are available 
 to provide direct mapping and data adaptation (using Shape Healing) with CAD software supporting the following formats:
@@ -2124,8 +2070,8 @@ to provide direct mapping and data adaptation (using Shape Healing) with CAD sof
 
 These components are based on the same architecture as interfaces with STEP and IGES.
 
-Translating a shape to STL Format
----------------------------------
+### Translating a shape to STL Format
+
 
 OCCT includes a module for translating OCCT shapes to STL (Stereolithography) format. 
 STL is a format designed for rapid prototyping. 
@@ -2144,14 +2090,9 @@ When translating shapes to STL format, remember that all references
 to shapes mean references to OCCT shapes unless otherwise explicitly defined. 
 In addition, sets of faces or unclosed shells may also be translated but visualization in foreign viewers may be incorrect.
 
-Translating a shape to VRML Format
-----------------------------------
-
-The Virtual Reality Modeling Language (VRML) is a language 
-for describing multi-participant interactive simulations   
-* virtual worlds networked via the Internet and hyperlinked 
-with the World Wide Web. VRML is a format designed for animated visualization of solids.
+### Translating a shape to VRML Format
 
+The Virtual Reality Modeling Language (VRML) is a language for describing multi-participant interactive simulations, virtual worlds networked via the Internet and hyperlinked with the World Wide Web. VRML is a format designed for animated visualization of solids.
 OCCT includes a module for translating OCCT shapes to VRML (Virtual Reality Modeling Language). 
 OCCT shapes may be translated in two representations (states): shaded or wireframe. 
 Since shaded VRML format files include only solids described by their mesh structures, the OCCT shapes intended to be written must be solids, components of solids or closed shells with a correct orientation.
@@ -2331,8 +2272,7 @@ variables: <i> CSF_PluginDefaults</i>, which defines the path of the plug-in fil
 The plugin and the resource files of the application will be located in <i> myDirector</i>.
 The name of the plugin file must be <i>Plugin</i>.
 
-Resource File
---------------
+### Resource File
 
 The resource file describes the documents (type and extension) and 
 the type of data that the application can manipulate 
@@ -2365,8 +2305,7 @@ OCAF-MyApplication.AttributeRetrievalPlugin: 47b0b827-d931-11d1-b5da-00a0c906436
 ~~~~
  
   
-Plugin File
------------
+### Plugin File
 
 The plugin file describes the list of required plug-ins to run the application and the
 libraries in which plug-ins are located.
@@ -2403,8 +2342,7 @@ The following ready-to-use attributes are provided:
   * Function attributes which regenerate any data affected by modifications made in a
 document 
 
-Shape Attributes
-----------------
+### Shape Attributes
 
 A topological attribute can be seen as a hook into the topological structure. To
 this hook, data can be attached and references defined.
@@ -2425,11 +2363,11 @@ dependent shapes by the changed one.
 If a shape is newly created, the old shape for the corresponding named shape is an empty
 shape. If a shape is deleted, then the new shape in this named shape is empty.
 
-![](/technical_overview/images/technical_overview_shapeattrib.png "")
+@image html /technical_overview/images/technical_overview_shapeattrib.png
+@image latex /technical_overview/images/technical_overview_shapeattrib.png
 
 
-Shape attributes in data framework. 
--------------------------------
+### Shape attributes in data framework. 
 
 Algorithms can dispose sub-shapes of the result shape at the individual
 label depending on necessity: 
@@ -2458,7 +2396,8 @@ without ambiguity, their number may change. Figure 6 illustrates this example, f
 F1 to F6 of the box each have a hook. Faces F7 to F10, the lateral faces of the protrusion,
 share a single hook, and face F11, the top face, has one hook.
 
-![](/technical_overview/images/technical_overview_occ_0068.png "")
+@image html /technical_overview/images/technical_overview_occ_0068.png
+@image latex /technical_overview/images/technical_overview_occ_0068.png
 
 This structure raises two problems: 
 
@@ -2474,8 +2413,8 @@ that this face could have been split in two faces (for example if the function h
 been a slot) and both new faces would have been attached to the same hook.
 
 
-Standard Attributes
--------------------
+### Standard Attributes
+
 
 Standard attributes are already existing ready-to-use attributes, which allow you
 to create and modify labels and attributes for many basic data types.
@@ -2490,15 +2429,15 @@ attribute you are looking for. For this, find this information using the method
 ~~~~
 
 
-Function Attributes
--------------------
+### Function Attributes
+
 
 A model consists of data and algorithms manipulating with data. OCAF attributes store
 data. A Function attribute stores data corresponding to a Function (see the white
 paper OCAF Function Mechanism User's Guide). This mechanism manipulates with algorithms
 computing the model in the optimal way following the modifications. 
 
-@subsection OCCT_TOVW_SECTION_7_2 Persistent Data Storage
+@subsection OCCT_TOVW_SECTION_7_3 Persistent Data Storage
 
 There are three schemas of persistence, which you can use to store and retrieve OCAF data (documents):
 
@@ -2527,7 +2466,7 @@ Finally, information about opening and saving persistent data is presented in St
 Documents. 
 
 
-@subsubsection OCCT_TOVW_SECTION_7_2_1 Basic Data Storage
+@subsubsection OCCT_TOVW_SECTION_7_3_1 Basic Data Storage
 
 Normally, all data structures provided by Open CASCADE Technology are run-time structures,
 in other words, transient data. As transient data, they exist only while an application
@@ -2537,8 +2476,7 @@ resources, which enable an application to store data on disk as persistent data.
 Data storage services also provide libraries of persistent classes and translation
 functions needed to translate data from transient to persistent state and vice-versa.
 
-Libraries of persistent classes
--------------------------------
+#### Libraries of persistent classes
 
 Libraries of persistent classes are extensible libraries of elementary classes you
 use to define the database schema of your application. They include:
@@ -2549,8 +2487,7 @@ All persistent classes are derived from the \b Persistent base class, which defi
 a unique way of creating and handling persistent objects. You create new persistent
 classes by inheriting from this base class.
 
-Translation Functions
----------------------
+#### Translation Functions
 
 Translation functions allow you to convert persistent objects to transient ones and
 vice-versa. These translation functions are used to build Storage and Retrieval drivers
@@ -2560,8 +2497,7 @@ For each class of 2D and 3D geometric types, and for the general shape class in
 topological data structure library, there are corresponding persistent class libraries,
 which allow you to translate your data with ease.
 
-Creation of Persistent Classes
--------------------------------
+#### Creation of Persistent Classes
 
 If you are using Unix platforms as well as WOK and CDL, you can create your own persistent
 classes. In this case, data storage is achieved by implementing Storage and Retrieval
@@ -2585,7 +2521,7 @@ The standard procedure for an application in writing a container is as follows:
   *call the function <i> Write </i> from the schema, setting the driver and the <i> Storage_Data </i> instance as parameters,
   *close the driver.
 
-@subsubsection OCCT_TOVW_SECTION_7_2_2 Persistent Collections
+@subsubsection OCCT_TOVW_SECTION_7_3_2 Persistent Collections
 
 Persistent collections are classes which handle dynamically sized collections of
 data that can be stored in the database. These collections provide three categories
@@ -2619,7 +2555,7 @@ Persistent string and array classes are found in the <i> PCollection</i> package
 In addition, <i> PColStd</i> package provides standard, 
 and frequently used, instantiations of persistent arrays, for very simple objects.
 
-@subsubsection OCCT_TOVW_SECTION_7_2_3 Persistent Geometry
+@subsubsection OCCT_TOVW_SECTION_7_3_3 Persistent Geometry
 
 The Persistent Geometry component describes geometric data structures which can be
 stored in the database. These packages provide a way to convert data from the transient
@@ -2682,7 +2618,7 @@ Handle(Geom_Axis2Placement)
 ~~~~
 
 
-@subsubsection OCCT_TOVW_SECTION_7_2_4 Persistent Topology
+@subsubsection OCCT_TOVW_SECTION_7_3_4 Persistent Topology
 
 The Persistent Topology component describes topological data structures which can be stored in the database. These packages provide a way to convert data from the transient "world" to the persistent "world".
 
@@ -2721,7 +2657,7 @@ Handle(TopoDS_HShape) aShape =
 aShape.Nullify();
 ~~~~
 
-@subsubsection OCCT_TOVW_SECTION_7_2_5 Standard Documents
+@subsubsection OCCT_TOVW_SECTION_7_3_5 Standard Documents
 
 Standard documents offer you a ready-to-use document containing a TDF-based data
 structure. The documents themselves are contained in a class inheriting from <i> TDocStd_Application</i>
@@ -2737,64 +2673,6 @@ alone provide access to the data framework. They also allow you to:
 
 @section OCCT_TOVW_SECTION_8 FAQ
 
-Dynamic library loading problem
--------------------------------
-
-Open CASCADE Technology uses a dynamic library loading mode. 
-Sometimes, the error message such as the following appears:
-
-~~~~
- "cannot map <i>libname.so</i> .. under any of the filenames .."
-~~~~
-
-When this happens, check your <i> PATH </i>under Windows, <i> LD_LIBRARY_PATH</i> under UNIX ,
-<i> SHLIB_PATH </i> under HP-UX or <i> LIBPATH</i> under IBM AIX . 
-It should contain the path where the required dynamic library is located.
-
-Running Draw under Windows
----------------------------
-
-When running <i> DRAWEXE</i> and using axo in the Command window you may see the "Invalid command name "axo" " message :
-
-Make sure that the OCCT directory name does not contain any blank spaces.
-It causes some problems when reading the OCCT description TCL Commands files.
-If you have set <i> DRAWHOME</i> and <i> DRAWDEFAULT</i>, replace \ by / in the variable. 
-
-Error on application start on Windows
---------------------------------------
-If Windows shows an error message with the text *Application failed to initialize properly* 
-upon launching the application, check access rights for all libraries used in the application, in particular, third-party libraries. 
-
-Make sure that you have all rights  necessary to access these libraries. 
-It is recommended to use option *Inherit access rights from parent*.
-
-Problems with 3D viewer
---------------------
-
-If the 3D viewer fails to display the scene properly, or works very slowly, or exhibits
-another problem, make sure to have the latest version of the graphics card driver
-installed. If this is not possible or does not help, try to decrease 
-hardware acceleration level (usually found in Troubleshooting section of the graphics card properties).
-
-Fatal error during graphic initialization
-----------------------------------------
-
-If you get the <b>Fatal error during graphic initialization</b> message when running 
-an Open CASCADE Technology based application, or if the application crashes 
-without displaying error messages, you must set the environment variable <i> CSF_GRAPHICSHR </i> as follows:
-
-  * On Windows, if we suppose that OCCT is installed in <i> D:\OpenCASCADE6.3.0 </i>
-
-~~~~
-    Set CSF_GraphicShr= D:\OpenCASCADE6.3.1\ros\win32\bin\TkOpenGl.dll
-~~~~
-
-  * On Linux or Unix, if we suppose that OCCT is installed in  <i> .../mydisk/ OpenCASCADE6.3.0 </i>
-
-~~~~
-    Setenv CSF_GraphicsShr /mydisk/ OpenCASCADE6.3.0ros/lin/lib/libTKOpenGl.so
-~~~~
-
 @subsection OCCT_TOVW_SECTION_8_1 Memory Management
 
 In a work-session, geometry modeling applications create and delete a certain number
@@ -2806,14 +2684,10 @@ on the following principles:
   * small memory arrays are grouped into clusters and then recycled (clusters are never released to the system),
   * large arrays are allocated and de-allocated through the standard functions of the system (the arrays are released to system when they are no longer used).
 
-The Reference Counter
--------------------
+### The Reference Counter
+
 To lighten usual programming difficulties linked to the management of object life duration, before deleting an object, the user must ensure the object is no longer referenced and the delete function is secured by a reference counter. 
-A smart-pointer
-called a Handle automates reference counter management and automatically deletes
-an object when it is no longer referenced – the application never calls the delete
-operator explicitly. To benefit from the memory manager in OCCT, transient classes
-must inherit from <i> TShared</i>. The principle of allocation is as follows:
+A smart-pointer called *Handle* automates reference counter management and automatically deletes an object when it is no longer referenced. The application never calls the delete operator explicitly. To benefit from the memory manager in OCCT, transient classes must inherit from <i>TShared</i>. The principle of allocation is as follows:
 
 ~~~~
     Handle (TColStd_HSequenceOfInteger) H1 = new TColStd_HSequenceOfInteger;
@@ -2837,22 +2711,17 @@ must inherit from <i> TShared</i>. The principle of allocation is as follows:
     // memory. In this case, there is no allocation of memory.
 ~~~~
 
-Cycles
-------
-As cycles are objects which reference one another, memory management is impossible
-if the data structure contains any cycles, particularly if there are back references.
+### Cycles
+
+As cycles are objects which reference one another, memory management is impossible if the data structure contains any cycles, particularly if there are back references.
+
+For example, objects in a graph include primitives and each one of these primitives has to know the graphic object to which it belongs (i.e. a reference to this graphic object). With normal references, the classical handle is used. With back references, a pointer is used. 
 
-For example, objects in a graph include primitives and each one of these primitives
-has to know the graphic object to which it belongs (i.e. a reference to this graphic
-object). With normal references, the classical handle is used. With back references,
-a pointer is used. 
+### Memory Consumption
 
-Memory Consumption
-------------------
 
-As a general rule, it is advisable to allocate memory through significant blocks.
-In this way, the user can work with blocks of contiguous data and it facilitates
-memory page manager processing.
+As a general rule, it is advisable to allocate memory through significant blocks. 
+In this way, the user can work with blocks of contiguous data and it facilitates memory page manager processing.
 
 @subsection OCCT_TOVW_SECTION_8_2 How to define a handled object without CDL
 
@@ -3014,4 +2883,62 @@ to another place defined by a label.
 
 The filter is used to forbid copying a specified type of attribute. 
 You can also have a look at <i> TDF_Closure*</i>, 
-which can be useful to determine the dependencies of the part you want to cut from the document.
\ No newline at end of file
+which can be useful to determine the dependencies of the part you want to cut from the document.
+
+@subsection OCCT_TOVW_SECTION_8_7 Platform-related problems 
+
+### Dynamic library loading 
+
+Open CASCADE Technology uses a dynamic library loading mode. Sometimes, the error message such as the following appears:
+
+~~~~
+ "cannot map <i>libname.so</i> .. under any of the filenames .."
+~~~~
+
+When this happens, check your <i> PATH </i>under Windows, <i> LD_LIBRARY_PATH</i> under UNIX ,
+<i> SHLIB_PATH </i> under HP-UX or <i> LIBPATH</i> under IBM AIX . 
+It should contain the path where the required dynamic library is located.
+
+### Running Draw under Windows
+
+
+When running <i> DRAWEXE</i> and using axo in the Command window you may see the "Invalid command name "axo" " message :
+
+Make sure that the OCCT directory name does not contain any blank spaces.
+It causes some problems when reading the OCCT description TCL Commands files.
+If you have set <i> DRAWHOME</i> and <i> DRAWDEFAULT</i>, replace \ by / in the variable. 
+
+### Error on application start on Windows
+
+If Windows shows an error message with the text *Application failed to initialize properly* 
+upon launching the application, check access rights for all libraries used in the application, in particular, third-party libraries. 
+
+Make sure that you have all rights  necessary to access these libraries. 
+It is recommended to use option *Inherit access rights from parent*.
+
+### Problems with 3D viewer
+
+
+If the 3D viewer fails to display the scene properly, or works very slowly, or exhibits
+another problem, make sure to have the latest version of the graphics card driver
+installed. If this is not possible or does not help, try to decrease 
+hardware acceleration level (usually found in Troubleshooting section of the graphics card properties).
+
+### Fatal error during graphic initialization
+
+
+If you get the <b>Fatal error during graphic initialization</b> message when running 
+an Open CASCADE Technology based application, or if the application crashes 
+without displaying error messages, you must set the environment variable <i> CSF_GRAPHICSHR </i> as follows:
+
+  * On Windows, if we suppose that OCCT is installed in <i> D:\OpenCASCADE6.3.0 </i>
+
+~~~~
+    Set CSF_GraphicShr= D:\OpenCASCADE6.3.1\ros\win32\bin\TkOpenGl.dll
+~~~~
+
+  * On Linux or Unix, if we suppose that OCCT is installed in  <i> .../mydisk/ OpenCASCADE6.3.0 </i>
+
+~~~~
+    Setenv CSF_GraphicsShr /mydisk/ OpenCASCADE6.3.0ros/lin/lib/libTKOpenGl.so
+~~~~
\ No newline at end of file
index 85ed40d..448eaa9 100644 (file)
@@ -82,12 +82,12 @@ The format of the file is compliant with standard Open CASCADE Technology resour
 Each key defines a sequence of either further (nested) keys or a name of the dynamic library. Keys can be nested down to an arbitrary level. However, cyclic dependencies between the keys are not checked. 
 **Example** (excerpt from DrawPlugin): 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
-OCAF               : VISUALIZATION, OCAFKERNEL 
-VISUALIZATION      : AISV 
-OCAFKERNEL         : DCAF 
+OCAF               : VISUALIZATION, OCAFKERNEL 
+VISUALIZATION      : AISV 
+OCAFKERNEL         : DCAF 
 
-DCAF               : TKDCAF 
-AISV               : TKViewerTest 
+DCAF               : TKDCAF 
+AISV               : TKViewerTest 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 @subsubsection occt_2142243456_177531676033 Activation of commands implemented in the plug-in
@@ -96,18 +96,18 @@ To load a plug-in declared in the resource file and to activate the commands the
 
 pload [-PluginFileName] [[Key1] [Key2]...], where: 
 
--PluginFileName        Defines the name of a plug-in resource file (prefix ;-; is mandatory) described above. 
+-PluginFileName        Defines the name of a plug-in resource file (prefix ;-; is mandatory) described above. 
 If this parameter is omitted then the default name DrawPlugin is used. 
 
-Key…                       Defines the key(s) enumerating plug-ins to be loaded. 
+Key…                       Defines the key(s) enumerating plug-ins to be loaded. 
 If no keys are specified then the key named DEFAULT is used (if there is no such key in the file then no plug-ins are loaded). 
 According to the OCCT resource file management rules, to access the resource file the environment variable CSF_PluginFileNameDefaults (and optionally CSF_PluginFileNameUserDefaults) must be set and point to the directory storing the resource file. If it is omitted then the plug-in resource file will be searched in the $CASROOT/src/DrawResources directory. 
 **Examples:** 
 
-Draw[]        pload -DrawPlugin OCAF 
+Draw[]        pload -DrawPlugin OCAF 
 Will search the resource file DrawPlugin using variable CSF_DrawPluginDefaults (and CSF_DrawPluginUserDefaults) and will start with the OCAF key. Since the DrawPlugin is the file shipped with Open CASCADE Technology it will be found in the $CASROOT/src/DrawResources directory (unless this location is redefined by user's variables). The OCAF key will be recursively extracted into two toolkits/plug-ins: TKDCAF and TKViewerTest (e.g. on Windows they correspond to TKDCAF.dll and TKViewerTest.dll). Thus, commands implemented for Visualization and OCAF will be loaded and activated in Test Harness. 
 
-Draw[]        pload (equivalent to pload -DrawPlugin DEFAULT). 
+Draw[]        pload (equivalent to pload -DrawPlugin DEFAULT). 
 Will find the default DrawPlugin file and the DEFAULT key. The latter finally maps to the TKTopTest toolkit which implements basic modeling commands. 
 
 
@@ -332,7 +332,7 @@ It is recommended that you use TCL variables only for strings and Draw for numer
 
 @subsubsection occt_2142243456_166853072961 set, unset
 
-Syntax:                  set varname [value] 
+Syntax:                  set varname [value] 
 unset varname [varname varname ...] 
 
 **set **assigns a string value to a variable. If the variable does not already exist, it is ñreated. 
@@ -359,7 +359,7 @@ See also: **dset**, **dval**
 
 @subsubsection occt_2142243456_166853072962 dset, dval
 
-Syntax                   dset var1 value1 vr2 value2 ... 
+Syntax                   dset var1 value1 vr2 value2 ... 
 dval name 
 
 **dset **assigns values to Draw numeric variables. The argument can be any numeric expression including Draw numeric variables. Since all Draw commands expect a numeric expression, there is no need to use $ or **expr**. The **dset **command can assign several variables. If there is an odd number of arguments, the last variable will be assigned a value of 0. If the variable does not exist, it will be created. 
@@ -410,7 +410,7 @@ TCL allows looping using control structures. The control structures are implemen
 
 @subsubsection occt_2142243456_166853072911 if
 
-Syntax       if condition script [elseif script .... else script] 
+Syntax       if condition script [elseif script .... else script] 
 
 **If **evaluates the condition and the script to see whether the condition is true. 
 **Example** 
@@ -426,7 +426,7 @@ puts ;negative;
 
 @subsubsection occt_2142243456_166853072912 while, for, foreach
 
-Syntax:                  while condition script 
+Syntax:                  while condition script 
 for init condition reinit script 
 foreach varname list script 
 
@@ -453,7 +453,7 @@ See also: **break**, **continue**
 
 @subsubsection occt_2142243456_166853072913 break, continue
 
-Syntax:                  break 
+Syntax:                  break 
 continue 
 
 Within loops, the **break **and **continue **commands have the same effect as in C. 
@@ -479,7 +479,7 @@ As TCL is not a strongly typed language it is very difficult to detect programin
 
 @subsubsection occt_2142243456_166853072921 proc
 
-Syntax:                  proc argumentlist script 
+Syntax:                  proc argumentlist script 
 
 **proc **defines a procedure. An argument may have a default value. It is then a list of the form {argument value}. The script is the body of the procedure. 
 
@@ -506,7 +506,7 @@ See also: **global**, **upvar**
 
 @subsubsection occt_2142243456_166853072922 global, upvar
 
-Syntax:                  global varname [varname ...] 
+Syntax:                  global varname [varname ...] 
 upvar varname localname [varname localname ...] 
 
 **global **accesses high level variables. Unlike C, global variables are not visible in procedures. 
@@ -550,7 +550,7 @@ This section describes several useful commands: **help **to get information, **s
 
 @subsubsection occt_2142243456_96704938111 help
 
-Syntax:                  help [command [helpstring group]] 
+Syntax:                  help [command [helpstring group]] 
 
 Provides help or modifies the help information. 
 
@@ -563,7 +563,7 @@ Specifying the command returns its syntax and in some cases, information on the
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 @subsubsection occt_2142243456_96704938112 source
 
-Syntax:                  source filename 
+Syntax:                  source filename 
 
 Executes a file. 
 
@@ -574,7 +574,7 @@ See also: exit
 
 @subsubsection occt_2142243456_96704938113 spy
 
-Syntax:                  spy [filename] 
+Syntax:                  spy [filename] 
 
 Saves interactive commands in the file. If spying has already been performed, the current file is closed. **spy **without an argument closes the current file and stops spying. If a file already exists, the file is overwritten. Commands are not appended. 
 If a command returns an error it is saved with a comment mark. 
@@ -592,7 +592,7 @@ See also: **source**
 
 @subsubsection occt_2142243456_96704938114 cpulimit
 
-Syntax:                  cpulimit [nbseconds] 
+Syntax:                  cpulimit [nbseconds] 
 
 **cpulimit **limits a process after the number of seconds specified in *nbseconds. *It is used in tests to avoid infinite loops. **cpulimit **without arguments removes all existing limits. 
 **Example** 
@@ -603,7 +603,7 @@ cpulimit 3600
 
 @subsubsection occt_2142243456_96704938115 wait
 
-Syntax:                  wait [nbseconds] 
+Syntax:                  wait [nbseconds] 
 
 Suspends execution for the number of seconds specified in *nbseconds*. The default value is ten (10) seconds. This is a useful command for a slide show. 
 
@@ -614,7 +614,7 @@ wait
 
 @subsubsection occt_2142243456_96704938116 chrono
 
-Syntax:                  chrono [ name start/stop/reset/show] 
+Syntax:                  chrono [ name start/stop/reset/show] 
 
 Without arguments, **chrono **activates Draw chronometers. The elapsed time ,cpu system and cpu user times for each command will be printed. 
 
@@ -635,11 +635,11 @@ ptorus t 20 5
 ==CPU system time: 0 seconds 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-@subsection occt_2142243456_9670493812  Variable management commands
+@subsection occt_2142243456_9670493812  Variable management commands
 
 @subsubsection occt_2142243456_96704938121 isdraw, directory
 
-Syntax:                  isdraw varname 
+Syntax:                  isdraw varname 
 directory [pattern] 
 
 **isdraw **tests to see if a variable is a Draw variable. **isdraw **will return 1 if there is a Draw value attached to the variable. 
@@ -667,7 +667,7 @@ See also: **whatis**
 
 @subsubsection occt_2142243456_96704938122 whatis, dump
 
-Syntax:                  whatis varname [varname ...] 
+Syntax:                  whatis varname [varname ...] 
 dump varname [varname ...] 
 
 **whatis **returns short information about a Draw variable. This is usually the type name. 
@@ -696,7 +696,7 @@ Radius :5
 
 @subsubsection occt_2142243456_96704938123 rename, copy
 
-Syntax:      rename varname tovarname [varname tovarname ...] 
+Syntax:      rename varname tovarname [varname tovarname ...] 
 copy varname tovarname [varname tovarname ...] 
 
 **rename **changes the name of a Draw variable. The original variable will no longer exist. Note that the content is not modified. Only the name is changed. 
@@ -713,7 +713,7 @@ copy c2 c3
 
 @subsubsection occt_2142243456_96704938124 datadir, save, restore
 
-Syntax:                  datadir [directory] 
+Syntax:                  datadir [directory] 
 save variable [filename] 
 restore filename [variablename] 
 
@@ -836,7 +836,7 @@ Graphic commands are used to manage the Draw graphic system. Draw provides a 2d
 
 @subsubsection occt_2142243456_44562206611 view, delete
 
-Syntax:                  view index type [X Y W H] 
+Syntax:                  view index type [X Y W H] 
 delete [index] 
 
 **view **is the basic view creation command: it creates a new view with the given index. If a view with this index already exits, it is deleted. The view is created with default parameters and X Y W H are the position and dimensions of the window on the screen. Default values are 0, 0, 500, 500. 
@@ -866,9 +866,9 @@ view 4 AXON 728 450 400 400
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 See also: **axo, pers, top, bottom, left, right, front, back, mu4, v2d, av2d, smallview** 
 
-@subsubsection occt_2142243456_44562206612  axo, pers, top, ...
+@subsubsection occt_2142243456_44562206612  axo, pers, top, ...
 
-Syntax:      axo 
+Syntax:      axo 
 pers 
 ... 
 smallview type 
@@ -888,7 +888,7 @@ See also: **view**, **delete**
 
 @subsubsection occt_2142243456_44562206613 mu, md, 2dmu, 2dmd, zoom, 2dzoom
 
-Syntax:                  mu [index] value 
+Syntax:                  mu [index] value 
 2dmu [index] value 
 zoom [index] value 
 wzoom 
@@ -918,7 +918,7 @@ See also: **fit**, **2dfit**
 
 @subsubsection occt_2142243456_44562206614 pu, pd, pl, pr, 2dpu, 2dpd, 2dpl, 2dpr
 
-Syntax:                  pu [index] 
+Syntax:                  pu [index] 
 pd [index] 
 
 The **p_ **commands are used to pan. **pu **and **pd **pan up and down respectively;**pl **and **pr **pan left and right respectively. Each time the view is displaced by 40 pixels.When no index is given, all views will pan in the direction specified. 
@@ -939,7 +939,7 @@ See also: **fit**, **2dfit**
 
 @subsubsection occt_2142243456_44562206615 fit, 2dfit
 
-Syntax:      fit [index] 
+Syntax:      fit [index] 
 2dfit [index] 
 
 **fit **computes the best zoom and pans on the content of the view. The content of the view will be centered and fit the whole window. 
@@ -958,7 +958,7 @@ See also: **zoom**, **mu**, **pu**
 
 @subsubsection occt_2142243456_44562206616 u, d, l, r
 
-Syntax:      u [index] 
+Syntax:      u [index] 
 d [index] 
 l [index] 
 r [index] 
@@ -973,7 +973,7 @@ u
 
 @subsubsection occt_2142243456_44562206617 focal, fu, fd
 
-Syntax:                  focal [f] 
+Syntax:                  focal [f] 
 fu [index] 
 fd [index] 
 **focal **changes the vantage point in perspective views. A low f value increases the perspective effect; a high one give a perspective similar to that of an axonometric view. The default value is 500. 
@@ -1009,7 +1009,7 @@ color 3 ;navy blue;
 
 @subsubsection occt_2142243456_44562206619 dtext
 
-Syntax:      dtext [x y [z]] string 
+Syntax:      dtext [x y [z]] string 
 
 **dtext **displays a string in all 3d or 2d views. If no coordinates are given, a graphic selection is required. If two coordinates are given, the text is created in a 2d view at the position specified. With 3 coordinates, the text is created in a 3d view. 
 
@@ -1024,7 +1024,7 @@ dtext 0 0 0 bebop
 
 @subsubsection occt_2142243456_445622066110 hardcopy, hcolor, xwd
 
-Syntax:      hardcopy [index] 
+Syntax:      hardcopy [index] 
 hcolor index width gray 
 xwd [index] filename 
 
@@ -1056,7 +1056,7 @@ See also: **color**
 
 @subsubsection occt_2142243456_445622066111 wclick, pick
 
-Syntax:      wclick 
+Syntax:      wclick 
 pick index X Y Z b [nowait] 
 
 **wclick **defers an event until the mouse button is clicked. The message ;just click; is displayed. 
@@ -1128,7 +1128,7 @@ rename . x
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 @subsubsection occt_2142243456_445622066112 autodisplay
 
-Syntax:      autodisplay [0/1] 
+Syntax:      autodisplay [0/1] 
 
 By default, Draw automatically displays any graphic object as soon as it is created. This behavior known as autodisplay can be removed with the command **autodisplay**. Without arguments, **autodisplay **toggles the autodisplay mode. The command always returns the current mode. 
 
@@ -1150,7 +1150,7 @@ See also: **display**
 
 @subsubsection occt_2142243456_445622066113 display, donly
 
-Syntax:      display varname [varname ...] 
+Syntax:      display varname [varname ...] 
 donly varname [varname ...] 
 
 **display **makes objects visible. 
@@ -1169,7 +1169,7 @@ See also: **erase**
 
 @subsubsection occt_2142243456_445622066114 erase, clear, 2dclear
 
-Syntax:      erase [varname varname ...] 
+Syntax:      erase [varname varname ...] 
 clear 
 2dclear 
 
@@ -1187,7 +1187,7 @@ foreach var [directory c_*] {erase $var}
 See also: **display** 
 @subsubsection occt_2142243456_445622066115 repaint, dflush
 
-Syntax:      repaint 
+Syntax:      repaint 
 dflush 
 
 **repaint **forces repainting of views. 
@@ -1210,19 +1210,19 @@ See also: **pick**
 
 @subsubsection occt_2142243456_44562206621 vinit
 
-Syntax:                  vinit 
+Syntax:                  vinit 
 
 Creates the 3D viewer window 
 
 @subsubsection occt_2142243456_44562206622 vhelp
 
-Syntax:                  vhelp 
+Syntax:                  vhelp 
 
 Displays help in the 3D viewer window. The help consists in a list of hotkeys and their functionalities. 
 
 @subsubsection occt_2142243456_44562206623 vtop
 
-Syntax:                  vtop 
+Syntax:                  vtop 
 
 Displays top view in the 3D viewer window. 
 **Example** 
@@ -1235,7 +1235,7 @@ vtop
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 @subsubsection occt_2142243456_44562206624 vaxo
 
-Syntax:                  vaxo 
+Syntax:                  vaxo 
 
 Displays axonometric view in the 3D viewer window. 
 **Example** 
@@ -1248,7 +1248,7 @@ vaxo
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 @subsubsection occt_2142243456_44562206625 vsetbg
 
-Syntax:                  vsetbg imagefile [filltype] 
+Syntax:                  vsetbg imagefile [filltype] 
 
 Loads image file as background. **filltype** must be **NONE, CENTERED, TILED or STRETCH**. 
 **Example** 
@@ -1258,25 +1258,25 @@ vsetbg myimage.brep CENTERED
 
 @subsubsection&