OCCT documentation (Overview and User Guides) has been converted from MS Word files to text-based MarkDown format and added to OCCT sources, in the new subfolder 'dox'. The HTML and PDF articles can be generated from the sources using Doxygen and MiKTeX. See the file OCCT_Docs_HowTo.md for details on the new documentation system.
This branch includes:
- new folder structure for Open CASCADE documentation
- sources of almost all OCCT User Guides and Overview
- tcl and bat scripts, which allow to generate HTML and PDF articles
*.brep eol=lf
*.rle eol=lf
*.vrml eol=lf
+*.md eol=lf
FILES eol=lf
PACKAGES eol=lf
EXTERNLIB eol=lf
/ao1
/sil
/wnt
+/doc
/drv
/inc
/work
/*.am
/*.m4
/*.ac
-/*.sh
-/*.bat
/autom4te.cache
/build_configure
/configure
CONDITIONS OF THIS LICENSE
-Open CASCADE S.A.S. is a French société par actions simplifiée having its main offices at 1, place des Frères Montgolfier, 78280 Guyancourt, France. Its web site is located at the following address www.opencascade.com
+Open CASCADE S.A.S. is a French société par actions simplifiée having its main offices at 1, place in Frères Montgolfier, 78280 Guyancourt, France. Its web site is located at the following address www.opencascade.com
Open CASCADE Technology Public License
Schedule "A"
-The content of this file is subject to the Open CASCADE Technology Public License Version 6.5 (the "License"). You may not use the content of this file except in compliance with the License. Please obtain a copy of the License at http://www.opencascade.org and read it completely before using this file.
+The content of this file is subject to the Open CASCADE Technology Public License Version 6.5 (the "License").
+You may not use the content of this file except in compliance with the License.
+Please obtain a copy of the License at http://www.opencascade.org and read it completely before using this file.
The Initial Developer of the Original Code is Open CASCADE S.A.S., with main offices at 1, place des Frères Montgolfier, 78280 Guyancourt, France. The Original Code is copyright © Open CASCADE S.A.S., 2001. All rights reserved.
--- /dev/null
+<doxygenlayout version="1.0">
+ <!-- Generated by doxygen 1.8.3.1 -->
+ <!-- Navigation index tabs for HTML output -->
+ <navindex>
+ <tab type="mainpage" visible="yes" title="Introduction"/>
+ <tab type="pages" visible="yes" title="Documents" intro="This section contains links to all OCCT documents that are available at the moment"/>
+ <tab type="modules" visible="yes" title="" intro=""/>
+ <tab type="namespaces" visible="yes" title="">
+ <tab type="namespacelist" visible="no" title="" intro=""/>
+ <tab type="namespacemembers" visible="yes" title="" intro=""/>
+ </tab>
+ <tab type="classes" visible="yes" title="Reference Manual">
+ <tab type="classlist" visible="no" title="" intro=""/>
+ <tab type="classindex" visible="$ALPHABETICAL_INDEX" title=""/>
+ <tab type="hierarchy" visible="no" title="" intro=""/>
+ <tab type="classmembers" visible="no" title="" intro=""/>
+ </tab>
+ <tab type="files" visible="no" title="Files">
+ <tab type="filelist" visible="yes" title="" intro=""/>
+ <tab type="globals" visible="yes" title="" intro=""/>
+ </tab>
+ <tab type="examples" visible="no" title="" intro=""/>
+ </navindex>
+
+ <!-- Layout definition for a class page -->
+ <class>
+ <briefdescription visible="yes"/>
+ <includes visible="$SHOW_INCLUDE_FILES"/>
+ <inheritancegraph visible="$CLASS_GRAPH"/>
+ <collaborationgraph visible="$COLLABORATION_GRAPH"/>
+ <memberdecl>
+ <nestedclasses visible="yes" title=""/>
+ <publictypes title=""/>
+ <publicslots title=""/>
+ <signals title=""/>
+ <publicmethods title=""/>
+ <publicstaticmethods title=""/>
+ <publicattributes title=""/>
+ <publicstaticattributes title=""/>
+ <protectedtypes title=""/>
+ <protectedslots title=""/>
+ <protectedmethods title=""/>
+ <protectedstaticmethods title=""/>
+ <protectedattributes title=""/>
+ <protectedstaticattributes title=""/>
+ <packagetypes title=""/>
+ <packagemethods title=""/>
+ <packagestaticmethods title=""/>
+ <packageattributes title=""/>
+ <packagestaticattributes title=""/>
+ <properties title=""/>
+ <events title=""/>
+ <privatetypes title=""/>
+ <privateslots title=""/>
+ <privatemethods title=""/>
+ <privatestaticmethods title=""/>
+ <privateattributes title=""/>
+ <privatestaticattributes title=""/>
+ <friends title=""/>
+ <related title="" subtitle=""/>
+ <membergroups visible="yes"/>
+ </memberdecl>
+ <detaileddescription title=""/>
+ <memberdef>
+ <inlineclasses title=""/>
+ <typedefs title=""/>
+ <enums title=""/>
+ <constructors title=""/>
+ <functions title=""/>
+ <related title=""/>
+ <variables title=""/>
+ <properties title=""/>
+ <events title=""/>
+ </memberdef>
+ <allmemberslink visible="yes"/>
+ <usedfiles visible="$SHOW_USED_FILES"/>
+ <authorsection visible="yes"/>
+ </class>
+
+ <!-- Layout definition for a namespace page -->
+ <namespace>
+ <briefdescription visible="yes"/>
+ <memberdecl>
+ <nestednamespaces visible="yes" title=""/>
+ <classes visible="yes" title=""/>
+ <typedefs title=""/>
+ <enums title=""/>
+ <functions title=""/>
+ <variables title=""/>
+ <membergroups visible="yes"/>
+ </memberdecl>
+ <detaileddescription title=""/>
+ <memberdef>
+ <inlineclasses title=""/>
+ <typedefs title=""/>
+ <enums title=""/>
+ <functions title=""/>
+ <variables title=""/>
+ </memberdef>
+ <authorsection visible="yes"/>
+ </namespace>
+
+ <!-- Layout definition for a file page -->
+ <file>
+ <briefdescription visible="yes"/>
+ <includes visible="$SHOW_INCLUDE_FILES"/>
+ <includegraph visible="$INCLUDE_GRAPH"/>
+ <includedbygraph visible="$INCLUDED_BY_GRAPH"/>
+ <sourcelink visible="yes"/>
+ <memberdecl>
+ <classes visible="yes" title=""/>
+ <namespaces visible="yes" title=""/>
+ <defines title=""/>
+ <typedefs title=""/>
+ <enums title=""/>
+ <functions title=""/>
+ <variables title=""/>
+ <membergroups visible="yes"/>
+ </memberdecl>
+ <detaileddescription title=""/>
+ <memberdef>
+ <inlineclasses title=""/>
+ <defines title=""/>
+ <typedefs title=""/>
+ <enums title=""/>
+ <functions title=""/>
+ <variables title=""/>
+ </memberdef>
+ <authorsection/>
+ </file>
+
+ <!-- Layout definition for a group page -->
+ <group>
+ <briefdescription visible="yes"/>
+ <groupgraph visible="$GROUP_GRAPHS"/>
+ <memberdecl>
+ <nestedgroups visible="yes" title=""/>
+ <dirs visible="yes" title=""/>
+ <files visible="yes" title=""/>
+ <namespaces visible="yes" title=""/>
+ <classes visible="yes" title=""/>
+ <defines title=""/>
+ <typedefs title=""/>
+ <enums title=""/>
+ <enumvalues title=""/>
+ <functions title=""/>
+ <variables title=""/>
+ <signals title=""/>
+ <publicslots title=""/>
+ <protectedslots title=""/>
+ <privateslots title=""/>
+ <events title=""/>
+ <properties title=""/>
+ <friends title=""/>
+ <membergroups visible="yes"/>
+ </memberdecl>
+ <detaileddescription title=""/>
+ <memberdef>
+ <pagedocs/>
+ <inlineclasses title=""/>
+ <defines title=""/>
+ <typedefs title=""/>
+ <enums title=""/>
+ <enumvalues title=""/>
+ <functions title=""/>
+ <variables title=""/>
+ <signals title=""/>
+ <publicslots title=""/>
+ <protectedslots title=""/>
+ <privateslots title=""/>
+ <events title=""/>
+ <properties title=""/>
+ <friends title=""/>
+ </memberdef>
+ <authorsection visible="yes"/>
+ </group>
+
+ <!-- Layout definition for a directory page -->
+ <directory>
+ <briefdescription visible="yes"/>
+ <directorygraph visible="yes"/>
+ <memberdecl>
+ <dirs visible="yes"/>
+ <files visible="yes"/>
+ </memberdecl>
+ <detaileddescription title=""/>
+ </directory>
+</doxygenlayout>
--- /dev/null
+overview/overview.md
+overview/tutorial/tutorial.md
+technical_overview/technical_overview.md
+
+user_guides/user_guides.md
+user_guides/foundation_classes/foundation_classes.md
+user_guides/modeling_data/modeling_data.md
+user_guides/modeling_algos/modeling_algos.md
+user_guides/visualization/visualization.md
+user_guides/iges/iges.md
+user_guides/step/step.md
+user_guides/xde/xde.md
+user_guides/ocaf/ocaf.md
+user_guides/tobj/tobj.md
+user_guides/shape_healing/shape_healing.md
+user_guides/draw_test_harness/draw_test_harness.md
+user_guides/wok/wok.md
+
+dev_guides/dev_guides.md
+dev_guides/wok/wok.md
+dev_guides/cdl/cdl.md
+dev_guides/tests/tests.md
+dev_guides/documentation/documentation.md
+
+dev_guides/building/automake.md
+dev_guides/building/cmake.md
+dev_guides/building/code_blocks.md
+dev_guides/building/msvc.md
+dev_guides/building/xcode.md
+
+overview/license.md
\ No newline at end of file
--- /dev/null
+License {#occt_pubic_license}
+=======
+
+## Open CASCADE Technology Public License
+
+*License version: 6.6* @htmlonly<br />@endhtmlonly
+*March, 2013*
+
+Open CASCADE S.A.S. releases and makes publicly available the source code of the software Open CASCADE Technology to the free software development community under the terms and conditions of this license.
+
+It is not the purpose of this license to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this license has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice.
+
+
+Please read this license carefully and completely before downloading this software. By downloading, using, modifying, distributing and sublicensing this software, you indicate your acceptance to be bound by the terms and conditions of this license. If you do not want to accept or cannot accept for any reasons the terms and conditions of this license, please do not download or use in any manner this software.
+
+### 1. Definitions
+
+Unless there is something in the subject matter or in the context inconsistent therewith, the capitalized terms used in this License shall have the following meaning.
+
+"Applicable Intellectual Property Rights" means (a) with respect to the Initial Developer, any rights under patents or patents applications or other intellectual property rights that are now or hereafter acquired, owned by or assigned to the Initial Developer and that cover subject matter contained in the Original Code, but only to the extent necessary to use, reproduce, modify, distribute or sublicense the Original Code without infringement; and (b) with respect to You or any Contributor, any rights under patents or patents applications or other intellectual property rights that are now or hereafter acquired, owned by or assigned to You or to such Contributor and that cover subject matter contained in Your Modifications or in such Contributor's Modifications, taken alone or in combination with Original Code.
+
+"Contributor" means each individual or legal entity that creates or contributes to the creation of any Modification, including the Initial Developer.
+
+"Derivative Program": means a new program combining the Software or portions thereof with other source code not governed by the terms of this License.
+
+"Initial Developer": means Open CASCADE S.A.S., with main offices at 1, place des Frères Montgolfier, 78280 Guyancourt, France.
+
+"Modifications": mean any addition to, deletion from or change to the substance or the structure of the Software. When source code of the Software is released as a series of files, a Modification is: (a) any addition to, deletion from or change to the contents of a file containing the Software or (b) any new file or other representation of computer program statements that contains any part of the Software. By way of example, Modifications include any debug of, or improvement to, the Original Code or any of its components or portions as well as its next versions or releases thereof.
+
+"Original Code": means (a) the source code of the software Open CASCADE Technology originally made available by the Initial Developer under this License, including the source code of any updates or upgrades of the Original Code and (b) the object code compiled from such source code and originally made available by Initial Developer under this License.
+
+"Software": means the Original Code, the Modifications, the combination of Original Code and any Modifications or any respective portions thereof.
+
+"You" or "Your": means an individual or a legal entity exercising rights under this License.
+
+
+### 2. Acceptance of license
+
+By using, reproducing, modifying, distributing or sublicensing the Software or any portion thereof, You expressly indicate Your acceptance of the terms and conditions of this License and undertake to act in accordance with all the provisions of this License applicable to You.
+
+
+### 3. Scope and purpose
+
+This License applies to the Software and You may not use, reproduce, modify, distribute, sublicense or circulate the Software, or any portion thereof, except as expressly provided under this License. Any attempt to otherwise use, reproduce, modify, distribute or sublicense the Software is void and will automatically terminate Your rights under this License.
+
+
+### 4. Contributor license
+
+Subject to the terms and conditions of this License, the Initial Developer and each of the Contributors hereby grant You a world-wide, royalty-free, irrevocable and non-exclusive license under the Applicable Intellectual Property Rights they own or control, to use, reproduce, modify, distribute and sublicense the Software provided that:
+
+You reproduce in all copies of the Software the copyright and other proprietary notices and disclaimers of the Initial Developer as they appear in the Original Code and attached hereto as Schedule "A" and any other notices or disclaimers attached to the Software and keep intact all notices in the Original Code that refer to this License and to the absence of any warranty;
+You include a copy of this License with every copy of the Software You distribute;
+If you distribute or sublicense the Software (as modified by You or on Your behalf as the case may be), You cause such Software to be licensed as a whole, at no charge, to all third parties, under the terms and conditions of the License, making in particular available to all third parties the source code of the Software;
+You document all Your Modifications, indicate the date of each such Modifications, designate the version of the Software You used, prominently include a file carrying such information with respect to the Modifications and duplicate the copyright and other proprietary notices and disclaimers attached hereto as Schedule "B" or any other notices or disclaimers attached to the Software with your Modifications.
+
+For greater certainty, it is expressly understood that You may freely create Derivative Programs (without any obligation to publish such Derivative Program) and distribute same as a single product. In such case, You must ensure that all the requirements of this License are fulfilled for the Software or any portion thereof.
+
+
+### 5. Your license
+
+You hereby grant all Contributors and anyone who becomes a party under this License a world-wide, non-exclusive, royalty-free and irrevocable license under the Applicable Intellectual Property Rights owned or controlled by You, to use, reproduce, modify, distribute and sublicense all Your Modifications under the terms and conditions of this License.
+
+
+### 6. Software subject to license
+
+Your Modifications shall be governed by the terms and conditions of this License. You are not authorized to impose any other terms or conditions than those prevailing under this License when You distribute and/or sublicense the Software, save and except as permitted under Section 7 hereof.
+
+
+### 7. Additional terms
+
+You may choose to offer, on a non-exclusive basis, and to charge a fee for any warranty, support, maintenance, liability obligations or other rights consistent with the scope of this License with respect to the Software (the "Additional Terms") to the recipients of the Software. However, You may do so only on Your own behalf and on Your sole and exclusive responsibility. You must obtain the recipient's agreement that any such Additional Terms are offered by You alone, and You hereby agree to indemnify, defend and hold the Initial Developer and any Contributor harmless for any liability incurred by or claims asserted against the Initial Developer or any Contributors with respect to any such Additional Terms.
+
+
+### 8. Disclaimer of warranty
+
+The Software is provided under this License on an "as is" basis, without warranty of any kind, including without limitation, warranties that the Software is free of defects, merchantable, fit for a particular purpose or non-infringing. The entire risk as to the quality and performance of the Software is with You.
+
+
+### 9. Liability
+
+Under no circumstances shall You, the Initial Developer or any Contributor be liable to any person for any direct or indirect damages of any kind including, without limitation, damages for loss of goodwill, loss of data, work stoppage, computer failure or malfunction or any and all other commercial damages or losses resulting from or relating to this License or indirectly to the use of the Software.
+
+
+### 10. Trademark
+
+This License does not grant any rights to use the trademarks, trade names and domain names "MATRA", "EADS Matra Datavision", "CAS.CADE", "Open CASCADE", "opencascade.com" and "opencascade.org" or any other trademarks, trade names or domain names used or owned by the Initial Developer.
+
+
+### 11. Copyright
+
+The Initial Developer retains all rights, title and interest in and to the Original Code. You may not remove the copyright © notice which appears when You download the Software.
+
+
+### 12. Term
+
+This License is granted to You for a term equal to the remaining period of protection covered by the intellectual property rights applicable to the Original Code.
+
+
+### 13. Termination
+
+In case of termination, as provided in Section 3 above, You agree to immediately stop any further use, reproduction, modification, distribution and sublicensing of the Software and to destroy all copies of the Software that are in Your possession or control. All sublicenses of the Software which have been properly granted prior to termination shall survive any termination of this License. In addition, Sections 5, 8 to 11, 13.2 and 15.2 of this License, in reason of their nature, shall survive the termination of this License for a period of fifteen (15) years.
+
+
+### 14. Versions of the license
+
+The Initial Developer may publish new versions of this License from time to time. Once Original Code has been published under a particular version of this License, You may choose to continue to use it under the terms and conditions of that version or use the Original Code under the terms of any subsequent version of this License published by the Initial Developer.
+
+
+### 15. Miscellaneous
+
+#### 15.1 Relationship of Parties
+
+This License will not be construed as creating an agency, partnership, joint venture or any other form of legal association between You and the Initial Developer, and You will not represent to the contrary, whether expressly, by implication or otherwise.
+
+#### 15.2 Independent Development
+
+Nothing in this License will impair the Initial Developer's right to acquire, license, develop, have others develop for it, market or distribute technology or products that perform the same or similar functions as, or otherwise compete with, Modifications, Derivative Programs, technology or products that You may develop, produce, market or distribute.
+
+#### 15.3 Severability
+
+If for any reason a court of competent jurisdiction finds any provision of this License, or portion thereof, to be unenforceable, that provision of the License will be enforced to the maximum extent permissible so as to effect the economic benefits and intent of the parties, and the remainder of this License will continue in full force and extent.
+
+
+@htmlonly<center>@endhtmlonly
+#### END OF THE TERMS AND CONDITIONS OF THIS LICENSE
+
+Open CASCADE S.A.S. is a French société par actions simplifiée having its main offices at 1, place in Frères Montgolfier, 78280 Guyancourt, France. Its web site is located at the following address http://www.opencascade.com
+
+
+#### Open CASCADE Technology Public License
+
+#### Schedule "A"
+
+The content of this file is subject to the Open CASCADE Technology Public License Version 6.5 (the "License").
+You may not use the content of this file except in compliance with the License.
+Please obtain a copy of the License at http://www.opencascade.org and read it completely before using this file. The Initial Developer of the Original Code is Open CASCADE S.A.S., with main offices at 1, place des Frères Montgolfier, 78280 Guyancourt, France. The Original Code is copyright © Open CASCADE S.A.S., 2001. All rights reserved.
+
+"The Original Code and all software distributed under the License are distributed on an "AS IS" basis, without warranty of any kind, and the Initial Developer hereby disclaims all such warranties, including without limitation, any warranties of merchantability, fitness for a particular purpose or non-infringement.
+
+Please see the License for the specific terms and conditions governing rights and limitations under the License".
+
+#### End of Schedule "A"
+
+
+#### Open CASCADE Technology Public License
+
+#### Schedule "B"
+
+"The content of this file is subject to the Open CASCADE Technology Public License Version 6.5 (the "License"). You may not use the content of this file except in compliance with the License. Please obtain a copy of the License at http://www.opencascade.org and read it completely before using this file. The Initial Developer of the Original Code is Open CASCADE S.A.S., with main offices at 1, place des Frères Montgolfier, 78280 Guyancourt, France. The Original Code is copyright © Open CASCADE S.A.S., 2001. All rights reserved.
+
+Modifications to the Original Code have been made by ________________________. Modifications are copyright © [Year to be included]. All rights reserved.
+
+The software Open CASCADE Technology and all software distributed under the License are distributed on an "AS IS" basis, without warranty of any kind, and the Initial Developer hereby disclaims all such warranties, including without limitation, any warranties of merchantability, fitness for a particular purpose or non-infringement. Please see the License for the specific terms and conditions governing rights and limitations under the License".
+
+#### End of Schedule "B"
+
+@htmlonly</center>@endhtmlonly
\ No newline at end of file
--- /dev/null
+Overview {#mainpage}
+========
+
+@section OCCT_OVW_SECTION_1 Welcome
+
+Welcome to Open CASCADE Technology version 6.6.0, a minor release,
+which introduces a number of new features and improved traditional
+functionality along with some changes over the previous maintenance release 6.5.5.
+
+This release makes Open CASCADE Technology even a more powerful and stable
+development platform for 3D modeling and numerical simulation applications.
+
+Open CASCADE Technology 6.6.0 is a full-featured package that allows developing
+applications on Windows and Linux platforms.
+
+@htmlonly<center>@endhtmlonly http://www.opencascade.org
+
+
+
+Copyright © 2001-2013 OPEN CASCADE S.A.S.
+
+
+
+@htmlonly</center>@endhtmlonly
+
+@section OCCT_OVW_SECTION_2 Copyrights
+
+Copyright© 2001-2013 by OPEN CASCADE S.A.S. All rights reserved.
+
+ Trademark information
+----------------------
+
+You are hereby informed that all software is a property of its respective authors and is protected by
+international and domestic laws on intellectual property and trademarks.
+Should you need further information, please directly contact the authors.
+
+CAS.CADE and Open CASCADE are registered trademarks of OPEN CASCADE S.A.S.
+
+ Acknowledgement
+------------------
+
+The following parties are acknowledged for producing tools which are used within
+Open CASCADE Technology libraries or for release preparation.
+
+You are hereby informed that all rights to the software listed below belong to its respective
+authors and such software may not be freely available and/or be free of charge for any kind
+of use or purpose. We strongly recommend that you carefully read the license of these products
+and, in case you need any further information, directly contact their authors.
+
+**Qt** is a cross-platform application framework that is widely used for developing application software
+with graphical user interface (GUI). Qt is free and open source software distributed under
+the terms of the GNU Lesser General Public License. In OCCT Qt is used for programming samples.
+If you need further information on Qt, please, refer to Qt Homepage (qt.digia.com).
+
+**Tcl** is a high-level programming language. Tk is a graphical user interface (GUI) toolkit,
+with buttons, menus, listboxes, scrollbars, and so on. Taken together Tcl and Tk provide a solution
+to develop cross-platform graphical user interfaces with a native look and feel. Tcl/Tk is under copyright by
+Scriptics Corp., Sun Microsystems, and other companies. However, Tcl/Tk is an open source, and
+the copyright allows you to use, modify, and redistribute Tcl/Tk for any purpose, without an
+explicit license agreement and without paying any license fees or royalties.
+To use Tcl/Tk, please refer to the Licensing Terms (http://www.tcl.tk/software/tcltk/license.html).
+
+**Robert Boehne** has developed **GNU Autoconf**, **Automake** and **Libtool** scripts and makefiles
+for the Open CASCADE project http://sourceforge.net/projects/autoopencas/,
+which became an initial groundwork for the build scripts based on respective GNU tools
+(autoconf, automake and libtool) in Open CASCADE Technology version 4.0.
+These scripts are now maintained by the OPEN CASCADE company.
+
+**GL2PS** is developed by Christophe Geuzaine and others. It is OpenGL to PostScript printing library.
+The library is licensed under GL2PS LICENSE http://www.geuz.org/gl2ps/COPYING.GL2PS Version 2, November 2003.
+
+**FreeType 2** is developed by Antoine Leca, David Turner, Werner Lemberg and others.
+It is a software font engine that is designed to be small, efficient, highly customizable and
+portable while capable of producing high-quality output (glyph images). This product
+can be used in graphic libraries, display servers, font conversion tools,
+text image generation tools, and many other products.
+
+FreeType 2 is released under two open-source licenses: BSD-like FreeType License and the GPL.
+
+**Intel® Threading Building Blocks (TBB)** offers a rich and complete approach to expressing parallelism in a C++ program.
+It is a library that helps you to take advantage of multi-core processor performance without having to be a threading expert.
+Threading Building Blocks is not just a threads-replacement library. It represents a higher-level, task-based parallelism that
+abstracts platform details and threading mechanisms for scalability and performance.
+TBB is available under GPLv2 license with the runtime exception.
+
+Open CASCADE Technology WOK module on Windows also makes use of LGPL-licensed C routines * regexp and getopt, taken from GNU C library.
+
+**Doxygen** (Copyright © 1997-2010 by Dimitri van Heesch) is open source documentation system for
+C++, C, Java, Objective-C, Python, IDL, PHP and C#. This product is used in Open CASCADE Technology
+for automatic creation of Technical Documentation from C++ header files.
+If you need further information on Doxygen, please refer to http://www.stack.nl/~dimitri/doxygen/index.html.
+
+**Graphviz** is open source graph visualization software developed by John Ellson, Emden Gansner, Yifan Hu and Arif Bilgin.
+Graph visualization is representiation of structured information as diagrams of abstract graphs and networks.
+This product is used together with Doxygen in Open CASCADE Technology for automatic creation of Technical Documentation
+(generation of dependency graphs). Current versions of Graphviz are licensed on an open source
+basis only under The Eclipse Public License (EPL) (http://www.graphviz.org/License.php).
+
+**Inno Setup** is a free script-driven installation system created in CodeGear Delphi by Jordan Russell.
+In OCCT Inno Setup is used to create Installation Wizard on Windows.
+It is licensed under Inno Setup License (http://www.jrsoftware.org/files/is/license.txt).
+
+**FreeImage** is an Open Source library supporting popular graphics image formats, such as PNG, BMP, JPEG, TIFF
+and others used by multimedia applications. This library is developed by Hervé Drolon and Floris van den Berg.
+FreeImage is easy to use, fast, multithreading safe, compatible with all 32-bit or 64-bit versions of Windows,
+and cross-platform (works both with Linux and Mac OS X). FreeImage is licensed under the
+GNU General Public License, version 2.0 (GPLv2) and
+the FreeImage Public License (FIPL) (http://freeimage.sourceforge.net/freeimage-license.txt).
+
+Adobe Systems, Inc. provides **Adobe Acrobat Professional**, which is a software to view, create, manipulate,
+print and manage files in Portable Document Format (PDF).
+This product is used in OCCT for the development and update of User's Guides.
+
+The same developer provides **Robohelp HTML** that allows developing online Help for applications that are run on the Web and on Intranets.
+**Robohelp HTML X5.0.2** is used in OCCT for the development and update of OCCT Overview.
+
+**Linux** is a registered trademark of Linus Torvalds.
+
+**Windows** is a registered trademark of Microsoft Corporation in the United States and other countries.
+
+**Mac** and the Mac logo are trademarks of Apple Inc., registered in the U.S. and other countries.
+
+
+@section OCCT_OVW_SECTION_3 Introduction
+
+
+This document is just an introduction to Open CASCADE Technology (OCCT) dealing with
+compatibility and installation issues and providing a general description of OCCT modules
+and other features. All modules and development tools are described in User's Guides, available in
+Adobe Portable Document Format (PDF). To read this format, you need Adobe Acrobat Reader,
+which is a freeware and can be downloaded from the Adobe site.
+All user guides can be accessed directly from this help.
+
+Alongside with PDF User Guides, OCCT suggests its users full reference documentation on all
+implementation classes automatically generated by Doxygen software.
+This Doxygen generated documentation is supplied in the form of a separate package,
+in a usual html file format.
+
+Reference documentation is presented in **Modules --> Toolkits --> Packages --> Classes**
+logic structure with cross-references to all OCCT classes and complete in-browser search by all classes.
+
+**Recommendation for generation of reference documentation**
+
+Reference documentation can be generated by OCCT binary WOK package that
+is available for downloading from www.opencascade.org and dev.opencascade.org sites.
+
+Prerequisites:
+
+ * Doxygen version 1.7.4 or higher
+ * Graphviz version 2.28.0 or higher
+
+Run WOK (cd \<WOK_INSTALL_DIR\>/site folder):
+
+* Using WOK TCL shell:
+ > wok_tclsh.sh
+
+* Using Emacs editor:
+ > wok_emacs.sh
+
+In the WOK prompt, step into your workbench:
+
+ >wokcd <your workbench>
+
+In your workbench, use **wgendoc** command with –h argument to get information about arguments of **wgendoc** command:
+
+ >wgendoc -h
+
+then run **wgendoc** command with required arguments
+
+e.g., wgendoc –output=d:/occt/doc {–m=Draw Visualization} -chm
+
+
+@section OCCT_OVW_SECTION_4 Installation
+
+Open CASCADE Technology can be installed with binaries precompiled by
+Visual C++ 2008 using Installation Procedure under Windows platform only
+
+The source package and the building tools are available for self-dependent
+preparation binary files on Unix and Windows platforms.
+
+@subsection OCCT_OVW_SECTION_4_1 Windows
+
+**Recommendation:**
+
+If you have a previous version of OCCT installed on your station,
+and you do not plan to use it along with the new version, you might want to uninstall
+the previous version (using Control Panel, Add/Remove Programs) before
+the installation of this new version, to avoid possible problems
+(conflict of system variables, paths, etc).
+
+**Attention:** For full installation OCCT requires approximately 650 Mb of disk space,
+but during the installation process you will need 1,2 Gb of free disk space.
+
+OCCT installation with reference documentation requires 1,4 Gb on disk.
+
+ * Download the OCCT installer from OPEN CASCADE web site using the link. you have been provided
+ * Launch the installer and follow the instructions.
+
+### Third-party tools
+
+
+The includes and binaries of third-party libraries necessary for building and launching
+OCCT are included into binary distribution (built with Visual C++ 2008).
+To recompile OCCT libraries with other Visual C++ versions,
+it is necessary to install headers and libraries of these third-party products.
+
+The recommended way to do this is to download each of the third-party tools from its web site
+and build it using the relevant tools. For additional convenience of the users,
+OPEN CASCADE also provides the documents with recommendations on building
+third-party products from source files.
+
+When the installation is complete, you will find the following directories
+(some might be absent in case of custom installation):
+
+
+
+### Description of directory tree
+
+
+ * **3rdparty** * This folder contains third-party products necessary to compile and use OCCT as well as start sample applications with Visual C++ 2008;
+ * **ros/adm** * This folder contains administration files, which allow rebuilding OCCT;
+ * **ros/adm/cmake** * This folder contains files of CMake building procedure;
+ * **ros/adm/msvc** * This folder contains Visual Studio projects for Visual C++ 2005, 2008 and 2010, which allow rebuilding OCCT under Windows platform in 32 and 64-bit mode;
+ * **ros/data** * This folder contains CAD files in different formats, which can be used to test the OCCT functionalities;
+ * **ros/doc** * This folder contains OCCT Overview documentation;
+ * **ros/drv** * This folder contains source files generated by WOK (private header files and instantiations of generic classes);
+ * **ros/inc** * This folder contains all OCCT header files;
+ * **ros/samples** * This folder contains sample applications.
+ * **ros/src** * This folder contains OCCT source files. They are organized in folders, one per development unit;
+ * **ros/tests** * This folder contains scripts for OCCT testing.
+ * **ros/win32/vc9** * This folder contains executable and library files built in optimize mode for Windows platform by Visual C++ 2008;
+
+
+@subsection OCCT_OVW_SECTION_4_2 System Environment Variables
+
+To run any Open CASCADE Technology application you need to set the environment variables.
+
+### On Windows
+
+
+You can define the environment variables with env.bat script located in the
+OpenCACADE<version_number>/ros folder. This script accepts two arguments to be used:
+the version of Visual Studio (vc8, vc9, or vc10) and the architecture (win32 or win64).
+
+The additional environment settings necessary for compiling OCCT libraries and samples
+by Microsoft Visual Studio can be set using script custom.bat located in the same folder.
+You might need to edit this script to correct the paths to third-party libraries
+if they are installed on your system in a non-default location.
+
+Script msvc.bat can be used with the same arguments for immediate launch of Visual Studio for (re)compiling OCCT.
+
+### On Unix
+
+
+ If OCCT was built by Code::Blocks, you can define the environment variables with env_cbp.sh or custom_cbp.sh script.
+
+ If OCCT was built by Automake, you can define the environment variables with env_amk.sh or custom_amk.sh script.
+
+The scripts are located in the OpenCACADE<version_number>/ros folder of the source package.
+
+
+### Description of system variables:
+
+
+ * **CASROOT** is used to define the root directory of Open CASCADE Technology;
+ * **PATH** is required to define the path to OCCT binaries and 3rdparty folder;
+ * **LD_LIBRARY_PATH** is required to define the path to OCCT libraries (on UNIX platforms only);
+ * **MMGT_OPT** if set to 1, the memory manager performs optimizations as described below; if set to 2,
+ Intel ® TBB optimized memory manager is used; if 0 (default), every memory block is allocated
+ in C memory heap directly (via malloc() and free() functions).
+ In the latter case, all other options except MMGT_CLEAR and MMGT_REENTRANT are ignored;
+ * **MMGT_CLEAR** if set to 1 (default), every allocated memory block is cleared by zeros;
+ if set to 0, memory block is returned as it is;
+ * **MMGT_CELLSIZE** defines the maximal size of blocks allocated in large pools of memory. Default is 200;
+ * **MMGT_NBPAGES** defines the size of memory chunks allocated for small blocks in pages
+ (operating-system dependent). Default is 10000;
+ * **MMGT_THRESHOLD** defines the maximal size of blocks that are recycled internally
+ instead of being returned to the heap. Default is 40000;
+ * **MMGT_MMAP** when set to 1 (default), large memory blocks are allocated using
+ memory mapping functions of the operating system; if set to 0,
+ they will be allocated in the C heap by malloc();
+ * **MMGT_REENTRANT** when set to 1 (default), all calls to the
+ optimized memory manager will be secured against possible simultaneous access from different execution threads.
+
+This variable should be set in any multithreaded application that uses
+an optimized memory manager (MMGT_OPT=1) and has more than one thread
+potentially calling OCCT functions. If set to 0, OCCT memory management and
+exception handling routines will skip the code protecting from possible concurrency
+in multi-threaded environment. This can yield some performance gain in some applications,
+but can lead to unpredictable results if used in a multithreaded application;
+
+**Special note:** for applications that use OCCT memory manager from more than one thread,
+on multiprocessor hardware, it is recommended to use options MMGT_OPT=2 and MMGT_REENTRANT=1.
+
+ * **CSF_LANGUAGE** is required to define the default language of messages;
+ * **CSF_EXCEPTION_PROMPT** – if defined and set to 1 then a diagnostic message is displayed in case of an exception;
+ * **CSF_MDTVFontDirectory** accesses the fonts that can be used in OCCT;
+ * **CSF_MDTVTexturesDirectory** defines the directory for available textures when using texture mapping;
+ * **CSF_UnitsDefinition** and **CSF_UnitsLexicon** are required by programs considering units;
+ * **CSF_SHMessage** is required in order to define the path to the messages file for *ShapeHealing*;
+ * **CSF_XSMessage** is required in order to define the path to the messages file for **STEP** and **IGES** translators;
+ * **CSF_StandardDefaults** and **CSF_PluginDefaults** are required in order to maintain CASCADE Persistence mechanism to make possible any open/save operations with OCAF documents;
+ * **CSF_StandardLiteDefaults** is required in order to maintain *OCCT Persistence mechanism* to make possible any open/save operations with Lite OCAF documents;
+ * **CSF_XCAFDefaults** any open/save operations for **XDE** documents;
+ * **CSF_GraphicShr** is required to define the path to the *TKOpenGl* library;
+ * **CSF_IGESDefaults** and **CSF_STEPDefaults** are required for **IGES** and **STEP** translators correspondingly in order to define the path to the resource files;
+ * **CSF_XmlOcafResource** is required in order to set the path to **XSD** resources, which defines XML grammar.
+
+As part of XML persistence support, these definitions can be used by end users
+in XML validators or editors, together with persistent XmlOcaf documents;
+
+* **CSF_MIGRATION_TYPES** is required in order to read documents that contain old data types, such as *TDataStd_Shape*;
+* **TCLLIBPATH**, **TCL_LIBRARY**, **TK_LIBRARY** and **TIX_LIBRARY** are required to allow work with **DRAW** and **WOK**.
+
+
+@section OCCT_OVW_SECTION_5 Requirements
+
+@subsection OCCT_OVW_SECTION_5_1 Linux Intel
+
+| Operating System | 32/64-bit: Debian: 4.0, Mandriva: 2010* |
+| :--------------------------------------------- | :------------------------------------------------------------------------------------------------- |
+| Minimum memory | 512 Mb, 1 Gb recommended |
+| Free disk space (complete installation) | For full installation Open CASCADE Technology requires 600 Mb of disk space. |
+| Minimum swap space | 500 Mb |
+| Video card | GeForce, |
+| | The following versions of GeForce drivers are recommended: |
+| | 64-bit Version: 100.14.19 or later http://www.nvidia.com/object/linux_display_amd64_100.14.19.html |
+| | 32-bit Version: 100.14.19 or later http://www.nvidia.com/object/linux_display_ia32_100.14.19.html |
+| Graphic library | OpenGL 1.1+ (OpenGL 1.5+ is recommended) |
+| C++ | GNU gcc 4.0. * 4.3.2. |
+| TCL (for testing tools) | Tcltk 8.5 or 8.6 |
+| | http://www.tcl.tk/software/tcltk/8.6.html |
+| Qt (for demonstration tools) | Qt 4.6.2 http://qt.digia.com/downloads |
+| Freetype (OCCT Text rendering) | freetype-2.4.10 |
+| | http://sourceforge.net/projects/freetype/files/ |
+| FreeImage (Support of common graphic formats ) | FreeImage 3.14.1 |
+| | http://sourceforge.net/projects/freeimage/files/Source%20Distribution/ |
+| gl2ps (Export contents of OCCT | gl2ps-1.3.5 |
+| viewer to vector graphic file) | http://geuz.org/gl2ps/ |
+| TBB (optional tool for parallelized | TBB 3.x or 4.x |
+| version of BRepMesh component) | http://www.threadingbuildingblocks.org/ |
+
+@subsection OCCT_OVW_SECTION_5_2 Windows Intel
+
+| Operating System | 32/64-bit: 8/ 7 SP1 / VISTA SP2 /XP SP3 |
+| :--------------------------------------------- | :----------------------------------------------------------------------------------------------- |
+| Minimum memory | 512 Mb, 1 Gb recommended |
+| Free disk space | For full installation Open CASCADE Technology requires 650 Mb of disk space. |
+| (complete installation) | but during the process of installation you will need 1,2 Gb of free disk space. |
+| Minimum swap space | 500 Mb |
+| Video card | GeForce, |
+| | Version 266.58 WHQL or later is recommended:http://www.nvidia.com/Download/index.aspx |
+| Graphic library | OpenGL 1.1+ (OpenGL 1.5+ is recommended) |
+| C++ | Microsoft Visual Studio .NET 2005 SP1 with all security updates |
+| | Microsoft Visual Studio .NET 2008 SP1* |
+| | Microsoft Visual Studio .NET 2010 |
+| | Microsoft Visual Studio .NET 2012 |
+| TCL (for testing tools) | ActiveTcl 8.5 or 8.6 |
+| | http://www.activestate.com/activetcl/downloads |
+| Qt (for demonstration tools) | Qt 4.6.2 http://qt.digia.com/downloads |
+| Freetype (OCCT Text rendering) | freetype-2.4.10 |
+| | http://sourceforge.net/projects/freetype/files/ |
+| FreeImage (Support of common graphic formats ) | FreeImage 3.14.1 |
+| | http://sourceforge.net/projects/freeimage/files/Source%20Distribution/ |
+| gl2ps (Export contents of OCCT | gl2ps-1.3.5 |
+| viewer to vector graphic file) | http://geuz.org/gl2ps/ |
+| TBB (optional tool for parallelized | TBB 3.x or 4.x |
+| version of BRepMesh component) | http://www.threadingbuildingblocks.org/ |
+
+@subsection OCCT_OVW_SECTION_5_3 MAC OS X
+
+| Operating System | Requires Mac OS X 10.6.8 Snow Leopard / 10.7 Lion |
+| :--------------------------------------------- | :----------------------------------------------------------------------------------------------- |
+| Minimum memory | 512 Mb, 1 Gb recommended |
+| Free disk space (complete installation) | For full installation Open CASCADE Technology requires 600 Mb of disk space. |
+| Minimum swap space | 500 Mb |
+| Graphic library | OpenGL 1.1+ (OpenGL 1.5+ is recommended) |
+| C++ | XCode 3.2 or newer (4.x is recommended) |
+| TCL (for testing tools) | Tcltk 8.5 or 8.6 |
+| | http://www.tcl.tk/software/tcltk/8.6.html |
+| Qt (for demonstration tools) | Qt 4.6.2 http://qt.digia.com/downloads |
+| Freetype (OCCT Text rendering) | freetype-2.4.10 |
+| | http://sourceforge.net/projects/freetype/files/ |
+| FreeImage (Support of common graphic formats ) | FreeImage 3.14.1 |
+| | http://sourceforge.net/projects/freeimage/files/Source%20Distribution/ |
+| gl2ps (Export contents of OCCT | gl2ps-1.3.5 |
+| viewer to vector graphic file) | http://geuz.org/gl2ps/ |
+| TBB (optional tool for parallelized | TBB 3.x or 4.x |
+| version of BRepMesh component) | http://www.threadingbuildingblocks.org/ |
+
+
+@section OCCT_OVW_SECTION_6 Release Notes
+
+
+Open CASCADE Technology latest version
+@htmlonly
+<a href="http://occtrel.nnov.opencascade.com/OpenCASCADE6.6.0/doc/release_notes.pdf">Release Notes</a>
+@endhtmlonly (PDF)
+
+
+@section OCCT_OVW_SECTION_7 Getting Started
+
+
+@subsection OCCT_OVW_SECTION_7_1 Draw Test Harness
+
+Draw is a command interpreter based on TCL and a graphical system used for testing and demonstrating OCCT modeling libraries.
+
+Draw can be used interactively to create, display and modify objects such as curves, surfaces and topological shapes.
+
+
+
+Scripts can be written to customize Draw and perform tests.
+New types of objects and new commands can be added using C++ programming language.
+
+Draw contains:
+
+ * A command interpreter based on TCL command language.
+ * A 2D an 3D graphic viewer with support of operations such as zoom, pan, rotation and full-screen views.
+ * An optional set of geometric commands to create and modify curves and surfaces and to use OCCT geometry algorithms.
+ * A set of topological commands to create and modify BRep shapes and to use OCCT topology algorithms.
+ * A set of graphic commands for view and display operations including Mesh Visualization Service.
+ * A set of Application framework commands for handling of files and attributes.
+ * A set of Data Exchange commands for translation of files from various formats (IGES,STEP) into OCCT shapes.
+ * A set of Shape Healing commands: check of overlapping edges, approximation of a shape to BSpline, etc.
+
+You can add new custom test harness commands to Draw in order to test
+or demonstrate a new functionality, which you are developing.
+
+Currently DRAW Test Harness is a single executable called DRAWEXE.
+
+Commands grouped in toolkits can be loaded at run-time thereby implementing dynamically loaded plug-ins.
+Thus you can work only with the commands that suit your needs adding
+the commands dynamically without leaving the Test Harness session.
+
+Declaration of available plug-ins is done through special resource file(s).
+The pload command loads the plug-in in accordance with
+the specified resource file and activates the commands implemented in the plug-in.
+
+The whole process of using the plug-in mechanism as well as the instructions for extending Test Harness is described in the
+@htmlonly
+<a href="http://occtrel.nnov.opencascade.com/OpenCASCADE6.6.0/doc/OCCT_Tests.pdf">User's Guide/</a>
+@endhtmlonly
+
+Draw Test Harness provides an environment for OCCT automated testing system. Please, consult its
+@htmlonly
+<a href="http://occtrel.nnov.opencascade.com/OpenCASCADE6.6.0/doc/OCCT_Tests.pdf">User's Guide /</a>
+@endhtmlonly
+for details.
+
+Remarks:
+
+* The DRAWEXE executable is delivered with the installation procedure on Windows platform only.
+* To start it, launch DRAWEXE executable from Open CASCADE Technology//Draw Test Harness item of the Start\\Programs menu.
+
+@subsection OCCT_OVW_SECTION_7_2 Experimenting with Draw Test Harness
+
+ Running Draw
+------------
+
+**On Linux:**
+
+1. If OCCT was built by Code::Blocks * use $CASROOT/draw_cbp.sh file to launch DRAWEXE executable;
+2. If OCCT was built by Automake * use $CASROOT/draw_amk.sh file to launch DRAWEXE executable;
+
+Draw[1]> prompt appears in the command window
+
+Type pload ALL
+
+**On Windows:**
+
+Launch Draw executable from Open CASCADE Technology\\Test Harness\\Draw Test Harness
+item of the Start\\Programs menu or Use $CASROOT\\draw.bat file to launch DRAWEXE executable.
+
+Draw[1]> prompt appears in the command window
+
+Type pload ALL
+
+**Creating your first geometric objects**
+
+1. In the command window, type axo to create an axonometric view
+2. Type box b -10 -10 -10 20 20 20 to create a cube b of size 20,
+ parallel to the X Y Z axis and centered on the origin.
+ The cube will be displayed in the axonometric view in wireframe mode
+3. Type fit to fill the viewer with the cube
+4. Type pcylinder c 2 30 to create a cylinder c of radius 2 and height 30.
+ The cylinder will be displayed in addition to the cube
+
+**Manipulating the view**
+
+1. Type clear to erase the view
+2. Type donly c to display the cylinder only
+3. Type donly b to display the cube only
+4. Type hlr hlr b to display the cube in the hidden line removal mode
+
+**Running demonstration files**
+
+1. Type cd ..//.. to return to the root directory
+2. Type cd src//DrawResources to reach the DrawResources directory
+3. Type source "Available Demo File" to run the demonstration provided with Open CASCADE
+4. The following demonstration files are available:
+ * DataExchangeDemo.tcl
+ * ModelingDemo.tcl
+ * OCAFDemo.tcl
+ * VisualizationDemo.tcl
+
+**Getting Help**
+
+1. Type help to see all available commands
+2. Type help command-name to find out the arguments for a given command
+
+@subsection OCCT_OVW_SECTION_7_3 Programming Samples
+
+@subsubsection OCCT_OVW_SECTION_7_3_1 MFC
+
+Visual C++ programming samples containing 10 Visual C++ projects
+illustrating how to use a particular module or functionality.
+
+The list of MFC samples:
+
+ * Geometry
+ * Modeling
+ * Viewer2d
+ * Viewer3d
+ * ImportExport
+ * Ocaf
+ * Triangulation
+ * HLR
+ * Animation
+ * Convert
+
+
+
+**Remarks:**
+
+ * MFC samples are available only on Windows platform;
+ * To start a sample use Open CASCADE Technology\\Samples\\Mfc\\ item of the Start\\Programs menu;
+ * Read carefully readme.txt to learn about launching and compilation options.
+
+@subsubsection OCCT_OVW_SECTION_7_3_2 Qt
+
+OCCT contains three samples based on Qt application framework
+
+ Import Export
+-------------
+
+ Import Export programming sample contains 3D Viewer and Import // Export functionality.
+
+
+
+ Tutorial
+---------
+
+The Qt programming tutorial teaches how to use Open CASCADE Technology services to model a 3D object.
+The purpose of the tutorial is not to explain all OCCT classes but
+to help start thinking in terms of the Open CASCADE Technology.
+
+This tutorial assumes that the user has experience in using and setting up C++.
+From the viewpoint of programming, Open CASCADE Technology is designed
+to enhance user's C++ tools with high performance modeling classes, methods and functions.
+The combination of these resources allows creating substantial applications.
+
+**See also:** @subpage overview__tutorial "3D Object Tutorial"
+
+ Voxel
+------
+
+This is a demonstration application showing OCCT voxel models.
+It also includes a set of non-regression tests and other commands
+for testing this functionality (accessible only through TEST pre-processor definition).
+
+**See also:**
+ @htmlonly
+<a href="http://occtrel.nnov.opencascade.com/OpenCASCADE6.6.0/doc/voxels_wp.pdf">Voxels User's guide (PDF)</a>
+@endhtmlonly
+
+**Remarks:**
+
+ * Qt samples are available on all supported platforms;
+ * To start a sample on Windows use Open CASCADE Technology\\Samples\\Qt\\ item of the Start\\Programs menu.
+
+@subsubsection OCCT_OVW_SECTION_7_3_3 C#
+
+C# sample containing 3D Viewer and Import // Export functionality.
+
+
+
+Import:
+
+ * BRep
+ * Iges
+ * Step
+
+Export:
+
+ * Brep
+ * Iges
+ * Step
+ * Stl
+ * Vrml
+
+**Remarks:**
+
+ * C# sample is available only on Windows platform;
+ * It is delivered in source code only and must be built with Microsoft Visual C++ 2005.
--- /dev/null
+Building with Automake {#dev_guides__building__automake}
+======================
+
+This file describes steps to build OCCT libraries from complete source
+archive on Linux with GNU build system (Autotools).
+
+If you are building OCCT from bare sources (as in Git repository), or do some
+changes affecting CDL files, you need to use WOK to re-generate header files
+and build scripts / projects. See file \ref wok "WOK" for instructions.
+
+Before building OCCT, you need to install required third-party libraries; see
+OCCT_Build3rdParty_Linux.pdf for instructions.
+
+Note that during compilation by makefiles on some Linux OS on a station with
+NVIDIA video card you may experience problems because the installation
+procedure of NVIDIA video driver removes library libGL.so included in package
+libMesaGL from directory /usr/X11R6/lib and places this library libGL.so in
+directory /usr/lib. However, libtool expects to find the library in directory
+/usr/X11R6/lib, which causes compilation crash (See /usr/X11R6/lib/libGLU.la).
+
+To prevent this, suggest making links:
+
+ ln -s /usr/lib/libGL.so /usr/X11R6/lib/libGL.so
+ ln -s /usr/lib/libGL.la /usr/X11R6/lib/libGL.la
+
+ 1.In OCCT root folder, launch build_configure script
+
+ This will generate files configure and Makefile.in for your system.
+
+ 2.Go to the directory where OCCT will be built, and run configure to generate
+ makefiles.
+
+ $CASROOT/configure \<FLAGS\>
+
+ Where \<FLAGS\> is a set of options.
+ The following flags are mandatory:
+
+ * --with-tcl= defines location of tclConfig.sh
+ * --with-tk= defines location of tkConfig.sh
+ * --with-freetype= defines location of installed FreeType product
+ * --prefix= defines location for the installation of OCCT binaries
+
+ Additional flags:
+
+ * --with-gl2ps= defines location of installed gl2ps product
+ * --with-freeimage= defines location of installed FreeImage product
+ * --with-tbb-include= defines location of tbb.h
+ * --with-tbb-library= defines location of libtbb.so
+ * --enable-debug= yes: includes debug information, no: does not include debug information
+ * --enable-production= yes: switches code optimization, no: switches off code optimization
+ * --disable-draw - allows OCCT building without Draw.
+
+ If location of FreeImage, TBB, and Gl2Ps is not specified, OCCT will be
+ built without these optional libraries.
+
+
+ Attention: 64-bit platforms are detected automatically.
+
+ Example:
+
+ > ./configure -prefix=/PRODUCTS/occt-6.5.5 --with-tcl=/PRODUCTS/tcltk-8.5.8/lib --with-tk=/PRODUCTS/tcltk-8.5.8/lib --with-freetype=/PRODUCTS/freetype-2.4.10 --with-gl2ps=/PRODUCTS/gl2ps-1.3.5 --with-freeimage=/PRODUCTS/freeimage-3.14.1 --with-tbb-include=/PRODUCTS/tbb30_018oss/include --with-tbb-library=/PRODUCTS/tbb30_018oss/lib/ia32/cc4.1.0_libc2.4_kernel2.6.16.21
+
+ 3.If configure exits successfully, you can build OCCT with make command.
+
+ > make -j8 install
+
+To start DRAW, launch
+
+ > draw.sh
--- /dev/null
+Building with CMake {#dev_guides__building__cmake}
+===================
+
+This file describes steps to build OCCT libraries from complete source package
+with CMake. CMake is free software that can create GNU Makefiles, KDevelop,
+XCode, and Visual Studio project files. Version 2.6 or above of CMake is
+required.
+
+If you are building OCCT from bare sources (as in Git repository), or do some
+changes affecting CDL files, you need to use WOK to re-generate header files
+and build scripts / projects. See file \ref wok "WOK" for instructions.
+
+Before building OCCT, you need to install required third-party libraries; see
+instructions for your platform on Resources page at http://dev.opencascade.org
+
+1. Decide on location of build and install directories.
+
+ The build directory is the one where intermediate files will be created
+ (projects / makefiles, objects, binaries).
+ The install directory is the one where binaries will be installed after
+ build, along with header files and resources required for OCCT use in
+ applications.
+
+ OCCT CMake scripts assume use of separate build and one install directories
+ for each configuration (Debug or Release).
+
+ It is recommended to separate build and install directories from OCCT
+ source directory, for example:
+
+ /user/home/occt/ros - sources
+ /user/home/tmp/occt-build-release - intermediate files (release)
+ /user/home/occt-install-release - installed binaries (release)
+
+2. Run CMake indicating path to OCCT sources (ros subdirectory) and selected build directory.
+ It is recommended to use GUI tools provided by CMake: cmake-gui on Windows
+ and Mac, ccmake on Linux.
+
+ Example:
+
+ Linux> cd /user/home/occt-install-release
+ Linux> ccmake /user/home/occt/ros
+
+3. Run Configure
+
+ You will likely get CMake errors due to missing paths to 3rd-party
+ libraries. This is normal; proceed with configuration as follows.
+
+4. Check parameters shown by CMake, set them in accordance with your
+ environment, and repeat Configure until it runs without error:
+
+ - 3RDPARTY_DIR: path to directory whethe 3rd-party libraries are installed
+ (for the cases when they are not in default locations, or on Windows)
+ - 3RDPARTY_USE_\<library\>: select to use optional libraries
+ - Other options in 3RDPARTY group can be used to fine-tune paths to
+ 3rd-party libraries
+
+ - BUILD_TYPE: configuration to build (Debug or Release)
+ - BUILD_BITNESS: bitness (32 or 64)
+ - BUILD_TOOLKITS: optional string containing list of toolkits to be built
+ in addition to those included in completely built modueles
+ - BUILD_\<module\>: select to build corresponding OCCT module
+
+ - INSTALL_DIR: directory to install OCCT
+ - INSTALL_\<library\>: select to copy corresponding 3rd-party library to OCCT
+ install dir
+
+5. Run Generate
+
+ This will create makefiles or project files for your build system.
+
+6. Build OCCT:
+
+ - on Windows with MSVC: open solution OCCT.sln and build it, when build project INSTALL_ALL explicitly to have binaries and headers installed
+ - on Linux with make files: run 'make install'
+
+
+
\ No newline at end of file
--- /dev/null
+Building with Code::Blocks on Mac OS X {#dev_guides__building__code_blocks}
+======================================
+
+This file describes steps to build OCCT libraries from complete source package
+on Mac OS X with Code::Blocks.
+
+If you are building OCCT from bare sources (as in Git repository), or do some
+changes affecting CDL files, you need to use WOK to re-generate header files
+and build scripts / projects. See file \ref wok "WOK" for instructions.
+
+Before building OCCT, you need to install required third-party libraries; see
+OCCT_Build3rdParty_OSX.pdf for details.
+
+1. Add paths to the mandatory 3rd-party products (Tcl/Tk and FreeType) in file
+ custom.sh located in \<OCCT_ROOT_DIR\>. For this:
+
+ 1.1. Add paths to the includes in variable "CSF_OPT_INC";
+
+ 1.2. Add paths to the binary libraries in variable "CSF_OPT_LIB64";
+
+ All paths should be separated by ":" symbol.
+
+2. Add paths to the optional 3rd-party libraries (TBB, gl2ps and FreeImage)
+ in the aforementioned environment variables "CSF_OPT_INC" and
+ "CSF_OPT_LIB64" from file custom.sh.
+
+ If you want to build OCCT without the optional libraries perform the
+ following steps:
+
+ 2.1 Disable unnecessary library in custom.sh by setting the corresponding
+ variable HAVE_\<LIBRARY_NAME\> to "false".
+
+ export HAVE_GL2PS=false
+
+ 2.2 Remove this library from Linker settings in Code::Blocks for each project
+ that uses it: right click on the required project, choose "Build options",
+ go to "Linker settings" tab in the opened window , select unnecessary
+ libraries and click "Delete" button.
+
+3. Open Terminal application
+
+4. Enter \<OCCT_ROOT_DIR\>:
+
+ cd \<OCCT_ROOT_DIR\>
+
+5. To start Code::Blocks, run the command /codeblocks.sh
+
+6. To build all toolkits, click "Build->Build workspace" in the menu bar.
+
+
+To start DRAWEXE, which has been built with Code::Blocks on Mac OS X, perform
+the following steps:
+
+1. Open Terminal application
+
+2. Enter \<OCCT_ROOT_DIR\>:
+
+ cd \<OCCT_ROOT_DIR\>
+
+3. Run script
+
+ ./draw_cbp.sh cbp [d]
+
+ Option "d" is used if OCCT has been built in Debug mode.
--- /dev/null
+Building with MS Visual C++ {#dev_guides__building__msvc}
+===========================
+
+This file describes steps to build OCCT libraries from complete source
+archive on Windows with MS Visual C++.
+
+If you are building OCCT from bare sources (as in Git repository), or do some
+changes affecting CDL files, you need to use WOK to re-generate header files
+and build scripts / projects. See file \ref wok "WOK" for instructions.
+
+Before building OCCT, you need to install required third-party libraries; see
+OCCT_Build3rdParty_Windows.pdf for instructions.
+
+1. Edit file custom.bat to define environment:
+
+ - VCVER - version of Visual Studio (vc8, vc9, vc10 or vc11),
+ and relevant VCVARS path
+ - ARCH - architecture (32 or 64), affects only PATH variable for execution
+ - HAVE_* - flags to enable or disable use of optional third-party products
+ - CSF_OPT_* - paths to search for includes and binaries of all used
+ third-party products
+
+2. Launch msvc.bat to start Visual Studio with all necessary environment
+ variables defined.
+
+ Note: the MSVC project files are located in folders adm\\msvc\\vc[9-11].
+ Binaries are produced in win32 or win64 folders.
+
+3. Build with Visual Studio
+
+To start DRAW, launch draw.bat.
--- /dev/null
+Building with Xcode {#dev_guides__building__xcode}
+===================
+
+This file describes steps to build OCCT libraries from complete source package
+on Mac OS X with Xcode.
+
+If you are building OCCT from bare sources (as in Git repository), or do some
+changes affecting CDL files, you need to use WOK to re-generate header files
+and build scripts / projects. See file \ref wok "WOK" for instructions.
+
+Before building OCCT, you need to install required third-party libraries; see
+OCCT_Build3rdParty_OSX.pdf for details.
+
+1. Add paths to the mandatory 3rd-party products (Tcl/Tk and FreeType)
+ in file custom.sh located in \<OCCT_ROOT_DIR\>. For this:
+
+ 1.1. Add paths to the includes in variable "CSF_OPT_INC";
+
+ 1.2. Add paths to the binary libraries in variable "CSF_OPT_LIB64";
+
+ All paths should be separated by ":" symbol.
+
+2. Add paths to the optional 3rd-party libraries (TBB, gl2ps and FreeImage)
+ in the aforementioned environment variables "CSF_OPT_INC" and
+ "CSF_OPT_LIB64" from file custom.sh.
+
+ If you want to build OCCT without the optional libraries perform the
+ following steps:
+
+ 2.1 Disable unnecessary library in custom.sh by setting the corresponding
+ variable HAVE_<LIBRARY_NAME> to "false".
+
+ export HAVE_GL2PS=false
+
+ 2.2 Remove this library from Project navigator in Xcode for each project that
+ uses it: choose the required project, right click on the unnecessary
+ library and select "Delete" button.
+
+3. Open Terminal application.
+
+4. Enter \<OCCT_ROOT_DIR\>:
+
+ cd \<OCCT_ROOT_DIR\>
+
+5. To start Xcode, run the command /xcode.sh
+
+6. To build a certain toolkit, select it in "Scheme" drop-down list in Xcode
+ toolbar, press "Product" in the menu and click "Build" button.
+
+ To build the entire OCCT, create a new empty project (select "File ->
+ New -> Project -> "Empty project" in the menu. Input the project name,
+ e.g. "OCCT", click "Next" and "Create" buttons). Drag and drop the "OCCT"
+ folder in the created "OCCT" project in the Project navigator. Select
+ "File -> New -> Target -> Aggregate" in the menu. Enter the project name
+ (e.g. "OCCT") and click "Finish". The "Build Phases" tab will open.
+ Click "+" button to add the necessary toolkits to the target project.
+ It is possible to select all toolkits by pressing "Command+A" combination.
+
+To start DRAWEXE, which has been built with Xcode on Mac OS X, perform the following steps:
+
+1. Open Terminal application
+
+2. Enter \<OCCT_ROOT_DIR\>:
+
+ cd \<OCCT_ROOT_DIR\>
+
+3. Run script
+
+ ./draw_cbp.sh xcd [d]
+
+ Option "d" is used if OCCT has been built in Debug mode.
--- /dev/null
+ Component Definition Language (CDL) {#dev_guides__cdl}
+==============================
+
+@section occt_1819379591_354121062 CDL and Application Architecture
+
+CDL is the component definition language of the Open CASCADE Technology (**OCCT**) programming platform. Some components, which CDL allows you to create, are specific to OCCT application architecture. These and other components, which you can define using CDL include the following:
+
+ * Class (including enumeration, exception)
+ * Package
+ * Schema
+ * Executable
+ * Client.
+A** class** is the fundamental software component in object-oriented development. Because of a very large number of resources used in large-scale applications, the **class **itself is too small to be used as a basic management unit.
+
+So, while the class is the basic data component defined in CDL, this language also provides a way to group classes, **enumerations**, and **exceptions **together – the **package**. A package groups together a number of classes, which have semantic links. For example, a geometry package would contain Point, Line, and Circle classes. A package can also contain enumerations, exceptions, and package methods. In practice, a class name is prefixed with the name of its package e.g. Geom_Circle.
+
+Using the services described in the **packages**, you can construct an **executable**. You can also group together services provided by **packages**.
+
+To save data in a file, you need to define persistent classes. Then, you group these classes in a schema, which provides the necessary read/write tools.
+
+ <table>
+ <tr>
+ <td>
+
+ </td>
+ </tr>
+ <tr>
+ <td>
+
+ </td>
+ <td>
+ 
+ </td>
+ </tr>
+</table>
+Figure 1. Building an Open CASCADE Technology application
+@section occt_1819379591_986437237 2. Introduction to CDL
+@subsection occt_1819379591_98643723721 Purposes of the Language
+You can use CDL to **define data **in the Open CASCADE Technology environment. CDL allows you to define various kinds of data types supporting the application architecture and development methodology, which you envision. CDL is neither an analysis formalism (e.g. Booch methodology) nor a data manipulation language (e.g. C++).
+
+You use CDL in the **design phase **of a development process to define a set of software components which best model the concepts stated in the application specification.
+
+ <table>
+ <tr>
+ <td>
+
+ </td>
+ </tr>
+ <tr>
+ <td>
+
+ </td>
+ <td>
+ 
+ </td>
+ </tr>
+</table>
+
+Figure 2. The Development Process
+
+From a structural point of view, CDL is an object-oriented language. It is centered on the notion of the **class **- a data type, which represents an elementary concept. CDL offers various means of organizing classes, mostly under the fundamental form of **packages**. A package contains a set of classes, which share some semantic relationship. This greatly simplifies your task of managing individual classes when confronted with a very large number of them.
+
+Once you have defined the classes and packages using CDL, you can implement their **methods **- i.e., their functionality - in one of the data manipulation languages supported by the OCCT environment (currently C++).
+
+Even though you can describe classes directly in C++ and save them as header files (.hxx), to do so would forfeit all the advantages of using CDL. These are:
+
+ * Precise, complete, and easy-to-read description of the software components.
+ * Creation of a link with the database; object persistence forms part of the predefined environment of the language.
+ * Multi-language access to the services of an application engine – a specific architectural form created using the CDL tools, which serves as the motor of an application.
+@subsection occt_1819379591_98643723722 Overview of CDL
+
+CDL is an object-oriented language. In other words, it structures a system around data types rather than around the actions carried out on them. In this context, an **object **is an **instance **of a data type, and its definition determines how you can use it. Each data type is implemented by one or more classes, which make up the basic elements of the system.
+@subsubsection occt_1819379591_986437237221 Classes
+
+A class is an implementation of a **data type**. It defines its **behavior **and its **representation**.
+
+The behavior of a class is its programming interface - the services offered by its **methods**. The representation of a class is its data structure - the **fields**,** **which store its data.
+
+Every object is an **instance **of its class. For example, the object *p *of the data type *Point *is an instance of the class Point.
+
+The class Point could be defined as in the example below:
+
+@code
+class Point from GeomPack
+@endcode
+@code
+ ---Purpose: represents a point in 3D space.
+@endcode
+@code
+ is
+@endcode
+@code
+ Create returns Point;
+@endcode
+@code
+fields
+@endcode
+@code
+ x, y, z : Real;
+@endcode
+@code
+end Point;
+@endcode
+
+The definition of this class comprises two sections:
+
+ * one starting with the keywords **is**
+ * one starting with the keyword **fields**.
+
+The first section contains a list of methods available to the clients of the class. The second section defines the way in which instances are represented. Once this class has been compiled you could **instantiate **its data type in a C++ test program as in the example below:
+
+
+
+@code
+GeomPack_Point p;
+@endcode
+@subsubsection occt_1819379591_986437237222 Categories of Types
+
+You declare the variables of a **data manipulation language **as being of certain data types. These fall into two categories:
+
+ * Data types manipulated by handle (or reference)
+ * Data types manipulated by value
+ <table>
+ <tr>
+ <td>
+
+ </td>
+ </tr>
+ <tr>
+ <td>
+
+ </td>
+ <td>
+ 
+ </td>
+ </tr>
+</table>
+
+Figure 3. Manipulation of data types
+
+
+As seen above, you implement data types using classes. However, classes not only define their data representation and methods available for their instances, but they also define how the instances will be manipulated:
+ * A data type manipulated by value contains the instance itself.
+ * A data type manipulated by handle contains a reference to the instance.
+
+The most obvious examples of data types manipulated by value are the predefined **primitive types**: Boolean, Character, Integer, Real ...
+
+A variable of a data type manipulated by handle, which is not attached to an object, is said to be **null**. To reference an object, you need to instantiate the class with one of its constructors. This is done in C++ as in the following syntax:
+
+
+
+@subsubsection occt_1819379591_986437237223 Persistence
+
+An object is called **persistent **if it can be permanently stored. In other words, you can use the object again at a later date, both in the application, which created it, and in another application.
+
+In order to make an object persistent, you need to declare it in CDL as inheriting from the **Persistent** class, or to have one of its parent classes inheriting from the **Persistent **class.
+
+Note that the classes inheriting from the Persistent class are handled by reference.
+
+**Example**
+
+In this example, building the application, you add the Watch class to the corresponding schema of data types.
+If, running the application, you instantiate an object of the Watch class, you have the possibility of storing it in a file.
+You cannot store objects instantiated from classes, which inherit from the **Storable** class. However, you can store them as fields of an object, which inherits from Persistent.
+
+Note that the objects inheriting from Storable are handled by value.
+**Example**
+
+If
+class WatchSpring inherits Storable
+//then this could be stored as a field of a Watch
+//object:
+class Watch inherits Persistent
+is......
+fields
+name : ConstructorName;
+powersource : WatchSpring;
+end;
+
+
+@subsubsection occt_1819379591_986437237224 Packages
+
+In large-scale long-term development the task of marshalling potentially thousands of classes is likely to quickly prove unmanageable. CDL introduces the notion of **package **of classes containing a set of classes, which have some semantic or syntactic relationship. For example, all classes representing a particular set of electronic components might make up a package called Diode.
+
+As the package name prefixes the class name when implementing such class (in C++ for example), classes belonging to different packages can have the same name. For example, two packages, one dealing with finance and the other dealing with aircraft maneuvers, might both contain a class called Bank, without any possibility of confusion.
+**Example**
+
+Finance_Bank
+Attitude_Bank
+
+
+
+@subsubsection occt_1819379591_986437237225 Inheritance
+
+The purpose of inheritance is to reduce development workload. The inheritance mechanisms allow you to declare a new class as already containing the characteristics of an existing class. This new class can then be rapidly specialized for a task at hand. This eliminates the necessity of developing each component “from scratch”.
+
+For example, having already developed a class BankAccount, you can quickly specialize new classes - SavingsAccount, LongTermDepositAccount, MoneyMarketAccount, RevolvingCreditAccount, etc..
+
+As a consequence, when two or more classes inherit from a parent (or ancestor) class, all these classes surely inherit the behavior of their parent (or ancestor). For example, if the parent class BankAccount contains the method Print that tells it to print itself out, then all its descendent classes offer the same service.
+
+One way of ensuring the use of inheritance is to declare classes at the top of a hierarchy as being **deferred**. In such classes, the inherited methods are not implemented. This forces you to create a new class used to redefine the methods. In this way, you guarantee a certain minimum common behavior among descendent classes.
+**Example**
+
+deferred class BankAccount inherits Persistent
+is
+.......
+fields
+name : AccountHolderName;
+balance : CreditBalance;
+end;
+
+
+@subsubsection occt_1819379591_986437237226 Genericity
+
+You will often wish to model a certain type of behavior as a class. For example, you will need a list modeled as a class.
+
+In order to be able to list different objects, the class **List **must be able to accept different data types as parameters. This is where genericity comes in: you first declare a list declared as the generic class **List**, willing to accept any data type (or only a particular set of acceptable data types). Then, when you want to make a list of a certain type of object, you instantiate the class **List **with the appropriate data type.
+**Example**
+
+generic class NewList (Item)
+inherits OldList
+is
+.....
+end ;
+
+Items may be of any type, an Integer or a Real for example.
+
+When defining the package, add the following line:
+**Example**
+
+class NewListOfInteger instantiates
+NewList (Integer);
+
+
+@subsubsection occt_1819379591_986437237227 Exceptions
+
+The behavior of any object is implemented by methods, which you define in its class declaration. The definition of these methods includes not only their signature (their programming interface) but also their domain of validity.
+
+In CDL, this domain is expressed by **exceptions**. Exceptions are raised under various error conditions. This mechanism is a safeguard of software quality.
+@subsubsection occt_1819379591_986437237228 Completeness
+
+You use CDL to define data types. Such definitions are not considered complete unless they contain the required amount of structured commentary.
+
+The compiler does not enforce this required degree of completeness, so it is the responsibility of the developer to ensure that all CDL codes are properly annotated.
+
+Completeness is regarded as an essential component of long-term viability of a software component.
+
+
+@subsection occt_1819379591_98643723723 Lexical Conventions
+@subsubsection occt_1819379591_986437237231 Syntax notation
+
+In this manual, CDL declarations are described using a simple variant of the Backus-Naur formalism. Note the following:
+
+ * Italicized words, which may also be hyphenated, denote syntactical categories, for example:
+
+*declaration-of-a-non-generic-class*
+
+ * Keywords appear in bold type:
+
+**class**
+
+ * Brackets enclose optional elements:
+
+identifier [**from **package-name]
+
+ * Curly braces enclose repeated elements. The element may appear zero or many times:
+
+integer ::= digit{digit}
+
+ * Vertical bars separate alternatives:
+
+passing-method ::= [**in**] | **out **| **in out**
+
+ * Two apostrophes enclose a character or a string of characters, which must appear:
+
+exponent ::= ’E’[’+’]integer | ’E-’ integer
+
+NOTE
+So as to introduce ideas progressively, the examples presented in this manual may be incomplete, and thus not compilable by the CDL compiler.
+
+
+@subsubsection occt_1819379591_986437237232 Lexical elements
+
+A CDL source is composed of text from one or more compiled units. The text of each compiled unit is a string of separate lexical elements: **identifiers**, **keywords**, **constants**, and **separators**. The separators (blank spaces, end of line, format characters) are ignored by the CDL compiler, but these are often necessary for separating identifiers, keywords, and constants.
+
+
+@subsubsection occt_1819379591_986437237233 Comments
+
+With CDL, you cannot use the expression of all useful information about a development unit. In particular, certain information is more easily expressed in natural language. You can add such information to the CDL description of a data type.
+
+Rubrics and free comments are to be differentiated:
+
+**Free comments **are preceded by the characters “--” (two hyphens), and they terminate at the end of the line in which they appear.
+**Example**
+
+--This is a comment
+
+Unlike rubrics, free comments can appear before or after any lexical element. The first written character of the comment itself *must not *be a hyphen. If a hyphen is necessary make sure it is preceded by a blank.
+**Example**
+
+-- -List item
+
+**Rubrics **are various types of comments attached to CDL components. A rubric is a comment made up of three hyphens, name of the rubric (without any intermediary space) and then a colon and a space. It is terminated by the beginning of the following rubric, or by the end of the commentary.
+**Example**
+
+---Purpose:This is an example of a
+--rubric composed of a
+--comment which extends to
+--four lines.
+
+The different categories of rubrics and the form of their content do not depend on the Component Description Language, but on the tool for which it is intended.
+
+The use of commentary is generally governed by the internal programming standards of an enterprise. You are encouraged to use various well-defined rubrics, such as Purpose, Warning, Example, References, Keywords, etc.
+
+These rubrics can be attached to:
+
+ * Packages
+ * Classes
+ * Methods
+ * Schemas
+ * Executables
+ * Clients
+
+@subsubsection occt_1819379591_986437237234 Identifiers
+
+An identifier is an arbitrary chain of characters, either letters or digits, but it must begin with a letter.
+
+The underscore “_” is considered to be a letter as long as it doesn’t appear at the beginning or the end of an identifier.
+Capital and small letters are not equivalent (i.e. AB, Ab, aB, ab are four different identifiers).
+
+
+@subsubsection occt_1819379591_986437237235 Keywords
+
+The following is a list of keywords.
+
+alias any as asynchronous
+class client deferred end
+enumeration exception executable external
+fields friends from generic
+immutable imported inherits instantiates
+is library like me
+mutable myclass out package
+pointer primitive private protected
+raises redefined returns schema
+static to uses virtual
+
+In a CDL file, the following characters are used as punctuation:
+; : , = ( ) [ ] ‘ “
+
+@subsubsection occt_1819379591_986437237236 Constants
+
+There are three categories of constants:
+
+ * Numeric
+ * Literal
+ * Named
+
+***Numeric Constants***
+
+There are two types of numeric constants: integer and real.
+An **integer **constant consists of a string of digits, which may or may not be preceded by a sign. Integer constants express whole numbers.
+**Examples**
+
+1995 0 -273 +78
+
+A **real **constant may or may not be preceded by a sign, and consists of an integral part followed by a decimal point and a fractional part (either one or both parts may be null, but both parts must always be present). It may also be followed by the letter E to indicate that the following figures represent the exponent (also optionally signed).
+**Examples**
+
+5.0 0.0 -0.8E+3 5.67E-12
+
+***Literal Constants***
+
+Literal constants include individual characters and strings of characters.
+
+An **individual character **constant is a single printable character enclosed by two apostrophes. (See the definition of the class Character in the Standard Package).
+**Examples**
+
+ ‘B’ ‘y’ ‘&’ ‘*’ ‘’’ ‘‘
+
+A **string **constant is composed of printable characters enclosed by quotation marks.
+**Examples**
+
+’’G’’ ’’jjjj’’ ’’This is a character string, isn’t it?’’
+
+The **quotation mark **can itself appear within a character string as long as it is preceded by a backslash.
+**Examples**
+
+’’This film was originally called \’’Gone with the Tide\’’.’’
+
+***Named Constants***
+
+Named constants are sub-divided into two categories: Booleans and enumerations.
+
+**Booleans **can be of two types: True or False.
+
+An **enumeration **constant is an identifier, which appears in the description of an enumeration.
+
+@section occt_1819379591_1718435309 3. Software Components
+
+
+
+@subsection occt_1819379591_171843530931 Predefined Resources
+@subsubsection occt_1819379591_1718435309311 Primitive types
+
+Primitive types are predefined in the language and they are **manipulated by value**.
+
+Four of these primitives are known to the schema of the database because they inherit from the class **Storable**. In other words, they can be used in the implementation of persistent objects, either when contained in entities declared within the methods of the object, or when they form part of the internal representation of the object.
+
+The primitives inheriting from Storable are the following:
+
+**Boolean **Is used to represent logical data. It has only two values:
+*True *and *False*.
+**Byte **8-bit number.
+**Character **Designates any ASCII character.
+**ExtCharacter **Is an extended character.
+**Integer **Is an integer number.
+**Real **Denotes a real number (i.e. one with a whole and a fractional part, either of which may be null).
+**ShortReal **Real with a smaller choice of values and memory size.
+
+There are also non-storable primitives. They are:
+
+**CString **Is used for literal constants.
+**ExtString **Is an extended string.
+**Address **Represents a byte address of undetermined size.
+
+The services offered by each of these types are described in the Standard Package.
+
+
+@subsubsection occt_1819379591_1718435309312 Manipulating types by reference (by handle)
+
+Two types are manipulated by handle:
+
+ * Types defined using classes inheriting from the **Persistent **class are storable in a file.
+
+ * Types defined using classes inheriting from the **Transient **class.
+These types are not storable as such in a file.
+
+
+
+Figure 4. Manipulation of a data type by reference
+
+
+@subsubsection occt_1819379591_1718435309313 Manipulating types by value
+
+Types, which are manipulated by value, behave in a more direct fashion than those manipulated by handle. As a consequence, they can be expected to perform operations faster, but they cannot be stored independently in a file.
+
+You can store types known to the schema (i.e. either primitives or inheriting from Storable) and manipulated by value inside a persistent object as part of the representation. This is the only way for you to store objects “manipulated by value” in a file.
+
+
+ <table>
+ <tr>
+ <td>
+
+ </td>
+ </tr>
+ <tr>
+ <td>
+
+ </td>
+ <td>
+ 
+ </td>
+ </tr>
+</table>
+Figure 5. Manipulation of a data type by value
+Three types are manipulated by value:
+
+ * Primitive types
+ * Enumerated types
+ * Types defined by classes not inheriting from Persistent or Transient, whether directly or not
+
+@subsubsection occt_1819379591_1718435309314 Summary of properties
+
+**Figure 6. Summary of the relationship for the various data**
+**types between how they are handled and their storability.**
+
+
+@subsection occt_1819379591_171843530932 Classes
+
+@subsubsection occt_1819379591_1718435309321 Class declaration
+
+The class is the main system for creating data types under CDL. By analyzing any CDL-based software, you find that classes are the modular units that make up packages. When you describe a new class, you introduce a new data type.
+
+Whatever the category of the described type (manipulated by value, Storable or not, manipulated by handle, Persistent or not) the structure of the class definition remains the same. The syntax below illustrates it:
+**Example**
+
+-- declaration-of-a-simple-class ::=
+class class-name from package-name
+[uses data-type { ’,’ data-type } ]
+[raises exception-name { ’,’ exception-name} ]
+is class-definition
+end [ class-name ] ’;’
+data-type ::= enumeration-name | class-name |
+exception-name | primitive-type
+package-name ::= identifier
+class-name ::= identifier
+class-definition ::=
+[{member-method}]
+[declaration-of-fields]
+[declaration-of-friends]
+
+Class name becomes a new data type, which you can use inside its own definition. Other types appearing in the definition must either be primitive types, previously declared classes, exceptions, or enumerations.
+
+Apart from the types defined in the Standard Package, which are **implicitly visible **everywhere, you need to declare the data types after the keyword **uses**. This concerns both the class behavior and its internal representation.
+
+**Exceptions **are declared after the word **raises**.
+**Example**
+
+class Line from GeomPack
+usesPoint, Direction, Transformation
+raisesNullDirection, IdenticalPoints
+is-- class definition follows here
+-- using Point, Direction and
+-- Transformation objects,and the
+-- NullDirection and Identical-
+-- -Points exceptions.
+end Line;
+
+The elements, which make up the definition of a class, are divided into four parts:
+
+ * the behavior
+ * the invariants
+ * the internal representation
+ * the friend methods and friend classes.
+ <table>
+ <tr>
+ <td>
+
+ </td>
+ </tr>
+ <tr>
+ <td>
+
+ </td>
+ <td>
+ 
+ </td>
+ </tr>
+</table>
+**Figure 7. Contents of a class**
+*** a deferred class does not have to contain a constructor**
+
+
+@subsubsection occt_1819379591_1718435309322 Categories of classes
+
+Classes fall into three categories:
+
+ * Ordinary classes
+ * Deferred classes
+ * Generic classes
+
+<h4>Deferred classes</h4>
+
+The principal characteristic of a **deferred class **is that you cannot instantiate it. Its purpose is to provide you with a given behavior shared by a hierarchy of classes and dependent on the implementation of the descendents. This allows you to guarantee a certain base of inherited behavior common to all classes based on a particular deferred class. Deferred classes are declared as in the following syntax:
+**Example**
+
+-- declaration-of-a-deferred-class ::=
+deferred class class-name
+[inherits class-name {’,’ class-name}]
+[uses data-type {’,’ data-type}]
+[raises exception-name {’,’ exception-name}]
+is class-definition
+end [class-name]’;’
+
+
+<h4>Generic classes</h4>
+
+The principal characteristic of a **generic class **is that it offers you a set of functional behavior allowing you to manipulate other data types. To instantiate a generic class you need to pass a data type in argument. Generic classes are declared as in the following syntax:
+**Example**
+
+-- declaration-of-a-generic-class ::=
+[deferred] generic class class-name ’(’generic-type
+{’,’ generic-type}’)’
+[inheritsclass-name {’,’ class-name}]
+[usesdata-type {’,’ data-type}]
+[raisesexception-name {’,’ exception-name}]
+[{[visibility] declaration-of-a-class}]
+is class-definition
+end [class-name]’;’
+generic-type ::= identifier as type-constraint
+identifier ::= letter{[underscore]alphanumeric}
+type-constraint ::= any | class-name [’(’data-type {’,’
+data-type}’)’]
+
+
+
+@subsection occt_1819379591_171843530933 Packages
+
+@subsubsection occt_1819379591_1718435309331 Package declaration
+
+ **Packages** are used to group classes, which have some logical coherence. For example, the Standard Package groups together all the predefined resources of the language. In its simplest form, a package contains the declaration of all data types, which it introduces. You may also use a package to offer public methods and hide its internal classes by declaring them private.
+** **
+**Example**
+
+-- package-declaration ::=
+**package **package-name
+[**uses **package-name {’,’ package-name}]
+**is **package-definition
+**end **[package-name]’;’
+-- package-name ::=
+identifier
+-- package-definition ::=
+[{type-declaration}]
+[{package-method}]
+-- type-declaration ::=
+[**private**] declaration-of-an-enumeration |
+[**private**] declaration-of-a-class |
+declaration-of-an-exception
+-- package-method ::=
+identifier [simple-formal-part][returned-type
+-declaration]
+[error-declaration]
+[***is private***]’;’
+
+The data types described in a package *may *include one or more of the following data types:
+
+ * Enumerations
+ * Object classes
+ * Exceptions
+ * Pointers to other object classes.
+
+Inside a package, two data types *cannot *have the same name.
+
+You declare data types before using them in the definition of other data types.
+
+When two classes are **mutually recursive**, one of the two *must *be first declared in an incomplete fashion.
+
+Grouped behind the keyword **uses **are the names of all the packages containing definitions of classes of which the newly introduced data types are clients.
+
+The methods you declare in a package do not belong to any particular class. **Package methods ***must *carry a name different from the data types contained in the package. Like any other method, they can be overloaded. With the exception of the keyword **me **and the visibility (a package method can *only *be either public or private) package methods are described in the same way as **instance methods**.
+
+
+Figure 8. Contents of a package
+
+The example of the package below includes some of the basic data structures:
+**Example**
+
+package Collection
+uses
+Standard
+is
+exception NoSuchObject inherits Failure;
+exception NoMoreObject inherits Failure;
+generic class SingleList;
+generic class Set;
+end Collection;
+
+Note that the class Set is declared after the declarations of the NoSuchObject and NoMoreObject exceptions and the SingleList class of which Set is a client. In the same way, the classes Failure, Persistent, and the exception NoSuchObject are defined before they are used. They are defined in the Standard package, which appears after the keyword **uses**.
+
+@subsubsection occt_1819379591_1718435309332 Name space
+
+The **name space **or **scope **of a class extends from the beginning of its declaration up to the end of the package in which it appears.
+
+Sometimes, two classes, which come from separate packages, are both visible to a third package and carry the same name. For example, there might be two different classes both called “Window” in a screen generator package and in an architectural package. As a client of a data type, you can find yourself in the position of having to remove the ambiguity over the origin of this type; you do this by means of the keyword **from**.
+**Example**
+
+-- class-name ::=
+identifier [**from **package-name]
+-- exception-name ::=
+identifier [**from **package-name]
+-- enumeration-name ::=
+identifier [**from **package-name]
+
+You can use the keyword **from **everywhere the name of a class, exception, or enumeration appears. As a consequence, as a client of the class “Window” you could write wherever necessary:
+**Example**
+
+Window from ScreenGenerator
+-- or
+Window from ArchitecturalFeatures
+
+NOTES
+***Within the description of a package the keyword *****from**** *must be used when referencing any data type that is not defined in this package.***
+
+Here is a further example:
+**Example**
+
+class Line from Geom
+uses
+Point from Geom2d,
+Point from Geom3d
+is
+-- class definition using
+-- Point from AppropriatePackage
+-- wherever Point appears
+end;
+
+
+@subsubsection occt_1819379591_1718435309333 Declaration of classes
+
+You cannot describe a package in one single file. You need to describe it in different units and send them separately to the CDL compiler. Each compilation unit can contain the declaration of a class or of a package. When you describe a class in a unit different than that, which describes its package, you need to specify which package the class belongs to. You do this using the keyword **from**.
+
+If the **from **clause appears in the **uses **clause of the package, it does not need to be repeated elsewhere.
+
+The following example takes the package “Collection” which was presented above, but this time it is divided into three compilation units.
+**Example**
+
+-- First compilation unit, the package “Collection” :
+package Collection
+uses
+Standard
+is
+exception NoMoreObject inherits Failure from Standard;
+exception NoSuchObject inherits Failure from Standard;
+generic class SingleList;
+generic class Set, Node, Iterator;
+end Collection;
+-- Second compilation unit, the class “SingleList” :
+generic class SingleList from Collection (Item as
+Storable)
+inherits
+Persistent from Standard
+raises
+NoSuchObject from Collection
+is
+-- definition of the SingleList class
+end SingleList;
+-- Third compilation unit, the class “Set” :
+generic class Set from Collection (Item as Storable)
+ inherits
+Persistent from Standard;
+raises
+NoSuchObject from Collection,
+NoMoreObject from Collection
+private class Node instantiates SingleList
+from Collection (Item);
+-- etc....
+ end Set;
+
+
+NOTE
+It is not explicitly stated that the “Node” class belongs to the “Collection” package. In fact any nested class necessarily belongs to the package of the class, which encompasses it.
+
+Note that a package can hide certain classes (just as it can hide methods) by declaring them **private**. To make a class private, you prefix its description with the keyword **private**. In the example of the “Collection” package, the “SingleList” class serves only to implement the “Set” class. It is recommended to make it private. You write this as in the following syntax:
+**Example**
+
+package Collection
+uses
+Standard
+is
+generic class Set, Node, Iterator;
+private generic class SingleList;
+exception NoMoreObject inherits Failure from Standard;
+end Collection;
+
+
+
+
+@subsection occt_1819379591_171843530934 Other Data Types
+
+These are:
+
+ * Enumerations
+ * Imports
+ * Aliases
+ * Exceptions
+ * Pointers
+
+@subsubsection occt_1819379591_1718435309341 Enumerations
+
+The **enumerated types **are the second type, which is manipulated by value. Unlike the primitive types they are extensible because they are defined by the user under the form of enumerations. An enumeration is an ordered sequence of named whole constant values called enumeration constants.
+**Example**
+
+declaration-of-an-enumeration ::=
+**numeration **enumeration-name
+**is **identifier {’,’ identifier}
+[**end **[enumeration-name]]’;’
+enumeration-name ::= identifier
+
+The declaration of an enumeration creates an enumerated type. An object of this type can successively take the value of any one of the constants cited in the list.
+**Example**
+
+enumeration MagnitudeSign is Negative, Null, Positive;
+
+
+Inside a package, two enumeration constants cannot have the same name, even if they belong to different enumerated types.
+**Example**
+
+enumeration Cars is
+Honda,
+Ford,
+Volkswagen,
+Renault
+end;
+enumeration AmericanPresidents is
+Nixon,
+Reagan,
+Ford, -- Error: ‘Ford’ already defined
+Carter
+end;
+
+
+@subsubsection occt_1819379591_1718435309342 Imports
+
+An **imported type **is one of which which has not been defined in CDL. It is up to the supplier of this data type to ensure compatibility with the CDL language by providing services which allow CDL to recognize the imported data type.
+
+The CDL syntax for declaring an imported type is:
+
+declaration-of-an-imported-type::=
+[**private**] **imported **typename ;
+**Example**
+
+-- You can define an imported type as follows:
+-- In the MyPack.cdl file, you declare the imported
+type:
+-- package MyPack
+....
+imported MyImport;
+....
+end Mypack;
+-- In the MyPack_MyImport.hxx file, you write the
+following
+-- C++ code:
+#ifndef _MyPack_MyImport_HeaderFile
+#define _MyPack_MyImport_HeaderFile
+#include Standard_Type.hxx
+typedef unsigned long MyPack_MyImport;
+extern const Handle(Standard_Type)& TYPE
+(MyPack_MyImport);
+-- In the MyPack_MyImport.cxx file, you write the
+following
+-- C++ code:
+#ifndef _MyPack_MyImport_HeaderFile
+#include MyPack_MyImport.hxx
+#endif
+const Handle(Standard_Type)& TYPE (MyPack_MyImport)
+
+{
+static Handle(Standard_Type) _aType =
+new Standard_Type (“MyPack_MyImport”,sizeof
+(MyPack_MyImport))
+ return _aType;
+}
+
+Then, add the names of these two files (MyPack_MyImport.hxx, MyPack_MyImport.cxx) to a file called FILES in the src subdirectory of the package. If the file does not exist you must create it.
+
+
+@subsubsection occt_1819379591_1718435309343 Aliases
+
+An **alias **is an extra name for a type, which is already known. It is declared as in the following syntax:
+
+declaration-of-an-alias::=
+[**private**] **alias **type1 **is **type2 [**from **apackage] ;
+**Example**
+
+alias Mass is Real;
+---Purpose:
+-- Defined as a quantity of matter.
+-- Gives rise to the inertial and
+-- gravitational properties of a body.
+-- It is measured in kilograms.
+
+Having defined *Mass *as a type of *Real*, you can use either *Mass *or *Real *to type an argument when defining a method.
+
+
+@subsubsection occt_1819379591_1718435309344 Exceptions
+
+In the model recommended by CDL, the principal characteristic of errors is that they are treated in a different place from the place where they appear. In other words, the methods recovering and those raising a given exception are written independently from each other.
+
+Subsequently this poses the problem of communication between the two programs. The principle adopted consists in viewing the exception as both a class and an object. The exception class (by means of one of its instances) is used to take control of an exception, which has been raised.
+
+Consequently, error conditions are defined by means of **classes of exceptions**. Exception classes are arranged hierarchically so as to be able to recover them in groups. They are all descendents of a single root class called “Failure”, and it is at the level of this class that the behavior linked to the raising of exceptions is implemented.
+
+declaration-of-an-exception ::=
+**exception **exception-name **inherits **exception-name
+
+All exceptions share identical behavior, that of the class “Failure”. Here are some examples of exception classes:
+exception NumericError inherits Failure;
+exception Overflow inherits NumericError;
+exception Underflow inherits NumericError;
+
+The use of exceptions as a means to interrupt the normal execution of one program and then take control of another one depends on the programming language used to implement the methods. See the following chapter <a href="#Defing_Software_Components">“Defining the Software Components”</a> on page 32.
+
+
+@subsection occt_1819379591_171843530935 Schemas
+
+The purpose of a **schema **is to list persistent data types, which will be stored in files by the application. A schema groups together persistent packages. A persistent package is one, which contains at least one persistent class.
+
+declaration-of-a-schema ::=
+**schema **SchemaName
+is
+{**package **PackageName;}
+{**class **ClassName;}
+**end**;
+**Example**
+
+schema Bicycle
+---Purpose: Defines the Bicycle schema.
+is
+package FrameComponents;
+package WheelComponents;
+end;
+
+***NOTE***
+Note that it is unnecessary to specify all the dependencies of the packages. It is sufficient to specify the highest level ones. The others on which they depend are automatically supplied.
+@subsection occt_1819379591_171843530936 Executables
+
+The purpose of an **executable **is to make an executable program without a front-end. It can be used to test more than one package at a time. An executable is written in a .cdl file as a set of packages.
+**Example**
+
+definition-of-an-executable ::=
+executable ExecutableName
+is
+{
+executable ExecutablePart
+[uses [Identifier as external]
+[{’,’ Identifier as external}]
+[UnitName as library]
+[{’,’ UnitName as library}]
+is
+{FileName [as C++|c|fortran|object];}
+end;
+}
+end;
+**Example**
+
+executable MyExecUnit
+---Purpose:
+-- Describes the executable MyExecUnit
+is
+executable myexec
+-- the binary file
+uses
+Tcl_Lib as external
+is
+myexec;
+-- the C++ file
+end;
+-- several binaries can be specified in one .cdl file.
+executable myex2
+is
+myex2;
+end;
+end;
+
+@section occt_1819379591_1972310108 4. Defining the Software Components
+
+@subsection occt_1819379591_197231010841 Behavior
+
+The behavior of an object class is defined by a list of **methods, **which are either **functions **or **procedures**. Functions return an object, whereas procedures only communicate by passing arguments. In both cases, when the transmitted object is an instance manipulated by a handle, its identifier is passed. There are three categories of methods:
+
+**Object constructor **Creates an instance of the described class. A class will have one or more object constructors with various arguments or none.
+
+**Instance method **Operates on the instance which owns it.
+
+**Class method **Does not work on individual instances, only on the class itself.
+
+@subsubsection occt_1819379591_1972310108411 Object Constructors
+
+A constructor is a function, which allows the **creation of instances **of the class it describes.
+**Example**
+
+constructor-declaration ::=
+Create [ simple-formal-part ] declaration-ofconstructed-
+type
+[ exception-declarations ]
+simple-formal-part ::=
+’(’ initialization-parameter {’;’ initialization parameter}’)’
+initialization-parameter ::=
+identifier {’,’ identifier} ’:’ parameter-access datatype
+[ ’=’ initial-value ]
+parameter-access ::=
+**mutable **| [ **immutable **]
+initial_value ::=
+numeric-constant | literal-constant | named-constant
+declaration-of-constructed-type ::=
+**returns **[ **mutable **] class-name
+
+The name of the constructors is fixed: “Create”. The object returned by a constructor is always of the type of the described class. If that type is manipulated by a handle, you *must *declare it as **mutable**, in which case the content of the instance it references is accessible for further modification.
+
+For example, the constructor of the class “Point”
+**Example**
+
+Create (X, Y, Z : Real)
+returns mutable Point;
+
+With the exception of the types predefined by the language, all types of initialization parameters *must *appear in the **uses **clause of the class of which the constructor is a member.
+
+When an initialization parameter is of a type which is manipulated by a handle, an access right *must *be associated with it so as to express if the internal representation of the referenced object is modifiable (**mutable**) or not (**immutable**). The default option is **immutable**. For example, the constructor of the persistent class “Line”.
+**Example**
+
+Create (P : mutable Point; D : mutable Direction)
+returns mutable Line;
+
+In the above example “P” and “D” must be mutable because the constructor stores them in the internal representation of the created line, which is mutable itself. An alternative would be to accept immutable initialization parameters and then copy them into the constructor in a mutable form.
+
+The parameters of a native type can have a default value: this is expressed by assigning a constant of the same type to the parameter concerned. Parameters, which have a default value, may not be present when the call to the constructor is made, in which case they take the value specified in the declaration. For this reason, they must all be grouped at the end of the list. For example, the constructor of the persistent class “Vector”.
+**Example**
+
+Create (D : mutable Direction; M : Real = 1.0)
+returns mutable Vector;
+
+A class can have many constructors (in this case, you say they are **overloaded**) provided that they differ in their syntax and that the presence of parameters having default values does not create ambiguities.
+
+The restrictions on their use are expressed by a list of **exceptions **against which each constructor is protected.
+
+Each class must have at least one constructor to be able to create objects of its type.
+@subsubsection occt_1819379591_1972310108412 Instance Methods
+
+An instance method is a function or procedure, which applies to any instance of the class, which describes it.
+**Example**
+
+declaration-of-an-instance-method ::=
+identifier formal-part-of-instance-method
+[ declaration-of-returned-type ]
+[ exception-declaration ]
+formal-part-of-instance-method ::=
+ ’(’ me [’:’ passing-mode parameter-access ] {’;’
+parameter}’)’
+parameter ::=
+identifier {’,’ identifier} ’:’ passing-mode
+parameter-access
+data-type [ ’=’ initial-value ]
+passing-mode ::=
+[ in ] | out | in out
+parameter-access ::=
+mutable | [immutable]
+declaration-of-returned-type ::=
+returns return-access data-type
+return-access ::=
+mutable |[ immutable ]| any
+
+The name **me **denotes the object to which the method is applied: you call this the “principal object” of the method. The passing mode expresses whether the direct content of the principal object or a parameter is either:
+
+ * read
+ * created and returned
+ * read then updated and returned by the method.
+
+Remember that the direct content of an argument of a type which is manipulated by value contains the internal representation of the object itself. Thus, when the argument is of this type, **out **and **in out **mean that the content of the object will undergo a modification. When the method is a function (as is the case for constructors), all the arguments must be **in **(read). This is the default mode.
+
+In case of an argument of a type manipulated by a handle, the direct content being an object identifier, the passing mode addresses itself to the handle, and no longer to the internal representation of the object, the modification of which is controlled by the access right. An argument of this type declared **mutable **may see its internal representation modified. If declared **immutable**, it is protected. When a parameter is both **in out **and **mutable**, the identifiers passed and returned denote two distinct modifiable objects.
+
+When the returned object is manipulated by a handle it can be declared modifiable or not, or indeterminate (**any**). To return an object with an indeterminate access right means that the method transmits the identifier without changing its state and that the method has no right to alter the access right. This functionality is particularly useful in the case of collections; temporarily storing an object in a structure and unable to modify its state.
+
+With the exception of the types predefined by the language, all types of parameters and returned objects, whether manipulated by a handle or by value, *must *appear in the **uses **clause of the class of which the method is a member.
+As is the case for constructors, some parameters can have a default value, provided that they are of primitive or enumerated type. They are passed in the **in **mode, and they are found at the end of the list of arguments.
+
+Overloading of instance methods and use of exceptions and post-conditions is allowed and respects the same rules than constructors.
+
+Note the overloading of “Coord” in the following example of instance methods associated with the persistent class “Point”:
+**Example**
+
+Coord (me; X, Y, Z : out Real);
+---Purpose: returns the coordinates of me
+
+Coord (me; i : Integer) returns Real;
+---Purpose: returns the abscissa (i=1), the
+-- ordinate (i=2) or the value (i=3) of me
+
+SetCoord (me : mutable; X, Y, Z : Real);
+---Purpose: modifies the coordinates of me
+
+Distance (me; P : Point) returns Real
+---Purpose: returns the distance to a point
+
+In all these cases, **me **is implicitly an object of type Point. Only “SetCoord” is able to modify the internal representation of a point.
+
+@subsubsection occt_1819379591_1972310108413 Class Methods
+
+A class method is a function or procedure relative to the class it describes, but does not apply to a particular instance of the class.
+
+declaration-of-a-class-method ::=
+identifier formal-part-of-class-method
+[ declaration-of-returned-type ]
+[ exception-declaration ]
+formal-part-of-class-method ::=
+’(’ **myclass **{’;’ parameter}’)’
+
+The first parameter **myclass **indicates that the method does not apply to a previously created instance, but to the class itself. The rest of the syntax is identical to that of the instance methods. In particular, access rights (**mutable**, **immutable**, **any**) and the argument passing mode (**in**, **out**, **in out**) must remain unchanged. With the exception of the types predefined by the language, all types of parameters must appear in the **uses **clause of the class of which the method is a member. Overloading of class methods and the use of exceptions and post-conditions is allowed, and it follows the same rules as for constructors and instance methods.
+Examples of class methods associated with the class “Real”:
+**Example**
+
+First (myclass) returns Real;
+---Purpose: returns lower limit of reals
+
+Last (myclass) returns Real;
+---Purpose: returns upper limit of reals
+
+
+@subsubsection occt_1819379591_1972310108414 Package Methods
+
+Package methods are methods which are members of a package. They are frequently used for library or application initialization, or for offering an application programming interface to the sources to the package. They are sometimes methods used for development purposes but which are not made available to final end-users of the package.
+
+package-method ::=
+identifier [simple-formal-part][returned-type-declaration]
+[exception-declaration]
+[**is private**]’;’
+
+
+@subsubsection occt_1819379591_1972310108415 Sensitivity to Overloading
+
+When there is more than one method of a class, several methods share the same name but have different syntax, you say the method is overloaded.
+
+In order that the methods can be considered distinct, they must differ either in the number of parameters, or one of their parameters must be of a different type. In particular, you *cannot *overload a method if you merely modify it as follows:
+
+ * The type of the returned object when the method behaves as a function
+ * The name or the mode of passing a parameter
+(**in**, **out**, or **in out**)
+ * The mutability of passed objects
+(**mutable**, **immutable**, **any**)
+ * Default value of a parameter.
+@subsection occt_1819379591_197231010842 Internal Representation
+
+Each object contains its own state in a private space in the memory. This state consists of a set of **fields**,** **which include or reference other objects.
+**Example**
+
+declaration-of-the-internal-representation-of-a-class
+::=
+**fields **field {field}
+field ::=
+identifier {’,’ identifier} ’:’ data-type [’[’integer
+{’,’integer}’]’]’;’
+
+A copy of all the defined fields exists locally in each instance of the class. This group of fields will be initialized by the class constructors when the object is instantiated.
+
+Fields *must not *have the same name as any method of the class in which they appear. When the field type is followed by a list of integer constants between square brackets, the data will take the form of a multi-dimensional array containing objects of this type.
+
+The following example shows two equivalent ways of describing three fields of the “Real” type:
+**Example**
+
+fields
+x, y, z: Real;
+coord: Real[3];
+
+Depending on their type, Object fields have one of the two forms. When the field is of the “manipulated by handle” type, it corresponds to an identifier. In this case, the contents of the object can be shared by other objects or by a handle in a program. When the field is of a “manipulated by value” type, it contains the value of the object. In this case you say the object is **embedded**.
+
+@subsection occt_1819379591_197231010843 Exceptions
+
+Exceptions describe exceptional situations, which can arise during the execution of a method. With the raising of an exception, the normal course of program execution is interrupted. The actions carried out in response to this situation are called treatment of exception.
+
+exception-treatment ::= **raises **exception-name {’,’
+exception-name}
+
+Each exception name corresponds to a class of exceptions previously defined as being susceptible to being raised by the method under which it appears. Exception classes must all appear in the **raises **clause of the class of which the method is a member. The class of exceptions is analogous to the class of objects described in this manual.
+
+Take for example the method which returns the x, y, or z coordinate of a point.
+**Example**
+
+Coord (me; i : Integer) returns Real
+---Purpose:
+-- Returns the abscissa (i=1)
+-- the ordinate (i=2)
+-- or the value (i=3)
+-- of me.
+raises OutOfRange;
+-- if i is not equal to 1, 2, or 3.
+
+Instance methods are likely to raise certain exceptions called **systematic exceptions **which do not have to appear. They are:
+
+**NullObject **Raised when the principal object does not exist.
+
+**ImmutableObject **Raised when a method tries to modify an immutable principal object.
+
+**TypeMismatch **Raised if an argument typed by association is of an unsuitable type.
+
+These exceptions are described in the Standard Package (System Toolkits).
+
+
+@subsection occt_1819379591_197231010844 Inheritance
+
+@subsubsection occt_1819379591_1972310108441 Overview
+
+The notion of inheritance comes from a development strategy according to which you begin by modeling data in the most general fashion. Then you specialize it more and more so as to correspond to more and more precise cases.
+
+For example, to develop a basic geometry, you can first of all consider the group of geometric objects, and then differentiate the points, vectors, and curves. You can specialize the latter into conic sections, and then decompose them into circles, ellipses, and hyperbolae. Then, the class of conics is considered as a sub-class of curves, and a super-class of circles.
+
+A sub-class has at least the behavior of its super-classes. Thus, a circle could be viewed as a conic, a curve, or even as a geometric object. In each case, the applicable methods belong to the level where you view the class. In this case, you say that the sub-class inherits the behavior from its super-classes.
+**Example**
+
+declaration-of-a-sub-class ::=
+**class **class-name
+**inherits **class-name
+[**uses **data-type {’,’ data-type}]
+[**raises **exception-name {’,’ exception-name}]
+**is **class-definition
+**end **[class-name]’;’
+
+A class cannot inherit one of its descendent classes; nor can it inherit a native type. All the classes of a system can be described in a non-cyclic diagram called the **inheritance graph**.
+
+The definition of a sub-class is identical to that of a simple class. Note that a super-class *must not *appear in the **uses **clause of the sub-class, even if it appears in the definition of the sub-class. The behavior of a sub-class includes as a minimum all instance methods and protected methods of its super-classes.
+
+NOTE
+Note that constructors and class methods are never inherited.
+
+
+@subsubsection occt_1819379591_1972310108442 Redefining methods
+
+Certain inherited methods can be redefined.
+**Example**
+
+declaration-of-a-redefined-method ::=
+identifier formal-part-of-instance-method [returnedtype-
+declaration]
+[declaration-of-exceptions]
+** is redefined **[visibility]’;’
+
+A redefined method must conform to the syntax described in the super-class where it appears. The exceptions contained in the super-class can be renewed, and others may be added as long as they inherit from an ancestor class.
+
+The **redefined **attribute can be applied neither to a constructor, nor to a class method, since neither of them can be inherited. If the redefined method is private or protected, the visibility must be exactly repeated in the redefinition. For further details on visibility, refer to <a href="#Visibility">“Visibility”</a> on page 48.
+**Example**
+
+SquareDistance (me; P : Point) returns Real
+is redefined private;
+
+With regards to the internal representation, all fields defined in the super-classes are, by default, inherited, but they can also be redefined.
+
+@subsubsection occt_1819379591_1972310108443 Non-redefinable methods
+
+Instance methods, which are declared virtual are redefinable in descendent classes, and you can force this redefinition by making a method **deferred**. For more details, see the next section.
+**Example**
+
+declaration-of-a-non-redefinable-method ::=
+identifier formal-part-of-instance-method [returnedtype-
+declaration]
+[declaration-of-exceptions]
+** is virtual **[visibility]’;’
+
+All methods are static by default. To enable redefinition in all the child classes, add “**is virtual;**“ when declaring the method.
+
+You must also be able to forbid redefinition. A redefinable method can become non-redefinable if you declare: **is redefined static**.
+
+
+@subsubsection occt_1819379591_1972310108444 Deferred Classes and Methods
+
+The presence of certain classes in the inheritance graph can be justified purely by their ability to force certain behavior on other classes, in other words, to make other classes provide various services.
+
+The CDL language allows you to describe a class, which introduces methods without implementing them, so as to force its descendent classes to define them. These are called **deferred classes**; the non-implemented methods are also termed **deferred methods**.
+**Example**
+
+declaration-of-a-deferred-class ::=
+**deferred class **class-name
+ [**inherits **class-name
+[**uses **data-type {’,’ data-type}]
+[**raises **exception-name {’,’ exception-name}]
+**is **class-definition
+**end **[class-name]’;’
+declaration-of-a-deferred-method ::=
+identifier formal-part-of-instance-method [returnedtype-
+declaration]
+[declaration-of-exceptions]
+**is deferred **[visibility]’;’
+
+Only instance methods can be deferred.
+
+It is sufficient for a class to contain one deferred method for it to be a deferred class. It can contain any number of deferred methods (or none).
+
+A deferred class may still have an internal representation but one or more **non-** **protected **constructors would be necessary to initialize them. The constructors must be visible in the sub-classes.
+
+The constructors of a deferred class are called **Initialize **(not **Create**). They are **protected **by default, and do not return any object. You cannot create an object of a deferred class type.
+For example, consider the class “Point”, and its declaration as deferred.
+**Example**
+
+deferred class Point inherits Geometry is
+Initialize;
+---Purpose: Initializes the point.
+Coord (me; X, Y, Z : out Real)
+---Purpose: Returns the coordinates
+is deferred;
+SetCoord (me : mutable; X, Y, Z : Real)
+---Purpose: Modifies the coordinates
+is deferred;
+Distance (me; P : Point) returns Real;
+---Purpose: Returns the distance from the point P
+end Point;
+
+Notice that the function “Distance” is not deferred. Although this class contains no representation, this method is programmable by calling “Coord”.
+
+In a sub-class of a deferred class, all deferred methods, which have been inherited, *must *be implemented, then redeclared (the attribute **redefined **is useless for this purpose), unless the sub-class is itself deferred.
+
+A non-deferred method can be redefined as a deferred one, in which case it will be declared as follows: **is redefined deferred**.
+
+The notion of deferred class is very useful. The advantage of introducing it, as was previously shown in the deferred class “Point”, is that the corresponding resources will be available even before being implemented. Later, you can add different representations to Point (for example, spherical or Cartesian coordinates) without having to modify client programs.
+
+Thanks to the possibility of redefining methods, this approach does not have any negative impact on performance: a method implemented at the level of a deferred class can be reprogrammed in one of its sub-classes while taking into account the data representation.
+@subsubsection occt_1819379591_1972310108445 Declaration by Association
+
+At the heart of a class hierarchy, object identifiers are compatible in the ascendant sense. Since the Conic class is descended from the Curve class, an identifier of type Curve can reference an object of type Conic (remember that the behavior of Curve is applicable to Conic). In other words, you can assign a reference to a Conic to an identifier of type Curve, but *not *vice versa.
+
+For example, once the classes have been compiled you could write a C++ test program in which you instantiate a Conic but reference it with a handle to a Curve:
+
+**Example**
+
+Handle(Curve) c = new Conic
+
+This same rule applies to parameters of methods; that is to say, you can call a method with identifiers corresponding to a sub-type of that specified in its declaration. To illustrate this, you go back to the “Distance” method of the “Point” class:
+**Example**
+
+Distance (me; P : point) returns Real;
+
+Conforming to the rule of type compatibility, you could make a call to the method “Distance” with reference to an object from a class descended from “Point”. Consequently, if “SphericPoint” is a sub-class of “Point” and therefore inherits this method, it will be possible to calculate the distance between two “SphericPoint”, or between a “SphericPoint” and a “Point”, without having to redefine the method.
+
+On the other hand, sometimes you may want to force two parameters to be exactly of the same type, and thus not apply the rule of type compatibility. To do this, you need to associate the type of the concerned parameters in the method declaration.
+**Example**
+
+association-typing ::=
+**like **associated-parameter
+associated-parameter ::=
+**me **| identifier
+
+
+NOTE
+***Note that identifier is the name of a parameter, which appears***
+***first in the formal part of the declaration of the method.***
+
+
+You can use this technique, which consists in declaring by association, to declare a method that will exchange the content of two objects, or a method, which copies another object:
+**Example**
+
+Swap (me : mutable; With : mutable like me);
+DeepCopy (me) returns mutable like me;
+
+Make sure *not *to write the Swap method as in the syntax below:
+
+**Example**
+
+Swap (me : mutable; With : mutable Point);
+
+In this case **me **may be a CartesianPoint or a SphericalPoint, while “With” can only be a Point.
+@subsubsection occt_1819379591_1972310108446 Redefinition of Fields
+
+The creation of a hierarchy of classes should be viewed as a means to specialize their behavior, (e.g. a circle is more specialized than a conic section). The more you specialize the object classes, the more it is justified to call into question the inherited fields in order to obtain greater optimization. So, in the description of the internal representation of a sub-class, it is possible not to inherit all of the fields of the super-classes. You then say the fields have been redefined.
+**Example**
+
+redefinition-of-the-representation-of-a-class ::=
+**redefined **redefinition-of-a-field {’,’ redefinition-of-a-
+field}’,’
+redefinition-of-a-field ::=
+[field-name] **from **[**class**] class-name
+
+Redefinition of fields can *only *be done in classes manipulated by a handle.
+
+This declaration appears at the beginning of the definition of the internal representation of the sub-class, which breaks the field inheritance. The non-inherited fields are all those which come from the class specified behind the rubric **from**.
+
+
+@subsection occt_1819379591_197231010845 Genericity
+
+@subsubsection occt_1819379591_1972310108451 Overview
+
+Inheritance is a powerful mechanism for extending a system, but it does not always allow you to avoid code duplication, particularly in the case where two classes differ only in the type of objects they manipulate (you certainly encounter this phenomenon in all basic structures). In such cases, it is convenient to send arbitrary parameters representing types to a class. Such a class is called a **generic class**. Its parameters are the generic types of the class.
+
+Generic classes are implemented in two steps. You first declare the generic class to establish the model, and then instantiate this class by giving information about the generic types.
+
+@subsubsection occt_1819379591_1972310108452 Declaration of a Generic Class
+
+The syntax is as follows:
+**Example**
+
+declaration-of-a-generic-class ::=
+[**deferred**] **generic class **class-name ’(’generic-type
+{’,’generic-type}’)’
+[**inherits **class-name
+[**uses **data-type {’,’ data-type}]
+[**raises **exception-name {’,’ exception-name}]
+**is **class-definition
+**end **[class-name]’;’
+generic-type ::=
+identifier **as **type-constraint
+type-constraint ::=
+**any **| class-name [’(’data-type {’,’data-type}’)’]
+
+The names of generic types become new types, which are usable in the definition of a class, both in its behavior (methods) and its representation (fields). The generic type is only visible inside the generic class introducing it. As a result, it is possible to have another generic class using the same generic type within the same package.
+When you specify the type constraint under the form of a class name, you impose a minimum set of behavior on the manipulated object.
+
+This shows that the generic type has as a minimum the services defined in the class. This can be any kind of a previously defined class, including another generic class, in which case you state exactly with what types they are instantiated.
+
+When the generic type is constrained by the attribute **any**, the generic class is intended to be used for any type at all, and thus corresponds to classes whether manipulated by a handle or by value.
+
+No class can inherit from a generic class.
+
+A generic class can be a deferred class. A generic class can also accept a deferred class as its argument. In both these cases any class instantiated from it will also be deferred. The resulting class can then be inherited by another class.
+
+Below is a partial example of a generic class: a persistent singly linked list.
+**Example**
+
+generic class SingleList (Item as Storable)
+inherits Persistent
+raises NoSuchObject
+is
+Create returns mutable SingleList;
+ ---Purpose: Creates an empty list
+IsEmpty (me) returns Boolean;
+ ---Purpose: Returns true if the list me is empty
+SwapTail (me : mutable; S : in out mutable
+SingleList)
+ ---Purpose: Exchanges the tail of list me with S
+-- Exception NoSuchObject raised when me is
+empty
+raises NoSuchObject;
+ Value (me) returns Item
+ ---Purpose: Returns first element of the list me
+-- Exception NoSuchObject raised when me is
+empty
+raises NoSuchObject;
+ Tail (me) returns mutable SingleList
+---Purpose: Returns the tail of the list me
+-- Exception NoSuchObject raised when me is
+empty
+raises NoSuchObject;
+ fields
+Data : Item;
+ Next : SingleList;
+ end SingleList;
+
+Even though no object of the type “SingleList” IS created, the class contains a constructor. This class constitutes a model, which will be recopied at instantiation time to create a new class which will generate objects. The constructor will then be required.
+**Example**
+
+generic class Sequence(Item as any, Node as
+SingleList(Item))
+inherits Object
+. . .
+end Sequence
+
+In the above example, there are two generic types: Item & Node. The first imposes no restriction. The second must at least have available the services of the class SingleList instantiated with the type with which Sequence will itself be instantiated.
+
+In the **incomplete declaration of a generic class**, the keyword **generic **must appear.
+**Example**
+
+generic class SingleList;
+generic class Sequence;
+@subsubsection occt_1819379591_1972310108453 Instantiation of a Generic Class
+
+The syntax is as follows:
+**Example**
+
+instantiation-of-a-generic-class ::=
+[**deferred**] **class **class-name
+** instantiates **class-name ’(’data-type {’,’
+data-type}’);’
+
+Instantiation is said to be **static**. In other words, it must take place before any use can be made of the type of the instantiated class. Each data type is associated term by term with those declared at the definition of the generic class. These latter ones, when they are not of the type **any**, restrict instantiation to those classes, which have a behavior at least equal to that of the class specified in the type constraint, including constructors. Note that this is not guaranteed by inheritance itself.
+
+For example, let’s instantiate the class “Sequence” for the type “Point”:
+**Example**
+
+class SingleListOfPoint instantiates SingleList(Point);
+class Sequence instantiates
+Sequence(Point,SingleListOfPoint);
+
+The instantiation of a generic deferred class is a deferred class (the **deferred **attribute must be present during instantiation). An instantiated class cannot be declared in an incomplete fashion.
+
+@subsubsection occt_1819379591_1972310108454 Nested Generic Classes
+
+It often happens that many classes are linked by a common generic type. This is the case when a base structure provides an iterator, for example, in the class “Graph”. A graph is made up of arcs, which join together the nodes, which reference objects of any type. This type is generic both for the graph and for the node. In this context, it is necessary to make sure that the group of linked generic classes is indeed instantiated for the same type of object. So as to group the instantiation, CDL allows the declaration of certain classes to be nested.
+**Example**
+
+declaration-of-a-generic-class ::=
+ [**deferred**] **generic class **class-name ’(’generic-
+type{’,’generic-type}’)’
+ [**inherits **class-name {’,’ class-name}]
+ [**uses **data-type {’,’ data-type}]
+ [**raises **exception-name {’,’ exception-name}]
+ [{[visibility] class-declaration}]
+** is **class-definition
+**end **[class-name]’;’
+ class-declaration ::=
+ incomplete-declaration-of-a-class |
+ declaration-of-a-non-generic-class |
+ instantiation-of-a-generic-class
+
+**Nested classes**, even though they are described as non-generic classes, are generic by construction, being inside the class of which they are a part. As a consequence, the generic types introduced by the **encompassing class **can be used in the definition of the nested class. This is true even if the generic type is only used in a nested class. The generic types still* must *appear as an argument of the encompassing class. All other types used by a nested class *must *appear in its **uses **or **raises **clauses, just as if it were an independent class.
+
+Nested classes are, by default, **public**. In other words, they can be used by the clients of the encompassing class. On the other hand, when one of the nested classes is declared **private **or **protected**, this class *must not *appear in any of the public methods of the other classes. It cannot be used in a protected field because then it could be used in a sub-class, which implies it would not be private.
+
+The following example shows how to write the Set class with its iterator.
+**Example**
+
+generic class Set (Item as Storable)
+inherits Persistent
+private class Node instantiates SingleList (Item);
+class Iterator
+ uses Set, Node
+ raises NoSuchObject, NoMoreObject
+ is
+ Create (S : Set) returns mutable Iterator;
+---Purpose: Creates an iterator on the group S
+ More (me) returns Boolean;
+---Purpose: Returns true if there are still elements
+ -- to explore
+ Next (me) raises NoMoreObject;
+---Purpose: Passes to the following element
+ Value (me) returns any Item raises NoSuchObject;
+---Purpose: Returns the current element
+ fields
+ Current : Node;
+end Iterator;
+is
+ Create returns mutable Set;
+---Purpose: Creates an empty group
+ IsEmpty (me) returns Boolean;
+---Purpose: Returns true if the group is empty
+ Add (me : mutable; T : Item);
+---Purpose: Adds an item to the group me
+ Remove (me : mutable; T : item) raises
+NoSuchObject;
+---Purpose: Removes an item from the group me
+ etc.
+ fields
+ Head : Node;
+end Set;
+
+Note that in their fields, both “Set” and “Iterator” are clients of another class, “Node”. This last can be effectively declared **private **for it only appears in fields which are themselves private.
+
+The instantiation of a generic class containing nested classes remains unchanged. The same declaration is used to instantiate the encompassing class and the nested classes. These latter will have their name suffixed by the name supplied at instantiation, separated by “Of”. For example, you instantiate the class “Set” described above for the type “Point” as follows:
+**Example**
+
+class SetOfPoint instantiates Set(Point);
+
+In doing so, you implicitly describe the classes “NodeOfSetOfPoint” and “IteratorOfSetOfPoint”, which are respectively the result of the concatenation of “Node” and “Iterator” with “Of” then “SetOfPoint”.
+
+Note that in the incomplete declaration of an encompassing class, all the names of the nested classes *must *appear behind that of the encompassing class.
+
+incomplete-declaration-of-a-generic-class ::=
+[**deferred**] **generic **class-name {’,’ class-name};
+
+For example, an incomplete declaration of the above class “Set” would be as in the example below:
+**Example**
+
+generic class Set, Node, Iterator;
+
+Only the encompassing class can be deferred. In the above example only the class “Set” can be deferred.
+
+
+
+@subsection occt_1819379591_197231010846 Visibility
+
+@subsubsection occt_1819379591_1972310108461 Overview
+
+A field, method, class, or package method is only available for use if it is **visible**.
+Each of these components has a default visibility, which can be explicitly modified during class or package declaration. The three possible states of visibility are:
+
+ * Public
+ * Private
+ * Protected
+
+@subsubsection occt_1819379591_1972310108462 Visibility of Fields
+
+A field is **private**. It can never be public - this would destroy the whole concept of data encapsulation. The attribute **private **is redundant when it is applied to a field. This means that a field is only visible to methods within its own class.
+A field can be declared **protected **which means that it becomes visible in subclasses of its own class. Its contents can be modified by methods in subclasses.
+
+field ::=
+identifier {’,’ identifier} ’:’ data-type
+[’[’integer{’,’integer}’]’]
+[**is protected**]’;’
+Example
+
+fields
+ Phi, Delta, Gamma : AngularMomenta [3]
+ is protected ;
+
+
+@subsubsection occt_1819379591_1972310108463 Visibility of Methods
+
+Methods act on fields. Only methods belonging to a class can act on the fields of the class; this stems from the principle of object encapsulation. Methods can be characterized in three ways: by default, methods are **public**. Methods can be declared **private **or **protected **to restrict their usage.
+
+**Public methods **Are the default and are generally the most common. They describe the behavior of a class or a package, and they are callable by any part of a program.
+
+**Private methods **Exist only for the internal structuring of their class or their package. Private class methods can only be called by methods belonging to the same class. Private package methods can only be called by all methods belonging to the same package and its classes.
+
+**Protected methods **Are private methods, which are also callable from the interior of descendent classes.
+
+If you want to restrict the usage of a method, you associate with it a visibility as follows :
+
+-- declaration-of-the-visibility ::=
+**is **visibility
+visibility ::= **private **| **protected**
+
+The declaration of the visibility of a method appears at the end of its definition, before the final semi-colon. The attribute **private **indicates that the method will only be visible to the behavior of the class of which the method is a member; **protected **will propagate the visibility among the sub-classes of this class.
+
+For example, add to the class “Line” an internal method allowing the calculation of the perpendicular distance to the power of two, from the line to a point.
+**Example**
+
+SquareDistance (me; P : Point) returns Real
+@subsubsection occt_1819379591_1972310108464 Visibility of Classes, Exceptions, & Enumerations
+
+The visibility of a class is the facility to be able to use this class in the definition of another class. The visibility of a class extends from the beginning of its declaration up to the end of the package in which it appears. You have seen that the keyword **uses **allows extension of this visibility to other packages.
+
+As was explained in the section on “<a href="#Name_Space">Name Space</a>”, any ambiguity, which arises from having two classes with the same name coming from different packages, is dealt with by the use of the keyword **from**.
+
+A class declared **private **is only available within its own package.
+
+@subsubsection occt_1819379591_1972310108465 Friend Classes & Methods
+
+In certain cases, methods need to have direct access to the private or protected parts of classes of which they are clients. Such a method is called a **friend **of the class, which is accessed. For example, you declare a method to be a friend when a service can only be obtained via the use of another non-descendent class, or perhaps when this will help to improve performance.
+
+Classes can also be declared friends of other classes. In this case all the methods of the friend class will have access to the fields and methods of the host class. The right is **not reciprocal**.
+
+Friend classes or methods are declared inside the class, which reveals its private and protected data or methods to them. This helps in managing the continuing evolution of a class, helping to recognize and to avoid the creation of side effects.
+**Example**
+
+declaration-of-friends ::=
+**friends **friend {’,’friend}
+ friend ::=
+ identifier **from **[**class**] class-name [formal-part] |
+**Defining the Software Components 67**
+identifier **from **[**package**] package-name [formal-part] |
+** class**] class-name
+ formal-part ::=
+ simple-formal-part |
+ formal-part-of-instance-method |
+ formal-part-of-class-method
+
+The formal part *must *be presented if the method contains one; thus this can be overloaded without necessarily propagating the friend relationship among its homonyms. The keyword **class **allows you to avoid certain ambiguities. For example, it removes any confusion between “method M from class C” and “method M from package P”.
+
+As an example, take a method, which calculates the perpendicular distance between a line and a point. Suppose this method needs to access the fields of the point. In the class “Point” you would write:
+**Example**
+
+friends Distance from Line (me; P : Point)
+
+A method can be a friend to many classes. The class to which the method belongs does *not *need to appear in the **uses **clause of other classes of which it is a friend.
+ <table>
+ <tr>
+ <td>
+
+ </td>
+ </tr>
+ <tr>
+ <td>
+
+ </td>
+ <td>
+ 
+ </td>
+ </tr>
+</table> When the methods of a class are all friends of another class, you can establish the friendship at the level of the class.
+
+
+
+Figure 9. Visibility of various components
+@section occt_1819379591_858765726 Appendix A. Syntax Summary
+
+
+
+This summary of the CDL syntax will aid in the comprehension of the language, but does *not *constitute an exact definition thereof. In particular, the grammar described here accepts a super-set of CDL constructors semantically validated.
+
+(1) capital ::=
+’A’ | ’B’ | ’C’ | ’D’ | ’E’ | ’F’ | ’G’ | ’H’ |
+’I’ | ’J’ | ’K’ | ’L’ | ’M’ | ’N’ |
+’O’ | ’P’ | ’Q’ | ’R’ | ’S’ | ’T’ | ’U’ | ’V’ |
+’W’ | ’X’ | ’Y’ | ’Z’
+
+(2) non-capital ::=
+’a’ | ’b’ | ’c’ | ’d’ | ’e’ | ’f’ | ’g’ | ’h’ |
+’i’ | ’j’ | ’k’ | ’l’ | ’m’ | ’n’ |
+’o’ | ’p’ | ’q’ | ’r’ | ’s’ | ’t’ | ’u’ | ’v’ |
+’w’ | ’x’ | ’y’ | ’z’
+
+(3) digit ::=
+’0’ | ’1’ | ’2’ | ’3’ | ’4’ | ’5’ | ’6’ | ’7’ |
+’8’ | ’9’
+
+(4) underscore ::=
+’_’
+
+(5) special character ::=
+’ ’ | ’!’ | ’”’ | ’#’ | ’$’ | ’%’ | ’&’ | ’’’ |
+’(’ | ’)’ | ’*’ | ’+’ | ’,’ | ’-’ |
+’.’ | ’/’ | ’:’ | ’;’ | ’’ | ’=’ | ’’ | ’?’ |
+’@’ | ’[’ | ’\’ | ’]’ | ’^’ | ’‘’ |
+’{’ | ’|’ | ’}’ | ’~’
+
+(6) printable character::=
+capitals | non-capitals | digits | underscore |
+special characters
+
+(7) letter ::=
+capital | non-capital
+
+(8) alphanumeric ::=
+letter | digit
+
+(9) identifier ::=
+letter{[underscore]alphanumeric}
+
+(10) integer ::=
+digit{digit}
+
+(11) exponent ::=
+’E’[’+’]integer | ’E-’integer
+
+(12) numeric-constant ::=
+[’+’]integer ’.’ integer[exponent] | ’-’integer
+’.’ integer[exponent]
+
+
+(13) literal-constant ::=
+’’’printable character’’’ | ’~’{printable
+character}’~’
+
+(14) package-name ::=
+identifier
+
+(15) enumeration-name ::=
+identifier [**from**** **package-name]
+
+(16) class-name ::=
+identifier [**from**** **package-name]
+
+(17) exception-name ::=
+identifier [**from**** **package-name]
+
+(18) constructor-name ::=
+’Create’ | ’Initialize’
+
+(19) primitive-type ::=
+’Boolean’ | ’Character’ | ’Integer’ | ’Real’
+
+(20) data-type ::=
+enumeration-name | class-name | exception-name
+| primitive-type
+
+(21) passed-type ::=
+data-type | **like me**** **| **like**** **identifier
+
+(22) passing-mode ::=
+[**in**] | **out**** **| **in out**
+
+(23) parameter-access ::=
+**mutable**** **| [**immutable**]
+
+(23A) return-access ::=
+**mutable**** **| [**immutable**]| **any**
+
+(24) value ::=
+numeric-constant | literal-constant |
+identifier
+
+(25) parameter ::=
+identifier {’,’ identifier} ’:’ passing-mode
+access-right passed-type [’=’ value]
+
+(26) simple-formal-part ::=
+’(’parameter {’;’ parameter}’)’
+
+(27) formal-part-of-instance-method ::=
+’(’**me**** **[’:’ passing-mode access-right] {’;’
+parameter}’)’
+
+(28) formal-part-of-class-method ::=
+’(’**myclass**** **{’;’ parameter}’)’
+
+(29) visibility ::=
+**private**** **| **protected**
+(30) redefinition ::=
+**static**** **| **deferred**
+(31) definition-level ::=
+redefinition |** ****redefined**** **[redefinition]
+
+(32) declaration-of-constructed-type ::=
+**returns**** **[**mutable**] class-name
+
+(33) declaration-of-returned-type ::=
+**returns**** **return-access passed-type
+
+(34) declaration-of-errors ::=
+**raises**** **exception-name {’,’ exception-name}
+
+(35) declaration-of-visibility ::=
+**is**** **visibility
+
+(36) declaration-of-attributes-of-instance-method ::=
+**is**** **visibility | **is **definition-of-level
+[visibility]
+
+(37) constructor ::=
+constructor-name [simple-formal-part]
+[declaration-of-constructed-type]
+[declaration-of-errors]
+[declaration-of-visibility]’;’
+
+(38) instance-method ::=
+identifier formal-part-of-instance-method
+[declaration of returned type]
+[declaration-of-errors]
+[declaration-of-attributes-of-instancemethod]’;’
+
+(39) class-method ::=
+identifier formal-part-of-the-class-method
+[declaration of returned type]
+[declaration-of-errors]
+[declaration-of-visibility]’;’
+
+(40) package-method ::=
+identifier [simple-formal-part]
+[declaration-of-returned-type]
+[declaration-of-errors]
+[**is private**]’;’
+
+(41) member-method ::=
+constructor | instance-method | class-method
+
+(42) formal-part ::=
+simple-formal-part |
+formal-part-of-instance-method|
+formal-part-of-class-method
+
+(43) friend ::=
+identifier **from**** **[**class**] class-name [formal-part]
+|
+identifier **from**** **[**package**] package-name [formal-
+part] |
+[**class**] class-name
+
+(44) field ::=
+identifier {’,’ identifier} ’:’ data-type
+[’[’integer {’,’ integer}’]’]
+[**is protected**]’;’
+
+45) redefinition-of-field ::=
+[field-name] **from**** **[**class**] class-name
+
+(46) declaration-of-fields ::=
+**fields**** **[**redefined**** **redefinition-of-field {’,’
+redefinition-of-field}’;’]
+field {field}
+
+(47) declaration-of-an-alias::=
+[**private**] **alias**** **class-name1 **is**** **class-name2 [**from**
+package-name]
+
+(48) declaration-of-friends ::=
+**friends**** **friend {’,’ friend}
+
+(49) class-definition ::=
+[{member-method}]
+[declaration-of-fields]
+[declaration-of-friends]
+
+(50) declaration-of-an-exception ::=
+**exception**** **exception-name
+**inherits**** **exception-name
+
+(51) declaration-of-an-enumeration ::=
+**enumeration**** **enumeration-name
+**is**** **identifier {’,’ identifier}
+[**end**** **[enumeration-name]]’;’
+
+(52) incomplete-declaration-of-a-non-generic-class ::=
+[**deferred**] **class**** **class-name’;’
+
+(53) incomplete-declaration-of-a-generic-class ::=
+[**deferred**] **generic class**** **class-name {’,’ class-name}’;’
+
+(54) declaration-of-a-non-generic-class ::=
+[**deferred**] **class**** **class-name
+[**inherits**** **class-name
+[**uses**** **data-type {’,’ data-type}]
+[**raises**** **exception-name {’,’ exception-name}]
+** is **definition-of-a-class
+**end **[class-name]’;’
+
+(55) type-constraint ::=
+**any**** **| class-name [’(’data-type {’,’ data-type}’)’]
+
+(56) generic-type ::=
+identifier **as**** **type-constraint
+@section occt_1819379591_2139552861 Appendix B.
+
+
+
+@subsection occt_1819379591_213955286151 Comparison of CDL & C++ Syntax for Data Types manipulated by Handle and by Value
+
+ <table>
+ <tr>
+ <td>
+
+ </td>
+ </tr>
+ <tr>
+ <td>
+
+ </td>
+ <td>
+ 
+ </td>
+ </tr>
+</table>
+
--- /dev/null
+ Developer Guides {#dev_guides}
+================
+
+@section OCCT_OVW_SECTION1 Source Repository
+
+This directory contains sources of Open CASCADE Technology (OCCT), a collection
+of C++ libraries providing services for 3D surface and solid modeling, CAD data
+exchange, and visualization. OCCT can be best applied in development of
+software dealing with 3D modeling (CAD), manufacturing / measuring (CAM) or
+numerical simulation (CAE).
+
+The OCCT code is subject to the Open CASCADE Technology Public License Version
+6.6 (the "License"). You may not use the content of the relevant files except in
+compliance with the License. Please see the LICENSE file or obtain a copy of the
+License at http://www.opencascade.org and read it completely before using this
+software.
+
+@section OCCT_OVW_SECTION11 Building OCCT Libraries
+
+The source package of the Open CASCADE Technology including the source files of samples
+and tools and the set of building procedures is available for self-dependent preparation
+binary files on UNIX and Windows platforms.
+
+In order to build OCCT libraries from these sources for use in your program,
+you need to:
+
+1. Install the required third-party libraries.
+
+ Follow the instructions provided in the documents titled "Building 3rd party
+ products for OCCT" on http://dev.opencascade.org/?q=home/resources for
+ choice of the needed libraries, their installation and building.
+
+2. If you use OCCT sources from Git repository or do come changes affecting
+ CDL files or dependencies of OCCT toolkit, update header files generated
+ from CDL, and regenerate build scripts for your environment using WOK.
+ See \subpage dev_guides__wok "WOK" for details.
+
+ Skip to step 3 if you use complete source package (e.g. official OCCT
+ release) without changes in CDL.
+
+3. Build using your preferred build tool.
+ - \subpage dev_guides__building__automake "Building on Linux with Autotools"
+ - \subpage dev_guides__building__cmake "Building with CMake (cross-platform)"
+ - \subpage dev_guides__building__code_blocks "Building on Mac OS X with Code::Blocks"
+ - \subpage dev_guides__building__msvc "Building on Windows with MS Visual Studio 2005-2012"
+ - \subpage dev_guides__building__xcode "Building on Mac OS X with Xcode"
+
+The current version of OCCT can be consulted in the file src/Standard/Standard_Version.hxx
+
+@section OCCT_OVW_SECTION111 Automatic tests
+
+OCCT automatic testing system is integrated with @ref draw "DRAW Test Harness",
+a console application based on Tcl (a scripting language).
+All tests are run from DRAW command prompt (run **draw.bat** or
+**draw.sh** to start it).
+
+Standard OCCT tests are located in subdirectory **tests** of the OCCT root
+folder. This location is set as default at DRAW start (see environment variable
+_CSF_TestScriptsPath_ defined in **src/DrawResources/DrawDefaults**).
+
+The tests are organized in three levels:
+- Group: a group of related test grids, usually testing a particular subset of OCCT functionality (e.g. *blend*).
+- Grid: a set of test cases within a group, usually aimed at testing a particular aspect or mode of execution of the relevant functionality (e.g. *buildevol*).
+- Test case: a script implementing an individual test (e.g. *K4*).
+
+To run all tests, type command *testgrid*:
+
+ Draw[]\> testgrid
+
+For running only a group or a grid of tests, give additional arguments indicating the group and (if needed) the grid name:
+
+ Draw[]\> testgrid blend simple
+
+As the tests progress, the result of each test case is reported.
+At the end of the log a summary of test cases is output, including the list of
+detected regressions and improvements, if any.
+The tests are considered as non-regressive if only OK, BAD (i.e. known problem),
+and SKIPPED (i.e. not executed, typically because of lack of a data file)
+statuses are reported.
+
+To run a single test, type command 'test' followed by the names of
+group, grid, and test case.
+
+ Draw[1]\> test blend simple A1
+ CASE blend simple A1: OK
+
+To see intermediate commands and their output during the test execution,
+add one more argument '-echo' at the end of the command line, or type 'dlog get'
+after test completion.
+
+For more information consult \subpage dev_guides__tests "Automatic Testing System"
+
+@section OCCT_OVW_SECTION1112 CDL Overview
+
+CDL is the component definition language of the Open CASCADE Technology (OCCT) programming platform.
+Some components, which CDL allows you to create, are specific to OCCT application architecture.
+
+For more information consult \subpage dev_guides__cdl "Component Definition Language Developer's Guide"
+
+@section OCCT_OVW_SECTION1113 Documentation Overview
+
+\subpage dev_guides__documentation "Documentation Developer's Guide"
--- /dev/null
+ Documentation {#dev_guides__documentation}
+=================
+
+@section OCCT_DM_SECTION_1 Introduction
+
+This document provides practical guidenes for generation and editing of OCCT user documentation.
+
+@section OCCT_DM_SECTION_2 Prerequisites
+
+<b>Tcl/Tk</b>
+The lates version: http://www.tcl.tk/software/tcltk/download.html
+
+<b>Doxygen</b> ( >= 1.8.4 )
+The latest version: http://www.stack.nl/~dimitri/doxygen/download.html
+
+<b>MathJax</b> (used for rendering math formulas in browser). Download it for local installation or use the MathJax Content Delivery Network. \(read
+@htmlonly <a href="#OCCT_DM_SECTION_A_9">Formulas</a> @endhtmlonly paragraph for more detailed description\).
+The latest version: http://www.mathjax.org/download/
+
+<b>MiKTeX</b> or equivalent tool (used for PDF document creation)
+Latest version: http://miktex.org/download
+
+@section OCCT_DM_SECTION_2_1 Documentation Generation
+
+Run gendoc.bat from OCCT directory to generate all articles are defined in FILES.txt:
+
+gendoc.bat options:
+
+ * -html : To generate HTML files (cannot be used with -pdf);
+ * -pdf : To generate PDF files (cannot be used with -html);
+ * -m=<modules_list> : Specifies list of articles to generate. If it is not specified, all files, mentioned in FILES.txt are processed;
+ * -l=<document_name> : Specifies the article caption for a single document;
+ * -h : Prints help message;
+ * -v : Specifies the Verbose mode (info on all script actions is shown).
+
+If you run the command without arguments (like example above) it will generate HTML documentation
+for all articles are defined into FILES.txt.
+
+**Note**: the generation process generates PDF files for each article,
+but in html case it generates common Html page with references to the ones.
+
+For generation of specific article you need:
+ * have it's name with relative path (from \%OCCDIR\%/dox/ to the file) contained in FILES.txt
+ (is located into \%OCCDIR\%/dox/ directory).
+
+@verbatim
+devs_guid/documentation/documentation.md
+@endverbatim
+
+where documentation .md is name of article and devs_guid/documentation/ is relative path of it
+
+ * use this name with -m option in the generation process:
+
+@verbatim
+% gen.bat -html -m=devs_guid/documentation/documentation.md
+@endverbatim
+
+Multiple files are separated with comma:
+
+@verbatim
+% gen.bat -html -m=MD_FILE_1,MD_FILE_2
+@endverbatim
+
+To sepcify a article name with -l option, use tcl list to prevent whitespaces incorrect interpretation:
+
+@verbatim
+% gen.bat -pdf -m=MD_FILE_1 -l=[list MD File 1 Label]
+@endverbatim
+
+@section OCCT_DM_SECTION_3 Documentation Conventions
+
+This section contains information about conventions in the field of OCCT documentation file format,
+structure of documentation directories, etc.
+
+@subsection OCCT_DM_SECTION_3_1 File Format
+
+It is proposed to use MarkDown file format for easy maintainance of generic text documents.
+The MarkDown files have a "*.md" extension and are based on rules desribed in
+@htmlonly <a href="#OCCT_DM_SECTION_A">Document Syntax</a> @endhtmlonly section.
+
+@subsection OCCT_DM_SECTION_3_2 Directory Structure
+
+
+
+Every separate article has own folder if images are used in it. These images
+are stored into "images" subfolder.
+
+If you want to use the same image for several articles, you can place the one into "dox/resources" folder.
+
+**Note**: Every article can use any image that is used by others articles. To avoid incorrect image
+displaying, use relative path to the image (starting from dox folder). For instance
+@verbatim
+
+@endverbatim
+
+Result of generation of the documentation is:
+
+%OCCT_DIR% / doc - a folder for generated articles;
+ * html/ - a directory for generated HTML pages;
+ * pdf/ - a directory for generated PDF files.
+
+@section OCCT_DM_SECTION_4 Adding a New Article
+
+ - Place a new article into folder that is chosen taking into account the place of the article
+at the hierarchy of the documentation. For instance the article about "using SVN working with OCCT
+source code" (svn.md - the file of the article) might be placed into /dox/devs_guide/ . If the article has images then you may create
+the own folder of the article and subfolder in it for images. For instance
+*/dox/devs_guide/svn/ - for svn.md file
+*/dox/devs_guide/svn/images/ - for images
+
+ - Update dox/FILES.txt to add relative path to svn.md. For instance
+@verbatim
+devs_guide/snv/svn.md
+@endverbatim
+
+**Note**: the place of the relative path to an article is connected with the place
+into treeview of html version.
+
+
+Note, that you should specify a file tag, not the document name.
+See <a href="#OCCT_DM_SECTION_A_1">Header section</a> for details.
+
+@section OCCT_DOC_SECTION_5 Additional Resources
+
+More information about OCCT can be found at http://www.opencascade.org
+
+The information on formula syntax can be found at:
+http://en.wikipedia.org/wiki/Help:Displaying_a_formula
+
+More information on MarkDown and Doxygen syntax can be found at:
+http://www.stack.nl/~dimitri/doxygen/manual
+
+
+@section OCCT_DM_SECTION_A Appendix 1: Document Syntax
+
+Each OCCT document file in *.md format has a simple structure.
+It can contain:
+
+| Content type | Obligation |
+| :---------------- | :-------------------: |
+| Header | M |
+| Footer | M |
+| Plain text | O |
+| List | O |
+| Table | O |
+| Code | O |
+| Formula | O |
+| Image | O |
+| Page numbers | M (auto generation) |
+| Table of contents | M (auto generation) |
+
+The legend:
+
+ * M is for Mandatory
+ * O is for Optional
+
+@subsection OCCT_DM_SECTION_A_1 Text Caption (a header)
+
+headings of different levels can be specified with the following code:
+
+@verbatim
+Header 1 {#header1}
+=======
+@endverbatim
+
+ to get
+
+ Header 1
+=========
+
+ and with the following code:
+
+@verbatim
+Header 2 {#header2}
+--------
+@endverbatim
+
+to get
+
+Header 2
+---------
+
+Where a word in curly braces is a MarkDown-style reference, which can be used in table of contents.
+If you would like to have the table of contents, it is recommended to use \@section,
+\@subsection and \@subsubsection pages instead of MarkDown headers as follows:
+
+@verbatim
+ @section Section_Name Section Header
+ @subsection SubSection_Name SubSection Header
+ @subsubsection SubSubSection_Name SubSubSection Header
+@endverbatim
+
+@subsection OCCT_DM_SECTION_A_2 Plain Text
+
+Plain text is a text in a notepad-like format. To insert special symbols,
+like \< , \> or \\, prepend them with \\ character: \\\<, \\\>, \\\\
+To emphasize some words, write one pair of asterisks ( * ) or underscores ( _ ) across the word
+to make it *italic* and two pairs of these symbols to make a word **Bold**.
+
+@subsection OCCT_DM_SECTION_A_3 Lists
+
+To create a bulleted list, start each line with a hyphen or an asterisk,
+followed by a space. List items can be nested. This code:
+
+@verbatim
+ * Bullet 1
+ * Bullet 2
+ * Bullet 2a
+ * Bullet 2b
+ * Bullet 3
+@endverbatim
+
+ produces this list:
+
+ * Bullet 1
+ * Bullet 2
+ * Bullet 2a
+ * Bullet 2b
+ * Bullet 3
+
+To create a numbered list, start each line with number and a period, then a space. Thus this code
+
+@verbatim
+ 1. ListItem_1
+ 2. ListItem_2
+ 3. ListItem_3
+@endverbatim
+
+ produces this list:
+
+ 1. ListItem_1
+ 2. ListItem_2
+ 3. ListItem_3
+
+It is recommended to indent lists with 2 spaces.
+
+@subsection OCCT_DM_SECTION_A_4 Tables
+
+A table consists of a header line, a separator line, and at least one row line.
+Table columns are separated by the pipe (|) character. The following example:
+
+@verbatim
+First Header | Second Header
+------------- | -------------
+Content Cell | Content Cell
+Content Cell | Content Cell
+@endverbatim
+
+ will produce the following table:
+
+First Header | Second Header
+------------ | -------------
+Content Cell | Content Cell
+Content Cell | Content Cell
+
+Column alignment can be controlled via one or two colons at the header separator line:
+
+@verbatim
+| Right | Center | Left |
+| ----: | :----: | :---- |
+| 10 | 10 | 10 |
+| 1000 | 1000 | 1000 |
+@endverbatim
+
+which will looks as follows:
+
+| Right | Center | Left |
+| ----: | :----: | :---- |
+| 10 | 10 | 10 |
+| 1000 | 1000 | 1000 |
+
+@subsection OCCT_DM_SECTION_A_5 Code Blocks
+
+It is recommended to indent a code lines with 4 spaces.
+A fenced code block does not require indentation, and is defined by a pair of "fence lines".
+Such line consists of 3 or more tilde (~) characters on a line.
+The end of the block should have the same number of tildes. Here is an example:
+
+~~~~~~~~~~~~~~~~~~~~~~~
+ a one-line code block
+~~~~~~~~~~~~~~~~~~~~~~~
+
+By default the output is the same as for a normal code block.
+To highlight the code, the developer has to indicate the typical file extension,
+which corresponds to the programming language, after the opening fence.
+For highlighting according to the C++ language, for instance, write the following code (the curly braces and dot are optional):
+
+@verbatim
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ int func(int a,int b) { return a*b; }
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+@endverbatim
+
+which will produce:
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ int func(int a,int b) { return a*b; }
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Verbatim content can be written by using framing \@verbatim \@endverbatim . For instance
+
+@verbatim
+ verbatim text
+@endverbatim
+
+@subsection OCCT_DM_SECTION_A_6 References
+
+To insert a reference to a website, it is proposed to write a URL. For example: http://en.wikipedia.org
+To insert a reference to another part of the same document, the developer can write:
+
+@verbatim
+ @htmlonly
+ <a href="#OCCT_DOC_SECTION_5">Doxygen Configuration file</a>
+ @endhtmlonly
+@endverbatim
+
+to get a link to paragraph : @htmlonly <a href="#OCCT_DOC_SECTION_5">Doxygen configuration</a> @endhtmlonly
+
+@subsection OCCT_DM_SECTION_A_7 Images
+
+To insert image into document the developer can write the following code(in Doxygen-style):
+@verbatim
+
+@endverbatim
+
+This code tells Doxygen to insert a picture right in the place this code was written. Like this:
+@verbatim
+
+@endverbatim
+
+
+
+@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.
--- /dev/null
+ Automated Testing System {#dev_guides__tests}
+======================================
+
+@section testmanual_1 Introduction
+
+This document provides overview and practical guidelines for work with OCCT automatic testing system.
+Reading this section *Introduction* should be sufficient for OCCT developers to use the test system
+to control non-regression of the modifications they implement in OCCT. Other sections provide
+more in-depth description of the test system, required for modifying the tests and adding new test cases.
+
+@subsection testmanual_1_1 Basic Information
+
+OCCT automatic testing system is organized around DRAW Test Harness [1],
+a console application based on Tcl (a scripting language) interpreter extended by OCCT-related commands.
+Standard OCCT tests are included with OCCT sources and are located in subdirectory *tests*
+ of the OCCT root folder. Other test folders can be included in the scope of the test system,
+ e.g. for testing applications based on OCCT.
+Logically the tests are organized in three levels:
+
+ * Group: group of related test grids, usually relating to some part of OCCT functionality (e.g. blend)
+ * Grid: set of test cases within a group, usually aimed at testing some particular aspect or mode of execution of the relevant functionality (e.g. buildevol)
+ * Test case: script implementing individual test (e.g. K4)
+
+Some tests involve data files (typically CAD models) which are located separately
+ and are not included with OCCT code. The archive with publicly available
+ test data files should be downloaded and installed independently on OCCT code from dev.opencascade.org.
+
+@subsection testmanual_1_2 Intended Use of Automatic Tests
+
+Each modification made in OCCT code must be checked for non-regression
+by running the whole set of tests. The developer who does the modification
+is responsible for running and ensuring non-regression on the tests that are available to him.
+Note that many tests are based on data files that are confidential and thus available only at OPEN CASCADE.
+Thus official certification testing of the changes before integration to master branch
+of official OCCT Git repository (and finally to the official release) is performed by OPEN CASCADE in any case.
+
+Each new non-trivial modification (improvement, bug fix, new feature) in OCCT
+should be accompanied by a relevant test case suitable for verifying that modification.
+This test case is to be added by developer who provides the modification.
+If a modification affects result of some test case(s),
+either the modification should be corrected (if it causes regression)
+or affected test cases should be updated to account for the modification.
+
+The modifications made in the OCCT code and related test scripts
+should be included in the same integration to master branch.
+
+@subsection testmanual_1_3 Quick Start
+
+@subsubsection testmanual_1_3_1 Setup
+
+Before running tests, make sure to define environment variable CSF_TestDataPath
+pointing to the directory containing test data files.
+(The publicly available data files can be downloaded
+from http://dev.opencascade.org separately from OCCT code.)
+The recommended way for that is adding a file *DrawInitAppli*
+in the directory which is current at the moment of starting DRAWEXE (normally it is $CASROOT).
+This file is evaluated automatically at the DRAW start. Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+set env(CSF_TestDataPath) d:/occt/tests_data
+return ;# this is to avoid an echo of the last command above in cout
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+All tests are run from DRAW command prompt, thus first run draw.tcl or draw.sh to start DRAW.
+
+@subsubsection testmanual_1_3_2 Running Tests
+
+To run all tests, type command *testgrid* followed by path
+to the new directory where results will be saved.
+It is recommended that this directory should be new or empty;
+use option –overwrite to allow writing logs in existing non-empty directory.
+
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ Draw[]> testgrid d:/occt/results-2012-02-27
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If empty string is given as log directory name, the name will be generated automatically
+using current date and time, prefixed by *results_*. Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ Draw[]> testgrid {}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+For running only some group or a grid of tests,
+give additional arguments indicating group and (if needed) grid. Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ Draw[]> testgrid d:/occt/results-2012-02-28 blend simple
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+As the tests progress, the result of each test case is reported.
+At the end of the log summary of test cases is output,
+including list of detected regressions and improvements, if any. Example:
+
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ Tests summary
+
+ CASE 3rdparty export A1: OK
+ ...
+ CASE pipe standard B1: BAD (known problem)
+ CASE pipe standard C1: OK
+ No regressions
+ Total cases: 208 BAD, 31 SKIPPED, 3 IMPROVEMENT, 1791 OK
+ Elapsed time: 1 Hours 14 Minutes 33.7384512019 Seconds
+ Detailed logs are saved in D:/occt/results_2012-06-04T0919
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The tests are considered as non-regressive if only OK, BAD (i.e. known problem),
+and SKIPPED (i.e. not executed, e.g. because of lack of data file) statuses are reported.
+See <a href="#testmanual_3_4">Grid’s *cases.list* file</a> chapter for details.
+
+The detailed logs of running tests are saved in the specified directory and its sub-directories.
+Cumulative HTML report summary.html provides links to reports on each test case.
+An additional report TESTS-summary.xml is output in JUnit-style XML format
+that can be used for integration with Jenkins or other continuous integration system.
+Type *help testgrid* in DRAW prompt to get help on additional options supported by testgrid command.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ Draw[3]> help testgrid
+ testgrid: Run all tests, or specified group, or one grid
+ Use: testgrid logdir [group [grid]] [options...]
+ Allowed options are:
+ -verbose {0-2}: verbose level, 0 by default, can be set to 1 or 2
+ -parallel N: run in parallel with up to N processes (default 0)
+ -refresh N: save summary logs every N seconds (default 60)
+ -overwrite: force writing logs in existing non-empty directory
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@subsubsection testmanual_1_3_3 Running Single Test
+
+To run single test, type command *test*’ followed by names of group, grid, and test case.
+
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ Draw[1]> test blend simple A1
+ CASE blend simple A1: OK
+ Draw[2]>
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Note that normally intermediate output of the script is not shown.
+To see intermediate commands and their output, type command *decho on*
+before running the test case. (Type ‘decho off’ to disable echoing when not needed.)
+The detailed log of the test can also be obtained after the test execution by command *dlog get*.
+
+@section testmanual_2 Organization of Test Scripts
+
+@subsection testmanual_2_1 General Layout
+
+Standard OCCT tests are located in subdirectory tests of the OCCT root folder ($CASROOT).
+Additional test folders can be added to the test system
+by defining environment variable CSF_TestScriptsPath.
+This should be list of paths separated by semicolons (*;*) on Windows
+or colons (*:*) on Linux or Mac. Upon DRAW launch,
+path to tests sub-folder of OCCT is added at the end of this variable automatically.
+Each test folder is expected to contain:
+
+ * Optional file parse.rules defining patterns for interpretation of test results, common for all groups in this folder
+ * One or several test group directories.
+
+Each group directory contains:
+
+ * File grids.list that identifies this test group and defines list of test grids in it.
+ * Test grids (sub-directories), each containing set of scripts for test cases, and optional files cases.list, parse.rules, begin, and end.
+ * Optional sub-directory data
+ * Optional file parse.rules
+ * Optional files begin and end
+
+By convention, names of test groups, grids, and cases should contain no spaces and be lowercase.
+Names begin, end, data, parse.rules, grids.list, cases.list are reserved.
+General layout of test scripts is shown on Figure 1.
+
+
+
+Figure 1. Layout of tests folder
+
+@subsection testmanual_2_2 Test Groups
+
+@subsubsection testmanual_2_2_1 Group Names
+
+Test folder usually contains several directories representing test groups (Group 1, Group N).
+Each directory contains test grids for certain OCCT functionality.
+The name of directory corresponds to this functionality.
+Example:
+
+@verbatim
+ caf
+ mesh
+ offset
+@endverbatim
+
+@subsubsection testmanual_2_2_2 Group's *grids.list* File
+
+The test group must contain file *grids.list* file
+which defines ordered list of grids in this group in the following format:
+
+~~~~~~~~~~~~~~~~~
+001 gridname1
+002 gridname2
+...
+NNN gridnameN
+~~~~~~~~~~~~~~~~~
+
+Example:
+
+~~~~~~~~~~~~~~~~~
+ 001 basic
+ 002 advanced
+~~~~~~~~~~~~~~~~~
+
+@subsubsection testmanual_2_2_3 Group's *begin* File
+
+The file *begin* is a Tcl script. It is executed before every test in current group.
+Usually it loads necessary Draw commands, sets common parameters and defines
+additional Tcl functions used in test scripts.
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ pload TOPTEST ;# load topological command
+ set cpulimit 300 ;# set maximum time allowed for script execution
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@subsubsection testmanual_2_2_4 Group's *end* File
+
+The file end is a TCL script. It is executed after every test in current group.
+Usually it checks the results of script work, makes a snap-shot
+of the viewer and writes *TEST COMPLETED* to the output.
+Note: *TEST COMPLETED* string should be presented in output
+in order to signal that test is finished without crash.
+See <a href="#testmanual_3">Creation And Modification Of Tests</a> chapter for more information.
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ if { [isdraw result] } {
+ checkshape result
+ } else {
+ puts *Error: The result shape can not be built*
+ }
+ puts *TEST COMPLETED*
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@subsubsection testmanual_2_2_5 Group’s *parse.rules* File
+
+The test group may contain *parse.rules* file.
+This file defines patterns used for analysis of the test execution log
+and deciding the status of the test run.
+Each line in the file should specify a status (single word),
+followed by a regular expression delimited by slashes (*/*)
+that will be matched against lines in the test output log to check if it corresponds to this status.
+The regular expressions support subset of the Perl re syntax.
+The rest of the line can contain a comment message
+which will be added to the test report when this status is detected.
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ FAILED /\b[Ee]xception\b/ exception
+ FAILED /\bError\b/ error
+ SKIPPED /Cannot open file for reading/ data file is missing
+ SKIPPED /Could not read file .*, abandon/ data file is missing
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Lines starting with a *#* character and blank lines are ignored to allow comments and spacing.
+See <a href="#testmanual_2_3_4">Interpretation of test results</a> chapter for details.
+
+If a line matches several rules, the first one applies.
+Rules defined in the grid are checked first, then rules in group,
+then rules in the test root directory. This allows defining some rules on the grid level
+with status IGNORE to ignore messages that would otherwise be treated as errors due to the group level rules.
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ FAILED /\bFaulty\b/ bad shape
+ IGNORE /^Error [23]d = [\d.-]+/ debug output of blend command
+ IGNORE /^Tcl Exception: tolerance ang : [\d.-]+/ blend failure
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@subsection testmanual_2_3 Test Grids
+
+@subsubsection testmanual_2_3_1 Grid Names
+
+Group folder can have several sub-directories (Grid 1… Grid N) defining test grids.
+Each test grid directory contains a set of related test cases.
+The name of directory should correspond to its contents.
+
+Example:
+
+caf
+ basic
+ bugs
+ presentation
+
+Where **caf** is the name of test group and *basic*, *bugs*, *presentation*, etc are the names of grids.
+
+@subsubsection testmanual_2_3_2 Grid’s *begin* File
+
+The file *begin* is a TCL script. It is executed before every test in current grid.
+Usually it sets variables specific for the current grid.
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ set command bopfuse ;# command tested in this grid
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@subsubsection testmanual_2_3_3 Grid’s *end* File
+
+The file *end* is a TCL script. It is executed after every test in current grid.
+Usually it executes specific sequence of commands common for all tests in the grid.
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ vdump $logdir/${casename}.gif ;# makes a snap-shot of AIS viewer
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@subsubsection testmanual_2_3_4 Grid’s *cases.list* File
+
+The grid directory can contain an optional file cases.list
+defining alternative location of the test cases.
+This file should contain singe line defining the relative path to collection of test cases.
+
+Example:
+
+../data/simple
+
+This option is used for creation of several grids of tests with the same data files
+and operations but performed with differing parameters.
+The common scripts are usually located place in common
+subdirectory of the test group (data/simple as in example).
+If cases.list file exists then grid directory should not contain any test cases.
+The specific parameters and pre- and post-processing commands
+for the tests execution in this grid should be defined in the begin and end files.
+
+@subsection testmanual_2_4 Test Cases
+
+The test case is TCL script which performs some operations using DRAW commands
+and produces meaningful messages that can be used to check the result for being valid.
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ pcylinder c1 10 20 ;# create first cylinder
+ pcylinder c2 5 20 ;# create second cylinder
+ ttranslate c2 5 0 10 ;# translate second cylinder to x,y,z
+ bsection result c1 c2 ;# create a section of two cylinders
+ checksection result ;# will output error message if result is bad
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The test case can have any name (except reserved names begin, end, data, cases.list, parse.rules).
+For systematic grids it is usually a capital English letter followed by a number.
+
+Example:
+
+@verbatim
+ A1
+ A2
+ B1
+ B2
+@endverbatim
+
+Such naming facilitates compact representation of results
+of tests execution in tabular format within HTML reports.
+
+@subsection testmanual_2_5 Directory *data*
+
+The test group may contain subdirectory data.
+Usually it contains data files used in tests (BREP, IGES, STEP, etc.)
+and / or test scripts shared by different test grids
+(in subdirectories, see <a href="#testmanual_2_3_4">Grid’s *cases.list* file</a> chapter).
+
+@section testmanual_3 Creation And Modification Of Tests
+
+This section describes how to add new tests and update existing ones.
+
+@subsection testmanual_3_1 Choosing Group, Grid, and Test Case Name
+
+The new tests are usually added in context of processing some bugs.
+Such tests in general should be added to group bugs, in the grid
+corresponding to the affected OCCT functionality.
+New grids can be added as necessary to contain tests on functionality not yet covered by existing test grids.
+The test case name in the bugs group should be prefixed by ID
+of the corresponding issue in Mantis (without leading zeroes).
+It is recommended to add a suffix providing a hint on the situation being tested.
+If more than one test is added for a bug, they should be distinguished by suffixes;
+either meaningful or just ordinal numbers.
+
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ 12345_coaxial
+ 12345_orthogonal_1
+ 12345_orthogonal_2
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In the case if new test corresponds to functionality for which
+specific group of tests exists (e.g. group mesh for BRepMesh issues),
+this test can be added (or moved later by OCC team) to this group.
+
+@subsection testmanual_3_2 Adding Data Files Required for a Test
+
+It is advisable that tests scripts should be made self-contained whenever possible,
+so as to be usable in environments where data files are not available.
+For that simple geometric objects and shapes can be created using DRAW commands in the test script itself.
+If test requires some data file, it should be put to subdirectory data of the test grid.
+Note that when test is integrated to master branch,
+OCC team can move data file to data files repository,
+so as to keep OCCT sources repository clean from big data files.
+When preparing a test script, try to minimize size of involved data model.
+For instance, if problem detected on a big shape can be reproduced on a single face
+extracted from that shape, use only this face in the test.
+
+@subsection testmanual_3_3 Implementation of the Script
+
+Test should run commands necessary to perform the operations being tested,
+in a clean DRAW session. This includes loading necessary functionality by *pload* command,
+if this is not done by *begin* script. The messages produced by commands in standard output
+should include identifiable messages on the discovered problems if any.
+Usually the script represents a set of commands that a person would run interactively
+to perform the operation and see its results, with additional comments to explain what happens.
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ # Simple test of fusing box and sphere
+ box b 10 10 10
+ sphere s 5
+ bfuse result b s
+ checkshape result
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Make sure that file parse.rules in the grid or group directory contains
+regular expression to catch possible messages indicating failure of the test.
+For instance, for catching errors reported by *checkshape* command
+relevant grids define a rule to recognize its report by the word *Faulty*: FAILED /\bFaulty\b/ bad shape
+For the messages generated in the script the most natural way is to use the word *Error* in the message.
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ set expected_length 11
+ if { [expr $actual_length - $expected_length] > 0.001 } {
+ puts *Error: The length of the edge should be $expected_length*
+ }
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+At the end, the test script should output *TEST COMPLETED* string
+to mark successful completion of the script.
+This is often done by the end script in the grid.
+When test script requires data file, use Tcl procedure *locate_data_file*
+to get path to the data file, rather than explicit path.
+This will allow easy move of the data file from OCCT repository
+to the data files repository without a need to update test script.
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ stepread [locate_data_file CAROSKI_COUPELLE.step] a *
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+When test needs to produce some snapshots or other artifacts,
+use Tcl variable logdir as location where such files should be put.
+Command *testgrid* sets this variable to the subdirectory of the results folder
+corresponding to the grid. Command *test* sets it to $CASROOT/tmp unless it is already defined.
+Use Tcl variable casename to prefix all the files produced by the test.
+This variable is set to the name of the test case.
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ xwd $logdir/${casename}.gif
+ vdisplay result; vfit
+ vdump $logdir/${casename}-axo.gif
+ vfront; vfit
+ vdump $logdir/${casename}-front.gif
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+could produce:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ A1.gif
+ A1-axo.gif
+ A1-front.gif
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@subsection testmanual_3_4 Interpretation of Test Results
+
+The result of the test is evaluated by checking its output against patterns
+defined in the files parse.rules of the grid and group.
+The OCCT test system recognizes five statuses of the test execution:
+
+ * SKIPPED: reported if line matching SKIPPED pattern is found (prior to any FAILED pattern). This indicates that the test cannot be run in the current environment; most typical case is absence of the required data file.
+ * FAILED: reported if some line matching pattern with status FAILED is found (unless it is masked by preceding IGNORE pattern or a TODO statement, see below), or if message TEST COMPLETED is not found at the end. This indicates that test produces bad or unexpected result, and usually highlights a regression.
+ * BAD: reported if test script output contains one or several TODO statements and corresponding number of matching lines in the log. This indicates a known problem (see 3.5). The lines matching TODO statements are not checked against other patterns and thus will not cause a FAILED status.
+ * IMPROVEMENT: reported if test script output contains TODO statement for which no corresponding line is found. This is possible indication of improvement (known problem disappeared).
+ * OK: If none of the above statuses have been assigned. This means test passed without problems.
+
+Other statuses can be specified in the parse.rules files, these will be classified as FAILED.
+Before integration of the change to OCCT repository, all tests should return either OK or BAD status.
+The new test created for unsolved problem should return BAD.
+The new test created for a fixed problem should return FAILED without the fix, and OK with the fix.
+
+@subsection testmanual_3_5 Marking BAD Cases
+
+If the test produces invalid result at a certain moment then the corresponding bug
+should be created in the OCCT issue tracker [3], and the problem should be marked as TODO in the test script.
+The following statement should be added to such test script:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ puts *TODO BugNumber ListOfPlatforms: RegularExpression*
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+where:
+
+ * BugNumber is an ID of the bug in the tracker. For example: #12345
+ * ListOfPlatform is a list of platforms at which the bug is reproduced (e.g. Mandriva2008, Windows or All).
+
+*Note: the platform name is custom for the OCCT test system;*
+*it can be consulted as value of environment variable os_type defined in DRAW.*
+
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ Draw[2]> puts $env(os_type)
+ windows
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+
+ * RegularExpression is a regular expression which should be matched against the line indicating the problem in the script output.
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ puts *TODO #22622 Mandriva2008: Abort .* an exception was raised*
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Parser checks the output of the test and if an output line matches
+the RegularExpression then it will be assigned a BAD status instead of FAILED.
+For each output line matching to an error expression a separate TODO line
+must be added to mark the test as BAD.
+If not all the TODO statements are found in the test log,
+the test will be considered as possible improvement.
+To mark the test as BAD for an incomplete case
+(when final TEST COMPLETE message is missing)
+the expression *TEST INCOMPLETE* should be used instead of regular expression.
+
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ puts *TODO OCC22817 All: exception.+There are no suitable edges*
+ puts *TODO OCC22817 All: \\*\\* Exception \\*\\**
+ puts *TODO OCC22817 All: TEST INCOMPLETE*
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@section testmanual_4 Extended Use
+
+@subsection testmanual_4_1 Running Tests on Older Versions of OCCT
+
+Sometimes it might be necessary to run tests on previous versions of OCCT (up to to 6.5.3)
+that do not include this test system. This can be done by adding DRAW configuration file DrawAppliInit
+in the directory which is current by the moment of DRAW startup,
+to load test commands and define necessary environment. Example
+(assume that d:/occt contains up-to-date version of OCCT sources
+with tests, and test data archive is unpacked to d:/test-data):
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ set env(CASROOT) d:/occt
+ set env(CSF_TestScriptsPath) $env(CASROOT)/tests
+ source $env(CASROOT)/src/DrawResources/TestCommands.tcl
+ set env(CSF_TestDataPath) d:/test-data
+ return
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Note that on older versions of OCCT the tests are run in compatibility mode
+and not all output of the test command can be captured;
+this can lead to absence of some error messages (can be reported as improvement).
+
+@subsection testmanual_4_2 Adding Custom Tests
+
+You can extend the test system by adding your own tests.
+For that it is necessary to add paths to the directory where these tests are located,
+and additional data directory(ies), to the environment variables CSF_TestScriptsPath and CSF_TestDataPath.
+The recommended way for doing this is using DRAW configuration file DrawAppliInit
+located in the directory which is current by the moment of DRAW startup.
+
+Use Tcl command *_path_separator* to insert platform-dependent separator to the path list.
+Example:
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ set env(CSF_TestScriptsPath) \
+ $env(TestScriptsPath)[_path_separator]d:/MyOCCTProject/tests
+ set env(CSF_TestDataPath) \
+ d:/occt/test-data[_path_separator]d:/MyOCCTProject/tests
+ return ;# this is to avoid an echo of the last command above in cout
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@section testmanual_5 References
+
+-# DRAW Test Harness User’s Guide
+-# Perl regular expressions, http://perldoc.perl.org/perlre.html
+-# OCCT MantisBT issue tracker, http://tracker.dev.opencascade.org
--- /dev/null
+WOK {#dev_guides__wok}
+=========
+
+WOK is a legacy build environment for Open CASCADE Technology. It is required
+for generation of header files for classes defined with @ref ug_cdl "CDL"
+("Cascade Definition Language"). Also tools for generation of project files
+for other build systems, and OCCT documentation, are integrated to WOK.
+
+WOK thus is needed in the following situations:
+- Building from OCCT sources from Git repository (do not contain generated files)
+- Building after some changes made in CDL files
+
+Before installing and using WOK, make sure that you have installed a compiler (it is assumed that it is Visual Studio on Windows or gcc on Linux and MacOS) and third-party components required for building OCCT.
+
+@section wok1 Installing WOK
+
+ Download the latest version of binary distribution WOK from http://dev.opencascade.org/index.php?q=home/resources
+
+@subsection wok11 Windows
+
+ Run the installer. You will be prompted to read and accept the OCCT Public License to proceed:
+
+ 
+
+ 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:
+
+ 
+
+ 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:
+
+ 
+
+ * 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:
+
+ 
+
+ * 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\92s 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
--- /dev/null
+# -----------------------------------------------------------------------
+# Script name: CompileDocs.tcl
+# This script compiles OCCT documents from *.md files to HTML pages
+# Author: omy
+# -----------------------------------------------------------------------
+
+# Generates Doxygen configuration file for Overview documentation
+proc OverviewDoc_MakeDoxyfile {casDir outDir tagFileDir {doxyFileName} {generatorMode ""} DocFilesList verboseMode} {
+
+ if {$verboseMode == "YES"} {
+ puts "INFO: Doxygen is now generating Doxyfile..."
+ }
+
+ set doxyFile [open $doxyFileName "w"]
+ set casroot $casDir
+ set inputDir $casDir/dox
+
+ # Common configs
+ puts $doxyFile "DOXYFILE_ENCODING = UTF-8"
+ puts $doxyFile "PROJECT_NAME = \"Open CASCADE Technology\""
+ puts $doxyFile "PROJECT_NUMBER = 6.6.0"
+ puts $doxyFile "PROJECT_BRIEF = "
+ puts $doxyFile "PROJECT_LOGO = $inputDir/resources/occt_logo.png"
+
+ puts $doxyFile "OUTPUT_DIRECTORY = $outDir"
+ puts $doxyFile "CREATE_SUBDIRS = NO"
+ puts $doxyFile "OUTPUT_LANGUAGE = English"
+ puts $doxyFile "ABBREVIATE_BRIEF = \"The \$name class\" \
+ \"The \$name widget\" \
+ \"The \$name file\" \
+ is \
+ provides \
+ specifies \
+ contains \
+ represents \
+ a \
+ an \
+ the"
+
+ puts $doxyFile "FULL_PATH_NAMES = YES"
+ puts $doxyFile "INHERIT_DOCS = YES"
+ puts $doxyFile "TAB_SIZE = 4"
+ puts $doxyFile "MARKDOWN_SUPPORT = YES"
+ puts $doxyFile "EXTRACT_ALL = YES"
+ puts $doxyFile "CASE_SENSE_NAMES = NO"
+ puts $doxyFile "INLINE_INFO = YES"
+ puts $doxyFile "SORT_MEMBER_DOCS = YES"
+ puts $doxyFile "WARNINGS = YES"
+ puts $doxyFile "WARN_IF_UNDOCUMENTED = YES"
+ puts $doxyFile "WARN_IF_DOC_ERROR = YES"
+ puts $doxyFile "WARN_NO_PARAMDOC = NO"
+ puts $doxyFile "WARN_FORMAT = \"\$file:\$line: \$text\""
+ puts $doxyFile "INPUT_ENCODING = UTF-8"
+ puts $doxyFile "FILE_PATTERNS = *.md *.dox "
+ puts $doxyFile "RECURSIVE = YES"
+ puts $doxyFile "SOURCE_BROWSER = NO"
+ puts $doxyFile "INLINE_SOURCES = YES"
+ puts $doxyFile "COLS_IN_ALPHA_INDEX = 5"
+
+ # Generation options
+ puts $doxyFile "GENERATE_DOCSET = NO"
+ puts $doxyFile "GENERATE_HTMLHELP = NO"
+ puts $doxyFile "GENERATE_CHI = NO"
+ puts $doxyFile "GENERATE_QHP = NO"
+ puts $doxyFile "GENERATE_ECLIPSEHELP = NO"
+ puts $doxyFile "GENERATE_RTF = NO"
+ puts $doxyFile "GENERATE_MAN = NO"
+ puts $doxyFile "GENERATE_XML = NO"
+ puts $doxyFile "GENERATE_DOCBOOK = NO"
+ puts $doxyFile "GENERATE_AUTOGEN_DEF = NO"
+ puts $doxyFile "GENERATE_PERLMOD = NO"
+
+ set PARAM_INPUT "INPUT = "
+ set PARAM_IMAGEPATH "IMAGE_PATH = $inputDir/resources/ "
+
+ foreach docFile $DocFilesList {
+ set NEW_IMG_PATH [file normalize [file dirname "$inputDir/$docFile"]]
+ if { [string compare $NEW_IMG_PATH $casroot] != 0 } {
+ if {[file isdirectory "$NEW_IMG_PATH/images"]} {
+ append PARAM_IMAGEPATH " " "$NEW_IMG_PATH/images"
+ }
+ }
+ append PARAM_INPUT " " $inputDir/$docFile
+ }
+ puts $doxyFile $PARAM_INPUT
+ puts $doxyFile $PARAM_IMAGEPATH
+
+ if { $generatorMode == "PDF_ONLY"} {
+ set PARAM_LATEX_EF "LATEX_EXTRA_FILES ="
+ foreach docFile $DocFilesList {
+ set NEW_LEF_PATH [file normalize [file dirname "$inputDir/$docFile"]]
+ if { [string compare $NEW_LEF_PATH $casroot] != 0 } {
+ append PARAM_LATEX_EF " " "$NEW_LEF_PATH/images"
+ }
+ }
+ puts $doxyFile $PARAM_LATEX_EF
+ }
+
+ if { $generatorMode == "HTML_ONLY"} {
+ # Set a reference to a TAGFILE
+ if { $tagFileDir != "" } {
+ if {[file exists $tagFileDir/OCCT.tag] == 1} {
+ set tagPath [OverviewDoc_GetRelPath $tagFileDir $outDir/html]
+ puts $doxyFile "TAGFILES = $tagFileDir/OCCT.tag=$tagPath/html"
+ }
+ }
+
+ # HTML Output
+ puts $doxyFile "GENERATE_LATEX = NO"
+ puts $doxyFile "GENERATE_HTML = YES"
+ puts $doxyFile "HTML_COLORSTYLE_HUE = 220"
+ puts $doxyFile "HTML_COLORSTYLE_SAT = 100"
+ puts $doxyFile "HTML_COLORSTYLE_GAMMA = 80"
+ puts $doxyFile "HTML_TIMESTAMP = YES"
+ puts $doxyFile "HTML_DYNAMIC_SECTIONS = YES"
+ puts $doxyFile "HTML_INDEX_NUM_ENTRIES = 100"
+ puts $doxyFile "DISABLE_INDEX = YES"
+ puts $doxyFile "GENERATE_TREEVIEW = YES"
+ puts $doxyFile "ENUM_VALUES_PER_LINE = 8"
+ puts $doxyFile "TREEVIEW_WIDTH = 250"
+ puts $doxyFile "EXTERNAL_PAGES = NO"
+ puts $doxyFile "SEARCHENGINE = YES"
+ puts $doxyFile "SERVER_BASED_SEARCH = NO"
+ puts $doxyFile "EXTERNAL_SEARCH = NO"
+ puts $doxyFile "SEARCHDATA_FILE = searchdata.xml"
+ puts $doxyFile "SKIP_FUNCTION_MACROS = YES"
+ # Formula options
+ puts $doxyFile "FORMULA_FONTSIZE = 12"
+ puts $doxyFile "FORMULA_TRANSPARENT = YES"
+ puts $doxyFile "USE_MATHJAX = YES"
+ puts $doxyFile "MATHJAX_FORMAT = HTML-CSS"
+ puts $doxyFile "MATHJAX_RELPATH = http://cdn.mathjax.org/mathjax/latest"
+
+ } elseif { $generatorMode == "PDF_ONLY"} {
+
+ puts $doxyFile "GENERATE_HTML = NO"
+ puts $doxyFile "DISABLE_INDEX = YES"
+ puts $doxyFile "GENERATE_TREEVIEW = NO"
+ puts $doxyFile "PREDEFINED = PDF_ONLY"
+ puts $doxyFile "GENERATE_LATEX = YES"
+ puts $doxyFile "COMPACT_LATEX = YES"
+ puts $doxyFile "PDF_HYPERLINKS = YES"
+ puts $doxyFile "USE_PDFLATEX = YES"
+ puts $doxyFile "LATEX_BATCHMODE = YES"
+ puts $doxyFile "LATEX_OUTPUT = latex"
+ puts $doxyFile "LATEX_CMD_NAME = latex"
+ puts $doxyFile "MAKEINDEX_CMD_NAME = makeindex"
+ }
+
+ close $doxyFile
+}
+
+# Returns the relative path between two directories
+proc OverviewDoc_GetRelPath {targetFile currentpath} {
+ set cc [file split [file normalize $currentpath]]
+ set tt [file split [file normalize $targetFile]]
+
+ if {![string equal [lindex $cc 0] [lindex $tt 0]]} {
+ # not on *n*x then
+ return -code error "$targetFile not on same volume as $currentpath"
+ }
+ while {[string equal [lindex $cc 0] [lindex $tt 0]] && [llength $cc] > 0} {
+ # discard matching components from the front
+ set cc [lreplace $cc 0 0]
+ set tt [lreplace $tt 0 0]
+ }
+ set prefix ""
+ if {[llength $cc] == 0} {
+ # just the file name, so targetFile is lower down (or in same place)
+ set prefix "."
+ }
+ # step up the tree
+ for {set i 0} {$i < [llength $cc]} {incr i} {
+ append prefix " .."
+ }
+ # stick it all together (the eval is to flatten the targetFile list)
+ return [eval file join $prefix $tt]
+}
+
+# Prints Help message
+proc OverviewDoc_PrintHelpMessage {} {
+ puts "\nUsage : occdoc \[-h\] \[-html\] \[-pdf\] \[-m=<list of files>\] \[-l=<document name>\] \[-v\]"
+ puts ""
+ puts " Options are : "
+ puts " -html : To generate HTML files"
+ puts " (cannot be used with -pdf)"
+ puts " -pdf : To generate PDF files"
+ puts " (cannot be used with -html)"
+ puts " -m=<modules_list> : Specifies list of documents to generate."
+ puts " If it is not specified, all files, "
+ puts " mentioned in FILES.txt are processed."
+ puts " -l=<document_name> : Specifies the document caption "
+ puts " for a single document"
+ puts " -h : Prints help message"
+ puts " -v : Specifies the Verbose mode"
+ puts " (info on all script actions is shown)"
+}
+
+# Parses command line arguments
+proc OverviewDoc_ParseArguments {arguments} {
+ global args_names
+ global args_values
+ set args_names {}
+ array set args_values {}
+
+ foreach arg $arguments {
+ if {[regexp {^(-)[a-z]+$} $arg] == 1} {
+ set name [string range $arg 1 [string length $arg]-1]
+ lappend args_names $name
+ set args_values($name) "NULL"
+ continue
+ } elseif {[regexp {^(-)[a-z]+=.+$} $arg] == 1} {
+ set equal_symbol_position [string first "=" $arg]
+ set name [string range $arg 1 $equal_symbol_position-1]
+ lappend args_names $name
+ set value [string range $arg $equal_symbol_position+1 [string length $arguments]-1]
+
+ # To parse a list of values for -m parameter
+ if { [string first "," $value] != -1 } {
+ set value [split $value ","];
+ }
+ set args_values($name) $value
+ } else {
+ puts "Error in argument $arg"
+ return 1
+ }
+ }
+ return 0
+}
+
+# Loads a list of docfiles from file FILES.txt
+proc OverviewDoc_LoadFilesList {} {
+
+ set INPUTDIR [file normalize [file dirname [info script]]]
+
+ global available_docfiles
+ set available_docfiles {}
+
+ # Read data from file
+ if { [file exists "$INPUTDIR/FILES.txt"] == 1 } {
+ set FILE [open "$INPUTDIR/FILES.txt" r]
+ while {1} {
+ set line [gets $FILE]
+ if {$line != ""} {
+ lappend available_docfiles $line
+ }
+
+ if {[eof $FILE]} {
+ close $FILE
+ break
+ }
+ }
+ } else {
+ return -1
+ }
+ return 0
+}
+
+# Writes new tex file for conversion from tex to pdf for a specific doc
+proc OverviewDoc_MakeRefmanTex {fileName latexDir docLabel verboseMode} {
+
+ if {$verboseMode == "YES"} {
+ puts "INFO: Making refman.tex file for $fileName"
+ }
+ set DOCNAME "$latexDir/refman.tex"
+ if {[file exists $DOCNAME] == 1} {
+ file delete -force $DOCNAME
+ }
+ set texfile [open $DOCNAME w]
+
+ puts $texfile "\\batchmode"
+ puts $texfile "\\nonstopmode"
+ puts $texfile "\\documentclass\[oneside\]{article}"
+ puts $texfile "\n% Packages required by doxygen"
+ puts $texfile "\\usepackage{calc}"
+ puts $texfile "\\usepackage{doxygen}"
+ puts $texfile "\\usepackage{graphicx}"
+ puts $texfile "\\usepackage\[utf8\]{inputenc}"
+ puts $texfile "\\usepackage{makeidx}"
+ puts $texfile "\\usepackage{multicol}"
+ puts $texfile "\\usepackage{multirow}"
+ puts $texfile "\\usepackage{textcomp}"
+ puts $texfile "\\usepackage{amsmath}"
+ puts $texfile "\\usepackage\[table\]{xcolor}"
+ puts $texfile "\\usepackage{indentfirst}"
+ puts $texfile ""
+ puts $texfile "% Font selection"
+ puts $texfile "\\usepackage\[T1\]{fontenc}"
+ puts $texfile "\\usepackage{mathptmx}"
+ puts $texfile "\\usepackage\[scaled=.90\]{helvet}"
+ puts $texfile "\\usepackage{courier}"
+ puts $texfile "\\usepackage{amssymb}"
+ puts $texfile "\\usepackage{sectsty}"
+ puts $texfile "\\renewcommand{\\familydefault}{\\sfdefault}"
+ puts $texfile "\\allsectionsfont{%"
+ puts $texfile " \\fontseries{bc}\\selectfont%"
+ puts $texfile " \\color{darkgray}%"
+ puts $texfile "}"
+ puts $texfile "\\renewcommand{\\DoxyLabelFont}{%"
+ puts $texfile " \\fontseries{bc}\\selectfont%"
+ puts $texfile " \\color{darkgray}%"
+ puts $texfile "}"
+ puts $texfile ""
+ puts $texfile "% Page & text layout"
+ puts $texfile "\\usepackage{geometry}"
+ puts $texfile "\\geometry{%"
+ puts $texfile " a4paper,%"
+ puts $texfile " top=2.5cm,%"
+ puts $texfile " bottom=2.5cm,%"
+ puts $texfile " left=2.5cm,%"
+ puts $texfile " right=2.5cm%"
+ puts $texfile "}"
+ puts $texfile "\\tolerance=750"
+ puts $texfile "\\hfuzz=15pt"
+ puts $texfile "\\hbadness=750"
+ puts $texfile "\\setlength{\\emergencystretch}{15pt}"
+ puts $texfile "\\setlength{\\parindent}{0.75cm}"
+ puts $texfile "\\setlength{\\parskip}{0.2cm}"
+ puts $texfile "\\makeatletter"
+ puts $texfile "\\renewcommand{\\paragraph}{%"
+ puts $texfile " \@startsection{paragraph}{4}{0ex}{-1.0ex}{1.0ex}{%"
+ puts $texfile "\\normalfont\\normalsize\\bfseries\\SS@parafont%"
+ puts $texfile " }%"
+ puts $texfile "}"
+ puts $texfile "\\renewcommand{\\subparagraph}{%"
+ puts $texfile " \\@startsection{subparagraph}{5}{0ex}{-1.0ex}{1.0ex}{%"
+ puts $texfile "\\normalfont\\normalsize\\bfseries\\SS@subparafont%"
+ puts $texfile " }%"
+ puts $texfile "}"
+ puts $texfile "\\makeatother"
+ puts $texfile ""
+ puts $texfile "% Headers & footers"
+ puts $texfile "\\usepackage{fancyhdr}"
+ puts $texfile "\\pagestyle{fancyplain}"
+ puts $texfile "\\fancyhead\[LE\]{\\fancyplain{}{\\bfseries\\thepage}}"
+ puts $texfile "\\fancyhead\[CE\]{\\fancyplain{}{}}"
+ puts $texfile "\\fancyhead\[RE\]{\\fancyplain{}{\\bfseries\\leftmark}}"
+ puts $texfile "\\fancyhead\[LO\]{\\fancyplain{}{\\bfseries\\rightmark}}"
+ puts $texfile "\\fancyhead\[CO\]{\\fancyplain{}{}}"
+ puts $texfile "\\fancyhead\[RO\]{\\fancyplain{}{\\bfseries\\thepage}}"
+ puts $texfile "\\fancyfoot\[LE\]{\\fancyplain{}{}}"
+ puts $texfile "\\fancyfoot\[CE\]{\\fancyplain{}{}}"
+ puts $texfile "\\fancyfoot\[RE\]{\\fancyplain{}{\\bfseries\\scriptsize © Open CASCADE Technology 2001\-2013}}"
+ puts $texfile "\\fancyfoot\[LO\]{\\fancyplain{}{\\bfseries\\scriptsize © Open CASCADE Technology 2001\-2013}}"
+ puts $texfile "\\fancyfoot\[CO\]{\\fancyplain{}{}}"
+ puts $texfile "\\fancyfoot\[RO\]{\\fancyplain{}{}}"
+ puts $texfile "\\renewcommand{\\footrulewidth}{0.4pt}"
+ puts $texfile "\\renewcommand{\\sectionmark}\[1\]{%"
+ puts $texfile " \\markright{\\thesection\\ #1}%"
+ puts $texfile "}"
+ puts $texfile ""
+ puts $texfile "% Indices & bibliography"
+ puts $texfile "\\usepackage{natbib}"
+ puts $texfile "\\usepackage\[titles\]{tocloft}"
+ puts $texfile "\\renewcommand{\\cftsecleader}{\\cftdotfill{\\cftdotsep}}"
+ puts $texfile "\\setcounter{tocdepth}{3}"
+ puts $texfile "\\setcounter{secnumdepth}{5}"
+ puts $texfile "\\makeindex"
+ puts $texfile ""
+ puts $texfile "% Hyperlinks (required, but should be loaded last)"
+ puts $texfile "\\usepackage{ifpdf}"
+ puts $texfile "\\ifpdf"
+ puts $texfile " \\usepackage\[pdftex,pagebackref=true\]{hyperref}"
+ puts $texfile "\\else"
+ puts $texfile " \\usepackage\[ps2pdf,pagebackref=true\]{hyperref}"
+ puts $texfile "\\fi"
+ puts $texfile "\\hypersetup{%"
+ puts $texfile " colorlinks=true,%"
+ puts $texfile " linkcolor=black,%"
+ puts $texfile " citecolor=black,%"
+ puts $texfile " urlcolor=blue,%"
+ puts $texfile " unicode%"
+ puts $texfile "}"
+ puts $texfile ""
+ puts $texfile "% Custom commands"
+ puts $texfile "\\newcommand{\\clearemptydoublepage}{%"
+ puts $texfile " \\newpage{\\pagestyle{empty}\\cleardoublepage}%"
+ puts $texfile "}"
+ puts $texfile "\n"
+ puts $texfile "%===== C O N T E N T S =====\n"
+ puts $texfile "\\begin{document}"
+ puts $texfile ""
+ puts $texfile "% Titlepage & ToC"
+ puts $texfile "\\hypersetup{pageanchor=false}"
+ puts $texfile "\\pagenumbering{roman}"
+ puts $texfile "\\begin{titlepage}"
+ puts $texfile "\\vspace*{7cm}"
+ puts $texfile "\\begin{center}%"
+ puts $texfile "\\includegraphics\[width=0.75\\textwidth, height=0.2\\textheight\]{occttransparent.png}\\\\\\\\"
+ puts $texfile "{\\Large Open C\\-A\\-S\\-C\\-A\\-D\\-E Technology \\\\\[1ex\]\\Large 6.\\-6.\\-0 }\\\\"
+ puts $texfile "\\vspace*{1cm}"
+ puts $texfile "{\\Large $docLabel}\\\\"
+ puts $texfile "\\vspace*{1cm}"
+ puts $texfile "{\\large Generated by Doxygen 1.8.4}\\\\"
+ puts $texfile "\\vspace*{0.5cm}"
+ puts $texfile "{\\small \\today}\\"
+ puts $texfile "\\end{center}"
+ puts $texfile "\\end{titlepage}"
+ puts $texfile "\\clearpage"
+ puts $texfile "\\pagenumbering{roman}"
+ puts $texfile "\\tableofcontents"
+ puts $texfile "\\newpage"
+ puts $texfile "\\pagenumbering{arabic}"
+ puts $texfile "\\hypersetup{pageanchor=true}"
+ puts $texfile ""
+ puts $texfile "\\hypertarget{$fileName}{}"
+ puts $texfile "\\input{$fileName}"
+ puts $texfile ""
+ puts $texfile "% Index"
+ puts $texfile "\\newpage"
+ puts $texfile "\\phantomsection"
+ puts $texfile "\\addcontentsline{toc}{part}{Index}"
+ puts $texfile "\\printindex\n"
+ puts $texfile "\\end{document}"
+
+ close $texfile
+}
+
+# Postprocesses generated TeX files
+proc OverviewDoc_ProcessTex {{texFiles {}} {latexDir} verboseMode} {
+
+ foreach TEX $texFiles {
+ if {$verboseMode == "YES"} {
+ puts "INFO: Preprocessing file $TEX"
+ }
+ set IN_F [open "$TEX" r]
+ set TMPFILENAME "$latexDir/temp.tex"
+ set OUT_F [open $TMPFILENAME w]
+
+ while {1} {
+ set line [gets $IN_F]
+ if { [string first "\\includegraphics" $line] != -1 } {
+ # Center images in TeX files
+ set line "\\begin{center}\n $line\n\\end{center}"
+ } elseif { [string first "\\subsection" $line] != -1 } {
+ # Replace \subsection with \section tag
+ regsub -all "\\\\subsection" $line "\\\\section" line
+ } elseif { [string first "\\subsubsection" $line] != -1 } {
+ # Replace \subsubsection with \subsection tag
+ regsub -all "\\\\subsubsection" $line "\\\\subsection" line
+ } elseif { [string first "\\paragraph" $line] != -1 } {
+ # Replace \paragraph with \subsubsection tag
+ regsub -all "\\\\paragraph" $line "\\\\subsubsection" line
+ }
+ puts $OUT_F $line
+
+ if {[eof $IN_F]} {
+ close $IN_F
+ close $OUT_F
+ break
+ }
+ }
+ file delete -force $TEX
+ file rename $TMPFILENAME $TEX
+ }
+}
+
+# Main procedure for documents compilation
+proc OverviewDoc_Main { {docfiles {}} generatorMode docLabel verboseMode} {
+
+ set INDIR [file normalize [file dirname [info script]]]
+ set CASROOT [file normalize [file dirname "$INDIR/../../"]]
+ set OUTDIR $CASROOT/doc
+ set PDFDIR $OUTDIR/overview/pdf
+ set HTMLDIR $OUTDIR/overview/html
+ set LATEXDIR $OUTDIR/overview/latex
+ set TAGFILEDIR $OUTDIR/refman
+ set DOXYFILE $OUTDIR/OCCT.cfg
+
+ # Create or clean the output folders
+ if {[file exists $OUTDIR] == 0} {
+ file mkdir $OUTDIR
+ }
+ if {[file exists $HTMLDIR] == 0} {
+ file mkdir $HTMLDIR
+ }
+ if {[file exists $LATEXDIR] == 0} {
+ file mkdir $LATEXDIR
+ }
+ if {[file exists $PDFDIR] == 0} {
+ file mkdir $PDFDIR
+ }
+
+ # Run tools to compile documents
+ puts ""
+ puts " [clock format [clock seconds] -format {%Y.%m.%d %H:%M}] Generation process started..."
+ puts ""
+ puts " Please, wait while Doxygen finishes it\'s work"
+ OverviewDoc_MakeDoxyfile $CASROOT "$OUTDIR/overview" $TAGFILEDIR $DOXYFILE $generatorMode $docfiles $verboseMode
+
+ # Run doxygen tool
+ if { $generatorMode == "HTML_ONLY"} {
+ puts " [clock format [clock seconds] -format {%Y.%m.%d %H:%M}] Doxygen is now generating HTML files...\n"
+ }
+ set RESULT [catch {exec doxygen $DOXYFILE > $OUTDIR/doxygen_out.log} DOX_ERROR]
+ if {$RESULT != 0} {
+ if {[llength [split $DOX_ERROR "\n"]] > 1} {
+ if {$verboseMode == "YES"} {
+ puts "INFO: See Doxygen messages in $OUTDIR/doxygen_warnings_and_errors.log"
+ }
+ set DOX_ERROR_FILE [open "$OUTDIR/doxygen_warnings_and_errors.log" "w"]
+ puts $DOX_ERROR_FILE $DOX_ERROR
+ close $DOX_ERROR_FILE
+ } else {
+ puts $DOX_ERROR
+ }
+ }
+ # Close the Doxygen application
+ after 300
+
+ # Start PDF generation routine
+ if { $generatorMode == "PDF_ONLY" } {
+ puts ""
+ puts " [clock format [clock seconds] -format {%Y.%m.%d %H:%M}] Doxygen is now generating PDF files...\n"
+
+ set OS $::tcl_platform(platform)
+ if { $OS == "unix" } {
+ set PREFIX ".sh"
+ } elseif { $OS == "windows" } {
+ set PREFIX ".bat"
+ }
+
+ # Prepare a list of TeX files, generated by Doxygen
+ cd $LATEXDIR
+
+ set TEXFILES [glob $LATEXDIR -type f -directory $LATEXDIR -tails "*.tex" ]
+ set REFMAN_IDX [lsearch $TEXFILES "refman.tex"]
+ set TEXFILES [lreplace $TEXFILES $REFMAN_IDX $REFMAN_IDX]
+ set REFMAN_IDX [lsearch $TEXFILES "index.tex"]
+ set TEXFILES [lreplace $TEXFILES $REFMAN_IDX $REFMAN_IDX]
+
+ set IDX [lsearch $TEXFILES "$LATEXDIR"]
+ while { $IDX != -1} {
+ set TEXFILES [lreplace $TEXFILES $IDX $IDX]
+ set IDX [lsearch $TEXFILES "$LATEXDIR"]
+ }
+
+ # Preprocess generated TeX files
+ OverviewDoc_ProcessTex $TEXFILES $LATEXDIR $verboseMode
+
+ # Generate PDF files from
+ foreach TEX $TEXFILES {
+ # Rewrite existing REFMAN.tex file...
+ set TEX [string range $TEX 0 [ expr "[string length $TEX] - 5"]]
+ OverviewDoc_MakeRefmanTex $TEX $LATEXDIR $docLabel $verboseMode
+
+ if {$verboseMode == "YES"} {
+ puts "INFO: Generating PDF file from $TEX"
+ }
+ # ...and use it to generate PDF from TeX...
+ set RESULT [catch {eval exec [auto_execok $LATEXDIR/make$PREFIX] > "$OUTDIR/pdflatex_out.log"} LaTeX_ERROR]
+ if {$RESULT != 0} {
+ if {[llength [split $LaTeX_ERROR "\n"]] > 1} {
+ set LaTeX_ERROR_FILE [open "$OUTDIR/pdflatex_warnings_and_errors.log" "w"]
+ puts $LaTeX_ERROR_FILE $LaTeX_ERROR
+ close $LaTeX_ERROR_FILE
+ } else {
+ puts $DOX_ERROR
+ }
+ }
+
+ # ...and place it to the specific folder
+ if { [file exists $PDFDIR/$TEX.pdf] == 1 } {
+ file delete -force $PDFDIR/$TEX.pdf
+ }
+ file rename $LATEXDIR/refman.pdf "$PDFDIR/$TEX.pdf"
+ }
+ if {$verboseMode == "YES"} {
+ puts "INFO: See LaTeX messages in $OUTDIR/pdflatex_warnings_and_errors.log"
+ }
+ }
+
+ cd $INDIR
+ puts " [clock format [clock seconds] -format {%Y.%m.%d %H:%M}] Generation process finished..."
+ puts ""
+ puts "--------------------------------------------------------------------"
+ if { $generatorMode == "HTML_ONLY" } {
+ puts " You can look at generated HTML pages by opening: "
+ set RESFILE $OUTDIR/overview/html/index.html
+ puts " $RESFILE"
+ }
+ if { $generatorMode == "PDF_ONLY" } {
+ puts " You can look at generated PDF files in: "
+ puts " $OUTDIR/overview/pdf folder"
+ }
+ puts ""
+ puts " Copyright \u00a9 Open CASCADE Technology 2001-2013"
+ puts "--------------------------------------------------------------------\n"
+}
+
+# A command for User Documentation compilation
+proc occdoc {args} {
+ # Programm options
+ set GEN_HTML "NO"
+ set GEN_PDF "NO"
+ set DOCFILES {}
+ set DOCLABEL "Default OCCT Document"
+ set VERB_MODE "NO"
+ set GEN_MODE "DEFAULT"
+ global available_docfiles
+ global args_names
+ global args_values
+
+ # Load list of docfiles
+ if { [OverviewDoc_LoadFilesList] != 0 } {
+ puts "ERROR: File FILES.txt was not found"
+ return
+ }
+
+ # Parse CL arguments
+ if {[OverviewDoc_ParseArguments $args] == 1} {
+ return
+ }
+ if {$args_names == {}} {
+ set GEN_HTML "YES"
+ set VERB_MODE "YES"
+ } else {
+ foreach arg_n $args_names {
+ if {$arg_n == "h"} {
+ OverviewDoc_PrintHelpMessage
+ return
+ } elseif {$arg_n == "html"} {
+ set GEN_HTML "YES"
+ } elseif {$arg_n == "pdf"} {
+ set GEN_PDF "YES"
+ } elseif {$arg_n == "v"} {
+ set VERB_MODE "YES"
+ } elseif {$arg_n == "m"} {
+ if {$args_values(m) != "NULL"} {
+ set DOCFILES $args_values(m)
+ } else {
+ puts "Error in argument m"
+ return
+ }
+ # Check if all chosen docfiles are correct
+ foreach docfile $DOCFILES {
+ if { [lsearch $available_docfiles $docfile] == -1 } {
+ puts "File \"$docfile\" is not presented in the list of available docfiles"
+ puts "Please, specify the correct docfile name"
+ return
+ } else {
+ puts "File $docfile is presented in FILES.TXT"
+ }
+ }
+ } elseif {$arg_n == "l"} {
+ if { [llength $DOCFILES] <= 1 } {
+ if {$args_values(l) != "NULL"} {
+ set DOCLABEL $args_values(l)
+ } else {
+ puts "Error in argument l"
+ return
+ }
+ }
+ } else {
+ puts "\nWrong argument: $arg_n"
+ OverviewDoc_PrintHelpMessage
+ return
+ }
+ }
+ }
+
+ # Specify generation mode
+ if {$GEN_HTML == "YES" && $GEN_PDF == "NO"} {
+ set GEN_MODE "HTML_ONLY"
+ } elseif {$GEN_PDF == "YES"} {
+ set GEN_MODE "PDF_ONLY"
+ }
+ # Check if -v is the only option
+ if {$GEN_MODE == "DEFAULT"} {
+ if { $VERB_MODE == "YES" } {
+ puts "\nArgument -v can't be used without -pdf or -html argument"
+ OverviewDoc_PrintHelpMessage
+ }
+ return
+ }
+
+ # Specify verbose mode
+ if { $GEN_PDF != "YES" && [llength $DOCFILES] > 1 } {
+ set DOCLABEL ""
+ }
+
+ # If we don't specify list for docfiles with -m argument,
+ # we assume that we have to generate all docfiles
+ if { [llength $DOCFILES] == 0 } {
+ set DOCFILES $available_docfiles
+ }
+
+ # Start main activities
+ OverviewDoc_Main $DOCFILES $GEN_MODE $DOCLABEL $VERB_MODE
+}
--- /dev/null
+ Tutorial {#overview__tutorial}
+=======
+
+@section sec1 Overview
+
+
+This tutorial will teach you how to use Open CASCADE Technology services to model a 3D object. The purpose of this tutorial is not to describe all Open CASCADE Technology classes but to help you start thinking in terms of Open CASCADE Technology as a tool.
+
+
+@subsection OCCT_TUTORIAL_SUB1_1 Prerequisites
+
+This tutorial assumes that you have experience in using and setting up C++.
+From a programming standpoint, Open CASCADE Technology is designed to enhance your C++ tools with 3D modeling classes, methods and functions. The combination of all these resources will allow you to create substantial applications.
+
+@subsection OCCT_TUTORIAL_SUB1_2 The Model
+
+To illustrate the use of classes provided in the 3D geometric modeling toolkits, you will create a bottle as shown:
+
+
+
+In the tutorial we will create, step-by-step, a function that will model a bottle as shown above. You will find the complete source code of this tutorial, including the very function *MakeBottle* in the distribution of Open CASCADE Technology. The function body is provided in the file samples/qt/Tutorial/src/MakeBottle.cxx.
+
+@subsection OCCT_TUTORIAL_SUB1_3 Model Specifications
+
+We first define the bottle specifications as follows:
+
+| Object Parameter | Parameter Name | Parameter Value |
+| :--------------: | :------------: | :-------------: |
+| Bottle height | MyHeight | 70mm |
+| Bottle width | MyWidth | 50mm |
+| Bottle thickness | MyThickness | 30mm |
+
+In addition, we decide that the bottle's profile (base) will be centered on the origin of the global Cartesian coordinate system.
+
+
+
+This modeling requires four steps:
+
+ * build the bottle's Profile
+ * build the bottle's Body
+ * build the Threading on the bottle's neck
+ * build the result compound
+
+
+@section sec2 Building the Profile
+
+@subsection OCCT_TUTORIAL_SUB2_1 Defining Support Points
+
+To create the bottle's profile, you first create characteristic points with their coordinates as shown below in the (XOY) plane. These points will be the supports that define the geometry of the profile.
+
+
+
+There are two classes to describe a 3D Cartesian point from its X, Y and Z coordinates in Open CASCADE Technology:
+
+ * the primitive geometric *gp_Pnt* class
+ * the transient *Geom_CartesianPoint* class manipulated by handle
+
+A handle is a type of smart pointer that provides automatic memory management.
+To choose the best class for this application, consider the following:
+
+ * *gp_Pnt* is manipulated by value. Like all objects of its kind, it will have a limited lifetime.
+ * *Geom_CartesianPoint* is manipulated by handle and may have multiple references and a long lifetime.
+
+Since all the points you will define are only used to create the profile's curves, an object with a limited lifetime will do. Choose the *gp_Pnt* class.
+To instantiate a *gp_Pnt* object, just specify the X, Y, and Z coordinates of the points in the global cartesian coordinate system:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ gp_Pnt aPnt1(-myWidth / 2., 0, 0);
+ gp_Pnt aPnt2(-myWidth / 2., -myThickness / 4., 0);
+ gp_Pnt aPnt3(0, -myThickness / 2., 0);
+ gp_Pnt aPnt4(myWidth / 2., -myThickness / 4., 0);
+ gp_Pnt aPnt5(myWidth / 2., 0, 0);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Once your objects are instantiated, you can use methods provided by the class to access and modify its data. For example, to get the X coordinate of a point:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+Standard_Real xValue1 = aPnt1.X();
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@subsection OCCT_TUTORIAL_SUB2_2 Profile: Defining the Geometry
+With the help of the previously defined points, you can compute a part of the bottle's profile geometry. As shown in the figure below, it will consist of two segments and one arc.
+
+
+
+To create such entities, you need a specific data structure, which implements 3D geometric objects. This can be found in the Geom package of Open CASCADE Technology.
+In Open CASCADE Technology a package is a group of classes providing related functionality. The classes have names that start with the name of a package they belong to. For example, *Geom_Line* and *Geom_Circle* classes belong to the *Geom* package. The *Geom* package implements 3D geometric objects: elementary curves and surfaces are provided as well as more complex ones (such as *Bezier* and *BSpline*).
+However, the *Geom* package provides only the data structure of geometric entities. You can directly instantiate classes belonging to *Geom*, but it is easier to compute elementary curves and surfaces by using the *GC* package.
+This is because the *GC* provides two algorithm classes which are exactly what is required for our profile:
+
+ * Class *GC_MakeSegment* to create a segment. One of its constructors allows you to define a segment by two end points P1 and P2
+ * Class *GC_MakeArcOfCircle* to create an arc of a circle. A useful constructor creates an arc from two end points P1 and P3 and going through P2.
+
+Both of these classes return a *Geom_TrimmedCurve* manipulated by handle. This entity represents a base curve (line or circle, in our case), limited between two of its parameter values. For example, circle C is parameterized between 0 and 2PI. If you need to create a quarter of a circle, you create a *Geom_TrimmedCurve* on C limited between 0 and M_PI/2.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ Handle(Geom_TrimmedCurve) aArcOfCircle = GC_MakeArcOfCircle(aPnt2,aPnt3,aPnt4);
+ Handle(Geom_TrimmedCurve) aSegment1 = GC_MakeSegment(aPnt1, aPnt2);
+ Handle(Geom_TrimmedCurve) aSegment2 = GC_MakeSegment(aPnt4, aPnt5);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+All *GC* classes provide a casting method to obtain a result automatically with a function-like call. Note that this method will raise an exception if construction has failed. To handle possible errors more explicitly, you may use the *IsDone* and *Value* methods. For example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ GC_MakeSegment mkSeg (aPnt1, aPnt2);
+ Handle(Geom_TrimmedCurve) aSegment1;
+ if(mkSegment.IsDone()){
+ aSegment1 = mkSeg.Value();
+ }
+ else {
+ // handle error
+ }
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+@subsection OCCT_TUTORIAL_SUB2_3 Profile: Defining the Topology
+
+
+You have created the support geometry of one part of the profile but these curves are independent with no relations between each other.
+To simplify the modeling, it would be right to manipulate these three curves as a single entity.
+This can be done by using the topological data structure of Open CASCADE Technology defined in the *TopoDS* package: it defines relationships between geometric entities which can be linked together to represent complex shapes.
+Each object of the *TopoDS* package, inheriting from the *TopoDS_Shape* class, describes a topological shape as described below:
+
+| Shape | Open CASCADE Technology Class | Description |
+| :-------- | :---------------------------- | :------------------------------------------------------------ |
+| Vertex | TopoDS_Vertex | Zero dimensional shape corresponding to a point in geometry. |
+| Edge | TopoDS_Edge | One-dimensional shape corresponding to a curve and bounded by a vertex at each extremity.|
+| Wire | TopoDS_Wire | Sequence of edges connected by vertices. |
+| Face | TopoDS_Face | Part of a surface bounded by a closed wire(s). |
+| Shell | TopoDS_Shell | Set of faces connected by edges. |
+| Solid | TopoDS_Solid | Part of 3D space bounded by Shells. |
+| CompSolid | TopoDS_CompSolid | Set of solids connected by their faces. |
+| Compound | TopoDS_Compound | Set of any other shapes described above. |
+
+Referring to the previous table, to build the profile, you will create:
+
+ * Three edges out of the previously computed curves.
+ * One wire with these edges.
+
+
+
+However, the *TopoDS* package provides only the data structure of the topological entities. Algorithm classes available to compute standard topological objects can be found in the *BRepBuilderAPI* package.
+To create an edge, you use the BRepBuilderAPI_MakeEdge class with the previously computed curves:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ TopoDS_Edge aEdge1 = BRepBuilderAPI_MakeEdge(aSegment1);
+ TopoDS_Edge aEdge2 = BRepBuilderAPI_MakeEdge(aArcOfCircle);
+ TopoDS_Edge aEdge3 = BRepBuilderAPI_MakeEdge(aSegment2);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In Open CASCADE Technology, you can create edges in several ways. One possibility is to create an edge directly from two points, in which case the underlying geometry of this edge is a line, bounded by two vertices being automatically computed from the two input points. For example, aEdge1 and aEdge3 could have been computed in a simpler way:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ TopoDS_Edge aEdge1 = BRepBuilderAPI_MakeEdge(aPnt1, aPnt3);
+ TopoDS_Edge aEdge2 = BRepBuilderAPI_MakeEdge(aPnt4, aPnt5);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To connect the edges, you need to create a wire with the *BRepBuilderAPI_MakeWire* class. There are two ways of building a wire with this class:
+
+ * directly from one to four edges
+ * by adding other wire(s) or edge(s) to an existing wire (this is explained later in this tutorial)
+
+When building a wire from less than four edges, as in the present case, you can use the constructor directly as follows:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ TopoDS_Wire aWire = BRepBuilderAPI_MakeWire(aEdge1, aEdge2, aEdge3);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+@subsection OCCT_TUTORIAL_SUB2_4 Profile: Completing the Profile
+
+
+Once the first part of your wire is created you need to compute the complete profile. A simple way to do this is to:
+
+ * compute a new wire by reflecting the existing one.
+ * add the reflected wire to the initial one.
+
+
+
+To apply a transformation on shapes (including wires), you first need to define the properties of a 3D geometric transformation by using the gp_Trsf class. This transformation can be a translation, a rotation, a scale, a reflection, or a combination of these.
+In our case, we need to define a reflection with respect to the X axis of the global coordinate system. An axis, defined with the gp_Ax1 class, is built out of a point and has a direction (3D unitary vector). There are two ways to define this axis.
+The first way is to define it from scratch, using its geometric definition:
+
+ * X axis is located at (0, 0, 0) - use the *gp_Pnt* class.
+ * X axis direction is (1, 0, 0) - use the *gp_Dir* class. A *gp_Dir* instance is created out of its X, Y and Z coordinates.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ gp_Pnt aOrigin(0, 0, 0);
+ gp_Dir xDir(1, 0, 0);
+ gp_Ax1 xAxis(aOrigin, xDir);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The second and simplest way is to use the geometric constants defined in the gp package (origin, main directions and axis of the global coordinate system). To get the X axis, just call the *gp::OX* method:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ gp_Ax1 xAxis = gp::OX();
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+As previously explained, the 3D geometric transformation is defined with the *gp_Trsf* class. There are two different ways to use this class:
+
+ * by defining a transformation matrix by all its values
+ * by using the appropriate methods corresponding to the required transformation (SetTranslation for a translation, SetMirror for a reflection, etc.): the matrix is automatically computed.
+
+Since the simplest approach is always the best one, you should use the SetMirror method with the axis as the center of symmetry.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ gp_Trsf aTrsf;
+ aTrsf.SetMirror(xAxis);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You now have all necessary data to apply the transformation with the BRepBuilderAPI_Transform class by specifying:
+
+ * the shape on which the transformation must be applied.
+ * the geometric transformation
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ BRepBuilderAPI_Transform aBRepTrsf(aWire, aTrsf);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+*BRepBuilderAPI_Transform* does not modify the nature of the shape: the result of the reflected wire remains a wire. But the function-like call or the *BRepBuilderAPI_Transform::Shape* method returns a *TopoDS_Shape* object:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ TopoDS_Shape aMirroredShape = aBRepTrsf.Shape();
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+What you need is a method to consider the resulting reflected shape as a wire. The *TopoDS* global functions provide this kind of service by casting a shape into its real type. To cast the transformed wire, use the *TopoDS::Wire* method.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ TopoDS_Wire aMirroredWire = TopoDS::Wire(aMirroredShape);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The bottle's profile is almost finished. You have created two wires: *aWire* and *aMirroredWire*. You need to concatenate them to compute a single shape. To do this, you use the *BRepBuilderAPI_MakeWire* class as follows:
+
+ * create an instance of *BRepBuilderAPI_MakeWire*.
+ * add all edges of the two wires by using the *Add* method on this object.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ BRepBuilderAPI_MakeWire mkWire;
+ mkWire.Add(aWire);
+ mkWire.Add(aMirroredWire);
+ TopoDS_Wire myWireProfile = mkWire.Wire();
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+@section sec3 Building the Body
+
+
+@subsection OCCT_TUTORIAL_SUB3_1 Prism the Profile
+
+
+To compute the main body of the bottle, you need to create a solid shape. The simplest way is to use the previously created profile and to sweep it along a direction. The *Prism* functionality of Open CASCADE Technology is the most appropriate for that task. It accepts a shape and a direction as input and generates a new shape according to the following rules:
+
+| Shape | Generates |
+| :----- | :----------------- |
+| Vertex | Edge |
+| Edge | Face |
+| Wire | Shell |
+| Face | Solid |
+| Shell | Compound of Solids |
+
+
+
+Your current profile is a wire. Referring to the Shape/Generates table, you need to compute a face out of its wire to generate a solid.
+To create a face, use the *BRepBuilderAPI_MakeFace* class. As previously explained, a face is a part of a surface bounded by a closed wire. Generally, *BRepBuilderAPI_MakeFace* computes a face out of a surface and one or more wires.
+When the wire lies on a plane, the surface is automatically computed.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ TopoDS_Face myFaceProfile = BRepBuilderAPI_MakeFace(myWireProfile);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The *BRepPrimAPI* package provides all the classes to create topological primitive constructions: boxes, cones, cylinders, spheres, etc. Among them is the *BRepPrimAPI_MakePrism* class. As specified above, the prism is defined by:
+
+ * the basis shape to sweep;
+ * a vector for a finite prism or a direction for finite and infinite prisms.
+
+You want the solid to be finite, swept along the Z axis and to be myHeight height. The vector, defined with the *gp_Vec* class on its X, Y and Z coordinates, is:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ gp_Vec aPrismVec(0, 0, myHeight);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+All the necessary data to create the main body of your bottle is now available. Just apply the *BRepPrimAPI_MakePrism* class to compute the solid:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ TopoDS_Shape myBody = BRepPrimAPI_MakePrism(myFaceProfile, aPrismVec);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+@subsection OCCT_TUTORIAL_SUB3_2 Applying Fillets
+
+
+The edges of the bottle's body are very sharp. To replace them by rounded faces, you use the *Fillet* functionality of Open CASCADE Technology.
+For our purposes, we will specify that fillets must be:
+
+ * applied on all edges of the shape
+ * have a radius of *myThickness* / 12
+
+
+
+To apply fillets on the edges of a shape, you use the *BRepFilletAPI_MakeFillet* class. This class is normally used as follows:
+
+ * Specify the shape to be filleted in the *BRepFilletAPI_MakeFillet* constructor.
+ * Add the fillet descriptions (an edge and a radius) using the *Add* method (you can add as many edges as you need).
+ * Ask for the resulting filleted shape with the *Shape* method.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+BRepFilletAPI_MakeFillet mkFillet(myBody);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To add the fillet description, you need to know the edges belonging to your shape. The best solution is to explore your solid to retrieve its edges. This kind of functionality is provided with the *TopExp_Explorer* class, which explores the data structure described in a *TopoDS_Shape* and extracts the sub-shapes you specifically need.
+Generally, this explorer is created by providing the following information:
+
+ * the shape to explore
+ * the type of sub-shapes to be found. This information is given with the *TopAbs_ShapeEnum* enumeration.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+TopExp_Explorer anEdgeExplorer(myBody, TopAbs_EDGE);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+An explorer is usually applied in a loop by using its three main methods:
+
+ * *More()* to know if there are more sub-shapes to explore.
+ * *Current()* to know which is the currently explored sub-shape (used only if the *More()* method returns true).
+ * *Next()* to move onto the next sub-shape to explore.
+
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ while(anEdgeExplorer.More()){
+ TopoDS_Edge anEdge = TopoDS::Edge(anEdgeExplorer.Current());
+ //Add edge to fillet algorithm
+ ...
+ anEdgeExplorer.Next();
+ }
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In the explorer loop, you have found all the edges of the bottle shape. Each one must then be added in the *BRepFilletAPI_MakeFillet* instance with the *Add()* method. Do not forget to specify the radius of the fillet along with it.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ mkFillet.Add(myThickness / 12., anEdge);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Once this is done, you perform the last step of the procedure by asking for the filleted shape.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ myBody = mkFillet.Shape();
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+@subsection OCCT_TUTORIAL_SUB3_3 Adding the Neck
+
+
+To add a neck to the bottle, you will create a cylinder and fuse it to the body. The cylinder is to be positioned on the top face of the body with a radius of *myThickness* / 4. and a height of *myHeight* / 10.
+
+
+
+To position the cylinder, you need to define a coordinate system with the *gp_Ax2* class defining a right-handed coordinate system from a point and two directions - the main (Z) axis direction and the X direction (the Y direction is computed from these two).
+To align the neck with the center of the top face, being in the global coordinate system (0, 0, *myHeight*), with its normal on the global Z axis, your local coordinate system can be defined as follows:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ gp_Pnt neckLocation(0, 0, myHeight);
+ gp_Dir neckAxis = gp::DZ();
+ gp_Ax2 neckAx2(neckLocation, neckAxis);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To create a cylinder, use another class from the primitives construction package: the *BRepPrimAPI_MakeCylinder* class. The information you must provide is:
+
+ * the coordinate system where the cylinder will be located;
+ * the radius and height.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ Standard_Real myNeckRadius = myThickness / 4.;
+ Standard_Real myNeckHeight = myHeight / 10;
+ BRepPrimAPI_MakeCylinder MKCylinder(neckAx2, myNeckRadius, myNeckHeight);
+ TopoDS_Shape myNeck = MKCylinder.Shape();
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You now have two separate parts: a main body and a neck that you need to fuse together.
+The *BRepAlgoAPI* package provides services to perform Boolean operations between shapes, and especially: *common* (Boolean intersection), *cut* (Boolean subtraction) and *fuse* (Boolean union).
+Use *BRepAlgoAPI_Fuse* to fuse the two shapes:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ myBody = BRepAlgoAPI_Fuse(myBody, myNeck);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+@subsection OCCT_TUTORIAL_SUB3_4 Creating a Hollowed Solid
+
+
+Since a real bottle is used to contain liquid material, you should now create a hollowed solid from the bottle's top face.
+In Open CASCADE Technology, a hollowed solid is called a *Thick* *Solid* and is internally computed as follows:
+
+ * Remove one or more faces from the initial solid to obtain the first wall W1 of the hollowed solid.
+ * Create a parallel wall W2 from W1 at a distance D. If D is positive, W2 will be outside the initial solid, otherwise it will be inside.
+ * Compute a solid from the two walls W1 and W2.
+
+
+
+To compute a thick solid, you create an instance of the *BRepOffsetAPI_MakeThickSolid* class by giving the following information:
+
+ * The shape, which must be hollowed.
+ * The tolerance used for the computation (tolerance criterion for coincidence in generated shapes).
+ * The thickness between the two walls W1 and W2 (distance D).
+ * The face(s) to be removed from the original solid to compute the first wall W1.
+
+The challenging part in this procedure is to find the face to remove from your shape - the top face of the neck, which:
+
+ * has a plane (planar surface) as underlying geometry;
+ * is the highest face (in Z coordinates) of the bottle.
+
+To find the face with such characteristics, you will once again use an explorer to iterate on all the bottle's faces to find the appropriate one.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ for(TopExp_Explorer aFaceExplorer(myBody, TopAbs_FACE) ; aFaceExplorer.More() ; aFaceExplorer.Next()){
+ TopoDS_Face aFace = TopoDS::Face(aFaceExplorer.Current());
+ }
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+For each detected face, you need to access the geometric properties of the shape: use the *BRep_Tool* class for that. The most commonly used methods of this class are:
+
+ * *Surface* to access the surface of a face;
+ * *Curve* to access the 3D curve of an edge;
+ * *Point* to access the 3D point of a vertex.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+Handle(Geom_Surface) aSurface = BRep_Tool::Surface(aFace);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+As you can see, the *BRep_Tool::Surface* method returns an instance of the *Geom_Surface* class manipulated by handle. However, the *Geom_Surface* class does not provide information about the real type of the object *aSurface*, which could be an instance of *Geom_Plane*, *Geom_CylindricalSurface*, etc.
+All objects manipulated by handle, like *Geom_Surface*, inherit from the *Standard_Transient* class which provides two very useful methods concerning types:
+
+ * *DynamicType* to know the real type of the object
+ * *IsKind* to know if the object inherits from one particular type
+
+DynamicType returns the real type of the object, but you need to compare it with the existing known types to determine whether *aSurface* is a plane, a cylindrical surface or some other type.
+To compare a given type with the type you seek, use the *STANDARD_TYPE* macro, which returns the type of a class:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ if(aSurface->DynamicType() == STANDARD_TYPE(Geom_Plane)){
+ //
+ }
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If this comparison is true, you know that the *aSurface* real type is *Geom_Plane*. You can then convert it from *Geom_Surface* to *Geom_Plane* by using the *DownCast()* method provided by each class inheriting *Standard_Transient*. As its name implies, this static method is used to downcast objects to a given type with the following syntax:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ Handle(Geom_Plane) aPlane = Handle(Geom_Plane)::DownCast(aSurface);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Remember that the goal of all these conversions is to find the highest face of the bottle lying on a plane. Suppose that you have these two global variables:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ TopoDS_Face faceToRemove;
+ Standard_Real zMax = -1;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You can easily find the plane whose origin is the biggest in Z knowing that the location of the plane is given with the *Geom_Plane::Location* method. For example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ gp_Pnt aPnt = aPlane->Location();
+ Standard_Real aZ = aPnt.Z();
+ if(aZ > zMax){
+ zMax = aZ;
+ faceToRemove = aFace;
+ }
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You have now found the top face of the neck. Your final step before creating the hollowed solid is to put this face in a list. Since more than one face can be removed from the initial solid, the *BRepOffsetAPI_MakeThickSolid* constructor takes a list of faces as arguments.
+Open CASCADE Technology provides many collections for different kinds of objects: see *TColGeom* package for collections of objects from *Geom* package, *TColgp* package for collections of objects from gp package, etc.
+The collection for shapes can be found in the *TopTools* package. As *BRepOffsetAPI_MakeThickSolid* requires a list, use the *TopTools_ListOfShape* class.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ TopTools_ListOfShape facesToRemove;
+ facesToRemove.Append(faceToRemove);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+All the necessary data are now available so you can create your hollowed solid by calling the *BRepOffsetAPI_MakeThickSolid* constructor:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ MyBody = BRepOffsetAPI_MakeThickSolid(myBody, facesToRemove, -myThickness / 50, 1.e-3);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+@section sec4 Building the Threading
+
+
+@subsection OCCT_TUTORIAL_SUB4_1 Creating Surfaces
+
+
+Up to now, you have learned how to create edges out of 3D curves.
+You will now learn how to create an edge out of a 2D curve and a surface.
+To learn this aspect of Open CASCADE Technology, you will build helicoidal profiles out of 2D curves on cylindrical surfaces. The theory is more complex than in previous steps, but applying it is very simple.
+As a first step, you compute these cylindrical surfaces. You are already familiar with curves of the *Geom* package. Now you can create a cylindrical surface (*Geom_CylindricalSurface*) using:
+
+ * a coordinate system;
+ * a radius.
+
+Using the same coordinate system *neckAx2* used to position the neck, you create two cylindrical surfaces *Geom_CylindricalSurface* with the following radii:
+
+
+
+Notice that one of the cylindrical surfaces is smaller than the neck. There is a good reason for this: after the thread creation, you will fuse it with the neck. So, we must make sure that the two shapes remain in contact.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ Handle(Geom_CylindricalSurface) aCyl1 = new Geom_CylindricalSurface(neckAx2, myNeckRadius * 0.99);
+
+ Handle(Geom_CylindricalSurface) aCyl2 = new Geom_CylindricalSurface(neckAx2, myNeckRadius * 1.05);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+@subsection OCCT_TUTORIAL_SUB4_2 Defining 2D Curves
+
+
+To create the neck of the bottle, you made a solid cylinder based on a cylindrical surface. You will create the profile of threading by creating 2D curves on such a surface.
+All geometries defined in the *Geom* package are parameterized. This means that each curve or surface from Geom is computed with a parametric equation.
+A *Geom_CylindricalSurface* surface is defined with the following parametric equation:
+
+P(U, V) = O + R * (cos(U) * xDir + sin(U) * yDir) + V * zDir, where :
+
+ * P is the point defined by parameters (U, V).
+ * O, *Dir, yDir and zDir are respectively the origin, the X direction, Y direction and Z direction of the cylindrical surface local coordinate system.
+ * R is the radius of the cylindrical surface.
+ * U range is [0, 2PI] and V is infinite.
+
+
+
+The advantage of having such parameterized geometries is that you can compute, for any (U, V) parameters of the surface:
+
+ * the 3D point;
+ * the derivative vectors of order 1, 2 to N at this point.
+
+There is another advantage of these parametric equations: you can consider a surface as a 2D parametric space defined with a (U, V) coordinate system. For example, consider the parametric ranges of the neck's surface:
+
+
+
+Suppose that you create a 2D line on this parametric (U, V) space and compute its 3D parametric curve. Depending on the line definition, results are as follows:
+
+| Case | Parametric Equation | Parametric Curve |
+| :------------ | :----------------------------------------------------------- | :---------------------------------------------------------------------------- |
+| U = 0 | P(V) = O + V * zDir | Line parallel to the Z direction |
+| V = 0 | P(U) = O + R * (cos(U) * xDir + sin(U) * yDir) | Circle parallel to the (O, X, Y) plane |
+| U != 0 V != 0 | P(U, V) = O + R * (cos(U) * xDir + sin(U) * yDir) + V * zDir | Helicoidal curve describing the evolution of height and angle on the cylinder |
+
+The helicoidal curve type is exactly what you need. On the neck's surface, the evolution laws of this curve will be:
+
+ * In V parameter: between 0 and myHeighNeck for the height description
+ * In U parameter: between 0 and 2PI for the angle description. But, since a cylindrical surface is U periodic, you can decide to extend this angle evolution to 4PI as shown in the following drawing:
+
+
+
+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.
+
+
+
+To use 2D primitive geometry types of Open CASCADE Technology for defining a point and a coordinate system, you will once again instantiate classes from gp:
+
+ * To define a 2D point from its X and Y coordinates, use the *gp_Pnt2d* class.
+ * To define a 2D direction (unit vector) from its X and Y coordinates, use the gp_Dir2d class. The coordinates will automatically be normalized.
+ * To define a 2D right-handed coordinate system, use the *gp_Ax2d* class, which is computed from a point (origin of the coordinate system) and a direction - the X direction of the coordinate system. The Y direction will be automatically computed.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ gp_Pnt2d aPnt(2. * M_PI, myNeckHeight / 2.);
+ gp_Dir2d aDir(2. * M_PI, myNeckHeight / 4.);
+ gp_Ax2d anAx2d(aPnt, aDir);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+You will now define the curves. As previously mentioned, these thread profiles are computed on two cylindrical surfaces. In the following figure, curves on the left define the base (on *aCyl1* surface) and the curves on the right define the top of the thread's shape (on *aCyl2* surface).
+
+
+
+You have already used the *Geom* package to define 3D geometric entities. For 2D, you will use the *Geom2d* package. As for *Geom*, all geometries are parameterized. For example, a *Geom2d_Ellipse* ellipse is defined from:
+
+ * a coordinate system whose origin is the ellipse center;
+ * a major radius on the major axis defined by the X direction of the coordinate system;
+ * a minor radius on the minor axis defined by the Y direction of the coordinate system.
+
+Supposing that:
+
+ * Both ellipses have the same major radius of 2*PI,
+ * Minor radius of the first ellipse is myNeckHeight / 10,
+ * And the minor radius value of the second ellipse is a fourth of the first one,
+
+Your ellipses are defined as follows:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ Standard_Real aMajor = 2. * M_PI;
+ Standard_Real aMinor = myNeckHeight / 10;
+ Handle(Geom2d_Ellipse) anEllipse1 = new Geom2d_Ellipse(anAx2d, aMajor, aMinor);
+ Handle(Geom2d_Ellipse) anEllipse2 = new Geom2d_Ellipse(anAx2d, aMajor, aMinor / 4);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To describe portions of curves for the arcs drawn above, you define *Geom2d_TrimmedCurve* trimmed curves out of the created ellipses and two parameters to limit them.
+As the parametric equation of an ellipse is P(U) = O + (MajorRadius * cos(U) * XDirection) + (MinorRadius * sin(U) * YDirection), the ellipses need to be limited between 0 and M_PI.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ Handle(Geom2d_TrimmedCurve) anArc1 = new Geom2d_TrimmedCurve(anEllipse1, 0, M_PI);
+ Handle(Geom2d_TrimmedCurve) anArc2 = new Geom2d_TrimmedCurve(anEllipse2, 0, M_PI);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The last step consists in defining the segment, which is the same for the two profiles: a line limited by the first and the last point of one of the arcs.
+To access the point corresponding to the parameter of a curve or a surface, you use the Value or D0 method (meaning 0th derivative), D1 method is for first derivative, D2 for the second one.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ gp_Pnt2d anEllipsePnt1 = anEllipse1->Value(0);
+ gp_Pnt2d anEllipsePnt2;
+ anEllipse1->D0(M_PI, anEllipsePnt2);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+When creating the bottle's profile, you used classes from the *GC* package, providing algorithms to create elementary geometries.
+In 2D geometry, this kind of algorithms is found in the *GCE2d* package. Class names and behaviors are similar to those in *GC*. For example, to create a 2D segment out of two points:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ Handle(Geom2d_TrimmedCurve) aSegment = GCE2d_MakeSegment(anEllipsePnt1, anEllipsePnt2);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+@subsection OCCT_TUTORIAL_SUB4_3 Building Edges and Wires
+
+
+As you did when creating the base profile of the bottle, you can now:
+
+ * compute the edges of the neck's threading.
+ * compute two wires out of these edges.
+
+
+
+Previously, you have built:
+
+ * two cylindrical surfaces of the threading
+ * three 2D curves defining the base geometry of the threading
+
+To compute the edges out of these curves, once again use the *BRepBuilderAPI_MakeEdge* class. One of its constructors allows you to build an edge out of a curve described in the 2D parametric space of a surface.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ TopoDS_Edge anEdge1OnSurf1 = BRepBuilderAPI_MakeEdge(anArc1, aCyl1);
+ TopoDS_Edge anEdge2OnSurf1 = BRepBuilderAPI_MakeEdge(aSegment, aCyl1);
+ TopoDS_Edge anEdge1OnSurf2 = BRepBuilderAPI_MakeEdge(anArc2, aCyl2);
+ TopoDS_Edge anEdge2OnSurf2 = BRepBuilderAPI_MakeEdge(aSegment, aCyl2);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Now, you can create the two profiles of the threading, lying on each surface.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ TopoDS_Wire threadingWire1 = BRepBuilderAPI_MakeWire(anEdge1OnSurf1, anEdge2OnSurf1);
+ TopoDS_Wire threadingWire2 = BRepBuilderAPI_MakeWire(anEdge1OnSurf2, anEdge2OnSurf2);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Remember that these wires were built out of a surface and 2D curves.
+One important data item is missing as far as these wires are concerned: there is no information on the 3D curves. Fortunately, you do not need to compute this yourself, which can be a difficult task since the mathematics can be quite complex.
+When a shape contains all the necessary information except 3D curves, Open CASCADE Technology provides a tool to build them automatically. In the BRepLib tool package, you can use the *BuildCurves3d* method to compute 3D curves for all the edges of a shape.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ BRepLib::BuildCurves3d(threadingWire1);
+ BRepLib::BuildCurves3d(threadingWire2);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+@subsection OCCT_TUTORIAL_SUB4_4 Creating Threading
+
+
+You have computed the wires of the threading. The threading will be a solid shape, so you must now compute the faces of the wires, the faces allowing you to join the wires, the shell out of these faces and then the solid itself. This can be a lengthy operation.
+There are always faster ways to build a solid when the base topology is defined. You would like to create a solid out of two wires. Open CASCADE Technology provides a quick way to do this by building a loft: a shell or a solid passing through a set of wires in a given sequence.
+The loft function is implemented in the *BRepOffsetAPI_ThruSections* class, which you use as follows:
+
+
+
+ * Initialize the algorithm by creating an instance of the class. The first parameter of this constructor must be specified if you want to create a solid. By default, *BRepOffsetAPI_ThruSections* builds a shell.
+ * Add the successive wires using the AddWire method.
+ * Use the *CheckCompatibility* method to activate (or deactivate) the option that checks whether the wires have the same number of edges. In this case, wires have two edges each, so you can deactivate this option.
+ * Ask for the resulting loft shape with the Shape method.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ BRepOffsetAPI_ThruSections aTool(Standard_True);
+ aTool.AddWire(threadingWire1); aTool.AddWire(threadingWire2);
+ aTool.CheckCompatibility(Standard_False);
+ TopoDS_Shape myThreading = aTool.Shape();
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+@section sec5 Building the Resulting Compound
+
+
+You are almost done building the bottle. Use the *TopoDS_Compound* and *BRep_Builder* classes to build single shape from *myBody* and *myThreading*:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ TopoDS_Compound aRes;
+ BRep_Builder aBuilder;
+ aBuilder.MakeCompound (aRes);
+ aBuilder.Add (aRes, myBody);
+ aBuilder.Add (aRes, myThreading);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Congratulations! Your bottle is complete. Here is the result snapshot of the Tutorial application:
+
+
+
+We hope that this tutorial has provided you with a feel for the industrial strength power of Open CASCADE Technology.
+If you want to know more and develop major projects using Open CASCADE Technology, we invite you to study our training, support, and consulting services on our site at http://www.opencascade.org/support. Our professional services can maximize the power of your Open CASCADE Technology applications.
+
+
+@section sec6 Appendix
+
+
+Complete definition of MakeBottle function (defined in the file src/MakeBottle.cxx of the Tutorial):
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ TopoDS_Shape MakeBottle(const Standard_Real myWidth, const Standard_Real myHeight,
+ const Standard_Real myThickness)
+ {
+ // Profile : Define Support Points
+ gp_Pnt aPnt1(-myWidth / 2., 0, 0);
+ gp_Pnt aPnt2(-myWidth / 2., -myThickness / 4., 0);
+ gp_Pnt aPnt3(0, -myThickness / 2., 0);
+ gp_Pnt aPnt4(myWidth / 2., -myThickness / 4., 0);
+ gp_Pnt aPnt5(myWidth / 2., 0, 0);
+
+ // Profile : Define the Geometry
+ Handle(Geom_TrimmedCurve) anArcOfCircle = GC_MakeArcOfCircle(aPnt2,aPnt3,aPnt4);
+ Handle(Geom_TrimmedCurve) aSegment1 = GC_MakeSegment(aPnt1, aPnt2);
+ Handle(Geom_TrimmedCurve) aSegment2 = GC_MakeSegment(aPnt4, aPnt5);
+
+ // Profile : Define the Topology
+ TopoDS_Edge anEdge1 = BRepBuilderAPI_MakeEdge(aSegment1);
+ TopoDS_Edge anEdge2 = BRepBuilderAPI_MakeEdge(anArcOfCircle);
+ TopoDS_Edge anEdge3 = BRepBuilderAPI_MakeEdge(aSegment2);
+ TopoDS_Wire aWire = BRepBuilderAPI_MakeWire(anEdge1, anEdge2, anEdge3);
+
+ // Complete Profile
+ gp_Ax1 xAxis = gp::OX();
+ gp_Trsf aTrsf;
+
+ aTrsf.SetMirror(xAxis);
+ BRepBuilderAPI_Transform aBRepTrsf(aWire, aTrsf);
+ TopoDS_Shape aMirroredShape = aBRepTrsf.Shape();
+ TopoDS_Wire aMirroredWire = TopoDS::Wire(aMirroredShape);
+
+ BRepBuilderAPI_MakeWire mkWire;
+ mkWire.Add(aWire);
+ mkWire.Add(aMirroredWire);
+ TopoDS_Wire myWireProfile = mkWire.Wire();
+
+ // Body : Prism the Profile
+ TopoDS_Face myFaceProfile = BRepBuilderAPI_MakeFace(myWireProfile);
+ gp_Vec aPrismVec(0, 0, myHeight);
+ TopoDS_Shape myBody = BRepPrimAPI_MakePrism(myFaceProfile, aPrismVec);
+
+ // Body : Apply Fillets
+ BRepFilletAPI_MakeFillet mkFillet(myBody);
+ TopExp_Explorer anEdgeExplorer(myBody, TopAbs_EDGE);
+ while(anEdgeExplorer.More()){
+ TopoDS_Edge anEdge = TopoDS::Edge(anEdgeExplorer.Current());
+ //Add edge to fillet algorithm
+ mkFillet.Add(myThickness / 12., anEdge);
+ anEdgeExplorer.Next();
+ }
+
+ myBody = mkFillet.Shape();
+
+ // Body : Add the Neck
+ gp_Pnt neckLocation(0, 0, myHeight);
+ gp_Dir neckAxis = gp::DZ();
+ gp_Ax2 neckAx2(neckLocation, neckAxis);
+
+ Standard_Real myNeckRadius = myThickness / 4.;
+ Standard_Real myNeckHeight = myHeight / 10.;
+
+ BRepPrimAPI_MakeCylinder MKCylinder(neckAx2, myNeckRadius, myNeckHeight);
+ TopoDS_Shape myNeck = MKCylinder.Shape();
+
+ myBody = BRepAlgoAPI_Fuse(myBody, myNeck);
+
+ // Body : Create a Hollowed Solid
+ TopoDS_Face faceToRemove;
+ Standard_Real zMax = -1;
+
+ for(TopExp_Explorer aFaceExplorer(myBody, TopAbs_FACE); aFaceExplorer.More(); aFaceExplorer.Next()){
+ TopoDS_Face aFace = TopoDS::Face(aFaceExplorer.Current());
+ // Check if <aFace> is the top face of the bottle's neck
+ Handle(Geom_Surface) aSurface = BRep_Tool::Surface(aFace);
+ if(aSurface->DynamicType() == STANDARD_TYPE(Geom_Plane)){
+ Handle(Geom_Plane) aPlane = Handle(Geom_Plane)::DownCast(aSurface);
+ gp_Pnt aPnt = aPlane->Location();
+ Standard_Real aZ = aPnt.Z();
+ if(aZ > zMax){
+ zMax = aZ;
+ faceToRemove = aFace;
+ }
+ }
+ }
+
+ TopTools_ListOfShape facesToRemove;
+ facesToRemove.Append(faceToRemove);
+ myBody = BRepOffsetAPI_MakeThickSolid(myBody, facesToRemove, -myThickness / 50, 1.e-3);
+ // Threading : Create Surfaces
+ Handle(Geom_CylindricalSurface) aCyl1 = new Geom_CylindricalSurface(neckAx2, myNeckRadius * 0.99);
+ Handle(Geom_CylindricalSurface) aCyl2 = new Geom_CylindricalSurface(neckAx2, myNeckRadius * 1.05);
+
+ // Threading : Define 2D Curves
+ gp_Pnt2d aPnt(2. * M_PI, myNeckHeight / 2.);
+ gp_Dir2d aDir(2. * M_PI, myNeckHeight / 4.);
+ gp_Ax2d anAx2d(aPnt, aDir);
+
+ Standard_Real aMajor = 2. * M_PI;
+ Standard_Real aMinor = myNeckHeight / 10;
+
+ Handle(Geom2d_Ellipse) anEllipse1 = new Geom2d_Ellipse(anAx2d, aMajor, aMinor);
+ Handle(Geom2d_Ellipse) anEllipse2 = new Geom2d_Ellipse(anAx2d, aMajor, aMinor / 4);
+ Handle(Geom2d_TrimmedCurve) anArc1 = new Geom2d_TrimmedCurve(anEllipse1, 0, M_PI);
+ Handle(Geom2d_TrimmedCurve) anArc2 = new Geom2d_TrimmedCurve(anEllipse2, 0, M_PI);
+ gp_Pnt2d anEllipsePnt1 = anEllipse1->Value(0);
+ gp_Pnt2d anEllipsePnt2 = anEllipse1->Value(M_PI);
+
+ Handle(Geom2d_TrimmedCurve) aSegment = GCE2d_MakeSegment(anEllipsePnt1, anEllipsePnt2);
+ // Threading : Build Edges and Wires
+ TopoDS_Edge anEdge1OnSurf1 = BRepBuilderAPI_MakeEdge(anArc1, aCyl1);
+ TopoDS_Edge anEdge2OnSurf1 = BRepBuilderAPI_MakeEdge(aSegment, aCyl1);
+ TopoDS_Edge anEdge1OnSurf2 = BRepBuilderAPI_MakeEdge(anArc2, aCyl2);
+ TopoDS_Edge anEdge2OnSurf2 = BRepBuilderAPI_MakeEdge(aSegment, aCyl2);
+ TopoDS_Wire threadingWire1 = BRepBuilderAPI_MakeWire(anEdge1OnSurf1, anEdge2OnSurf1);
+ TopoDS_Wire threadingWire2 = BRepBuilderAPI_MakeWire(anEdge1OnSurf2, anEdge2OnSurf2);
+ BRepLib::BuildCurves3d(threadingWire1);
+ BRepLib::BuildCurves3d(threadingWire2);
+
+ // Create Threading
+ BRepOffsetAPI_ThruSections aTool(Standard_True);
+ aTool.AddWire(threadingWire1);
+ aTool.AddWire(threadingWire2);
+ aTool.CheckCompatibility(Standard_False);
+
+ TopoDS_Shape myThreading = aTool.Shape();
+
+ // Building the Resulting Compound
+ TopoDS_Compound aRes;
+ BRep_Builder aBuilder;
+ aBuilder.MakeCompound (aRes);
+ aBuilder.Add (aRes, myBody);
+ aBuilder.Add (aRes, myThreading);
+
+ return aRes;
+ }
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--- /dev/null
+# Command-line starter for occdoc command, use it as follows:
+# tclsh> source dox/start.tcl [arguments]
+
+source [file join [file dirname [info script]] occdoc.tcl]
+occdoc {*}$argv
\ No newline at end of file
--- /dev/null
+Technical Overview {#technical_overview}
+========================================
+
+@section OCCT_TOVW_SECTION_1 Product Overview
+
+Open CASCADE Technology is an object-oriented C++ class librarLzlz ljky designed for rapid
+production of sophisticated domain-specific design applications. A typical application
+developed using OCCT deals with two or three-dimensional (2D or 3D) geometric modeling
+in general-purpose or specialized Computer Aided Design (CAD) systems, manufacturing
+or analysis applications, simulation applications, or illustration tools. OCCT Object
+Libraries help you to develop your applications significantly faster.
+
+
+
+The OCCT Library provides the following services:
+
+
+ * 2D and 3D geometric modeling toolkits which allow you to model any type of object:
+ * Creating primitives such as prism, cylinder, cone and torus
+ * Performing Boolean operations (addition, subtraction and intersection)
+ * Tweaking constructions using fillets, chamfers and drafts
+ * Modeling constructions using offsets, shelling, hollowing and sweeps
+ * Computing properties such as surface, volume, center of gravity, curvature
+ * Computing geometry using projection, interpolation, approximation
+ * Visualization services that allow you to manage object display and manipulate views, for example:
+ * 3D rotation
+ * Zoom
+ * Shading
+ * The application framework features:
+ * Association between non-geometric application data and geometry
+ * Parameterization of models
+ * Java Application Desktop (JAD), a framework for creating your Graphical User Interfaces (GUI)
+ * Data exchange providing import and export functions of OCCT models to and from standard formats such as IGES and STEP
+
+OCCT Library is developed and marketed by OPEN CASCADE Company. The library is designed
+to be truly modular and extensible. As such, they separate C++ classes for:
+
+ * Defining data structures (geometric modeling, display and graphic selection)
+ * Implementing complex algorithms
+ * Providing Application Programming Interfaces (APIs)
+
+
+Related classes are grouped into packages to prevent any class-name conflicts;
+C++ class-names are prefixed by a package name. For example, all classes defining
+3D geometric objects belong to the Geompackage.
+In Geom, the class implementing Bezier surfaces is called BezierSurface, and its full name is <i> Geom_BezierSurface</i>.
+
+Packages are then archived into libraries, to which you can link your application.
+
+Finally, libraries are grouped into six modules: Foundation Classes,
+Modeling Data, Modeling Algorithms, Visualization, Data Exchange and Application Framework.
+
+In addition Draw Test Harness (Draw) provides testing tools for the Visualization,
+Modeling Algorithms, Application Framework and Data Exchange modules.
+These tools include a wide range of interpreted commands which allow experimenting with OCCT.
+
+Refer to the Technical Overview and OCCT documentation for details about the services provided in each module.
+
+@section OCCT_TOVW_SECTION_2 Foundation Classes
+
+
+Foundation Classes provide a variety of general-purpose services such as:
+
+ * Primitive types, strings and various types of quantities
+ * Automated management of heap memory
+ * Exception handling
+ * Classes for manipulating data collections
+ * Math tools such as vectors, matrices and primitive geometric types
+ * Basic services for saving data in ASCII files
+
+These services are organized into the following libraries:
+
+ * Kernel Classes
+ * Math Utilities
+ * Basic Persistence
+
+The technical overview provides only a basic description of the libraries. Please, refer for more details to Foundation Classes User's guide
+
+See also: our web site at E-learning and Training.
+
+@subsection OCCT_TOVW_SECTION_2_1 Kernel Classes
+
+
+Root Classes
+------------
+
+Root Classes, primarily implemented in the Standard package, are the predefined classes on which
+all other Open CASCADE Technology classes are built. They provide:
+
+ * Primitive types such as Boolean, Character, Integer or Real
+ * Memory manager based on reference counting for optimizing the allocation and deallocation of large numbers of small C++ objects
+ * <i>Standard_Transient</i> class automating memory management through smart pointers
+ * OCCT <i>Handle</i>; most of OCCT classes inherit from this base class.
+ * Management of exceptions,
+ * Encapsulation of C++ streams.
+
+Quantities
+-----------
+
+Quantity classes provide the following services:
+
+ * Definition of primitive types representing most of mathematical and physical quantities
+ * Unit conversion tools.
+ * Resources to manage time information such as dates and time periods
+ * Resources to manage color definition
+
+A mathematical quantity is characterized by the name and the value (real).
+A physical quantity is characterized by the name, the value (real) and the unit.
+The unit may be either an international unit complying with the International Unit System (SI)
+or a user defined unit. The unit is managed by the physical quantity user.
+
+The fact that both physical and mathematical quantities are manipulated as real
+values means that :
+
+ * They are defined as aliases of real values, so all functions provided by the <i>Standard_Real</i> class are available on each quantity.
+ * It is possible to mix several physical quantities in a mathematical or physical formula involving real values.
+
+<i>Quantity</i> package includes all commonly used basic physical quantities.
+
+Exceptions
+----------
+
+Exception classes list all the exceptions, which can be raised by any OCCT function.
+
+Each exception inherits from Standard_Failure either directly or by inheriting from
+another exception.
+
+Exceptions describe anomalies which can occur during the execution of a method. With
+the raising of an exception, the normal course of program execution is abandoned.
+The execution of actions in response to this situation is called the treatment of
+the exception.
+
+
+The methods try & catch are redefined in OCCT to work properly on any platform. Nevertheless
+they call native mechanisms each time it is possible. The only reason not to use
+native exceptions is that they may not work properly on some compilers. In this case,
+a specific OCCT code is used instead.
+
+
+Strings
+-------
+
+Strings are classes that handle dynamically sized sequences of characters based on
+ASCII/Unicode UTF-8 (normal 8-bit character type)
+and UTF-16/UCS-2 (16-bit character type). They provide editing operations with built-in
+memory management which make the relative objects easier to use than ordinary character
+arrays.
+
+String classes provide the following services to manipulate character strings:
+ * Editing operations on string objects, using a built-in string manager
+ * Handling of dynamically-sized sequences of characters
+ * Conversion from/to ASCII and UTF-8 strings.
+
+Strings may also be manipulated by handles and therefore, can be shared.
+
+These classes are implemented in <i>TCollection</i> and <i>NCollection</i> packages.
+
+
+Collections
+-----------
+
+Apart from strings, the <i> TCollection</i> package contains classes of dynamically sized
+aggregates of data. They include a wide range of collections.
+
+ * Arrays (unidimensional and bidimensional) are generally used for quick access to an item.
+ Note that an array is a fixed-sized aggregate.
+ * Sequences are ordered collections of non-unique objects.
+ A sequence item is longer to access than an array item: only an exploration in sequence
+ is efficient (but sequences are not adapted for numerous explorations).
+ Arrays and sequences are commonly used as data structures for more complex objects.
+ * Maps are dynamic structures where the size is constantly adapted to the number of inserted
+ items and access to an item is the fastest. Maps structures are commonly used in
+ cases of numerous explorations: they are typically internal data structures for complex
+ algorithms. Sets generate the same results as maps but computation time is considerable.
+ * Lists, queues and stacks, which are minor structures similar to sequences but with different
+ algorithms to explore them
+ * Specific iterators for sequences, maps, and stacks.
+
+Most collections follow value semantics: their instances are the actual collections,
+not handles to a collection. Only arrays, sequences and sets may also be manipulated
+by handle, and therefore shared.
+
+
+Collection classes are generic (C++ template-like), so they can contain
+a variety of objects which do not necessarily inherit from
+a unique root class. When you need to use a collection of a given object type, you
+must instantiate the collection for this specific type. Once the code for this declaration
+is compiled, all functions available on the generic collection are available on your
+instantiated class.
+
+Each collection directly used as an argument in Open CASCADE Technology public syntax
+is instantiated in an OCCT component using the corresponding generic class in package
+<i> TCollection</i>, by means of compiling the CDL declaration of the instance.
+Thus OCCT generic classes require compilation of definitions in the CDL language and therefore
+can only be instantiated in WOK.
+
+If you are not using CDL in your project (CDL compilation under WOK is necessary
+to instantiate any generic Collection from package <i>TCollection</i>), then you should
+use the Collections defined in <i> NCollection</i> package. It contains definitions of the
+same generic collection classes described above, but in a form of C++ templates.
+Therefore, to instantiate any collection type no additional support is required beyond
+the ANSI C++ compiler.
+
+@subsection OCCT_TOVW_SECTION_2_2 Math Utilities
+
+
+Vectors and Matrices
+--------------------
+
+The <i> Vector</i> and <i> Matrix </i> classes provide commonly used mathematical algorithms which
+include:
+
+ * Basic calculations involving vectors and matrices;
+ * Computation of eigenvalues and eigenvectors of a square matrix;
+ * Solvers for a set of linear algebraic equations;
+ * Algorithms to find the roots of a set of non-linear equations;
+ * Algorithms to find the minimum function of one or more independent variables.
+
+These classes also provide a data structure to represent any expression,
+relation, or function used in mathematics, including the assignment of variables.
+
+Vectors and matrices have arbitrary ranges which must be defined at declaration time
+and cannot be changed after declaration.
+
+~~~
+ math_Vector v(1, 3);
+ // a vector of dimension 3 with range (1..3)
+
+ math_Matrix m(0, 2, 0, 2);
+ // a matrix of dimension 3x3 with range (0..2, 0..2)
+
+ math_Vector v(N1, N2);
+ // a vector of dimension N2-N1+1 with range (N1..N2)
+~~~
+
+Vector and Matrix objects follow "value semantics", that is, they cannot be shared
+and are copied though assignment.
+
+~~~
+ math_Vector v1(1, 3), v2(0, 2);
+
+ v2 = v1; // v1 is copied into v2
+ // a modification of v1 does not affect v2
+~~~
+
+Vector and Matrix elements can be retrieved using indexes, which must be in the range
+defined upon Vector/Matrix creation. The elements can be initialized with some numerical
+value upon creation as well.
+
+~~~
+ math_Vector v(1, 3);
+ math_Matrix m(1, 3, 1, 3);
+ Standard_Real value;
+
+ v(2) = 1.0;
+ value = v(1);
+ m(1, 3) = 1.0;
+ value = m(2, 2);
+~~~
+
+Some operations on Vector and Matrix objects may not be legal. In this case an exception
+is raised. Two standard exceptions are used:
+ * <i> Standard_DimensionError </i> exception is raised when two matrices or vectors involved
+in an operation are of incompatible dimensions.
+ * <i> Standard_RangeError </i>exception is raised if an attempt to access outside the range
+defined upon creation of a vector or a matrix is made.
+
+~~~
+ math_Vector v1(1, 3), v2(1, 2), v3(0, 2);
+
+ v1 = v2; // error:
+ // Standard_DimensionError is raised
+
+ v1 = v3; // OK: ranges are not equal
+ // but dimensions are compatible
+
+ v1(0) = 2.0; // error:
+ // Standard_RangeError is raised
+~~~
+
+
+Fundamental Geometry Types
+-------------------------
+
+The Fundamental Geometry Types component groups the following packages:
+
+ * geometric processor package <i> gp</i>;
+ * <i>GeomAbs</i> package, which provides enumerations generally used in geometry.
+
+<i>gp</i> package is a STEP-compliant implementation of basic geometric and algebraic
+entities, used to define and manipulate elementary data structures.
+
+In particular, <i>gp</i> provides:
+
+ * descriptions of primitive geometric shapes, such as:
+ * Points;
+ * Vectors;
+ * Lines;
+ * Circles and conics;
+ * Planes and elementary surfaces;
+ * positioning of these shapes in space or in a plane by means of an axis or a coordinate system;
+ * definition and application of geometric transformations to these shapes:
+ * Translations;
+ * Rotations;
+ * Symmetries;
+ * Scaling transformations;
+ * Composed transformations;
+ * Tools (coordinates and matrices) for algebraic computation.
+
+These functions are defined in 3D space and in the plane.
+
+<i> gp</i> curves and surfaces are analytic: there is no parameterization and no orientation
+on <i>gp</i> entities, i.e. these entities do not provide functions which work with these properties.
+If you need, you may use more evolved data structures provided by <i> Geom</i>
+(in 3D space) and <i> Geom2d</i> (in the plane). However, the definition of <i> gp</i> entities
+is identical to the one of equivalent <i> Geom</i> and <i> Geom2d</i> entities, and they are located
+in the plane or in space with the same kind of positioning systems.
+They implicitly contain the orientation, which they express
+on the <i> Geom </i> and <i> Geom2d </i> entities, and they induce the definition of their parameterization.
+
+
+Therefore, it is easy to give an implicit parameterization to <i> gp</i> curves and surfaces,
+which is the parametarization of the equivalent <i> Geom</i> or <i> Geom2d</i> entity. This property
+is particularly useful when computing projections or intersections, or for operations
+involving complex algorithms where it is particularly important to manipulate the
+simplest data structures, i.e. those of <i> gp</i>. Thus, the <i> ElCLib</i> and <i> ElSLib</i> packages
+provide functions to compute:
+
+ * the point of parameter u on a 2D or 3D gp curve,
+ * the point of parameter (u,v) on a gp elementary surface, and
+ * any derivative vector at this point.
+
+Note: the <i> gp</i> entities cannot be shared when they are inside more complex data structures.
+
+
+Common Mathematical Algorithms
+----------------------
+
+Common mathematical algorithms provided in OCCT include:
+
+ * Algorithms to solve a set of linear algebraic equations,
+ * Algorithms to find the minimum of a function of one or more independent variables,
+ * Algorithms to find roots of one or of a set of non-linear equations,
+ * An algorithm to find the eigenvalues and eigenvectors of a square matrix.
+
+
+@section OCCT_TOVW_SECTION_3 Modeling Data
+
+Modeling Data supplies data structures to represent 2D and 3D geometric models.
+
+
+
+These services are organized into the following libraries:
+
+ * 2D Geometry
+ * 3D Geometry
+ * Geometry Utilities
+ * Topology
+
+The technical overview provides only a basic description of the libraries. Please,
+refer for more details to Modeling Data User's guide
+
+3D geometric models are stored in OCCT native BREP format. It is possible to learn
+more about it in BREP Format Description White Paper
+
+See also: our web site at E-learning and Training.
+
+@subsection OCCT_TOVW_SECTION_3_1 2D Geometry Types
+
+<i> Geom2d</i> package provides an implementation of 2D geometric objects complying with
+STEP, part 42. In particular, it provides functions for:
+
+ * description of points, vectors and curves,
+ * their positioning in the plane using coordinate systems,
+ * their geometric transformation, by applying translations, rotations, symmetries, scaling transformations and combinations thereof.
+
+The key characteristic of <i> Geom2d </i> curves is that they are parameterized.
+Each class provides functions to work with the parametric equation of the curve,
+and, in particular, to compute the point of parameter u on a curve and the derivative vectors of order 1, 2.., N at this point.
+
+As a consequence of the parameterization, a <i> Geom2d </i> curve is naturally oriented.
+
+Parameterization and orientation differentiate elementary <i>Geom2d </i>curves from their
+equivalent as provided by <i> gp</i> package. <i> Geom2d</i> package provides conversion
+functions to transform a <i> Geom2d</i> object into a <i> gp</i> object, and vice-versa, when this is possible.
+
+Moreover, <i> Geom2d</i> package provides more complex curves, including Bezier curves,
+BSpline curves, trimmed curves and offset curves.
+
+<i> Geom2d </i> objects are organized according to an inheritance structure over several levels.
+Thus, an ellipse (specific class <i> Geom2d_Ellipse</i>) is also a conical curve and inherits
+from the abstract class <i> Geom2d_Conic</i>, while a Bezier curve (concrete class <i> Geom2d_BezierCurve</i>)
+is also a bounded curve and inherits from the abstract class <i> Geom2d_BoundedCurve</i>;
+both these examples are also curves (abstract class <i>Geom2d_Curve</i>). Curves, points
+and vectors inherit from the abstract class <i> Geom2d_Geometry,<i> which describes the properties
+common to any geometric object from the <i>Geom2d</i> package.
+
+This inheritance structure is open and it is possible to describe new objects which
+inherit from those provided in the <i>Geom2d</i> package, provided that they respect the
+behavior of the classes from which they are to inherit.
+
+Finally, <i> Geom2d</i> objects can be shared within more complex data structures.
+This is why they are used within topological data structures, for example.
+
+<i> Geom2d </i>package uses the services of the <i> gp</i> package to:
+
+ * implement elementary algebraic calculus and basic analytic geometry,
+ * describe geometric transformations which can be applied to <i> Geom2d</i> objects,
+ * describe the elementary data structures of <i>Geom2d</i> objects.
+
+However, the <i> Geom2d</i> package essentially provides data structures and not algorithms.
+You can refer to the <i> GCE2d </i> package to find more evolved construction algorithms for <i> Geom2d </i> objects.
+
+@subsection OCCT_TOVW_SECTION_3_2 3D Geometry Types
+
+The <i> Geom</i> package provides an implementation of 3D geometric objects complying with
+STEP, part 42. In particular, it provides functions for:
+
+ * description of points, vectors, curves and surfaces,
+ * their positioning in 3D space using axis or coordinate systems, and
+ * their geometric transformation, by applying translations, rotations, symmetries, scaling transformations and combinations thereof.
+
+The key characteristic of Geom curves and surfaces is that they are parameterized.
+Each class provides functions to work with the parametric equation of the curve or
+surface, and, in particular, to compute:
+
+ * the point of parameter u on a curve, or
+ * the point of parameters (u, v) on a surface.
+
+together with the derivative vectors of order 1, 2, ... N at this point.
+
+As a consequence of this parameterization, a Geom curve or surface is naturally oriented.
+
+Parameterization and orientation differentiate elementary Geom curves and surfaces from the classes of the same (or similar) names found in the <i> gp</i> package.
+The <i>Geom</i> package also provides conversion functions to transform a Geom object into a <i> gp</i> object, and vice-versa, when such transformation is possible.
+
+Moreover, the <i> Geom </i>package provides more complex curves and surfaces, including:
+ * Bezier and BSpline curves and surfaces,
+ * swept surfaces, for example surfaces of revolution and surfaces of linear extrusion,
+ * trimmed curves and surfaces, and
+ * offset curves and surfaces.
+
+Geom objects are organized according to an inheritance structure over several levels.
+Thus, a sphere (concrete class <i> Geom_SphericalSurface</i>) is also an elementary surface and inherits from the abstract class <i> Geom_ElementarySurface</i>, while a Bezier surface (concrete class <i> Geom_BezierSurface</i>) is also a bounded surface and inherits from the abstract class <i> Geom_BoundedSurface</i>; both these examples are also surfaces (abstract class <i> Geom_Surface</i>). Curves, points and vectors inherit from the abstract class <i> Geom_Geometry,</i> which describes the properties common to any geometric object from the <i>Geom</i> package.
+
+This inheritance structure is open and it is possible to describe new objects, which inherit from those provided in the Geom package, on the condition that they respect the behavior of the classes from which they are to inherit.
+
+Finally, Geom objects can be shared within more complex data structures. This is why they are used within topological data structures, for example.
+
+The <i> Geom</i> package uses the services of the <i> gp</i> package to:
+ * implement elementary algebraic calculus and basic analytic geometry,
+ * describe geometric transformations which can be applied to Geom objects,
+ * describe the elementary data structures of Geom objects.
+
+However, the Geom package essentially provides data structures and not algorithms.
+You can refer to the <i> GC</i> package to find more evolved construction algorithms for
+Geom objects.
+
+
+Adaptors for Curves and Surfaces
+-----------------
+
+Some Open CASCADE Technology general algorithms may work theoretically on numerous types of curves or surfaces.
+To do this, they simply get the services required of the analysed curve or surface through an interface so as to a single API, whatever the type of curve or surface. These interfaces are called adaptors.
+For example, <i> Adaptor3d_Curve </i> is the abstract class which provides the required services by an algorithm which uses any 3d curve.
+
+<i> GeomAdaptor </i>package provides interfaces:
+
+ * On a Geom curve;
+ * On a curve lying on a Geom surface;
+ * On a Geom surface;
+
+<i> Geom2dAdaptor</i> package provides interfaces :
+
+ * On a <i>Geom2d</i> curve.
+
+<i> BRepAdaptor </i> package provides interfaces:
+
+ * On a Face
+ * On an Edge
+
+When you write an algorithm which operates on geometric objects, use <i> Adaptor3d</i> (or <i> Adaptor2d</i>) objects.
+As a result, you can use the algorithm with any kind of object,
+if you provide for this object, an interface derived from Adaptor3d or Adaptor2d.
+These interfaces are easy to use: simply create an adapted curve or surface from a Geom2d curve,
+and then use this adapted curve as an argument for the algorithm which requires it.
+
+
+@subsection OCCT_TOVW_SECTION_3_3 Geometry Utilities
+
+This library provides standard high-level functions in 2D and 3D geometry such as:
+
+ * Direct construction of algorithms;
+ * Approximation of curves and surfaces from points;
+ * Conversion of more elementary geometry to BSpline curves and surfaces;
+ * Calculation of points on a 2D or 3D curve;
+ * Calculation of extrema between two geometries.
+
+Direct Construction
+-------
+
+The <i> gp</i>, <i> Geom2d</i> and <i> Geom</i> packages describe elementary data structures of simple geometric
+objects. The constructors of these objects are elementary: the construction arguments
+are fields by which the objects are represented in their data structure.
+
+
+On the other hand, the <i> gce</i>, <i> GCE2d</i> and <i> GC</i> packages provided
+by the Direct Construction component construct the same types of objects
+as <i> gp</i>, <i> Geom2d </i>and <i> Geom</i> respectively.
+However, the former implement geometric construction algorithms that translate the
+constructor's arguments into the data structure specific to each object.
+
+
+Algorithms implemented by these packages are simple: there is no creation of objects
+defined by advanced positional constraints (for more information on this subject,
+see <i> Geom2dGcc</i> and <i> GccAna</i> which describe geometry by constraints).
+
+
+<i> gce</i>, <i> GCE2d</i> and <i> GC </i>each offer a series of classes of construction algorithms.
+
+
+For example, the class <i> gce_MakeCirc</i> provides a framework
+for defining eight problems encountered in the geometric construction of circles,
+and implementing the eight related construction algorithms.
+
+The object created (or implemented) is an algorithm which can be consulted to find out, in particular:
+
+ * its result, which is a </i>gp_Circ</i>, and
+ * its status. Here, the status indicates whether or not the construction was successful.
+
+If it was unsuccessful, the status gives the reason for the failure.
+
+~~~~
+ gp_Pnt P1 (0.,0.,0.);
+ gp_Pnt P2 (0.,10.,0.);
+ gp_Pnt P3 (10.,0.,0.);
+ gce_MakeCirc MC (P1,P2,P3);
+ if (MC.IsDone()) {
+ const gp_Circ& C = MC.Value();
+ }
+~~~~
+
+In addition, <i> gce</i>, <i> GCE2d</i> and <i> GC</i> each have a <i>Root</i> class. This class is the root of
+all the classes in the package which return a status. The returned status (successful
+construction or construction error) is described by the enumeration <i> gce_ErrorType</i>.
+
+Note: classes which construct geometric transformations do not return a status, and
+therefore do not inherit from Root.
+
+Approximations
+-----------
+
+Approximation of Curves and Surfaces groups together a variety of functions used in 2D and 3D geometry for:
+
+ * the interpolation of a set of 2D points using a 2D BSpline or Bezier curve;
+ * the approximation of a set of 2D points using a 2D BSpline or Bezier curve;
+ * the interpolation of a set of 3D points using a 3D BSpline or Bezier curve, or a BSpline surface;
+ * the approximation of a set of 3D points using a 3D BSpline or Bezier curve, or a BSpline surface.
+
+You can program approximations in two ways:
+
+ * Using high-level functions, designed to provide a simple method for obtaining approximations with minimal programming,
+ * Using low-level functions, designed for users requiring more control over the approximations.
+
+The low-level functions provide a second API with functions to:
+
+ * Define compulsory tangents for an approximation. These tangents have origins and extremities.
+ * Approximate a set of curves in parallel to respect identical parameterization.
+ * Smooth approximations. This is to produce a faired curve.
+
+The classes <i> AppDef_MultiPointConstraints</i> and <i> AppDef_MultiLines </i> allow organizing the data.
+The classes <i> AppDef_Compute</i>, <i> AppDef_BSplineCompute</i> and <i> AppDef_TheVariational </i>
+classes perform the approximation itself using Bezier curves, BSpline curves, and smooth BSpline curves, respectively.
+
+You can also find functions to compute:
+
+ * The minimal box which includes a set of points
+ * The mean plane, line or point of a set of coplanar, collinear or coincident points.
+
+Conversion to and from BSplines
+----------------------------
+
+The Conversion to and from BSplines component has the following two distinct purposes:
+ * Firstly, it provides a homogenous formulation which can be used to describe any curve or surface.
+ This is useful for writing algorithms for a single data structure model.
+ The BSpline formulation can be used to represent most basic geometric objects provided
+ by the components which describe geometric data structures ("Fundamental Geometry Types", "2D Geometry Types" and "3D Geometry Types" components).
+ * Secondly, it can be used to divide a BSpline curve or surface into a series of curves or surfaces,
+ thereby providing a higher degree of continuity. This is useful for writing algorithms
+ which require a specific degree of continuity in the objects to which they are applied.
+ Discontinuities are situated on the boundaries of objects only.
+
+The "Conversion to and from BSplines" component is composed of three packages.
+
+The <i> Convert </i> package provides algorithms to convert the following into a BSpline curve or surface:
+
+ * a bounded curve based on an elementary 2D curve (line, circle or conic) from the <i> gp </i> package,
+ * a bounded surface based on an elementary surface (cylinder, cone, sphere or torus) from the <i> gp</i> package,
+ * a series of adjacent 2D or 3D Bezier curves defined by their poles.
+
+These algorithms compute the data needed to define the resulting BSpline curve or surface.
+This elementary data (degrees, periodic characteristics, poles and weights, knots and multiplicities)
+may then be used directly in an algorithm, or can be used to construct the curve or the surface
+by calling the appropriate constructor provided by the classes <i>Geom2d_BSplineCurve, Geom_BSplineCurve </i> or <i>Geom_BSplineSurface</i>.
+
+The <i>Geom2dConvert</i> package provides the following:
+
+ * a global function which is used to construct a BSpline curve from a bounded curve based on a 2D curve from the Geom2d package,
+ * a splitting algorithm which computes the points at which a 2D BSpline curve should be cut in order to obtain arcs with the same degree of continuity,
+ * global functions used to construct the BSpline curves created by this splitting algorithm, or by other types of segmentation of the BSpline curve,
+ * an algorithm which converts a 2D BSpline curve into a series of adjacent Bezier curves.
+
+The <i> GeomConvert</i> package also provides the following:
+
+ * a global function used to construct a BSpline curve from a bounded curve based on a curve from the Geom package,
+ * a splitting algorithm, which computes the points at which a BSpline curve should be cut in order to obtain arcs with the same degree of continuity,
+ * global functions to construct BSpline curves created by this splitting algorithm, or by other types of BSpline curve segmentation,
+ * an algorithm, which converts a BSpline curve into a series of adjacent Bezier curves,
+ * a global function to construct a BSpline surface from a bounded surface based on a surface from the Geom package,
+ * a splitting algorithm, which determines the curves along which a BSpline surface should be cut in order to obtain patches with the same degree of continuity,
+ * global functions to construct BSpline surfaces created by this splitting algorithm, or by other types of BSpline surface segmentation,
+ * an algorithm, which converts a BSpline surface into a series of adjacent Bezier surfaces,
+ * an algorithm, which converts a grid of adjacent Bezier surfaces into a BSpline surface.
+
+Points on Curves
+--------
+
+The Making Points on Curves component comprises high level functions providing an Application Programming Interface for complex algorithms that compute points on a 2D or 3D curve. The functions use various methods.
+
+The algorithms result in the following:
+
+ * a point on a curve, situated at a given curvilinear distance from another point on the curve
+ * a distribution of points situated at constant curvilinear intervals along a curve
+ * a distribution of points at a constant rise (i.e. respecting a criterion of maximum rise between the curve and the polygon that results from the computed points) along a curve
+ * the length of a curve.
+
+@subsection OCCT_TOVW_SECTION_3_4 Topology
+
+Topological library allows you to build pure topological data structures..
+
+Topology defines relationships between simple geometric entities. In this way,
+you can model complex shapes as assemblies of simpler entities.
+Due to a built-in non-manifold (or mixed-dimensional) feature, you can build models mixing:
+
+ * 0D entities such as points;
+ * 1D entities such as curves;
+ * 2D entities such as surfaces;
+ * 3D entities such as volumes.
+
+You can, for example, represent a single object made of several distinct bodies
+containing embedded curves and surfaces connected or non-connected to an outer boundary.
+
+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.
+
+The wire and the solid can be either infinite or closed.
+
+A face with 3D underlying geometry may also refer to a collection of connected triangles
+that approximate the underlying surface. The surfaces can be undefined
+leaving the faces represented by triangles only. If so, the model is purely polyhedral.
+
+Topology defines the relationship between simple geometric entities,
+which can thus be linked together to represent complex shapes.
+
+Abstract Topology is provided by six packages.
+The first three packages describe the topological data structure used in Open CASCADE Technology:
+
+ * <i> TopAbs</i> package provides general resources for topology-driven applications. It contains enumerations that are used to describe basic topological notions: topological shape, orientation and state. It also provides methods to manage these enumerations.
+ * <i> TopLoc </i>package provides resources to handle 3D local coordinate systems: <i> Datum3D</i>and <i> Location</i>. <i> Datum3D</i> describes an elementary coordinate system, while <i> Location</i> comprises a series of elementary coordinate systems.
+ * <i> TopoDS</i> package describes classes to model and build data structures that are purely topological.
+
+Three additional packages provide tools to access and manipulate this abstract topology:
+
+ * <i> TopTools</i> package provides basic tools to use on topological data structures.
+ * <i> TopExp</i> package provides classes to explore and manipulate the topological data structures described in the TopoDS package.
+ * <i> BRepTools </i> package provides classes to explore, manipulate, read and write BRep data structures. These more complex data structures combine topological descriptions with additional geometric information, and include rules for evaluating equivalence of different possible representations of the same object, for example, a point.
+
+@subsection OCCT_TOVW_SECTION_3_5 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.
+
+The local properties which may be queried are:
+
+ * for a point of parameter u on a curve which supports an edge :
+ * the point,
+ * the derivative vectors, up to the third degree,
+ * the tangent vector,
+ * the normal,
+ * the curvature, and the center of curvature;
+ * for a point of parameter (u, v) on a surface which supports a face :
+ * the point,
+ * the derivative vectors, up to the second degree,
+ * the tangent vectors to the u and v isoparametric curves,
+ * the normal vector,
+ * the minimum or maximum curvature, and the corresponding directions of curvature;
+ * the degree of continuity of a curve which supports an edge, built by the concatenation of two other edges, at their junction point.
+
+Analyzed edges and faces are described as <i> BRepAdaptor</i> curves and surfaces,
+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
+------------------------------------
+
+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:
+
+ * <i> Geom2dLProp</i> package, which provides local properties on 2D curves
+ * <i> GeomLProp </i> package, which provides local properties on 3D curves and surfaces
+ * <i> LProp </i> package, which provides an enumeration used to characterize a particular point on a 2D curve.
+
+Curves are either <i> Geom_Curve </i> curves (in 3D space) or <i> Geom2d_Curve </i> curves (in the plane).
+Surfaces are <i> Geom_Surface </i> surfaces. The point on which local properties are calculated
+is defined by its u parameter value on a curve, and its (u,v) parameter values on a surface.
+
+It is possible to query the same local properties for points as mentioned above, and additionally for 2D curves:
+
+ * the points corresponding to a minimum or a maximum of curvature;
+ * the inflection points.
+
+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.
+
+The global properties computed for a system are :
+
+ * mass,
+ * mass center,
+ * matrix of inertia,
+ * moment about an axis,
+ * radius of gyration about an axis,
+ * principal properties of inertia such as principal axis, principal moments, and principal radius of gyration.
+
+Geometric systems are generally defined as shapes. Depending on the way they are analyzed, these shapes will give properties of:
+
+ * lines induced from the edges of the shape,
+ * surfaces induced from the faces of the shape, or
+ * volumes induced from the solid bounded by the shape.
+
+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.
+
+@subsection OCCT_TOVW_SECTION_3_6 Examples
+
+How to compute the curve length
+----------------------
+
+To compute curve length, use the method <i>AbscissaPoint::Length</i> from <i> GCPnts</i>.
+
+This function is used only for initializing a framework to compute the length of a curve (or a series of curves).
+
+The adapted curves are:
+
+ * Adaptor_Curve2d for 2D curves
+ * Adaptor_Curve for 3D curves.
+
+The adapted curve is created in the following way:
+
+In 2D:
+
+~~~~~~~~~~~
+ Handle(Geom2d_Curve) mycurve = ... ;
+ Geom2dAdaptor_Curve C (mycurve) ;
+~~~~~~~~~~~
+
+In 3D:
+
+~~~~~~~~~
+ Handle(Geom_Curve) mycurve = ... ;
+ GeomAdaptor_Curve C (mycurve) ;
+~~~~~~~~~
+
+
+The length of the curve is then computed using this curve object:
+
+~~~~~~~~
+ GCPnts_AbscissaPoint myAlgo () ;
+ Standard_Real L = myAlgo.Length( C ) ;
+~~~~~~~~
+
+How to check the surface concavity
+--------------------------------
+
+To check the concavity of a surface, proceed as follows:
+
+ 1. Sample the surface and compute at each point the Gaussian curvature.
+ 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
+--------------------------------------------
+
+To approximate a curve with respect to tangencies, follow these steps:
+
+ 1. Create an object of type <i> AppDef_MultiPointConstraints</i> from the set of points to approximate and use the method <i> SetTang </i>to set the tangency vectors.
+ 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
+--------------------------------------
+
+To extract the underlying geometry from a Shape, use the following methods:
+
+ * <i> BRep_Tool::Surface</i> to get the geometric surface from a face.
+ * <i> BRep_Tool::Curve</i> to get the 3d geometric curve from an edge.
+ * <i> BRep_Tool::CurveOnSurface</i> to get the 2d geometric curve of an edge, defined in the parametric space of a face.
+ * <i> BRep_Tool::Pnt </i> to get the 3D point from a vertex.
+
+Some of these methods have a location as argument.
+
+For example, when you use <i> S1 = BRep_Tool::Surface(F,L), </i> you then get the surface stored in <i> TShape</i>.
+
+To use this surface in the same position as the face, you have to apply
+a transformation to it corresponding to the location of the face as follows:
+
+~~~~~~~~~~~~
+ gp_Trsf T(L) ;
+ S2 = S1->Moved(T) ;
+~~~~~~~~~~~~
+
+The same method used without location as argument is <i>S3 = BRep_Tool : : Surface(F)</i>
+returns a Surface in position, according to the location. S3 and S2 are geometrically equivalent surfaces.
+
+Warning: with the first method, you get a pointer on the surface stored in the shape.
+Do not modify the surface because you will modify the shape and may produce an inconsistent model.
+With the second method, you get a copy of the surface on which the location has been applied.
+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
+-----------------------------------
+
+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
+---------------------
+
+To explore the edges of a wire in a contiguous order, use <i> BrepTools_WireExplorer</i> class.
+
+~~~~
+ TopoDS_Wire myWire =&ldots;.
+ BRepTools_WireExplorer Ex;
+ for (Ex.Init(myWire); Ex.More(); Ex.Next()) {
+ TopoDS_Edge currentedge = Ex.Current();
+ // Process current edge
+ }
+~~~~
+
+How to merge bspline curves
+--------------------------
+
+To merge joined bspline curves use the following methods:
+
+~~~~
+ void GeomConvert::ConcatG1
+ TColGeom_Array1OfBSplineCurve& ArrayOfCurves,
+ const TColStd_Array1OfReal& ArrayOfToler,
+ Handle(TColGeom_HArray1OfBSplineCurve) & ArrayOfConcatenated,
+ const Standard_Boolean ClosedG1Flag,
+ const Standard_Real ClosedTolerance)
+~~~~
+
+This method concatenates according to G1 (tangency continuity along the curve) the
+<i>ArrayOfCurves</i> as far as possible. The following arguments are used:
+
+ * <i> ArrayOfCurves</i> must have dimension bounds [0, N-1], N * number of curves to be merged.
+ * <i> ArrayOfToler</i> contains the biggest tolerance of the two points shared by two consecutive curves. Its dimension is: [0, N-2].
+ * <i> ArrayOfConcatenated</i> contains results of operation: one or more, when impossible to merge all curves from <i> ArrayOfCurves </i> into one, new bspline curves are created.
+ * <i> ClosedG1Flag </i> indicates if the <i> ArrayOfCurves </i> is closed or not.
+ * If <i> ClosedG1Flag = Standard_True, ClosedTolerance </i> contains the biggest tolerance of the two points which are at the closure, otherwise its value is 0.0.
+
+~~~~
+ void GeomConvert::ConcatC1
+ TColGeom_Array1OfBSplineCurve& ArrayOfCurves,
+ const TColStd_Array1OfReal& ArrayOfToler,
+ Handle(TColStd_HArray1OfInteger)& ArrayOfIndices,
+ Handle(TColGeom_HArray1OfBSplineCurve)& ArrayOfConcatenated,
+ const Standard_Boolean ClosedG1Flag,
+ const Standard_Real ClosedTolerance,
+ const Standard_Real AngularTolerance)
+~~~~
+
+This method concatenates according to C1 (first derivative continuity along the curve) the <i>
+ArrayOfCurves</i> as far possible. The following arguments are used (additionally to the mentioned above):
+
+* <i> ArrayOfIndices</i> contains indices that define curves from <i> ArrayOfCurves</i> which are beginning curves for each group of curves merged into a new curve.
+* <i> AngularTolerance</i> is used to check the continuity of tangencies.
+
+~~~~
+ void GeomConvert::ConcatC1
+ TColGeom_Array1OfBSplineCurve& ArrayOfCurves,
+ const TColStd_Array1OfReal& ArrayOfToler,
+ Handle(TColStd_HArray1OfInteger)& ArrayOfIndices,
+ Handle(TColGeom_HArray1OfBSplineCurve)& ArrayOfConcatenated,
+ const Standard_Boolean ClosedG1Flag,
+ const Standard_Real ClosedTolerance)
+~~~~
+This method is the same as the previous one, except for that <i> AngularTolerance = Precision::Angular() </i>
+
+It is also possible to use class <i> GeomConvert_CompCurveToBSplineCurve</i>.
+This class provides methods to concatenate several restricted curves to a bspline curve.
+Non-bspline curves are converted to bspline before concatenation.
+
+Constructor:
+~~~~~~~~~~
+ GeomConvert_CompCurveToBSplineCurve::
+ GeomConvert_CompCurveToBSplineCurve(const Handle(Geom_BoundedCurve)& BasisCurve, const Convert_ParameterisationType Parameterization)
+ BasisCurve * beginning curve;
+~~~~~~~~~~
+
+Parameterization defines the ways of conversion in bspline (by default <i> Convert_TgtThetaOver2</i>).
+
+The method to add a new curve is:
+~~~~
+ Standard_Boolean GeomConvert_CompCurveToBSplineCurve::
+ Add(const Handle(Geom_BoundedCurve)& NewCurve,
+ const Standard_Real Tolerance,
+ const Standard_Boolean After,
+ const Standard_Boolean WithRatio,
+ const Standard_Integer MinM)
+~~~~
+
+It returns False if the curve is not C0 with the <i> BSplineCurve</i>.
+
+Tolerance is used to check the continuity and decrease the Multiplicity
+at the common Knot until <i> MinM </i>. If <i> MinM = 0 </i>, the common Knot can be removed.
+
+The parameter after defines the place for a new curve when it is possible to put
+the new curve before or after the <i> BasisCurve</i> (in fact, it is case when concatenated curve can be closed).
+It does not change the shape of the curve, but defines its first and last points.
+
+If <i> WithRatio = Standard_True </i> the algorithm tries to reach C1 continuity.
+
+The method to get a result is <i> Handle(Geom_BSplineCurve) GeomConvert_CompCurveToBSplineCurve::BSplineCurve() const </i>
+
+@section OCCT_TOVW_SECTION_4 Modeling Algorithms
+
+Modeling Algorithms module groups a wide range of
+topological algorithms used in modeling and geometric algorithms, called by them.
+
+These services are organized into the following libraries:
+
+ * Geometric Tools
+ * Topological Tools
+ * Construction of Primitives
+ * Boolean Operations
+ * Fillets and Chamfers
+ * Offsets and Drafts
+ * Features
+ * Hidden Line Removal
+ * Shape Healing
+
+
+
+The technical overview provides only a basic description of the libraries.
+Please, refer for more details to Modeling Algorithms User's guide
+
+See also: our web site at E-learning and Training.
+
+@subsection OCCT_TOVW_SECTION_4_1 Geometric Tools
+
+This library provides algorithms to:
+
+ * Calculate the intersection of two 2D curves, surfaces, or a 3D curve and a surface;
+ * Project points onto 2D and 3D curves, points onto surfaces, and 3D curves onto surfaces;
+ * Construct lines and circles from constraints;
+ * Construct curves and surfaces from constraints;
+ * Construct curves and surfaces by interpolation
+
+OPEN CASCADE company also provides a product known as Surfaces from Scattered Points
+(SSP), which allows constructing surfaces from scattered points. This algorithm accepts
+or constructs an initial B-Spline surface and looks for its deformation (finite elements
+method) which would satisfy the constraints. Using optimized computation methods,
+this algorithm is able to construct a surface from more than 500 000 points.
+
+SSP product is not supplied with Open CASCADE Technology, but can be purchased separately.
+
+@subsubsection OCCT_TOVW_SECTION_4_1_1 Intersections
+
+The Intersections component is used to compute intersections between 2D or 3D geometrical
+objects:
+
+ * the intersections between two 2D curves
+ * the self-intersections of a 2D curve
+ * the intersection between a 3D curve and a surface
+ * the intersection between two surfaces.
+
+@subsubsection OCCT_TOVW_SECTION_4_1_2 Projections
+
+The Projections component provides functionality for 2D and 3D geometry objects for computing the following:
+
+ * the projections of a 2D point onto a 2D curve
+ * 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.
+
+@subsubsection OCCT_TOVW_SECTION_4_1_3 Lines and Circles from Constraints
+
+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 passage of a straight line or circle through a point,
+ * the centering of a circle on 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.
+
+The implemented algorithms are more complex than those provided
+by the Direct Constructions component for building 2D circles or lines.
+
+The expression of a tangency problem generally leads to several results, according
+to the relative positions of the solution and the circles or straight lines in relation
+to which the tangency constraints are expressed. For example, consider the following
+case of a circle of a given radius (a small one) which is tangential to two secant
+circles C1 and C2:
+
+
+
+This diagram clearly shows that there are 8 possible solutions.
+
+In order to limit the number of solutions, we can try to express the relative position
+of the required solution in relation to the circles to which it is tangential. For
+example, if we specify that the solution is inside the circle C1 and outside the
+circle C2, only two solutions referenced 3 and 4 on the diagram respond to the problem
+posed.
+
+This technique of qualification of a solution, in relation to the curves to which
+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.
+
+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
+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.
+
+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.
+
+The provided algorithms compute all solutions, which correspond to the stated geometric
+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
+ 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.
+
+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> GccEnt</i> and <i> Geom2dGcc</i> packages also provide simple functions for building qualified curves in a very efficient way.
+
+The <i> GccAna </i>package also provides algorithms for constructing bisecting loci between
+circles, lines or points. Bisecting loci between two geometric objects are such that
+each of their points is at the same distance from the two geometric objects. They
+are typically curves, such as circles, lines or conics for <i> GccAna</i> algorithms.
+Each elementary solution is given as an elementary bisecting locus object (line, circle,
+ellipse, hyperbola, parabola), described by the <i>GccInt</i> package.
+
+Note: Curves used by <i> GccAna </i> algorithms to define the geometric problem to be solved,
+are 2D lines or circles from the <i> gp</i> package: they are not explicitly parameterized.
+However, these lines or circles retain an implicit parameterization, corresponding
+to that which they induce on equivalent Geom2d objects. This induced parameterization
+is the one used when returning parameter values on such curves, for instance with
+the functions <i> Tangency1, Tangency2, Tangency3, Intersection2</i> and <i> CenterOn3</i> provided
+by construction algorithms from the <i> GccAna </i> or <i> Geom2dGcc</i> packages.
+
+@subsubsection OCCT_TOVW_SECTION_4_1_4 Curves and Surfaces from Constraints
+
+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
+ * construction of ruled surfaces
+ * construction of pipe surfaces
+ * filling of surfaces
+ * construction of plate surfaces
+ * extension of a 3D curve or surface beyond its original bounds.
+
+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
+between two sets of nails and in this way, take the form of a curve based on the
+two points, the directions of the forces applied at those points, and the properties
+of the wooden lathe itself.
+
+Maintaining these constraints requires both longitudinal and transversal forces to
+be applied to the beam in order to compensate for its internal elasticity. The longitudinal
+forces can be a push or a pull and the beam may or may not be allowed to slide over
+these fixed points.
+
+The class <i> Batten</i> produces curves defined on the basis of one or more constraints
+on each of the two reference points. These include point and angle of tangency settings.
+The class <i> MinimalVariation</i> produces curves with minimal variation in curvature.
+The exact degree of variation is provided by curvature settings.
+
+Ruled Surfaces
+----------------
+A ruled surface is built by ruling a line along the length of two curves.
+
+Pipe Surfaces
+--------------
+
+A pipe is built by sweeping a curve (the section) along another curve (the path).
+
+The following types of construction are available:
+ * pipes with a circular section of constant radius,
+ * pipes with a constant section,
+ * pipes with a section evolving between two given curves.
+
+
+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.
+
+A case in point is the intersection of two fillets at a corner. If the radius of
+the fillet on one edge is different from that of the fillet on another, it becomes
+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.
+
+
+
+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
+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
+------------------
+
+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,
+a technical or an aesthetic order.
+
+
+Essentially, a plate surface is constructed by deforming a surface so that it conforms
+to a given number of curve or point constraints. In the figure below, you can see
+four segments of the outline of the plane, and a point which have been used as the
+curve constraints and the point constraint respectively. The resulting surface can
+be converted into a BSpline surface by using the function <i> MakeApprox </i>.
+
+
+The surface is built using a variational spline algorithm. It uses the principle
+of deformation of a thin plate by localised mechanical forces. If not already given
+in the input, an initial surface is calculated. This corresponds to the plate prior
+to deformation. Then, the algorithm is called to calculate the final surface. It
+looks for a solution satisfying constraints and minimizing energy input.
+
+
+
+
+
+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
+
+The Interpolation Laws component provides definitions of functions: <i> y=f(x) </i>.
+
+In particular, it provides definitions of:
+
+ * a linear function,
+ * an <i> S </i> function, and
+ * an interpolation function for a range of values.
+
+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.
+
+@subsection OCCT_TOVW_SECTION_4_2 Topological Tools
+
+This library provides algorithms to:
+
+ * Tessellate shapes
+ * Validate shapes
+ * Determine the local properties of shapes
+ * Determine the global properties of shapes
+ * Perform geometric transformations
+ * Find planes in which edges are located
+ * Convert shapes to NURBS geometry.
+
+It also furnishes a complete brep data structure for topological data structures defined
+in the Topology library of the Modeling Data module.
+This linAllows you to create standard topological objects such as:
+
+ * Vertices
+ * Edges
+ * Faces
+ * Wires
+ * Polygonal wires
+ * Shells
+ * Solids.
+
+The API provides classes to build objects:
+
+ * The constructors of classes provide different construction methods;
+ * The class retains different tools used to build objects as fields;
+ * The class provides a casting method to obtain the result automatically with a function-like call.
+
+For example, to build a vertex V on a point P, you can use:
+
+~~~
+ V = BRepBuilderAPI_MakeVertex(P);
+~~~
+or
+
+~~~
+ BRepBuilderAPI_MakeVertex MV(P);
+ V = MV.Vertex();
+~~~
+
+For error handling, the <i> BRepBuilderAPI</i> commands raise only the
+<i> 0StdFail_NotDone</i> exception. When <i> IsDone</i> is false for a command,
+the error description can be requested from the command.
+
+@subsection OCCT_TOVW_SECTION_4_3 Construction of Primitives
+
+This library contained in <i> BRepPrimAPI</i> package provides an API (Application Programming Interface) for:
+
+ * Construction of primitives such as:
+ * Boxes;
+ * Cones;
+ * Cylinders;
+ * Prisms.
+ * Construction by sweeping along a profile:
+ * Linear;
+ * Rotational (through an angle of rotation).
+
+Sweeps are objects obtained by sweeping a profile along a path.
+The profile can be any topology and the path is usually a curve or a wire.
+The profile generates objects according to the following rules:
+
+ * Vertices generate Edges
+ * Edges generate Faces.
+ * Wires generate Shells.
+ * Faces generate Solids.
+ * Shells generate Composite Solids.
+
+It is not allowed to sweep Solids and Composite Solids.
+
+Swept constructions along complex profiles such as
+BSpline curves are also available in the <i> BRepOffsetAPI </i> package.
+
+This API provides simple, high level calls for the most common operations.
+
+@subsection OCCT_TOVW_SECTION_4_4 Boolean Operations
+
+Boolean operations to create new shapes from old ones by using:
+
+ * Common
+ * Cut
+ * Fuse
+ * Section
+
+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
+------------------------------------------
+
+ * 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 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.
+ * 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.
+
+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.
+
+@subsection OCCT_TOVW_SECTION_4_5 Features
+
+This library contained in BRepFeat package is necessary for the creation
+and manipulation of both form and mechanical features in a Boundary Representation framework.
+
+The form features are depressions or protrusions including the following types:
+
+ * Cylinder;
+ * Draft Prism;
+ * Prism;
+ * Revolved feature;
+ * Pipe.
+
+Depending on whether you wish to make a depression or a protrusion,
+you can choose either to remove matter (Boolean cut: Fuse equal to 0) or to add it (Boolean fusion: Fuse equal to 1).
+
+The semantics of form feature creation is based on the construction of shapes:
+
+ * for a certain length in a certain direction;
+ * up to the limiting face;
+ * from the limiting face at a height;
+ * above and/or below a plane.
+
+The shape defining the construction of a feature can be
+either a supporting edge or a concerned area of a face.
+
+In case of supporting edge, this contour can be attached to a face
+of the basis shape by binding. When the contour is bound to this face,
+the information that the contour will slide on the face becomes available
+to the relevant class methods. In case of the concerned area of a face, you could,
+for example, cut it out and move it at a different height,
+which will define the limiting face of a protrusion or depression.
+
+Topological definition with local operations of this sort makes calculations simpler
+and faster than a global operation. The latter would entail a second phase
+of removing unwanted matter to get the same result.
+
+Mechanical features include ribs, protrusions and grooves (or slots),
+depressions along planar (linear) surfaces or revolution surfaces.
+
+The semantics of mechanical features is based on giving thickness to a contour.
+This thickness can either be
+
+ * unilateral
+ * on one side of the contour
+ * or bilateral
+ * on both sides.
+
+As in the semantics of form features, the thickness is defined
+by construction of shapes in specific contexts.
+
+However, in case of mechanical features, development contexts differ.
+Here they include extrusion:
+
+ * to a limiting face of the basis shape;
+ * to or from a limiting plane;
+ * to a height.
+
+@subsection OCCT_TOVW_SECTION_4_6 Hidden Line Removal
+
+This library provides two algorithms: <i> HLRBRep_Algo</i> and <i> HLRBRep_PolyAlgo</i> to define the lines of a shape hidden in a given projection. These lines can be shown or hidden to have the precision required in industrial design. To do this, the Hidden Line Removal component provides
+
+These algorithms remove or indicate lines hidden by surfaces.
+For a given projection, they calculate a set of lines characteristic of the object being represented. They are also used in conjunction with extraction utilities, which reconstruct a new, simplified shape from a selection of calculation results.
+This new shape is made up of edges, which represent the lines of the visualized shape in a plane. This plane is the projection plane.
+
+The algorithm <i> HLRBRep_Algo</i> allows working with the shape itself, while <i> HLRBRep_PolyAlgo </i>works with its polyhedral simplification. When you use <i> HLRBRep_Algo</i>, you obtain an exact result, whereas, when you use <i> HLRBRep_PolyAlgo</i>, you reduce computation time but obtain polygonal segments.
+
+@subsection OCCT_TOVW_SECTION_4_7 Shape Healing
+
+Shape Healing library provides algorithms to modify the geometry and topology of OCCT shapes.
+Shape Healing adapts shapes to make them maximally appropriate for use by OCCT, for example:
+
+ * analyze shape characteristics and, in particular, identify the shapes that do not comply with OCCT validity rules;
+ * fix incorrect or problem shapes;
+ * upgrade and change shape characteristics if needed, for example a C0 supporting surface can become C1 continuous.
+
+It has several sub-domains, each with its own scope of functionality:
+
+ * analysis - exploring shape properties, computing shape features, detecting violation of OCCT requirements (the shape itself is not modified);
+ * fixing - fixing shape to meet the OCCT requirements (the shape may change its original form: modifying, removing, constructing sub-shapes, etc.);
+ * upgrade - shape improvement for better usability in OCCT or other algorithms (the shape is replaced with a new one, but geometrically they are the same);
+ * customization - modifying shape representation to fit specific needs (the shape is not modified, only the form of its representation is modified);
+ * processing - mechanism of shape modification via a user-editable resource file.
+
+The technical overview provides only a basic description of the libraries. Please, refer for more details to Shape Healing User's guide
+
+See also: our web site at E-learning and Training.
+
+
+@subsection OCCT_TOVW_SECTION_4_8 Miscellaneous modelling algorithms.
+
+Fillets and Chamfers
+---------------------
+
+This library provides algorithms to make fillets and chamfers on shape edges.
+The following cases are addressed:
+
+ * Corners and apexes with different radii;
+ * Corners and apexes with different concavity.
+
+If there is a concavity, both surfaces that need to be extended and those, which do not, are processed.
+
+Offsets, Drafts, Sewing and Sweeps
+----------------------------------
+
+These classes provide the following services:
+
+ * Creation of offset shapes and their variants such as:
+ * Hollowing;
+ * Shelling;
+ * Lofting;
+ * Creation of tapered shapes using draft angles
+ * Sewing
+ * Creation of sweeps
+
+
+@subsection OCCT_TOVW_SECTION_4_9 Examples
+
+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.
+If it is, you can use <i> BRepTopAdaptor_FClass2d </i>class. For example:
+
+~~~~~
+ BRepTopAdaptor_FClass2d::Load (to load the solid )
+ BRepTopAdaptor_FClass2d::Perform (to compute the state of the point )
+ BRepTopAdaptor_FClass2d::State (to get the TopAbs_State).
+~~~~~
+
+
+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.
+
+If it is, you can use the <i> BRepClass3d_SolidClassifier </i> class, for example:
+
+~~~~~
+ BRepClass3d_SolidClassifier::Load (to load the solid)
+ BRepClass3d_SolidClassifier::Perform (to compute the state of the point)
+ BRepClass3d_SolidClassifier::State (to get a TopAbs_State object)
+ BRepClass3d_SolidClassifier inherits BRepclass3d_SClassifier
+~~~~~
+
+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.
+
+~~~~~
+ BRepOffsetAPI_Sewing Sew;
+ Sew.Add(Face1);
+ Sew.Add(Face2);
+ ...
+ Sew.Add(Facen);
+ Sew.Perform();
+ TopoDS_Shape result= Sew.SewedShape();
+~~~~~
+
+@note The sewing algorithm uses a tolerance to assemble the faces by sewing them along common edges. You must therefore check the gap between faces before sewing or adjust the value of the tolerance according to the real gap of the geometry.
+
+If all faces have been sewed correctly, the result is a shell. Otherwise, it is a compound. After a successful sewing operation all faces have a coherent orientation.
+
+For more information, refer to the entry for this class in reference documentation.
+
+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.
+
+~~~~~
+ BRepClass3d_SolidClassifier clas3d(aShell);
+ clas3d.PerformInfinitePoint(Precision::Confusion());
+ if (clas3d.State() == TopAbs_IN)
+ newShell.Reverse();
+ BRepBuilderAPI_MakeSolid aSolid(aShell);
+~~~~~
+
+@section OCCT_TOVW_SECTION_5 Visualization
+
+Visualization in Open CASCADE Technology is based on the separation of modeling data you want to display and select, and on the graphical presentation of its structure.
+
+For visualizing data structures, OCCT provides ready-to-use algorithms, which create graphic presentations from geometric models. These data structures may be used with the viewers supplied, and can be customized to take the specificity of your application into account.
+
+Displaying is managed through presentation services, and selection in its turn is managed through selection services. With these services, data structures and algorithms are provided to display objects of an application, and to support graphical selection of these objects.
+
+Application Interactive Services (AIS) are provided to manage displaying, detection and selection of graphical presentations. These services associate data structures and interactive objects.
+
+Please, refer for more details to Visualization User's guide
+
+See also: our web site at E-learning and Training.
+
+
+
+@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.
+A group is the smallest editable element of a structure.
+
+A structure can be displayed, erased, highlighted and transformed.
+Structures can be connected to form a hierarchy of structures, composed by transformations.
+The viewer can perform global manipulation of structures.
+
+<i> Visual3d </i> package contains the group of classes required to implement commands for 3D viewer. The viewer manages views and light sources.
+
+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
+
+This library provides services for:
+
+ * Selection of 3D data structures
+ * Presentation of 3D data structures
+
+Access to 3D presentation and selection is provided through AIS (Application Interactive Services).
+This package is a high-level interface that offers access to the lower-level presentation and selection services.
+AIS expand this underlying functionality with standard 3D selection attributes, presentation management, and standard 3D presentation attributes, and manages it in the definition of GUI viewers. To implement these services, AIS package includes the following:
+
+ * Interactive context
+ * Interactive objects
+ * A graphic attributes manager
+ * Selection filters
+
+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.
+
+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
+-------------------
+
+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, or AIS Drawer, stores graphic attributes for specific interactive objects and for interactive objects controlled by interactive context.
+
+Initially, all drawer attributes are filled out with the predefined values which will define the default 3D object appearance.
+
+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
+-----------------
+
+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.
+
+
+@subsection OCCT_TOVW_SECTION_5_3 Application Interactive Services (AIS)
+
+Application Interactive Services provide the means to create links between an application GUI viewer and the packages which are used to manage selection and presentation. The tools AIS defined for this include different sorts of entities: the selectable viewable objects themselves and the context and attribute managers to define their selection and display.
+
+To orient the user as he works in a modeling environment, views and selections must be comprehensible.
+There must be several different sorts of selectable and viewable object defined.
+These must also be interactive, that is, connecting graphic representation and the underlying reference geometry. These entities are called Interactive Objects, and are divided into four types:
+ * the Datum
+ * the Relation
+ * the Object
+ * None.
+
+The Datum groups together the construction elements such as lines, circles, points, trihedrons, plane trihedrons, planes and axes.
+The Relation is made up of constraints on one or more interactive shapes and the corresponding reference geometry. For example, you might want to constrain two edges in a parallel relation. This constraint is considered as an object in its own right, and is shown as a sensitive primitive. This takes the graphic form of a perpendicular arrow marked with the || symbol and lying between the two edges.
+
+The Object type includes topological shapes, and connections between shapes.
+
+None, in order not to eliminate the object, tells the application to look further until it finds an object definition in its generation which is accepted.
+
+Inside these categories, you have the possibility of an additional characterization by means of a signature. The signature provides an index to the further characterization. By default, the Interactive Object has a None type and a signature of 0 (equivalent to None.)
+If you want to give a particular type and signature to your interactive object, you must redefine the two virtual methods: <i> Type</i> and <i> Signature</i>.
+
+In the C++ inheritance structure of the package, each class representing a specific Interactive Object inherits <i> AIS_InteractiveObject</i>. Among these inheriting classes, <i> AIS_Relation</i> functions as the abstract mother class for inheriting classes defining display of specific relational constraints and types of dimension. Some of these include:
+
+ * display of constraints based on relations of symmetry, tangency, parallelism and concentricity
+ * display of dimensions for angles, offsets, diameters, radii and chamfers.
+
+No viewer can show everything at once with any coherence or clarity.
+Views must be managed carefully both sequentially and at any given instant.
+Another function of the view is that of a context to carry out design in.
+The design changes are applied to the objects in the view and then extended
+to the underlying reference geometry by a solver.
+To make sense of this complicated visual data, several display and selection tools are required.
+To facilitate management, each object and each construction element has a selection priority.
+There are also means to modify the default priority.
+
+To define an environment of dynamic detection, you can use standard filter classes or create your own.
+A filter questions the owner of the sensitive primitive in local context to determine
+if it has the desired qualities. If it answers positively, it is kept. If not, it is rejected.
+
+The standard filters supplied in AIS include:
+
+ * <i> AIS_AttributeFilter</i>
+ * <i> AIS_SignatureFilter</i>
+ * <i> AIS_TypeFilter</i>.
+
+Only the type filter can be used in the default operating mode, the neutral point.
+The others can only be used in open local contexts.
+
+Neutral point and local context constitute the two operating modes of the
+central entity which pilots visualizations and selections, the Interactive Context.
+It is linked to a main viewer and if you like, a trash bin viewer as well.
+
+The neutral point, which is the default mode, allows you to easily visualize and select interactive objects which have been loaded into the context. Opening local contexts allows you to prepare and use a temporary selection environment without disturbing the neutral point.
+A set of functions allows you to choose the interactive objects which you want to act on, the selection modes which you want to activate, and the temporary visualizations which you will execute. When the operation is finished, you close the current local context and return to the state in which you were before opening it (neutral point or previous local context).
+
+An interactive object can have a certain number of graphic attributes, which are specific to it, such as visualization mode, color, and material. By the same token, the interactive context has a set of graphic attributes, the Drawer which is valid by default for the objects it controls.
+When an interactive object is visualized, the required graphic attributes are first taken from the object's own <i> Drawer</i> if one exists, or from the context drawer for the others.
+
+
+@subsection OCCT_TOVW_SECTION_5_4 Presentation
+
+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.
+
+Note that each new Interactive Object must have all its display modes defined.
+
+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
+--------------------------
+ <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
+---------------
+
+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
+-------------------
+
+The <i> StdSelect</i> package provides the following services:
+
+ * definition of selection modes for topological shapes
+ * definition of several filter standard <i> Selection2d.ap </i> classes
+ * 3D viewer selectors.
+
+Note that each new Interactive Object must have all its selection modes defined.
+The <i>Select3D</i> package provides the following services:
+
+ * definition of standard 3D sensitive primitives such as points, curves and faces;
+ * recovery of the bounding boxes in the 2D graphic selection space, if required;
+ * a 3D-2D projector.
+
+Selection Management
+--------------------
+
+The <i> SelectMgr</i> package provides low level services and the classes
+<i> SelectMgr_SelectionManager</i> and <i> SelectMgr_ViewerSelector </i>
+in particular are only to be used when you do not want to use the services provided by <i> AIS</i>.
+
+<i> SelectMgr </i> manages the process of dynamic selection through the following services:
+
+ * activating and deactivating selection modes for Interactive Objects
+ * adding and removing viewer selectors
+ * definitions of abstract filter classes
+
+The principle of graphic selection consists in representing the objects which you want
+to select by a bounding box in the selection view.
+The object is selected when you use the mouse to designate the zone produced by the object.
+
+To realize this, the application creates a selection structure
+which is independent of the point of view. This structure is made up
+of sensitive primitives which have one owner object associated to each of them.
+The role of the sensitive primitive is to reply to the requests of the selection algorithm
+whereas the owner's purpose is to make the link between
+the sensitive primitive and the object to be selected.
+Each selection structure corresponds to a selection mode which defines the elements that can be selected.
+
+For example, to select a complete geometric model,
+the application can create a sensitive primitive for each face
+of the interactive object representing the geometric model.
+In this case, all the primitives share the same owner.
+On the other hand, to select an edge in a model,
+the application must create one sensitive primitive per edge.
+
+~~~~
+
+void InteractiveBox::ComputeSelection
+ (const Handle(SelectMgr_Selection)& Sel,
+ const Standard_Integer Mode){
+
+switch(Mode){
+case 0:
+// locating the whole box by making its faces sensitive ...
+ {
+ Handle(SelectMgr_EntityOwner) Ownr = new
+ SelectMgr_EntityOwner(this,5);
+ for(Standard_Integer I=1;I<=Nbfaces;I++){
+ Sel->Add(new Select3D_SensitiveFace
+ (Ownr,[array of the vertices] face I);
+ break;
+ }
+
+case 1: // locates the edges
+ {
+
+ for(Standard_Integer i=1;i<=12;i++){
+ // 1 owner per edge...
+ Handle(mypk_EdgeOwner) Ownr =
+ new mypk_EdgeOwner(this,i,6);
+ // 6->priority
+ Sel->Add(new
+ Select3D_SensitiveSegment
+ (Ownr,firstpt(i),lastpt(i));
+ }
+ }
+}
+
+~~~~
+
+The algorithms for creating selection structures store the sensitive primitives in a
+<i> SelectMgr_Selection </i> object. To do this, a set of ready-made sensitive primitives is supplied
+in the <i> Select2D </i>and <i> Select3D </i>packages. New sensitive primitives can be defined through inheritance
+from <i> SensitiveEntity</i>. For the application to make its own objects selectable,
+ it must define owner classes inheriting <i> SelectMgr_EntityOwner</i>.
+
+For any object inheriting from <i> AIS_InteractiveObject</i>, you redefine
+its <i> ComputeSelection</i> functions. In the example below there are different modes
+of selection on the topological shape contained within the interactive object,
+selection of the shape itself, the vertices, the edges, the wires, the faces.
+
+~~~~
+ void MyPack_MyClass::ComputeSelection(
+ const Handle(SelectMgr_Selection)& aSelection,
+ const Standard_Integer aMode)
+ {
+ switch(aMode){
+ case 0:
+ StdSelect_BRepSelectionTool::Load(
+ aSelection,this,myShape,TopAbs_SHAPE);
+ break;
+ }
+ case 1:
+ StdSelect_BRepSelectionTool::Load(
+ aSelection,this,myShape,TopAbs_VERTEX);
+ break;
+ }
+ case 2:
+ StdSelect_BRepSelectionTool::Load(
+ aSelection,this,myShape,TopAbs_EDGE);
+ break;
+ }
+ case 3:
+ StdSelect_BRepSelectionTool::Load(
+ aSelection,this,myShape,TopAbs_WIRE);
+ break;
+ }
+ case 4:
+ StdSelect_BRepSelectionTool::Load(
+ aSelection,this,myShape,TopAbs_FACE);
+ break;
+ }
+ }
+~~~~
+
+The <i> StdSelect_BRepSelectionTool </i> object provides a high level service
+which will make the shape <i> myShape</i> selectable when the <i> AIS_InteractiveContext</i> is asked to display your object.
+
+Note:
+
+The traditional way of highlighting selected entity owners
+adopted by Open CASCADE Technology assumes that each entity owner
+highlights itself on its own. This approach has two drawbacks:
+
+ * each entity owner has to maintain its own <i>Prs3d_Presentation object</i>, that results in large memory overhead for thousands of owners;
+ * drawing selected owners one by one is not efficient from the OpenGL usage viewpoint.
+
+That is why a different method has been introduced.
+On the basis of <i> SelectMgr_EntityOwner::IsAutoHilight() </i> return value
+<i> AIS_LocalContext </i> object either uses the traditional way of highlighting
+( <i> IsAutoHilight() </i> returned true) or groups such owners according to their
+Selectable Objects and finally calls <i> SelectMgr_SelectableObject::HilightSelected()</i> or
+<i> ClearSelected()</i>, passing a group of owners as an argument.
+
+Hence, an application can derive its own interactive object and redefine <i> HilightSelected()</i>,
+ <i> ClearSelected()</i> and <i> HilightOwnerWithColor()</i> virtual methods
+ to take advantage of such OpenGL technique as arrays of primitives.
+ In any case, these methods should at least have empty implementation.
+
+ The <i> AIS_LocalContext::UpdateSelected(const Handle(AIS_InteratciveObject)&, Standard_Boolean)
+ </i> method can be used for efficient redrawing a selection presentation for a given interactive object from an application code.
+
+Additionally, the <i> SelectMgr_SelectableObject::ClearSelections() </i>
+method now accepts an optional Boolean argument.
+This parameter defines whether all object selections should be flagged for further update or not.
+This improved method can be used to re-compute an object selection (without redisplaying the object completely)
+when some selection mode is activated not for the first time.
+
+
+@subsection OCCT_TOVW_SECTION_5_6 Attribute Management
+
+The Attribute Management tool-kit 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> Prs3d </i> package provides the following services:
+
+ * a presentation object (the context for all modifications to the display, its presentation will be displayed in every view of an active viewer)
+ * an attribute manager governing how objects such as color, width, and type of line are displayed; these are generic objects, whereas those in <i>StdPrs </i> are specific geometries and topologies.
+ * generic algorithms providing default settings for objects such as points, curves, surfaces and shapes
+ * a root object which provides the abstract framework for the DsgPrs definitions at work in display of dimensions, relations and trihedrons.
+
+
+@subsection OCCT_TOVW_SECTION_5_7 Mesh Visualization Services
+
+<i> MeshVS</i> (Mesh Visualization Service) component extends 3D visualization capabilities
+of Open CASCADE Technology. It provides flexible means of displaying meshes along with associated pre- and post-processor data.
+
+From a developer's point of view, it is easy to integrate the MeshVS component i
+nto any mesh-related application with the help of the following guidelines:
+
+Derive a data source class from the MeshVS_DataSource class.
+Re-implement its virtual methods, so as to give the <i> MeshVS</i> component access
+to the application data model. This is the most important part of the job,
+since visualization performance is affected by performance of data retrieval methods of your data source class.
+
+Create an instance of the <i> MeshVS_Mesh</i> class.
+
+Create an instance of your data source class and pass it to a <i> MeshVS_Mesh </i> object through the <i> SetDataSource()</i> method.
+
+Create one or several objects of <i> MeshVS_PrsBuilder</i>-derived classes
+(either standard, included in the <i> MeshVS</i> package, or your custom ones).
+Each <i> PrsBuilder</i> is responsible for drawing a <i> MeshVS_Mesh</i> presentation
+in certain display mode(s) specified as a <i> PrsBuilder</i> constructor's argument.
+Display mode is treated by <i> MeshVS</i> classes as a combination of bit flags
+(two least significant bits are used to encode standard display modes: wireframe, shading and shrink).
+Pass these objects to the <i> MeshVS_Mesh::AddBuilder()</i> method. <i> MeshVS_Mesh</i>
+takes advantage of improved selection highlighting mechanism: it highlights its selected entities itself,
+with the help of so called "highlighter" object. You can set one of <i> PrsBuilder</i>
+objects to act as a highlighter with the help of a corresponding argument of the <i> AddBuilder()</i> method.
+
+Visual attributes of the <i> MeshVS_Mesh </i> object (such as shading color, shrink coefficient and so on)
+are controlled through <i> MeshVS_Drawer</i> object. It maintains a map "Attribute ID --> attribute value"
+and can be easily extended with any number of custom attributes.
+
+In all other respects, <i> MeshVS_Mesh</i> is very similar to any other class derived
+from <i> AIS_InteractiveObject</i> and it should be used accordingly
+(refer to the description of <i> AIS package</i> in the documentation).
+
+@subsection OCCT_TOVW_SECTION_5_8 Images and Drivers
+
+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
+---------
+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.
+
+The <i> Cocoa</i> package provides interaction with Cocoa API on Mac OS X.
+
+@subsection OCCT_TOVW_SECTION_5_9 New Interactive Services (NIS)
+
+New Interactive Services package provides the API similar to the traditional AIS but with some important differences/improvements:
+
+ * Each type of <i> InteractiveObject</i> should have a corresponding Drawer class that defines the presentation of the Object type using direct OpenGl calls. This is a much faster way to display 3D objects, providing for more than 1 million separate selectable entities in one view.
+ * The abstract type <i> NIS_InteractiveObject</i> does not support any properties (color, material, other aspects). The relevant properties should be defined in the specializations of the Drawer class, and the API to set/modify should be implemented in the specializations of InteractiveObject class.
+ * Interactive selection is managed by <i> InteractiveObject</i> methods instead of special selector classes and data types. This is possible since in NIS the selection is based on 3D representation (by a ray or a box corresponding to the view direction) without intermediate 2D projection.
+ * Many <i> InteractiveContext</i> instances can be attached to a <i> V3d_View</i>, these instances being independent containers of interactive objects; removal (detaching) of <i> InteractiveContext</i> instance destroys the contained objects.
+ * All data types and algorithms are designed to provide the best performance for both OpenGl (server side) and application. On the other hand, the API is open to any feature supported by any version of OpenGl. This allows building custom presentations quickly and efficiently.
+ * Standard <i> NIS_View</i> subclasses <i> V3d_View</i> thus providing all its public API, such as scene definition (view orientation, lights, background, etc.) and the standard view transformations (pan/zoom/rotate,fitAll,...). The traditional AIS-based presentations (e.g., <i> AIS_Shape</i>) are also supported, they can be rendered together with NIS presentations in the same view window.
+
+The DRAW test plugin, <i> TKViewerTest</i>, has been modified
+to manage <i> AIS_InteractiveContext</i> and <i> NIS_InteractiveContext</i> together in one view window.
+
+@subsection OCCT_TOVW_SECTION_5_10 Voxels
+
+A voxel is a sub-volume box with constant scalar/vector value.
+The object in voxel representation is split into many small sub-volumes (voxels) and its properties are distributed through voxels.
+
+Voxels are used for analysis and visualization of 3D-dimensional distribution of data.
+Medicine (mainly, tomography), computational physics (hydrodynamics, aerodynamics, nuclear physics)
+and many other industries use voxels for 3D data visualization and analysis of physical processes.
+
+Open CASCADE Technology provides several basic data containers for voxels
+with fast access to the data and optimal allocation of data in memory.
+Also, a special visualization toolkit allows visualizing voxels
+as colored or black/white points and cubes, displaying only the voxels visible from the user's point of view.
+
+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
+------------------------------------------------
+The set of graphic attributes of an interactive object is defined in AIS_Drawer.
+Each interactive object can have its own visualization attributes.
+
+By default, the interactive object takes the graphic attributes of
+the interactive context in which it is visualized
+(visualization mode, deflection, values for the calculation of presentations,
+number of isoparametric lines, color, type of line, material, etc.)
+
+In the <i> AIS_InteractiveObject</i> abstract class, several standard attributes
+have been privileged. These include: color, thickness of line, material, and transparency.
+Consequently, a certain number virtual functions which allow us to act on these attributes have been proposed.
+Each new class of interactive object can use them as they are or
+can redefine these functions to bring about the changes it should produce in the behavior of the class.
+
+Other attributes can be changed by acting directly on the drawer of the object.
+An interactive object has a specific drawer as soon as you change an attribute on it.
+If you do not modify any graphic attribute on it, the default drawer of the interactive context is referenced and used.
+
+To get the <i> AIS_Drawer</i> of an object, call method <i> AIS_InteractiveObject::Attributes </i>.
+
+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
+----------------------------
+
+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)
+and the aspect ratio of the view. This is provided by method <i>V3d_View::Dump</i>. For example:
+
+~~~~
+CString filename ("myView3D.bmp");
+myView->Dump (filename, Aspect_FOSP_A4);
+~~~~
+
+<i> myView</i> is a <i> V3d_View</i>, where OCCT objects are displayed using, for example, AIS services.
+
+Please, note:
+
+ * The file name extension can be any among ".xwd", ".png", or ".bmp" formats both on UNIX or NT.
+ * Be careful about dump time requirements of the resulting file, especially for the A formats.
+ * The GIF format generates very small files, BMP and XWD generates much larger files (4 to 6 times the size of a GIF).
+ * 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
+---------------------------------------------
+
+You can add or remove an object from a selection in one of two ways. You can use:
+
+ * <i> AIS_InteractiveContext::AddOrRemoveCurrentObject</i> method at neutral points;
+ * <i> AddOrRemoveCurrent </i> method if a local context is opened.
+
+
+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>
+to successively highlight all the objects found under the selection.
+This allows you to choose and validate the required object.
+
+~~~~
+ If ( myAISContext->HasNextDetected()) {
+
+ // if up key is pressed
+ myAISContext ->HilightNextDetected(myView);
+
+ // if down key is pressed
+ myAISContext ->HilightPreviousDetected(myView);
+
+ }
+~~~~
+
+
+
+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.
+
+~~~~
+ Handle(V3d_View) aview
+ aView->Convert(Xp,Yp,X,Y,Z)
+~~~~
+
+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
+-----------------
+
+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.
+
+<i> CSF_WALKTHROUGH</i> variable enables you to manage the perspective of the view
+in the viewer by defining <i> setenv CSF_WALKTHROUGH </i> "Yes".
+
+If you use the syntax <i> unsetenv CSF_WALKTHROUGH </i>, you make sure that the variable
+is deactivated. In this case, the eye is located outside the 3D bounding box of the view.
+This is the default behavior for managing the view perspective.
+
+@section OCCT_TOVW_SECTION_6 Data Exchange
+
+Data Exchange is a key factor in using Open CASCADE Technology (as well as applications based thereon)
+concurrently with other software such as CAD systems. It provides the openness of OCCT in a multi-software environment,
+by allowing it to process external data and providing a good level of integration.
+
+This means obtaining results of good quality, and covering the needs of exchanges
+from OCCT-based applications regardless of external data quality or requirements,
+in particular in respect of allowed data types and arrangements between them, accepted gaps between geometries.
+
+This matter is addressed by Data Exchange Module, which is organized in a modular way.
+
+
+
+Data Exchange interfaces in OCCT allow software based on OCCT
+to exchange data with various CAD software, thus ensuring a good level of interoperability.
+
+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
+--------------------------
+
+* STEP (AP203 : Mechanical Design, this covers General 3D CAD; AP214: Automotive Design)
+* IGES (up to 5.3)
+* STL
+* VRML
+
+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 (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.
+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
+------------------------
+
+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:
+
+* ACIS SAT
+* Parasolid X_T
+* DXF
+
+These components are based on the same architecture as interfaces with STEP and IGES.
+
+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.
+It is intended to send geometric data (volumic) to stereolithography machines,
+which can read and interpret such data. These machines can transform a volumic model
+to a physical prototype made of plastic, by using laser to coagulate material,
+which corresponds to the volume, and set free the material around.
+STL defines these surfaces by triangles.
+Thus, no machining is required to switch from a virtual model to a physical one.
+
+Since STL files can only include solids described by their mesh structures,
+OCCT shapes, which are intended to be written, must be solids,
+components of solids or closed shells with a correct orientation.
+
+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.
+
+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.
+
+@subsection OCCT_TOVW_SECTION_6_1 General Definitions
+
+OCCT general definitions for Data Exchange include several enumerations and classes used by IGES and STEP data exchange interfaces.
+
+To define translation parameters and file headers, you can use:
+
+ * <i> Interface_InterfaceModel</i>
+ * <i> Interface_Static</i>
+
+To manage Message display, use class <i> Mesage_Messenger</i>.
+
+To define the type of analysis of the source file, and to ensure the success
+of the loading operation, you use the following enumerations from the <i> IFSelect</i> package:
+
+ * <i> PrintCount</i>
+ * <i> ReturnStatus</i>
+
+To read and write attributes such as names, colors, layers for IGES and STEP
+and validation properties and structure of assemblies for STEP, you can use an XDE document.
+
+It is possible to learn more about XDE documents from XDE User's guide
+
+See also: our web site at E-learning and Training.
+
+
+@subsection OCCT_TOVW_SECTION_6_2 IGES
+
+The IGES interface reads IGES files and translates them to Open CASCADE Technology models.
+IGES files produced in accordance with IGES standard versions up to and including version 5.3 can be read.
+The interface is able to translate one entity, a group of entities or a whole file.
+Before beginning a translation, you can set a range of parameters to manage the translation process.
+If you like, you can also check file consistency before translation.
+
+The IGES interface also translates OCCT models to IGES files.
+IGES files produced by this component conform to IGES standard version 5.3.
+
+Other kinds of data such as colors and names can be read or written
+with the help of XDE tools <i> IGESCAFControl_Reader</i> and <i> IGESCAFControl_Writer</i>.
+
+Please, note:
+
+ * an IGES model is an IGES file that has been loaded into memory.
+ * an IGES entity is an entity in the IGES normal sense.
+ * a root entity is the highest level entity of any given type, e.g. type 144 for surfaces and type 186 for solids. Roots are not referenced by other entities.
+
+It is possible to learn more about the IGES interface from IGES User's guide
+
+See also: our web site at E-learning and Training.
+
+@subsection OCCT_TOVW_SECTION_6_3 STEP
+
+The STEP interface reads STEP files produced in accordance with STEP Application Protocol 214
+(Conformance Class 2 both CD and DIS versions of schema) and translates them
+to Open CASCADE Technology models. STEP Application Protocol 203 is also supported.
+
+The STEP interface also translates OCCT models to STEP files. STEP files that are produced
+by this interface conform to STEP AP 203 or AP 214 (
+Conformance Class 2, either CD or DIS version of the schema) depending on the user's option.
+
+Basic interface reads and writes geometrical, topological STEP data and assembly structures.
+
+The interface is able to translate one entity, a group of entities or a whole file.
+
+Other kinds of data such as colors, validation properties, layers, names
+and the structure of assemblies can be read or written
+with the help of XDE tools - <i> STEPCAFControl_Reader</i> and <i> STEPCAFControl_Writer</i>.
+
+To choose a translation mode when exporting to a STEP format, use <i> STEPControl_STEPModelType</i>.
+
+There is a set of parameters that concern the translation and can be set before the beginning of the translation.
+
+Please, note:
+* a STEP model is a STEP file that has been loaded into memory;
+* all references to shapes indicate OCCT shapes unless otherwise explicitly stated;
+* a root entity is the highest level entity of any given type, i.e. an entity that is not referenced by any other one.
+
+It is possible to learn more about the STEP interface from STEP User's guide
+See also: our web site at E-learning and Training.
+
+@subsection OCCT_TOVW_SECTION_6_4 STL
+
+The STL component translates Open CASCADE Technology shapes to STL files. STL (Stereolithography) format is widely used for rapid prototyping.
+
+As STL files can only include solids described by their mesh structure,
+the OCCT shapes to be written must be solids, components of solids or closed shells with a correct orientation.
+
+Note All references to shapes indicate OCCT shapes unless otherwise explicitly stated.
+
+Sets of faces or unclosed shells may also be translated to STL format but visualization with foreign viewers may be incorrect.
+
+@subsection OCCT_TOVW_SECTION_6_5 VRML
+
+The VRML component translates Open CASCADE Technology shapes to VRML 1.0 files
+(Virtual Reality Modeling Language). OCCT shapes may be translated in two representations:
+shaded or wireframe. A shaded representation present shapes as sets of triangles
+computed by a mesh algorithm while a wireframe representation present shapes as sets of curves.
+
+As shaded VRML format files only include solids described by their mesh structures,
+the OCCT shapes to be written must be solids, components of solids or closed shells with a correct orientation.
+
+Please, note:
+
+ * all references to shapes indicate OCCT shapes unless otherwise explicitly stated;
+ * sets of faces or unclosed shells may also be translated to shaded VRML format but visualization with foreign viewers may be incorrect.
+
+@section OCCT_TOVW_SECTION_7 Application Framework
+
+The Application Framework uses an associativity engine to simplify the development of a CAD application.
+Based on application/document architecture, it does this due to the following features:
+
+ * Application data is handled by the mechanism of attributes
+ * Attributes may be organized according to your development needs
+ * Multiple documents can be managed by an application
+ * Ready-to-use modeling data attributes common to CAD/CAM applications
+ * Document modification and recomputation
+ * Data storage services
+ * A ready-to-use Undo-Redo and Copy-Paste functions
+
+Since OCAF handles your application structure, your only major development task is the creation
+of application-specific data and GUIs. It is the organization of application data
+due to which OCAF differs from any other CAD framework. In OCAF, data structures are not shape-driven,
+but reference-key driven. In this respect, attributes such as shape data, color, material,
+are attached to a deeper invariant structure of a model than the shapes themselves.
+Then OCAF organizes and embeds these attributes in a document.
+For example, a geometry becomes the value of the Shape attribute,
+in the same way as a number is the value of the Integer attribute and a string is the value of the Name attribute.
+
+OCAF documents are in their turn managed by an OCAF application.
+
+Please, refer for more details to OCAF User's guide and the OCAF white papers:
+* Application Framework
+* Distribution of Data through OCAF Tree
+* Application Framework Function Mechanism
+
+See also: our web site at E-learning and Training.
+
+@subsection OCCT_TOVW_SECTION_7_1 How to start working with OCAF
+
+To create a useful OCAF-based application, it is necessary to redefine the following
+two deferred methods: <i> Formats</i> and <i> ResourcesName</i>
+
+In the <i> Formats </i> method, it is necessary to add the format
+of the documents to be read by the application and which may have been built in other applications.
+
+For example:
+
+~~~~
+ void myApplication::Formats(TColStd_SequenceOfExtendedString& Formats)
+ {
+ Formats.Append(TCollection_ExtendedString ("OCAF-myApplication"));
+ }
+~~~~
+
+In the <i> ResourcesName</i> method, you only define the name of the resource file. This
+file contains several definitions for the saving and opening mechanisms associated
+with each format and calling of the plug-in file.
+
+~~~~
+ Standard_CString myApplication::ResourcesName()
+ {
+ return Standard_CString ("Resources");
+ }
+~~~~
+
+To obtain the saving and opening mechanisms, it is necessary to set two environment
+variables: <i> CSF_PluginDefaults</i>, which defines the path of the plug-in file and <i> CSF_ResourcesDefault</i>, which defines the resource file:
+
+~~~~
+ SetEnvironmentVariable ( "CSF_ResourcesDefaults",myDirectory);
+ SetEnvironmentVariable ( "CSF_PluginDefaults",myDirectory);
+~~~~
+
+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
+--------------
+
+The resource file describes the documents (type and extension) and
+the type of data that the application can manipulate
+by identifying the storage and retrieval drivers appropriate for this data.
+
+Each driver is unique and identified by a GUID generated, for example, with the <i> uuidgen </i> tool in Windows.
+
+Five drivers are required to use all standard attributes provided within OCAF:
+
+ * the schema driver (ad696002-5b34-11d1-b5ba-00a0c9064368)
+ * the document storage driver (ad696000-5b34-11d1-b5ba-00a0c9064368)
+ * the document retrieval driver (ad696001-5b34-11d1-b5ba-00a0c9064368)
+ * the attribute storage driver (47b0b826-d931-11d1-b5da-00a0c9064368)
+ * the attribute retrieval driver (47b0b827-d931-11d1-b5da-00a0c9064368)
+
+These drivers are provided as plug-ins and are located in the <i> PappStdPlugin</i> library.
+
+
+For example, this is a resource file, which declares a new model document OCAF-MyApplication:
+
+~~~~
+formatlist:OCAF-MyApplication
+OCAF-MyApplication.Description: MyApplication Document Version 1.0
+OCAF-MyApplication.FileExtension: sta
+OCAF-MyApplication.StoragePlugin: ad696000-5b34-11d1-b5ba-00a0c9064368
+OCAF-MyApplication.RetrievalPlugin: ad696001-5b34-11d1-b5ba-00a0c9064368
+OCAF-MyApplicationSchema: ad696002-5b34-11d1-b5ba-00a0c9064368
+OCAF-MyApplication.AttributeStoragePlugin: 47b0b826-d931-11d1-b5da-00a0c9064368
+OCAF-MyApplication.AttributeRetrievalPlugin: 47b0b827-d931-11d1-b5da-00a0c9064368
+~~~~
+
+
+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.
+
+You need at least the <i> FWOSPlugin</i> and the plug-in drivers to run an OCAF application.
+
+The syntax of each item is <i> Identification.Location Library_Name, </i> where:
+* Identification is GUID.
+* Location defines the location of the Identification (where its definition is found).
+* Library_Name is the name (and path to) the library, where the plug-in is located.
+
+For example, this is a Plugin file:
+
+~~~~
+a148e300-5740-11d1-a904-080036aaa103.Location: FWOSPlugin
+! base document drivers plugin
+ad696000-5b34-11d1-b5ba-00a0c9064368.Location: PAppStdPlugin
+ad696001-5b34-11d1-b5ba-00a0c9064368.Location: PAppStdPlugin
+ad696002-5b34-11d1-b5ba-00a0c9064368.Location: PAppStdPlugin
+47b0b826-d931-11d1-b5da-00a0c9064368.Location: PAppStdPlugin
+47b0b827-d931-11d1-b5da-00a0c9064368.Location: PAppStdPlugin
+~~~~
+
+@subsection OCCT_TOVW_SECTION_7_2 Data Attributes
+
+The following ready-to-use attributes are provided:
+ * Shape attributes, which contain shapes and their evolution
+ * Standard attributes, a collection of common CAD/CAM attributes including:
+ * Real
+ * Integer
+ * Name
+ * Constrain
+ * Visualization attributes implement the Application Interactive Services in the context of Open CASCADE Application Framework.
+ * Function attributes which regenerate any data affected by modifications made in a
+document
+
+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.
+
+
+It is used for keeping and access to topological objects and their evolution. All
+topological objects are stored in the one user-protected <i> TNaming_UsedShapes attribute</i>
+at the root label of the data framework. This attribute contains map with all topological
+shapes, used in this document.
+
+TNaming_NamedShape attribute can be added to any other attribute. This attribute contains
+references (hooks) to shapes from the <i> TNaming_UsedShapes</i> attribute and evolution
+of these shapes. <i> TNaming_NamedShape </i> attribute contains a set of pairs of hooks: old
+shape and new shape (see the figure below). It allows not only get the topological
+shapes by the labels, but also trace evolution of the shapes and correctly resolve
+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.
+
+
+
+
+Shape attributes in data framework.
+-------------------------------
+
+Algorithms can dispose sub-shapes of the result shape at the individual
+label depending on necessity:
+
+ * If a sub-shape must have some extra attributes (material of each face or color of each edge). In this case a specific sub-shape is placed to the separate label (usually, sub-label of the result shape label) with all attributes of this sub-shape.
+ * If topological naming is needed, a necessary and sufficient (for selected sub-shapes identification) set of sub-shapes is placed to the child labels of the result shape label. As usual, as far as basic solids and closed shells are concerned, all faces of the shape are disposed. Edges and vertices sub-shapes can be identified as intersection of contiguous faces. Modified/generated shapes may be placed to one named shape and identified as this named shape and source named shape that also can be identified with used algorithms.
+
+<i> TNaming_NamedShape </i> may contain a few pairs of hooks with the same evolution. In this
+case topology shape, which belongs to the named shape, is a compound of new shapes.
+
+The data model contains both the topology and the hooks, and functions handle both
+topological entities and hooks. Consider the case of a box function, which creates
+a solid with six faces and six hooks. Each hook is attached to a face. If you want,
+you can also have this function create hooks for edges and vertices as well as for
+faces.
+
+Not all functions can define explicit hooks for all topological entities they create,
+but all topological entities can be turned into hooks when necessary. This is where
+topological naming is necessary.
+
+Consider the following example. A box defines six hooks for the six faces, but a
+protrusion created on a face of the box can only define two hooks, one for the top
+face, and one for all the lateral faces. As the basic wire defining the protrusion
+may change in the future the protrusion function cannot designate the lateral faces
+without ambiguity, their number may change. Figure 6 illustrates this example, faces
+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.
+
+
+
+This structure raises two problems:
+
+ * the value of the face F6 attribute-hook has changed;
+ * no data can be attached to F7.
+
+When a hook designates multiple faces like F7-F10 (or the hook on F6 if F6 was split)
+it is impossible to attach data to an individual face like F7.
+
+In fact, the protrusion has a trimmed face F6. As a result, the value of this face
+has changed and the current value of the hook attached to it needs to be found. Note
+that this face could have been split in two faces (for example if the function had
+been a slot) and both new faces would have been attached to the same hook.
+
+
+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.
+
+To find an attribute attached to a specific label, you use the GUID of the type of
+attribute you are looking for. For this, find this information using the method
+<i> GetID</i> and the method <i> Find</i> for the label as follows:
+
+~~~~
+ Standard_GUID anID = MyAttributeClass::GetID();
+ Standard_Boolean HasAttribute = aLabel.Find(anID,anAttribute);
+~~~~
+
+
+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
+
+There are three schemas of persistence, which you can use to store and retrieve OCAF data (documents):
+
+ * <i> Standard</i> persistence schema, compatible with previous OCAF applications
+ * <i> XmlOcaf</i> persistence, allowing the storage of all OCAF data in XML form
+ * <i> BinOcaf</i> persistence, allowing the storage of all OCAF data in binary format form
+
+
+All schemes are independent of each other, but they guarantee that the standard OCAF
+attributes stored and retrieved by one schema will be storable and retrievable by
+the other. Therefore in any OCAF application you can use any persistence schema or
+even all three of them. The choice is made by the Format string of stored OCAF documents
+or automatically by the file header data - * on retrieval.
+
+Persistent data storage in OCAF using the <i> Standard</i> package is presented in:
+
+ * Basic Data Storage
+ * Persistent Collections
+
+Persistent storage of shapes is presented in the following chapters:
+
+ * Persistent Geometry
+ * Persistent Topology
+
+Finally, information about opening and saving persistent data is presented in Standard
+Documents.
+
+
+@subsubsection OCCT_TOVW_SECTION_7_2_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
+is running and are not stored permanently. However, the Data Storage module provides
+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 are extensible libraries of elementary classes you
+use to define the database schema of your application. They include:
+* Unicode (8-bit or 16-bit character type) strings
+* Collections of any kind of persistent data such as arrays, stacks, queues, and graphs.
+
+All persistent classes are derived from the \b Persistent base class, which defines
+a unique way of creating and handling persistent objects. You create new persistent
+classes by inheriting from this base class.
+
+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
+of an application.
+
+For each class of 2D and 3D geometric types, and for the general shape class in the
+topological data structure library, there are corresponding persistent class libraries,
+which allow you to translate your data with ease.
+
+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
+drivers.
+
+The <i> Storage </i> package is used to write and read persistent objects.
+These objects are read and written by a retrieval or storage algorithm
+(<i> Storage_Schema </i>object) in a container (disk, memory, network ...).
+Drivers (<i> FSD_File</i> objects) assign a physical container for data to be stored or retrieved.
+
+The standard procedure for an application in reading a container is as follows:
+
+ *open the driver in reading mode,
+ *call the Read function from the schema, setting the driver as a parameter. This function returns an instance of the <i> Storage_Data </i> class which contains the data being read,
+ *close the driver.
+
+The standard procedure for an application in writing a container is as follows:
+
+ *open the driver in writing mode,
+ *create an instance of the <i> Storage_Data </i> class, then add the persistent data to write with the function <i> AddRoot</i> ,
+ *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
+
+Persistent collections are classes which handle dynamically sized collections of
+data that can be stored in the database. These collections provide three categories
+of service:
+
+ * persistent strings,
+ * generic arrays of data,
+ * commonly used instantiations of arrays.
+
+Persistent strings are concrete classes that handle sequences of characters based
+on both ASCII (normal 8-bit) and Unicode (16-bit) character sets.
+
+Arrays are generic classes, that is, they can hold a variety of objects not necessarily
+inheriting from a unique root class. These arrays can be instantiated with any kind
+of storable or persistent object, and then inserted into the persistent data model
+of a user application.
+
+The purpose of these data collections is simply to convert transient data into its
+persistent equivalent so that it can be stored in the database. To this end, the
+collections are used to create the persistent data model and assure the link with
+the database. They do not provide editing or query capabilities because it is more
+efficient, within the operative data model of the application, to work with transient
+data structures (from the <i> TCollection</i> package).
+
+For this reason:
+
+ * the persistent strings only provide constructors and functions to convert between transient and persistent strings, and
+ * the persistent data collections are limited to arrays. In other words, <i> PCollection</i> does not include sequences, lists, queues, sets, stacks and so on (unlike <i> TCollection</i>).
+
+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
+
+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
+"world" to the persistent "world".
+
+Persistent Geometry consists of a set of atomic data models parallel to the geometric
+data structures described in the geometry packages. Geometric data models, independent
+of each other, can appear within the data model of any application. The system provides
+the means to convert each atomic transient data model into a persistent one, but
+it does not provide a way for these data models to share data.
+
+Consequently, you can create a data model using these components, store data in,
+and retrieve it from a file or a database, using the geometric components provided
+in the transient and persistent "worlds". In other words, you customize the system
+by declaring your own objects, and the conversion of the geometric components from
+persistent to transient and vice versa is automatically managed for you by the system.
+
+However, these simple objects cannot be shared within a more complex data model.
+To allow data to be shared, you must provide additional tools.
+
+Persistent Geometry is provided by several packages.
+
+The <i> PGeom</i> package describes geometric persistent objects in 3D space, such as points,
+vectors, positioning systems, curves and surfaces.
+
+These objects are persistent versions of those provided by the <i> Geom</i> package: for
+each type of transient object provided by Geom there is a corresponding type of persistent
+object in the <i>PGeom</i> package. In particular the inheritance structure is parallel.
+
+However the <i> PGeom </i>package does not provide any functions to construct, edit or access
+the persistent objects. Instead the objects are manipulated as follows:
+
+ * Persistent objects are constructed by converting the equivalent transient <i> Geom </i> objects. To do this you use the <i>MgtGeom::Translate</i> function.
+ * Persistent objects created in this way are used to build persistent data structures that are then stored in a file or database.
+ * When these objects are retrieved from the file or database, they are converted back into the corresponding transient objects from the Geom package. To do this, you use <i>MgtGeom::Translate</i> function.
+
+In other words, you always edit or query transient data structures within the transient
+data model supplied by the session.
+Consequently, the documentation for the <i> PGeom </i> package consists simply of a list of available objects.
+
+The <i> PGeom2d </i> package describes persistent geometric objects in 2D space, such as points,
+vectors, positioning systems and curves. This package provides the same type of services
+as the <i> PGeom</i> package, but for the 2D geometric objects provided by the <i> Geom2d</i> package.
+Conversions are provided by the <i>MgtGeom::Translate</i> function.
+
+~~~~
+//Create a coordinate system
+Handle(Geom_Axis2Placement) aSys;
+
+
+//Create a persistent coordinate PTopoDS_HShape.cdlsystem
+Handle(PGeom_Axis2placement)
+ aPSys = MgtGeom::Translate(aSys);
+
+//Restore a transient coordinate system
+Handle(PGeom_Axis2Placement) aPSys;
+
+Handle(Geom_Axis2Placement)
+ aSys = MgtGeom::Translate(aPSys);
+~~~~
+
+
+@subsubsection OCCT_TOVW_SECTION_7_2_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".
+
+Persistent Topology is based on the BRep concrete data model provided by the topology packages. Unlike the components of the Persistent Geometry package, topological components can be fully shared within a single model, as well as between several models.
+
+Each topological component is considered to be a shape: a <i> TopoDS_Shape</i> object. The system's capacity to convert a transient shape into a persistent shape and vice-versa applies to all objects, irrespective of their complexity: vertex, edge, wire, face, shell, solid, and so on.
+
+When a user creates a data model using BRep shapes, he uses the conversion functions that the system provides to store the data in, and retrieve it from the database. The data can also be shared.
+
+Persistent Topology is provided by several packages.
+
+The <i> PTopoDS</i> package describes the persistent data model associated with any BRep shape; it is the persistent version of any shape of type <i> TopoDS_Shape</i>. As is the case for persistent geometric models, this data structure is never edited or queried, it is simply stored in or retrieved from the database. It is created or converted by the <i>MgtBRep::Translate</i> function.
+
+The <i> MgtBRepAbs</i> and <i> PTColStd </i> packages provide tools used by the conversion functions of topological objects.
+
+~~~~
+//Create a shape
+TopoDS_Shape aShape;
+
+//Create a persistent shape
+PtColStd_DoubleTransientPersistentMap aMap;
+
+Handle(PTopoDS_HShape) aPShape =
+ aMap.Bind2(MgtBRep::Translate
+ aShape,aMap,MgtBRepAbs_WithTriangle));
+
+aPShape.Nullify();
+
+//Restore a transient shape
+Handle(PTopoDS_HShape) aPShape;
+
+Handle(TopoDS_HShape) aShape =
+ aMap.Bind1(MgtBRep::Translate
+ (aPShape,aMap,MgtBRepAbs_WithTriangle));
+
+aShape.Nullify();
+~~~~
+
+@subsubsection OCCT_TOVW_SECTION_7_2_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>
+which manages creation, storage and retrieval of documents.
+
+You can implement undo and redo in your document, and refer from the data framework
+of one document to that of another one. This is done by means of external link attributes,
+which store the path and the entry of external links. To sum up, standard documents
+alone provide access to the data framework. They also allow you to:
+*Update external links;
+*Manage the saving and opening of data;
+*Manage undo/redo functionality.
+
+@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
+of C++ objects. In this context, memory allocation and de-allocation standard functions
+are not suited to the system's requirements and for this reason a specialized Memory
+Manager is implemented into Open CASCADE Technology. The Memory Manager is based
+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
+-------------------
+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 \96 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;
+ // H1 has one reference and corresponds to 48 bytes of memory
+ {
+ Handle (TColStd_HSequenceOfInteger) H2;
+ H2 = H1; // H1 has two references
+ if (argc == 3)
+ {
+ Handle (TColStd_HSequenceOfInteger) H3;
+ H3 = H1;
+ // Here, H1 has three references
+ }
+ // Here, H1 has two references
+ }
+ // Here, H1 has 1 reference
+ }
+ // Here, H1 has no reference but the 48 bytes of memory are kept.
+ Handle (TColStd_HSequenceOfInteger) H1 = new TColStd_HSequenceOfInteger;
+ // Here, H1 has one reference and corresponds to the preceding 48 bytes of
+ // 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.
+
+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
+------------------
+
+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
+
+You can create a class manipulated by handle even if you do not use CDL (Open CASCADE Definition Language).
+To do that you have to use the <i>Define_Standard_Handle</i> macro which is defined in the include file <i> Standard_DefineHandle.hxx</i>.
+
+Here is an example which shows how to define a class <i> SamplePoint </i> manipulated by handle.
+
+~~~~
+
+Sample_Point.hxx:
+---------------
+
+ #ifndef _Sample_Point_HeaderFile
+ #define _Sample_Point_HeaderFile
+ #ifndef _Standard_Macro_HeaderFile
+ #include <Standard_Macro.hxx>
+ #endif
+ #include <MMgt_TShared.hxx>
+ #include <Standard_DefineHandle.hxx>
+ // Handle definition
+ //
+
+ DEFINE_STANDARD_HANDLE(Sample_Point,MMgt_TShared)
+ class Sample_Point: public MMgt_TShared {
+ public:
+ Sample_Point();
+ Sample_Point(const Standard_Real, const
+ Standard_Real);
+ void SetX(const Standard_Real x) {
+ myX = x;
+ }
+ void SetY(const Standard_Real y) {
+ myY = y;
+ }
+ Standard_Real X() const {
+ return myX;
+ }
+ Standard_Real Y() const {
+ return myY;
+ }
+ // some methods like DynamicType() or
+ IsKind()
+ //
+ DEFINE_STANDARD_RTTI(Sample_Point)
+ private:
+ Standard_Real myX;
+ Standard_Real myY;
+ };
+ #endif
+
+Sample_Point.cxx:
+----------------
+
+ #include <Sample_Point.hxx>
+
+ // Implementation of Handle and type mgt
+
+ IMPLEMENT_STANDARD_HANDLE(Sample_Point,MMgt_TShared)
+ IMPLEMENT_STANDARD_RTTI(Sample_Point,MMgt_TShared)
+
+ // For ancestors, we add a IMPLEMENT_STANDARD_SUPERTYPE and
+ // a IMPLEMENT_STANDARD_SUPERTYPE_ARRAY_ENTRY macro.
+ // We must respect the order: from the direct ancestor class to the base class.
+
+ IMPLEMENT_STANDARD_TYPE(Sample_Point)
+ IMPLEMENT_STANDARD_SUPERTYPE(MMgt_TShared)
+ IMPLEMENT_STANDARD_SUPERTYPE(Standard_Transient)
+ IMPLEMENT_STANDARD_SUPERTYPE_ARRAY()
+ IMPLEMENT_STANDARD_SUPERTYPE_ARRAY_ENTRY(MMgt_TShared)
+ IMPLEMENT_STANDARD_SUPERTYPE_ARRAY_ENTRY(Standard_Transient)
+ IMPLEMENT_STANDARD_SUPERTYPE_ARRAY_END()
+ IMPLEMENT_STANDARD_TYPE_END(Sample_Point)
+
+ // Constructors implementation
+
+ Sample_Point::Sample_Point(const
+ Standard_Real x, const Standard_Real y)
+ {
+ myX = x;
+ myY = y;
+ }
+ Sample_Point::Sample_Point()
+ {
+ myX = 0.0;
+ myY = 0.0;
+ }
+~~~~
+
+@subsection OCCT_TOVW_SECTION_8_3 When is it necessary to use a handle?
+
+When designing an object, the user is faced with the choice of manipulating that
+object by value, or by handle.
+
+ * If your object may have a long lifetime within the application and you want to make multiple references to it, it would be preferable to manipulate this object with a handle. The memory for the object will be allocated on the heap. The handle which points to that memory is a light object which can be rapidly passed in argument. This avoids the penalty of copying a large object.
+ * If your object will have a limited lifetime, for example, used within a single algorithm, it would be preferable to manipulate this object by value, non-regarding its size, because this object is allocated on the stack and the allocation and de-allocation of memory is extremely rapid, which avoids the implicit calls to 'new' and 'delete' occasioned by allocation on the heap.
+ * Finally, if an object will be created only once during, but will exist throughout the lifetime of the application, the best choice may be a class manipulated by handle or a value declared as a global variable.
+
+
+@subsection OCCT_TOVW_SECTION_8_4 How to cast shape handle to void
+
+You can easily cast a reference to the handle object to <i> void* </i> by defining the following:
+
+~~~~
+ void *pointer;
+ Handle(Some_class) aHandle;
+ // Here only a pointer will be copied
+ Pointer = &aHandle;
+ // Here the Handle object will be copied
+ aHandle = * (Handle(Some_Class) *)pointer;
+~~~~
+
+@subsection OCCT_TOVW_SECTION_8_5 How to test correct ending of OCCT algorithms
+
+Generally OCCT algorithms implement <i> IsDone</i> method, which returns <i> true</i>
+if computation has been performed successfully from beginning to end or <i> false</i> if computation has failed.
+
+When <i> IsDone</i> returns <i> true</i>, the computation is successful regarding
+to the input data, but it does not necessary mean that you get a result. For example, if
+you perform a cut algorithm between two shapes without any common part, the <i> IsDone</i>
+method will return <i> true</i>, but the result will be empty.
+
+So, in some cases, it can be necessary to analyse the structure of a result before
+using it again in following computations. These tests are not done systematically
+into algorithms to get faster computations. The application performs necessary tests
+depending on the context.
+
+@subsection OCCT_TOVW_SECTION_8_6 How to cut, copy and paste inside a document
+
+To cut, copy and paste inside a document, you must use the <i> CopyLabel</i> class from the <i> TDF</i> package.
+In fact, you must define a Label which contains the temporary value a cut or
+copy operation (say, in <i> Lab_Clipboard</i>). You must also define two other labels:
+
+* One containing the data (e.g. <i> Lab_source</i>)
+* One for the destination of the copy (e.g. <i> Lab_ Target</i> )
+
+~~~~
+ Copy = copy (Lab_Source => Lab_Clipboard)
+ Cut = copy + Lab_Source.ForgetAll() // command clear the contents of LabelSource.
+ Paste = copy (Lab_Clipboard => Lab_target)
+~~~~
+
+So we need a tool to copy all (or a part) of the content of a label and its sub-label,
+to another place defined by a label.
+
+~~~~
+ TDF_CopyLabel aCopy;
+ TDF_IDFilter aFilter (Standard_False);
+
+ //Don't copy TDataStd_TreeNode attribute
+
+ aFilter.Ignore(TDataStd_TreeNode::GetDefaultTreeID());
+ aCopy.Load(aSource, aTarget); aCopy.UseFilter(aFilter); aCopy.Perform();
+
+ // copy the data structure to clipboard
+
+ return aCopy.IsDone(); }
+~~~~
+
+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
--- /dev/null
+Draw Test Harness {#user_guides__test_harness}
+===============================
+
+@section occt_2142243456_1775316760 Introduction
+
+This manual explains how to use Draw, the test harness for Open CASCADE Technology (**OCCT**). It provides basic documentation on using Draw. For advanced information on Draw and its applications, see our offerings on our web site at <a href="http://www.opencascade.org/support/training">http://www.opencascade.org/support/training</a>
+
+Draw is a command interpreter based on TCL and a graphical system used to test and demonstrate Open CASCADE Technology modeling libraries.
+
+
+@subsection occt_2142243456_17753167601 Overview
+
+Draw is a test harness for Open CASCADE Technology. It provides a flexible and easy to use means of testing and demonstrating the OCCT modeling libraries.
+
+Draw can be used interactively to create, display and modify objects such as curves, surfaces and topological shapes.
+
+Scripts may be written to customize Draw and perform tests. New types of objects and new commands may be added using the C++ programing language.
+
+Draw consists of:
+
+ * A command interpreter based on the TCL command language.
+ * A 3d graphic viewer based on the X system.
+ * A basic set of commands covering scripts, variables and graphics.
+ * A set of geometric commands allowing the user to create and modify curves and surfaces and to use OCCT geometry algorithms. This set of commands is optional.
+ * A set of topological commands allowing the user to create and modify BRep shapes and to use the OCCT topology algorithms.
+
+
+There is also a set of commands for each delivery unit in the modeling libraries:
+
+GEOMETRY, TOPOLOGY, ADVALGOS, GRAPHIC, PRESENTATION.
+
+
+@subsection occt_2142243456_17753167602 Contents of this documentation
+
+This documentation describes:
+
+ * The command language.
+ * The basic set of commands.
+ * The graphical commands.
+ * The Geometry set of commands.
+ * The Topology set of commands.
+
+This document does not describe other sets of commands and does not explain how to extend Draw using C++.
+
+This document is a reference manual. It contains a full description of each command. All descriptions have the format illustrated below for the exit command.
+**Example**
+
+**exit**
+Syntax: exit
+
+Terminates the Draw, TCL session. If the commands are read from a file using the source command, this will terminate the file.
+
+**Example**
+
+# this is a very short example
+exit
+
+
+
+@subsection occt_2142243456_17753167603 Getting started
+
+Install Draw and launch Emacs. Get a command line in Emacs using *Esc x *and key in *woksh*.
+
+Since version 5.1.1 Open CASCADE Technology introduces a single executable in the DRAW Test Harness that supersedes the several separate executables that existed before. Respectively the user does not need to have his own executables to activate his custom commands. All he needs to do is to implement the commands themselves, they will be activated in the common executable. This executable is now called **DRAWEXE**.
+
+Commands grouped in toolkits can now be loaded at run-time thereby implementing dynamically loaded plug-ins. Thus, the user can work only with those commands that suit his needs adding these commands dynamically without leaving the Test Harness session.
+
+Declaration of available plug-ins is done through the special resource file(s). The **pload** command loads the plug-in in accordance with the specified resource file and activates the commands implemented in the plug-in.
+The whole process of using new advantages of the plug-in mechanism as well as instructions for extending Test Harness are described below.
+
+
+@subsubsection occt_2142243456_177531676031 Launching DRAW Test Harness
+
+Test Harness executable DRAWEXE is located in the $CASROOT/platform/bin directory (where platform is win32 for Windows, SunOS for Sun Solaris and Linux for Linux operating systems). Prior to launching it is important to make sure the environment is correctly set-up (usually this is done automatically after the installation process on Windows or after launching specific scripts on Unix/Linux) - refer to Technical Documentation for details.
+
+
+@subsubsection occt_2142243456_177531676032 Plug-in resource file
+
+Open CASCADE Technology is shipped with the DrawPlugin resource file located in the $CASROOT/src/DrawResources directory.
+The format of the file is compliant with standard Open CASCADE Technology resource files (see the Resource_Manager.cdl file for details).
+
+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
+
+DCAF : TKDCAF
+AISV : TKViewerTest
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@subsubsection occt_2142243456_177531676033 Activation of commands implemented in the plug-in
+
+To load a plug-in declared in the resource file and to activate the commands the following command must be used in Test Harness:
+
+pload [-PluginFileName] [[Key1] [Key2]...], where:
+
+-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.
+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
+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).
+Will find the default DrawPlugin file and the DEFAULT key. The latter finally maps to the TKTopTest toolkit which implements basic modeling commands.
+
+
+@subsubsection occt_2142243456_177531676034 Mapping between former separate Test Harness executables and the new plug-ins
+
+Before version 5.1.1 Open CASCADE Technology used to be shipped with several separate executables providing different sets of commands. The following table represents the mapping between former executables and new plug-ins.
+
+
+For instance, in order to activate commands available in the former AISViewer executable, now it is enough to use the command pload VISUALIZATION.
+
+When you have the tclsh prompt, key in the library references:
+
+*wokcd MDL:k1deb:ref:DRAWEXE*. At the prompt, key in the environment
+(*@@ -setenv *in Unix). Draw displays a prompt. Here is a sample session:
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+# create two views, one 2d the other axonometric. Use either the command line or the Draw taskbar (*Views/av2d*).
+Draw[1]av2d
+
+# create a 2d circle
+Draw[2]circle c 0 0 1 0 5
+# trim the circle and dump it
+Draw[3] trim c c 0 pi/2
+Draw[4] dump c
+==***** Dump of c *****
+==Trimmed curve
+==Parameters : 0 1.5707963267949
+==Basis curve :
+==Circle
+== Center :0, 0
+== XAxis :1, 0
+== YAxis :-0, 1
+== Radius :5
+# make a 3d circle from it, and turn it into a bspline
+Draw[6] to3d c1 c
+Draw[7] fit
+Draw[8] convert c2 c1
+Draw[9] dump c2
+***** Dump of c2 *****
+BSplineCurve rational
+Degree 2, 3 Poles, 2 Knots
+Poles :
+1 : 5, 0, 0 1
+2 : 5, 5, 0 0.707106781186548
+3 : 3.06161699786838e-16, 5, 0 1
+Knots :
+1 : 0 3
+2 : 1.5707963267949 3
+
+# make a surface of revolution from the spline
+Draw[10] fit
+Draw[11] help rev
+reverse : reverse name ...
+revsurf : revsurf name curvename x y z dx dy dz
+# here you must click on the curve with the mouse
+Draw[12] revsurf s . 5 5 0 -1 1 0
+Pick an object
+Draw[13] fit
+# rotate the view
+Draw[14] u
+Draw[15] erase c
+# make a bspline surface and intersect with a plane
+Draw[20] convert s s
+Draw[21] fit
+Draw[22] plane p 5 5 5 1 1 1 1 0 0
+Draw[23] intersect c p s
+# pick one of the intersection curves
+# you may get c_2 onstead of c_1
+Draw[24] whatis .
+Pick an object
+c_1 is a a 3d curve
+Draw[25] clear
+Draw[27] rename c_1 c
+Draw[28] fit
+# save the curve, use datadir (p. 32) to specify the
+directory you want to save your file in.
+Draw[29] save c
+Draw[30] exit
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+In this example some geometrical operations have been performed. Objects displayed and written to files.
+@section occt_2142243456_1668530729 The Command Language
+
+
+
+
+
+@subsection occt_2142243456_16685307294 Overview
+
+The command language used in Draw is Tcl. Tcl<a href="#_ftn1">[1]</a> documentation such as ;TCL and the TK Toolkit; by John K. Ousterhout (Addison-Wesley) will prove useful if you intend to use Draw extensively.
+
+This chapter is designed to give you a short outline of both the TCL language and some extensions included in Draw. The following topics are covered:
+
+ * Syntax of the TCL language.
+ * Accessing variables in TCL and Draw.
+ * Control structures.
+ * Procedures.
+
+@subsection occt_2142243456_16685307295 Syntax of TCL
+
+TCL is an interpreted command language, not a structured language like C, Pascal, LISP or Basic. It uses a shell similar to that of csh. TCL is, however, easier to use than csh because control structures and procedures are easier to define. As well, because TCL does not assign a process to each command, it is faster than csh.
+
+The basic program for TCL is a script. A script consists of one or more commands. Commands are separated by new lines or semicolons.
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+set a 24
+set b 15
+set a 25; set b 15
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Each command consists of one or more *words*; the first word is the name of a command and additional words are arguments to that command.
+
+Words are separated by spaces or tabs. In the preceding example each of the four commands has three words. A command may contain any number of words and each word is a string of arbitrary length.
+
+The evaluation of a command by TCL is done in two steps. In the first step, the command is parsed and broken into words. Some substitutions are also performed. In the second step, the command procedure corresponding to the first word is called and the other words are interpreted as arguments. In the first step, there is only string manipulation, The words only acquire *meaning* in the second step by the command procedure.
+
+The following substitutions are performed by TCL:
+
+**1. **Variable substitution is triggered by the $ character (as with csh), the content of the variable is substitued; { } may be used as in csh to enclose the name of the variable.
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+# set a variable value
+set file documentation
+puts $file #to display file contents on the screen
+
+# a simple substitution, set psfile to documentation.ps
+set psfile $file.ps
+puts $psfile
+
+# another substitution, set pfile to documentationPS
+set pfile ${file}PS
+
+# a last one,
+# delete files NEWdocumentation and OLDdocumentation
+foreach prefix {NEW OLD} {rm $prefix$file}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+**2. **Command substitution is triggered by the [ ] characters. The brackets must enclose a valid script. The script is evaluated and the result is substituted.
+Compare command construction in csh.
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+set degree 30
+set pi 3.14159265
+# expr is a command evaluating a numeric expression
+set radian [expr $pi*$degree/180]
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+**3. **Backslash substitution is triggered by the backslash character. It is used to insert special characters like $, [ , ] , etc. It is also useful to insert a new line, a backslash terminated line is continued on the following line.
+TCL uses two forms of *quoting* to prevent substitution and word breaking.
+
+**4. **Double quote *quoting* enables the definition of a string with space and tabs as a single word. Substitutions are still performed inside the inverted commas ; ;.
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+# set msg to ;the price is 12.00;
+set price 12.00
+set msg ;the price is $price;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+**5. **Braces *quoting* prevents all substitutions. Braces are also nested. The main use of braces is to defer evaluation when defining procedures and control structures. Braces are used for a clearer presentation of TCL scripts on several lines.
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+set x 0
+# this will loop for ever
+# because while argument is ;0 3;
+while ;$x 3; {set x [expr $x+1]}
+# this will terminate as expected because
+# while argument is {$x 3}
+while {$x 3} {set x [expr $x+1]}
+# this can be written also
+while {$x 3} {
+set x [expr $x+1]
+}
+# the following cannot be written
+# because while requires two arguments
+while {$x 3}
+{
+set x [expr $x+1]
+}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Comments start with a # character as the first non-blank character in a command. To add a comment at the end of the line, the comment must be preceded by a semi-colon to end the preceding command.
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+# This is a comment
+set a 1 # this is not a comment
+set b 1; # this is a comment
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The number of words is never changed by substitution when parsing in TCL. For example, the result of a substitution is always a single word. This is different from csh but convenient as the behavior of the parser is more predictable. It may sometimes be necessary to force a second round of parsing. **eval **accomplishes this: it accepts several arguments, concatenates them and executes the resulting script.
+
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+# I want to delete two files
+
+set files ;foo bar;
+
+# this will fail because rm will receive only one argument
+# and complain that ;foo bar; does not exit
+
+exec rm $files
+
+# a second evaluation will do it
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@subsection occt_2142243456_16685307296 Accessing variables in TCL and Draw
+
+TCL variables have only string values. Note that even numeric values are stored as string literals, and computations using the **expr **command start by parsing the strings. Draw, however, requires variables with other kinds of values such as curves, surfaces or topological shapes.
+
+TCL provides a mechanism to link user data to variables. Using this functionality, Draw defines its variables as TCL variables with associated data.
+
+The string value of a Draw variable is meaningless. It is usually set to the name of the variable itself. Consequently, preceding a Draw variable with a *$ *does not change the result of a command. The content of a Draw variable is accessed using appropriate commands.
+
+There are many kinds of Draw variables, and new ones may be added with C++. Geometric and topological variables are described below.
+
+Draw numeric variables can be used within an expression anywhere a Draw command requires a numeric value. The **expr **command is useless in this case as the variables are stored not as strings but as floating point values.
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+# dset is used for numeric variables
+# pi is a predefined Draw variable
+dset angle pi/3 radius 10
+point p radius*cos(angle) radius*sin(angle) 0
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+It is recommended that you use TCL variables only for strings and Draw for numerals. That way, you will avoid the **expr **command. As a rule, Geometry and Topology require numbers but no strings.
+
+@subsubsection occt_2142243456_166853072961 set, unset
+
+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.
+
+Without a value, **set **returns the content of the variable.
+
+**unset **deletes variables. It is is also used to delete Draw variables.
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+set a ;Hello world;
+set b ;Goodbye;
+set a
+== ;Hello world;
+unset a b
+set a
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+<h4>NOTE</h4>
+*The set command can set only one variable, unlike the dset command.*
+
+
+See also: **dset**, **dval**
+
+
+@subsubsection occt_2142243456_166853072962 dset, dval
+
+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.
+
+**dval **evaluates an expression containing Draw numeric variables and returns the result as a string, even in the case of a single variable. This is not used in Draw commands as these usually interpret the expression. It is used for basic TCL commands expecting strings.
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+# z is set to 0
+dset x 10 y 15 z
+== 0
+
+# no $ required for Draw commands
+point p x y z
+
+# *puts* prints a string
+puts ;x = [dval x], cos(x/pi) = [dval cos(x/pi)];
+== x = 10, cos(x/pi) = -0.99913874099467914
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+<h4>NOTE</h4>
+*In TCL, parentheses are not considered to be special characters. Do not forget to quote an expression if it contains spaces in order to avoid parsing different words. (a + b) is parsed as three words:;(a + b); or (a+b) are correct.*
+
+See also: **set**, **unset**
+
+
+
+@subsection occt_2142243456_16685307297 lists
+
+TCL uses lists. A list is a string containing elements separated by spaces or tabs. If the string contains braces, the braced part accounts as one element.
+
+This allows you to insert lists within lists.
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+# a list of 3 strings
+;a b c;
+
+# a list of two strings the first is a list of 2
+;{a b} c;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Many TCL commands return lists and **foreach **is a useful way to create loops on list elements.
+
+@subsubsection occt_2142243456_166853072971 Control Structures
+
+TCL allows looping using control structures. The control structures are implemented by commands and their syntax is very similar to that of their C counterparts (**if**, **while**, **switch**, etc.). In this case, there are two main differences between TCL and C:
+
+2. You use braces instead of parentheses to enclose conditions.
+3. You do not start the script on the next line of your command.
+
+
+@subsubsection occt_2142243456_166853072911 if
+
+Syntax if condition script [elseif script .... else script]
+
+**If **evaluates the condition and the script to see whether the condition is true.
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+if {$x 0} {
+puts ;positive;
+} elseif {$x == 0} {
+puts ;null;
+} else {
+puts ;negative;
+}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@subsubsection occt_2142243456_166853072912 while, for, foreach
+
+Syntax: while condition script
+for init condition reinit script
+foreach varname list script
+
+The three loop structures are similar to their C or csh equivalent. It is important to use braces to delay evaluation. **foreach **will assign the elements of the list to the variable before evaluating the script.
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+# while example
+dset x 1.1
+while {[dval x] 100} {
+ circle c 0 0 x
+ dset x x*x
+}
+# for example
+# incr var d, increments a variable of d (default 1)
+for {set i 0} {$i 10} {incr i} {
+ dset angle $i*pi/10
+ point p$i cos(angle0 sin(angle) 0
+}
+# foreach example
+foreach object {crapo tomson lucas} {display $object}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+See also: **break**, **continue**
+
+
+@subsubsection occt_2142243456_166853072913 break, continue
+
+Syntax: break
+continue
+
+Within loops, the **break **and **continue **commands have the same effect as in C.
+
+**break **interrupts the innermost loop and **continue **jumps to the next iteration.
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+# search the index for which t$i has value ;secret;
+for {set i 1} {$i = 100} {incr i} {
+ if {[set t$i] == ;secret;} break;
+}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+@subsection occt_2142243456_16685307292 Procedures
+
+TCL can be extended by defining procedures using the **proc **command, which sets up a context of local variables, binds arguments and executes a TCL script.
+
+The only problematic aspect of procedures is that variables are strictly local, and as they are implicitly created when used, it may be difficult to detect errors.
+
+There are two means of accessing a variable outside the scope of the current procedures: **global **declares a global variable (a variable outside all procedures); **upvar **accesses a variable in the scope of the caller. Since arguments in TCL are always string values, the only way to pass Draw variables is by reference, i.e. passing the name of the variable and using the **upvar **command as in the following examples.
+
+As TCL is not a strongly typed language it is very difficult to detect programing errors and debugging can be tedious. TCL procedures are, of course, not designed for large scale software development but for testing and simple command or interactive writing.
+
+
+@subsubsection occt_2142243456_166853072921 proc
+
+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.
+
+**return **gives a return value to the procedure.
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+# simple procedure
+proc hello {} {
+ puts ;hello world;
+}
+# procedure with arguments and default values
+proc distance {x1 y1 {x2 0} {y2 0}} {
+ set d [expr (x2-x1)*(x2-x1) + (y2-y1)*(y2-y1)]
+ return [expr sqrt(d)]
+}
+proc fact n {
+ if {$n == 0} {return 1} else {
+ return [expr n*[fact [expr n -1]]]
+ }
+}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+See also: **global**, **upvar**
+
+
+@subsubsection occt_2142243456_166853072922 global, upvar
+
+Syntax: global varname [varname ...]
+upvar varname localname [varname localname ...]
+
+**global **accesses high level variables. Unlike C, global variables are not visible in procedures.
+
+**upvar **gives a local name to a variable in the caller scope. This is useful when an argument is the name of a variable instead of a value. This is a call by reference and is the only way to use Draw variables as arguments.
+
+<h4>NOTE</h4>
+*Note in the following examplesthat the $ character is always*
+*necessarily used to access the arguments.*
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+# convert degree to radian
+# pi is a global variable
+proc deg2rad (degree} {
+ return [dval pi*$degree/2.]
+}
+# create line with a point and an angle
+proc linang {linename x y angle} {
+ upvar linename l
+ line l $x $y cos($angle) sin($angle)
+}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@section occt_2142243456_967049381 Basic Commands
+
+This chapter describes all the commands defined in the basic Draw package. Some are TCL commands, but most of them have been formulated in Draw. These commands are found in all Draw applications. The commands are grouped into four sections:
+
+ * General commands, which are used for Draw and TCL management.
+ * Variable commands, which are used to manage Draw variables such as storing and dumping.
+ * Graphic commands, which are used to manage the graphic system, and so pertain to views.
+ * Variable display commands, which are used to manage the display of objects within given views.
+
+Note that Draw also features a GUI taskbar providing an alternative way to give certain general, graphic and display commands
+
+
+
+@subsection occt_2142243456_9670493811 General commands
+
+This section describes several useful commands: **help **to get information, **source **to eval a script from a file, **spy **to capture the commands in a file, **cpulimit **to limit the process cpu time, **wait **to waste some time, **chrono **to time commands.
+
+
+@subsubsection occt_2142243456_96704938111 help
+
+Syntax: help [command [helpstring group]]
+
+Provides help or modifies the help information.
+
+**help **without arguments lists all groups and the commands in each group.
+
+Specifying the command returns its syntax and in some cases, information on the command, The joker,*, is automatically added at the end so that all completing commands are returned as well.
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+# Gives help on all commands starting with *a*
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+@subsubsection occt_2142243456_96704938112 source
+
+Syntax: source filename
+
+Executes a file.
+
+The **exit **command will terminate the file.
+
+See also: exit
+
+
+@subsubsection occt_2142243456_96704938113 spy
+
+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.
+
+The file created by **spy **can be executed with the **source **command.
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+# all commands will be saved in the file ;session;
+spy session
+# the file ;session; is closed and commands are not saved
+spy
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+See also: **source**
+
+
+@subsubsection occt_2142243456_96704938114 cpulimit
+
+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**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+#limit cpu to one hour
+cpulimit 3600
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@subsubsection occt_2142243456_96704938115 wait
+
+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.
+
+<h5>Example</h5>
+
+# You have ten seconds ...
+wait
+
+@subsubsection occt_2142243456_96704938116 chrono
+
+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.
+
+With arguments, **chrono **is used to manage activated chronometers. You can perform the following actions with a chronometer.
+
+ * run the chronometer (start).
+ * stop the chronometer (stop).
+ * reset the chronometer to 0 (reset).
+ * display the current time (show).
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+chrono
+==Chronometers activated.
+ptorus t 20 5
+==Elapsed time: 0 Hours 0 Minutes 0.0318 Seconds
+==CPU user time: 0.01 seconds
+==CPU system time: 0 seconds
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@subsection occt_2142243456_9670493812 Variable management commands
+
+@subsubsection occt_2142243456_96704938121 isdraw, directory
+
+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.
+Use **directory **to return a list of all Draw global variables matching a pattern.
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+set a 1
+isdraw a
+=== 0
+
+dset a 1
+isdraw a
+=== 1
+
+circle c 0 0 1 0 5
+isdraw c
+=== 1
+
+# to destroy all Draw objects with name containing curve
+foreach var [directory *curve*] {unset $var}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+See also: **whatis**
+
+
+@subsubsection occt_2142243456_96704938122 whatis, dump
+
+Syntax: whatis varname [varname ...]
+dump varname [varname ...]
+
+**whatis **returns short information about a Draw variable. This is usually the type name.
+
+**dump **returns a brief type description, the coordinates, and if need be, the parameters of a Draw variable.
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+circle c 0 0 1 0 5
+whatis c
+c is a 2d curve
+
+dump c
+
+***** Dump of c *****
+Circle
+Center :0, 0
+XAxis :1, 0
+YAxis :-0, 1
+Radius :5
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+<h4>NOTE</h4>
+*The behavior of whatis on other variables (not Draw) is not*
+*excellent.*
+
+
+@subsubsection occt_2142243456_96704938123 rename, copy
+
+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.
+
+**copy **creates a new variable with a copy of the content of an existing variable. The exact behavior of **copy **is type dependent; in the case of certain topological variables, the content may still be shared.
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+circle c1 0 0 1 0 5
+rename c1 c2
+
+# curves are copied, c2 will not be modified
+copy c2 c3
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@subsubsection occt_2142243456_96704938124 datadir, save, restore
+
+Syntax: datadir [directory]
+save variable [filename]
+restore filename [variablename]
+
+**datadir **without arguments prints the path of the current data directory.
+**datadir **with an argument sets the data directory path.
+If the path starts with a dot (.) only the last directory name will be changed in the path.
+
+**save **writes a file in the data directory with the content of a variable. By default the name of the file is the name of the variable. To give a different name use a second argument.
+
+**restore **reads the content of a file in the data directory in a local variable. By default, the name of the variable is the name of the file. To give a different name, use a second argument.
+
+The exact content of the file is type-dependent. They are usually ASCII files and so, architecture independent.
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+# note how TCL accesses shell environment variables
+# using $env()
+datadir
+==.
+
+datadir $env(WBCONTAINER)/data/default
+==/adv_20/BAG/data/default
+
+box b 10 20 30
+save b theBox
+==/adv_20/BAG/data/default/theBox
+
+# when TCL does not find a command it tries a shell command
+ls [datadir]
+== theBox
+
+restore theBox
+== theBox
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+@subsection occt_2142243456_9670493813 User defined commands
+
+DrawTrSurf provides commands to create and display a Draw **geometric **variable from a Geom_Geometry object and also get a Geom_Geometry object from a Draw geometric variable name.
+
+DBRep provides commands to create and display a Draw **topological **variable from a TopoDS_Shape object and also get a TopoDS_Shape object from a Draw topological variable name.
+
+@subsubsection occt_2142243456_96704938131 set
+
+**DrawTrSurf Package:**
+Syntax:
+
+void Set(Standard_CString& Name,const gp_Pnt& G) ;
+void Set(Standard_CString& Name,const gp_Pnt2d& G) ;
+void Set(Standard_CString& Name,
+const Handle(Geom_Geometry)& G) ;
+void Set(Standard_CString& Name,
+const Handle(Geom2d_Curve)& C) ;
+void Set(Standard_CString& Name,
+const Handle(Poly_Triangulation)& T) ;
+void Set(Standard_CString& Name,
+const Handle(Poly_Polygon3D)& P) ;
+void Set(Standard_CString& Name,
+const Handle(Poly_Polygon2D)& P) ;
+
+**DBRep Package:**
+Syntax:
+
+void Set(const Standard_CString Name,
+const TopoDS_Shape& S) ;
+
+**Example: DrawTrSurf**
+
+Handle(Geom2d_Circle) C1 = new Geom2d_Circle
+(gce_MakeCirc2d (gp_Pnt2d(50,0,) 25));
+DrawTrSurf::Set(char*, C1);
+
+**Example: DBRep**
+
+TopoDS_Solid B;
+B = BRepPrimAPI_MakeBox (10,10,10);
+DBRep::Set(char*,B);
+
+See also: **get**
+
+@subsubsection occt_2142243456_96704938132 get
+
+**DrawTrSurf Package:**
+Syntax:
+
+Handle_Geom_Geometry Get(Standard_CString& Name) ;
+
+**DBRep Package:**
+Syntax:
+
+TopoDS_Shape Get(Standard_CString& Name,
+const TopAbs_ShapeEnum Typ = TopAbs_SHAPE,
+const Standard_Boolean Complain
+= Standard_True) ;
+**Example: DrawTrSurf**
+
+Standard_Integer MyCommand
+(Draw_Interpretor& theCommands,
+Standard_Integer argc, char** argv)
+{......
+// Creation of a Geom_Geometry from a Draw geometric
+// name
+Handle (Geom_Geometry) aGeom= DrawTrSurf::Get(argv[1]);
+}
+
+**Example: DBRep**
+
+Standard_Integer MyCommand
+(Draw_Interpretor& theCommands,
+Standard_Integer argc, char** argv)
+{......
+// Creation of a TopoDS_Shape from a Draw topological
+// name
+TopoDS_Solid B = DBRep::Get(argv[1]);
+}
+See also: **set**
+
+@section occt_2142243456_445622066 Graphic Commands
+
+Graphic commands are used to manage the Draw graphic system. Draw provides a 2d and a 3d viewer with up to 30 views. Views are numbered and the index of the view is displayed in the window’s title. Objects are displayed in all 2d views or in all 3d views, depending on their type. 2d objects can only be viewed in 2d views while 3d objects – only in 3d views correspondingly.
+
+@subsection occt_2142243456_4456220661 Axonometric viewer
+
+@subsubsection occt_2142243456_44562206611 view, delete
+
+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.
+
+As a rule it is far simpler either to use the procedures **axo**, **top**, **left **or to click on the desired view type in the menu under *Views *in the taskbar..
+
+**delete **deletes a view. If no index is given, all the views are deleted.
+
+Type selects from the following range:
+
+ * AXON: Axonometric view
+ * PERS: Perspective view
+ * +X+Y: View on both axes (i.e. a top view), other codes are -X+Y, +Y-Z etc.
+ * -2D- : 2d view
+
+The index, the type, the current zoom are displayed in the window title .
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+# this is the content of the mu4 procedure
+proc mu4 {} {
+delete
+view 1 +X+Z 320 20 400 400
+view 2 +X+Y 320 450 400 400
+view 3 +Y+Z 728 20 400 400
+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, ...
+
+Syntax: axo
+pers
+...
+smallview type
+
+All these commands are procedures used to define standard screen layout. They delete all existing views and create new ones. The layout usually complies with the European convention, i.e. a top view is under a front view.
+
+ * **axo **creates a large window axonometric view.
+ * **pers **creates a large window perspective view.
+ * **top**, **bottom**, **left**, **right**, **front**, **back **create a large window axis view
+ * **mu4 **creates four small window viewsview: front, left, top and axo.
+ * **v2d**: creates a large window 2d view.
+ * **av2d **creates two small window views, one 2d and one axo
+**smallview **creates a view at the bottom right of the screen of the given type.
+
+See also: **view**, **delete**
+
+
+@subsubsection occt_2142243456_44562206613 mu, md, 2dmu, 2dmd, zoom, 2dzoom
+
+Syntax: mu [index] value
+2dmu [index] value
+zoom [index] value
+wzoom
+
+**mu **(magnify up) increases the zoom in one or several views by a factor of 10%.
+**md **(magnify down) decreases the zoom by the inverse factor. **2dmu **and **2dmd**
+perform the same on one or all 2d views.
+
+**zoom **and **2dzoom **set the zoom factor to a value specified by you. The current
+zoom factor is always displayed in the window’s title bar. Zoom 20 represents a
+full screen view in a large window; zoom 10, a full screen view in a small one.
+
+**wzoom **(window zoom) allows you to select the area you want to zoom in on with the mouse. You will be prompted to give two of the corners of the area that you want to magnify and the rectangle so defined will occupy the window of the view.
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+# set a zoom of 2.5
+zoom 2.5
+
+# magnify by 10%
+mu 1
+
+# magnify by 20%
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+See also: **fit**, **2dfit**
+
+
+@subsubsection occt_2142243456_44562206614 pu, pd, pl, pr, 2dpu, 2dpd, 2dpl, 2dpr
+
+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.
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+# you have selected one anonometric view
+pu
+# or
+pu 1
+
+# you have selected an mu4 view; the object in the third
+# view will pan up
+pu 3
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+See also: **fit**, **2dfit**
+
+
+@subsubsection occt_2142243456_44562206615 fit, 2dfit
+
+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.
+
+When fitting all views a unique zoom is computed for all the views. All views are on the same scale.
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+# fit only view 1
+fit 1
+# fit all 2d views
+2dfit
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+See also: **zoom**, **mu**, **pu**
+
+
+@subsubsection occt_2142243456_44562206616 u, d, l, r
+
+Syntax: u [index]
+d [index]
+l [index]
+r [index]
+
+**u**, **d**, **l**, **r **Rotate the object in view around its axis by five degrees up, down, left or right respectively. This command is restricted to axonometric and perspective views.
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+# rotate the view up
+u
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@subsubsection occt_2142243456_44562206617 focal, fu, fd
+
+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.
+
+Use **fu **and **fd **to increase or decrease the focal value by 10%. **fd **makes the eye closer to the object.
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+pers
+repeat 10 fd
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+*NOTE*
+*Do not use a negative or null focal value.*
+
+See also: **pers**
+
+
+@subsubsection occt_2142243456_44562206618 color
+
+Syntax: color index name
+
+**color **sets the color to a value. The index of the color is a value between 0 and 15. The name is an X window color name. The list of these can be found in the file rgb.txt in the X library directory.
+
+The default values are 0 White, 1 Red, 2 Green, 3 Blue, 4 Cyan, 5 Gold, 6 Magenta, 7 Marron, 8 Orange, 9 Pink, 10 Salmon, 11 Violet, 12 Yellow, 13 Khaki, 14 Coral.
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+# change the value of blue
+color 3 ;navy blue;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+<h4>NOTE</h4>
+*The color change will be visible on the next redraw of the*
+*views, for example after fit or mu, etc.*
+
+
+@subsubsection occt_2142243456_44562206619 dtext
+
+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.
+
+The coordinates are real space coordinates.
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+# mark the origins
+dtext 0 0 bebop
+dtext 0 0 0 bebop
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@subsubsection occt_2142243456_445622066110 hardcopy, hcolor, xwd
+
+Syntax: hardcopy [index]
+hcolor index width gray
+xwd [index] filename
+
+**hardcopy **creates a postcript file called a4.ps in the current directory. This file contains the postscript description of the view index, and will allow you to print the view.
+
+**hcolor **lets you change the aspect of lines in the postscript file. It allows to specify a width and a gray level for one of the 16 colors. **width **is measured in points with default value as 1, **gray **is the gray level from 0 = black to 1 = white with default value as 0. All colors are bound to the default values at the beginning.
+
+**xwd **creates an X window xwd file from an active view. By default, the index is set to1. To visualize anxwd file, use the unix command **xwud**.
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+# all blue lines (color 3)
+# will be half-width and gray
+hcolor 3 0.5
+
+# make a postscript file and print it
+hardcopy
+lpr a4.ps
+
+# make an xwd file and display it
+xwd theview
+xwud -in theview
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+<h4>NOTE</h4>
+*When more than one view is present, specify the index of the view.*
+*Only use a postscript printer to print postscript files.*
+
+See also: **color**
+
+
+@subsubsection occt_2142243456_445622066111 wclick, pick
+
+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.
+
+Use the **pick **command to get graphic input. The arguments must be names for variables where the results are stored.
+
+ * index: index of the view where the input was made.
+ * X,Y,Z: 3d coordinates in real world.
+ * b: b is the mouse button 1,2 or 3.
+
+When there is an extra argument, its value is not used and the command does not wait for a click; the value of b may then be 0 if there has not been a click.
+
+This option is useful for tracking the pointer.
+
+*NOTE*
+*The results are stored in Draw numeric variables.*
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+# make a circle at mouse location
+pick index x y z b
+circle c x y z 0 0 1 1 0 0 0 30
+
+# make a dynamic circle at mouse location
+# stop when a button is clicked
+# (see the repaint command)
+
+dset b 0
+while {[dval b] == 0} {
+pick index x y z b nowait
+circle c x y z 0 0 1 1 0 0 0 30
+repaint
+}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+See also: **repaint**
+
+
+Draw provides commands to manage the display of objects. **display**, **donly **are used to display, **erase**, **clear**, **2dclear **to erase. The **autodisplay **command is used to check whether variables are displayed when created.
+
+The variable name ;.; (dot) has a special status in Draw. Any Draw command expecting a Draw object as argument can be passed a dot. The meaning of the dot is the following.
+
+ * If the dot is an input argument, a graphic selection will be made. Instead of getting the object from a variable, Draw will ask you to select an object in a view.
+ * If the dot is an output argument, an unnamed object will be created. Of course this makes sense only for graphic objects: if you create an unnamed number you will not be able to access it. This feature is used when you want to create objects for display only.
+ * If you do not see what you expected while executing loops or sourcing files, use the **repaint **and **dflush **commands.
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+# OK use dot to dump an object on the screen
+dump .
+
+point . x y z
+
+#Not OK. display points on a curve c
+# with dot no variables are created
+for {set i 0} {$i = 10} {incr i} {
+cvalue c $i/10 x y z
+point . x y z
+}
+
+# point p x y z
+# would have displayed only one point
+# because the precedent variable content is erased
+
+# point p$i x y z
+# is an other solution, creating variables
+# p0, p1, p2, ....
+
+# give a name to a graphic object
+rename . x
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+@subsubsection occt_2142243456_445622066112 autodisplay
+
+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.
+
+When **autodisplay **is off, using the dot return argument is ineffective.
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+# c is displayed
+circle c 0 0 1 0 5
+
+# toggle the mode
+autodisplay
+== 0
+circle c 0 0 1 0 5
+
+# c is erased, but not displayed
+display c
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+See also: **display**
+
+@subsubsection occt_2142243456_445622066113 display, donly
+
+Syntax: display varname [varname ...]
+donly varname [varname ...]
+
+**display **makes objects visible.
+
+**donly **(*display only*) makes objects visible and erases all other objects. It is very useful to extract one object from a messy screen.
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+# to see all objects
+foreach var [directory] {display $var}
+
+# to select two objects and erase the other ones
+donly . .
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+See also: **erase**
+
+
+@subsubsection occt_2142243456_445622066114 erase, clear, 2dclear
+
+Syntax: erase [varname varname ...]
+clear
+2dclear
+
+**erase **removes objects from all views. **erase **without arguments erases everything in 2d and 3d.
+
+**clear **erases only 3d objects and **2dclear, **only 2d objects. **erase **without arguments is similar to ; clear; 2dclear;.
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+# erase eveerything with a name starting with c_
+foreach var [directory c_*] {erase $var}
+
+# clear 2d views
+2d clear
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+See also: **display**
+@subsubsection occt_2142243456_445622066115 repaint, dflush
+
+Syntax: repaint
+dflush
+
+**repaint **forces repainting of views.
+
+**dflush **flushes the graphic buffers.
+
+These commands are useful within loops or in scripts.
+
+When an object is modified or erased, the whole view must be repainted. To avoid doing this too many times, Draw sets up a flag and delays the repaint to the end of the command in which the new prompt is issued. In a script, you may want to display the result of a change immediately. If the flag is raised, **repaint **will repaint the views and clear the flag.
+
+Graphic operations are buffered by Draw (and also by the X system). Usually the buffer is flushed at the end of a command and before graphic selection. If you want to flush the buffer from inside a script, use the **dflush **command.
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+# See the example with the pick command
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+See also: **pick**
+
+@subsection occt_2142243456_4456220662 AIS viewer – view commands
+
+
+@subsubsection occt_2142243456_44562206621 vinit
+
+Syntax: vinit
+
+Creates the 3D viewer window
+
+@subsubsection occt_2142243456_44562206622 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
+
+Displays top view in the 3D viewer window.
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+vinit
+box b 10 10 10
+vdisplay b
+vfit
+vtop
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+@subsubsection occt_2142243456_44562206624 vaxo
+
+Syntax: vaxo
+
+Displays axonometric view in the 3D viewer window.
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+vinit
+box b 10 10 10
+vdisplay b
+vfit
+vaxo
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+@subsubsection occt_2142243456_44562206625 vsetbg
+
+Syntax: vsetbg imagefile [filltype]
+
+Loads image file as background. **filltype** must be **NONE, CENTERED, TILED or STRETCH**.
+**Example**
+
+vinit
+vsetbg myimage.brep CENTERED
+
+@subsubsection occt_2142243456_44562206626 vclear
+
+Syntax: vclear
+
+Removes all objects from the viewer.
+
+@subsubsection occt_2142243456_44562206627 vrepaint
+
+Syntax: vrepaint
+
+Forcedly redisplays the shape in the 3D viewer window.
+
+@subsubsection occt_2142243456_44562206628 vfit
+
+Syntax: vfit
+
+Automatic zoom/panning. Objects in the view are visualized to occupy the maximum surface.
+
+@subsubsection occt_2142243456_44562206629 vzfit
+
+Syntax: vzfit
+
+Automatic depth panning. Objects in the view are visualized to occupy the maximum 3d space.
+
+
+@subsection occt_2142243456_4456220663 AIS viewer – display commands
+
+@subsubsection occt_2142243456_44562206631 vdisplay
+
+Syntax: vdisplay name1 [name2] … [name n]
+
+Displays named objects.
+**Example**
+
+vinit
+box b 40 40 40 10 10 10
+psphere s 20
+vdisplay s b
+vfit
+
+
+@subsubsection occt_2142243456_44562206632 vdonly
+
+Syntax: vdonly [name1] … [name n]
+
+Displays only selected or named objects. If there are no selected or named objects, nothing is done.
+**Example**
+
+vinit
+box b 40 40 40 10 10 10
+psphere s 20
+vdonly b
+vfit
+@subsubsection occt_2142243456_44562206633 vdisplayall
+
+Syntax: vdisplayall
+
+Displays all created objects.
+**Example**
+
+vinit
+box b 40 40 40 10 10 10
+psphere s 20
+vdisplayall
+vfit
+@subsubsection occt_2142243456_44562206634 verase
+
+Syntax: verase [name1] [name2] … [name n]
+
+Erases some selected or named objects. If there are no selected or named objects, the whole viewer is erased.
+**Example**
+
+vinit
+box b1 40 40 40 10 10 10
+box b2 -40 -40 -40 10 10 10
+psphere s 20
+vdisplayall
+vfit
+# erase only first box
+verase b1
+# erase second box and sphere
+verase
+@subsubsection occt_2142243456_44562206635 veraseall
+
+Syntax: veraseall
+
+Erases all objects displayed in the viewer.
+**Example**
+vinit
+box b1 40 40 40 10 10 10
+box b2 -40 -40 -40 10 10 10
+psphere s 20
+vdisplayall
+vfit
+# erase only first box
+verase b1
+# erase second box and sphere
+verseall
+
+@subsubsection occt_2142243456_44562206636 vsetdispmode
+
+Syntax: vsetdispmode [name] mode(0,1,2,3)
+
+Sets display mode for all, selected or named objects.
+**mode** is **0** (**WireFrame**), **1** (**Shading**), **2** (**Quick HideLineremoval**), **3** (**Exact HideLineremoval**).
+**Example**
+
+vinit
+box b 10 10 10
+vdisplay b
+vsetdispmode 1
+vfit
+@subsubsection occt_2142243456_44562206637 vdisplaytype
+
+Syntax: vdisplaytype type
+
+Displays all objects of a given type.
+Possible **type**s are **;Point;, ;Axis;, ;Trihedron;, ;PlaneTrihedron;, ;Line;, ;Circle;, ;Plane;, ;Shape;, ;ConnectedShape;, ;MultiConn.Shape;, ;ConnectedInter.;, ;MultiConn.;, ;Constraint; **and** ;Dimension; **(see **vtypes**).
+
+@subsubsection occt_2142243456_44562206638 verasetype
+
+Syntax: verasetype type
+
+Erases all objects of a given type.
+Possible** type**s are **;Point;, ;Axis;, ;Trihedron;, ;PlaneTrihedron;, ;Line;, ;Circle;, ;Plane;, ;Shape;, ;ConnectedShape;, ;MultiConn.Shape;, ;ConnectedInter.;, ;MultiConn.;, ;Constraint; **and **;Dimension; **(see **vtypes**).
+
+@subsubsection occt_2142243456_44562206639 vtypes
+
+Syntax: vtypes
+
+Makes a list of known types and signatures in AIS.
+
+@subsubsection occt_2142243456_445622066310 vsetcolor
+
+Syntax: vsetcolor [shapename] colorname
+
+Sets color for all, selected or named shapes.
+Possible **colorname**s are **;BLACK;, ;MATRAGRAY;, ;MATRABLUE;, ;ALICEBLUE;, ;ANTIQUEWHITE;, ;ANTIQUEWHITE1;, ;ANTIQUEWHITE2;, ;ANTIQUEWHITE3;, ;ANTIQUEWHITE4;, ;AQUAMARINE1;, ;AQUAMARINE2;, ;AQUAMARINE4;, ;AZURE;, ;AZURE2;, ;AZURE3;, ;AZURE4;, ;BEIGE;, ;BISQUE;, ;BISQUE2;, ;BISQUE3;, ;BISQUE4;, ;BLANCHEDALMOND;, ;BLUE1;, ;BLUE2;, ;BLUE3;, ;BLUE4;, ;BLUEVIOLET;, ;BROWN;, ;BROWN1;, ;BROWN2;, ;BROWN3;, ;BROWN4;, ;BURLYWOOD;, ;BURLYWOOD1;, ;BURLYWOOD2;, ;BURLYWOOD3;, ;BURLYWOOD4;, ;CADETBLUE;, ;CADETBLUE1;, ;CADETBLUE2;, ;CADETBLUE3;, ;CADETBLUE4;, ;CHARTREUSE;, ;CHARTREUSE1;, ;CHARTREUSE2;, ;CHARTREUSE3;, ;CHARTREUSE4;, ;CHOCOLATE;, ;CHOCOLATE1;, ;CHOCOLATE2;, ;CHOCOLATE3;, ;CHOCOLATE4;, ;CORAL;, ;CORAL1;, ;CORAL2;, ;CORAL3;, ;CORAL4;, ;CORNFLOWERBLUE;, ;CORNSILK1;, ;CORNSILK2;, ;CORNSILK3;, ;CORNSILK4;, ;CYAN1;, ;CYAN2;, ;CYAN3;, ;CYAN4;, ;DARKGOLDENROD;, ;DARKGOLDENROD1;, ;DARKGOLDENROD2;, ;DARKGOLDENROD3;, ;DARKGOLDENROD4;, ;DARKGREEN;, ;DARKKHAKI;, ;DARKOLIVEGREEN;, ;DARKOLIVEGREEN1;, ;DARKOLIVEGREEN2;, ;DARKOLIVEGREEN3;, ;DARKOLIVEGREEN4;, ;DARKORANGE;, ;DARKORANGE1;, ;DARKORANGE2;, ;DARKORANGE3;, ;DARKORANGE4;, ;DARKORCHID;, ;DARKORCHID1;, ;DARKORCHID2;, ;DARKORCHID3;, ;DARKORCHID4;, ;DARKSALMON;, ;DARKSEAGREEN;, ;DARKSEAGREEN1;, ;DARKSEAGREEN2;, ;DARKSEAGREEN3;, ;DARKSEAGREEN4;, ;DARKSLATEBLUE;, ;DARKSLATEGRAY1;, ;DARKSLATEGRAY2;, ;DARKSLATEGRAY3;, ;DARKSLATEGRAY4;, ;DARKSLATEGRAY;, ;DARKTURQUOISE;, ;DARKVIOLET;, ;DEEPPINK;, ;DEEPPINK2;, ;DEEPPINK3;, ;DEEPPINK4;, ;DEEPSKYBLUE1;, ;DEEPSKYBLUE2;, ;DEEPSKYBLUE3;, ;DEEPSKYBLUE4;, ;DODGERBLUE1;, ;DODGERBLUE2;, ;DODGERBLUE3;, ;DODGERBLUE4;, ;FIREBRICK;, ;FIREBRICK1;, ;FIREBRICK2;, ;FIREBRICK3;, ;FIREBRICK4;, ;FLORALWHITE;, ;FORESTGREEN;, ;GAINSBORO;, ;GHOSTWHITE;, ;GOLD;, ;GOLD1;, ;GOLD2;, ;GOLD3;, ;GOLD4;, ;GOLDENROD;, ;GOLDENROD1;, ;GOLDENROD2;, ;GOLDENROD3;, ;GOLDENROD4;, ;GRAY;, ;GRAY0;, ;GRAY1;, ;GRAY10;, ;GRAY11;, ;GRAY12;, ;GRAY13;, ;GRAY14;, ;GRAY15;, ;GRAY16;, ;GRAY17;, ;GRAY18;, ;GRAY19;, ;GRAY2;, ;GRAY20;, ;GRAY21;, ;GRAY22;, ;GRAY23;, ;GRAY24;, ;GRAY25;, ;GRAY26;, ;GRAY27;, ;GRAY28;, ;GRAY29;, ;GRAY3;, ;GRAY30;, ;GRAY31;, ;GRAY32;, ;GRAY33;, ;GRAY34;, ;GRAY35;, ;GRAY36;, ;GRAY37;, ;GRAY38;, ;GRAY39;, ;GRAY4;, ;GRAY40;, ;GRAY41;, ;GRAY42;, ;GRAY43;, ;GRAY44;, ;GRAY45;, ;GRAY46;, ;GRAY47;, ;GRAY48;, ;GRAY49;, ;GRAY5;, ;GRAY50;, ;GRAY51;, ;GRAY52;, ;GRAY53;, ;GRAY54;, ;GRAY55;, ;GRAY56;, ;GRAY57;, ;GRAY58;, ;GRAY59;, ;GRAY6;, ;GRAY60;, ;GRAY61;, ;GRAY62;, ;GRAY63;, ;GRAY64;, ;GRAY65;, ;GRAY66;, ;GRAY67;, ;GRAY68;, ;GRAY69;, ;GRAY7;, ;GRAY70;, ;GRAY71;, ;GRAY72;, ;GRAY73;, ;GRAY74;, ;GRAY75;, ;GRAY76;, ;GRAY77;, ;GRAY78;, ;GRAY79;, ;GRAY8;, ;GRAY80;, ;GRAY81;, ;GRAY82;, ;GRAY83;, ;GRAY85;, ;GRAY86;, ;GRAY87;, ;GRAY88;, ;GRAY89;, ;GRAY9;, ;GRAY90;, ;GRAY91;, ;GRAY92;, ;GRAY93;, ;GRAY94;, ;GRAY95;, ;GREEN;, ;GREEN1;, ;GREEN2;, ;GREEN3;, ;GREEN4;, ;GREENYELLOW;, ;GRAY97;, ;GRAY98;, ;GRAY99;, ;HONEYDEW;, ;HONEYDEW2;, ;HONEYDEW3;, ;HONEYDEW4;, ;HOTPINK;, ;HOTPINK1;, ;HOTPINK2;, ;HOTPINK3;, ;HOTPINK4;, ;INDIANRED;, ;INDIANRED1;, ;INDIANRED2;, ;INDIANRED3;, ;INDIANRED4;, ;IVORY;, ;IVORY2;, ;IVORY3;, ;IVORY4;, ;KHAKI;, ;KHAKI1;, ;KHAKI2;, ;KHAKI3;, ;KHAKI4;, ;LAVENDER;, ;LAVENDERBLUSH1;, ;LAVENDERBLUSH2;, ;LAVENDERBLUSH3;, ;LAVENDERBLUSH4;, ;LAWNGREEN;, ;LEMONCHIFFON1;, ;LEMONCHIFFON2;, ;LEMONCHIFFON3;, ;LEMONCHIFFON4;, ;LIGHTBLUE;, ;LIGHTBLUE1;, ;LIGHTBLUE2;, ;LIGHTBLUE3;, ;LIGHTBLUE4;, ;LIGHTCORAL;, ;LIGHTCYAN1;, ;LIGHTCYAN2;, ;LIGHTCYAN3;, ;LIGHTCYAN4;, ;LIGHTGOLDENROD;, ;LIGHTGOLDENROD1;, ;LIGHTGOLDENROD2;, ;LIGHTGOLDENROD3;, ;LIGHTGOLDENROD4;, ;LIGHTGOLDENRODYELLOW;, ;LIGHTGRAY;, ;LIGHTPINK;, ;LIGHTPINK1;, ;LIGHTPINK2;, ;LIGHTPINK3;, ;LIGHTPINK4;, ;LIGHTSALMON1;, ;LIGHTSALMON2;, ;LIGHTSALMON3;, ;LIGHTSALMON4;, ;LIGHTSEAGREEN;, ;LIGHTSKYBLUE;, ;LIGHTSKYBLUE1;, ;LIGHTSKYBLUE2;, ;LIGHTSKYBLUE3;, ;LIGHTSKYBLUE4;, ;LIGHTSLATEBLUE;, ;LIGHTSLATEGRAY;, ;LIGHTSTEELBLUE;, ;LIGHTSTEELBLUE1;, ;LIGHTSTEELBLUE2;, ;LIGHTSTEELBLUE3;, ;LIGHTSTEELBLUE4;, ;LIGHTYELLOW;, ;LIGHTYELLOW2;, ;LIGHTYELLOW3;, ;LIGHTYELLOW4;, ;LIMEGREEN;, ;LINEN;, ;MAGENTA1;, ;MAGENTA2;, ;MAGENTA3;, ;MAGENTA4;, ;MAROON;, ;MAROON1;, ;MAROON2;, ;MAROON3;, ;MAROON4;, ;MEDIUMAQUAMARINE;, ;MEDIUMORCHID;, ;MEDIUMORCHID1;, ;MEDIUMORCHID2;, ;MEDIUMORCHID3;, ;MEDIUMORCHID4;, ;MEDIUMPURPLE;, ;MEDIUMPURPLE1;, ;MEDIUMPURPLE2;, ;MEDIUMPURPLE3;, ;MEDIUMPURPLE4;, ;MEDIUMSEAGREEN;, ;MEDIUMSLATEBLUE;, ;MEDIUMSPRINGGREEN;, ;MEDIUMTURQUOISE;, ;MEDIUMVIOLETRED;, ;MIDNIGHTBLUE;, ;MINTCREAM;, ;MISTYROSE;, ;MISTYROSE2;, ;MISTYROSE3;, ;MISTYROSE4;, ;MOCCASIN;, ;NAVAJOWHITE1;, ;NAVAJOWHITE2;, ;NAVAJOWHITE3;, ;NAVAJOWHITE4;, ;NAVYBLUE;, ;OLDLACE;, ;OLIVEDRAB;, ;OLIVEDRAB1;, ;OLIVEDRAB2;, ;OLIVEDRAB3;, ;OLIVEDRAB4;, ;ORANGE;, ;ORANGE1;, ;ORANGE2;, ;ORANGE3;, ;ORANGE4;, ;ORANGERED;, ;ORANGERED1;, ;ORANGERED2;, ;ORANGERED3;, ;ORANGERED4;, ;ORCHID;, ;ORCHID1;, ;ORCHID2;, ;ORCHID3;, ;ORCHID4;, ;PALEGOLDENROD;, ;PALEGREEN;, ;PALEGREEN1;, ;PALEGREEN2;, ;PALEGREEN3;, ;PALEGREEN4;, ;PALETURQUOISE;, ;PALETURQUOISE1;, ;PALETURQUOISE2;, ;PALETURQUOISE3;, ;PALETURQUOISE4;, ;PALEVIOLETRED;, ;PALEVIOLETRED1;, ;PALEVIOLETRED2;, ;PALEVIOLETRED3;, ;PALEVIOLETRED4;, ;PAPAYAWHIP;, ;PEACHPUFF;, ;PEACHPUFF2;, ;PEACHPUFF3;, ;PEACHPUFF4;, ;PERU;, ;PINK;, ;PINK1;, ;PINK2;, ;PINK3;, ;PINK4;, ;PLUM;, ;PLUM1;, ;PLUM2;, ;PLUM3;, ;PLUM4;, ;POWDERBLUE;, ;PURPLE;, ;PURPLE1;, ;PURPLE2;, ;PURPLE3;, ;PURPLE4;, ;RED;, ;RED1;, ;RED2;, ;RED3;, ;RED4;, ;ROSYBROWN;, ;ROSYBROWN1;, ;ROSYBROWN2;, ;ROSYBROWN3;, ;ROSYBROWN4;, ;ROYALBLUE;, ;ROYALBLUE1;, ;ROYALBLUE2;, ;ROYALBLUE3;, ;ROYALBLUE4;, ;SADDLEBROWN;, ;SALMON;, ;SALMON1;, ;SALMON2;, ;SALMON3;, ;SALMON4;, ;SANDYBROWN;, ;SEAGREEN;, ;SEAGREEN1;, ;SEAGREEN2;, ;SEAGREEN3;, ;SEAGREEN4;, ;SEASHELL;, ;SEASHELL2;, ;SEASHELL3;, ;SEASHELL4;, ;BEET;, ;TEAL;, ;SIENNA;, ;SIENNA1;, ;SIENNA2;, ;SIENNA3;, ;SIENNA4;, ;SKYBLUE;, ;SKYBLUE1;, ;SKYBLUE2;, ;SKYBLUE3;, ;SKYBLUE4;, ;SLATEBLUE;, ;SLATEBLUE1;, ;SLATEBLUE2;, ;SLATEBLUE3;, ;SLATEBLUE4;, ;SLATEGRAY1;, ;SLATEGRAY2;, ;SLATEGRAY3;, ;SLATEGRAY4;, ;SLATEGRAY;, ;SNOW;, ;SNOW2;, ;SNOW3;, ;SNOW4;, ;SPRINGGREEN;, ;SPRINGGREEN2;, ;SPRINGGREEN3;, ;SPRINGGREEN4;, ;STEELBLUE;, ;STEELBLUE1;, ;STEELBLUE2;, ;STEELBLUE3;, ;STEELBLUE4;, ;TAN;, ;TAN1;, ;TAN2;, ;TAN3;, ;TAN4;, ;THISTLE;, ;THISTLE1;, ;THISTLE2;, ;THISTLE3;, ;THISTLE4;, ;TOMATO;, ;TOMATO1;, ;TOMATO2;, ;TOMATO3;, ;TOMATO4;, ;TURQUOISE;, ;TURQUOISE1;, ;TURQUOISE2;, ;TURQUOISE3;, ;TURQUOISE4;, ;VIOLET;, ;VIOLETRED;, ;VIOLETRED1;, ;VIOLETRED2;, ;VIOLETRED3;, ;VIOLETRED4;, ;WHEAT;, ;WHEAT1;, ;WHEAT2;, ;WHEAT3;, ;WHEAT4;, ;WHITE;, ;WHITESMOKE;, ;YELLOW;, ;YELLOW1;, ;YELLOW2;, ;YELLOW3;, ;YELLOW4; and ;YELLOWGREEN;**.
+
+
+
+@subsubsection occt_2142243456_445622066311 vunsetcolor
+
+Syntax: vunsetcolor [shapename]
+
+Sets default color for all, selected or named shapes.
+
+@subsubsection occt_2142243456_445622066312 vsettransparency
+
+Syntax: vsettransparency [shapename] coeficient
+
+Sets transparency for all selected or named shapes. The **Coefficient** may be between 0.0 (opaque) and 1.0 (fully transparent). Warning: at 1.0 the shape becomes invisible.
+**Example**
+
+vinit
+box b 10 10 10
+psphere s 20
+vdisplay b s
+vfit
+vsetdispmode 1
+vsettransparency b 0.5
+
+@subsubsection occt_2142243456_445622066313 vunsettransparency
+
+Syntax: vunsettransparency [shapename]
+
+Sets default transparency (0.0) for all selected or named shapes.
+
+@subsubsection occt_2142243456_445622066314 vsetmaterial
+
+Syntax: vsetmaterial [shapename] materialname
+
+Sets material for all selected or named shapes.
+**materialname** is ***BRASS*, *BRONZE*, *COPPER*, *GOLD*, *PEWTER*, *PLASTER*, *PLASTIC*, *SILVER*, *STEEL*, *STONE*, *SHINY_PLASTIC*, *SATIN*, *METALIZED*, *NEON_GNC*, *CHROME*, *ALUMINIUM*, *OBSIDIAN*, *NEON_PHC*, *JADE*.**
+**Example**
+
+vinit
+psphere s 20
+vdisplay s
+vfit
+vsetdispmode 1
+vsetmaterial s JADE
+
+@subsubsection occt_2142243456_445622066315 vunsetmaterial
+
+Syntax: vunsetmaterial [shapename]
+
+Sets default material for all selected or named shapes.
+
+@subsubsection occt_2142243456_445622066316 vsetwidth
+
+Syntax: vsetwidth [shapename] coeficient
+
+Sets width of the edges for all selected or named shapes.
+The **Coefficient** may be between 0.0 and 10.0.
+**Example**
+
+vinit
+box b 10 10 10
+vdisplay b
+vfit
+vsetwidth b 5
+
+@subsubsection occt_2142243456_445622066317 vunsetwidth
+
+Syntax: vunsetwidth [shapename]
+
+Sets default width of edges (0.0) for all selected or named shapes.
+
+@subsubsection occt_2142243456_445622066318 vsetshading
+
+Syntax: vsetshading shapename [coefficient]
+
+Sets deflection coefficient that defines the quality of the shape’s representation in the shading mode. Default coefficient is 0.0008.
+**Example**
+
+vinit
+psphere s 20
+vdisplay s
+vfit
+vsetdispmode 1
+vsetshading s 0.005
+@subsubsection occt_2142243456_445622066319 vunsetshading
+
+Syntax: vunsetshading [shapename]
+
+Sets default deflection coefficient (0.0008) that defines the quality of the shape’s representation in the shading mode. Default coefficient is 0.0008.
+
+@subsubsection occt_2142243456_445622066320 vsetam
+
+Syntax: vsetam [shapename] mode
+
+Activates selection mode for all selected or named shapes.
+**mode** is **0** for **shape** itself, **1** for **vertices**, **2** for **edges**, **3** for **wires**, **4** for **faces**, **5** for **shells**, **6** for **solids**, **7** for **compounds**.
+**Example**
+
+vinit
+box b 10 10 10
+vdisplay b
+vfit
+vsetam b 2
+@subsubsection occt_2142243456_445622066321 vunsetam
+
+Syntax: vunsetam
+
+Deactivates all selection modes for all shapes.
+
+@subsubsection occt_2142243456_445622066322 vdump
+
+Syntax: vdump filename.{png|xwd|bmp}
+
+Extracts the contents of the viewer window to a png, XWD or BMP file.
+
+@subsubsection occt_2142243456_445622066323 vdir
+
+Syntax: vdir
+
+Displays the list of displayed objects.
+
+@subsubsection occt_2142243456_445622066324 vsub
+
+Syntax: vsub 0/1(on/off)[shapename]
+
+Hilights/unhilights named or selected objects which are displayed at neutral state with subintensity color.
+**Example**
+
+vinit
+box b 10 10 10
+psphere s 20
+vdisplay b s
+vfit
+vsetdispmode 1
+vsub b 1
+
+@subsubsection occt_2142243456_445622066325 vardis
+
+Syntax: vardis
+
+Displays active areas (for each activated sensitive entity, one or several 2D bounding boxes are displayed, depending on the implementation of a particular entity).
+
+@subsubsection occt_2142243456_445622066326 varera
+
+Syntax: varera
+
+Erases active areas.
+
+@subsubsection occt_2142243456_445622066327 vsensdis
+
+Syntax: vsensdis
+
+Displays active entities (sensitive entities of one of the standard types corresponding to active selection modes).
+
+Standard entity types are those defined in Select3D package:
+ * sensitive box
+ * sensitive face
+ * sensitive curve
+ * sensitive segment
+ * sensitive circle
+ * sensitive point
+ * sensitive triangulation
+ * sensitive triangle
+Custom (application-defined) sensitive entity types are not processed by this command.
+
+@subsubsection occt_2142243456_445622066328 vsensera
+
+Syntax: vsensera
+
+Erases active entities.
+
+@subsubsection occt_2142243456_445622066329 vperf
+
+Syntax: vperf shapename 1/0 (Transformation/Loacation) 1/0 (Primitives sensibles ON/OFF)
+
+Tests the animation of an object along a predefined trajectory.
+**Example**
+
+vinit
+box b 10 10 10
+psphere s 20
+vdisplay b s
+vfit
+vsetdispmode 0
+vperf b 1 1
+@subsubsection occt_2142243456_445622066330 vr
+
+Syntax: vr filename
+
+Reads shape from BREP-format file and displays it in the viewer.
+**Example**
+
+vinit
+vr myshape.brep
+@subsubsection occt_2142243456_445622066330331 vstate
+
+Syntax: vstate [name1] … [name n]
+
+Makes a list of the status (**Displayed** or **Not Displayed**) of some selected or named objects.
+
+
+
+@subsection occt_2142243456_4456220663304 AIS viewer – object commands
+
+@subsubsection occt_2142243456_44562206633041 vtrihedron
+
+Syntax: vtrihedron name [X0] [Y0] [Z0] [Zu] [Zv] [Zw] [Xu] [Xv] [Xw]
+
+Creates a new AIS_Trihedron object. If no argument is set, the default trihedron (0XYZ) is created.
+**Example**
+
+vinit
+vtrihedron tr
+
+@subsubsection occt_2142243456_44562206633042 vplanetri
+
+Syntax: vplanetri name
+
+Creates a plane from a trihedron selection.
+
+
+@subsubsection occt_2142243456_44562206633043 vsize
+
+Syntax: vsize [name] [size]
+
+Changes the size of a named or selected trihedron. If the name is not defined: it affects the selected trihedrons otherwise nothing is done. If the value is not defined, it is set to 100 by default.
+**Example**
+
+vinit
+vtrihedron tr1
+vtrihedron tr2 0 0 0 1 0 0 1 0 0
+vsize tr2 400
+
+@subsubsection occt_2142243456_44562206633044 vaxis
+
+Syntax: vaxis name [Xa Ya Za Xb Yb Zb]
+
+Creates an axis. If the values are not defined, an axis is created by interactive selection of two vertices or one edge
+**Example**
+
+vinit
+vtrihedron tr
+vaxis axe1 0 0 0 1 0 0
+
+@subsubsection occt_2142243456_44562206633045 vaxispara
+
+Syntax: vaxispara nom
+
+Creates an axis by interactive selection of an edge and a vertex.
+
+@subsubsection occt_2142243456_44562206633046 vaxisortho
+
+Syntax: vaxisotrho name
+
+Creates an axis by interactive selection of an edge and a vertex. The axis will be orthogonal to the selected edge.
+
+@subsubsection occt_2142243456_44562206633047 vpoint
+
+Syntax: vpoint name [Xa Ya Za]
+
+Creates a point from coordinates. If the values are not defined, a point is created by interactive selection of a vertice or an edge (in the center of the edge).
+**Example**
+
+vinit
+vpoint p 0 0 0
+
+@subsubsection occt_2142243456_44562206633048 vplane
+
+Syntax: vplane name [AxisName] [PointName]
+ vplane name [PointName] [PointName] [PointName]
+ vplane name [PlaneName] [PointName]
+
+Creates a plane from named or interactively selected entities.
+**Example**
+
+vinit
+vpoint p1 0 50 0
+vaxis axe1 0 0 0 0 0 1
+vtrihedron tr
+vplane plane1 axe1 p1
+
+@subsubsection occt_2142243456_44562206633049 vplanepara
+
+Syntax: vplanepara name
+
+Creates a plane from interactively selected vertex and face.
+
+@subsubsection occt_2142243456_445622066330410 vplaneortho
+
+Syntax: vplaneortho name
+
+Creates a plane from interactive selected face and coplanar edge.
+
+@subsubsection occt_2142243456_445622066330411 vline
+
+Syntax: vline name [PointName] [PointName]
+ vline name [Xa Ya Za Xb Yb Zb]
+
+Creates a line from coordinates, named or interactively selected vertices.
+**Example**
+
+vinit
+vtrihedron tr
+vpoint p1 0 50 0
+vpoint p2 50 0 0
+vline line1 p1 p2
+vline line2 0 0 0 50 0 1
+
+@subsubsection occt_2142243456_445622066330412 vcircle
+
+Syntax: vcircle name [PointName PointName PointName IsFilled]
+vcircle name [PlaneName PointName Radius IsFilled]
+
+Creates a circle from named or interactively selected entities. Parameter IsFilled is defined as 0 or 1.
+**Example**
+
+vinit
+vtrihedron tr
+vpoint p1 0 50 0
+vpoint p2 50 0 0
+vpoint p3 0 0 0
+vcircle circle1 p1 p2 p3 1
+
+
+@subsubsection occt_2142243456_445622066330413 vtri2d
+
+Syntax: vtri2d name
+
+Creates a plane with a 2D trihedron from an interactively selected face.
+
+@subsubsection occt_2142243456_445622066330414 vselmode
+
+Syntax: vselmode [object] mode On/Off
+
+Sets the selection mode for an object. If the object value is not defined, the selection mode is set for all displayed objects.
+Value On is defined as 1 and Off – as 0.
+**Example**
+
+vinit
+vpoint p1 0 0 0
+vpoint p2 50 0 0
+vpoint p3 25 40 0
+vtriangle triangle1 p1 p2 p3
+@subsubsection occt_2142243456_445622066330415 vconnect, vconnectsh
+
+Syntax: vconnect name object Xo Yo Zo Xu Xv Xw Zu Zv Zw
+ vconnectsh name shape Xo Yo Zo Xu Xv Xw Zu Zv Zw
+
+Creates and displays an object with input location connected to a named entity.
+The difference between these two commands is that the object created by vconnect does not support the selection modes differrent from 0.
+**Example**
+
+Vinitvinit
+vpoint p1 0 0 0
+vpoint p2 50 0 0
+vsegment segment p1 p2
+restore CrankArm.brep obj
+vdisplay obj
+vconnectsh new obj 100100100 1 0 0 0 0 1
+
+
+
+@subsubsection occt_2142243456_445622066330416 vtriangle
+
+Syntax: vtriangle name PointName PointName PointName
+
+Creates and displays a filled triangle from named points.
+**Example**
+
+vinit
+vpoint p1 0 0 0
+vpoint p2 50 0 0
+vpoint p3 25 40 0
+vtriangle triangle1 p1 p2 p3
+
+@subsubsection occt_2142243456_445622066330417 vsegment
+
+Syntax: vsegment name PointName PointName
+
+Creates and displays a segment from named points.
+**Example**
+
+Vinit
+vpoint p1 0 0 0
+vpoint p2 50 0 0
+vsegment segment p1 p2
+
+
+**MeshVS **(Mesh Visualization Service) component provides flexible means of displaying meshes with associated pre- and post- processor data.
+
+
+
+@subsection occt_2142243456_4456220663305 AIS viewer – Mesh Visualization Service
+
+@subsubsection occt_2142243456_44562206633051 meshfromstl
+
+Syntax: meshfromstl meshname file
+
+Creates a MeshVS_Mesh object based on STL file data. The object will be displayed immediately.
+**Example**
+
+meshfromstl mesh myfile.stl
+
+@subsubsection occt_2142243456_44562206633052 meshdispmode
+
+Syntax: meshdispmode meshname displaymode
+
+Changes the display mode of object **meshname**. The **displaymode** is integer, which can be **1** (for wireframe), **2** (for shading mode) or **3** (for shrink mode).
+**Example**
+
+vinit
+meshfromstl mesh myfile.stl
+meshdispmode mesh 2
+
+@subsubsection occt_2142243456_44562206633053 meshselmode
+
+Syntax: meshselmode meshname selectionmode
+
+Changes the selection mode of object **meshname**. The **selectionmode** is integer OR-combination of mode flags. The basic flags are the following:
+**1** – node selection,
+**2** – 0D elements (not suppored in STL)
+**4** – links (not supported in STL)
+**8** – faces
+**Example**
+
+vinit
+meshfromstl mesh myfile.stl
+meshselmode mesh 1
+
+@subsubsection occt_2142243456_44562206633054 meshshadcolor
+
+Syntax: meshshadcolor meshname red green blue
+
+Changes the face interior color of object **meshname**. The **red**, **green** and **blue** are real values between **0** and **1**.
+**Example**
+
+vinit
+meshfromstl mesh myfile.stl
+meshshadcolormode mesh 0.5 0.5 0.5
+
+@subsubsection occt_2142243456_44562206633055 meshlinkcolor
+
+Syntax: meshlinkcolor meshname red green blue
+
+Changes the color of face borders for object **meshname**. The **red**, **green** and **blue** are real values between **0** and **1**.
+**Example**
+
+vinit
+meshfromstl mesh myfile.stl
+meshlinkcolormode mesh 0.5 0.5 0.5
+
+@subsubsection occt_2142243456_44562206633056 meshmat
+
+Syntax: meshmat meshname material
+
+Changes the material of object **meshname**. **material** is represented with an integer value as follows (equivalent to enumeration Graphic3d_NameOfMaterial):
+**0 – BRASS,**
+**1 – BRONZE,**
+**2 - COPPER,**
+**3 - GOLD,**
+**4 - PEWTER,**
+**5 - PLASTER,**
+**6 - PLASTIC,**
+**7 - SILVER,**
+**8 - STEEL,**
+**9 - STONE,**
+**10 - SHINY_PLASTIC,**
+**11 - SATIN,**
+**12 - METALIZED,**
+**13 - NEON_GNC,**
+**14 - CHROME,**
+**15 - ALUMINIUM,**
+**16 - OBSIDIAN,**
+**17 - NEON_PHC,**
+**18 - JADE,**
+**19 - DEFAULT,**
+**20 - UserDefined**
+**Example**
+
+vinit
+meshfromstl mesh myfile.stl
+meshmat mesh JADE
+
+@subsubsection occt_2142243456_44562206633057 meshshrcoef
+
+Syntax: meshshrcoef meshname shrinkcoefficient
+
+Changes the value of shrink coefficient used in the shrink mode. In the shrink mode the face is shown as a congruent part of a usual face, so that **shrinkcoefficient** controls the value of this part. The **shrinkcoefficient** is a positive real number.
+**Example**
+
+vinit
+meshfromstl mesh myfile.stl
+meshshrcoef mesh 0.05
+
+@subsubsection occt_2142243456_44562206633058 meshshow
+
+Syntax: meshshow meshname
+
+Displays **meshname** in the viewer (if it is erased).
+**Example**
+
+vinit
+meshfromstl mesh myfile.stl
+meshshow mesh
+
+@subsubsection occt_2142243456_44562206633059 meshhide
+
+Syntax: meshhide meshname
+
+Hides **meshname** in the viewer.
+**Example**
+
+vinit
+meshfromstl mesh myfile.stl
+meshhide mesh
+
+@subsubsection occt_2142243456_445622066330510 meshhidesel
+
+Syntax: meshhidesel meshname
+
+Hides only selected entities. The other part of **meshname** remains visible.
+
+@subsubsection occt_2142243456_445622066330511 meshshowsel
+
+Syntax: meshshowsel meshname
+
+Shows only selected entities. The other part of **meshname** becomes invisible.
+
+@subsubsection occt_2142243456_445622066330512 meshshowall
+
+Syntax: meshshowall meshname
+
+Changes the state of all entities to visible for **meshname**.
+
+@subsubsection occt_2142243456_445622066330513 meshdelete
+
+Syntax: meshdelete meshname
+
+Deletes MeshVS_Mesh object **meshname**.
+**Example**
+
+vinit
+meshfromstl mesh myfile.stl
+meshdelete mesh
+
+
+
+
+@subsection occt_2142243456_4456220663306 AIS viewer – 2D viewer – view commands
+
+@subsubsection occt_2142243456_44562206633061 v2dinit
+
+Syntax: v2dinit
+
+**v2dinit **creates the 2D viewer window.
+
+@subsubsection occt_2142243456_44562206633062 v2dsetbg
+
+Syntax: v2dsetbg imagefile [filletype]
+
+**v2dsetbg** loads **imagefile** as background. **filletype** is **NONE**, **CENTERED**, **TILED**, **STRETCH**.
+**Example**
+
+v2dinit
+v2dsetbg myimage.brep CENTERED
+
+@subsubsection occt_2142243456_44562206633063 v2dfit
+
+Syntax: v2dfit
+
+Fits all shapes to the size of the window.
+
+@subsubsection occt_2142243456_44562206633064 v2drepaint
+
+Syntax: v2drepaint
+
+Forcedly repaints all shapes.
+
+@subsubsection occt_2142243456_44562206633065 v2dclear
+
+Syntax: v2dclear
+
+Clears the 2D viewer window
+
+@subsubsection occt_2142243456_44562206633066 v2dtext
+
+Syntax: v2dtext text x y [angle scale fontindex]
+
+Creates a new object with the name **text_i** (i – integer value) and displays **text** at the position** x**, **y.** The text can be displayed at a certain **angle**, on a certain **scale** and with a certain **fontindex**.
+Default values are: **angle=0.0, scale=1.0, fontindex=0**.
+**Example**
+
+v2dinit
+v2dtext *My text* 10 10
+@subsubsection occt_2142243456_44562206633067 v2dsettextcolor
+
+Syntax: v2dsettextcolor text_name colorindex
+
+Changes the color of **text_name** object (**name** must be an integer value).
+**Example**
+
+v2dinit
+v2dtext *My text* 10 10
+# Change color to red
+v2dsettextcolor text_0 3
+@subsubsection occt_2142243456_44562206633068 v2dpick
+
+Syntax: v2dpick
+
+Displays mouse coordinates and color after clicking the mouse button in the 2D viewer window.
+
+
+@subsubsection occt_2142243456_44562206633069 v2dgrid
+
+Syntax: v2dgrid [type x y xstep ystep angle [drawmode]]
+ v2dgrid [type x y radiusstep division angle [drawmode]]
+
+Loads a grid in the 2D viewer window.
+**type** is **Rect** or **Circ**.
+**drawmode** is **Lines**, **Points** or **None**.
+**Example**
+
+v2dinit
+v2dgrid Circ 0 0 250 12 0 Lines
+v2drmgrid
+v2dgrid Rect 0 0 200 200 0 Lines
+@subsubsection occt_2142243456_445622066330610 v2rmgrid
+
+Syntax: v2rmgrid
+
+Unloads a grid from the window.
+
+@subsubsection occt_2142243456_445622066330611 v2dpickgrid
+
+Syntax: v2dpickgrid [mouse_x mouse_y [grid_x grid_y]]
+
+Gets coordinates of a grid point near the mouse button click in the 2D viewer window and sets it to **grid_x**, **grid_y** variables.
+
+@subsubsection occt_2142243456_445622066330612 v2dpsout
+
+Syntax: v2dpsout imagefile [scale colorspace]
+ [width height [xcenter ycenter]]
+
+Exports **imagefile**. You can set its the scale, width, height and colorspace.
+**colorspace** can be **RGB, BlackAndWhite, GreyScale**.
+
+@subsubsection occt_2142243456_445622066330612613 v2ddir
+
+Syntax: v2ddir
+
+Makes aLlist of the displayed objects.
+
+
+@subsection occt_2142243456_4456220663306127 Ais viewer – 2D viewer – display commands
+
+@subsubsection occt_2142243456_44562206633061271 v2ddisplay
+
+Syntax: v2ddisplay name [projection]
+
+Projection: origin_x origin_y origin_z normal_x normal_y normal_z dx_x dx_y dx_z.
+
+Displays named objects.
+**Example**
+
+v2dinit
+box b 10 10 10
+psphere s 20
+v2ddisplay s
+v2ddisplay b
+v2dfit
+@subsubsection occt_2142243456_44562206633061272 v2ddonly
+
+Syntax: v2ddonly [name1] … [name n]
+
+Displays only selected or named objects. If there are no selected or named objects, nothing is done.
+**Example**
+
+v2dinit
+box b 10 10 10
+psphere s 20
+v2ddisplay b
+v2ddisplay s
+v2ddonly s
+v2dfit
+@subsubsection occt_2142243456_44562206633061273 v2ddisplayall
+
+Syntax: v2ddisplayall
+
+Displays all created objects.
+**Example**
+
+v2dinit
+box b 10 10 10
+psphere s 20
+v2ddisplay b
+v2ddisplay s
+v2ddonly
+v2ddisplayall
+v2dfit
+@subsubsection occt_2142243456_44562206633061274 v2derase
+
+Syntax: v2derase name1 [name2] … [name n]
+
+Erases some selected or named objects. If there are no selected or named objects, the whole viewer is erased.
+**Example**
+
+v2dinit
+box b 10 10 10
+psphere s 20
+v2ddisplay b
+v2ddisplay s
+v2derase b
+v2dfit
+@subsubsection occt_2142243456_44562206633061275 v2deraseall
+
+Syntax: v2deraseall
+
+Erases all objects displayed in the viewer.
+**Example**
+
+v2dinit
+box b 10 10 10
+psphere s 20
+v2ddisplay b
+v2ddisplay s
+v2deraseall
+v2dfit
+@subsubsection occt_2142243456_44562206633061276 v2dsetcolor
+
+Syntax: v2dsetcolor [shapename] colorname
+
+Sets color for all, selected or named shapes.
+Values of **colorname** see **vsetcolor**.
+**Example**
+
+v2dinit
+box b 10 10 10
+v2ddisplay b
+v2ddisplay s
+v2dsetcolor b RED
+v2dfit
+@subsubsection occt_2142243456_44562206633061277 v2dunsetcolor
+
+Syntax: v2dunsetcolor [shapename]
+
+Sets default color for all, selected or named shapes.
+**Example**
+
+v2dinit
+box b 10 10 10
+v2ddisplay b
+v2ddisplay s
+v2dsetcolor RED
+v2dunsetcolor b
+v2dfit
+@subsubsection occt_2142243456_44562206633061278 v2dsetbgcolor
+
+Syntax: v2dsetbgcolor colorname
+
+Sets background color.
+See **vsetcolor** for the values of **colorname.**.
+**Example**
+
+v2dinit
+box b 10 10 10
+v2ddisplay b
+v2ddisplay s
+v2dsetbgcolor RED
+v2dfit
+@subsubsection occt_2142243456_44562206633061279 v2dsetwidth
+
+Syntax: v2dsetwidth [shapename] widthenum
+
+Set width of the edges for all, selected or named shapes.
+**widthenum** may be one of: **THIN, MEDIUM, THICK, VERYTHICK**.
+**Example**
+
+v2dinit
+box b 10 10 10
+v2ddisplay b
+v2ddisplay s
+v2dsetwidth b THICK
+v2dfit
+@subsubsection occt_2142243456_445622066330612710 v2dunsetwidth
+
+Syntax: vunsetwidth [shapename]
+
+Sets default width of the edges for all, selected or named shapes.
+**Example**
+
+v2dinit
+box b 10 10 10
+v2ddisplay b
+v2ddisplay s
+v2dsetwidth THICK
+v2dunsetwidth b
+v2dfit
+
+@section occt_2142243456_930384826 OCAF commands
+
+
+This chapter contains a set of commands for Open CASCADE Technology Application Framework (OCAF).
+
+
+@subsection occt_2142243456_9303848261 Application commands
+
+
+@subsubsection occt_2142243456_93038482611 NewDocument
+
+Syntax: NewDocument docname [format]
+
+Creates a new **docname** document with MDTV-Standard or described format.
+**Example**
+
+# Create new document with default (MDTV-Standard) format
+NewDocument D
+
+# Create new document with BinOcaf format
+NewDocument D2 BinOcaf
+
+@subsubsection occt_2142243456_93038482612 IsInSession
+
+Syntax: IsInSession path
+
+**I**Returns **0**, if **path** document is managed by the application session, **1** – otherwise.
+**Example**
+
+IsInSession /myPath/myFile.std
+
+@subsubsection occt_2142243456_93038482613 ListDocuments
+
+Syntax: ListDocuments
+
+Makes a list of documents handled during the session of the application.
+
+
+@subsubsection occt_2142243456_93038482614 Open
+
+Syntax: Open path docname
+
+Retrieves the document of file **docname** in the path **path**. Overwrites the document, if it is already in session.
+**Example**
+
+Open /myPath/myFile.std D
+
+@subsubsection occt_2142243456_93038482615 Close
+
+Syntax: Close docname
+
+Closes **docname** document. The document is no longer handled by the applicative session.
+**Example**
+
+Close D
+
+@subsubsection occt_2142243456_93038482616 Save
+
+Syntax: Save docname
+
+Saves **docname** active document.
+**Example**
+
+Save D
+
+@subsubsection occt_2142243456_93038482617 SaveAs
+
+Syntax: SaveAs docname path
+
+Saves the active document in the file **docname** in the path **path**. Overwrites the file if it already exists.
+**Example**
+
+SaveAs D /myPath/myFile.std
+
+@subsection occt_2142243456_9303848262 Basic commands
+
+
+@subsubsection occt_2142243456_930384826521 Label
+
+Syntax: Label docname entry
+
+Creates the label expressed by **entry** if it does not exist.
+**Example**
+
+Label D 0:2
+
+@subsubsection occt_2142243456_930384826522 NewChild
+
+Syntax: NewChild docname [taggerlabel = Root label]
+
+Finds (or creates) a TagSource attribute located at father label of **taggerlabel** and makes a new child label.
+**Example**
+
+# Create new child of root label
+NewChild D
+
+# Create new child of existing label
+Label D 0:2
+NewChild D 0:2
+
+@subsubsection occt_2142243456_930384826523 Children
+
+Syntax: Children docname label
+
+Returns the list of attributes of **label**.
+**Example**
+
+Children D 0:2
+
+@subsubsection occt_2142243456_930384826524 ForgetAll
+
+Syntax: ForgetAll docname label
+
+Forgets all attributes of the label.
+**Example**
+
+ForgetAll D 0:2
+
+@subsection occt_2142243456_93038482653 Application commands
+
+
+@subsubsection occt_2142243456_930384826531 Main
+
+Syntax: Main docname
+
+Returns the main label of the framework.
+**Example**
+
+Main D
+
+@subsubsection occt_2142243456_930384826532 UndoLimit
+
+Syntax: UndoLimit docname [value=0]
+
+
+Sets the limit on the number of Undo Delta stored. 0 will disable Undo on the document. A negative **value** means that there is no limit. Note that by default Undo is disabled. Enabling it will take effect with the next call to NewCommand. Of course, this limit is the same for Redo
+**Example**
+
+UndoLimit D 100
+
+@subsubsection occt_2142243456_930384826533 Undo
+
+Syntax: Undo docname [value=1]
+
+Undoes **value** steps.
+**Example**
+
+Undo D
+
+@subsubsection occt_2142243456_930384826534 Redo
+
+Syntax: Redo docname [value=1]
+
+Redoes **value** steps.
+**Example**
+
+Redo D
+
+@subsubsection occt_2142243456_930384826535 OpenCommand
+
+Syntax: OpenCommand docname
+
+Opens a new command transaction.
+**Example**
+
+OpenCommand D
+
+@subsubsection occt_2142243456_930384826536 CommitCommand
+
+Syntax: CommitCommand docname
+
+Commits the Command transaction.
+**Example**
+
+CommitCommand D
+
+@subsubsection occt_2142243456_930384826537 NewCommand
+
+Syntax: NewCommand docname
+
+This is a short-cut for Commit and Open transaction.
+**Example**
+
+NewCommand D
+
+@subsubsection occt_2142243456_930384826538 AbortCommand
+
+Syntax: AbortCommand docname
+
+Aborts the Command transaction.
+**Example**
+
+AbortCommand D
+
+@subsubsection occt_2142243456_930384826539 Copy
+
+Syntax: Copy docname entry Xdocname Xentry
+
+Copies the contents of **entry** to **Xentry**. No links are registred.
+**Example**
+
+Copy D1 0:2 D2 0:4
+
+@subsubsection occt_2142243456_9303848265310 UpdateLink
+
+Syntax: UpdateLink docname [entry]
+
+Updates external reference set at **entry**.
+**Example**
+
+UpdateLink D
+
+@subsubsection occt_2142243456_9303848265311 CopyWithLink
+
+Syntax: CopyWithLink docname entry Xdocname Xentry
+
+Aborts the Command transaction.
+Copies the content of **entry** to **Xentry**. The link is registred with an Xlink attribute at ** Xentry** label.
+**Example**
+
+CopyWithLink D1 0:2 D2 0:4
+
+@subsubsection occt_2142243456_9303848265312 UpdateXLinks
+
+Syntax: UpdateXLinks docname entry
+
+Sets modifications on labels impacted by external references to the **entry**. The **document** becomes invalid and must be recomputed
+**Example**
+
+UpdateXLinks D 0:2
+
+@subsubsection occt_2142243456_9303848265313 DumpDocument
+
+Syntax: DumpDocument docname
+
+Displays parameters of **docname** document.
+**Example**
+
+DumpDocument D
+
+@subsection occt_2142243456_93038482654 Data Framework commands
+
+
+@subsubsection occt_2142243456_930384826541 MakeDF
+
+Syntax: MakeDF dfname
+
+Creates a new data framework.
+**Example**
+
+MakeDF D
+
+@subsubsection occt_2142243456_930384826542 ClearDF
+
+Syntax: ClearDF dfname
+
+Clears a data framework.
+**Example**
+
+ClearDF D
+
+@subsubsection occt_2142243456_930384826543 CopyDF
+
+Syntax: CopyDF dfname1 entry1 [dfname2] entry2
+
+Copies a data framework.
+**Example**
+
+CopyDF D 0:2 0:4
+
+@subsubsection occt_2142243456_930384826544 CopyLabel
+
+Syntax: CopyLabel dfname fromlabel tolablel
+
+Copies a label.
+**Example**
+
+CopyLabel D1 0:2 0:4
+
+@subsubsection occt_2142243456_930384826545 MiniDumpDF
+
+Syntax: MiniDumpDF dfname
+
+Makes a mini-dump of a data framework.
+**Example**
+
+MiniDumpDF D
+
+@subsubsection occt_2142243456_930384826546 XDumpDF
+
+Syntax: XDumpDF dfname
+
+Makes an extended dump of a data framework.
+**Example**
+
+XDumpDF D
+
+@subsection occt_2142243456_93038482655 General attributes commands
+
+
+@subsubsection occt_2142243456_930384826551 SetInteger
+
+Syntax: SetInteger dfname entry value
+
+Finds or creates an Integer attribute at **entry** label and sets **value**.
+**Example**
+
+SetInteger D 0:2 100
+
+@subsubsection occt_2142243456_930384826552 GetInteger
+
+Syntax: GetInteger dfname entry [drawname]
+
+Gets a value of an Integer attribute at **entry** label and sets it to **drawname** variable, if it is defined.
+**Example**
+
+GetInteger D 0:2 Int1
+
+@subsubsection occt_2142243456_930384826553 SetReal
+
+Syntax: SetReal dfname entry value
+
+Finds or creates a Real attribute at **entry** label and sets **value**.
+**Example**
+
+SetReal D 0:2 100.
+
+@subsubsection occt_2142243456_930384826554 GetReal
+
+Syntax: GetReal dfname entry [drawname]
+
+Gets a value of a Real attribute at **entry** label and sets it to **drawname** variable, if it is defined.
+**Example**
+
+GetReal D 0:2 Real1
+
+@subsubsection occt_2142243456_930384826555 SetIntArray
+
+Syntax: SetIntArray dfname entry lower upper value1 value2 …
+
+Finds or creates an IntegerArray attribute at **entry** label with lower and upper bounds and sets **value1, **.** value2…**
+**Example**
+
+SetIntArray D 0:2 1 4 100 200 300 400
+
+@subsubsection occt_2142243456_930384826556 GetIntArray
+
+Syntax: GetIntArray dfname entry
+
+Gets a value of an IntegerArray attribute at **entry** label.
+**Example**
+
+GetIntArray D 0:2
+
+@subsubsection occt_2142243456_930384826557 SetRealArray
+
+Syntax: SetRealArray dfname entry lower upper value1 value2 …
+
+Finds or creates a RealArray attribute at **entry** label with lower and upper bounds and sets **value1, **.** value2…**
+**Example**
+
+GetRealArray D 0:2 1 4 100. 200. 300. 400.
+
+@subsubsection occt_2142243456_930384826558 GetRealArray
+
+Syntax: GetRealArray dfname entry
+
+Gets a value of a RealArray attribute at **entry** label.
+**Example**
+
+GetRealArray D 0:2
+
+@subsubsection occt_2142243456_930384826559 SetComment
+
+Syntax: SetComment dfname entry value
+
+Finds or creates a Comment attribute at **entry** label and sets **value**.
+**Example**
+
+SetComment D 0:2 *My comment*
+
+@subsubsection occt_2142243456_9303848265510 GetComment
+
+Syntax: GetComment dfname entry
+
+Gets a value of a Comment attribute at **entry** label.
+**Example**
+
+GetComment D 0:2
+
+@subsubsection occt_2142243456_9303848265511 SetExtStringArray
+
+Syntax: SetExtStringArray dfname entry lower upper value1 value2 …
+
+Finds or creates an ExtStringArray attribute at **entry** label with lower and upper bounds and sets **value1, **.** value2…**
+**Example**
+
+SetExtStringArray D 0:2 1 3 *string1* *string2* *string3*
+
+@subsubsection occt_2142243456_9303848265512 GetExtStringArray
+
+Syntax: GetExtStringArray dfname entry
+
+Gets a value of an ExtStringArray attribute at **entry** label.
+**Example**
+
+GetExtStringArray D 0:2
+
+@subsubsection occt_2142243456_9303848265513 SetName
+
+Syntax: SetName dfname entry value
+
+Finds or creates a Name attribute at **entry** label and set **value**.
+**Example**
+
+SetName D 0:2 *My name*
+
+@subsubsection occt_2142243456_9303848265514 GetName
+
+Syntax: GetName dfname entry
+
+Gets a value of a Name attribute at **entry** label.
+**Example**
+
+GetName D 0:2
+
+@subsubsection occt_2142243456_9303848265515 SetReference
+
+Syntax: SetReference dfname entry reference
+
+Creates a Reference attribute at **entry** label and sets **reference**.
+**Example**
+
+SetReference D 0:2 0:4
+
+@subsubsection occt_2142243456_9303848265516 GetReference
+
+Syntax: GetReference dfname entry
+
+Gets a value of a Reference attribute at **entry** label.
+**Example**
+
+GetReference D 0:2
+
+@subsubsection occt_2142243456_9303848265517 SetUAttribute
+
+Syntax: SetUAttribute dfname entry localGUID
+
+Creates a UAttribute attribute at **entry** label with **localGUID**.
+**Example**
+
+set localGUID *c73bd076-22ee-11d2-acde-080009dc4422*
+SetUAttribute D 0:2 ${localGUID}
+
+@subsubsection occt_2142243456_9303848265518 GetUAttribute
+
+Syntax: GetUAttribute dfname entry loacalGUID
+
+Finds a UAttribute at **entry** label with **localGUID**.
+**Example**
+
+set localGUID *c73bd076-22ee-11d2-acde-080009dc4422*
+GetUAttribute D 0:2 ${localGUID}
+
+@subsubsection occt_2142243456_9303848265519 SetFunction
+
+Syntax: SetFunction dfname entry ID failure
+
+Finds or creates a Function attribute at **entry** label with driver ID and **failure** index.
+**Example**
+
+set ID *c73bd076-22ee-11d2-acde-080009dc4422*
+SetFunction D 0:2 ${ID} 1
+
+@subsubsection occt_2142243456_9303848265520 GetFunction
+
+Syntax: GetFunction dfname entry ID failure
+
+Finds a Function attribute at **entry** label and sets driver ID to **ID** variable and failure index to **failure** variable.
+**Example**
+
+GetFunction D 0:2 ID failure
+
+@subsubsection occt_2142243456_9303848265521 NewShape
+
+Syntax: NewShape dfname entry [shape]
+
+
+Finds or creates a Shape attribute at **entry** label. Creates or updates the associated NamedShape attribute by **shape** if **shape** is defined.
+**Example**
+
+box b 10 10 10
+NewShape D 0:2 b
+
+@subsubsection occt_2142243456_9303848265522 SetShape
+
+Syntax: SetShape dfname entry shape
+
+Creates or updates a NamedShape attribute at **entry** label by **shape**.
+**Example**
+
+box b 10 10 10
+SetShape D 0:2 b
+
+@subsubsection occt_2142243456_9303848265523 GetShape
+
+Syntax: GetShape2 dfname entry shape
+
+Sets a shape from NamedShape attribute associated with **entry** label to **shape** draw variable.
+**Example**
+
+GetShape2 D 0:2 b
+
+@subsection occt_2142243456_93038482656 Geometric attributes commands
+
+
+@subsubsection occt_2142243456_930384826561 SetPoint
+
+Syntax: SetPoint dfname entry point
+
+Finds or creates a Point attribute at **entry** label and sets **point** as generated in the associated NamedShape attribute.
+**Example**
+
+point p 10 10 10
+SetPoint D 0:2 p
+
+@subsubsection occt_2142243456_930384826562 GetPoint
+
+Syntax: GetPoint dfname entry [drawname]
+
+Gets a vertex from NamedShape attribute at **entry** label and sets it to **drawname** variable, if it is defined.
+**Example**
+
+GetPoint D 0:2 p
+
+@subsubsection occt_2142243456_930384826563 SetAxis
+
+Syntax: SetAxis dfname entry axis
+
+Finds or creates an Axis attribute at **entry** label and sets **axis** as generated in the associated NamedShape attribute.
+**Example**
+
+line l 10 20 30 100 200 300
+SetAxis D 0:2 l
+
+@subsubsection occt_2142243456_930384826564 GetAxis
+
+Syntax: GetAxis dfname entry [drawname]
+
+Gets a line from NamedShape attribute at **entry** label and sets it to **drawname** variable, if it is defined.
+**Example**
+
+GetAxis D 0:2 l
+
+@subsubsection occt_2142243456_930384826565 SetPlane
+
+Syntax: SetPlane dfname entry plane
+
+Finds or creates a Plane attribute at **entry** label and sets **plane** as generated in the associated NamedShape attribute.
+**Example**
+
+plane pl 10 20 30 –1 0 0
+SetPlane D 0:2 pl
+
+@subsubsection occt_2142243456_930384826566 GetPlane
+
+Syntax: GetPlane dfname entry [drawname]
+
+Gets a plane from NamedShape attribute at **entry** label and sets it to **drawname** variable, if it is defined.
+**Example**
+
+GetPlane D 0:2 pl
+
+@subsubsection occt_2142243456_930384826567 SetGeometry
+
+Syntax: SetGeometry dfname entry [type] [shape]
+
+
+Creates a Geometry attribute at **entry** label and sets **type** and **shape** as generated in the associated NamedShape attribute if they are defined. **type** must be one of the following: **any/pnt/lin/cir/ell/spl/pln/cyl**.
+**Example**
+
+point p 10 10 10
+SetGeometry D 0:2 pnt p
+
+@subsubsection occt_2142243456_930384826568 GetGeometryType
+
+Syntax: GetGeometryType dfname entry
+
+Gets a geometry type from Geometry attribute at **entry** label.
+**Example**
+
+GetGeometryType D 0:2
+
+@subsubsection occt_2142243456_930384826569 SetConstraint
+
+Syntax: SetConstraint dfname entry keyword geometrie [geometrie …]
+ SetConstraint dfname entry *plane* geometrie
+ SetConstraint dfname entry *value* value
+
+1. Creates a Constraint attribute at **entry** label and sets **keyword** constraint between geometry(ies).
+**keyword** must be one of the following:
+**rad/dia/minr/majr/tan/par/perp/concentric/equal/dist/angle/eqrad/symm/midp/ eqdist/fix/rigid**
+or
+**from/axis/mate/alignf/aligna/axesa/facesa/round/offset**
+
+2. Sets plane for the existing constraint.
+
+3. Sets value for the existing constraint.
+**Example**
+
+SetConstraint D 0:2 *value* 5
+
+@subsubsection occt_2142243456_9303848265610 GetConstraint
+
+Syntax: GetConstraint dfname entry
+
+Dumps a Constraint attribute at **entry** label
+**Example**
+
+GetConstraint D 0:2
+
+@subsubsection occt_2142243456_9303848265611 SetVariable
+
+Syntax: SetVariable dfname entry isconstant(0/1) units
+
+Creates a Variable attribute at **entry** label and sets **isconstant** flag and **units** as a string.
+**Example**
+
+SetVariable D 0:2 1 *mm*
+
+@subsubsection occt_2142243456_9303848265612 GetVariable
+
+Syntax: GetVariable dfname entry isconstant units
+
+Gets an **isconstant** flag and **units** of a Variable attribute at **entry** label.
+**Example**
+
+GetVariable D 0:2 isconstant units
+puts *IsConstant=${isconstant}*
+puts *Units=${units}*
+
+
+@subsection occt_2142243456_93038482657 Tree attributes commands
+
+
+@subsubsection occt_2142243456_930384826571 RootNode
+
+Syntax: RootNode dfname treenodeentry [ID]
+
+Returns ultimate father of TreeNode attribute identified by its **treenodeentry** and its **ID** (or default ID, if **ID** is not defined).
+
+
+@subsubsection occt_2142243456_930384826572 SetNode
+
+Syntax: SetNode dfname treenodeentry [ID]
+
+Creates a TreeNode attribute on the **treenodeentry** label with its tree **ID** (or assigns a default ID, if the **ID** is not defined).
+
+
+@subsubsection occt_2142243456_930384826573 AppendNode
+
+Syntax: AppendNode dfname fatherentry childentry [fatherID]
+
+
+Inserts a TreeNode attribute with its tree **fatherID** (or default ID, if **fatherID** is not defined) on **childentry** as last child of **fatherentry**.
+
+
+
+
+@subsubsection occt_2142243456_930384826574 PrependNode
+
+Syntax: PrependNode dfname fatherentry childentry [fatherID]
+
+
+Inserts a TreeNode attribute with its tree **fatherID** (or default ID, if **fatherID** is not defined) on **childentry** as first child of **fatherentry**.
+
+
+@subsubsection occt_2142243456_930384826575 InsertNodeBefore
+
+Syntax: InsertNodeBefore dfname treenodeentry beforetreenode [ID]
+
+Inserts a TreeNode attribute with tree **ID** (or default ID, if **ID** is not defined) **beforetreenode** before **treenodeentry**.
+
+
+@subsubsection occt_2142243456_930384826576 InsertNodeAfter
+
+Syntax: InsertNodeAfter dfname treenodeentry aftertreenode [ID]
+
+Inserts a TreeNode attribute with tree **ID** (or default ID, if **ID** is not defined) **aftertreenode** after **treenodeentry**.
+
+
+@subsubsection occt_2142243456_930384826577 DetachNode
+
+Syntax: DetachNode dfname treenodeentry [ID]
+
+Removes a TreeNode attribute with tree **ID** (or default ID, if **ID** is not defined) from **treenodeentry**.
+
+
+@subsubsection occt_2142243456_930384826578 ChildNodeIterate
+
+Syntax: ChildNodeIterate dfname treenodeentry alllevels(0/1) [ID]
+
+
+Iterates on the tree of TreeNode attributes with tree **ID** (or default ID, if **ID** is not defined). If **alllevels** is set to **1** it explores not only the first, but all the sub Step levels.
+**Example**
+
+Label D 0:2
+Label D 0:3
+Label D 0:4
+Label D 0:5
+Label D 0:6
+Label D 0:7
+Label D 0:8
+Label D 0:9
+
+# Set root node
+SetNode D 0:2
+
+AppendNode D 0:2 0:4
+AppendNode D 0:2 0:5
+PrependNode D 0:4 0:3
+PrependNode D 0:4 0:8
+PrependNode D 0:4 0:9
+
+InsertNodeBefore D 0:5 0:6
+InsertNodeAfter D 0:4 0:7
+
+DetachNode D 0:8
+
+
+# List all levels
+ChildNodeIterate D 0:2 1
+
+==0:4
+==0:9
+==0:3
+==0:7
+==0:6
+==0:5
+
+
+# List only first levels
+ChildNodeIterate D 0:2 1
+
+==0:4
+==0:7
+==0:6
+==0:5
+
+@subsubsection occt_2142243456_930384826579 InitChildNodeIterator
+
+Syntax: InitChildNodeIterator dfname treenodeentry alllevels(0/1) [ID]
+
+
+Initializes the iteration on the tree of TreeNode attributes with tree **ID** (or default ID, if **ID** is not defined). If **alllevels** is set to **1** it explores not only the first, but also all sub Step levels.
+**Example**
+
+InitChildNodeIterate D 0:5 1
+set aChildNumber 0
+for {set i 1} {$i 100} {incr i} {
+ if {[ChildNodeMore] == *TRUE*} {
+ puts *Tree node = [ChildNodeValue]*
+ incr aChildNumber
+ ChildNodeNext
+ }
+}
+puts *aChildNumber=$aChildNumber*
+
+@subsubsection occt_2142243456_9303848265710 ChildNodeMore
+
+Syntax: ChildNodeMore
+
+Returns TRUE if there is a current item in the iteration.
+
+
+@subsubsection occt_2142243456_9303848265711 ChildNodeNext
+
+Syntax: ChildNodeNext
+
+Moves to the next Item.
+
+
+@subsubsection occt_2142243456_9303848265712 ChildNodeValue
+
+Syntax: ChildNodeValue
+
+Returns the current treenode of ChildNodeIterator.
+
+
+@subsubsection occt_2142243456_9303848265713 ChildNodeNextBrother
+
+Syntax: ChildNodeNextBrother
+
+Moves to the next Brother. If there is none, goes up. This method is interesting only with ;allLevels; behavior.
+
+
+@subsection occt_2142243456_93038482658 Standard presentation commands
+
+
+@subsubsection occt_2142243456_930384826581 AISInitViewer
+
+Syntax: AISInitViewer docname
+
+Creates and sets AISViewer attribute at root label, creates AIS viewer window.
+**Example**
+
+AISInitViewer D
+
+@subsubsection occt_2142243456_930384826582 AISRepaint
+
+Syntax: AISRepaint docname
+
+Updates the AIS viewer window.
+**Example**
+
+AISRepaint D
+
+@subsubsection occt_2142243456_930384826583 AISDisplay
+
+Syntax: AISDisplay docname entry [not_update]
+
+
+Displays a presantation of AISobject from **entry** label in AIS viewer. If **not_update** is not defined then AISobject is recomputed and all visualization settings are applied.
+**Example**
+
+AISDisplay D 0:5
+
+@subsubsection occt_2142243456_930384826584 AISUpdate
+
+Syntax: AISUpdate docname entry
+
+Recomputes a presantation of AISobject from **entry** label and applies the visualization setting in AIS viewer.
+**Example**
+
+AISUpdate D 0:5
+
+@subsubsection occt_2142243456_930384826585 AISErase
+
+Syntax: AISErase docname entry
+
+Erases AISobject of **entry** label in AIS viewer.
+**Example**
+
+AISErase D 0:5
+
+@subsubsection occt_2142243456_930384826586 AISRemove
+
+Syntax: AISRemove docname entry
+
+Erases AISobject of **entry** label in AIS viewer, then AISobject is removed from AIS_InteractiveContext.
+**Example**
+
+AISRemove D 0:5
+
+@subsubsection occt_2142243456_930384826587 AISSet
+
+Syntax: AISSet docname entry ID
+
+
+Creates AISPresentation attribute at **entry** label and sets as driver ID. ID must be one of the following: **A** (axis), **C** (constraint), **NS** (namedshape), **G** (geometry), **PL** (plane), **PT** (point).
+**Example**
+
+AISSet D 0:5 NS
+
+@subsubsection occt_2142243456_930384826588 AISDriver
+
+Syntax: AISDriver docname entry [ID]
+
+
+Returns DriverGUID stored in AISPresentation attribute of an **entry** label or sets a new one. ID must be one of the following: **A** (axis), **C** (constraint), **NS** (namedshape), **G** (geometry), **PL** (plane), **PT** (point).
+**Example**
+
+# Get Driver GUID
+AISDriver D 0:5
+
+@subsubsection occt_2142243456_930384826589 AISUnset
+
+Syntax: AISUnset docname entry
+
+Deletes AISPresentation attribute (if it exists) of an **entry** label.
+**Example**
+
+AISUnset D 0:5
+
+@subsubsection occt_2142243456_9303848265810 AISTransparency
+
+Syntax: AISTransparency docname entry [transparency]
+
+Sets (if **transparency** is defined) or gets the value of transparency for AISPresentation attribute of an **entry** label.
+**Example**
+
+AISTransparency D 0:5 0.5
+
+@subsubsection occt_2142243456_9303848265811 AISHasOwnTransparency
+
+Syntax: AISHasOwnTransparency docname entry
+
+Tests AISPresentation attribute of an **entry** label by own transparency.
+**Example**
+
+AISHasOwnTransparency D 0:5
+
+@subsubsection occt_2142243456_9303848265812 AISMaterial
+
+Syntax: AISMaterial docname entry [material]
+
+
+Sets (if **material** is defined) or gets the value of transparency for AISPresentation attribute of an **entry** label. **material** is integer from 0 to 20 (see **meshmat**).
+**Example**
+
+AISMaterial D 0:5 5
+
+@subsubsection occt_2142243456_9303848265813 AISHasOwnMaterial
+
+Syntax: AISHasOwnMaterial docname entry
+
+Tests AISPresentation attribute of an **entry** label by own material.
+**Example**
+
+AISHasOwnMaterial D 0:5
+
+@subsubsection occt_2142243456_9303848265814 AISColor
+
+Syntax: AISColor docname entry [color]
+
+Sets (if **color** is defined) or gets value of color for AISPresentation attribute of an **entry** label. **color** is integer from 0 to 516 (see color names in **vsetcolor**).
+**Example**
+
+AISColor D 0:5 25
+
+@subsubsection occt_2142243456_9303848265815 AISHasOwnColor
+
+Syntax: AISHasOwnColor docname entry
+
+Tests AISPresentation attribute of an **entry** label by own color.
+**Example**
+
+AISHasOwnColor D 0:5
+
+
+
+@section occt_2142243456_1101404852 Geometry commands
+
+
+
+
+@subsection occt_2142243456_110140485261 Overview
+
+Draw provides a set of commands to test geometry libraries. These commands are found in the TGEOMETRY executable, or in any Draw executable which includes GeometryTest commands.
+
+In the context of Geometry, Draw includes the following types of variable:
+
+ * 2d and 3d points
+ * The 2d curve, which corresponds to *Curve *in *Geom2d*.
+ * The 3d curve and surface, which correspond to *Curve *and *Surface *in *Geom *<a href="#_ftn2">[2]</a>.
+Draw geometric variables never share data; the **copy **command will always make a complete copy of the content of the variable.
+
+The following topics are covered in the nine sections of this chapter:
+
+ * **Curve creation **deals with the various types of curves and how to create them.
+ * **Surface creation **deals with the different types of surfaces and how to create them.
+ * **Curve and surface modification **deals with the commands used to modify the definition of curves and surfaces, most of which concern modifications to bezier and bspline curves.
+ * **Geometric transformations **covers translation, rotation, mirror image and point scaling transformations.
+ * **Curve and Surface Analysis **deals with the commands used to compute points, derivatives and curvatures.
+ * **Intersections **presents intersections of surfaces and curves.
+ * **Approximations **deals with creating curves and surfaces from a set of points.
+ * **Constraints **concerns construction of 2d circles and lines by constraints such as tangency.
+ * **Display **describes commands to control the display of curves and surfaces.
+
+Where possible, the commands have been made broad in application, i.e. they apply to 2d curves, 3d curves and surfaces. For instance, the **circle **command may create a 2d or a 3d circle depending on the number of arguments given.
+
+Likewise, the **translate **command will process points, curves or surfaces, depending on argument type. You may not always find the specific command you are looking for in the section where you expect it to be. In that case, look in another section. The **trim **command, for example, is described in the surface section. It can, nonetheless, be used with curves as well.
+
+
+
+@subsection occt_2142243456_110140485262 Curve creation
+
+This section deals with both points and curves. Types of curves are:
+
+ * Analytical curves such as lines, circles, ellipses, parabolas, and hyperbolas.
+ * Polar curves such as bezier curves and bspline curves.
+ * Trimmed curves and offset curves made from other curves with the **trim **and **offset **commands. Because they are used on both curves and surfaces, the **trim **and **offset **commands are described in the *surface creation *section.
+ * NURBS can be created from other curves using **convert **in the *Surface Creation *section.
+ * Curves can be created from the isoparametric lines of surfaces by the **uiso **and **viso **commands.
+ * 3d curves can be created from 2d curves and vice versa using the **to3d **and **to2d **commands. The **project **command computes a 2d curve on a 3d surface.
+
+Curves are displayed with an arrow showing the last parameter.
+
+
+@subsubsection occt_2142243456_1101404852621 point
+
+Syntax: point name x y [z]
+
+**point **creates a 2d or 3d point, depending on the number of arguments.
+<h5>Example</h5>
+
+# 2d point
+point p1 1 2
+
+# 3d point
+point p2 10 20 -5
+
+
+@subsubsection occt_2142243456_1101404852622 line
+
+Syntax: line name x y [z] dx dy [dz]
+
+**line **creates a 2d or 3d line. x y z are the coordinates of the line’s point of origin; dx, dy, dz give the direction vector.
+
+A 2d line will be represented asl x y dx dy, and a 3d line asl x y z dx dy dz. A line is parameterized along its length starting from the point of origin along the direction vector. The direction vector is normalized and must not be null. Lines are infinite, even though their representation is not.
+**Example**
+
+# a 2d line at 45 degrees of the X axis
+line l 2 0 1 1
+
+# a 3d line through the point 10 0 0 and parallel to Z
+line l 10 0 0 0 0 1
+
+
+@subsubsection occt_2142243456_1101404852623 circle
+
+Syntax: circle name x y [z [dx dy dz]] [ux uy [uz]] radius
+
+**circle **creates a 2d or a 3d circle.
+
+In 2d, x, y are the coordinates of the center and ux, uy define the vector towards the point of origin of the parameters. By default, this direction is (1,0). The X Axis of the local coordinate system defines the origin of the parameters of the circle. Use another vector than the x axis to change the origin of parameters.
+
+In 3d, x, y, z are the coordinates of the center; dx, dy, dz give the vector normal to the plane of the circle. By default, this vector is (0,0,1) i.e. the Z axis (it must not be null). ux, uy, uz is the direction of the origin; if not given, a default direction will be computed. This vector must neither be null nor parallel to dx, dy, dz.
+
+The circle is parameterized by the angle in [0,2*pi] starting from the origin and. Note that the specification of origin direction and plane is the same for all analytical curves and surfaces.
+
+**Example**
+
+# A 2d circle of radius 5 centered at 10,-2
+circle c1 10 -2 5
+
+# another 2d circle with a user defined origin
+# the point of parameter 0 on this circle will be
+# 1+sqrt(2),1+sqrt(2)
+circle c2 1 1 1 1 2
+
+# a 3d circle, center 10 20 -5, axis Z, radius 17
+circle c3 10 20 -5 17
+
+# same 3d circle with axis Y
+circle c4 10 20 -5 0 1 0 17
+
+# full 3d circle, axis X, origin on Z
+circle c5 10 20 -5 1 0 0 0 0 1 17
+
+
+@subsubsection occt_2142243456_1101404852624 ellipse
+
+Syntax: ellipse name x y [z [dx dy dz]] [ux uy [uz]] firstradius secondradius **ellipse **creates a 2d or 3d ellipse. In a 2d ellipse, the first two arguments define the center; in a 3d ellipse, the first three. The axis system is given by *firstradius*, the major radius, and *secondradius*, the minor radius. The parameter range of the ellipse is [0,2.*pi] starting from the X axis and going towards the Y axis. The Draw ellipse is parameterized by an angle:
+
+P(u) = O + firstradius*cos(u)*Xdir + secondradius*sin(u)*Ydir
+
+where:
+
+ * P is the point of parameter u,
+ * O, Xdir and Ydir are respectively the origin, *X Direction* and *Y Direction* of its local coordinate system.
+<h5>Example</h5>
+
+# default 2d ellipse
+ellipse e1 10 5 20 10
+
+# 2d ellipse at angle 60 degree
+ellipse e2 0 0 1 2 30 5
+
+# 3d ellipse, in the XY plane
+ellipse e3 0 0 0 25 5
+
+# 3d ellipse in the X,Z plane with axis 1, 0 ,1
+ellipse e4 0 0 0 0 1 0 1 0 1 25 5
+
+See also: **circle**
+@subsubsection occt_2142243456_1101404852625 hyperbola
+
+Syntax: hyperbola name x y [z [dx dy dz]] [ux uy [uz]] firstradius secondradius
+
+**hyperbola **creates a 2d or 3d conic. The first arguments define the center. The axis system is given by *firstradius*, the major radius, and *secondradius*, the minor radius. Note that the hyperbola has only one branch, that in the X direction.
+
+The Draw hyperbola is parameterized as follows:
+
+P(U) = O + firstradius*Cosh(U)*XDir + secondradius*Sinh(U)*YDir
+
+where:
+
+ * P is the point of parameter U,
+ * O, XDir and YDir are respectively the origin, *X Direction* and *Y
+
+Direction* of its local coordinate system.
+**Example**
+
+# default 2d hyperbola, with asymptotes 1,1 -1,1
+hyperbola h1 0 0 30 30
+
+# 2d hyperbola at angle 60 degrees
+hyperbola h2 0 0 1 2 20 20
+
+# 3d hyperbola, in the XY plane
+hyperbola h3 0 0 0 50 50
+
+See also: **circle**
+
+
+@subsubsection occt_2142243456_1101404852626 parabola
+
+Syntax: parabola name x y [z [dx dy dz]] [ux uy [uz]] FocalLength
+
+**parabola **creates a 2d or 3d parabola. in the axis system defined by the first arguments.The origin is the apex of the parabola.
+
+The Geom_Parabola parabola is parameterized as follows:
+
+P(u) = O + u*u/(4.*F)*XDir + u*YDir
+
+where:
+ * P is the point of parameter u,
+ * O, XDir and YDir are respectively the origin, *X Direction* and *Y Direction* of its local coordinate system,
+ * F is the focal length of the parabola.
+**Example**
+
+# 2d parabola
+parabola p1 0 0 50
+
+# 2d parabola with convexity +Y
+parabola p2 0 0 0 1 50
+
+# 3d parabola in the Y-Z plane, convexity +Z
+parabola p3 0 0 0 1 0 0 0 0 1 50
+
+See also: **circle**
+
+
+@subsubsection occt_2142243456_1101404852627 beziercurve, dbeziercurve
+
+Syntax: beziercurve name nbpole pole, [weight]
+2dbeziercurve name nbpole pole, [weight]
+
+**beziercurve **creates a 3d rational or non-rational Bezier curve. Give the number of poles (control points,) and the coordinates of the poles (x1 y1 z1 [w1] x2 y2 z2 [w2]). The degree will be nbpoles-1. To create a rational curve, give weights with the poles. You must give weights for all poles or for none. If the weights of all the poles are equal, the curve is polynomial, and therefore non-rational.
+**Example**
+
+# a rational 2d bezier curve (arc of circle)
+2dbeziercurve ci 3 0 0 1 10 0 sqrt(2.)/2. 10 10 1
+
+# a 3d bezier curve, not rational
+beziercurve cc 4 0 0 0 10 0 0 10 0 10 10 10 10
+
+
+@subsubsection occt_2142243456_1101404852628 bsplinecurve, dbsplinecurve, pbsplinecurve, dpbsplinecurve
+
+Syntax: bsplinecurve name degree nbknots knot, umult pole, weight 2dbsplinecurve name degree nbknots knot, umult pole, weight pbsplinecurve name degree nbknots knot, umult pole, weight(periodic)
+2dpbsplinecurve name degree nbknots knot, umult pole, weight (periodic)
+
+**bsplinecurve **creates 2d or 3d bspline curves; the **pbsplinecurve **and **2dpbsplinecurve **commands create periodic bspline curves.
+
+A bspline curve is defined by its degree, its periodic or non-periodic nature, a table of knots and a table of poles (i.e. control points). Consequently, specify the degree, the number of knots, and for each knot, the multiplicity, for each pole, the weight. In the syntax above, the commas link the adjacent arguments which they fall between: knot and multiplicities, pole and weight.
+
+The table of knots is an increasing sequence of reals without repetition.
+Multiplicities must be lower or equal to the degree of the curve. For non-periodic curves, the first and last multiplicities can be equal to degree+1. For a periodic curve, the first and last multiplicities must be equal.
+
+The poles must be given with their weights, use weights of 1 for a non rational curve, the number of poles must be:
+
+ * For a non periodic curve: Sum of multiplicities - degree + 1
+ * For a periodic curve: Sum of multiplicities - last multiplicity
+**Example**
+
+# a bspline curve with 4 poles and 3 knots
+bsplinecurve bc 2 3 0 3 1 1 2 3 \
+10 0 7 1 7 0 7 1 3 0 8 1 0 0 7 1
+# a 2d periodic circle (parameter from 0 to 2*pi !!)
+dset h sqrt(3)/2
+2dpbsplinecurve c 2 \
+4 0 2 pi/1.5 2 pi/0.75 2 2*pi 2 \
+0 -h/3 1 \
+0.5 -h/3 0.5 \
+0.25 h/6 1 \
+0 2*h/3 0.5 \
+-0.25 h/6 1 \
+-0.5 -h/3 0.5 \
+0 -h/3 1
+
+<h4>NOTE</h4>
+*You can create the **NURBS **subset of bspline curves and*
+*surfaces by trimming analytical curves and surfaces and*
+*executing the command *convert*; see below.*
+
+
+@subsubsection occt_2142243456_1101404852629 uiso, viso
+
+Syntax: uiso name surface u
+viso name surface u
+
+Use these commands to create a U or V isoparametric curve from a surface.
+**Example**
+
+# create a cylinder and extract iso curves
+
+cylinder c 10
+uiso c1 c pi/6
+viso c2 c
+
+*NOTE*
+*Cannot be done from offset surfaces.*
+
+
+@subsubsection occt_2142243456_11014048526210 tod, tod
+
+Syntax: to3d name curve2d [plane]
+to2d name curve3d [plane]
+
+The **to3d **and **to2d **commands are used to create respectively a 3d curve from a 2d curve and a 2d curve from a 3d curve. The transformation uses a planar surface to define the XY plane in 3d (by default this plane is the default OXYplane). **to3d **always gives a correct result, but as **to2d **is not a projection, it may surprise you. It is always correct if the curve is planar and parallel to the plane of projection. The points defining the curve are projected on the plane. A circle, however, will remain a circle and will not be changed to an ellipse.
+**Example**
+
+# the following commands
+circle c 0 0 5
+plane p -2 1 0 1 2 3
+to3d c c p
+
+# will create the same circle as
+circle c -2 1 0 1 2 3 5
+
+See also: **project**
+
+
+@subsubsection occt_2142243456_11014048526211 project
+
+Syntax: project name curve3d surface
+
+**project **computes a 2d curve in the parametric space of a surface corresponding to a 3d curve. This can only be used on analytical surfaces.
+**Example**
+
+# intersect a cylinder and a plane
+# and project the resulting ellipse on the cylinder
+# this will create a 2d sinusoid-like bspline
+cylinder c 5
+plane p 0 0 0 0 1 1
+intersect i c p
+project i2d i c
+
+@subsection occt_2142243456_110140485263 Surface creation
+
+Types of surfaces are:
+
+ * Analytical surfaces: plane, cylinder, cone, sphere, torus.
+ * Polar surfaces: bezier surfaces, bspline surfaces
+ * Trimmed and Offset surfaces; see **trim**, **trimu**, **trimv**, **offset**.
+ * Surfaces produced by Revolution and Extrusion, created from curves with the **revsurf **and **extsurf**.
+ * NURBS surfaces.
+
+Surfaces are displayed with isoparametric lines. To show the parameterization, a small parametric line with a length 1/10 of V is displayed at 1/10 of U.
+
+
+@subsubsection occt_2142243456_1101404852631 plane
+
+Syntax: plane name [x y z [dx dy dz [ux uy uz]]]
+
+Uses this command to create an infinite plane. A plane is the same as a 3d coordinate system, x,y,z is the origin, dx, dy, dz is the Z direction and ux, uy, uz is the X direction. The plane is perpendicular to Z and X is the U parameter. dx,dy,dz and ux,uy,uz must not be null and not colinear. ux,uy,uz will be modified to be orthogonal to dx,dy,dz. There are default values for the coordinate system. If no arguments are given, the global system (0,0,0), (0,0,1), (1,0,0). If only the origin is given, the axes are those given by default(0,0,1), (1,0,0). If the origin and the Z axis are given, the X axis is generated perpendicular to the Z axis. Note that this definition will be used for all analytical surfaces.
+**Example**
+
+# a plane through the point 10,0,0 perpendicular to X
+# with U direction on Y
+plane p1 10 0 0 1 0 0 0 1 0
+
+# an horixontal plane with origin 10, -20, -5
+plane p2 10 -20 -5
+
+
+@subsubsection occt_2142243456_1101404852632 cylinder
+
+Syntax: cylinder name [x y z [dx dy dz [ux uy uz]]] radius
+
+A cylinder is defined by a coordinate system, and a radius. The surface generated is an infinite cylinder with the Z axis as the axis. The U parameter is the angle starting from X going in the Y direction.
+See also: **plane**
+**Example**
+
+# a cylinder on the default Z axis, radius 10
+cylinder c1 10
+
+# a cylinder, also along the Z axis but with origin 5,
+10, -3
+cylinder c2 5 10 -3 10
+
+# a cylinder through the origin and on a diagonal
+# with longitude pi/3 and latitude pi/4 (euler angles)
+dset lo pi/3. la pi/4.
+cylinder c3 0 0 0 cos(la)*cos(lo) cos(la)*sin(lo)
+sin(la) 10
+
+
+@subsubsection occt_2142243456_1101404852633 cone
+
+Syntax: cone name [x y z [dx dy dz [ux uy uz]]] semi-angle radius
+
+Creates a cone in the infinite coordinate system along the Z-axis. The radius is that of the circle at the intersection of the cone and the XY plane. The semi-angle is the angle formed by the cone relative to the axis; it should be between –90° and 90°. If the radius is 0, the vertex is the origin.
+See also: **plane**
+**Example**
+
+# a cone at 45 degrees at the origin on Z
+cone c1 45 0
+
+# a cone on axis Z with radius r1 at z1 and r2 at z2
+cone c2 0 0 z1 180.*atan2(r2-r1,z2-z1)/pi r1
+
+@subsubsection occt_2142243456_1101404852634 sphere
+
+Syntax: sphere name [x y z [dx dy dz [ux uy uz]]] radius
+
+Creates a sphere in the local coordinate system defined in the **plane **command. The sphere is centered at the origin. To parameterize the sphere, u is the angle from X to Y, between o and 2*pi. v is the angle in the half-circle at angle u in the plane containing the Z axis. v is between -pi/2 and pi/2. The poles are the points Z = +/- radius; their parameters are u,+/-pi/2 for any u in 0,2*pi.
+**Example**
+# a sphere at the origin
+sphere s1 10
+# a sphere at 10 10 10, with poles on the axis 1,1,1
+sphere s2 10 10 10 1 1 1 10
+
+See also: **plane**
+
+
+@subsubsection occt_2142243456_1101404852635 torus
+
+Syntax: torus name [x y z [dx dy dz [ux uy uz]]] major minor
+
+Creates a torus in the local coordinate system with the given major and minor radii. Z is the axis for the major radius. The major radius may be lower in value than the minor radius.
+
+To parameterize a torus, u is the angle from X to Y; v is the angle in the plane at angle u from the XY plane to Z. u and v are in 0,2*pi.
+**Example**
+
+# a torus at the origin
+torus t1 20 5
+
+# a torus in another coordinate system
+torus t2 10 5 -2 2 1 0 20 5
+
+See also: **plane**
+
+
+@subsubsection occt_2142243456_1101404852636 beziersurf
+
+Syntax: beziersurf name nbupoles nbvolpes pole, [weight]
+
+Use this command to create a bezier surface, rational or non-rational. First give the numbers of poles in the u and v directions.
+
+Then give the poles in the following order: pole(1, 1), pole(nbupoles, 1), pole(1, nbvpoles) and pole(nbupoles, nbvpoles).
+
+Weights may be omitted, but if you give one weight you must give all of them.
+**Example**
+
+# a non-rational degree 2,3 surface
+beziersurf s 3 4 \
+0 0 0 10 0 5 20 0 0 \
+0 10 2 10 10 3 20 10 2 \
+0 20 10 10 20 20 20 20 10 \
+0 30 0 10 30 0 20 30 0
+
+See also: **beziercurve**
+
+@subsubsection occt_2142243456_1101404852637 bsplinesurf, upbsplinesurf, vpbsplinesurf, uvpbsplinesurf
+
+Syntax: bsplinesurf name udegree nbuknots uknot umult ... nbvknot vknot
+vmult ... x y z w ...
+upbsplinesurf ...
+vpbsplinesurf ...
+uvpbsplinesurf ...
+
+**bsplinesurf **generates bspline surfaces. **upbsplinesurf **creates a bspline surface periodic in u; **vpbsplinesurf **creates one periodic in v; and **uvpbsplinesurf **creates one periodic in uv.
+
+The syntax is similar to the **bsplinecurve **command. First give the degree in u and the knots in u with their multiplicities, then do the same in v. The poles follow. The number of poles is the product of the number in u and the number in v. See **bsplinecurve **to compute the number of poles, the poles are first given in U as in the beziersurf command. You must give weights if the surface is rational.
+**Example**
+
+# create a bspline surface of degree 1 2
+# with two knots in U and three in V
+bsplinesurf s \
+1 2 0 2 1 2 \
+2 3 0 3 1 1 2 3 \
+0 0 0 1 10 0 5 1 \
+0 10 2 1 10 10 3 1 \
+0 20 10 1 10 20 20 1 \
+0 30 0 1 10 30 0 1
+
+See also: **bsplinecurve**, **beziersurf**, **convert**
+
+
+@subsubsection occt_2142243456_1101404852638 trim, trimu, trimv
+
+Syntax: trim newname name [u1 u2 [v1 v2]]
+trimu newname name
+trimv newname name
+
+The **trim **commands create trimmed curves or trimmed surfaces. Note that trimmed curves and surfaces are classes of the *Geom *package. The **trim **command creates either a new trimmed curve from a curve or a new trimmed surface in u and v from a surface. **trimu **creates a u-trimmed surface, and **trimv **a v-trimmed surface. After an initial trim, a second execution with no parameters given recreates the basis curve. The curves can be either 2d or 3d. If the trimming parameters decrease and if the curve or surface is not periodic, the direction is reversed.
+<h4>NOTE</h4>
+*Note that a trimmed curve or surface contains a copy of the*
+*basis geometry: modifying that will not modify the trimmed*
+*geometry. Trimming trimmed geometry will not create*
+*multiple levels of trimming. The basis geometry will be used.*
+**Example**
+
+# create a 3d circle
+circle c 0 0 0 10
+
+# trim it, use the same variable, the original is
+deleted
+trim c c 0 pi/2
+
+# the original can be recovered!
+trim orc c
+
+# trim again
+trim c c pi/4 pi/2
+
+# the original is not the trimmed curve but the basis
+trim orc c
+
+# as the circle is periodic, the two following commands
+are identical
+trim cc c pi/2 0
+trim cc c pi/2 2*pi
+
+# trim an infinite cylinder
+cylinder cy 10
+trimv cy cy 0 50
+
+See also: **reverse**
+
+
+@subsubsection occt_2142243456_1101404852639 offset
+
+Syntax: offset name basename distance [dx dy dz]
+
+Creates offset curves or surfaces at a given distance from a basis curve or surface. Offset curves and surfaces are classes from the *Geom *package.
+
+The curve can be a 2d or a 3d curve. To compute the offsets for a 3d curve, you must also give a vector dx,dy,dz. For a planar curve, this vector is usually the normal to the plane containing the curve.
+
+The offset curve or surface copies the basic geometry, which can be modified later.
+**Example**
+
+# graphic demonstration that the outline of a torus
+# is the offset of an ellipse
+smallview +X+Y
+dset angle pi/6
+torus t 0 0 0 0 cos(angle) sin(angle) 50 20
+fit
+ellipse e 0 0 0 50 50*sin(angle)
+# note that the distance can be negative
+offset l1 e 20 0 0 1
+@subsubsection occt_2142243456_11014048526310 revsurf
+
+Syntax: revsurf name curvename x y z dx dy dz
+
+Creates a surface of revolution from a 3d curve. A surface of revolution or revolved surface is obtained by rotating a curve (called the *meridian*) through a complete revolution about an axis (referred to as the *axis of revolution*). The curve and the axis must be in the same plane (the *reference plane* of the surface). Give the point of origin x,y,z and the vector dx,dy,dz to define the axis of revolution. To parameterize a surface of revolution: u is the angle of rotation around the axis. Its origin is given by the position of the meridian on the surface. v is the parameter of the meridian.
+**Example**
+
+# another way of creating a torus like surface
+circle c 50 0 0 20
+revsurf s c 0 0 0 0 1 0
+
+
+@subsubsection occt_2142243456_11014048526311 extsurf
+
+Syntax: extsurf newname curvename dx dy dz
+
+Use the **extsurf **command to create a surface of linear extrusion from a 3d curve. The basis curve is swept in a given direction,the *direction of extrusion* defined by a vector. In the syntax, dx,dy,dz gives the direction of extrusion. To parameterize a surface of extrusion: u is the parameter along the extruded curve; the v parameter is along the direction of extrusion.
+**Example**
+
+# an elliptic cylinder
+ellipse e 0 0 0 10 5
+extsurf s e 0 0 1
+# to make it finite
+trimv s s 0 10
+
+
+@subsubsection occt_2142243456_11014048526312 convert
+
+Syntax: convert newname name
+
+**convert **creates a 2d or 3d NURBS curve or a NURBS surface from any 2d curve, 3d curve or surface. In other words, conics, beziers and bsplines are turned into NURBS. Offsets are not processed.
+**Example**
+
+# turn a 2d arc of a circle into a 2d NURBS
+circle c 0 0 5
+trim c c 0 pi/3
+convert c1 c
+
+# an easy way to make a planar bspline surface
+plane p
+trim p p -1 1 -1 1
+convert p1 p
+
+<h4>NOTE</h4>
+*Offset curves and surfaces are not treated by this command.*
+
+
+
+@subsection occt_2142243456_110140485264 Curve and surface modifications
+
+Draw provides commands to modify curves and surfaces, some of them are general, others restricted to bezier curves or bsplines.
+
+General modifications:
+
+ * Reversing the parametrization: **reverse**, **ureverse**, **vreverse**
+
+Modifications for both bezier curves and bsplines:
+
+ * Exchanging U and V on a surface: **exchuv**
+ * Segmentation: **segment**, **segsur**
+ * Increasing the degree: **incdeg**, **incudeg**, **incvdeg**
+ * Moving poles: **cmovep**, **movep**, **movecolp**, **moverowp**
+
+Modifications for bezier curves:
+
+ * Adding and removing poles: **insertpole**, **rempole**, **remcolpole**, **remrowpole**
+
+Modifications for bspline:
+
+ * Inserting and removing knots: **insertknot**, **remknot**, **insertuknot**, **remuknot**, **insetvknot**, **remvknot**
+ * Modifying periodic curves and surfaces: **setperiodic**, **setnotperiodic**, **setorigin**, **setuperiodic**, **setunotperiodic**, **setuorigin**, **setvperiodic**, **setvnotperiodic**, **setvorigin**
+
+
+
+
+
+@subsubsection occt_2142243456_1101404852641 reverse, ureverse, vreverse
+
+
+Syntax: reverse curvename
+ureverse surfacename
+vreverse surfacename
+
+The **reverse **command reverses the parameterization and inverses the orientation of a 2d or 3d curve. Note that the geometry is modified. To keep the curve or the surface, you must copy it before modification.
+
+**ureverse **or **vreverse **reverse the u or v parameter of a surface. Note that the new parameters of the curve may change according to the type of curve. For instance, they will change sign on a line or stay 0,1 on a bezier.
+
+Reversing a parameter on an analytical surface may create an indirect coordinate system.
+**Example**
+
+# reverse a trimmed 2d circle
+circle c 0 0 5
+trim c c pi/4 pi/2
+reverse c
+
+# dumping c will show that it is now trimmed between
+# 3*pi/2 and 7*pi/4 i.e. 2*pi-pi/2 and 2*pi-pi/4
+
+
+@subsubsection occt_2142243456_1101404852642 exchuv
+
+Syntax: exchuv surfacename
+
+For a bezier or bspline surface this command exchanges the u and v parameters.
+**Example**
+
+# exchanging u and v on a spline (made from a cylinder)
+cylinder c 5
+trimv c c 0 10
+convert c1 c
+exchuv c1
+
+
+@subsubsection occt_2142243456_1101404852643 segment, segsur
+
+Syntax: segment curve Ufirst Ulast
+segsur surface Ufirst Ulast Vfirst Vlast
+
+**segment **and **segsur **segment a bezier curve and a bspline curve or surface respectively. These commands modify the curve to restrict it between the new parameters: the starting point of the modified curve, Ufirst, and the end point, Ulast. Ufirst is less than Ulast.
+
+This command must not be confused with **trim **which creates new geometry.
+
+**Example**
+
+# segment a bezier curve in half
+beziercurve c 3 0 0 0 10 0 0 10 10 0
+segment c ufirst ulast
+
+
+@subsubsection occt_2142243456_1101404852644 iincudeg, incvdeg
+
+Syntax: incudeg surfacename newdegree
+incvdeg surfacename newdegree
+
+**incudeg **and **incvdeg **increase the degree in the U or V parameter of a bezier or bspline surface.
+**Example**
+
+# make a planar bspline and increase the degree to 2 3
+plane p
+trim p p -1 1 -1 1
+convert p1 p
+incudeg p1 2
+incvdeg p1 3
+
+<h4>NOTE</h4>
+*The geometry is modified.*
+
+
+@subsubsection occt_2142243456_1101404852645 cmovep, movep, movecolp, moverowp
+
+Syntax: cmovep curve index dx dy [dz]
+movep surface uindex vindex dx dy dz
+movecolp surface uindex dx dy dz
+moverowp surface vindex dx dy dz
+
+**move **methods translate poles of a bezier curve, a bspline curve or a bspline surface. **cmovep **and **movep **translate one pole with a given index.
+
+**movecolp **and **moverowp **translate a whole column (expressed by the uindex) or row (expressed by the vindex) of poles.
+**Example**
+
+# start with a plane
+# transform to bspline, raise degree and add relief
+plane p
+trim p p -10 10 -10 10
+convert p1 p
+incud p1 2
+incvd p1 2
+movecolp p1 2 0 0 5
+moverowp p1 2 0 0 5
+movep p1 2 2 0 0 5
+
+
+@subsubsection occt_2142243456_1101404852646 insertpole, rempole, remcolpole, remrowpole
+
+Syntax: insertpole curvename index x y [z] [weight]
+rempole curvename index
+remcolpole surfacename index
+remrowpole surfacename index
+
+**insertpole **inserts a new pole into a 2d or 3d bezier curve. You may add a weight for the pole. The default value for the weight is 1. The pole is added at the position after that of the index pole. Use an index 0 to insert the new pole before the first one already existing in your drawing.
+
+**rempole **removes a pole from a 2d or 3d bezier curve. Leave at least two poles in the curves.
+
+**remcolpole **and **remrowpole **remove a column or a row of poles from a bezier surface. A column is in the v direction and a row in the u direction The resulting degree must be at least 1; i.e there will be two rows and two columns left.
+**Example**
+
+# start with a segment, insert a pole at end
+# then remove the central pole
+beziercurve c 2 0 0 0 10 0 0
+insertpole c 2 10 10 0
+rempole c 2
+
+
+@subsubsection occt_2142243456_1101404852647 insertknot, insertuknot, insertvknot
+
+Syntax: insertknot name knot [mult = 1] [knot mult ...]
+insertuknot surfacename knot mult
+insertvknot surfacename knot mult
+
+**insertknot **inserts knots in the knot sequence of a bspline curve. You must give a knot value and a target multiplicity. The default multiplicity is 1. If there is already a knot with the given value and a multiplicity lower than the target one, its multiplicity will be raised. **insertuknot **and **insertvknot **insert knots in a surface.
+
+
+
+
+**Example**
+
+# create a cylindrical surface and insert a knot
+cylinder c 10
+trim c c 0 pi/2 0 10
+convert c1 c
+insertuknot c1 pi/4 1
+
+@subsubsection occt_2142243456_1101404852648 remknot, remuknot, remvknot
+
+Syntax: remknot index [mult] [tol]
+remuknot index [mult] [tol]
+remvknot index [mult] [tol]
+
+**remknot **removes a knot from the knot sequence of a curve or a surface. Give the index of the knot and optionally, the target multiplicity. If the target multiplicity is not 0, the multiplicity of the knot will be lowered. As the curve may be modified, you are allowed to set a tolerance to control the process. If the tolerance is low, the knot will only be removed if the curve will not be modified.
+
+By default, if no tolerance is given, the knot will always be removed.
+**Example**
+
+# bspline circle, remove a knot
+circle c 0 0 5
+convert c1 c
+incd c1 5
+remknot c1 2
+
+*NOTE*
+*Curves or Surfaces may be modified.*
+
+
+@subsubsection occt_2142243456_1101404852649 setperiodic, setnotperiodic, setuperiodic, setunotperiodic, setvperiodic, setvnotperiodic
+
+Syntax: setperiodic curve
+setnotperiodic curve
+setuperiodic surface
+setunotperiodic surface
+setvperiodic surface
+setvnotperiodic surface
+
+**setperiodic **turns a bspline curve into a periodic bspline curve; the knot vector stays the same and excess poles are truncated. The curve may be modified if it has not been closed. **setnotperiodic **removes the periodicity of a periodic curve. The pole table mau be modified. Note that knots are added at the beginning and the end of the knot vector and the multiplicities are knots set to degree+1 at the start and the end.
+
+**setuperiodic **and **setvperiodic **make the u or the v parameter of bspline surfaces periodic; **setunotperiodic**, and **setvnotperiodic **remove periodicity from the u or the v parameter of bspline surfaces.
+**Example**
+
+# a circle deperiodicized
+circle c 0 0 5
+convert c1 c
+setnotperiodic c1
+@subsubsection occt_2142243456_11014048526410 setorigin, setuorigin, setvorigin
+
+Syntax: setorigin curvename index
+setuorigin surfacename index
+setuorigin surfacename index
+
+These commands change the origin of the parameters on periodic curves or surfaces. The new origin must be an existing knot. To set an origin other than an existing knot, you must first insert one with the **insertknot **command.
+**Example**
+
+# a torus with new U and V origins
+torus t 20 5
+convert t1 t
+setuorigin t1 2
+setvorigin t1 2
+
+
+@subsection occt_2142243456_110140485265 Transformations
+
+Draw provides commands to apply linear transformations to geometric objects: they include translation, rotation, mirroring and scaling.
+
+@subsubsection occt_2142243456_1101404852651 translate, dtranslate
+
+Syntax: translate name [names ...] dx dy dz
+2dtranslate name [names ...] dx dy
+
+The **Translate **command translates 3d points, curves and surfaces along a vector dx,dy,dz. You can translate more than one object with the same command.
+
+For 2d points or curves, use the **2dtranslate **command.
+**Example**
+
+# 3d tranlation
+point p 10 20 30
+circle c 10 20 30 5
+torus t 10 20 30 5 2
+translate p c t 0 0 15
+*NOTE*
+*Objects are modified by this command.*
+
+@subsubsection occt_2142243456_1101404852652 rotate, drotate
+
+Syntax: rotate name [name ...] x y z dx dy dz angle
+2drotate name [name ...] x y angle
+The **rotate **command rotates a 3d point curve or surface. You must give an axis of rotation with a point x,y,z, a vector dx,dy,dz, and an angle in degrees.
+
+For a 2d rotation, you need only give the center point and the angle. In 2d or 3d, the angle can be negative.
+**Example**
+
+# make a helix of circles. create a scripte file with
+this code and execute it using **source**.
+circle c0 10 0 0 3
+for {set i 1} {$i = 10} {incr i} {
+copy c[expr $i-1] c$i
+translate c$i 0 0 3
+rotate c$i 0 0 0 0 0 1 36
+}
+
+@subsubsection occt_2142243456_1101404852653 pmirror, lmirror, smirror, dpmirror, dlmirror
+
+Syntax: pmirror name [names ...] x y z
+lmirror name [names ...] x y z dx dy dz
+smirror name [names ...] x y z dx dy dz
+2dpmirror name [names ...] x y
+2dlmirror name [names ...] x y dx dy
+
+The mirror commands perform a mirror transformation of 2d or 3d geometry.
+
+**pmirror **is the point mirror, mirroring 3d curves and surfaces about a point of symmetry. **lmirror **is the line mirror commamd, mirroring 3d curves and surfaces about an axis of symmetry. **smirror **is the surface mirror, mirroring 3d curves and surfaces about a plane of symmetry. In the last case, the plane of symmetry is perpendicular to dx,dy,dz.
+
+In 2d, only **2dpmirror**, point symmetry mirroring, and **2dlmirror**, axis symmetry mirroring, are available.
+**Example**
+
+# build 3 images of a torus
+torus t 10 10 10 1 2 3 5 1
+copy t t1
+pmirror t1 0 0 0
+copy t t2
+lmirror t2 0 0 0 1 0 0
+copy t t3
+smirror t3 0 0 0 1 0 0
+
+@subsubsection occt_2142243456_1101404852654 pscale, dpscale
+
+Syntax: pscale name [name ...] x y z s
+2dpscale name [name ...] x y s
+The **pscale **and **2dpscale **commands transform an object by point scaling. You must give the center and the scaling factor. Because other scalings modify the type of the object, they are not provided. For example, a sphere may be transformed into an ellipsoid. Using a scaling factor of -1 is similar to using **pmirror**.
+**Example**
+
+# double the size of a sphere
+sphere s 0 0 0 10
+pscale s 0 0 0 2
+
+@subsection occt_2142243456_110140485266 Curve and surface analysis
+
+**Draw **provides methods to compute information about curves and surfaces:
+
+ * **coord **to find the coordinates of a point.
+ * **cvalue **and **2dcvalue **to compute points and derivatives on curves.
+ * **svalue **to compute points and derivatives on a surface.
+ * **localprop **and **minmaxcurandif **to compute the curvature on a curve.
+ * **parameters **to compute (u,v) values for a point on a surface.
+ * **proj **and **2dproj **to project a point on a curve or a surface.
+ * **surface_radius **to compute the curvature on a surface.
+
+@subsubsection occt_2142243456_1101404852661 coord
+
+Syntax: coord P x y [z]
+
+The **coord **command will set the coordinates of the point P. x, y (and optionally z)
+**Example**
+
+# translate a point
+point p 10 5 5
+translate p 5 0 0
+coord p x y z
+# x value is 15
+See also: **point**
+@subsubsection occt_2142243456_1101404852662 cvalue, dcvalue
+
+Syntax: cvalue curve U x y z [d1x d1y d1z [d2x d2y d2z]]
+2dcvalue curve U x y [d1x d1y [d2x d2y]]
+
+For a curve at a given parameter, and depending on the number of arguments, **cvalue **computes: the coordinates in x,y,z, the first derivative in d1x,d1y,d1z and the second derivative in d2x,d2y,d2z.
+<h5>Example</h5>
+
+# on a bezier curve at parameter 0
+# the point is the first pole
+# the derivative is the vector first to second pole
+# multiplied by the degree
+# the second derivative is the difference
+# first to second pole, second to third pole
+# multipied by degree * degree-1
+2dbeziercurve c 4 0 0 1 1 2 1 3 0
+2dcvalue c 0 x y d1x d1y d2x d2y
+
+# values of x y d1x d1y d2x d2y
+# are 0 0 3 3 0 -6
+
+
+@subsubsection occt_2142243456_1101404852663 svalue
+
+Syntax: svalue surfname U v x y z [dux duy duz dvx dvy dvz [d2ux d2uy d2uz d2vx d2vy d2vz d2uvx d2uvy d2uvz]]
+
+**svalue **computes points and derivatives on a surface for a pair of parameter values. The result depends on the number of arguments. You can compute first and second derivatives.
+**Example**
+
+# display points on a sphere
+sphere s 10
+for {dset t 0} {[dval t] = 1} {dset t t+0.01} {
+svalue s t*2*pi t*pi-pi/2 x y z
+point . x y z
+}
+
+
+@subsubsection occt_2142243456_1101404852664 localprop, minmaxcurandinf
+
+Syntax: localprop curvename U
+minmaxcurandinf curve
+
+The **localprop **command computes the curvature of a curve.
+**minmaxcurandinf **computes and prints the parameters of the points where the curvature is minimum and maximum on a 2d curve.
+**Example**
+
+# show curvature at the center of a bezier curve
+beziercurve c 3 0 0 0 10 2 0 20 0 0
+localprop c 0.5
+== Curvature : 0.02
+
+See also: **surface_radius**
+
+
+@subsubsection occt_2142243456_1101404852665 parameters
+
+Syntax: parameters surf/curve x y z U [V]
+
+The **parameters **command returns the parameters on the surface of the 3d point x,y,z in variables u and v . This command may only be used on analytical surfaces: plane, cylinder, cone, sphere and torus.
+**Example**
+
+# Compute parameters on a plane
+plane p 0 0 10 1 1 0
+parameters p 5 5 5 u v
+# the values of u and v are : 0 5
+
+
+@subsubsection occt_2142243456_1101404852666 proj, dproj
+
+Syntax: proj name x y z
+2dproj name xy
+
+Use **proj **to project a point on a 3d curve or a surface and **2dproj **for a 2d curve.
+
+The command will compute and display all points in the projection. The lines joining the point to the projections are created with the names ext_1, ext_2, ...
+**Example**
+
+# project point on a torus
+torus t 20 5
+proj t 30 10 7
+== ext_1 ext_2 ext_3 ext_4
+
+
+@subsubsection occt_2142243456_1101404852667 surface_radius
+
+Syntax: surface_radius surface u v [c1 c2]
+
+The **surface_radius **command computes the main curvatures of a surface at parameters (u,v). If there are extra arguments, their curvatures are stored in variables c1 and c2.
+**Example**
+
+# computes curvatures of a cylinder
+cylinder c 5
+surface_radius c pi 3 c1 c2
+== Min Radius of Curvature : -5
+== Min Radius of Curvature : infinite
+
+
+
+@subsection occt_2142243456_110140485267 Intersections
+
+The **intersect **command computes intersections of surfaces; the **2dintersect **command, intersections of 2d curves.
+
+
+@subsubsection occt_2142243456_1101404852671 intersect
+
+Syntax: intersect name surface1 surface2
+
+The **intersect **command intersects two surfaces. If there is one intersection curve it will be named ;name;, if there are more than one they will be named ;name_1;, ;name_2;, ...
+**Example**
+
+# create an ellipse
+cone c 45 0
+plane p 0 0 40 0 1 5
+intersect e c p
+
+
+@subsubsection occt_2142243456_1101404852672 dintersect
+
+Syntax: 2dintersect curve1 curve2
+
+**2dintersect **displays the intersection points between two 2d curves.
+**Example**
+
+# intersect two 2d ellipses
+ellipse e1 0 0 5 2
+ellipse e2 0 0 0 1 5 2
+2dintersect e1 e2
+@subsection occt_2142243456_110140485268 Approximations
+
+Draw provides command to create curves and surfaces by approximation.
+
+**2dapprox **fits a curve through 2d points, **appro **fits a curve through 3d points, **surfapp **and **grilapp **fits a surface through 3d points, **2dinterpolate **may be used to interpolate a curve.
+
+@subsubsection occt_2142243456_1101404852681 appro, dapprox
+
+Syntax: appro result nbpoint [curve]
+2dapprox result nbpoint [curve / x1 y1 x2 y2]
+
+These commands fit a curve through a set of points. First give the number of points, then choose one of the three ways available to get the points. If you have no arguments, click on the points. If you have a curve argument or a list of points, the command launches computation of the points on the curve.
+**Example**
+
+# pick points and they will be fitted
+2dapprox c 10
+
+
+@subsubsection occt_2142243456_1101404852682 surfapp, grilapp
+
+
+Syntax: surfapp name nbupoints nbvpoints x y z ....
+grilapp name nbupoints nbvpoints xo dx yo dy z11 z12 ...
+
+**surfapp **fits a surface through an array of u and v points, nbupoints*nbvpoints.
+
+**grilapp **has the same function, but the x,y coordinates of the points are on a grid starting at x0,y0 with steps dx,dy.
+**Example**
+
+# a surface using the same data as in the beziersurf
+example sect 4.4
+surfapp s 3 4 \
+0 0 0 10 0 5 20 0 0 \
+0 10 2 10 10 3 20 10 2 \
+0 20 10 10 20 20 20 20 10 \
+0 30 0 10 30 0 20 30 0
+
+
+
+
+
+@subsection occt_2142243456_110140485269 Constraints
+
+The **cirtang **command is used to construct 2d circles tangent to curves and **lintan **to construct 2d lines tangent to curves.
+
+
+@subsubsection occt_2142243456_1101404852691 cirtang
+
+Syntax: cirtang cname curve/point/radius curve/point/radius curve/point/radius
+
+The **cirtang **command will build all circles satisfying the three constraints which are either a curve (the circle must be tangent to that curve), a point (the circle must pass through that point), or a radius for the circle. Only one constraint can be a radius. The solutions will be stored in variables *name_1*, *name_2*, etc.
+**Example**
+
+# a point, a line and a radius. 2 solutions
+point p 0 0
+line 1 10 0 -1 1
+cirtang c p 1 4
+== c_1 c_2
+
+
+@subsubsection occt_2142243456_1101404852692 lintan
+
+Syntax: lintan name curve curve [angle]
+
+The **lintan **command will build all 2d lines tangent to two curves. If a third angle argument is given the second curve must be a line and **lintan **will build all lines tangent to the first curve and forming the given angle with the line. The angle is given in degrees. The solutions are named name_1, name_2, etc.
+**Example**
+
+# lines tangent to 2 circles, 4 solutions
+circle c1 -10 0 10
+circle c2 10 0 5
+lintan l c1 c2
+
+# lines at 15 degrees tangent to a circle and a line, 2
+solutions: l1_1 l1_2
+circle c1 -10 0 1
+line l 2 0 1 1
+lintan l1 c1 l 15
+
+
+
+
+@subsection occt_2142243456_1101404852610 Display
+
+Draw provides commands to control the display of geometric objects. Some display parameters are used for all objects, others are valid for surfaces only, some for bezier and bspline only, and others for bspline only.
+
+On curves and surfaces, you can control the mode of representation with the **dmode **command. You can control the parameters for the mode with the **defle **command and the **discr **command, which control deflection and discretization respectively.
+
+On surfaces, you can control the number of isoparametric curves displayed on the surface with the **nbiso **commands.
+
+On bezier and bspline curve and surface you can toggle the display of the control points with the **clpoles **and **shpoles **commands.
+
+On bspline curves and surfaces you can toggle the display of the knots with the **shknots **and **clknots **commands.
+
+
+@subsubsection occt_2142243456_11014048526101 dmod, discr, defle
+
+Syntax: dmode name [name ...] u/d
+discr name [name ...] nbintervals
+defle name [name ...] deflection
+
+**dmode **allows you to choose the display mode for a curve or a surface.
+
+In mode ;u;, or *uniform deflection*, the points are computed to keep the polygon at a distance lower than the deflection of the geometry. The deflection is set with the **defle **command. This mode involves intensive use of computational power.
+
+In ;d;, or discretization mode, a fixed number of points is computed. This number is set with the **discr **command. This is the default mode. On a bspline, the fixed number of points is computed for each span of the curve. (A span is the interval between two knots).
+
+If the curve or the isolines seem to present too many angles, you can either increase the discretization or lower the deflection, depending on the mode. This will increase the number of points.
+**Example**
+
+# increment the number of points on a big circle
+circle c 0 0 50 50
+discr 100
+
+# change the mode
+dmode c u
+
+
+@subsubsection occt_2142243456_11014048526102 nbiso
+
+Syntax: nbiso name [names...] nuiso nviso
+
+**nbiso **changes the number of isoparametric curves displayed on a surface in the U and V directions. On a bspline surface, isoparametric curves are displayed by default at knot values. Use **nbiso **to turn this feature off.
+**Example**
+
+# display 35 meridians and 15 parallels on a spere
+sphere s 20
+nbiso s 35 15
+
+
+@subsubsection occt_2142243456_11014048526103 clpoles, shpoles
+
+Syntax: clpoles name
+shpoles name
+
+On bezier and bspline curves and surfaces, the control polygon is displayed by default: **clpoles **erases it and **shpoles **restores it.
+**Example**
+
+# make a bezier curve and erase the poles
+beziercurve c 3 0 0 0 10 0 0 10 10 0
+clpoles c
+
+
+@subsubsection occt_2142243456_11014048526104 clknots, shknots
+
+Syntax: clknots name
+shknots name
+
+By default, knots on a bspline curve or surface are displayed with markers at the points with parametric value equal to the knots. **clknots **removes them and **shknots **restores them.
+**Example**
+
+# hide the knots on a bspline curve
+bsplinecurve bc 2 3 0 3 1 1 2 3 \
+10 0 7 1 7 0 7 1 3 0 8 1 0 0 7 1
+clknots bc
+@section occt_2142243456_1869436669 Topology commands
+
+
+
+
+
+
+
+Draw provides a set of commands to test OCCT Topology libraries. The Draw commands are found in the DRAWEXE executable or in any executable including the BRepTest commands.
+
+Topology defines the relationship between simple geometric entities, which can thus be linked together to represent complex shapes. The type of variable used by Topology in Draw is the shape variable.
+
+The different topological shapes<a href="#_ftn3">[3]</a> include:
+
+ * COMPOUND: A group of any type of topological object.
+ * COMPSOLID: A set of solids connected by their faces. This expands the notions of WIRE and SHELL to solids.
+ * SOLID: A part of space limited by shells. It is three dimensional.
+ * SHELL: A set of faces connected by their edges. A shell can be open or closed.
+ * FACE: In 2d, a plane; in 3d, part of a surface. Its geometry is constrained (trimmed) by contours. It is two dimensional.
+ * WIRE: A set of edges connected by their vertices. It can be open or closed depending on whether the edges are linked or not.
+ * EDGE: A topological element corresponding to a restrained curve. An edge is generally limited by vertices. It has one dimension.
+ * VERTEX: A topological element corresponding to a point. It has a zero dimension.
+
+Shapes are usually shared. **copy **will create a new shape which shares its representation with the original. Nonetheless, two shapes sharing the same topology can be moved independently (see the section on **transformation**).
+
+The following topics are covered in the eight sections of this chapter:
+
+ * Basic shape commands to handle the structure of shapes and control the display.
+ * Curve and surface topology, or methods to create topology from geometry and vice versa.
+ * Primitive construction commands: box, cylinder, wedge etc.
+ * Sweeping of shapes.
+ * Transformations of shapes: translation, copy, etc.
+ * Topological operations, or booleans.
+ * Drafting and blending.
+ * Analysis of shapes.
+
+
+
+@subsection occt_2142243456_186943666971 Basic topology
+
+The set of basic commands allows simple operations on shapes, or step-by-step construction of objects. These commands are useful for analysis of shape structure and include:
+
+ * **isos **and **discretisation **to control display of shape faces by isoparametric curves .
+ * **orientation**, **complement **and **invert **to modify topological attributes such as orientation.
+ * **explode**, **exwire **and **nbshapes **to analyze the structure of a shape.
+ * **emptycopy**, **add**, **compound **to create shapes by stepwise construction.
+
+In Draw, shapes are displayed using isoparametric curves. There is color coding for the edges:
+
+ * a red edge is an isolated edge, which belongs to no faces.
+ * a green edge is a free boundary edge, which belongs to one face,
+ * a yellow edge is a shared edge, which belongs to at least two faces.
+
+
+@subsubsection occt_2142243456_1869436669711 isos, discretisation
+
+Syntax: isos [name ...][nbisos]
+discretisation nbpoints
+**isos **determines or changes the number of isoparametric curves on shapes.
+
+The same number is used for the u and v directions. With no arguments, **isos **prints the current default value. To determine, the number of isos for a shape, give it name as the first argument.
+
+**discretisation **changes the default number of points used to display the curves. The default value is 30.
+**Example**
+
+# Display only the edges (the wireframe)
+isos 0
+
+<h4>NOTE</h4>
+Don’t confuse *isos* and *discretisation* with the geometric
+*commands *nbisos* and *discr*.*
+
+
+@subsubsection occt_2142243456_1869436669712 orientation, complement, invert, normals, range
+
+Syntax: orientation name [name ...] F/R/E/I
+complement name [name ...]
+invert name
+normals s (length = 10), disp normals
+range name value value
+
+**orientation **assigns the orientation of shapes - simple and complex - to one of the following four values: FORWARD, REVERSED, INTERNAL, EXTERNAL.
+
+**complement **changes the current orientation of shapes to its complement, FORWARD - REVERSED, INTERNAL - EXTERNAL.
+
+**invert **creates a new shape which is a copy of the original with the orientation all subshapes reversed. For example, it may be useful to reverse the normals of a solid.
+
+**normals **returns the assignment of colors to orientation values.
+
+**range **defines the length of a selected edge by defining the values of a starting point and an end point.
+**Example**
+
+# invert normals of a box
+box b 10 20 30
+normals b 5
+invert b
+normals b 5
+
+# to assign a value to an edge
+box b1 10 20 30
+# to define the box as edges
+explode b1 e
+b_1 b_2 b_3 b_4 b_5 b_6 b_7 b_8 b_9 b_10 b_11 b_12
+# to define as an edge
+makedge e 1
+# to define the length of the edge as starting from 0
+and finishing at 1
+range e 0 1
+
+
+@subsubsection occt_2142243456_1869436669713 explode, exwire, nbshapes
+
+Syntax: explode name [C/So/Sh/F/W/E/V]
+exwire name
+nbshapes name
+
+**explode **extracts subshapes from an entity. The subshapes will be named *name_1*, *name_2*, ... Note that they are not copied but shared with the original.
+
+With name only, **explode **will extract the first sublevel of shapes: the shells of a solid or the edges of a wire, for example. With one argument, **explode **will extract all subshapes of that type: *C *for compounds, *So *for solids, *Sh *for shells, *F *for faces, *W *for wires, *E *for edges, *V *for vertices.
+
+**exwire **is a special case of **explode **for wires, which extracts the edges in an ordered way,if possible. Each edge, for example, is connected to the following one by a vertex.
+
+**nbshapes **counts the number of shapes of each type in an entity.
+**Example**
+
+# on a box
+box b 10 20 30
+
+# whatis returns the type and various information
+whatis b
+= b is a shape SOLID FORWARD Free Modified
+
+# make one shell
+explode b
+whatis b_1
+= b_1 is a shape SHELL FORWARD Modified Orientable
+Closed
+
+# extract the edges b_1, ... , b_12
+explode b e
+==b_1 ... b_12
+
+# count subshapes
+nbshapes b
+==
+Number of shapes in b
+VERTEX : 8
+EDGE : 12
+WIRE : 6
+FACE : 6
+SHELL : 1
+SOLID : 1
+COMPSOLID : 0
+COMPOUND : 0
+SHAPE : 34
+
+
+@subsubsection occt_2142243456_1869436669714 emptycopy, add, compound
+
+Syntax: emptycopy [newname] name
+add name toname
+compound [name ...] compoundname
+
+**emptycopy **returns an empty shape with the same orientation, location, and geometry as the target shape, but with no sub-shapes. If the newname argument is not given, the new shape is stored with the same name. This command is used to modify a frozen shape. A frozen shape is a shape used by another one. To modify it, you must emptycopy it. Its subshape may be reinserted with the **add **command.
+
+**add **inserts shape C into shape S. Verify that C and S reference compatible types of objects:
+
+ * Any *Shape *can be added to a *Compound*.
+ * Only a *Solid *can be added to a *CompSolid*.
+ * Only a *Shell*, an *Edge *or a *Vertex *can be added into a *Solid*.
+ * Only a *Face *can be added to a *Shell*.
+ * Only a *Wire *and *Vertex *can be added in a *Solid*.
+ * Only an *Edge *can be added to a *Wire*.
+ * Only a *Vertex *can be added to an *Edge*.
+ * Nothing can be added to a *Vertex*.
+
+Care should be taken using **emptycopy **and **add**.
+
+On the other hand, **compound **is a safe way to achieve a similar result. It creates a compound from shapes. If no shapes are given, the compound is empty.
+**Example**
+
+# a compound with three boxes
+box b1 0 0 0 1 1 1
+box b2 3 0 0 1 1 1
+box b3 6 0 0 1 1 1
+compound b1 b2 b3 c
+
+
+@subsubsection occt_2142243456_1869436669715 checkshape
+
+Syntax: checkshape [-top] shape [result] [-short]
+
+Where:
+*-top* – check only topological validity of a shape.
+*shape *– the only required parameter which represents the name of the shape to check.
+*result* – optional parameter which is the prefix of the output shape names.
+*-short* – short description of check.
+
+
+**checkshape **examines the selected object for topological and geometric coherence. The object should be a three dimensional shape.
+**Example**
+
+# checkshape returns a comment valid or invalid
+box b1 0 0 0 1 1 1
+checkshape b1
+# returns the comment
+this shape seems to be valid
+
+<h4>NOTE</h4>
+*This test is performed using the tolerance set in the algorithm.*
+
+
+
+
+
+@subsection occt_2142243456_186943666972 Curve and surface topology
+
+This group of commands is used to create topology from shapes and to extract shapes from geometry.
+
+ * To create vertices, use the **vertex **command.
+ * To create edges use, the **edge**, **mkedge **commands.
+ * To create wires, use the **wire**, **polyline**, **polyvertex **commands.
+ * To create faces, use the **mkplane**, **mkface **commands.
+ * To extract the geometry from edges or faces, use the **mkcurve **and **mkface **commands.
+ * To extract the 2d curves from edges or faces, use the **pcurve **command.
+
+
+@subsubsection occt_2142243456_1869436669721 vertex
+
+Syntax: vertex name [x y z / p edge]
+
+Creates a vertex at either a 3d location x,y,z or the point at parameter p on an edge.
+**Example**
+
+vertex v1 10 20 30
+
+
+@subsubsection occt_2142243456_1869436669722 edge, mkedge, uisoedge, visoedge
+
+Syntax: edge name vertex1 vertex2
+mkedge edge curve [surface] [pfirst plast] [vfirst [pfirst] vlast [plast]]
+uisoedge edge face u v1 v2
+visoedge edge face v u1 u2
+
+**edge **creates a straight line edge between two vertices.
+
+**mkedge **generates edges from curves<a href="#_ftn4">[4]</a>.Two parameters can be given for the vertices: the first and last parameters of the curve are given by default. Vertices can also be given with their parameters, this option allows you to block the creation of new vertices. If the parameters of the vertices are not given, they are computed by projection on the curve. Instead of a 3d curve, a 2d curve and a surface can be given.
+**Example**
+
+# straight line edge
+vertex v1 10 0 0
+vertex v2 10 10 0
+edge e1 v1 v2
+
+# make a circular edge
+circle c 0 0 0 5
+mkedge e2 c 0 pi/2
+
+# A similar result may be achieved by trimming the curve
+# The trimming is removed by mkedge
+trim c c 0 pi/2
+mkedge e2 c
+
+**visoedge **and **uisoedge **are commands that generate a uiso parameter edge
+or a viso parameter edge.
+
+**Example**
+
+# to create an edge between v1 and v2 at point u
+# to create the example plane
+plane p
+trim p p 0 1 0 1
+convert p p
+incudeg p 3
+incvdeg p 3
+movep p 2 2 0 0 1
+movep p 3 3 0 0 0.5
+mkface p p
+# to create the edge in the plane at the u axis point
+0.5, and between the v axis points v=0.2 and v =0.8
+uisoedge e p 0.5 0.20 0.8
+
+
+@subsubsection occt_2142243456_1869436669723 wire, polyline, polyvertex
+
+Syntax: wire wirename e1/w1 [e2/w2 ...]
+polyline name x1 y1 z1 x2 y2 z2 ...
+polyvertex name v1 v2 ...
+
+**wire **creates a wire from edges or wires. The order of the elements should ensure that the wire is connected, and vertex locations will be compared to detect connection. If the vertices are different, new edges will be created to ensure topological connectivity. The original edge may be copied in the new one.
+
+**polyline **creates a polygonal wire from point coordinates. To make a closed wire, you should give the first point again at the end of the argument list.
+
+**polyvertex **creates a polygonal wire from vertices.
+**Example**
+
+# create two polygonal wires
+# glue them and define as a single wire
+polyline w1 0 0 0 10 0 0 10 10 0
+polyline w2 10 10 0 0 10 0 0 0 0
+wire w w1 w2
+
+
+@subsubsection occt_2142243456_1869436669724 profile
+
+Syntax profile name [code values] [code values] ...
+
+**Code** **Values ** **Action**
+O X Y Z Sets the origin of the plane
+P DX DY DZ UX UY UZ Sets the normal and X of the plane
+F X Y Sets the first point
+X DX Translates a point along X
+Y DY Translates a point along Y
+L DL Translates a point along direction
+XX X Sets point X coordinate
+YY Y Sets point Y coordinate
+T DX DY Translates a point
+TT X Y Sets a point
+R Angle Rotates direction
+RR Angle Sets direction
+D DX DY Sets direction
+IX X Intersects with vertical
+IY Y Intersects with horizontal
+C Radius Angle Arc of circle tangent to direction
+
+<h5>Suffix</h5>
+No suffix Makes a closed face
+W Make a closed wire
+WW Make an open wire
+
+
+**profile **builds a profile in a plane using a moving point and direction. By default, the profile is closed and a face is created. The original point is 0 0, and direction is 1 0 situated in the XY plane.
+
+Codes and values are used to define the next point or change the direction. When the profile changes from a straight line to a curve, a tangent is created. All angles are in degrees and can be negative.
+
+The point [code values] can be repeated any number of times and in any order to create the profile contour.
+
+The profile shape definition is the suffix; no suffix produces a face, **w **is a closed wire, **ww **is an open wire.
+
+Code letters are not case-sensitive.
+**Example**
+
+# to create a trianglular plane using a vertex at the
+origin, in the xy plane
+profile p O 0 0 0 X 1 Y 0 x 1 y 1
+**Example**
+
+# to create a contour using the different code
+possibilities
+
+# two vertices in the xy plane
+profile p F 1 0 x 2 y 1 ww
+
+# to view from a point normal to the plane
+top
+
+# add a circular element of 45 degrees
+profile p F 1 0 x 2 y 1 c 1 45 ww
+
+# add a tangential segment with a length value 1
+profile p F 1 0 x 2 y 1 c 1 45 l 1 ww
+
+# add a vertex with xy values of 1.5 and 1.5
+profile p F 1 0 x 2 y 1 c 1 45 l 1 tt 1.5 1.5 ww
+
+# add a vertex with the x value 0.2, y value is constant
+profile p F 1 0 x 2 y 1 c 1 45 l 1 tt 1.5 1.5 xx 0.2 ww
+
+# add a vertex with the y value 2 x value is constant
+profile p F 1 0 x 2 y 1 c 1 45 l 1 tt 1.5 1.5 yy 2 ww
+
+# add a circular element with a radius value of 1 and a circular value of 290 degrees
+profile p F 1 0 x 2 y 1 c 1 45 l 1 tt 1.5 1.5 xx 0.2 yy 2 c 1 290
+
+# wire continues at a tangent to the intersection x = 0
+profile p F 1 0 x 2 y 1 c 1 45 l 1 tt 1.5 1.5 xx 0.2 yy 2 c 1 290 ix 0 ww
+
+# continue the wire at an angle of 90 degrees until it intersects the y axis at y= -o.3
+profile p F 1 0 x 2 y 1 c 1 45 l 1 tt 1.5 1.5 xx 0.2 yy 2 c 1 290 ix 0 r 90 ix -0.3 ww
+
+#close the wire
+profile p F 1 0 x 2 y 1 c 1 45 l 1 tt 1.5 1.5 xx 0.2 yy 2 c 1 290 ix 0 r 90 ix -0.3 w
+
+# to create the plane with the same contour
+profile p F 1 0 x 2 y 1 c 1 45 l 1 tt 1.5 1.5 xx 0.2 yy 2 c 1 290 ix 0 r 90 ix -0.3
+
+
+@subsubsection occt_2142243456_1869436669725 bsplineprof
+
+Syntax: bsplineprof name [S face] [W WW]
+
+for an edge : digitizes ... mouse button 2
+to end profile : mouse button 3
+
+Build a profile in the XY plane from digitizes
+By default the profile is closed and a face is built.
+
+W Make a closed wire
+WW Make an open wires
+
+**bsplineprof **creates a 2d profile from bspline curves using the mouse as the input. MB1 creates the points, MB2 finishes the current curve and starts the next curve, MB3 closes the profile.
+
+The profile shape definition is the suffix; no suffix produces a face, **w **is a closed wire, **ww **is an open wire.
+**Example**
+
+#to view the xy plane
+top
+#to create a 2d curve with the mouse
+bsplineprof res
+# click mb1 to start the curve
+# click mb1 to create the second vertex
+# click mb1 to create a curve
+==
+#click mb2 to finish the curve and start a new curve
+==
+# click mb1 to create the second curve
+# click mb3 to create the face
+
+
+@subsubsection occt_2142243456_1869436669726 mkoffset
+
+Syntax: mkoffset result face/compound of wires nboffset stepoffset
+
+**mkoffset **creates a parallel wire in the same plane using a face or an existing continuous set of wires as a reference. The number of occurences is not limited.
+
+The offset distance defines the spacing and the positionning of the occurences.
+**Example**
+
+#Create a box and select a face
+box b 1 2 3
+explode b f
+#Create three exterior parallel contours with an offset
+value of 2
+mkoffset r b_1 3 2
+Create one interior parallel contour with an offset
+value of
+0.4
+mkoffset r b_1 1 -0.4
+
+NOTE
+*The mkoffset command must be used with prudence, angular contours produce offset contours with fillets. Interior parallel contours can produce more than one wire, normally these are refused. In the following example, any increase in the offset value is refused*
+**Example**
+
+# to create the example contour
+profile p F 0 0 x 2 y 4 tt 1 1 tt 0 4 w
+# to create an incoherent interior offset
+mkoffset r p 1 -0.50
+==p is not a FACE but a WIRE
+BRepFill_TrimEdgeTool: incoherent intersection
+# to create two incoherent wires
+mkoffset r p 1 -0.50
+
+
+@subsubsection occt_2142243456_1869436669727 mkplane, mkface
+
+Syntax: mkplane name wire
+mkface name surface [ufirst ulast vfirst vlast]
+
+**mkplane **generates a face from a planar wire. The planar surface will be constructed with an orientation which keeps the face inside the wire.
+
+**mkface **generates a face from a surface. Parameter values can be given to trim a rectangular area. The default boundaries are those of the surface.
+**Example**
+
+# make a polygonal face
+polyline f 0 0 0 20 0 0 20 10 0 10 10 0 10 20 0 0 20 0 0 0 0
+mkplane f f
+
+# make a cylindrical face
+cylinder g 10
+trim g g -pi/3 pi/2 0 15
+mkface g g
+
+
+@subsubsection occt_2142243456_1869436669728 mkcurve, mksurface
+
+Syntax: mkcurve curve edge
+mksurface name face
+
+**mkcurve **creates a 3d curve from an edge. The curve will be trimmed to the edge boundaries.
+
+**mksurface **creates a surface from a face. The surface will not be trimmed.
+**Example**
+
+# make a line
+vertex v1 0 0 0
+vertex v2 10 0 0
+edge e v1 v2
+
+
+@subsubsection occt_2142243456_1869436669729 pcurve
+
+Syntax: pcurve [name edgename] facename
+
+**pcurve **extracts the 2d curve of an edge on a face. If only the face is specified, the command extracts all the curves and colors them according to their orientation. This is useful in checking to see if the edges in a face are correctly oriented, i.e. they turn counterclockwise. To make curves visible, use a fitted 2d view.
+**Example**
+
+# view the pcurves of a face
+plane p
+trim p p -1 1 -1 1
+mkface p p
+av2d; # a 2d view
+pcurve p
+2dfit
+
+
+@subsubsection occt_2142243456_18694366697210 chfid
+
+Syntax: chfi2d result face [edge1 edge2 (F radius/CDD d1 d2/CDA d ang) ....
+
+chfi2d creates chamfers and fillets on 2D objects. Select t:wo adjacent edges and:
+
+ * a radius value
+ * two respective distance values
+ * a distance value and an angle
+
+The radius value produces a fillet between the two faces.
+
+The distance is the length value from the edge between the two selected faces in a normal direction.
+
+**Example**
+
+# to create a 2d fillet
+top
+profile p x 2 y 2 x -2
+chfi2d cfr p . . F 0.3
+==Pick an object
+#select an edge
+==Pick an object
+#select an edge
+**Example**
+
+# to create a 2d chamfer using two distances
+profile p x 2 y 2 x -2
+chfi2d cfr p . . CDD 0.3 0.6
+==Pick an object
+#select an edge
+==Pick an object
+#select an edge
+**Example**
+
+# to create a 2d chamfer using a defined distance and
+angle
+top
+profile p x 2 y 2 x -2
+chfi2d cfr p . . CDA 0.3 75
+==Pick an object
+#select an edge
+==Pick an object
+#select an edge
+
+
+@subsubsection occt_2142243456_18694366697211 nproject
+
+Syntax: nproject pj e1 e2 e3 ... surf -g -d [dmax] [Tol
+[continuity [maxdeg [maxseg]]]
+
+**nproject **creates a shape projection which is normal to the target surface.
+<h5>Example</h5>
+
+# create a curved surface
+line l 0 0 0 1 0 0
+trim l l 0 2
+convert l l
+
+incdeg l 3
+cmovep l 1 0 0.5 0
+cmovep l 3 0 0.5 0
+copy l ll
+translate ll 2 -0.5 0
+mkedge e1 l
+mkedge e2 ll
+wire w e1 e2
+prism p w 0 0 3
+donl p
+#display in four views
+mu4
+fit
+# create the example shape
+circle c 1.8 -0.5 1 0 1 0 1 0 0 0.4
+mkedge e c
+donly p e
+# create the normal projection of the shape(circle)
+nproject r e p
+
+
+
+@subsection occt_2142243456_186943666973 Primitives
+
+Primitive commands make it possible to create simple shapes. They include:
+
+ * **box **and **wedge **commands.
+ * **pcylinder**, **pcone**, **psphere**, **ptorus **commands.
+ * **halfspace **command
+
+
+@subsubsection occt_2142243456_1869436669731 box, wedge
+
+Syntax: box name [x y z] dx dy dz
+wedge name dx dy dz ltx / xmin zmin xmax xmax
+
+**box **creates a box parallel to the axes with dimensions dx,dy,dz. x,y,z is the corner of the box. It is the default origin.
+
+**wedge **creates a box with five faces called a wedge. One face is in the OXZ plane, and has dimensions dx,dz while the other face is in the plane y = dy. This face either has dimensions ltx, dz or is bounded by xmin,zmin,xmax,zmax.
+
+The other faces are defined between these faces. The face in the y=yd plane may be degenerated into a line if ltx = 0, or a point if xmin = xmax and ymin = ymax. In these cases, the line and the point both have 5 faces each. To position the wedge use the **ttranslate **and **trotate **commands.
+**Example**
+
+# a box at the origin
+box b1 10 20 30
+
+# another box
+box b2 30 30 40 10 20 30
+
+# a wedge
+wedge w1 10 20 30 5
+
+# a wedge with a sharp edge (5 faces)
+wedge w2 10 20 30 0
+
+# a pyramid
+wedge w3 20 20 20 10 10 10 10
+
+
+@subsubsection occt_2142243456_1869436669732 pcylinder, pcone, psphere, ptorus
+
+Syntax: pcylinder name [plane] radius height [angle]
+pcone name [plane] radius1 radius2 height [angle]
+pcone name [plane] radius1 radius2 height [angle]
+psphere name [plane] radius1 [angle1 angle2] [angle]
+ptorus name [plane] radius1 radius2 [angle1 angle2] [angle]
+
+All these commands create solid blocks in the default coordinate system, using the Z axis as the axis of revolution and the X axis as the origin of the angles. To use another system, translate and rotate the resulting solid or use a plane as first argument to specify a coordinate system. All primitives have an optional last argument which is an angle expreesed in degrees and located on the Z axis, starting from the X axis. The default angle is 360.
+
+**pcylinder **creates a cylindrical block with the given radius and height.
+
+**pcone **creates a truncated cone of the given height with radius1 in the plane z = 0 and radius2 in the plane z = height. Neither radius can be negative, but one of them can be null.
+
+**psphere **creates a solid sphere centered on the origin. If two angles, *angle1 *and *angle2, *are given, the solid will be limited by two planes at latitude *angle1 *and *angle2*. The angles must be increasing and in the range -90,90.
+
+**ptorus **creates a solid torus with the given radii, centered on the origin, which is a point along the z axis. If two angles increasing in degree in the range 0 – 360 are given, the solid will be bounded by two planar surfaces at those positions on the circle.
+**Example**
+
+# a can shape
+pcylinder cy 5 10
+
+# a quarter of a truncated cone
+pcone co 15 10 10 90
+
+# three-quarters of sphere
+psphere sp 10 270
+
+# half torus
+ptorus to 20 5 0 90
+@subsubsection occt_2142243456_1869436669733 halfspace
+
+Syntax: halfspace result face/shell x y z
+
+**halfspace **creates an infinite solid volume based on a face in a defined direction. This volume can be used to perform the boolean operation of cutting a solid by a face or plane.
+**Example**
+
+box b 0 0 0 1 2 3
+explode b f
+==b_1 b_2 b_3 b_4 b_5 b_6
+halfspace hr b_3 0.5 0.5 0.5
+
+
+
+@subsection occt_2142243456_186943666974 Sweeping
+
+Sweeping creates shapes by sweeping out a shape along a defined path:
+
+ * **prism **sweeps along a direction.
+ * **revol **sweeps around an axis.
+ * **pipe **sweeps along a wire.
+ * **mksweep **and **buildsweep **are commands to create sweeps by defining the arguments and algorithms.
+ * **thrusections **creates a sweep from wire in different planes.
+
+
+@subsubsection occt_2142243456_1869436669741 prism
+
+Syntax: prism result base dx dy dz [Copy | Inf | SemiInf]
+
+**prism **creates a new shape by sweeping a shape in a direction. Any shape can be swept: a vertex gives an edge; an edge gives a face; and a face gives a solid.
+
+The shape is swept along the vector dx dy dz. The original shape will be shared in the result unless *Copy *is specified. If *Inf *is specified the prism is infinite in both directions. If *SemiInf *is specified the prism is infinite in the dx,dy,dz direction, and the length of the vector has no importance.
+**Example**
+
+# sweep a planar face to make a solid
+polyline f 0 0 0 10 0 0 10 5 0 5 5 0 5 15 0 0 15 0 0 0 0
+mkplane f f
+
+
+@subsubsection occt_2142243456_1869436669742 revol
+
+Syntax: revol result base x y z dx dy dz angle [Copy]
+
+**revol **creates a new shape by sweeping a base shape through an angle along the axis x,y,z dx,dy,dz. As with the prism command, the shape can be of any type and is not shared if *Copy *is specified.
+**Example**
+
+# shell by wire rotation
+polyline w 0 0 0 10 0 0 10 5 0 5 5 0 5 15 0 0 15 0
+revol s w 20 0 0 0 1 0 90
+
+
+
+@subsubsection occt_2142243456_1869436669743 pipe
+
+Syntax: pipe name wire_spine Profile
+
+**pipe **creates a new shape by sweeping a shape known as the profile along a wire known as the spine.
+**Example**
+
+# sweep a circle along a bezier curve to make a solid
+pipe
+
+beziercurve spine 4 0 0 0 10 0 0 10 10 0 20 10 0
+mkedge spine spine
+wire spine spine
+circle profile 0 0 0 1 0 0 2
+mkedge profile profile
+wire profile profile
+mkplane profile profile
+pipe p spine profile
+
+
+@subsubsection occt_2142243456_1869436669744 mksweep, deletesweep, buildsweep, simulsweep
+
+Syntax: mksweep wire
+addsweep wire[vertex][-M][-C] [auxiilaryshapedeletesweep wire
+setsweep options [arg1 [arg2 [...]]]
+
+options are :
+
+-FR : Tangent and Normal are defined by a Frenet trihedron
+-CF : Tangent is given by Frenet,
+the Normal is computed to minimize the torsion
+-DX Surf : Tangent and Normal are given by Darboux trihedron,
+Surf must be a shell or a face
+-CN dx dy dz : BiNormal is given by dx dy dz
+-FX Tx Ty TZ [Nx Ny Nz] : Tangent and Normal are fixed
+-G guide 0|1(AC
+simulsweep r [n] [option]
+buildsweep [r] [option] [Tol]
+
+These commands are used to create a shape from wires. One wire is designated as the contour that defines the direction; it is called the spine. At least one other wire is used to define the the sweep profile.
+
+**mksweep **initializes the sweep creation and defines the wire to be used as the spine.
+
+**addsweep **defines the wire to be used as the profile.
+
+**deletesweep **cancels the choice of profile wire, without leaving the mksweep mode. You can re-select a profile wire.
+
+**setsweep **commands the algorithms used for the construction of the sweep.
+
+**simulsweep **can be used to create a preview of the shape. [n] is the number of sections that are used to simulate the sweep.
+
+**buildsweep **creates the sweep using the arguments defined by all the commands.
+**Example**
+
+#create a sweep based on a semi-circular wire using the
+Frenet algorithm
+#create a circular figure
+circle c2 0 0 0 1 0 0 10
+trim c2 c2 -pi/2 pi/2
+mkedge e2 c2
+donly e2
+wire w e2
+whatis w
+mksweep w
+# to display all the options for a sweep
+setsweep
+#to create a sweep using the Frenet algorithm where the
+#normal is computed to minimise the torsion
+setsweep -CF
+addsweep w -R
+# to simulate the sweep with a visual approximation
+simulsweep w 3
+
+
+@subsubsection occt_2142243456_1869436669745 thrusections
+
+Syntax: thrusections [-N] result issolid isruled wire1 wire2 [..wire..]
+
+**thrusections **creates a shape using wires that are positioned in different planes. Each wire selected must have the same number of edges and vertices.
+A bezier curve is generated between the vertices of each wire. The option [-N] means no check is made on wires for direction.
+**Example**
+
+#create three wires in three planes
+polyline w1 0 0 0 5 0 0 5 5 0 2 3 0
+polyline w2 0 1 3 4 1 3 4 4 3 1 3 3
+polyline w3 0 0 5 5 0 5 5 5 5 2 3 5
+# create the shape
+thrusections th issolid isruled w1 w2 w3
+==thrusections th issolid isruled w1 w2 w3
+Tolerances obtenues -- 3d : 0
+-- 2d : 0
+
+
+
+
+
+@subsection occt_2142243456_186943666975 Topological transformation
+
+Transformations are applications of matrices. When the transformation is nondeforming, such as translation or rotation, the object is not copied. The topology localcoordinate system feature is used. The copy can be enforced with the **tcopy **command.
+
+ * **tcopy **makes a copy of the structure of a shape.
+ * **ttranslate**, **trotate**, **tmove**, **reset **move a shape.
+ * **tmirror**, **tscale **always modify the shape.
+
+
+@subsubsection occt_2142243456_1869436669751 tcopy
+
+Syntax: tcopy name toname [name toname ...]
+
+Copies the structure of one shape, including the geometry, into another, newer shape.
+**Example**
+
+# create an edge from a curve and copy it
+beziercurve c 3 0 0 0 10 0 0 20 10 0
+mkedge e1 c
+ttranslate e1 0 5 0
+tcopy e1 e2
+ttranslate e2 0 5 0
+# now modify the curve, only e1 and e2 will be modified
+
+@subsubsection occt_2142243456_1869436669752 tmove, treset
+
+Syntax: tmove name [name ...] shape
+reset name [name ...]
+
+**tmove **and **reset **modify the location, or the local coordinate system of a shape.
+
+**tmove **applies the location of a given shape to other shapes. **reset **restores one or several shapes it to its or their original coordinate system(s).
+**Example**
+
+# create two boxes
+box b1 10 10 10
+box b2 20 0 0 10 10 10
+# translate the first box
+ttranslate b1 0 10 0
+# and apply the same location to b2
+tmove b2 b1
+# return to original positions
+reset b1 b2
+
+
+@subsubsection occt_2142243456_1869436669753 ttranslate, trotate
+
+Syntax: ttranslate [name ...] dx dy dz
+trotate [name ...] x y z dx dy dz angle
+
+**ttranslate **translates a set of shapes by a given vector, and **trotate **rotates them by a given angle around an axis. Both commands only modify the location of the shape.
+When creating multiple shapes, the same location is used for all the shapes. (See toto.tcl example below. Note that the code of this file can also be directly executed in interactive mode.)
+
+Locations are very economic in the data structure because multiple occurences of an object share the topological description.
+**Example**
+# make rotated copies of a sphere in between two cylinders
+# create a file source toto.tcl
+# toto.tcl code:
+for {set i 0} {$i 360} {incr i 20} {
+copy s s$i
+trotate s$i 0 0 0 0 0 1 $i
+}
+
+# create two cylinders
+pcylinder c1 30 5
+copy c1 c2
+ttranslate c2 0 0 20
+
+#create a sphere
+psphere s 3
+ttranslate s 25 0 12.5
+
+# call the source file for multiple copies
+source toto.tcl
+
+
+@subsubsection occt_2142243456_1869436669754 tmirror, tscale
+
+Syntax: tmirror name x y z dx dy dz
+tscale name x y z scale
+
+**tmirror **makes a mirror copy of a shape about a plane x,y,z dx,dy,dz. **Tscale **applies a central homotopic mapping to a shape.
+**Example**
+
+# mirror a portion of cylinder about the YZ plane
+pcylinder c1 10 10 270
+copy c1 c2
+tmirror c2 15 0 0 1 0 0
+# and scale it
+tscale c1 0 0 0 0.5
+
+
+
+@subsection occt_2142243456_186943666976 Old Topological operations
+
+
+
+ * **fuse**, **cut**, **common **are boolean operations.
+ * **section**, **psection **compute sections.
+ * **sewing **joins two or more shapes.
+
+
+@subsubsection occt_2142243456_1869436669761 fuse, cut, common
+
+Syntax: fuse name shape1 shape2
+cut name shape1 shape2
+common name shape1 shape2
+
+**fuse **creates a new shape by a boolean operation on two existing shapes. The new shape contains both originals intact.
+
+**cut **creates a new shape which contains all parts of the second shape but only the first shape without the intersection of the two shapes.
+
+**common **creates a new shape which contains only what is in common between the two original shapes in their intersection.
+**Example**
+
+# all four boolean operations on a box and a cylinder
+
+box b 0 -10 5 20 20 10
+pcylinder c 5 20
+
+fuse s1 b c
+ttranslate s1 40 0 0
+
+cut s2 b c
+ttranslate s2 -40 0 0
+
+cut s3 c b
+ttranslate s3 0 40 0
+
+common s4 b c
+ttranslate s4 0 -40 0
+
+
+
+@subsubsection occt_2142243456_1869436669762 section, psection
+
+Syntax: section result shape1 shape2
+psection name shape plane
+
+**section **creates a compound object consisting of the edges for the intersection curves on the faces of two shapes.
+
+**psection **creates a planar section consisting of the edges for the intersection curves on the faces of a shape and a plane.
+**Example**
+
+# section line between a cylinder and a box
+pcylinder c 10 20
+box b 0 0 5 15 15 15
+trotate b 0 0 0 1 1 1 20
+section s b c
+
+# planar section of a cone
+pcone c 10 30 30
+plane p 0 0 15 1 1 2
+psection s c p
+
+
+@subsubsection occt_2142243456_1869436669763 sewing
+
+Syntax: sewing result [tolerance] shape1 shape2 ...
+
+**Sewing **joins shapes by connecting their adjacent or near adjacent edges. Adjacency can be redefined by modifying the tolerance value.
+
+**Example**
+
+# create two adjacent boxes
+box b 0 0 0 1 2 3
+box b2 0 2 0 1 2 3
+sewing sr b b2
+whatis sr
+sr is a shape COMPOUND FORWARD Free Modified
+
+
+@subsection occt_2142243456_186943666977 New Topological operations
+
+
+The new algorithm of Boolean operations avoids a large number of weak points and limitations presented in the old boolean operation algorithm.
+
+
+@subsubsection occt_2142243456_1869436669771 bop, bopfuse, bopcut, boptuc, bopcommon,
+
+**bop** defines **shape1** and **shape2** subject to ulterior Boolean operations
+
+**bopfuse **creates a new shape by a boolean operation on two existing shapes. The new shape contains both originals intact.
+
+**bopcut **creates a new shape which contains all parts of the second shape but only the first shape without the intersection of the two shapes.
+
+**boptuc **is a reverced** bopcut**.
+
+**bopcommon **creates a new shape which contains only whatever is in common between the two original shapes in their intersection.
+
+
+Syntax: bop shape1 shape2
+bopcommon result
+bopfuse result
+bopcut result
+boptuc result
+
+These commands have short variants:
+
+bcommon result shape1 shape2
+bfuse result shape1 shape2
+bcut result shape1 shape2
+
+
+**bop** fills data structure (DS) of boolean operation for **shape1** and **shape2**.
+**bopcommon, bopfuse, bopcut, boptuc **commands used after **bop** command. After one **bop** command it is possible to call several commands from the list above. For example: **bop** S1 S2; **bopfuse** R.
+
+**Example**
+
+# all four boolean operations on a box and a cylinder
+
+box b 0 -10 5 20 20 10
+pcylinder c 5 20
+
+# fills data structure
+bop b c
+
+bopfuse s1
+ttranslate s1 40 0 0
+
+bopcut s2
+ttranslate s2 -40 0 0
+
+boptuc s3
+ttranslate s3 0 40 0
+
+bopcommon s4
+ttranslate s4 0 -40 0
+
+
+Short variants of commands:
+
+bfuse s11 b c
+ttranslate s11 40 0 100
+
+bcut s12 b c
+ttranslate s12 -40 0 100
+
+bcommon s14 b c
+ttranslate s14 0 -40 100
+
+@subsubsection occt_2142243456_1869436669772 bopsection
+
+**bopsection **creates a compound object consisting of the edges for the intersection curves on the faces of two shapes.
+
+
+Syntax: bop shape1 shape2
+bopsection result
+
+
+
+Short variant:
+
+bsection result shape1 shape2 [-2d/-2d1/-2s2] [-a]
+
+
+**bop** fills data structure (DS) of boolean operation for **shape1** and **shape2**.
+**bopsection** command used after **bop** command.
+
+**-2d** - PCurves are computed on both parts.
+**-2d1** - PCurves are computed on first part.
+**-2d2 **- PCurves are computed on second part.
+**-a** - geometries built are approximated.
+
+
+**Example**
+
+# section line between a cylinder and a box
+pcylinder c 10 20
+box b 0 0 5 15 15 15
+trotate b 0 0 0 1 1 1 20
+bop b c
+bopsection s
+# Short variant:
+bsection s2 b c
+
+
+@subsubsection occt_2142243456_1869436669773 bopcheck, bopargshape
+
+Syntax: bopcheck shape
+bopargcheck shape1 [[shape2] [-F/O/C/T/S/U] [/R|F|T|V|E|I|P]] [#BF]
+
+
+**bopcheck** checks a shape for self-interference.
+
+**bopargcheck** checks the validity of argument(s) for boolean operations.
+
+-Boolean Operation
+ **F** (fuse)
+ **O** (common)
+ **C** (cut)
+ **T** (cut21)
+ **S** (section)
+ **U** (unknown)
+By default a section is made.
+
+ /Test Options
+ **R** (disable small edges (shrank range) test)
+ **F** (disable faces verification test)
+ **T** (disable tangent faces searching test)
+ **V** (disable test possibility to merge vertices)
+ **E** (disable test possibility to merge edges)
+ **I** (disable self-interference test)
+ **P** (disable shape type test)
+By default all options are enabled.
+
+ #Additional Test Options
+ **B** (stop test on first faulty found); default OFF
+ **F** (full output for faulty shapes);
+**By **default the output is made in a short format.
+
+ NOTE: Boolean Operation and Test Options are used only for a couple of argument shapes, except for **I** and **P** options that are always used to test a couple of shapes as well as a single shape.
+
+**Example**
+
+# checks a shape on self-interference
+box b1 0 0 0 1 1 1
+bopcheck b1
+
+# checks the validity of argument for boolean cut operations
+box b2 0 0 0 10 10 10
+bopargcheck b1 b2 -C
+
+
+@subsection occt_2142243456_186943666978 Drafting and blending
+
+Drafting is creation of a new shape by tilting faces through an angle.
+
+Blending is the creation of a new shape by rounding edges to create a fillet.
+
+ * Use the **depouille **command for drafting.
+ * Use the **chamf **command to add a chamfer to an edge
+ * Use the **blend **command for simple blending.
+ * Use **fubl **for a fusion + blending operation.
+ * Use **buildevol**, **mkevol**, **updatevol **to realize varying radius blending.
+
+
+@subsubsection occt_2142243456_1869436669781 depouille
+
+Syntax: dep result shape dirx diry dirz face angle x y x dx dy dz [face angle...]
+
+**depouille **creates a new shape by drafting one or more faces of a shape.
+
+Identify the shape(s) to be drafted, the drafting direction, and the face(s) with an angle and an axis of rotation for each face. You can use dot syntax to identify the faces.
+**Example**
+# draft a face of a box
+box b 10 10 10
+explode b f
+== b_1 b_2 b_3 b_4 b_5 b_6
+
+dep a b 0 0 1 b_2 10 0 10 0 1 0 5
+
+
+@subsubsection occt_2142243456_1869436669782 chamf
+
+Syntax: chamf newname shape edge face S dist
+chamf newname shape edge face dist1 dist2
+chamf newname shape edge face A dist angle
+
+**chamf **creates a chamfer along the edge between faces using:
+
+ * a equal distances from the edge
+ * the edge, a face and distance, a second distance
+ * the edge, a reference face and an angle
+
+Use the dot syntax to select the faces and edges.
+<h5>Example</h5>
+
+# to create a chamfer based on equal distances from the
+edge (45 degree angle)
+# create a box
+box b 1 2 3
+chamf ch b . . S 0.5
+==Pick an object
+# select an edge
+==Pick an object
+# select an adjacent face
+**Example**
+
+# to create a chamfer based on different distances from
+the selected edge
+box b 1 2 3
+chamf ch b . . 0.3 0.4
+==Pick an object
+# select an edge
+==Pick an object
+# select an adjacent face
+**Example**
+
+# to create a chamfer based on a distance from the edge
+and an angle
+box b 1 2 3
+chamf ch b . . A 0.4 30
+==Pick an object
+# select an edge
+==Pick an object
+# select an adjacent face
+
+
+@subsubsection occt_2142243456_1869436669783 blend
+
+Syntax: blend result object rad1 ed1 rad2 ed2 ... [R/Q/P]
+
+**blend **creates a new shape by filleting the edges of an existing shape. The edge must be inside the shape. You may use the dot syntax. Note that the blend is propagated to the edges of tangential planar, cylindrical or conical faces.
+**Example**
+
+# blend a box, click on an edge
+box b 20 20 20
+blend b b 2 .
+==tolerance ang : 0.01
+==tolerance 3d : 0.0001
+==tolerance 2d : 1e-05
+==fleche : 0.001
+==tolblend 0.01 0.0001 1e-05 0.001
+==Pick an object
+# click on the edge you want ot fillet
+
+==COMPUTE: temps total 0.1s dont :
+==- Init + ExtentAnalyse 0s
+==- PerformSetOfSurf 0.02s
+==- PerformFilletOnVertex 0.02s
+==- FilDS 0s
+==- Reconstruction 0.06s
+==- SetRegul 0s
+
+
+@subsubsection occt_2142243456_1869436669784 fubl
+
+Syntax: fubl name shape1 shape2 radius
+** **
+**fubl **creates a boolean fusion of two shapes and then blends (fillets) the intersection edges using the given radius.
+**Example**
+
+# fuse-blend two boxes
+box b1 20 20 5
+copy b1 b2
+ttranslate b2 -10 10 3
+fubl a b1 b2 1
+See also: **fuse**, **blend**
+
+
+@subsubsection occt_2142243456_1869436669785 mkevol, updatevol, buildevol
+
+Syntax: mkevol result object (then use updatevol) [R/Q/P]
+updatevol edge u1 radius1 [u2 radius2 ...]
+buildevol
+
+These three commands work together to create fillets with evolving radii.
+
+**mkevol **allows you to specify the shape and the name of the result. It returns the tolerances of the fillet.
+
+**updatevol **allows you to describe the filleted edges you want to create. For each edge, you give a set of coordinates: parameter and radius and the command prompts you to pick the edge of the shape which you want to modify. The parameters will be calculated along the edges and the radius function applied to the whole edge.
+
+**buildevol **produces the result described previously in **mkevol **and **updatevol**.
+**Example**
+
+# makes an evolved radius on a box
+box b 10 10 10
+mkevol b b
+==tolerance ang : 0.01
+==tolerance 3d : 0.0001
+==tolerance 2d : 1e-05
+==fleche : 0.001
+==tolblend 0.01 0.0001 1e-05 0.001
+
+# click an edge
+updatevol . 0 1 1 3 2 2
+==Pick an object
+
+buildevol
+==Dump of SweepApproximation
+==Error 3d = 1.28548881203818e-14
+==Error 2d = 1.3468326936926e-14 ,
+==1.20292299999388e-14
+==2 Segment(s) of degree 3
+
+==COMPUTE: temps total 0.91s dont :
+==- Init + ExtentAnalyse 0s
+==- PerformSetOfSurf 0.33s
+==- PerformFilletOnVertex 0.53s
+==- FilDS 0.01s
+==- Reconstruction 0.04s
+==- SetRegul 0s
+
+
+
+@subsection occt_2142243456_186943666979 Topological analysis
+
+Analysis of shapes includes commands to compute length, area, volumes and inertial properties.
+
+ * Use **lprops**, **sprops**, **vprops **to compute integral properties.
+ * Use **bounding **to display the bounding box of a shape.
+ * Use **distmini **to calculate the minimum distance between two shapes.
+
+
+
+
+@subsubsection occt_2142243456_1869436669791 lprops, sprops, vprops
+
+Syntax: lprops shape
+sprops shape
+vprops shape
+
+**lprops **computes the mass properties of all edges in the shape with a linear density of 1, **sprops **of all faces with a surface density of 1 and **vprops **of all solids with a density of 1.
+
+All three commands print the mass, the coordinates of the center of gravity, the matrix of inertia and the moments. Mass is either the length, the area or the volume. The center and the main axis of inertia are displayed.
+**Example**
+
+# volume of a cylinder
+pcylinder c 10 20
+vprops c
+== results
+Mass : 6283.18529981086
+
+Center of gravity :
+X = 4.1004749224903e-06
+Y = -2.03392858349861e-16
+Z = 9.9999999941362
+
+Matrix of Inertia :
+366519.141445068 5.71451850691484e-12
+0.257640437382627
+5.71451850691484e-12 366519.141444962
+2.26823064169991e-10 0.257640437382627
+2.26823064169991e-10 314159.265358863
+
+Moments :
+IX = 366519.141446336
+IY = 366519.141444962
+I.Z = 314159.265357595
+
+
+
+@subsubsection occt_2142243456_1869436669792 bounding
+
+Syntax: bounding shape
+
+Displays the bounding box of a shape. The bounding box is a cuboid created with faces parallel to the x, y, and z planes. The command returns the dimension values of the the box, *xmin ymin zmin xmax ymax zmax.*
+**Example**
+
+# bounding box of a torus
+ptorus t 20 5
+bounding t
+==-27.059805107309852 -27.059805107309852 -
+5.0000001000000003
+==27.059805107309852 27.059805107309852
+5.0000001000000003
+
+
+@subsubsection occt_2142243456_1869436669793 distmini
+
+Syntax: distmini name Shape1 Shape2
+
+**distmini **calculates the minimum distance between two shapes. The calculation returns the number of solutions, If more than one solution exists. The options are displayed in the viewer(red) and the results are listed in the shell window. The distmini lines are considered as shapes which have a value v.
+**Example**
+
+box b 0 0 0 10 20 30
+box b2 30 30 0 10 20 30
+distmini d1 b b2
+==the distance value is : 22.3606797749979
+==the number of solutions is :2
+
+==solution number 1
+==the type of the solution on the first shape is 0
+==the type of the solution on the second shape is 0
+==the coordinates of the point on the first shape are:
+==X=10 Y=20 Z=30
+==the coordinates of the point on the second shape
+are:
+==X=30 Y=30 Z=30
+
+==solution number 2:
+==the type of the solution on the first shape is 0
+==the type of the solution on the second shape is 0
+==the coordinates of the point on the first shape are:
+==X=10 Y=20 Z=0
+==the coordinates of the point on the second shape
+are:
+==X=30 Y=30 Z=0
+
+==d1_val d1 d12
+
+
+
+
+@subsection occt_2142243456_1869436669710 Surface creation
+
+Surface creation commands include surfaces created from boundaries and from spaces between shapes.
+
+ * gplate creates a surface from a boundary definition.
+ * filling creates a surface from a group of surfaces.
+
+
+@subsubsection occt_2142243456_18694366697101 gplate,
+
+Syntax: gplate result nbrcurfront nbrpntconst [SurfInit] [edge 0] [edge tang (1:G1;2:G2) surf]...[point] [u v tang (1:G1;2:G2) surf] ...
+
+**gplate **creates a surface from a defined boundary. The boundary can be defined using edges, points, or other surfaces.
+<h5>Example</h5>
+
+plane p
+trim p p -1 3 -1 3
+mkface p p
+
+beziercurve c1 3 0 0 0 1 0 1 2 0 0
+mkedge e1 c1
+tcopy e1 e2
+tcopy e1 e3
+
+ttranslate e2 0 2 0
+trotate e3 0 0 0 0 0 1 90
+tcopy e3 e4
+ttranslate e4 2 0 0
+# create the surface
+gplate r1 4 0 p e1 0 e2 0 e3 0 e4 0
+==
+======== Results ===========
+DistMax=8.50014503228635e-16
+* GEOMPLATE END*
+Calculation time: 0.33
+Loop number: 1
+Approximation results
+Approximation error : 2.06274907619957e-13
+Criterium error : 4.97600631215754e-14
+
+#to create a surface defined by edges and passing through a point
+# to define the border edges and the point
+plane p
+trim p p -1 3 -1 3
+mkface p p
+
+beziercurve c1 3 0 0 0 1 0 1 2 0 0
+mkedge e1 c1
+tcopy e1 e2
+tcopy e1 e3
+
+ttranslate e2 0 2 0
+trotate e3 0 0 0 0 0 1 90
+tcopy e3 e4
+ttranslate e4 2 0 0
+# to create a point
+point pp 1 1 0
+# to create the surface
+gplate r2 4 1 p e1 0 e2 0 e3 0 e4 0 pp
+==
+======== Results ===========
+DistMax=3.65622157610934e-06
+* GEOMPLATE END*
+Calculculation time: 0.27
+Loop number: 1
+Approximation results
+Approximation error : 0.000422195884750181
+Criterium error : 3.43709808053967e-05
+
+@subsubsection occt_2142243456_18694366697102 filling, fillingparam
+
+Syntax: filling result nbB nbC nbP [SurfInit] [edge][face]order...
+edge[face]order... point/u v face order...
+
+**filling **creates a surface between borders. It uses the **gplate **algorithm but creates a surface that is tangential to the adjacent surfaces. The result is a smooth continuous surface based on the G1 criterion.
+
+To define the surface border:
+
+ * enter the number of edges, constraints, and points
+ * enumerate the edges, constraints and points
+
+The surface can pass through other points. These are defined after the border definition.
+
+You can use the **fillingparam **command to access the filling parameters.
+
+The options are:
+
+-l : to list current values
+
+-i : to set default values
+
+-r deg nbPonC nbIt anis : to set filling options
+
+-c t2d t3d tang tcur : to set tolerances
+
+-a maxdeg maxseg : Approximation option
+**Example**
+
+# to create four curved survaces and a point
+plane p
+trim p p -1 3 -1 3
+mkface p p
+
+beziercurve c1 3 0 0 0 1 0 1 2 0 0
+mkedge e1 c1
+tcopy e1 e2
+tcopy e1 e3
+
+ttranslate e2 0 2 0
+trotate e3 0 0 0 0 0 1 90
+tcopy e3 e4
+ttranslate e4 2 0 0
+
+point pp 1 1 0
+
+prism f1 e1 0 -1 0
+prism f2 e2 0 1 0
+prism f3 e3 -1 0 0
+prism f4 e4 1 0 0
+
+# to create a tangential surface
+filling r1 4 0 0 p e1 f1 1 e2 f2 1 e3 f3 1 e4 f4 1
+# to create a tangential surface passing through point pp
+filling r2 4 0 1 p e1 f1 1 e2 f2 1 e3 f3 1 e4 f4 1 pp#
+# to visualise the surface in detail
+isos r2 40
+# to display the current filling parameters
+fillingparam -l
+==
+Degree = 3
+NbPtsOnCur = 10
+NbIter = 3
+Anisotropie = 0
+Tol2d = 1e-05
+Tol3d = 0.0001
+TolAng = 0.01
+TolCurv = 0.1
+
+MaxDeg = 8
+MaxSegments = 9
+
+
+
+
+@subsection occt_2142243456_1869436669711 Complex Topology
+
+Complex topology is the group of commands that modify the topology of shapes. This includes feature modeling.
+
+
+@subsubsection occt_2142243456_18694366697111 offsetshape, offsetcompshape
+
+Syntax: offsetshape r shape offset [tol] [face ...]
+offsetcompshape r shape offset [face ...]
+
+**offsetshape **and **offsetcompshape **assigns a thickness to the edges of a shape. The **offset **value can be negative or positive. This value defines the thickness and direction of the resulting shape. Each face can be removed to create a hollow object.
+
+The resulting shape is based on a calculation of intersections. In case of simple shapes such as a box, only the adjacent intersections are required and you can use the **offsetshape **command.
+
+In case of complex shapes, where intersections can occur from non-adjacent edges and faces, use the **offsetcompshape **command. **comp **indicates complete and requires more time to calculate the result.
+
+
+The opening between the object interior and exterior is defined by the argument face or faces.
+**Example**
+
+box b1 10 20 30
+explode b1 f
+== b1_1 b1_2 b1_3 b1_4 b1_5 b1_6
+offsetcompshape r b1 -1 b1_3
+
+Syntax: offsetparameter tolerance intersection(c/p) join(a/i)
+offsetload shape offset [face1 face2 …]
+offsetonface face1 offset1 face2 offset2 …
+offsetperform result
+
+**offsetparameter** sets the values of parameters and options for the following command **offsetload**:
+ * *tolerance* defines the coincidence tolerance criterion for generated shapes;
+ * *intersection* defines the mode of intersection: *c* means complete intersection, *p* means partial intersection;
+ * *join* defines the mode of connecting new adjacent faces: *a* means GeomAbs_Arc, *i* means GeomAbs_Intersection.
+
+**offsetload** loads shape, offset value and, if necessary, a set of faces to remove from the shape. These data are later used by command **offsetperform**.
+**offsetonface** indicates the faces of shape (loaded earlier by command **offsetload**) that should be shifted with special offset value. This command is optional. **Warning:** this command should be called only after **offsetload** and it takes effect only if parameter join = GeomAbs_Intersection.
+
+**offsetperform** performs the result of 3d-offset algorithm using the data loaded by previous commands.
+**Example**
+
+box b1 10 20 30
+explode b1 f
+== b1_1 b1_2 b1_3 b1_4 b1_5 b1_6
+offsetparameter 1e-7 p i
+offsetload b1 2 b1_1 b1_2
+offsetonface b1_3 5
+offsetperform result
+
+
+
+@subsubsection occt_2142243456_18694366697112 featprism, featdprism, featrevol, featlf, featrf
+
+Syntax: featprism shape element skface Dirx Diry Dirz Fuse(0/1/2) Modify(0/1)
+featdprism shape face skface angle Fuse(0/1/2) Modify(0/1)
+featrevol shape element skface Ox Oy Oz Dx Dy Dz Fuse(0/1/2) Modify(0/1)
+featlf shape wire plane DirX DirY DirZ DirX DirY DirZ Fuse(0/1/2) Modify(0/1)
+featrf shape wire plane X Y Z DirX DirY DirZ Size Size Fuse(0/1/2) Modify(0/1)
+featperform prism/revol/pipe/dprism/lf result [[Ffrom] Funtil]
+featperformval prism/revol/dprism/lf result value
+
+**featprism **loads the arguments for a prism with contiguous sides normal to the face.
+
+**featdprism **loads the arguments for a prism which is created in a direction normal to the face and includes a draft angle.
+
+**featrevol **loads the arguments for a prism with a circular evolution.
+
+**featlf **loads the arguments for a linear rib or slot. This feature uses planar faces and a wire as a guideline.
+
+**featrf **loads the arguments for a rib or slot with a curved surface. This feature uses a circular face and a wire as a guideline.
+
+**featperform **loads the arguments to create the feature.
+
+**featperformval **uses the defined arguments to create a feature with a limiting value.
+
+All the features are created from a set of arguments which are defined when you initialize the feature context. Negative values can be used to create depressions.
+**Example**
+
+# to create a feature prism with a draft angle and a
+normal direction
+# create a box with a wire contour on the upper face
+box b 1 1 1
+profil f O 0 0 1 F 0.25 0.25 x 0.5 y 0.5 x -0.5
+explode b f
+# loads the feature arguments defining the draft angle
+featdprism b f b_6 5 1 0
+# create the feature
+featperformval dprism r 1
+==BRepFeat_MakeDPrism::Perform(Height)
+BRepFeat_Form::GlobalPerform ()
+Gluer
+still Gluer
+Gluer result
+
+# to create a feature prism with circular direction
+# create a box with a wire contour on the upper face
+box b 1 1 1
+profil f O 0 0 1 F 0.25 0.25 x 0.5 y 0.5 x -0.5
+explode b f
+# loads the feature arguments defining a rotation axis
+featrevol b f b_6 1 0 1 0 1 0 1 0
+featperformval revol r 45
+==BRepFeat_MakeRevol::Perform(Angle)
+BRepFeat_Form::GlobalPerform ()
+Gluer
+still Gluer
+Gluer result
+
+# to create a slot using the linear feature
+#create the base model using the multi viewer
+mu4
+profile p x 5 y 1 x -3 y -0.5 x -1.5 y 0.5 x 0.5 y 4 x -1 y -5
+prism pr p 0 0 1
+# create the contour for the linear feature
+vertex v1 -0.2 4 0.3
+vertex v2 0.2 4 0.3
+vertex v3 0.2 0.2 0.3
+vertex v4 4 0.2 0.3
+vertex v5 4 -0.2 0.3
+edge e1 v1 v2
+edge e2 v2 v3
+edge e3 v3 v4
+edge e4 v4 v5
+wire w e1 e2 e3 e4
+# define a plane
+plane pl 0.2 0.2 0.3 0 0 1
+# loads the linear feature arguments
+featlf pr w pl 0 0 0.3 0 0 0 0 1
+featperform lf result
+
+# to create a rib using the revolution feature
+#create the base model using the multi viewer
+mu4
+pcylinder c1 3 5
+# create the contour for the revolution feature
+profile w c 1 190 WW
+trotate w 0 0 0 1 0 0 90
+ttranslate w -3 0 1
+trotate w -3 0 1.5 0 0 1 180
+plane pl -3 0 1.5 0 1 0
+# loads the revolution feature arguments
+featrf c1 w pl 0 0 0 0 0 1 0.3 0.3 1 1
+featperform rf result
+
+
+@subsubsection occt_2142243456_18694366697113 draft
+
+Syntax: draft result shape dirx diry dirz angle shape/surf/length [-IN/-OUT] [Ri/Ro] [-Internal]
+
+**draft **computes a draft angle surface from a wire. The surface is determined by the draft direction, the inclination of the draft surface, a draft angle, and a limiting distance.
+
+ * The draft angle is measured in radians.
+ * The draft direction is determined by the argument -INTERNAL
+ * The argument Ri/Ro deftermines wether the corner edges of the
+
+draft surface are angular or rounded.
+
+ * Arguments that can be used to define the surface distance are:
+ * length, a defined distance
+ * shape, until the surface contacts a shape
+ * surface, until the surface contacts a surface.
+
+<h4>NOTE</h4>
+*The original aim of adding a draft angle to a shape is to*
+*produce a shape which can be removed easily from a mould.*
+*The Examples below use larger angles than are used normally*
+*and the calculation results returned are not indicated.*
+
+**Example**
+
+# to create a simple profile
+profile p F 0 0 x 2 y 4 tt 0 4 w
+# creates a draft with rounded angles
+draft res p 0 0 1 3 1 -Ro
+# to create a profile with an internal angle
+profile p F 0 0 x 2 y 4 tt 1 1.5 tt 0 4 w
+# creates a draft with rounded external angles
+draft res p 0 0 1 3 1 -Ro
+
+
+@subsubsection occt_2142243456_18694366697114 deform, nurbsconvert
+
+Syntax: deform newname name CoeffX CoeffY CoeffZ
+
+**deform **modifies the shape using the x, y, and z coefficients. You can reduce or magnify the shape in the x,y, and z directions.
+
+Syntax nurbsconvert result name [result name]
+
+**nurbsconvert **changes the NURBS curve definition of a shape to a Bspline curve definition. This conversion is required for assymetric deformation and prepares the arguments for other commands such as **deform. **The conversion can be necessary when transferring shape data to other applications.
+**Example**
+
+pcylinder c 20 20
+deform a c 1 3 5
+# the conversion to bspline is followed by the
+deformation
+
+
+
+@subsection occt_2142243456_1869436669712 Texture Mapping to a Shape
+
+Texture mapping allows you to map textures on a shape. Textures are texture image files and several are predefined. You can control the number of occurrences of the texture on a face, the position of a texture and the scale factor of the texture.
+
+@subsubsection occt_2142243456_18694366697121 vtexture
+
+Syntax vtexture NameOfShape TextureFile
+vtexture NameOfShape
+vtexture NameOfShape ?
+vtexture NameOfShape IdOfTexture
+
+**TextureFile **identifies the file containing the texture you want. The same syntax without **TextureFile **disables texture mapping. The question-mark ***?* **lists available textures. **IdOfTexture **allows you to apply predefined textures.
+
+@subsubsection occt_2142243456_18694366697122 vtexscale
+
+Syntax: vtexscale NameOfShape ScaleU ScaleV
+vtexscale NameOfShape ScaleUV
+vtexscale NameOfShape
+
+**ScaleU **and **Scale V **allow you to scale the texture according to the U and V parameters individually, while **ScaleUV **applies the same scale to both parameters. The same syntax without **ScaleU**, **ScaleV **or **ScaleUV **disables texture scaling.
+
+@subsubsection occt_2142243456_18694366697123 vtexorigin
+
+Syntax vtexorigin NameOfShape UOrigin VOrigin
+vtexorigin NameOfShape UVOrigin
+vtexorigin NameOfShape
+
+**UOrigin **and **VOrigin **allow you to place the texture according to the U and V parameters individually while **UVOrigin **applies the same position value to both parameters. The same syntax without **UOrigin**, **VOrigin **or **UVOrigin **disables origin positioning.
+
+@subsubsection occt_2142243456_18694366697124 vtexrepeat
+
+Syntax vtexrepeat NameOfShape URepeat VRepeat
+vtexrepeat NameOfShape UVRepeat
+vtexrepeat NameOfShape
+
+**URepeat **and **VRepeat **allow you to repeat the texture along the U and V parameters individually while **UVRepeat **applies the same number of repetitions for both parameters. The same syntax without **URepeat**, **VRepeat **or **UVRepeat **disables texture repetition.
+
+@subsubsection occt_2142243456_18694366697125 vtexdefault
+
+Syntax vtexdefault NameOfShape
+
+**Vtexdefault **sets or resets the texture mapping default parameters.
+
+The defaults are:
+
+URepeat = VRepeat = 1 = no repetition
+UOrigin = VOrigin = 1 = origin set at (0,0)
+UScale = VScale = 1 = texture covers 100% of the face
+@section occt_2142243456_1866931135 Data Exchange commands
+
+
+@subsection occt_2142243456_186693113581 General
+
+This paragraph presents some general information about Data Exchange (DE) operations.
+
+DE commands are intended for translation files of various formats (IGES,STEP) into OCCT shapes with their attributes (colors, layers etc.)
+
+This files include a number of entities. Each entity has its own number in the file which we call label and denote as # for a STEP file and D for an IGES file. Each file has entities called roots (one or more). A full description of such entities is contained in the Users’s Guide for a corresponding format.
+
+Each Draw session has an interface model – some structure for keeping various information.
+First step of translation – loading information from a file into a model.
+Second step – creation of an OpenCASCADE shape from this model.
+Each entity from file has its own number in the model (num).
+During the translation a map of correspondences between labels(from file) and numbers (from model) is created.
+The model and the mentioned map are used for working with most of DE commands.
+
+@subsection occt_2142243456_186693113582 IGES commands
+
+These commands are used during the translation of IGES models.
+
+
+@subsubsection occt_2142243456_1866931135821 igesread
+
+Syntax: igesread file_name result_shape_name [selection]
+
+Read an IGES file to an OCCT shape.
+This command will interactively ask the user to select a set of entities to be converted:
+
+
+After the selected set of entities is loaded the user will be asked how loaded entities should be converted into OCCT shapes (e.g., one shape per root or one shape for all the entities). It is also possible to save loaded shapes in files, and to cancel loading.
+The second parameter of this command defines the name of the loaded shape. If several shapes are created, they will get indexed names. For instance, if the last parameter was ‘s’, they will be s_1, ... s_N.
+selection specifies the scope of selected entities in the model, it is xst-transferrable-roots by default. More about selection see in the *IGES FORMAT User’s Guide*.
+If we use symbol * as selection all roots will be translated.
+<h5>Example</h5>
+
+# translation all roots from file
+igesread /disk01/files/model.igs a *
+
+@subsubsection occt_2142243456_1866931135822 tplosttrim
+
+Syntax: tplosttrim [IGES_type]
+
+Sometimes the trimming contours of IGES faces (i.e., entity 141 for 143, 142 for 144) can be lost during translation due to fails. This command gives us a number of lost trims and the number of corresponding IGES entities.
+It outputs the rank and numbers of faces that lost their trims and their numbers for each type (143, 144, 510) and their total number. If a face lost several of its trims it is output only once.
+Optional parameter IGES_type can be TrimmedSurface, BoundedSurface or Face to specify the only type of IGES faces.
+<h5>Example</h5>
+
+tplosttrim TrimmedSurface
+
+@subsubsection occt_2142243456_1866931135823 brepiges
+
+Syntax: brepiges shape_name filename.igs
+
+Writes an OCCT shape to an IGES file.
+**Example**
+
+# write shape with name aa to IGES file
+brepiges aa /disk1/tmp/aaa.igs
+== unit (write) : MM
+== mode write : Faces
+== To modifiy : command param
+== 1 Shapes written, giving 345 Entities
+== Now, to write a file, command : writeall filename
+== Output on file : /disk1/tmp/aaa.igs
+== Write OK
+
+
+
+@subsection occt_2142243456_186693113583 STEP commands
+
+These commands are used during the translation of STEP models.
+
+
+@subsubsection occt_2142243456_1866931135831 stepread
+
+Syntax: stepread file_name result_shape_name [selection]
+
+Read a STEP file to an OCCT shape.
+This command will interactively ask the user to select a set of entities to be converted:
+
+
+After the selected set of entities is loaded the user will be asked how loaded entities should be converted into OCCT shapes.
+The second parameter of this command defines the name of the loaded shape. If several shapes are created, they will get indexed names. For instance, if the last parameter was ‘s’, they will be s_1, ... s_N.
+selection specifies the scope of selected entities in the model. More about selection see in the *STEP FORMAT User’s Guide*.
+If as selection we use symbol * all roots will be translated.
+<h5>Example</h5>
+
+# translation all roots from file
+stepread /disk01/files/model.stp a *
+
+@subsubsection occt_2142243456_1866931135832 stepwrite
+
+Syntax: stepwrite mode shape_name file_name
+
+Writes an OCCT shape to a STEP file.
+The available modes are the following:
+ 0 or ‘a’ - ;as is; mode – mode is selected automatically depending on type & geometry of the shape
+ 1 or ‘m’ - manifold_solid_brep or brep_with_voids
+ 2 or ‘f’ - faceted_brep
+ 3 or ‘w’ - geometric_curve_set
+ 4 or ‘s’ - shell_based_surface_model
+For further information see ;STEP FORMAT User’s Guide ;.
+<h5>Example</h5>
+
+# write shape with name a to STEP file with mode 0
+stepwrite 0 a /disk1/tmp/aaa.igs
+
+
+
+@subsection occt_2142243456_186693113584 General commands
+
+These commands are auxilary commands. Most of them are used for the analysis of result of translation of IGES and STEP files.
+
+@subsubsection occt_2142243456_1866931135841 count
+
+Syntax: count counter [selection]
+
+Is used to calculate statistics on the entities in the model.
+Gives us a count of entities.
+The optional selection argument, if specified, defines a subset of entities, which are to be taken into account. The first argument should be one of the currently defined counters (for example):
+
+<h5>Example</h5>
+
+count xst-types
+
+@subsubsection occt_2142243456_1866931135842 data
+
+Syntax: data symbol
+
+Is used to obtain general statistics on the loaded data.
+Information printed by this command depends on the symbol specified:
+<h5>Example</h5>
+
+# print full information about warnings and fails
+data c
+
+@subsubsection occt_2142243456_1866931135843 elabel
+
+Syntax: elabel num
+
+Entities in the IGES and STEP files are numbered in the succeeding order. An entity can be identified either by its number or by its label. Label is the letter ‘#'(for STEP, for IGES use ‘D’) followed by the rank. This command gives us a label for an entity with a known number.
+<h5>Example</h5>
+
+elabel 84
+
+@subsubsection occt_2142243456_1866931135844 entity
+
+Syntax: entity #(D)_or_num level_of_information
+
+The content of an IGES or STEP entity can be obtained by using this command.
+Entity can be determined by its number or label.
+level_of_information has range [0-6]. You can get more information about this level using this command without parameters.
+<h5>Example</h5>
+
+# full information for STEP entity with label 84
+entity #84 6
+
+@subsubsection occt_2142243456_1866931135845 enum
+
+Syntax: enum #(D)
+
+Prints a number for the entity with a given label.
+<h5>Example</h5>
+
+# give a number for IGES entity with label 21
+enum D21
+
+@subsubsection occt_2142243456_1866931135846 estatus
+
+Syntax: estatus #(D)_or_num
+
+The list of entities referenced by a given entity and the list of entities referencing to it can be obtained by this command.
+<h5>Example</h5>
+
+estatus #315
+
+@subsubsection occt_2142243456_1866931135847 fromshape
+
+Syntax: fromshape shape_name
+
+Gives us the number of an IGES or STEP entity corresponding to an OCCT shape. If no corresponding entity can be found and if OCCT shape is a compound the command explodes it to subshapes and try to find corresponding entities for them.
+<h5>Example</h5>
+
+fromshape a_1_23
+
+@subsubsection occt_2142243456_1866931135848 givecount
+
+Syntax: givecount selection_name [selection_name]
+
+<h5>Example</h5>
+
+givecount xst-model-roots
+
+@subsubsection occt_2142243456_1866931135849 givelist
+
+Syntax: givelist selection_name
+
+Prints a list of a subset of loaded entities defined by the selection argument:
+
+<h5>Example</h5>
+
+# give a list of all entities of the model
+givelist xst-model-all
+
+@subsubsection occt_2142243456_18669311358410 listcount
+
+Syntax: listcount counter [selection ...]
+
+Prints a list of entities per each type matching the criteria defined by arguments.
+Optional selection argument, if specified, defines a subset of entities, which are to be taken into account. Argument counter should be one of the currently defined counters:
+
+<h5>Example</h5>
+
+listcount xst-types
+
+@subsubsection occt_2142243456_18669311358411 listitems
+
+Syntax: listitems
+
+This command prints a list of objects (counters, selections etc.) defined in the current session.
+<h5>Example</h5>
+
+listitems
+
+@subsubsection occt_2142243456_18669311358412 listtypes
+
+Syntax: listtypes [selection_name ...]
+
+Gives a list of entity types which were encountered in the last loaded file (with a number of entities of each type). The list can be shown not for all entities but for a subset of them. This subset is defined by an optional selection argument.
+<h5>Example</h5>
+
+# full list of all entities with thier counts
+listtypes
+
+@subsubsection occt_2142243456_18669311358413 newmodel
+
+Syntax: newmodel
+
+Clears the current model.
+<h5>Example</h5>
+
+newmodel
+
+@subsubsection occt_2142243456_18669311358414 param
+
+Syntax: param [parameter] [value]
+
+This command is used to manage translation parameters.
+Command without arguments gives us a full list of parameters with current values.
+Command with parameter (without value) gives us the current value of this parameter and all possible values for it. Command with value sets this new value to parameter.
+For more information about translation parameters see the corresponding User’s Guide.
+<h5>Example</h5>
+
+# info about possible schemes for writing STEP file
+param write.step.schema
+
+@subsubsection occt_2142243456_18669311358415 sumcount
+
+Syntax: sumcount counter [selection ...]
+
+Prints only a number of entities per each type matching the criteria defined by arguments.
+<h5>Example</h5>
+
+sumcount xst-types
+
+@subsubsection occt_2142243456_18669311358416 tpclear
+
+Syntax: tpclear
+
+Clears the map of correspondences between IGES or STEP entities and OCCT shapes.
+<h5>Example</h5>
+
+tpclear
+
+@subsubsection occt_2142243456_18669311358417 tpdraw
+
+Syntax: tpdraw #(D)_or_num
+
+<h5>Example</h5>
+
+tpdraw 57
+
+@subsubsection occt_2142243456_18669311358418 tpent
+
+Syntax: tpent #(D)_or_num
+
+<h5>Example</h5>
+
+tpent #23
+
+@subsubsection occt_2142243456_18669311358419 tpstat
+
+Syntax: tpstat [*|?]symbol [selection]
+
+Gives all statistics on the last transfer, including the list of transferred entities with mapping from IGES or STEP to OCCT types, as well as fail and warning messages. The parameter *symbol *defines what information will be printed:
+
+
+The sign ‘*’ before the parameters **n**, **s**, **b**, **t**, **r** makes it work on all entities (not only on roots). The sign ‘?’ before **n**, **s**, **b**, **t** limits the scope of information to invalid entities.
+Optional argument selection can limit the action of the command with a selected subset of entities.
+<h5>Example</h5>
+
+# translation ratio on IGES faces
+tpstat *l iges-faces
+
+@subsubsection occt_2142243456_18669311358420 xload
+
+Syntax: xload file_name
+
+This command loads an IGES or STEP file into memory (i.e. to fill the model with data from the file) without creation of an OCCT shape.
+<h5>Example</h5>
+
+xload /disk1/tmp/aaa.stp
+
+
+
+@subsection occt_2142243456_186693113585 Overview of XDE commands
+
+These commands are used for translation of IGES and STEP files into an XCAF document (special document is inherited from CAF document and is intended for Extended Data Exchange (XDE) ) and working with it. XDE translation allows reading and writing of shapes with additional attributes – colors, layers etc. All commands can be divided into the following groups:
+ * **XDE translation commands**
+ * **XDE general commands**
+ * **XDE shape’s commands**
+ * **XDE color’s commands**
+ * **XDE layer’s commands**
+ * **XDE property’s commands**
+
+
+
+@subsection occt_2142243456_186693113586 XDE translation commands
+
+Reminding: All operations of translation are performed with parameters managed by command param (see above)
+
+@subsubsection occt_2142243456_1866931135861 ReadIges
+
+Syntax: ReadIges document file_name
+
+Reads information from an IGES file to an XCAF document.
+<h5>Example</h5>
+
+ReadIges D /disk1/tmp/aaa.igs
+== Document saved with name D
+
+@subsubsection occt_2142243456_1866931135862 ReadStep
+
+Syntax: ReadStep document file_name
+
+Reads information from a STEP file to an XCAF document.
+<h5>Example</h5>
+
+ReadStep D /disk1/tmp/aaa.stp
+== Document saved with name D
+
+@subsubsection occt_2142243456_1866931135863 WriteIges
+
+Syntax: WriteIges document file_name
+
+<h5>Example</h5>
+
+WriteIges D /disk1/tmp/aaa.igs
+
+@subsubsection occt_2142243456_1866931135864 WriteStep
+
+Syntax: WriteStep document file_name
+
+Writes information from an XCAF document to a STEP file.
+<h5>Example</h5>
+
+WriteStep D /disk1/tmp/aaa.stp
+
+@subsubsection occt_2142243456_1866931135865 XFileCur
+
+Syntax: XFileCur
+
+Returns the name of file which is set as the current one in the Draw session.
+<h5>Example</h5>
+
+XFileCur
+== *as1-ct-203.stp*
+
+@subsubsection occt_2142243456_1866931135866 XFileList
+
+Syntax: XFileList
+
+Returns a list all files that were transferred by the last transfer. This command is meant (assigned) for the assemble step file.
+<h5>Example</h5>
+
+XFileList
+== *as1-ct-Bolt.stp*
+== *as1-ct-L-Bracktet.stp*
+== *as1-ct-LBA.stp*
+== *as1-ct-NBA.stp*
+== …
+
+@subsubsection occt_2142243456_1866931135867 XFileSet
+
+Syntax: XFileSet filename
+
+Sets the current file taking it from the components list of the assemble file.
+<h5>Example</h5>
+
+XFileSet as1-ct-NBA.stp
+
+@subsubsection occt_2142243456_1866931135868 XFromShape
+
+Syntax: XFromShape shape
+
+This command is similar to command *fromshape* (see above) but gives additional information about the name of file. It is useful in the case when a shape was translated from several files.
+<h5>Example</h5>
+
+XFromShape a
+== Shape a: imported from entity 217:#26 in file as1-ct-Nut.stp
+
+
+@subsection occt_2142243456_186693113587 XDE general commands
+
+@subsubsection occt_2142243456_1866931135871 XNewDoc
+
+Syntax: XNewDoc document
+
+Creates a new XCAF document.
+<h5>Example</h5>
+
+XNewDoc D
+
+@subsubsection occt_2142243456_1866931135872 XShow
+
+Syntax: XShow document [ label1 … ]
+
+Shows a shape from a given label in the 3D viewer. If the label is not given – shows all shapes from the document.
+<h5>Example</h5>
+
+# show shape from label 0:1:1:4 from document D
+XShow D 0:1:1:4
+
+@subsubsection occt_2142243456_1866931135873 XStat
+
+Syntax: XStat document
+
+Prints common information from an XCAF document.
+<h5>Example</h5>
+
+XStat D
+==Statistis of shapes in the document:
+==level N 0 : 9
+==level N 1 : 18
+==level N 2 : 5
+==Total number of labels for shapes in the document = 32
+==Number of labels with name = 27
+==Number of labels with color link = 3
+==Number of labels with layer link = 0
+==Statistis of Props in the document:
+==Number of Centroid Props = 5
+==Number of Volume Props = 5
+==Number of Area Props = 5
+==Number of colors = 4
+==BLUE1 RED YELLOW BLUE2
+==Number of layers = 0
+
+@subsubsection occt_2142243456_1866931135874 XWdump
+
+Syntax: XWdump document filename
+
+Saves the contents of the viewer window as an image (XWD, png or BMP file).
+filename must have a corresponding extention.
+<h5>Example</h5>
+
+XWdump D /disk1/tmp/image.png
+
+@subsubsection occt_2142243456_1866931135875 Xdump
+
+Syntax: Xdump document [int deep {0|1}]
+
+Prints information about the tree structure of the document. If parameter 1 is given, then the tree is printed with a link to shapes.
+<h5>Example</h5>
+
+Xdump D 1
+== ASSEMBLY 0:1:1:1 L-BRACKET(0xe8180448)
+== ASSEMBLY 0:1:1:2 NUT(0xe82151e8)
+== ASSEMBLY 0:1:1:3 BOLT(0xe829b000)
+== ASSEMBLY 0:1:1:4 PLATE(0xe8387780)
+== ASSEMBLY 0:1:1:5 ROD(0xe8475418)
+== ASSEMBLY 0:1:1:6 AS1(0xe8476968)
+== ASSEMBLY 0:1:1:7 L-BRACKET-ASSEMBLY(0xe8476230)
+== ASSEMBLY 0:1:1:1 L-BRACKET(0xe8180448)
+== ASSEMBLY 0:1:1:8 NUT-BOLT-ASSEMBLY(0xe8475ec0)
+== ASSEMBLY 0:1:1:2 NUT(0xe82151e8)
+== ASSEMBLY 0:1:1:3 BOLT(0xe829b000)
+etc.
+
+
+@subsection occt_2142243456_186693113588 XDE shape’s commands
+
+@subsubsection occt_2142243456_1866931135881 XAddComponent
+
+Syntax: XAddComponent document label shape
+
+Adds a component shape to assembly.
+<h5>Example</h5>
+
+# Add shape b as component shape to assembly shape from
+# label 0:1:1:1
+XAddComponent D 0:1:1:1 b
+
+@subsubsection occt_2142243456_1866931135882 XAddShape
+
+Syntax: XAddShape document shape [makeassembly=1]
+
+Adds a shape (or an assembly) to a document. If this shape already exists in the document, then prints the label which points to it. By default, a new shape is added as an assembly (i.e. last parameter 1), otherwise it is necessary to pass 0 as the last parameter.
+<h5>Example</h5>
+
+# add shape b to document D
+XAddShape D b 0
+== 0:1:1:10
+# if pointed shape is compound and last parameter in
+# XAddShape command is used by default (1), then for
+# each subshapes new label is created
+
+@subsubsection occt_2142243456_1866931135883 XFindComponent
+
+Syntax: XFindComponent document shape
+
+Prints a sequence of labels of the assembly path.
+<h5>Example</h5>
+
+XFindComponent D b
+
+@subsubsection occt_2142243456_1866931135884 XFindShape
+
+Syntax: XFindShape document shape
+
+Finds and prints a label with an indicated top-level shape.
+<h5>Example</h5>
+
+XFindShape D a
+
+@subsubsection occt_2142243456_1866931135885 XGetFreeShapes
+
+Syntax: XGetFreeShapes document [shape_prefix]
+
+Print labels or create DRAW shapes for all free shapes in the document.
+If [shape_prefix] is absent – prints labels, else – creates DRAW shapes with names
+[shape_prefix]_num (i.e. for example: there are 3 free shapes and [shape_prefix] = a therefore shapes will be created with names a_1, a_2 and a_3).
+Note: a free shape is a shape to which no other shape refers to.
+<h5>Example</h5>
+
+XGetFreeShapes D
+== 0:1:1:6 0:1:1:10 0:1:1:12 0:1:1:13
+
+XGetFreeShapes D sh
+== sh_1 sh_2 sh_3 sh_4
+
+@subsubsection occt_2142243456_1866931135886 XGetOneShape
+
+Syntax: XGetOneShape shape document
+
+Creates one DRAW shape for all free shapes from a document.
+<h5>Example</h5>
+
+XGetOneShape a D
+
+@subsubsection occt_2142243456_1866931135887 XGetReferredShape
+
+Syntax: XGetReferredShape document label
+
+Prints a label that contains a top-level shape that corresponds to a shape at a given label.
+<h5>Example</h5>
+
+XGetReferredShape D 0:1:1:1:1
+
+@subsubsection occt_2142243456_1866931135888 XGetShape
+
+Syntax: XGetShape result document label
+
+Puts a shape from the indicated label in document to result.
+<h5>Example</h5>
+
+XGetShape b D 0:1:1:3
+
+@subsubsection occt_2142243456_1866931135889 XGetTopLevelShapes
+
+Syntax: XGetTopLevelShapes document
+
+Prints labels that contain top-level shapes.
+<h5>Example</h5>
+
+XGetTopLevelShapes D
+== 0:1:1:1 0:1:1:2 0:1:1:3 0:1:1:4 0:1:1:5 0:1:1:6 0:1:1:7
+0:1:1:8 0:1:1:9
+
+@subsubsection occt_2142243456_18669311358810 XLabelInfo
+
+Syntax: XLabelInfo document label
+
+Prints information about a shape, stored at an indicated label.
+**Example**
+
+XLabelInfo D 0:1:1:6
+== There are TopLevel Shape. There are an Assembly. This Shape don’t used.
+
+@subsubsection occt_2142243456_18669311358811 XNewShape
+
+Syntax: XNewShape document
+
+Creates a new empty top-level shape.
+<h5>Example</h5>
+
+XNewShape D
+
+@subsubsection occt_2142243456_18669311358812 XRemoveComponent
+
+Syntax: XRemoveComponent document label
+
+Removes a component from the components label.
+<h5>Example</h5>
+
+XRemoveComponent D 0:1:1:1:1
+
+@subsubsection occt_2142243456_18669311358813 XRemoveShape
+
+Syntax: XRemoveShape document label
+
+Removes a shape from a document (by it’s label).
+<h5>Example</h5>
+
+XRemoveShape D 0:1:1:2
+
+@subsubsection occt_2142243456_18669311358814 XSetShape
+
+Syntax: XSetShape document label shape
+
+Sets a shape at the indicated label.
+<h5>Example</h5>
+
+XSetShape D 0:1:1:3 b
+
+
+@subsection occt_2142243456_186693113589 XDE color’s commands
+
+@subsubsection occt_2142243456_1866931135891 XAddColor
+
+Syntax: XAddColor document R G B
+
+Adds color in document to the color table. Parameters R,G,B are real.
+<h5>Example</h5>
+
+XAddColor D 0.5 0.25 0.25
+
+@subsubsection occt_2142243456_1866931135892 XFindColor
+
+Syntax: XFindColor document R G B
+
+Finds a label where the indicated color is situated.
+<h5>Example</h5>
+
+XFindColor D 0.25 0.25 0.5
+== 0:1:2:2
+
+@subsubsection occt_2142243456_1866931135893 XGetAllColors
+
+Syntax: XGetAllColors document
+
+Prints all colors that are defined in the document.
+<h5>Example</h5>
+
+XGetAllColors D
+== RED DARKORANGE BLUE1 GREEN YELLOW3
+
+@subsubsection occt_2142243456_1866931135894 XGetColor
+
+Syntax: XGetColor document label
+
+Returns a color defined at the indicated label from the color table.
+<h5>Example</h5>
+
+XGetColor D 0:1:2:3
+== BLUE1
+
+@subsubsection occt_2142243456_1866931135895 XGetObjVisibility
+
+Syntax: XGetObjVisibility document {label|shape}
+
+Returns the visibility of a shape.
+<h5>Example</h5>
+
+XGetObjVisibility D 0:1:1:4
+
+@subsubsection occt_2142243456_1866931135896 XGetShapeColor
+
+Syntax: XGetShapeColor document label colortype(s|c)
+
+Returns the color defined by label. If colortype=’s’ – returns surface color, else – returns curve color.
+<h5>Example</h5>
+
+XGetShapeColor D 0:1:1:4 c
+
+@subsubsection occt_2142243456_1866931135897 XRemoveColor
+
+Syntax: XRemoveColor document label
+
+Removes a color from the color table in a document.
+<h5>Example</h5>
+
+XRemoveColor D 0:1:2:1
+
+@subsubsection occt_2142243456_1866931135898 XSetColor
+
+Syntax: XSetColor document {label|shape} R G B
+
+Sets an RGB color to a shape given by label.
+<h5>Example</h5>
+
+XsetColor D 0:1:1:4 0.5 0.5 0.
+
+@subsubsection occt_2142243456_1866931135899 XSetObjVisibility
+
+Syntax: XSetObjVisibility document {label|shape} {0|1}
+
+Sets the visibility of a shape.
+<h5>Example</h5>
+
+# set shape from label 0:1:1:4 as invisible
+XSetObjVisibility D 0:1:1:4 0
+
+@subsubsection occt_2142243456_18669311358910 XUnsetColor
+
+Syntax: XUnsetColor document {label|shape} colortype
+
+Unset a color given??? type (‘s’ or ‘c’) for the indicated shape.
+<h5>Example</h5>
+
+XUnsetColor D 0:1:1:4 s
+
+
+@subsection occt_2142243456_1866931135810 XDE layer’s commands
+
+@subsubsection occt_2142243456_18669311358101 XAddLayer
+
+Syntax: XAddLayer document layer
+
+Adds a new layer in an XCAF document. layer - name of new layer (string).
+<h5>Example</h5>
+
+XAddLayer D layer2
+
+@subsubsection occt_2142243456_18669311358102 XFindLayer
+
+Syntax: XFindLayer document layer
+
+Prints a label where a layer is situated.
+<h5>Example</h5>
+
+XFindLayer D Bolt
+== 0:1:3:2
+
+@subsubsection occt_2142243456_18669311358103 XGetAllLayers
+
+Syntax: XGetAllLayers document
+
+Prints all layers in an XCAF document.
+<h5>Example</h5>
+
+XGetAllLayers D
+== *0:1:1:3* *Bolt* *0:1:1:9*
+
+@subsubsection occt_2142243456_18669311358104 XGetLayers
+
+Syntax: XGetLayers document {shape|label}
+
+Returns names of layers, which are pointed to by links of an indicated shape.
+<h5>Example</h5>
+
+XGetLayers D 0:1:1:3
+== *bolt* *123*
+
+@subsubsection occt_2142243456_18669311358105 XGetOneLayer
+
+Syntax: XGetOneLayer document label
+
+Prints the name of a layer at a given label.
+<h5>Example</h5>
+
+XGetOneLayer D 0:1:3:2
+
+@subsubsection occt_2142243456_18669311358106 XIsVisible
+
+Syntax: XIsVisible document {label|layer}
+
+Returns 1 if the indicated layer is visible, else returns 0.
+<h5>Example</h5>
+
+XIsVisible D 0:1:3:1
+
+@subsubsection occt_2142243456_18669311358107 XRemoveAllLayers
+
+Syntax: XRemoveAllLayers document
+
+Removes all layers from an XCAF document.
+<h5>Example</h5>
+
+XRemoveAllLayers D
+
+@subsubsection occt_2142243456_18669311358108 XRemoveLayer
+
+Syntax: XRemoveLayer document {label|layer}
+
+Removes the indicated layer from an XCAF document.
+<h5>Example</h5>
+
+XRemoveLayer D layer2
+
+@subsubsection occt_2142243456_18669311358109 XSetLayer
+
+Syntax: XSetLayer document {shape|label} layer
+ [shape_in_one_layer {0|1}]
+
+Sets a reference between a shape and a layer (adds a layer if it is necessary).
+Parameter shape_in_one_layer shows whether a shape could be in a number of layers or only in one (0 by default).
+<h5>Example</h5>
+
+XSetLayer D 0:1:1:2 layer2
+
+@subsubsection occt_2142243456_186693113581010 XSetVisibility
+
+Syntax: XSetVisibility document {label|layer} isvisible {0|1}
+
+Sets the visibility of a layer.
+<h5>Example</h5>
+
+# set layer at label 0:1:3:2 as invisible
+XSetVisibility D 0:1:3:2 0
+
+@subsubsection occt_2142243456_186693113581011 XUnSetAllLayers
+
+Syntax: XUnSetAllLayers document {label|shape}
+
+Unsets a shape from all layers.
+<h5>Example</h5>
+
+XUnSetAllLayers D 0:1:1:2
+
+@subsubsection occt_2142243456_186693113581012 XUnSetLayer
+
+Syntax: XUnSetLayer document {label|shape} layer
+
+Unsets a shape from the indicated layer.
+<h5>Example</h5>
+
+XUnSetLayer D 0:1:1:2 layer1
+
+
+@subsection occt_2142243456_1866931135811 XDE property’s commands
+
+@subsubsection occt_2142243456_18669311358111 XCheckProps
+
+Syntax: XCheckProps document [ {0|deflection} [shape|label] ]
+
+Gets properties for a given shape (volume, area and centroid) and compares them with the results after internal calculations. If the second parameter is 0, the standard OCCT tool is used for the computation of properties. If the second parameter is not 0, it is treated as a deflection. If the deflection is positive the computation is done by triangulations, if it is negative – meshing is forced.
+<h5>Example</h5>
+
+# check properties for shapes at label 0:1:1:1 from
+# document using standard Open CASCADE Technology tools
+XCheckProps D 0 0:1:1:1
+== Label 0:1:1:1 ;L-BRACKET*
+== Area defect: -0.0 ( 0%)
+== Volume defect: 0.0 ( 0%)
+== CG defect: dX=-0.000, dY=0.000, dZ=0.000
+
+@subsubsection occt_2142243456_18669311358112 XGetArea
+
+Syntax: XGetArea document {shape|label}
+
+Returns the area of a given shape.
+<h5>Example</h5>
+
+XGetArea D 0:1:1:1
+== 24628.31815094999
+
+@subsubsection occt_2142243456_18669311358113 XGetCentroid
+
+Syntax: XGetCentroid document {shape|label}
+
+Returns the center of gravity coordinates of a given shape.
+<h5>Example</h5>
+
+XGetCentroid D 0:1:1:1
+
+@subsubsection occt_2142243456_18669311358114 XGetVolume
+
+Syntax: XGetVolume document {shape|label}
+
+Returns the volume of a given shape.
+<h5>Example</h5>
+
+XGetVolume D 0:1:1:1
+
+@subsubsection occt_2142243456_18669311358115 XSetArea
+
+Syntax: XSetArea document {shape|label} area
+
+Sets new area to attribute list ??? given shape.
+<h5>Example</h5>
+
+XSetArea D 0:1:1:1 2233.99
+
+@subsubsection occt_2142243456_18669311358116 XSetCentroid
+
+Syntax: XSetCentroid document {shape|label} x y z
+
+Sets new center of gravity to the attribute list ??? given shape.
+<h5>Example</h5>
+
+XSetCentroid D 0:1:1:1 0. 0. 100.
+
+@subsubsection occt_2142243456_18669311358117 XSetMaterial
+
+Syntax: XSetMaterial document {shape|label} name
+ density(g/cu sm)
+
+Adds a new label with material into the material table in a document, and adds a link to this material to the attribute list of agiven shape or a given label. The last parameter sets the density of a pointed material.
+<h5>Example</h5>
+
+XSetMaterial D 0:1:1:1 Titanium 8899.77
+
+@subsubsection occt_2142243456_18669311358118 XSetVolume
+
+Syntax: XSetVolume document {shape|label} volume
+
+Sets new volume to the attribute list ??? given shape.
+<h5>Example</h5>
+
+XSetVolume D 0:1:1:1 444555.33
+
+@subsubsection occt_2142243456_18669311358119 XShapeMassProps
+
+Syntax: XShapeMassProps document [ deflection [{shape|label}] ]
+
+Computes and returns real mass and real center of gravity for a given shape or for all shapes in a document. The second parameter is used for calculation of the volume and CG(center of gravity). If it is 0, then the standard CASCADE tool (geometry) is used for computation, otherwise - by triangulations with a given deflection.
+<h5>Example</h5>
+
+XShapeMassProps D
+== Shape from label : 0:1:1:1
+== Mass = 193.71681469282299
+== CenterOfGravity X = 14.594564763807696,Y =
+ 20.20271885211281,Z = 49.999999385313245
+== Shape from label : 0:1:1:2 not have a mass
+etc.
+
+@subsubsection occt_2142243456_186693113581110 XShapeVolume
+
+Syntax: XShapeVolume shape deflection
+
+Calculates the real volume of a pointed shape with a given deflection.
+<h5>Example</h5>
+
+XShapeVolume a 0
+
+@section occt_2142243456_1672096717 Shape Healing commands
+
+
+
+@subsection occt_2142243456_16720967171 General commands
+
+@subsubsection occt_2142243456_1672096717111 bsplres
+
+Syntax: bsplres result shape tol3d tol2d reqdegree reqnbsegments continuity3d continuity2d PriorDeg RationalConvert
+
+Performs approximations of a given shape (BSpline curves and surfaces or other surfaces) to BSpline with given required parameters. The specified continuity can be reduced if the approximation with a specified continuity was not done successfully. Results are put into the shape, which is given as a parameter result. For a more detailed description see the ShapeHealing User’s Guide (operator: BSplineRestriction).
+
+@subsubsection occt_2142243456_1672096717112 checkfclass2d
+
+Syntax: checkfclass2d face ucoord vcoord
+
+Shows where a point which is given by coordinates is located in relation to a given face – outbound, inside or at the bounds.
+<h5>Example</h5>
+
+checkfclass2d f 10.5 1.1
+== Point is OUT
+
+@subsubsection occt_2142243456_1672096717113 checkoverlapedges
+
+Syntax: checkoverlapedges edge1 edge2 [toler domaindist]
+
+Checks the overlapping of two given edges. If the distance between two edges is less than the given value of tolerance then edges are overlapped. Parameter domaindist sets length of part of edges on which edges are overlapped.
+<h5>Example</h5>
+
+checkoverlapedges e1 e2
+
+@subsubsection occt_2142243456_1672096717114 comtol
+
+Syntax: comptol shape [nbpoints] [prefix]
+
+Compares the real value of tolerance on curves with the value calculated by standard (using 23 points). The maximal value of deviation of 3d curve from pcurve at given simple points is taken as a real value (371 is by default). Command returns the maximal, minimal and average value of tolerance for all edges and difference between real values and set values. Edges with the maximal value of tolerance and relation will be saved if the ‘prefix’ parameter is given.
+**Example**
+
+comptol h 871 t
+
+== Edges tolerance computed by 871 points:
+== MAX=8.0001130696523449e-008 AVG=6.349346868091096e-009
+ MIN=0
+== Relation real tolerance / tolerance set in edge
+== MAX=0.80001130696523448 AVG=0.06349345591805905 MIN=0
+== Edge with max tolerance saved to t_edge_tol
+== Concerned faces saved to shapes t_1, t_2
+
+
+@subsubsection occt_2142243456_1672096717115 convtorevol
+
+Syntax: convtorevol result shape
+
+Converts all elementary surfaces of a given shape into surfaces of revolution.
+Results are put into the shape, which is given as theresult parameter.
+<h5>Example</h5>
+
+convtorevol r a
+
+@subsubsection occt_2142243456_1672096717116 directfaces
+
+Syntax: directfaces result shape
+
+Converts indirect surfaces and returns the results into the shape, which is given as the result parameter.
+<h5>Example</h5>
+
+directfaces r a
+
+@subsubsection occt_2142243456_1672096717117 expshape
+
+Syntax: expshape shape maxdegree maxseg
+
+Gives statistics for a given shape. This test command is working with Bezier and BSpline entities.
+<h5>Example</h5>
+
+expshape a 10 10
+== Number of Rational Bspline curves 128
+== Number of Rational Bspline pcurves 48
+
+@subsubsection occt_2142243456_1672096717118 fixsmall
+
+Syntax: fixsmall result shape [toler=1.]
+
+Fixes small edges in given shape by merging adjacent edges with agiven tolerance. Results are put into the shape, which is given as the result parameter.
+<h5>Example</h5>
+
+fixsmall r a 0.1
+
+@subsubsection occt_2142243456_1672096717119 fixsmalledges
+
+Syntax: fixsmalledges result shape [toler mode maxangle]
+
+Searches at least one small edge at a given shape. If such edges have been found, then small edges are merged with a given tolerance. If parameter mode is equal to Standard_True (can be given any values, except 2), then small edges, which can not be merged, are removed, otherwise they are to be kept (Standard_False is used by default). Parameter maxangle sets a maximum possible angle for merging two adjacent edges, by default no limit angle is applied (-1).Results are put into the shape, which is given as parameter result.
+<h5>Example</h5>
+
+fixsmalledges r a 0.1 1
+
+@subsubsection occt_2142243456_16720967171110 fixshape
+
+Syntax: fixshape result shape [preci [maxpreci]] [{switches}]
+
+Performs fixes of all sub-shapes (such as Solids, Shells, Faces, Wires and Edges) of a given shape. Parameter preci sets a basic precision value, maxpreci sets the maximal allowed tolerance. Results are put into the shape, which is given as parameter result.
+{switches} allows to tune parameters of ShapeFix
+The following syntax is used: symbolparameter
+- symbol may be - to set parameter off, + to set on or * to set default
+- parameters are identified by letters:
+l - FixLackingMode
+o - FixOrientationMode
+h - FixShiftedMode
+m - FixMissingSeamMode
+d - FixDegeneratedMode
+s - FixSmallMode
+i - FixSelfIntersectionMode
+n - FixNotchedEdgesMode
+For enhanced message output, use switch '+?'
+<h5>Example</h5>
+
+fixshape r a 0.001
+
+@subsubsection occt_2142243456_16720967171111 fixwgaps
+
+Syntax: fixwgaps result shape [toler=0]
+
+Fixes gaps between ends of curves of adjacent edges (both 3d and pcurves) in wires in a given shape with a given tolerance. Results are put into the shape, which is given as parameter result.
+<h5>Example</h5>
+
+fixwgaps r a
+
+@subsubsection occt_2142243456_16720967171112 offsetcurve, offset2dcurve
+
+Syntax: offsetcurve result curve offset direction(as point)
+ offset2dcurve result curve offset
+
+Both commands are intended to create a new offset curve by copying the given curve to distance, given by parameter offset. Parameter direction defines direction of the offset curve. It is created as a point. For correct work of these commands the direction of normal of the offset curve must be perpendicular to the plane, the basis curve is located there. Results are put into the curve, which is given as parameter result. **offsetcurve **works with the curve in 3d space, **offset2dcurve **in 2d space accordingly.
+<h5>Example</h5>
+
+point pp 10 10 10
+offsetcurve r c 20 pp
+
+@subsubsection occt_2142243456_16720967171113 projcurve
+
+Syntax: projcurve edge|curve3d|curve3d first last X Y Z
+
+**projcurve **returns the projection of a given point on a given curve. The curve may be defined by three ways: by giving the edge name, giving the 3D curve and by giving the unlimited curve and limiting it by pointing its start and finish values.
+**Example**
+
+projcurve k_1 0 1 5
+==Edge k_1 Params from 0 to 1.3
+==Precision (BRepBuilderAPI) : 9.9999999999999995e-008 ==Projection : 0 1 5
+==Result : 0 1.1000000000000001 0
+==Param = -0.20000000000000001 Gap = 5.0009999000199947
+
+
+@subsubsection occt_2142243456_16720967171114 projface
+
+Syntax: projface face X Y [Z]
+
+Returns the projection of a given point to a given face in 2d or 3d space. If two coordinates (2d space) are given then returns coordinates projection of this point in 3d space and vice versa.
+<h5>Example</h5>
+
+projface a_1 10.0 0.0
+== Point UV U = 10 V = 0
+== = proj X = -116 Y = -45 Z = 0
+
+@subsubsection occt_2142243456_16720967171115 scaleshape
+
+Syntax: scaleshape result shape scale
+
+<h5>Example</h5>
+
+scaleshape r a_1 0.8
+
+@subsubsection occt_2142243456_16720967171116 settolerance
+
+Syntax: settolerance shape [mode=v-e-w-f-a] val(fix value) or
+ tolmin tolmax
+
+Sets new values of tolerance for a given shape. If the given second parameter (mode) is given, then the atolerance value is set only for these sub shapes.
+<h5>Example</h5>
+
+settolerance a 0.001
+
+@subsubsection occt_2142243456_16720967171117 splitface
+
+Syntax: splitface result face [u usplit1 usplit2...] [v vsplit1 vsplit2 ...]
+
+Splits a given face in parametric space and puts the result into the given parameter result.
+Returns the status of split face.
+<h5>Example</h5>
+
+# split face f by parameter u = 5
+splitface r f u 5
+== Splitting by U: ,5
+== Status: DONE1
+
+@subsubsection occt_2142243456_16720967171118 statshape
+
+Syntax: statshape shape [particul]
+
+Returns the number of sub-shapes, which compose the given shape. For example, the number of solids, number of faces etc. It also returns the number of geometrical objects or sub-shapes with a specified type, example, number of free faces, number of C0 surfaces. The last parameter becomes out of date.
+<h5>Example</h5>
+
+statshape a
+== Count Item
+== ----- ----
+== 402 Edge (oriented)
+== 402 Edge (Shared)
+== 74 Face
+== 74 Face (Free)
+== 804 Vertex (Oriented)
+== 402 Vertex (Shared)
+== 78 Wire
+== 4 Face with more than one wire
+== 34 bspsur: BSplineSurface
+
+@subsubsection occt_2142243456_16720967171119 tolerance
+
+Syntax: tolerance shape [mode:D v e f c] [tolmin tolmax:real]
+
+Returns tolerance (maximal, avg and minimal values) of all given shapes and tolerance of their Faces, Edges and Vertices. If parameter tolmin or tolmax or both of them are given, then sub-shapes are returned as a result of analys of this shape, which satisfy the given tolerances. If a particular value of entity (all shapes (D) (v) vertices (e) edges (f) faces (c) combined (faces)) is given as the second parameter then only this group will be analyzed for tolerance.
+<h5>Example</h5>
+
+tolerance a
+== Tolerance MAX=0.31512672416608001 AVG=0.14901359484722074 MIN=9.9999999999999995e-08
+== FACE : MAX=9.9999999999999995e-08 AVG=9.9999999999999995e-08 MIN=9.9999999999999995e-08
+== EDGE : MAX=0.31512672416608001 AVG=0.098691334511810405 MIN=9.9999999999999995e-08
+== VERTEX : MAX=0.31512672416608001 AVG=0.189076074499648 MIN=9.9999999999999995e-08
+
+tolerance a v 0.1 0.001
+== Analysing Vertices gives 6 Shapes between tol1=0.10000000000000001 and tol2=0.001 , named tol_1 to tol_6
+
+
+
+@subsection occt_2142243456_16720967172 Convertion commands
+More detailed information about using here classes can be found into Shape Healing documentation. All this commands are created for testing.
+
+@subsubsection occt_2142243456_1672096717121 DT_ClosedSplit
+
+Syntax: DT_ClosedSplit result shape
+
+Divides all closed faces in the shape (for example cone) and returns result of given shape into shape, which is given as parameter result. Number of faces in resulting shapes will be increased.
+Note: Closed face – it’s face with one or more seam.
+<h5>Example</h5>
+
+DT_ClosetSplit r a
+
+@subsubsection occt_2142243456_1672096717122 DT_ShapeConvert, DT_ShapeConvertRev
+
+Syntax: DT_ShapeConvert result shape convert2d convert3d
+ DT_ShapeConvertRev result shape convert2d convert3d
+
+Both commands are intended for the conversion of 3D, 2D curves to Bezier curves and surfaces to Bezier based surfaces. Parameters convert2d and convert3d take on a value 0 or 1. If the given value is 1, then the conversion will be performed, otherwise it will not be performed. The results are put into the shape, which is given as parameter Result. Command **DT_ShapeConvertRev **differs from **DT_ShapeConvert **by converting all elementary surfaces into surfaces of revolution first.
+<h5>Example</h5>
+
+DT_ShapeConvert r a 1 1
+== Status: DONE1
+
+@subsubsection occt_2142243456_1672096717123 DT_ShapeDivide
+
+Syntax: DT_ShapeDivide result shape tol
+
+Divides the shape with C1 criterion and returns the result of geometry conversion of a given shape into the shape, which is given as parameter result. This command illustrates how class ShapeUpgrade_ShapeDivideContinuity works. This class allows to convert geometry with a continuity less than the specified continuity to geometry with target continuity. If conversion is not possible then the geometrical object is split into several ones, which satisfy the given tolerance. It also returns the status shape splitting:
+OK : no splitting was done
+Done1 : Some edges were split
+Done2 : Surface was split
+Fail1 : Some errors occurred
+<h5>Example</h5>
+
+DT_ShapeDivide r a 0.001
+== Status: OK
+
+@subsubsection occt_2142243456_1672096717124 DT_SplitAngle
+
+Syntax: DT_SplitAngle result shape [MaxAngle=95]
+
+Works with all revolved surfaces, like cylinders, surfaces of revolution etc. This command divides given revolved surfaces into segments so that each resulting segment covers not more than the given MaxAngle degrees and puts the result of splitting into the shape, which is given as parameter result. Values of returned status are given above.
+This command illustrates how class ShapeUpgrade_ShapeDivideAngle works.
+<h5>Example</h5>
+
+DT_SplitAngle r a
+== Status: DONE2
+
+@subsubsection occt_2142243456_1672096717125 DT_SplitCurve
+
+Syntax: DT_SplitCurve curve tol split(0|1)
+
+Divides the 3d curve with C1 criterion and returns the result of splitting of the given curve into a new curve. If the curve had been divided by segments, then each segment is put to an individual result. This command can correct a given curve at a knot with the given tolerance, if it is impossible, then the given surface is split at that knot. If the last parameter is 1, then 5 knots are added at the given curve, and its surface is split by segments, but this will be performed not for all parametric spaces.
+<h5>Example</h5>
+
+DT_SplitCurve r c
+
+@subsubsection occt_2142243456_1672096717126 DT_SplitCurve2d
+
+Syntax: DT_SplitCurve2d Curve Tol Split(0/1)
+
+Works just as DT_SplitCurve (see above), only with 2d curve.
+<h5>Example</h5>
+
+DT_SplitCurve2d r c
+
+@subsubsection occt_2142243456_1672096717127 DT_SplitSurface
+
+Syntax: DT_SplitSurface result Surface|GridSurf tol split(0|1)
+
+Divides surface with C1 criterion and returns the result of splitting of a given surface into surface, which is given as parameter result. If the surface has been divided into segments, then each segment is put to an individual result. This command can correct a given C0 surface at a knot with a given tolerance, if it is impossible, then the given surface is split at that knot. If the last parameter is 1, then 5 knots are added to the given surface, and its surface is split by segments, but this will be performed not for all parametric spaces.
+**Example**
+
+# split surface with name ‘su’
+DT_SplitSurface res su 0.1 1
+== single surf
+== appel a SplitSurface::Init
+== appel a SplitSurface::Build
+== appel a SplitSurface::GlobalU/VKnots
+== nb GlobalU;nb GlobalV=7 2 0 1 2 3 4 5 6.2831853072 0 1
+== appel a Surfaces
+== transfert resultat
+== res1_1_1 res1_2_1 res1_3_1 res1_4_1 res1_5_1 res1_6_1
+
+
+@subsubsection occt_2142243456_1672096717128 DT_ToBspl
+
+Syntax: DT_ToBspl result shape
+
+Converts a surface of linear extrusion, revolution and offset surfaces into BSpline surfaces. Returns the result into the shape, which is given as parameter result.
+**Example**
+
+DT_ToBspl res sh
+== error = 5.20375663162094e-08 spans = 10
+== Surface is aproximated with continuity 2
+
+@section occt_2142243456_1640587828 Performance evaluation commands
+
+
+@subsubsection occt_2142243456_16405878281.1 VDrawSphere
+
+Syntax: vdrawsphere shapeName Fineness [X=0.0 Y=0.0 Z=0.0] [Radius=100.0] [ToEnableVBO=1] [NumberOfViewerUpdate=1] [ToShowEdges=0]
+
+Calculates and displays in a given number of steps a sphere with given coordinates, radius and fineness. Returns the information about the properties of the sphere, the time and the amount of memory required to build it.
+
+This command can be used for visualization performance evaluation instead of the outdated Visualization Performance Meter.
+**Example**
+
+vdrawsphere s 200 1 1 1 500 1 == Compute Triangulation... == NumberOfPoints: 39602 == NumberOfTriangles: 79200 == Amount of memory required for PolyTriangulation without Normals: 2 Mb == Amount of memory for colors: 0 Mb == Amount of memory for PolyConnect: 1 Mb == Amount of graphic card memory required: 2 Mb == Number of scene redrawings: 1 == CPU user time: 15.6000999999998950 msec == CPU system time: 0.0000000000000000 msec == CPU average time of scene redrawing: 15.6000999999998950 msec
+
+
+
+@section occt_2142243456_713659999 Extending Test Harness with custom commands
+
+
+The following chapters explain how to extend Test Harness with custom commands and how to activate them using a plug-in mechanism.
+
+
+@subsection occt_2142243456_7136599991 Custom command implementation
+
+Custom command implementation has not undergone any changes since the introduction of the plug-in mechanism. The syntax of every command should still be like in the following example.
+**Example**
+
+static Standard_Integer myadvcurve(Draw_Interpretor& di,
+Standard_Integer n,
+char** a)
+{
+...
+}
+
+For examples of existing commands refer to Open CASCADE Technology (e.g. GeomliteTest.cxx).
+
+
+@subsection occt_2142243456_7136599992 Registration of commands in Test Harness
+
+To become available in the Test Harness the custom command must be registered in it. This should be done as follows.
+**Example**
+
+void MyPack::CurveCommands(Draw_Interpretor& theCommands)
+{
+...
+char* g = ;Advanced curves creation;;
+
+
+ theCommands.Add ( ;myadvcurve;, ;myadvcurve name p1 p2 p3 –
+ Creates my advanced curve from points;,
+__FILE__, myadvcurve, g);
+...
+}
+
+@subsection occt_2142243456_7136599993 Creating a toolkit (library) as a plug-in
+
+All custom commands are compiled and linked into a dynamic library (.dll on Windows, or .so on Unix/Linux). To make Test Harness recognize it as a plug-in it must respect certain conventions. Namely, it must export function PLUGINFACTORY() accepting the Test Harness interpreter object (Draw_Interpretor). This function will be called when the library is dynamically loaded during the Test Harness session.
+This exported function PLUGINFACTORY() must be implemented only once per library.
+For convenience the DPLUGIN macro (defined in the Draw_PluginMacro.hxx file) has been provided. It implements the PLUGINFACTORY() function as a call to the Package::Factory() method and accepts Package as an argument. Respectively, this Package::Factory() method must be implemented in the library and activate all implemented commands.
+**Example**
+
+#include Draw_PluginMacro.hxx
+
+void MyPack::Factory(Draw_Interpretor& theDI)
+{
+...
+//
+MyPack::CurveCommands(theDI);
+...
+}
+
+// Declare entry point PLUGINFACTORY
+DPLUGIN(MyPack)
+
+
+@subsection occt_2142243456_7136599994 Creation of the plug-in resource file
+
+As mentioned above, the plug-in resource file must be compliant with Open CASCADE Technology requirements (see Resource_Manager.cdl file for details). In particular, it should contain keys separated from their values by a colon (;:;).
+For every created plug-in there must be a key. For better readability and comprehension it is recommended to have some meaningful name.
+Thus, the resource file must contain a line mapping this name (key) to the library name. The latter should be without file extension (.dll on Windows, .so on Unix/Linux) and without the ;lib; prefix on Unix/Linux.
+For several plug-ins one resource file can be created. In such case, keys denoting plug-ins can be combined into groups, these groups - into their groups and so on (thereby creating some hierarchy). Any new parent key must have its value as a sequence of child keys separated by spaces, tabs or commas. Keys should form a tree without cyclic dependencies.
+**Examples** (file MyDrawPlugin):
+
+! Hierarchy of plug-ins
+ALL : ADVMODELING, MESHING
+DEFAULT : MESHING
+ADVMODELING : ADVSURF, ADVCURV
+
+! Mapping from naming to toolkits (libraries)
+ADVSURF : TKMyAdvSurf
+ADVCURV : TKMyAdvCurv
+MESHING : TKMyMesh
+
+
+For other examples of the plug-in resource file refer to the *;Plug-in resource file;* chapter above or to the $CASROOT/src/DrawPlugin file shipped with Open CASCADE Technology.
+
+
+@subsection occt_2142243456_7136599995 Dynamic loading and activation
+
+Loading a plug-in and activating its commands is described in the *;Activation of the commands implemented in the plug-in;* chapter.
+
+The procedure consists in defining the system variables and using the pload commands in the Test Harness session.
+
+**Example**
+
+Draw[] set env(CSF_MyDrawPluginDefaults) /users/test
+
+
--- /dev/null
+Foundation Classes {#user_guides__foundation_classes}
+=================================
+
+@section occt_fcug_1 Introduction
+
+@subsection occt_fcug_1_1 Foundation Classes Overview
+
+This manual explains how to use Open CASCADE Technology (**OCCT**) Foundation Classes. It provides basic documentation on foundation classes. For advanced information on foundation classes and their applications, see our offerings on our web site at <a href="http://www.opencascade.org/support/training/">www.opencascade.org/support/training/</a>
+Foundation Classes provide a variety of general-purpose services such as automated dynamic memory management (manipulation of objects by handle), collections, exception handling, genericity by downcasting and plug-in creation.
+Foundation Classes include the following:
+
+Root Classes
+------------
+Root classes are the basic data types and classes on which all the other classes are built. They provide:
+ * fundamental types such as Boolean, Character, Integer or Real,
+ * safe handling of dynamically created objects, ensuring automatic deletion of unreferenced objects (see the Standard_Transient class),
+ * configurable optimized memory manager increasing the performance of applications that intensively use dynamically created objects,
+ * extended run-time type information (RTTI) mechanism facilitating the creation of complex programs,
+ * management of exceptions,
+ * encapsulation of C++ streams.
+Root classes are mainly implemented in the **Standard** and **MMgt** packages.
+
+Strings
+-------
+Strings are classes that handle dynamically sized sequences of characters based on both ASCII (normal 8-bit character type) and Unicode (16-bit character type).
+Strings may also be manipulated by handles, and consequently be shared.
+Strings are implemented in the **TCollection** package.
+
+Collections
+-----------
+Collections are the classes that handle dynamically sized aggregates of data.
+Collection classes are *generic*, that is, they define a structure and algorithms allowing to hold a variety of objects which do not necessarily inherit from a unique root class (similarly to C++ templates). When you need to use a collection of a given type of object, you must *instantiate* it for this specific type of element. Once this declaration is compiled, all functions available on the generic collection are available on your *instantiated class*.
+
+Collections include a wide range of generic classes such as run-time sized arrays, lists, stacks, queues, sets and hash maps.
+Collections are implemented in the **TCollection** and **NCollection** packages.
+
+Collections of Standard Objects
+------------------------------
+The **TColStd** package provides frequently used instantiations of generic classes from the **TCollection** package with objects from the **Standard** package or strings from the **TCollection** package.
+
+Vectors and Matrices
+---------------------
+
+These classes provide commonly used mathematical algorithms and basic calculations (addition, multiplication, transposition, inversion, etc.) involving vectors and matrices.
+
+Primitive Geometric Types
+-------------------------
+Open CASCADE Technology primitive geometric types are a STEP-compliant implementation of basic geometric and algebraic entities.
+They provide:
+ * Descriptions of elementary geometric shapes:
+ * 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.
+
+Common Math Algorithms
+----------------------
+
+Open CASCADE Technology common math algorithms provide a C++ implementation of the most frequently used mathematical algorithms.
+These include:
+ * Algorithms to solve a set of linear algebraic equations,
+ * Algorithms to find the minimum of a function of one or more independent variables,
+ * Algorithms to find roots of one, or of a set, of non-linear equations,
+ * Algorithms to find the eigen-values and eigen-vectors of a square matrix.
+
+Exceptions
+----------
+A hierarchy of commonly used exception classes is provided, all based on class Failure, the root of exceptions.
+Exceptions describe exceptional situations, which can arise during the execution of a function. With the raising of an exception, the normal course of program execution is abandoned. The execution of actions in response to this situation is called the treatment of the exception.
+Quantities
+----------
+These are various classes supporting date and time information and fundamental types representing most physical quantities such as length, area, volume, mass, density, weight, temperature, pressure etc.
+
+Application services
+--------------------
+Foundation Classes also include implementation of several low-level services that facilitate the creation of customizable and user-friendly applications with Open CASCADE Technology. These include:
+ * Unit conversion tools, providing a uniform mechanism for dealing with quantities and associated physical units: check unit compatibility, perform conversions of values between different units and so on (see package UnitsAPI).
+ * Basic interpreter of expressions that facilitates the creation of customized scripting tools, generic definition of expressions and so on (see package ExprIntrp)
+ * Tools for dealing with configuration resource files (see package Resource) and customizable message files (see package Message), making it easy to provide a multi-language support in applications
+ * Progress indication and user break interfaces, giving a possibility even for low-level algorithms to communicate with the user in a universal and convenient way.
+
+
+@subsection occt_fcug_1_2 Fundamental Concepts
+An object-oriented language structures a system around data types rather than around the actions carried out on this data. In this context, an **object** is an **instance** of a data type and its definition determines how it can be used. Each data type is implemented by one or more classes, which make up the basic elements of the system.
+In Open CASCADE Technology the classes are usually defined using CDL (CASCADE Definition Language) that provides a certain level of abstraction from pure C++ constructs and ensures a definite level of similarity in the implementation of classes. See *CDL User’s Guide* for more details.
+This chapter introduces some basic concepts most of which are directly supported by CDL and used not only in Foundation Classes, but throughout the whole OCCT library.
+
+@subsubsection occt_fcug_1_2_1 Modules and toolkits
+The whole OCCT library is organized in a set of modules. The first module, providing most basic services and used by all other modules, is called Foundation Classes and described by this manual.
+Every module consists primarily of one or several toolkits (though it can also contain executables, resource units etc.). Physically a toolkit is represented by a shared library (e.g. .so or .dll). The toolkit is built from one or several packages.
+@subsubsection occt_fcug_1_2_2 Packages
+A **package** groups together a number of classes which have semantic links. For example, a geometry package would contain Point, Line, and Circle classes. A package can also contain enumerations, exceptions and package methods (functions). In practice, a class name is prefixed with the name of its package e.g.
+*Geom_Circle*.
+Data types described in a package *may *include one or more of the following data types:
+ * Enumerations
+ * Object classes
+ * Exceptions
+ * Pointers to other object classes
+Inside a package, two data types *cannot *bear the same name.
+
+
+
+**Methods** 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 different arguments or none.
+* **Instance method** Operates on the instance which owns it.
+* **Class method** Does not work on individual instances, only on the class itself.
+
+@subsubsection occt_fcug_1_2_3 Classes
+The fundamental software component in object-oriented software development is the class. A class is the implementation of a **data type**. It defines its **behavior** (the services offered by its functions) and its **representation** (the data structure of the class – the fields, which store its data).
+
+Categories of Classes
+------------------------
+Classes fall into three categories:
+ * Ordinary classes.
+ * Deferred classes. A **deferred class** cannot be instantiated. The purpose of having such classes is to have a given behavior shared by a hierarchy of classes and dependent on the implementation of the descendants. This is a way of guaranteeing a certain base of inherited behavior common to all the classes based on a particular deferred class. The C++ equivalent of a deferred CDL class is an abstract class.
+ * Generic classes. A **generic class** offers a set of functional behaviors to manipulate other data types. Instantiation of a generic class requires that a data type is given for its argument(s). The generic classes in CDL perform the same mission as template classes in C++.
+
+
+
+
+@subsubsection occt_fcug_1_2_4 Genericity
+Generic classes are implemented in two steps. First you declare the generic class to establish the model, then you instantiate this class by giving information about the generic types.
+
+Declaring a Generic Class
+---------------------------
+The generic classes in Open CASCADE Technology are similar by their intent to C++ templates with explicit instantiation.
+A generic class is declared in CDL as operating on data items of non-fixed types which are declared as arguments of the generic class. It is possible to put a restriction on these data types to be of subtype of some definite class. Definition of the generic class does not create new class type in C++ terms; it only defines a pattern for generation (instantiation) of the real classes.
+
+Instantiation of a Generic Class
+--------------------------------
+When a generic class is instantiated, its argument types are substituted by actually existing data types (elementary types or classes). The result of instantiation is a new C++ class with an arbitrary name (specified in the instantiating declaration). By convention, the name of the instantiated class is usually constructed from the name of the generic class and names of actual argument types. As for any other class, the name of the class instantiating a generic type is prefixed by the name of the package in which instantiation is declared.
+@code
+class Array1OfReal instantiates Array1 from TCollection (Real);
+@endcode
+
+This declaration located in a CDL file of the *TColStd* package defines a new C++ class *TColStd_Array1OfReal* as the instantiation of generic class *TCollection_Array1* for *Real* values.
+More than one class can be instantiated from the same generic class with the same argument types. Such classes will be identical by implementation, but considered as two different classes by C++.
+No class can inherit from a generic class.
+A generic class can be a deferred class. A generic class can also accept a deferred class as its argument. In both these cases, any class instantiated from it will also be deferred. The resulting class can then be inherited by another class.
+
+Nested Generic Classes
+----------------------
+It often happens that many classes are linked by a common generic type. This is the case when a base structure furnishes an iterator. In this context, it is necessary to make sure that the group of linked generic classes is indeed instantiated for the same type of object. In order to group the instantiation, you may declare certain classes as being nested.
+When generic class is instantiated, its nested classes are instantiated as well. The name of the instantiation of the nested class is constructed from the name of that nested class and name of the main generic class, connected by ‘Of’.
+@code
+class MapOfReal instantiates Map from TCollection (Real,MapRealHasher);
+@endcode
+This declaration in *TColStd* defines not only class *TColStd_MapOfReal*, but also class *TColStd_MapIteratorOfMapOfReal*, which is instantiated from nested class *MapIterator* of the generic class *TCollection_Map*. Note that instantiation of the nested class is separate class, it is not nested class to the instantiation of the main class.
+**Nested classes**, even though they are described as non-generic classes, are generic by construction being inside the class they are a member of.
+@subsubsection occt_fcug_1_2_5 Inheritance
+The purpose of inheritance is to reduce the development workload. The inheritance mechanism allows a new class to be declared already containing the characteristics of an existing class. This new class can then be rapidly specialized for the task in hand. This avoids the necessity of developing each component “from scratch”.
+For example, having already developed a class *BankAccount* you could quickly specialize new classes: *SavingsAccount, LongTermDepositAccount, MoneyMarketAccount, RevolvingCreditAccount*, etc....
+The corollary of this is that when two or more classes inherit from a parent (or ancestor) class, all these classes guarantee as a minimum the behavior of their parent (or ancestor). For example, if the parent class BankAccount contains the method Print which tells it to print itself out, then all its descendent classes guarantee to offer the same service.
+One way of ensuring the use of inheritance is to declare classes at the top of a hierarchy as being **deferred**. In such classes, the methods are not implemented. This forces the user to create a new class which redefines the methods. This is a way of guaranteeing a certain minimum of behavior among descendent classes.
+
+@subsubsection occt_fcug_1_2_6 Categories of Data Types
+The data types in Open CASCADE Technology fall into two categories:
+ * Data types manipulated by handle (or reference)
+ * Data types manipulated by value
+
+
+
+A data type is implemented as a class. The class not only defines its data representation and the methods available on instances, but it also suggests how the instance will be manipulated.
+ * A variable of a type manipulated by value contains the instance itself.
+ * A variable of a type manipulated by handle contains a reference to the instance.
+The first examples of types manipulated by values are the predefined **primitive types**: *Boolean, Character, Integer, Real*, etc.
+A variable of a type manipulated by handle which is not attached to an object is said to be **null**. To reference an object, we instantiate the class with one of its constructors. For example, in C++:
+
+~~~~~
+Handle(myClass) m = new myClass;
+~~~~~
+
+In Open CASCADE Technology, the Handles are specific classes that are used to safely manipulate objects allocated in the dynamic memory by reference, providing reference counting mechanism and automatic destruction of the object when it is not referenced.
+
+@subsubsection occt_fcug_1_2_7 Exceptions
+The behavior of any object is implemented by the methods, which were defined in its class declaration. The definition of these methods includes not only their signature (their programming interface) but also their domain of validity.
+This domain is expressed by **exceptions**. Exceptions are raised under various error conditions. This mechanism is a safeguard of software quality.
+
+@subsubsection occt_fcug_1_2_8 Persistence and Data Schema
+The data schema is the structure used by an application to store its data. Data schemas consist of persistent classes.
+An object is called **persistent** if it can be permanently stored. Thus, the object can be reused at a later date by the application, which created it, or by another application.
+In order for an object to be persistent for CDL, its type must be declared as inheriting from the class *Standard_Persistent* or have a parent class inheriting from the *Standard_Persistent* class. Note that classes inheriting from *Standard_Persistent* are handled by a reference.
+Objects instantiated from classes which inherit from the Standard_Storable class cannot themselves be stored individually, but they can be stored as fields of an object which inherits from *Standard_Persistent*. Note that objects inheriting from *Standard_Storable* are handled by a value.
+
+@section occt_fcug_2 Basics
+This chapter deals with basic services such as memory management, programming with handles, primitive types, exception handling, genericity by downcasting and plug-in creation.
+@subsection occt_fcug_2_1 Data Types
+@subsubsection occt_fcug_2_1_1 Primitive Types
+The primitive types are predefined in the language and they are **manipulated by value**.
+Some of these primitives inherit from the **Storable** class. This means they can be used in the implementation of persistent objects, either contained in entities declared within the methods of the object, or they form part of the internal representation of the object.
+The primitives inheriting from *Standard_Storable* are the following:
+* **Boolean** is used to represent logical data. It may have only two values: *Standard_True* and *Standard_False*.
+* **Character** designates any ASCII character.
+* **ExtCharacter** is an extended character.
+* **Integer** is a whole number.
+* **Real** denotes a real number (i.e. one with whole and a fractional part, either of which may be null).
+* **ShortReal** is a real with a smaller choice of values and memory size.
+There are also non-Storable primitives. They are:
+* **CString** is used for literal constants.
+* **ExtString** is an extended string.
+* **Address** represents a byte address of undetermined size.
+The services offered by each of these types are described in the **Standard** Package.
+The table below presents the equivalence existing between C++ fundamental types and OCCT primitive types.
+
+**Table 1: Equivalence between C++ Types and OCCT Primitive Types**
+|C++ Types | OCCT Types |
+|----------:|------------:|
+|int | Standard_Integer |
+| double | Standard_Real |
+|float | Standard_ShortReal |
+|unsigned int | Standard_Boolean |
+|char | Standard_Character |
+| short | Standard_ExtCharacter |
+| char* | Standard_CString |
+| void* | Standard_Address |
+|short* | Standard_ExtString |
+
+* pointer
+
+
+**Reminder of the classes listed above:**
+
+* Standard_Integer: fundamental type representing 32-bit integers yielding negative, positive or null values. **Integer** is implemented as a **typedef** of the C++ **int** fundamental type. As such, the algebraic operations +, -, *, / as well as the ordering and equivalence relations <, <=, ==, !=, >=, > are defined on it.
+* Standard_Real: fundamental type representing real numbers with finite precision and finite size. **Real** is implemented as a **typedef** of the C++ **double** (double precision) fundamental type. As such, the algebraic operations +, -, *, /, unary- and the ordering and equivalence relations <, <=, ==, !=, >=, > are defined on reals.
+* Standard_ShortReal: fundamental type representing real numbers with finite precision and finite size. **ShortReal** is implemented as a **typedef** of the C++ **float** (simple precision) fundamental type. As such, the algebraic operations +, -, *, /, unary- and the ordering and equivalence relations <, <=, ==, !=, >=, > are defined on reals.
+* Standard_Boolean: **Boolean** is a fundamental type representing logical expressions. It has two values, false and true. **Boolean** is implemented as a **typedef** of the C++ **unsigned int** fundamental type. As such, the algebraic operations and, or, xor, not as well as equivalence relations ==, != are defined on Booleans.
+* Standard_Character: **Character** is a fundamental type representing the normalized ASCII character set. It may be assigned the values of the 128 ASCII characters. **Character** is implemented as a **typedef** of the C++ **char** fundamental type. As such, the ordering and equivalence relations <, <=, ==, !=, >=, > are defined on characters using the order of the ASCII chart (ex: A B).
+* Standard_ExtCharacter: **ExtCharacter** is a fundamental type representing the Unicode character set. It is a 16-bit character type. **ExtCharacter** is implemented as a **typedef** of the C++ **short** fundamental type. As such, the ordering and equivalence relations <, <=, ==, !=, >=, > are defined on extended characters using the order of the UNICODE chart (ex: A B).
+* Standard_CString: **CString** is a fundamental type representing string literals. A string literal is a sequence of ASCII (8 bits) characters enclosed in double quotes. **CString** is implemented as a **typedef** of the C++ **char* ** fundamental type.
+* Standard_Address : **Address** is a fundamental type representing a generic pointer. **Address** is implemented as a **typedef** of the C++ **void* ** fundamental type.
+* Standard_ExtString : **ExtString** is a fundamental type representing string literals as sequences of Unicode (16 bits) characters. **ExtString** is implemented as a **typedef** of the C++ **short* ** fundamental type.
+
+@subsubsection occt_fcug_2_1_2 Types manipulated by value
+There are three categories of types which are manipulated by value:
+ * Primitive types
+ * Enumerated types
+ * Types defined by classes not inheriting from Standard_Persistent or Standard_Transient, whether directly or not.
+Types which are manipulated by value behave in a more direct fashion than those manipulated by handle and thus can be expected to perform operations faster, but they cannot be stored independently in a file.
+
+
+
+Types that are known to the schema (i.e. they are either **primitives**or they inherit from **Storable**) and are manipulated by value, can be stored inside a persistent object as part of the representation. Only in this way can a “manipulated by value” object be stored in a file.
+
+
+
+@subsubsection occt_fcug_2_1_3 Types manipulated by reference (handle)
+There are two categories of types which are manipulated by handle:
+ * Types defined by classes inheriting from the **Persistent**class, which are therefore storable in a file.
+ * Types defined by classes inheriting from the **Transient**class.
+
+
+
+@subsubsection occt_fcug_2_1_4 Summary of properties
+
+The following table summarizes how various data types are handled and stored.
+
+| | Manipulated by handle | Manipulated by value |
+|--------:|----------------------:|---------------------:|
+| storable | Persistent | Primitive, Storable (if nested in a persistent class)|
+|temporary | Transient | Other |
+
+
+@subsection occt_fcug_2_2 Programming with Handles
+@subsubsection occt_fcug_2_2_1 Handle Definition
+A handle may be compared with a C++ pointer. Several handles can reference the same object. Also, a single handle may reference several objects, but only one at a time. To have access to the object it refers to, the handle must be de-referenced just as with a C++ pointer.
+Transient and Persistent classes may be manipulated either with handles or with values. Handles which reference non-persistent objects are called non-storable handles; therefore, a persistent object cannot contain a non-storable handle.
+
+Organization of Classes
+-----------------------
+Classes used with handles are persistent or transient.
+Classes that inherit from *Standard_Transient* are transient while classes that inherit from *Standard_Persistent* are persistent.
+In this chapter we will discuss only transient classes and relevant handles. Persistent classes and their handles are organized in a similar manner.
+Class *Standard_Transient* is a root of a big hierarchy of OCCT classes that are said to be operable by handles. It provides a reference counter field, inherited by all its descendant classes, that is used by associated *Handle()* classes to track a number of handles pointing to this instance of the object.
+For every class derived (directly or indirectly) from *Transient*, CDL extractor creates associated class *Handle()* whose name is the same as the name of that class prefixed by *Handle_*. Open CASCADE Technology provides pre-processor macro *Handle()* that produces a name of a *Handle()* class for a given transient class name.
+
+Using a Handle
+--------------
+
+A handle is characterized by the object it references.
+Before performing any operation on a transient object, you must declare the handle.
+For example, if Point and Line are two transient classes from the Geom package, you would write:
+~~~~~
+Handle(Geom_Point) p1, p2;
+~~~~~
+Declaring a handle creates a null handle that does not refer to any object. The handle may be checked to be null by its method *IsNull()*. To nullify a handle, use method *Nullify()*.
+To initialize a handle, either a new object should be created or the value of another handle can be assigned to it, on condition that their types are compatible.
+**Note** that handles should only be used for object sharing. For all local operations, it is advisable to use classes manipulated by values.
+
+@subsubsection occt_fcug_2_2_2 Type Management
+
+General
+-------
+
+Open CASCADE Technology provides a means to describe the hierarchy of data types in a generic way, with a possibility to check the exact type of the given object at run-time (similarly to C++ RTTI). For every class type derived from *Standard_Transient*, CDL extractor creates a code instantiating single instance of the class *Standard_Type* (type descriptor) that holds information on that type: its name and list of ancestor types.
+That instance (actually, a handle on it) is returned by the virtual method *DynamicType()* of the class derived from *Standard_Transient*. The other virtual method *IsKind()* provides a means to check whether a given object has specified type or inherits it.
+In order to refer to the type descriptor object for a given class type, use macros *STANDARD_TYPE()* with argument being a name of the class.
+
+Type Conformity
+---------------
+The type used in the declaration of a handle is the static type of the object, the type seen by the compiler. A handle can reference an object instantiated from a subclass of its static type. Thus, the dynamic type of an object (also called the actual type of an object) can be a descendant of the type which appears in the handle declaration through which it is manipulated.
+Consider the persistent class *CartesianPoint*, a sub-class of *Point*; the rule of type conformity can be illustrated as follows:
+
+~~~~~
+Handle (Geom_Point) p1;
+Handle (Geom_CartesianPoint) p2;
+p2 = new Geom_CartesianPoint;
+p1 = p2; // OK, the types are compatible
+~~~~~
+
+
+The compiler sees p1 as a handle to *Point* though the actual object referenced by *p1* is of the *CartesianPoint* type.
+
+Explicit Type Conversion
+------------------------
+
+According to the rule of type conformity, it is always possible to go up the class hierarchy through successive assignments of handles. On the other hand, assignment does not authorize you to go down the hierarchy. Consequently, an explicit type conversion of handles is required.
+A handle can be converted explicitly into one of its sub-types if the actual type of the referenced object is a descendant of the object used to cast the handle. If this is not the case, the handle is nullified (explicit type conversion is sometimes called a “safe cast”). Consider the example below.
+
+~~~~~~
+Handle (Geom_Point) p1;
+Handle (Geom_CartesianPoint) p2, p3;
+p2 = new Geom_CartesianPoint;
+p1 = p2; // OK, standard assignment
+p3 = Handle (Geom_CartesianPoint)::DownCast (p1);
+// OK, the actual type of p1 is CartesianPoint, although the static type of the handle is Point
+~~~~~~
+
+If conversion is not compatible with the actual type of the referenced object, the handle which was “cast” becomes null (and no exception is raised). So, if you require reliable services defined in a sub-class of the type seen by the handle (static type), write as follows:
+
+~~~~~~
+void MyFunction (const Handle(A) & a)
+{
+ Handle(B) b = Handle(B)::Downcast(a);
+ if (! b.IsNull()) {
+ // we can use “b” if class B inherits from A
+ }
+ else {
+ // the types are incompatible
+ }
+}
+~~~~~~
+Downcasting is used particularly with collections of objects of different types; however, these objects should inherit from the same root class.
+For example, with a sequence of SequenceOfTransient transient objects and two classes A and B that both inherit from Standard_Transient, you get the following syntax:
+
+~~~~~
+Handle (A) a;
+Handle (B) b;
+Handle (Standard_Transient) t;
+SequenceOfTransient s;
+a = new A;
+s.Append (a);
+b = new B;
+s.Append (b);
+t = s.Value (1);
+// here, you cannot write:
+// a = t; // ERROR !
+// so you downcast:
+a = Handle (A)::Downcast (t)
+if (! a.IsNull()) {
+ // types are compatible, you can use a
+}
+else {
+ // the types are incompatible
+}
+~~~~~
+
+@subsubsection occt_fcug_2_2_3 Using Handles to Create Objects
+To create an object which is manipulated by handle, declare the handle and initialize it with the standard C++ **new** operator, immediately followed by a call to the constructor. The constructor can be any of those specified in the source of the class from which the object is instanced.
+
+~~~~~
+Handle (Geom_CartesianPoint) p;
+p = new Geom_CartesianPoint (0, 0, 0);
+~~~~~
+
+Unlike for a pointer, the **delete** operator does not work on a handle; the referenced object is automatically destroyed when no longer in use.
+
+@subsubsection occt_fcug_2_2_4 Invoking Methods
+Once you have a handle on a persistent or transient object, you can use it like a pointer in C++. To invoke a method which acts on the referenced object, you translate this method by the standard *arrow* operator, or alternatively, by function call syntax when this is available.
+To test or to modify the state of the handle, the method is translated by the *dot* operator.
+The example below illustrates how to access the coordinates of an (optionally initialized) point object:
+
+~~~~~
+Handle (Geom_CartesianPoint) centre;
+Standard_Real x, y, z;
+if (centre.IsNull()) {
+ centre = new PGeom_CartesianPoint (0, 0, 0);
+}
+centre->Coord(x, y, z);
+~~~~~
+
+The example below illustrates how to access the type object of a Cartesian point:
+
+~~~~~
+Handle(Standard_Transient) p = new Geom_CartesianPoint(0.,0.,0.);
+if ( p->DynamicType() == STANDARD_TYPE(Geom_CartesianPoint) )
+ cout << ;Type check OK; << endl;
+else
+ cout << ;Type check FAILED; << endl;
+~~~~~
+
+*NullObject* exception will be raised if a field or a method of an object is accessed via a *Null* handle.
+
+Invoking Class Methods
+----------------------
+A class method is called like a static C++ function, i.e. it is called by the name of the class of which it is a member, followed by the “::” operator and the name of the method.
+
+For example, we can find the maximum degree of a Bezier curve:
+
+~~~~~
+Standard_Integer n;
+n = Geom_BezierCurve::MaxDegree();
+~~~~~
+
+@subsubsection occt_fcug_2_2_5 Handle de-allocation
+Before you delete an object, you must ensure it is no longer referenced. To reduce the programming load related to this management of object life, the delete function in Open CASCADE Technology is secured by a **reference counter** of classes manipulated by handle. A handle automatically deletes an object when it is no longer referenced. Normally you never call the delete operator explicitly on instances of subclasses of Standard_Transient.
+When a new handle to the same object is created, the reference counter is incremented. When the handle is destroyed, nullified, or reassigned to another object, that counter is decremented. The object is automatically deleted by the handle when reference counter becomes 0.
+The principle of allocation can be seen in the example below.
+
+~~~~~
+...
+{
+Handle (TColStd_HSequenceOfInteger) H1 = new TColStd_HSequenceOfInteger;
+ // H1 has one reference and corresponds to 48 bytes of memory
+ {
+ Handle (TColStd_HSequenceOfInteger) H2;
+ H2 = H1; // H1 has two references
+ if (argc == 3) {
+ Handle (TColStd_HSequenceOfInteger) H3;
+ H3 = H1;
+ // Here, H1 has three references
+ ...
+ }
+ // Here, H1 has two references
+ }
+ // Here, H1 has 1 reference
+}
+// Here, H1 has no reference and the referred TColStd_HSequenceOfInteger object is deleted.
+~~~~~
+
+Cycles
+------
+Cycles appear if two or more objects reference each other by handles (stored as fields). In this condition automatic destruction will not work.
+Consider for example a graph, whose objects (primitives) have to know the graph object to which they belong, i.e. a primitive must have a reference to complete graph object. If both primitives and the graph are manipulated by handle and they refer to each other by keeping a handle as a field, the cycle appears.
+The graph object will not be deleted when the last handle to it is destructed in the application, since there are handles to it stored inside its own data structure (primitives).
+There are two approaches how to avoid such situation:
+ * Use C++ pointer for one kind of references, e.g. from a primitive to the graph
+ * Nullify one set of handles (e.g. handles to a graph in primitives) when a graph object needs to be destroyed
+
+@subsubsection occt_fcug_2_2_6 Creating Transient Classes without CDL
+
+Though generation of Handle class and related C++ code is normally performed by CDL extractor, it is also possible to define a class managed by handle without CDL. To facilitate that, several macros are provided in the file Standard_DefineHandle.hxx:
+
+* **DEFINE_STANDARD_HANDLE(class_name,ancestor_name)** - declares Handle class for a class *class_name* that inherits class *ancestor_name* (for instance, *Standard_Transient*). This macro should be put in a header file; the declaration of the handle to a base class must be available (usually put before or after the declaration of the class *class_name*, or into a separate header file).
+* **IMPLEMENT_STANDARD_HANDLE(class_name,ancestor_name)** - implements method *DownCast()* of the *Handle* class. Should be located in a C++ file (normally the file where methods of the class *class_name* are implemented).
+* **DEFINE_STANDARD_RTTI(class_name)** - declares methods required for RTTI in the class *class_name* declaration; should be in public: section.
+* **IMPLEMENT_STANDARD_RTTIEXT(class_name,ancestor_name)** - implements above methods. Usually put into the C++ file implementing class class_name.
+Note that it is important to ensure correctness of macro arguments, especially the ancestor name, otherwise the definition may be inconsistent (no compiler warnings will be issued in case of mistake).
+
+In *Appli_ExtSurface.hxx* file:
+~~~~~
+#include <Geom_Surface.hxx>
+class Appli_ExtSurface : public Geom_Surface
+{
+. . .
+public:
+ DEFINE_STANDARD_RTTI(Appli_ExtSurface)
+}
+DEFINE_STANDARD_HANDLE(Appli_ExtSurface,Geom_Surface)
+~~~~~
+
+In *Appli_ExtSurface.cxx* file:
+~~~~~
+#include <Appli_ExtSurface.hxx>
+IMPLEMENT_STANDARD_HANDLE(Appli_ExtSurface,Geom_Surface)
+IMPLEMENT_STANDARD_RTTIEXT(Appli_ExtSurface,Geom_Surface)
+~~~~~
+
+
+@subsection occt_fcug_2_3 Memory Management in Open CASCADE Technology
+In the course of a work session, geometric modeling applications create and delete a considerable number of C++ objects allocated in the dynamic memory (heap). In this context, performance of standard functions for allocating and de-allocating memory may be not sufficient. For this reason, Open CASCADE Technology employs a specialized memory manager implemented in the Standard package.
+
+@subsubsection occt_fcug_2_3_1. Usage
+To use the Open CASCADE Technology memory manager to allocate memory in a C code, just use method *Standard::Allocate()* instead of *malloc()* and method *Standard::Free()* instead of *free()*. In addition, method *Standard::Reallocate()* is provided to replace C function *realloc()*.
+In C++, operators *new()* and *delete()* for a class may be defined so as to allocate memory using *Standard::Allocate()* and free it using *Standard::Free()*. In that case all objects of that class and all inherited classes will be allocated using the OCCT memory manager.
+CDL extractor defines *new()* and *delete()* in this way for all classes declared with CDL. Thus all OCCT classes (apart from a few exceptions) are allocated using the OCCT memory manager.
+Since operators *new()* and *delete()* are inherited, this is also true for any class derived from an OCCT class, for instance, for all classes derived from *Standard_Transient*.
+**NOTE**
+It is possible (though not recommended unless really unavoidable) to redefine *new()* and *delete()* functions for some class inheriting Standard_Transient. If that is done, the method *Delete()* should be also redefined to apply operator *delete* to *this* pointer. This will ensure that appropriate *delete()* function will be called, even if the object is manipulated by a handle to a base class.
+
+@subsubsection occt_fcug_2_3_2 Configuring the memory manager
+The OCCT memory manager may be configured to apply different optimization techniques to different memory blocks (depending on their size), or even to avoid any optimization and use C functions *malloc()* and *free()* directly.
+The configuration is defined by numeric values of the following environment variables:
+ * *MMGT_OPT*: if set to 0 (default) every memory block is allocated in C memory heap directly (via *malloc()* and *free()* functions). In this case, all other options except for *MMGT_CLEAR* are ignored; if set to 1 the memory manager performs optimizations as described below; if set to 2, Intel ® TBB optimized memory manager is used.
+ * *MMGT_CLEAR*: if set to 1 (default), every allocated memory block is cleared by zeros; if set to 0, memory block is returned as it is.
+ * *MMGT_CELLSIZE*: defines the maximal size of blocks allocated in large pools of memory. Default is 200.
+ * *MMGT_NBPAGES*: defines the size of memory chunks allocated for small blocks in pages (operating-system dependent). Default is 1000.
+ * *MMGT_THRESHOLD*: defines the maximal size of blocks that are recycled internally instead of being returned to the heap. Default is 40000.
+ * *MMGT_MMAP*: when set to 1 (default), large memory blocks are allocated using memory mapping functions of the operating system; if set to 0, they will be allocated in the C heap by *malloc()*.
+ * MMGT_REENTRANT: when set to 1 (default), all calls to the optimized memory manager will be secured against possible simultaneous access from different execution threads. This variable should be set in any multithreaded application that uses an optimized memory manager (*MMGT_OPT=1*) and has more than one thread potentially calling OCCT functions. If set to 0, OCCT memory management and exception handling routines will skip the code protecting from possible concurrency in multi-threaded environment. This can yield some performance gain in some applications, but can lead to unpredictable results if used in a multithreaded application.
+**NOTE**
+For applications that use OCCT memory manager from more than one thread, on multiprocessor hardware, it is recommended to use options *MMGT_OPT=2* and *MMGT_REENTRANT=1*.
+@subsubsection occt_fcug_2_3_3 Implementation details
+When *MMGT_OPT* is set to 1, the following optimization techniques are used:
+ * Small blocks with a size less than *MMGT_CELLSIZE*, are not allocated separately. Instead, a large pools of memory are allocated (the size of each pool is *MMGT_NBPAGES* pages). Every new memory block is arranged in a spare place of the current pool. When the current memory pool is completely occupied, the next one is allocated, and so on.
+In the current version memory pools are never returned to the system (until the process finishes). However, memory blocks that are released by the method *Standard::Free()* are remembered in the free lists and later reused when the next block of the same size is allocated (recycling).
+ * Medium-sized blocks, with a size greater than *MMGT_CELLSIZE* but less than *MMGT_THRESHOLD*, are allocated directly in the C heap (using *malloc()* and *free()*). When such blocks are released by the method *Standard::Free()* they are recycled just like small blocks.
+However, unlike small blocks, the recycled medium blocks contained in the free lists (i.e. released by the program but held by the memory manager) can be returned to the heap by method *Standard::Purge()*.
+ * Large blocks with a size greater than *MMGT_THRESHOLD*, including memory pools used for small blocks, are allocated depending on the value of *MMGT_MMAP*: if it is 0, these blocks are allocated in the C heap; otherwise they are allocated using operating-system specific functions managing memory mapped files.
+Large blocks are returned to the system immediately when *Standard::Free()* is called.
+Benefits and drawbacks
+----------------------
+The major benefit of the OCCT memory manager is explained by its recycling of small and medium blocks that makes an application work much faster when it constantly allocates and frees multiple memory blocks of similar sizes. In practical situations, the real gain on the application performance may be up to 50%.
+The associated drawback is that recycled memory is not returned to the operating system during program execution. This may lead to considerable memory consumption and even be misinterpreted as a memory leak. To minimize this effect, the method Standard::Purge() shall be called after the completion of memory-intensive operations.
+The overhead expenses induced by the OCCT memory manager are:
+ * size of every allocated memory block is rounded up to 8 bytes (when MMGT_OPT is 0 (default), the rounding is defined by the CRT; the typical value for 32-bit platforms is 4 bytes)
+ * additional 4 bytes (or 8 on 64-bit platforms) are allocated in the beginning of every memory block to hold its size (or address of the next free memory block when recycled in free list) only when MMGT_OPT is 1
+Note that these overheads may be greater or less than overheads induced by the C heap memory manager, so overall memory consumption may be greater in either optimized or standard modes, depending on circumstances.
+As a general rule, it is advisable to allocate memory through significant blocks. In this way, you can work with blocks of contiguous data, and processing is facilitated for the memory page manager.
+In multithreaded mode (*MMGT_REENTRANT=1*), the OCCT memory manager uses mutex to lock access to free lists, therefore it may have less performance than non-optimized mode in situations when different threads often make simultaneous calls to the memory manager. The reason is that modern implementations of malloc() and free() employ several allocation arenas and thus avoid delays waiting mutex release, which are possible in such situations.
+
+@subsection occt_fcug_2_4 Exception Handling
+Exception handling provides a means of transferring control from a given point in a program being executed to an **exception handler **associated with another point previously executed.
+A method may raise an exception which interrupts its normal execution and transfers control to the handler catching this exception.
+Open CASCADE Technology provides a hierarchy of exception classes with a root class being class Standard_Failure from the Standard package. The CDL extractor generates exception classes with standardized interface.
+Open CASCADE Technology also provides support for converting system signals (such as access violation or division by zero) to exceptions, so that such situations can be safely handled with the same uniform approach.
+However, in order to support this functionality on various platforms, some special methods and workarounds are used. Though the implementation details are hidden and handling of OCCT exceptions is done basically in the same way as with C++, some peculiarities of this approach shall be taken into account and some rules must be respected.
+The following paragraphs describe recommended approaches for using exceptions when working with Open CASCADE Technology.
+@subsubsection occt_fcug_2_4_1 Raising an Exception
+
+“C++ like” Syntax
+-----------------
+To raise an exception of a definite type method Raise() of the appropriate exception class shall be used.
+~~~~~
+DomainError::Raise(“Cannot cope with this condition”);
+~~~~~
+
+raises an exception of DomainError type with the associated message “Cannot cope with this condition”, the message being optional. This exception may be caught by a handler of some DomainError type as follows:
+~~~~~
+try {
+ OCC_CATCH_SIGNALS
+ // try block
+}
+catch(DomainError) {
+// handle DomainError exceptions here
+}
+~~~~~
+
+Regular usage
+-------------
+Exceptions should not be used as a programming technique, to replace a “goto” statement for example, but as a way to protect methods against misuse. The caller must make sure its condition is such that the method can cope with it.
+Thus,
+ * No exception should be raised during normal execution of an application.
+ * A method which may raise an exception should be protected by other methods allowing the caller to check on the validity of the call.
+For example, if you consider the TCollection_Array1 class used with:
+ * a Value function to extract an element
+ * a Lower function to extract the lower bound of the array
+ * an Upper function to extract the upper bound of the array,
+then, the Value function may be implemented as follows:
+
+~~~~~
+Item TCollection_Array1::Value (const Standard_Integer&index) const
+{
+ // where r1 and r2 are the lower and upper bounds of the array
+ if(index r1 || index > r2) {
+ OutOfRange::Raise(“Index out of range in Array1::Value”);
+ }
+ return contents[index];
+}
+~~~~~
+
+Here validity of the index is first verified using the Lower and Upper functions in order to protect the call.
+Normally the caller ensures the index being in the valid range before calling Value(). In this case the above implementation of Value is not optimal since the test done in Value is time-consuming and redundant.
+It is a widely used practice to include that kind of protections in a debug build of the program and exclude in release (optimized) build. To support this practice, the macros Raise_if() are provided for every OCCT exception class:
+~~~~~
+<ErrorTypeName>_Raise_if(condition, “Error message”);
+~~~~~
+where ErrorTypeName is the exception type, condition is the logical expression leading to the raise of the exception, and Error message is the associated message.
+The entire call may be removed by defining one of the pre-processor symbols No_Exception or No_<ErrorTypeName> at compile-time:
+
+~~~~~
+#define No_Exception /* remove all raises */
+~~~~~
+
+Using this syntax, the Value function becomes:
+
+~~~~~
+Item TCollection_Array1::Value (const Standard_Integer&index) const
+ {
+ OutOfRange_Raise_if(index r1 || index > r2,
+ “index out of range in Array1::Value”);
+ return contents[index];
+}
+~~~~~
+
+@subsubsection occt_fcug_2_4_2 Handling an Exception
+When an exception is raised, control is transferred to the nearest handler of a given type in the call stack, that is:
+ * the handler whose try block was most recently entered and not yet exited,
+ * the handler whose type matches the raise expression.
+A handler of T exception type is a match for a raise expression with an exception type of E if:
+ * T and E are of the same type, or
+ * T is a supertype of E.
+In order to handle system signals as exceptions, make sure to insert macro OCC_CATCH_SIGNALS somewhere in the beginning of the relevant code. The recommended location for it is first statement after opening brace of try {} block.
+As an example, consider the exceptions of type NumericError, Overflow, Underflow and ZeroDivide where NumericError is the supertype of the three others.
+
+~~~~~
+void f(1)
+ {
+ try {
+ OCC_CATCH_SIGNALS
+ // try block
+ }
+ catch(Standard_Overflow) { // first handler
+ // ...
+ }
+ catch(Standard_NumericError) { // second handler
+ // ...
+ }
+}
+~~~~~
+
+Here, the first handler will catch exceptions of Overflow type and the second one – exceptions of NumericError type and all exceptions derived from it, including Underflow and Zerodivide.
+The handlers are checked in order of appearance, from the nearest to the most distant try block, until one matches the raise expression. For a try block, it would be a mistake to place a handler for a base exception type ahead of a handler for its derived type since that would ensure that the handler for the derived exception would never be invoked.
+
+~~~~~
+void f(1)
+{
+ int i = 0;
+ {
+ try {
+ OCC_CATCH_SIGNALS
+ g(i);// i is accessible
+ }
+ // statement here will produce compile-time errors !
+ catch(Standard_NumericError) {
+ // fix up with possible reuse of i
+ }
+ // statement here may produce unexpected side effect
+ }
+ . . .
+}
+~~~~~
+
+The exceptions form a hierarchy tree completely separated from other user defined classes. One exception of type Failure is the root of the entire exception hierarchy. Thus, using a handler with Failure type catches any OCCT exception. It is recommended to set up such a handler in the main routine.
+The main routine of a program would look like this:
+
+~~~~~
+#include <Standard_ErrorHandler.hxx>
+#include <Standard_Failure.hxx>
+#include <iostream.h>
+int main (int argc, char* argv[])
+{
+ try {
+ OCC_CATCH_SIGNALS
+ // main block
+ return 0;
+ }
+ catch(Standard_Failure) {
+ Handle(Standard_Failure) error = Standard_Failure::Caught ();
+ cout error end1;
+ }
+ return 1;
+}
+~~~~~
+
+In this example function Caught is a static member of Failure that returns an exception object containing the error message built in the raise expression. Note that this method of accessing a raised object is used in Open CASCADE Technology instead of usual C++ syntax (receiving the exception in catch argument).
+
+**NOTE**
+Though standard C++ scoping rules and syntax apply to try block and handlers, note that on some platforms Open CASCADE Technology may be compiled in compatibility mode when exceptions are emulated by long jumps (see below). In this mode it is required that no statement precedes or follows any handler. Thus it is highly recommended to always include a try block into additional {} braces. Also this mode requires that header file Standard_ErrorHandler.hxx be included in your program before a try block, otherwise it may fail to handle Open CASCADE Technology exceptions; furthermore catch() statement does not allow passing exception object as argument.
+
+Catching signals
+----------------
+In order for the application to be able to catch system signals (access violation, division by zero, etc.) in the same way as other exceptions, the appropriate signal handler shall be installed in the runtime by the method
+OSD::SetSignal();
+Normally this method is called in the beginning of the main() function. It installs a handler that will convert system signals into OCCT exceptions.
+In order to actually convert signals to exceptions, macro OCC_CATCH_SIGNALS shall be inserted in the source code. The typical place where this macro is put is beginning of the try{} block which catches such exceptions.
+
+@subsubsection occt_fcug_2_4_3 Implementation details
+The exception handling mechanism in Open CASCADE Technology is implemented in different ways depending on the preprocessor macros NO_CXX_EXCEPTIONS and OCC_CONVERT_SIGNALS, which shall be consistently defined by compilation procedures for both Open CASCADE Technology and user applications:
+1. On Windows and DEC, these macros are not defined by default, and normal C++ exceptions are used in all cases, including throwing from signal handler. Thus the behavior is as expected in C++.
+2. On SUN and Linux, macro OCC_CONVERT_SIGNALS is defined by default. The C++ exception mechanism is used for catching exceptions and for throwing them from normal code. Since it is not possible to throw C++ exception from system signal handler function, that function makes a long jump to the nearest (in the execution stack) invocation of macro OCC_CATCH_SIGNALS, and only there the C++ exception gets actually thrown. The macro OCC_CATCH_SIGNALS is defined in the file Standard_ErrorHandler.hxx. Therefore, including this file is necessary for successful compilation of a code containing this macro.
+This mode differs from standard C++ exception handling only for signals:
+ + macro OCC_CATCH_SIGNALS is necessary (besides call to OSD::SetSignal() described above) for conversion of signals into exceptions;
+ + the destructors for automatic C++ objects created in the code after that macro and till the place where signal is raised will not be called in case of signal, since no C++ stack unwinding is performed by long jump.
+3.On SUN and Linux Open CASCADE Technology can also be compiled in compatibility mode (which was default till Open CASCADE Technology 6.1.0). In that case macro NO_CXX_EXCEPTIONS is defined and the C++ exceptions are simulated with C long jumps. As a consequence, the behavior is slightly different from that expected in the C++ standard.
+While exception handling with NO_CXX_EXCEPTIONS is very similar to C++ by syntax, it has a number of peculiarities that should be taken into account:
+ * try and catch are actually macros defined in the file Standard_ErrorHandler.hxx. Therefore, including this file is necessary for handling OCCT exceptions;
+ * due to being a macro, catch cannot contain a declaration of the exception object after its type; only type is allowed in the catch statement. Use method Standard_Failure::Caught() to access an exception object;
+ * catch macro may conflict with some STL classes that might use catch(…) statements in their header files. So STL headers should not be included after Standard_ErrorHandler.hxx;
+ * Open CASCADE Technology try/catch block will not handle normal C++ exceptions; however this can be achieved using special workarounds;
+ * the try macro defines a C++ object that holds an entry point in the exception handler. Therefore if exception is raised by code located immediately after the try/catch block but on the same nesting level as *try*, it may be handled by that *catch*. This may lead to unexpected behavior, including infinite loop. To avoid that, always surround the try/catch block in {} braces;
+ * the destructors of the C++ objects allocated on the stack after handler initialization are not called by exception raising.
+In general, for writing platform-independent code it is recommended to insert macros OCC_CATCH_SIGNALS in try {} blocks or other code where signals may happen. For compatibility with previous versions of Open CASCADE Technology the limitations described above for NO_CXX_EXCEPTIONS shall be assumed.
+
+@subsection occt_fcug_2_5 Plug-In Management
+@subsubsection occt_fcug_2_5_1 Distribution by Plug-Ins
+A plug-in is a component that can be loaded dynamically into a client application, not requiring to be directly linked to it. The plug-in is not bound to its client, i.e. the plug-in knows only how its connection mechanism is defined and how to call the corresponding services.
+A plug-in can be used to:
+ * implement the mechanism of a *driver*, i.e dynamically changing a driver implementation according to the current transactions (for example, retrieving a document stored in another version of an application),
+ * restrict processing resources to the minimum required (for example, it does not load any application services at run-time as long as the user does not need them),
+ * facilitate development de-synchronization (an application can be delivered with base functions while some advanced capabilities will be added as plug-ins when they are available).
+The plug-in is identified with the help of the global universal identifier (GUID). The GUID includes lower case characters and cannot end with a blank space.
+Once it has been loaded, the call to the services provided by the plug-in is direct (the client is implemented in the same language as the plug-in).
+
+C++ Plug-In Implementation
+---------------------------
+The C++ plug-in implements a service as an object with functions defined in an abstract class (this abstract class and its parent classes with the GUID are the only information about the plug-in implemented in the client application). The plug-in consists of a sharable library including a method named Factory which creates the C++ object (the client cannot instantiate this object because the plug-in implementation is not visible).
+Foundation classes provide in the package **Plugin** a method named Load(), which enables the client to access the required service through a library.
+That method reads the information regarding available plug-ins and their locations from the resource file Plugin found by environment variable CSF_PluginDefaults:
+
+~~~~~
+$CSF_PluginDefaults/.Plugin
+~~~~~
+
+The Load method looks for the library name in the resource file or registry through its GUID, for example, on UNIX:
+~~~~~
+! METADATADRIVER whose value must be OS or DM.
+
+! FW
+a148e300-5740-11d1-a904-080036aaa103.Location:
+
+libFWOSPlugin.so
+a148e300-5740-11d1-a904-080036aaa103.CCL:
+/adv_44/CAS/BAG/FW-K4C/inc/FWOS.ccl
+
+! FWDM
+a148e301-5740-11d1-a904-080036aaa103.Location:
+libFWDMPlugin.so
+a148e301-5740-11d1-a904-080036aaa103.CCL:
+/adv_44/CAS/BAG/DESIGNMANAGER-K4C/inc/DMAccess.ccl|/
+adv_44/CAS/BAG/DATABASE-K4C/inc/FWDMCommands.ccl
+a148e301-5740-11d1-a904-080036aaa103.Message: /adv_44/CAS/
+BAG/DESIGNMANAGER-K4C/etc/locale/DMAccess
+
+! Copy-Paste
+5ff7dc00-8840-11d1-b5c2-00a0c9064368.Location:
+libCDMShapeDriversPlugin.so
+5ff7dc01-8840-11d1-b5c2-00a0c9064368.Location:
+libCDMShapeDriversPlugin.so
+5ff7dc02-8840-11d1-b5c2-00a0c9064368.Location:
+libCDMShapeDriversPlugin.so
+5ff7dc03-8840-11d1-b5c2-00a0c9064368.Location:
+libCDMShapeDriversPlugin.so
+5ff7dc04-8840-11d1-b5c2-00a0c9064368.Location:
+libCDMShapeDriversPlugin.so
+
+! Plugs 2d plotters:
+d0d722a2-b4c9-11d1-b561-0000f87a4710.location: FWOSPlugin
+d0d722a2-b4c9-11d1-b561-0000f87a4710.CCL: /adv_44/CAS/BAG/
+VIEWERS-K4C/inc/CCLPlotters.ccl
+d0d722a2-b4c9-11d1-b561-0000f87a4710.Message: /adv_44/CAS/
+BAG/VIEWERS-K4C/etc/locale/CCLPlotters
+
+!SHAPES
+e3708f72-b1a8-11d0-91c2-080036424703.Location:
+libBRepExchangerPlugin.so
+e3708f72-b1a8-11d0-91c2-080036424703.CCL: /adv_44/CAS/BAG/
+FW-K4C/inc/BRep.ccl
+~~~~~
+
+
+Then the Load method loads the library according to the rules of the operating system of the host machine (for example, by using environment variables such as LD_LIBRARY_PATH with Unix and PATH with Windows). After that it invokes the Factory method to return the object which supports the required service.
+The client may then call the functions supported by this object.
+
+C++ Client Plug-In Implementation
+----------------------------------
+To invoke one of the services provided by the plug-in, you may call the Plugin::ServiceFactory global function with the Standard_GUID of the requested service as follows:
+
+~~~~~
+Handle(FADriver_PartStorer)::DownCast
+(PlugIn::ServiceFactory
+(PlugIn_ServiceId(yourStandardGUID)))
+~~~~~
+
+Let us take **FAFactory.cxx** as an example:
+
+~~~~~
+#include <FAFactory.ixx>
+
+#include <FADriver_PartRetriever.hxx>
+#include <FADriver_PartStorer.hxx>
+#include <FirstAppSchema.hxx>
+#include <Standard_GUID.hxx>
+#include <Standard_Failure.hxx>
+#include <FACDM_Application.hxx>
+#include <Plugin_Macro.hxx>
+
+PLUGIN(FAFactory)
+
+static Standard_GUID
+ StorageDriver(“45b3c690-22f3-11d2-b09e-0000f8791463”);
+static Standard_GUID
+ RetrievalDriver(“45b3c69c-22f3-11d2-b09e-0000f8791463”);
+static Standard_GUID
+ Schema(“45b3c6a2-22f3-11d2-b09e-0000f8791463”);
+
+//======================================================
+// function : Factory
+// purpose :
+//======================================================
+
+Handle(Standard_Transient) FAFactory::Factory(const Standard_GUID& aGUID)
+{
+ if(aGUID == StorageDriver) {
+ cout “FAFactory : Create store driver” endl;
+ static Handle(FADriver_PartStorer) sd = new FADriver_PartStorer();
+ return sd;
+ }
+
+ if(aGUID == RetrievalDriver) {
+ cout “FAFactory : Create retrieve driver” endl;
+ static Handle(FADriver_PartRetriever)
+ rd = new FADriver_PartRetriever();
+ return rd;
+ }
+
+ if(aGUID == Schema) {
+ cout “FAFactory : Create schema” endl;
+ static Handle(FirstAppSchema) s = new FirstAppSchema();
+ return s;
+ }
+
+ Standard_Failure::Raise(“FAFactory: unknown GUID”);
+ Handle(Standard_Transient) t;
+ return t;
+}
+~~~~~
+
+Without using the Software Factory
+-------------------------------
+
+To create a factory without using the Software Factory, define a **dll **project under Windows or a library under UNIX by using a source file as specified above. The **FAFactory **class is implemented as follows:
+
+~~~~~
+#include <Handle_Standard_Transient.hxx>
+#include <Standard_Macro.hxx>
+class Standard_Transient;
+class Standard_GUID;
+class FAFactory {
+public:
+ Standard_EXPORT static Handle_Standard_Transient
+ Factory(const Standard_GUID& aGUID) ;
+ . . .
+};
+~~~~~
+
+
+@section occt_fcug_3 Collections, Strings and Unit Conversion
+@subsection occt_fcug_3_1. Collections
+@subsubsection occt_fcug_3_1_1 Overview
+The **Collections** component contains the classes that handle dynamically sized aggregates of data. They include a wide range of collections such as arrays, lists and maps.
+Collections classes are *generic*, that is, they can hold a variety of objects which do not necessarily inherit from a unique root class. When you need to use a collection of a given type of object you must *instantiate* it for this specific type of element. Once this declaration is compiled, all the functions available on the generic collection are available on your *instantiated class*. Note however:
+ * Each collection directly used as an argument in OCCT public syntax is instantiated in an OCCT component.
+ * The **TColStd** package (**Collections of Standard Objects** component) provides numerous instantiations of these generic collections with objects from the **Standard** package or from the **Strings** component.
+The **Collections** component provides a wide range of generic collections:
+ * *Arrays*are generally used for a quick access to the item, however an array is a fixed sized aggregate.
+ * *Sequences* are variable-sized structures, they avoid the use of large and quasi-empty arrays. A sequence item is longer to access than an array item: only an exploration in sequence is effective (but sequences are not adapted for numerous explorations). Arrays and sequences are commonly used as data structures for more complex objects.
+ * On the other hand, *maps *are dynamic structures where the size is constantly adapted to the number of inserted items and the access time for an item is effective. Maps structures are commonly used in cases of numerous explorations: they are typically internal data structures for complex algorithms. *Sets *generate the same results as maps but computation time is considerable.
+ * *Lists, queues *and *stacks *are minor structures similar to sequences but with other exploration algorithms.
+Most collections follow *value semantics*: their instances are the actual collections, not *handles *to a collection. Only arrays and sequences may also be manipulated by handle, and therefore shared.
+
+@subsubsection occt_fcug_3_1_2 Generic general-purpose Aggregates
+
+TCollection_Array1
+------------------
+Unidimensional arrays similar to C arrays, i.e. of fixed size but dynamically dimensioned at construction time.
+As with a C array, the access time for an **Array1 **indexed item is constant and is independent of the array size. Arrays are commonly used as elementary data structures for more complex objects.
+**Array1** is a generic class which depends on **Item**, the type of element in the array.
+**Array1** indexes start and end at a user-defined position. Thus, when accessing an item, you must base the index on the lower and upper bounds of the array.
+
+TCollection_Array2
+------------------
+Bi-dimensional arrays of fixed size but dynamically dimensioned at construction time.
+As with a C array, the access time for an **Array2 **indexed item is constant and is independent of the array size. Arrays are commonly used as elementary data structures for more complex objects.
+**Array2 **is a generic class which depends on **Item**, the type of element in the array.
+**Array2 **indexes start and end at a user-defined position. Thus, when accessing an item, you must base the index on the lower and upper bounds of the array.
+
+TCollection_HArray1
+-------------------
+Unidimensional arrays similar to C arrays, i.e. of fixed size but dynamically dimensioned at construction time.
+As with a C array, the access time for an **HArray1** or **HArray2** indexed item is constant and is independent of the array size. Arrays are commonly used as elementary data structures for more complex objects.
+**HArray1** objects are *handles *to arrays.
+ * **HArray1 **arrays may be shared by several objects.
+ * You may use a **TCollection_Array1 **structure to have the actual array.
+**HArray1 **is a generic class which depends on two parameters:
+ * **Item**, the type of element in the array,
+ * **Array**, the actual type of array handled by **HArray1**. This is an instantiation with **Item **of the **TCollection_Array1 **generic class.
+**HArray1 **indexes start and end at a user-defined position. Thus, when accessing an item, you must base the index on the lower and upper bounds of the array.
+
+TCollection_HArray2
+-------------------
+Bi-dimensional arrays of fixed size but dynamically dimensioned at construction time.
+As with a C array, the access time for an **HArray2 **indexed item is constant and is independent of the array size. Arrays are commonly used as elementary data structures for more complex objects.
+**HArray2 **objects are *handles *to arrays.
+ * **HArray2 **arrays may be shared by several objects.
+ * You may use a **TCollection_Array2 **structure to have the actual array.
+**HArray2 **is a generic class which depends on two parameters:
+ * **Item**, the type of element in the array,
+ * **Array**, the actual type of array handled by **HArray2**. This is an instantiation with **Item **of the **TCollection_Array2 **generic class.
+
+TCollection_HSequence
+---------------------
+
+A sequence of items indexed by an integer.
+Sequences have about the same goal as unidimensional arrays (**TCollection_HArray1**): they are commonly used as elementary data structures for more complex objects. But a sequence is a structure of *variable size*: sequences avoid the use of large and quasi-empty arrays. Exploring a sequence data structure is effective when the exploration is done *in sequence; *elsewhere a sequence item is longer to read than an array item. Note also that sequences are not effective when they have to support numerous algorithmic explorations: a map is better for that.
+**HSequence **objects are *handles *to sequences.
+ * **HSequence **sequences may be shared by several objects.
+ * You may use a **TCollection_Sequence **structure to have the actual sequence.
+**HSequence **is a generic class which depends on two parameters:
+ * **Item**, the type of element in the sequence,
+ * **Seq**, the actual type of sequence handled by **HSequence**. This is an instantiation with **Item **of the **TCollection_Sequence **generic class.
+
+TCollection_HSet
+----------------
+Collection of non-ordered items without any duplicates. At each transaction, the system ckecks to see that there are no duplicates.
+**HSet **objects are *handles *to sets.
+**HSet **is a generic class which depends on two parameters:
+ * **Item**, the type of element in the set,
+ * **Set**, the actual type of set handled by **HSet**. This is an instantiation with **TCollection_Set **generic class.
+
+TCollection_List
+----------------
+Ordered lists of non-unique objects which can be accessed sequentially using an iterator.
+Item insertion in a list is very fast at any position. But searching for items by value may be slow if the list is long, because it requires a sequential search.
+**List **is a generic class which depends on **Item**, the type of element in the structure.
+Use a **ListIterator **iterator to explore a **List **structure.
+An iterator class is automatically instantiated from the **TCollection_ListIterator **class at the time of instantiation of a **List **structure.
+A sequence is a better structure when searching for items by value.
+Queues and stacks are other kinds of list with a different access to data.
+
+TCollection_Queue
+-----------------
+A structure where items are added at the end and removed from the front. The first item entered will be the first removed (**FIFO** structure: First In First Out). **Queue** is a generic class which depends on **Item**, the type of element in the structure.
+
+TCollection_Sequence
+--------------------
+A sequence of items indexed by an integer.
+Sequences have about the same goal as unidimensional arrays (**TCollection_Array1**): they are commonly used as elementary data structures for more complex objects. But a sequence is a structure of *variable size*: sequences avoid the use of large and quasi-empty arrays. Exploring a sequence data structure is effective when the exploration is done *in sequence*; elsewhere a sequence item is longer to read than an array item. Note also that sequences are not effective when they have to support numerous algorithmic explorations: a map is better for that.
+**Sequence **is a generic class which depends on **Item**, the type of element in the sequence.
+
+TCollection_Set
+---------------
+Collection of non-ordered items without any duplicates. At each transaction, the system ckecks there are no duplicates.
+A set generates the same result as a map. A map is more effective; so it is advisable to use maps instead of sets.
+**Set **is a generic class which depends on **Item**, the type of element in the set.
+Use a **SetIterator **iterator to explore a **Set **structure.
+
+TCollection_Stack
+------------------
+A structure where items are added and removed from the top. The last item entered will be the first removed (;**LIFO**; structure: Last In First Out).
+**Stack**is a generic class which depends on **Item**, the type of element in the structure.
+Use a **StackIterator **iterator to explore a **Stack **structure.
+
+@subsubsection occt_fcug_3_1_3 Generic Maps
+
+Maps are dynamically extended data structures where data is quickly accessed with a key. TCollection_BasicMap is a root class for maps.
+
+General properties of maps
+--------------------------
+
+Map items may contain complex non-unitary data, thus it can be difficult to manage them with an array. The map allows a data structure to be indexed by complex data.
+The size of a map is dynamically extended. So a map may be first dimensioned for a little number of items. Maps avoid the use of large and quasi-empty arrays.
+The access time for a map item is much better than the one for a sequence, list, queue or stack item. It is comparable with the access time for an array item. It depends on the size of the map and on the quality of the user redefinable function (the *hashing function*) to find quickly where is the item.
+
+The performance of a map exploration may be better of an array exploration because the size of the map is adapted to the number of inserted items.
+That is why maps are commonly used as internal data structures for algorithms.
+
+Definitions
+-----------
+A map is a data structure for which data are addressed by *keys*.
+Once inserted in the map, a map item is referenced as an *entry *of the map.
+Each entry of the map is addressed by a key. Two different keys address two different entries of the map.
+The position of an entry in the map is called a *bucket*.
+A map is dimensioned by its number of buckets, i.e. the maximum number of entries in the map. The performance of a map is conditioned by the number of buckets.
+The *hashing function *transforms a key into a bucket index. The number of values that can be computed by the hashing function is equal to the number of buckets of the map.
+Both the hashing function and the equality test between two keys are provided by a *hasher *object.
+A map may be explored by a *map iterator*. This exploration provides only inserted entries in the map (i.e. non empty buckets).
+
+Collections of generic maps
+------------------------
+The **Collections **component provides numerous generic derived maps.
+These maps include automatic management of the number of *buckets*: they are automatically resized when the number of *keys *exceeds the number of buckets. If you have a fair idea of the number of items in your map, you can save on automatic resizing by specifying a number of buckets at the time of construction, or by using a resizing function. This may be considered for crucial optimization issues.
+*Keys, items* and *hashers* are parameters of these generic derived maps.
+**TCollection_MapHasher** class describes the functions required by any *hasher *which is to be used with a map instantiated from the **Collections **component.
+An iterator class is automatically instantiated at the time of instantiation of a map provided by the **Collections **component if this map is to be explored with an iterator. Note that some provided generic maps are not to be explored with an iterator but with indexes (*indexed maps*).
+
+TCollection_DataMap
+-------------------
+A map used to store keys with associated items. An entry of **DataMap **is composed of both the key and the item.
+The **DataMap **can be seen as an extended array where the keys are the indexes.
+**DataMap **is a generic class which depends on three parameters:
+ * **Key **is the type of key for an entry in the map,
+ * **Item **is the type of element associated with a key in the map,
+ * **Hasher **is the type of hasher on keys.
+Use a **DataMapIterator **iterator to explore a DataMap map.
+An iterator class is automatically instantiated from the
+**TCollection_DataMapIterator **generic class at the time of instantiation of a **DataMap **map.
+**TCollection_MapHasher **class describes the functions required for a **Hasher **object.
+
+TCollection_DoubleMap
+---------------------
+A map used to bind pairs of keys (Key1,Key2) and retrieve them in linear time.
+Key1 is referenced as the *first key *of the **DoubleMap **and Key2 as the *second key*.
+An entry of a **DoubleMap **is composed of a pair of two keys: the first key and the second key.
+**DoubleMap **is a generic class which depends on four parameters:
+ * **Key1 **is the type of the first key for an entry in the map,
+ * **Key2 **is the type of the second key for an entry in the map,
+ * **Hasher1 **is the type of hasher on first keys,
+ * **Hasher2 **is the type of hasher on second keys.
+Use a **DoubleMapIterator **to explore a **DoubleMap **map.
+An iterator class is automatically instantiated from the **TCollection_DoubleMapIterator **class at the time of instantiation of a **DoubleMap **map.
+**TCollection_MapHasher **class describes the functions required for a **Hasher1 **or a **Hasher2 **object.
+
+TCollection_IndexedDataMap
+--------------------------
+A map to store keys with associated items and to bind an index to them.
+Each new key stored in the map is assigned an index. Indexes are incremented as keys (and items) stored in the map. A key can be found by the index, and an index can be found by the key. No key but the last can be removed, so the indexes are in the range 1...Upper where Upper is the number of keys stored in the map. An item is stored with each key.
+An entry of an **IndexedDataMap **is composed of both the key, the item and the index. An **IndexedDataMap **is an ordered map, which allows a linear iteration on its contents. It combines the interest:
+ * of an array because data may be accessed with an index,
+ * and of a map because data may also be accessed with a key.
+
+**IndexedDataMap **is a generic class which depends on three parameters:
+ * **Key **is the type of key for an entry in the map,
+ * **Item **is the type of element associated with a key in the map,
+ * **Hasher **is the type of hasher on keys.
+
+TCollection_IndexedMap
+----------------------
+A map used to store keys and to bind an index to them.
+Each new key stored in the map is assigned an index. Indexes are incremented as keys stored in the map. A key can be found by the index, and an index by the key. No key but the last can be removed, so the indexes are in the range 1...Upper where Upper is the number of keys stored in the map.
+An entry of an **IndexedMap **is composed of both the key and the index. An **IndexedMap **is an ordered map, which allows a linear iteration on its contents. But no data is attached to the key. An **IndexedMap **is typically used by an algorithm to know if some action is still performed on components of a complex data structure.
+**IndexedMap **is a generic class which depends on two parameters:
+ * **Key **is the type of key for an entry in the map,
+ * **Hasher **is the type of hasher on keys.
+
+TCollection_Map
+---------------
+
+A basic hashed map, used to store and retrieve keys in linear time.
+An entry of a **Map **is composed of the key only. No data is attached to the key. A **Map **is typically used by an algorithm to know if some action is still performed on components of a complex data structure.
+**Map **is a generic class which depends on two parameters:
+ * **Key **is the type of key in the map,
+ * **Hasher **is the type of hasher on keys.
+Use a **MapIterator **iterator to explore a **Map **map.
+
+TCollection_MapHasher
+---------------------
+A hasher on the *keys *of a map instantiated from the **Collections **component.
+A hasher provides two functions:
+ * The *hashing function *(**HashCode**) transforms a *key *into a *bucket *index in the map. The number of values that can be computed by the hashing function is equal to the number of buckets in the map.
+ * **IsEqual **is the equality test between two keys. Hashers are used as parameters in generic maps provided by the **Collections **component.
+**MapHasher **is a generic class which depends on the type of keys, providing that **Key **is a type from the **Standard **package. In such cases **MapHasher **may be directly instantiated with **Key**. Note that the package **TColStd **provides some of these instantiations.
+Elsewhere, if **Key **is not a type from the **Standard **package you must consider **MapHasher **as a template and build a class which includes its functions, in order to use it as a hasher in a map instantiated from the **Collections **component.
+Note that **TCollection_AsciiString **and **TCollection_ExtendedString **classes correspond to these specifications, in consequence they may be used as hashers: when **Key **is one of these two types you may just define the hasher as the same type at the time of instantiation of your map.
+
+@subsubsection occt_fcug_3_1_4 Iterators
+
+TCollection_BasicMapIterator
+----------------------------
+Root class for map iterators. A map iterator provides a step by step exploration of all the entries of a map.
+
+TCollection_DataMapIterator
+---------------------------
+Functions used for iterating the contents of a **DataMap **map.
+A map is a non-ordered data structure. The order in which entries of a map are explored by the iterator depends on its contents and change when the map is edited.
+It is not recommended to modify the contents of a map during the iteration: the result is unpredictable.
+
+TCollection_DoubleMapIterator
+-----------------------------
+Functions used for iterating the contents of a **DoubleMap **map.
+
+TCollection_ListIterator
+------------------------
+Functions used for iterating the contents of a **List **data structure.
+A **ListIterator **object can be used to go through a list sequentially, and as a bookmark to hold a position in a list. It is not an index, however. Each step of the iteration gives the *current position *of the iterator, to which corresponds the *current item *in the list. The *current position *is *undefined *if the list is empty, or when the exploration is finished.
+An iterator class is automatically instantiated from this generic class at the time of instantiation of a **List **data structure.
+
+TCollection_MapIterator
+------------------------
+Functions used for iterating the contents of a **Map **map.
+An iterator class is automatically instantiated from this generic class at the time of instantiation of a **Map **map.
+
+TCollection_SetIterator
+-----------------------
+Functions used for iterating the contents of a **Set **data structure.
+An iterator class is automatically instantiated from this generic class at the time of instantiation of a **Set **structure.
+
+TCollection_StackIterator
+-------------------------
+Functions used for iterating the contents of a **Stack **data structure.
+An iterator class is automatically instantiated from this generic class at the time of instantiation of a **Stack **structure.
+
+@subsection occt_fcug_3_2 Collections of Standard Objects
+@subsubsection occt_fcug_3_2_1 Overview
+While generic classes of the **TCollection **package are the root classes that describe the generic purpose of every type of collection, classes effectively used are extracted from the **TColStd **package.
+The **TColStd **and **TShort **packages provide frequently used instantiations of generic classes with objects from the **Standard **package or strings from the **TCollection **package.
+
+@subsubsection occt_fcug_3_2_2 Description
+These instantiations are the following:
+ * Unidimensional arrays: instantiations of the **TCollection_Array1 **generic class with **Standard **Objects and **TCollection **strings.
+ * Bidimensional arrays: instantiations of the **TCollection_Array2 **generic class with **Standard **Objects.
+ * Unidimensional arrays manipulated by handles: instantiations of the **TCollection_HArray1 **generic class with **Standard **Objects and **TCollection **strings.
+ * Bidimensional arrays manipulated by handles: instantiations of the **TCollection_HArray2 **generic class with **Standard **Objects.
+ * Sequences: instantiations of the **TCollection_Sequence **generic class with **Standard **objects and **TCollection **strings.
+ * Sequences manipulated by handles: instantiations of the **TCollection_HSequence **generic class with **Standard **objects and **TCollection **strings.
+ * Lists: instantiations of the **TCollection_List **generic class with **Standard **objects.
+ * Queues: instantiations of the **TCollection_Queue **generic class with **Standard **objects.
+ * Sets: instantiations of the **TCollection_Set **generic class with **Standard **objects.
+ * Sets manipulated by handles: instantiations of the **TCollection_HSet **generic class with **Standard **objects.
+ * Stacks: instantiations of the **TCollection_Stack **generic class with **Standard **objects.
+ * Hashers on map keys: instantiations of the **TCollection_MapHasher **generic class with **Standard **objects.
+ * Basic hashed maps: instantiations of the **TCollection_Map **generic class with **Standard **objects.
+ * Hashed maps with an additional item: instantiations of the **TCollection_DataMap **generic class with **Standard **objects.
+ * Basic indexed maps: instantiations of the **TCollection_IndexedMap **generic class with **Standard **objects.
+ * Indexed maps with an additional item: instantiations of the **TCollection_IndexedDataMap **generic class with **Standard_Transient **objects.
+ * Class **TColStd_PackedMapOfInteger** provides alternative implementation of map of integer numbers, optimized for both performance and memory usage (it uses bit flags to encode integers, which results in spending only 24 bytes per 32 integers stored in optimal case). This class also provides Boolean operations with maps as sets of integers (union, intersection, subtraction, difference, checks for equality and containment).
+
+@subsection occt_fcug_3_3 NCollections
+@subsubsection occt_fcug_3_3_1 Overview
+
+NCollection package allows to not use WOK development environment in projects. Though it is quite natural to develop a code based on OCCT in any environment accepted in the industry, there is still one limitation: the so-called OCCT generic classes provided in TCollection package require compilation of the definitions in the CDL language and therefore can only be instantiated in WOK development environment.
+
+The NCollection library provides a full replacement of all TCollection generic classes so that any OCCT collection could be instantiated via C++ template or macro definitions. It can be used in WOK as a package development unit, or in any other configuration, since it only uses the standard capabilities of C++ compiler.
+
+Macro definitions of these classes are stored in *NCollection_Define*.hxx* files. These definitions are now obsolete though still can be used, particularly for compatibility with the existing code. On the contrary, template classes in *NCollection_*.hxx* files are recommended, they are supported by OPEN CASCADE Company and further developed according to various needs.
+
+The technology used in this unit continues and complements the one offered in the header file Standard_DefineHandle – allowing to implement outside CDL the classes managed by Handle, also providing OCCT RTTI support.
+
+@subsubsection occt_fcug_3_3_2 Instantiation of collection classes
+
+Now we are going to implement the definitions from NCollection in the code, taking as an example a sequence of points (analogue of *TColgp_SequenceOfPnt*).
+
+Definition of a new collection class
+------------------------------------
+
+Let the header file be *MyPackage_SequenceOfPnt.hxx* :
+
+Template class instantiaton
+~~~~~
+#include <NCollection_Sequence.hxx>
+#include <gp_Pnt.hxx>
+typedef NCollection_Sequence<gp_Pnt> MyPackage_SequenceOfPnt;
+~~~~~
+
+Macro instantiation
+~~~~~
+#include <NCollection_DefineSequence.hxx>
+#include <gp_Pnt.hxx>
+~~~~~
+
+The following line defines the class "base collection of points"
+~~~~~
+DEFINE_BASECOLLECTION(MyPackage_BaseCollPnt, gp_Pnt)
+~~~~~
+
+The following line defines the class MyPackage_SequenceOfPnt
+
+~~~~~
+DEFINE_SEQUENCE (MyPackage_SequenceOfPnt, MyPackage_BaseCollPnt , gp_Pnt)
+~~~~~
+
+Definition of a new collection class managed by Handle
+------------------------------------------------------
+
+It is necessary to provide relevant statements both in the header ( .hxx file) and the C++ source ( .cxx file).
+
+Header file MyPackage_HSequenceOfPnt.hxx:
+
+~~~~~
+#include <NCollection_DefineHSequence.hxx>
+#include <gp_Pnt.hxx>
+~~~~~
+
+The following line defines the class "base collection of points"
+
+~~~~~
+DEFINE_BASECOLLECTION(MyPackage_BaseCollPnt, gp_Pnt)
+~~~~~
+
+The following line defines the class MyPackage_SequenceOfPnt
+
+~~~~~
+DEFINE_SEQUENCE (MyPackage_SequenceOfPnt, MyPackage_BaseCollPnt, gp_Pnt)
+~~~~~
+
+The following line defines the classes MyPackage_HSequenceOfPnt and Handle(MyPackage_HSequenceOfPnt)
+
+~~~~~
+DEFINE_HSEQUENCE (MyPackage_HSequenceOfPnt, MyPackage_SequenceOfPnt)
+~~~~~
+
+Source code file will be MyPackage_HSequenceOfPnt.cxx or any other .cxx file (once in the whole project):
+
+~~~~~
+IMPLEMENT_HSEQUENCE (MyPackage_HSequenceOfPnt)
+~~~~~
+
+@subsubsection occt_fcug_3_3_3 Class architecture
+
+Architecture
+------------
+
+To understand the basic architecture of the classes instantiated from NCollection macros, please refer to the documentation on TCollection package, particularly to CDL files. Almost all API described there is preserved in NCollection. Changes are described in corresponding NCollection_Define*.hxx files.
+
+Nevertheless the internal structure of NCollection classes is more complex than that of TCollection ones, providing more capabilities. The advanced layer of architecture is described in the next chapter Features.
+
+There are two principal changes:
+* In TCollection some classes ( Stack, List, Set, Map, DataMap, DoubleMap ) define the Iterator type, the name of Iterator being like MyPackage_DoubleMapIteratorOfDoubleMapOfIntegerReal. In NCollection each Iterator is always defined as subtype of the collection (MyPackage_DoubleMapOfIntegerReal::Iterator).
+* Hashed collections (of type Map* ) require in TCollection that the special class Map*Hasher is defined. In NCollection it is only required that the global functions IsEqual and HashCode are defined.
+
+Interface to classes defined in CDL
+-----------------------------------
+The classes defined above can be used as types for fields, parameters of methods and return values in CDL definitions. In our example, if MyPackage is a CDL package, you will need to create the file MyPackage_SequenceOfPnt.hxx containing or including the above definitions, and then to add the line: imported SequenceOfPnt to file MyPackage.cdl;
+
+Then the new collection type can be used in any CDL definition under the name *SequenceOfPnt* from *MyPackage*.
+
+@subsubsection occt_fcug_3_3_4 New collection types
+
+There are 4 collection types provided as template classes:
+* NCollection_Vector
+* NCollection_UBTree
+* NCollection_SparseArray
+* NCollection_CellFilter
+
+Type Vector
+-----------
+
+This type is implemented internally as a list of arrays of the same size. Its properties:
+* Direct (constant-time) access to members like in Array1 type; data are allocated in compact blocks, this provides faster iteration.
+* Can grow without limits, like List, Stack or Queue types.
+* Once having the size LEN, it cannot be reduced to any size less than LEN – there is no operation of removal of items.
+
+Insertion in a Vector-type class is made by two methods:
+* _SetValue(ind, theValue)_ – array-type insertion, where ind is the index of the inserted item, can be any non-negative number. If it is greater than or equal to Length(), then the vector is enlarged (its Length() grows).
+* _Append(theValue)_ – list-type insertion equivalent to _myVec.SetValue(myVec.Length(), theValue)_ – incrementing the size of the collection.
+
+Other essential properties coming from List and Array1 type collections:
+* Like in List, the method Clear() destroys all contained objects and releases the allocated memory.
+* Like in Array1, the methods Value() and ChangeValue() return a contained object by index. Also, these methods have the form of overloaded operator ().
+
+Type UBTree
+-----------
+
+The name of this type stands for “Unbalanced Binary Tree”. It stores the members in a binary tree of overlapped bounding objects (boxes or else).
+Once the tree of boxes of geometric objects is constructed, the algorithm is capable of fast geometric selection of objects. The tree can be easily updated by adding to it a new object with bounding box.
+The time of adding to the tree of one object is O(log(N)), where N is the total number of objects, so the time of building a tree of N objects is O(N(log(N)). The search time of one object is O(log(N)).
+
+Defining various classes inheriting NCollection_UBTree::Selector we can perform various kinds of selection over the same b-tree object.
+
+The object may be of any type allowing copying. Among the best suitable solutions there can be a pointer to an object, handled object or integer index of object inside some collection. The bounding object may have any dimension and geometry. The minimal interface of TheBndType (besides public empty and copy constructor and operator =) used in UBTree algorithm as follows:
+
+~~~~~
+ class MyBndType
+ {
+ public:
+ inline void Add (const MyBndType& other);
+ // Updates me with other bounding type instance
+
+ inline Standard_Boolean IsOut (const MyBndType& other) const;
+ // Classifies other bounding type instance relatively me
+
+ inline Standard_Real SquareExtent() const;
+ // Computes the squared maximal linear extent of me (for a box it is the squared diagonal of the box).
+ };
+
+This interface is implemented in types of Bnd package: Bnd_Box, Bnd_Box2d, Bnd_B2x, Bnd_B3x.
+
+To select objects you need to define a class derived from UBTree::Selector that should redefine the necessary virtual methods to maintain the selection condition. Usually this class instance is also used to retrieve selected objects after search.
+The class UBTreeFiller is used to randomly populate an UBTree instance. The quality of a tree is better (considering the speed of searches) if objects are added to it in a random order trying to avoid the addition of a chain of nearby objects one following another.
+Instantiation of UBTreeFiller collects objects to be added, and then adds them at once to the given UBTree instance in a random order using the Fisher-Yates algorithm.
+Below is the sample code that creates an instance of NCollection_UBTree indexed by 2D boxes (Bnd_B2f), then a selection is performed returning the objects whose bounding boxes contain the given 2D point.
+
+~~~~~
+typedef NCollection_UBTree<MyData, Bnd_B2f> UBTree;
+typedef NCollection_List<MyData> ListOfSelected;
+//! Tree Selector type
+class MyTreeSelector : public UBTree::Selector
+{
+public:
+ // This constructor initializes the selection criterion (e.g., a point)
+
+ MyTreeSelector (const gp_XY& thePnt) : myPnt(thePnt) {}
+ // Get the list of selected objects
+
+ const ListOfSelected& ListAccepted () const
+ { return myList; }
+ // Bounding box rejection - definition of virtual method. @return True if theBox is outside the selection criterion.
+
+ Standard_Boolean Reject (const Bnd_B2f& theBox) const
+ { return theBox.IsOut(myPnt); }
+ // Redefined from the base class. Called when the bounding of theData conforms to the selection criterion. This method updates myList.
+
+ Standard_Boolean Accept (const MyData& theData)
+ { myList.Append(theData); }
+ private:
+ gp_XY myPnt;
+ ListOfSelected myList;
+};
+. . .
+// Create a UBTree instance and fill it with data, each data item having the corresponding 2D box.
+
+UBTree aTree;
+NCollection_UBTreeFiller <MyData, Bnd_B2f> aTreeFiller(aTree);
+for(;;) {
+ const MyData& aData = …;
+ const Bnd_B2d& aBox = aData.GetBox();
+ aTreeFiller.Add(aData, aBox);
+}
+aTreeFiller.Fill();
+. . .
+// Perform selection based on ‘aPoint2d’
+MyTreeSelector aSel(aPoint2d);
+aTree.Select(aSel);
+const ListOfSelected = aSel.ListAccepted();
+~~~~~
+
+
+Type SparseArray
+----------------
+
+This type has almost the same features as Vector but it allows to store items having scattered indices. In Vector, if you set an item with index 1000000, the container will allocate memory for all items with indices in the range 0-1000000. In SparseArray, only one small block of items will be reserved that contains the item with index 1000000.
+
+This class can be also seen as equivalence of DataMap<int,TheItemType> with the only one practical difference: it can be much less memory-expensive if items are small (e.g. Integer or Handle).
+
+This type has both interfaces of DataMap and Vector to access items.
+
+Type CellFilter
+---------------
+
+This class represents a data structure for sorting geometric objects in n-dimensional space into cells, with associated algorithm for fast checking of coincidence (overlapping, intersection, etc.) with other objects. It can be considered as a functional alternative to UBTree, as in the best case it provides the direct access to an object like in an n-dimensional array, while search with UBTree provides logarithmic law access time.
+
+@subsubsection occt_fcug_3_3_5 Features
+
+NCollection defines some specific features, in addition to the public API inherited from TCollection classes.
+
+Iterators
+---------
+Every collection defines its Iterator class capable of iterating the members in some predefined order. Every Iterator is defined as a subtype of the particular collection type (e.g., MyPackage_StackOfPnt::Iterator ). The order of iteration is defined by a particular collection type. The methods of Iterator are:
+
+* _void Init (const MyCollection&)_ - initializes the iterator on the collection object;
+* _Standard_Boolean More () const_ - makes a query if there is another non-iterated member;
+* _void Next ()_ - increments the iterator;
+* _const ItemType& Value () const_ - returns the current member;
+* _ItemType& ChangeValue () const_ - returns the mutable current member
+
+~~~~~
+typedef Ncollection_Sequence<gp_Pnt>
+MyPackage_SequenceOfPnt
+void Perform (const MyPackage_SequenceOfPnt& theSequence)
+{
+ MyPackage_SequenceOfPnt::Iterator anIter (theSequence);
+ for (; anIter.More(); anIter.Next()) {
+ const gp_Pnt aPnt& = anIter.Value();
+....
+ }
+}
+This feature is present only for some classes in TCollection (Stack, List, Set, Map, DataMap, DoubleMap). In NCollection it is generalized.
+
+
+Class BaseCollection
+--------------------
+
+There is a common abstract base class for all collections for a given item type (e.g., gp_Pnt). Developer X can arbitrarily name this base class like MyPackage_BaseCollPnt in the examples above. This name is further used in the declarations of any (non-abstract) collection class to designate the C++ inheritance.
+
+This base class has the following public API:
+* abstract class Iterator as the base class for all Iterators descried above;
+* _Iterator& CreateIterator () const_ - creates and returns the Iterator on this collection;
+* _Standard_Integer Size () const_ - returns the number of items in this collection;
+* void Assign (const NCollection_BaseCollection& theOther) - copies the contents of the Other to this collection object;
+
+These members enable accessing any collection without knowing its exact type. In particular, it makes possible to implement methods receiving objects of the abstract collection type:
+
+~~~~~
+#include <NColection_Map.hxx>
+typedef NCollection_Map<gp_Pnt> MyPackage_MapOfPnt;
+typedef NCollection_BaseCollection<gp_Pnt> MyPackage_BaseCollPnt;
+MyPackage_MapOfPnt aMapPnt;
+....
+gp_Pnt aResult = COG (aMapPnt);
+....
+gp_Pnt COG(const MyPackage_BaseCollPnt& theColl)
+{
+ gp_XYZ aCentreOfGravity(0., 0., 0.);
+// create type-independent iterator (it is abstract type instance)
+ MyPackage_BaseCollString::Iterator& anIter = theColl.CreateIterator();
+ for (; anIter.More(); anIter.Next()) {
+ aCentreOfGravity += anIter.Value().XYZ();
+ }
+ return aCentreOfGravity / theColl.Size();
+}
+~~~~~
+
+Note that there are fundamental differences between the shown type-independent iterator and the iterator belonging to a particular non-abstract collection:
+* Type-independent iterator can only be obtained via the call CreateIterator(); the typed iterator - only via the explicit construction.
+* Type-independent iterator is an abstract class, so it is impossible to copy it or to assign it to another collection object; the typed iterators can be copied and reassigned using the method Init() .
+* Type-independent iterator is actually destroyed when its collection object is destroyed; the typed iterator is destroyed as any other C++ object in the corresponding C++ scope.
+
+The common point between them is that it is possible to create any number of both types of iterators on the same collection object.
+
+Heterogeneous Assign
+--------------------
+
+The semantics of the method Assign() has been changed in comparison to TCollection. In NCollection classes the method Assign() is virtual and it receives the object of the abstract BaseCollection class (see the previous section). Therefore this method can be used to assign any collection type to any other if only these collections are instantiated on the same ItemType.
+
+For example, conversion of Map into Array1 is performed like this:
+
+~~~~~
+#include <NCollection_Map.hxx>
+#include <NCollection_Array1.hxx>
+typedef NCollection_Map<gp_Pnt> MyPackage_MapOfPnt;
+typedef NCollection_Array1<gp_Pnt> MyPackage_Array1OfPnt;
+....
+MyPackage_MapOfPnt aMapPnt;
+....
+MyPackage_Array1OfPnt anArr1Pnt (1, aMapPnt.Size());
+anArr1Pnt.Assign (aMapPnt); // heterogeneous assignment
+~~~~~
+
+There are some aspects to mention:
+* Unlike in TCollection, in NCollection the methods Assign and operator= do not coincide. The former is a virtual method defined in the BaseCollection class. The latter is always defined in instance classes as a non-virtual inline method and it corresponds exactly to the method Assign in TCollection classes. Therefore it is always profitable to use operator= instead of Assign wherever the types on both sides of assignment are known.
+* If the method Assign copies to Array1or Array2 structure, it first checks if the size of the array is equal to the number of items in the copied collection object. If the sizes differ, an exception is thrown, as in TCollection_Array1.gxx.
+* Copying to Map, IndexedMap, DataMap and IndexedDataMap can bring about a loss of data: when two or more copied data items have the same key value, only one item is copied and the others are discarded. It can lead to an error in the code like the following:
+
+~~~~~
+MyPackage_Array1OfPnt anArr1Pnt (1, 100);
+MyPackage_MapOfPnt aMapPnt;
+....
+aMapPnt.Assign(anArr1Pnt);
+anArr1Pnt.Assign(aMapPnt);
+~~~~~
+
+Objects of classes parameterised with two types (DoubleMap, DataMap and IndexedDataMap) cannot be assigned. Their method Assign throws the exception Standard_TypeMismatch (because it is impossible to check if the passed BaseCollection parameter belongs to the same collection type).
+
+Allocator
+---------
+
+All constructors of NCollection classes receive the Allocator Object as the last parameter. This is an object of a type managed by Handle, inheriting NCollection_BaseAllocator, with the following (mandatory) methods redefined:
+
+~~~~~
+Standard_EXPORT virtual void* Allocate (const size_t size);
+Standard_EXPORT virtual void Free (void * anAddress);
+~~~~~
+
+It is used internally every time when the collection allocates memory for its item(s) and releases this memory. The default value of this parameter (empty Handle) designates the use of NCollection_BaseAllocator X where the functions Standard::Allocate and Standard::Free are called. Therefore if the user of NCollection does not specify any allocator as a parameter to the constructor of his collection, the memory management will be identical to the one in TCollection and other Open CASCADE Technology classes.
+
+Nevertheless, the it is possible to define a custom Allocator type to manage the memory in the most optimal or convenient way for his algorithms.
+
+As one possible choice, the class NCollection_IncAllocator is included. Unlike BaseAllocator, it owns all memory it allocates from the system. Memory is allocated in big blocks (about 20kB) and the allocator keeps track of the amount of occupied memory. The method Allocate just increments the pointer to non-occupied memory and returns its previous value. Memory is only released in the destructor of IncAllocator, the method Free is empty. If used efficiently, this Allocator can greatly improve the performance of OCCT collections.
+
+
+
+@subsection occt_fcug_3_4 Strings
+
+The **Strings **component provides services to manipulate character strings.
+**Strings** are classes that handle dynamically sized sequences of characters based on both ASCII (normal 8-bit character type) and Unicode (16-bit character type). They provide editing operations with built-in memory management which make the relative objects easier to use than ordinary character arrays.
+*Strings *may also be manipulated by *handle*, and therefore shared.
+
+@subsubsection occt_fcug_3_4_1 Examples
+TCollection_AsciiString
+-----------------------
+A variable-length sequence of ASCII characters (normal 8-bit character type). It provides editing operations with built-in memory management to make **AsciiString **objects easier to use than ordinary character arrays.
+**AsciiString **objects follow ;value semantics;, that is, they are the actual strings, not handles to strings, and are copied through assignment. You may use **HAsciiString **objects to get handles to strings.
+TCollection_ExtendedString
+--------------------------
+A variable-length sequence of ;extended; (UNICODE) characters (16-bit character type). It provides editing operations with built-in memory management to make **ExtendedString **objects easier to use than ordinary extended character arrays.
+**ExtendedString **objects follow ;value semantics;, that is, they are the actual strings, not handles to strings, and are copied through assignment. You may use **HExtendedString **objects to get handles to strings.
+TCollection_HAsciiString
+------------------------
+A variable-length sequence of ASCII characters (normal 8-bit character type). It provides editing operations with built-in memory management to make **HAsciiString **objects easier to use than ordinary character arrays.
+**HAsciiString **objects are *handles *to strings.
+ * **HAsciiString **strings may be shared by several objects.
+ * You may use an **AsciiString **object to get the actual string.
+**HAsciiString **objects use an **AsciiString **string as a field.
+
+TCollection_HExtendedString
+---------------------------
+A variable-length sequence of ;extended; (UNICODE) characters (16-bit character type). It provides editing operations with built-in memory management to make **ExtendedString **objects easier to use than ordinary extended character arrays.
+**HExtendedString **objects are *handles *to strings.
+ * **HExtendedString **strings may be shared by several objects.
+ * You may use an **ExtendedString **object to get the actual string.
+**HExtendedString **objects use an **ExtendedString **string as a field.
+
+@subsubsection occt_fcug_3_4_2 Conversion
+Resource_Unicode
+----------------
+Functions used to convert a non-ASCII *C string *given in ANSI, EUC, GB or SJIS
+format, to a Unicode string of extended characters, and vice versa.
+
+@subsection occt_fcug_3_5 Unit Conversion
+
+The **UnitsAPI **global functions are used to convert a value from any unit into another unit. Conversion is executed among three unit systems:
+ * the **SI System**,
+ * the user’s **Local System**,
+ * the user’s **Current System**.
+The **SI System **is the standard international unit system. It is indicated by *SI *in the signatures of the **UnitsAPI **functions.
+The OCCT (former MDTV) System corresponds to the SI international standard but *the length unit and all its derivatives use the millimeter *instead of the meter.
+Both systems are proposed by Open CASCADE Technology; the SI System is the standard option. By selecting one of these two systems, you define your **Local System **through the **SetLocalSystem **function. The **Local System **is indicated by *LS *in the signatures of the **UnitsAPI **functions.
+The Local System units can be modified in the working environment. You define your **Current System **by modifying its units through the **SetCurrentUnit **function. The Current System is indicated by *Current *in the signatures of the **UnitsAPI **functions.
+A physical quantity is defined by a string (example: LENGTH).
+
+
+@section occt_occt_fcug_4 Math Primitives and Algorithms
+@subsection occt_occt_fcug_4_1 Overview
+Math primitives and algorithms available in Open CASCADE Technology include:
+ * Vectors and matrices
+ * Geometric primitives
+ * Math algorithms
+@subsection occt_occt_fcug_4_2 Vectors and Matrices
+The Vectors and Matrices component provides a C++ implementation of the fundamental types Matrix and Vector, currently used to define more complex data structures. The Vector and Matrix classes support vectors and matrices of real values with standard operations such as addition, multiplication, transposition, inversion etc.
+Vectors and matrices have arbitrary ranges which must be defined at declaration time and cannot be changed after declaration.
+
+~~~~~
+math_Vector v(1, 3);
+// a vector of dimension 3 with range (1..3)
+math_Matrix m(0, 2, 0, 2);
+// a matrix of dimension 3x3 with range (0..2, 0..2)
+math_Vector v(N1, N2);
+// a vector of dimension N2-N1+1 with range (N1..N2)
+~~~~~
+
+Vector and Matrix objects use value semantics. In other words, they cannot be shared and are copied through assignment.
+
+~~~~~
+math_Vector v1(1, 3), v2(0, 2);
+v2 = v1;
+// v1 is copied into v2. a modification of v1 does not affect v2
+~~~~~
+
+Vector and Matrix values may be initialized and obtained using indexes which must lie within the range definition of the vector or the matrix.
+
+~~~~~
+math_Vector v(1, 3);
+math_Matrix m(1, 3, 1, 3);
+Standard_Real value;
+
+v(2) = 1.0;
+value = v(1);
+m(1, 3) = 1.0;
+value = m(2, 2);
+~~~~~
+
+Some operations on Vector and Matrix objects may not be legal. In this case an exception is raised. Two standard exceptions are used:
+ * Standard_DimensionError exception is raised when two matrices or vectors involved in an operation are of incompatible dimensions.
+ * Standard_RangeError exception is raised if an access outside the range definition of a vector or of a matrix is attempted.
+
+~~~~~~
+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
+~~~~~~
+
+@subsection occt_occt_fcug_4_3 Primitive Geometric Types
+@subsubsection occt_occt_fcug_4_3_1 Overview
+Before creating a geometric object, you must decide whether you are in a 2d or in a 3d context and how you want to handle the object.
+The *gp *package offers classes for both 2d and 3d objects which are handled by value rather than by reference. When this sort of object is copied, it is copied entirely. Changes in one instance will not be reflected in another.
+@subsubsection occt_occt_fcug_4_3_2 gp
+The *gp *package defines the basic non-persistent geometric entities used for algebraic calculation and basic analytical geometry in 2d & 3d space. It also provides basic transformations such as identity, rotation, translation, mirroring, scale transformations, combinations of transformations, etc. Entities are handled by value.
+The available geometric entities are:
+ * 2d & 3d Cartesian coordinates (x, y, z)
+ * Matrices
+ * Cartesian points
+ * Vector
+ * Direction
+ * Axis
+ * Line
+ * Circle
+ * Ellipse
+ * Hyperbola
+ * Parabola
+ * Plane
+ * Infinite cylindrical surface
+ * Spherical surface
+ * Toroidal surface
+ * Conical surface.
+
+@subsection occt_occt_fcug_4_4 Collections of Primitive Geometric Types
+Before creating a geometric object, you must decide whether you are in a 2d or in a 3d context and how you want to handle the object.
+If you do not need a single instance of a geometric primitive but a set of them then the package which deals with collections of this sort of object, *TColgp*, will provide the necessary functionality.
+In particular, this package provides standard and frequently used instantiations of generic classes with geometric objects.
+@subsubsection occt_occt_fcug_4_4_1 TColgp
+The *TColgp *package provides instantiations of the TCollection classes with the classes from *gp *i.e. *XY*, *XYZ*, *Pnt*, *Pnt2d*, *Vec*, *Vec2d*, *Lin*, *Lin2d*, *Circ*, *Circ2d.*
+These are non-persistent classes.
+@subsection occt_occt_fcug_4_5 Basic Geometric Libraries
+There are various library packages available which offer a range of basic computations on curves and surfaces.
+If you are dealing with objects created from the *gp *package, the useful algorithms are in the elementary curves and surfaces libraries - the *ElCLib *and *ElSLib *packages.
+The *Precision *package describes functions for defining the precision criterion used to compare two numbers.
+@subsubsection occt_occt_fcug_4_5_1 EICLib
+Methods for analytic curves. A library of simple computations on curves from the *gp *package (Lines, Circles and Conics). Computes points with a given parameter. Computes the parameter for a point.
+@subsubsection occt_occt_fcug_4_5_2 EISLib
+Methods for analytic surfaces . A library of simple computations on surfaces from the package *gp *(Planes, Cylinders, Spheres, Cones, Tori). Computes points with a given pair of parameters. Computes the parameter for a point. There is a library for calculating normals on curves and surfaces.
+@subsubsection occt_occt_fcug_4_5_3 Bnd
+Package Bnd provides a set of classes and tools to operate with bounding boxes of geometric objects in 2d and 3d space.
+@subsection occt_occt_fcug_4_6 Common Math Algorithms
+The common math algorithms library provides a C++ implementation of the most frequently used mathematical algorithms. These include:
+ * Algorithms to solve a set of linear algebraic equations,
+ * Algorithms to find the minimum of a function of one or more independent variables,
+ * Algorithms to find roots of one, or of a set, of non-linear equations,
+ * An algorithm to find the eigenvalues and eigenvectors of a square matrix.
+@subsubsection occt_occt_fcug_4_6_1 Implementation of Algorithms
+All mathematical algorithms are implemented using the same principles. They contain:
+A constructor performing all, or most of, the calculation, given the appropriate arguments. All relevant information is stored inside the resulting object, so that all subsequent calculations or interrogations will be solved in the most efficient way.
+A function IsDone returning the boolean true if the calculation was successful.
+A set of functions, specific to each algorithm, enabling all the various results to be obtained.
+Calling these functions is legal only if the function IsDone answers true, otherwise the exception StdFail_NotDone is raised.
+The example below demonstrates the use of the Gauss class, which implements the Gauss solution for a set of linear equations.The following definition is an extract from the header file of the class math_Gauss:
+
+~~~~~~
+class Gauss {
+public:
+ Gauss (const math_Matrix& A);
+ Standard_Boolean IsDone() const;
+ void Solve (const math_Vector& B,
+ math_Vector& X) const;
+};
+~~~~~~
+
+Now the main program uses the Gauss class to solve the equations a*x1=b1 and a*x2=b2:
+
+~~~~~
+#include <math_Vector.hxx>
+#include <math_Matrix.hxx>
+main ()
+{
+ math_Vector a(1, 3, 1, 3);
+ math_Vector b1(1, 3), b2(1, 3);
+ math_Vector x1(1, 3), x2(1, 3);
+ // a, b1 and b2 are set here to the appropriate values
+ math_Gauss sol(a); // computation of the
+ // LU decomposition of A
+ if(sol.IsDone()) { // is it OK ?
+ sol.Solve(b1, x1); // yes, so compute x1
+ sol.Solve(b2, x2); // then x2
+ ...
+ }
+ else { // it is not OK:
+ // fix up
+ sol.Solve(b1, x1); // error:
+ // StdFail_NotDone is raised
+ }
+}
+~~~~~
+
+The next example demonstrates the use of the BissecNewton class, which implements a combination of the Newton and Bissection algorithms to find the root of a function known to lie between two bounds.The definition is an extract from the header file of the class math_BissecNewton:
+
+~~~~~
+class BissecNewton {
+ public:
+ BissecNewton (math_FunctionWithDerivative& f,
+ const Standard_Real bound1,
+ const Standard_Real bound2,
+ const Standard_Real tolx);
+ Standard_Boolean IsDone() const;
+ Standard_Real Root();
+};
+~~~~~
+
+The abstract class math_FunctionWithDerivative describes the services which have to be implemented for the function f which is to be used by a BissecNewton algorithm. The following definition corresponds to the header file of the abstract class math_FunctionWithDerivative:
+
+~~~~~
+class math_FunctionWithDerivative {
+ public:
+ virtual Standard_Boolean Value
+ (const Standard_Real x, Standard_Real& f) = 0;
+ virtual Standard_Boolean Derivative
+ (const Standard_Real x, Standard_Real& d) = 0;
+ virtual Standard_Boolean Values
+ (const Standard_Real x,
+ Standard_Real& f,
+ Standard_Real& d) = 0;
+};
+~~~~~
+
+Now the test sample uses the BissecNewton class to find the root of the equation f(x)=x**2-4 in the interval [1.5, 2.5]:the function to solve is implemented in the class myFunction which inherits from the class math_FunctionWithDerivative,then the main program finds the required root.
+
+~~~~~
+#include <math_BissecNewton.hxx>
+#include <math_FunctionWithDerivative.hxx>
+class myFunction : public math_FunctionWithDerivative
+{
+ Standard_Real coefa, coefb, coefc;
+
+ public:
+ myFunction (const Standard_Real a, const Standard_Real b,
+ const Standard_Real c) :
+ coefa(a), coefb(b), coefc(c)
+ {}
+
+ virtual Standard_Boolean Value (const Standard_Real x,
+ Standard_Real& f)
+ {
+ f = coefa * x * x + coefb * x + coefc;
+ }
+
+ virtual Standard_Boolean Derivative (const Standard_Real x,
+ Standard_Real& d)
+ {
+ d = coefa * x * 2.0 + coefb;
+ }
+
+ virtual Standard_Boolean Values (const Standard_Real x,
+ Standard_Real& f, Standard_Real& d)
+ {
+ f = coefa * x * x + coefb * x + coefc;
+ d = coefa * x * 2.0 + coefb;
+ }
+};
+
+main()
+{
+ myFunction f(1.0, 0.0, 4.0);
+ math_BissecNewton sol(F, 1.5, 2.5, 0.000001);
+ if(Sol.IsDone()) { // is it OK ?
+ Standard_Real x = sol.Root(); // yes.
+ }
+ else { // no
+ }
+~~~~~
+
+@subsection occt_occt_fcug_4_7 Precision
+
+On the OCCT platform, each object stored in the database should carry its own precision value. This is important when dealing with systems where objects are imported from other systems as well as with various associated precision values.
+The *Precision *package addresses the daily problem of the geometric algorithm developer: what precision setting to use to compare two numbers. Real number equivalence is clearly a poor choice. The difference between the numbers should be compared to a given precision setting.
+Do not write _if (X1 == X2),_ instead write _if (Abs(X1-X2) < Precision)._
+Also, to order real numbers, keep in mind that _if (X1 < X2 - Precision)_ is incorrect.
+_if (X2 - X1 > Precision)_ is far better when *X1 *and *X2 *are high numbers.
+This package proposes a set of methods providing precision settings for the most commonly encountered situations.
+In Open CASCADE Technology, precision is usually not implicit; low-level geometric algorithms accept precision settings as arguments. Usually these should not refer directly to this package.
+High-level modeling algorithms have to provide a precision setting to the low level geometric algorithms they call. One way is to use the settings provided by this package. The high-level modeling algorithms can also have their own strategy for managing precision. As an example the Topology Data Structure stores precision values which are later used by algorithms. When a new topology is created, it takes the stored value.
+Different precision settings offered by this package cover the most common needs of geometric algorithms such as *Intersection *and *Approximation*.
+The choice of a precision value depends both on the algorithm and on the geometric space. The geometric space may be either:
+ * a ;real; space, 3d or 2d where the lengths are measured in meters, micron, inches, etc.
+ * a ;parametric; space, 1d on a curve or 2d on a surface where numbers have no dimension.
+The choice of precision value for parametric space depends not only on the accuracy of the machine, but also on the dimensions of the curve or the surface.
+This is because it is desirable to link parametric precision and real precision. If you are on a curve defined by the equation *P(t)*, you would want to have equivalence between the following:
+
+~~~~~
+Abs(t1-t2) < ParametricPrecision
+Distance (P(t1),P(t2)) < RealPrecision.
+~~~~~
+
+@subsubsection occt_occt_fcug_4_7_1 The Precision package
+The Precision package offers a number of package methods and default precisions for use in dealing with angles, distances, intersections, approximations, and parametric space.
+It provides values to use in comparisons to test for real number equalities.
+ * Angular precision compares angles.
+ * Confusion precision compares distances.
+ * Intersection precision is used by intersection algorithms.
+ * Approximation precision is used by approximation algorithms.
+ * Parametric precision gets a parametric space precision from a 3D precision.
+ * *Infinite *returns a high number that can be considered to be infinite. Use *-Infinite *for a high negative number.
+
+@subsubsection occt_occt_fcug_4_7_2 Standard Precision values
+This package provides a set of real space precision values for algorithms. The real space precisions are designed for precision to *0.1* nanometers. The only unit available is the millimeter.
+The parametric precisions are derived from the real precisions by the *Parametric *function. This applies a scaling factor which is the length of a tangent to the curve or the surface. You, the user, provide this length. There is a default value for a curve with *[0,1] *parameter space and a length less than 100 meters.
+The geometric packages provide Parametric precisions for the different types of curves.
+The Precision package provides methods to test whether a real number can be considered to be infinite.
+
+Precision::Angular
+------------------
+This method is used to compare two angles. Its current value is *Epsilon(2 * PI) *i.e. the smallest number *x *such that *2*PI + x *is different of *2* PI*.
+
+It can be used to check confusion of two angles as follows:
+_Abs(Angle1 - Angle2) < Precision::Angular()_
+
+It is also possible to check parallelism of two vectors (_Vec_ from _gp_) as follows _V1.IsParallel(V2,Precision::Angular())_
+
+Note that *Precision::Angular()* can be used on both dot and cross products because for small angles the *Sine* and the *Angle* are equivalent. So to test if two directions of type *gp*_*Dir* are perpendicular, it is legal to use the following code:
+_Abs(D1 * D2) < Precision::Angular()_
+
+Precision::Confusion
+--------------------
+This method is used to test 3D distances. The current value is *1.e-7*, in other words, 1/10 micron if the unit used is the millimeter.
+
+It can be used to check confusion of two points (_Pnt_ from _gp_) as follows:
+_P1.IsEqual(P2,Precision::Confusion())_
+
+It is also possible to find a vector of null length (_Vec_ from _gp_) :
+_V.Magnitude() < Precision::Confusion()_
+
+Precision::Intersection
+-----------------------
+This is reasonable precision to pass to an Intersection process as a limit of refinement of Intersection Points. *Intersection* is high enough for the process to converge quickly. *Intersection* is lower than *Confusion* so that you still get a point on the intersected geometries. The current value is *Confusion() / 100*.
+
+Precision::Approximation
+------------------------
+This is a reasonable precision to pass to an approximation process as a limit of refinement of fitting. The approximation is greater than the other precisions because it is designed to be used when the time is at a premium. It has been provided as a reasonable compromise by the designers of the Approximation algorithm. The current value is *Confusion() * 10*.
+Note that Approximation is greater than Confusion, so care must be taken when using Confusion in an approximation process.
+
+@section occt_fcug_5 Data Storage
+@subsection occt_fcug_5_1 Saving and Opening Files
+
+
+
+In the example, the roots of the transferable transient objects *TopoDS_Shape, Geom_Geometry* and *Geom2d_Geometry* are used in algorithms, they contain data and temporary results.
+The associated objects in the persistent domain are here PTopoDS_HShape, PGeom_Geometry and PGeom2d_Geometry. They contain a real data structure which is stored in a file.
+Note that when an object is stored, if it contains another stored object, the references to the contained object are also managed.
+
+
+
+@subsection occt_fcug_5_2 Basic Storage Procedures
+That is how the storage and retrieval mechanisms work on shapes.
+
+@subsubsection occt_fcug_5_2_1 Saving
+
+The storage procedure of a transient object follows five main steps.
+1. Create an I/O driver for files. For example, *FSD_File f()*;
+2. Instance the data schema, which will process your persistent information. The schema is used for read/write operations. If ShapeSchema is the name of your schema:
+~~~~~
+Handle(ShapeSchema) s = new ShapeSchema;
+~~~~~
+
+3.Create a persistent shape from a transient shape.
+~~~~~
+TopoDS_Shape aShape;
+PTColStd_TransientPersistentMap aMap;
+Handle(PTopoDS_HShape) aPShape = MgtBRep::Translate
+ (aShape, aMap, MgtBRep_WithoutTriangle);
+~~~~~
+
+4.Create a new container and fill it using the *AddRoot()* method.
+~~~~~
+Handle(Storage_Data) d = new Storage_Data;
+d -> AddRoot (“ObjectName”, aPShape);
+~~~~~
+You may add as many objects as you want in this container.
+
+5. Save to the archive.
+~~~~~
+s -> Write (f,d);
+~~~~~
+
+@subsubsection occt_fcug_5_2_2 Opening
+The retrieval mechanism is the opposite of the storage mechanism. The procedure for retrieving an object is as follows:
+
+1. Create an I/O driver and instance a data schema (if not done).
+2. Read the persistent object from the archive and get the list of objects using Roots() method.
+~~~~~
+Handle(Storage_Data) d = s -> Read(f);
+Handle(Storage_HSeqOfRoot) roots = d-> Roots();
+~~~~~
+3. Loop on root objects to get Standard_Persistent objects (the following sequence only gets the first root).
+~~~~~
+Handle(Standard_Persistent) p;
+Handle(Standard_Root) r;
+if(roots -> Length() >= 1) {
+ r = roots -> Value(1);
+ p = r -> Object();
+}
+~~~~~
+4. DownCast the persistent object to a PTopoDS_Hshape.
+~~~~~
+Handle(PTopoDS_HShape) aPShape;
+aPShape = Handle(PTopoDS_HShape)::DownCast(p);
+~~~~~
+5. Create the TopoDS_Shape.
+~~~~~
+TopoDS_Shape aShape;
+PTColStd_PersistentTransientMap aMap;
+MgtBRep::Translate (aPShape, aMap, aShape, MgtBRep_WithoutTriangle);
+~~~~~
+
+
+
--- /dev/null
+IGES Support {#user_guides__iges}
+==================
+
+@section occt_1856844696_591811643 Introduction
+
+@subsection occt_1856844696_591811643_1 The IGES-Open CASCADE Technology processor
+This manual explains how to convert an IGES file to an Open CASCADE Technology (**OCCT**) shape and vice versa. It provides basic documentation on conversion. For advanced information on conversion, see our offerings on our web site at <a href="http://www.opencascade.org/support/training/">www.opencascade.org/support/training/</a>
+
+IGES files up to and including IGES version 5.3 can be read. IGES files that are produced by this interface conform to IGES version 5.3 (Initial Graphics Exchange Specification, IGES 5.3. ANS US PRO/IPO-100-1996).
+This manual principally deals with two OCCT classes:
+ * The Reader class, which loads IGES files and translates their contents to OCCT shapes,
+ * The Writer class, which translates OCCT shapes to IGES entities and then writes these entities to IGES files.
+File translation is performed in the programming mode, via C++ calls, and the resulting OCCT objects are shapes.
+All definitions in IGES version 5.3 are recognized but only 3D geometric entities are translated. When the processor encounters data, which is not translated, it ignores it and writes a message identifying the types of data, which was not handled. This message can be written either to a log file or to screen output.
+@section occt_1856844696_804874798 Reading IGES
+@subsection occt_1856844696_804874798_1 Procedure
+You can translate an IGES file to an OCCT shape by following the steps below:
+ -# Load the file,
+ -# Check file consistency,
+ -# Set the translation parameters,
+ -# Perform the file translation,
+ -# Fetch the results.
+@subsection occt_1856844696_804874798_2 Domain covered
+@subsubsection occt_1856844696_804874798_21 Translatable entities
+The types of IGES entities, which can be translated, are:
+ * Points
+ * Lines
+ * Curves
+ * Surfaces
+ * B-Rep entities
+ * Structure entities (groups). Each entity in the group outputs a shape. There can be a group of groups.
+ * Subfigures. Each entity defined in a subfigure outputs a shape
+ * Transformation Matrix.
+***NOTE***
+*All non-millimeter length unit values in the IGES file are converted to millimeters.*
+@subsubsection occt_1856844696_804874798_22 Attributes
+Entity attributes in the Directory Entry Section of the IGES file (such as layers, colors and thickness) are translated to Open CASCADE Technology using XDE.
+@subsubsection occt_1856844696_804874798_23 Administrative data
+Administrative data, in the Global Section of the IGES file (such as the file name, the name of the author, the date and time a model was created or last modified) is not translated to Open CASCADE Technology. Administrative data can, however, be consulted in the IGES file.
+
+
+@subsection occt_1856844696_804874798_3 Description of the process
+@subsubsection occt_1856844696_804874798_31 Loading the IGES file
+Before performing any other operation, you have to load the file using the syntax below.
+IGESControl_Reader reader;
+IFSelect_ReturnStatus stat = reader.ReadFile(“filename.igs”);
+The loading operation only loads the IGES file into computer memory; it does not translate it.
+@subsubsection occt_1856844696_804874798_32 Checking the IGES file
+This step is not obligatory. Check the loaded file with:
+Standard_Boolean ok = reader.Check(Standard_True);
+The variable “ok is True” is returned if no fail message was found; “ok is False” is returned if there was at least one fail message.
+reader.PrintCheckLoad (failsonly, mode);
+Error messages are displayed if there are invalid or incomplete IGES entities, giving you information on the cause of the error.
+Standard_Boolean failsonly = Standard_True or Standard_False;
+If you give True, you will see fail messages only. If you give False, you will see both fail and warning messages.
+Your analysis of the file can be either message-oriented or entity-oriented. Choose your preference with:
+IFSelect_PrintCount mode = IFSelect_xxx
+Where xxx can be any of the following:
+ItemsByEntity gives a sequential list of all messages per IGES entity.
+CountByItem gives the number of IGES entities with their types per message.
+ShortByItem gives the number of IGES entities with their types per message and displays rank numbers of the first five IGES entities per message.
+ListByItem gives the number of IGES entities with their type and rank numbers per message.
+EntitiesByItem gives the number of IGES entities with their types, rank numbers and Directory Entry numbers per message.
+
+@subsubsection occt_1856844696_804874798_33 Setting translation parameters
+The following parameters can be used to translate an IGES file to an OCCT shape. If you give a value that is not within the range of possible values, it will be ignored.
+<h4>read.iges.bspline.continuity</h4>
+manages the continuity of BSpline curves (IGES entities 106, 112 and 126) after translation to Open CASCADE Technology (Open CASCADE Technology requires that the curves in a model be at least C1 continuous; no such requirement is made by IGES).
+0: no change; the curves are taken as they are in the IGES file. C0 entities of Open CASCADE Technology may be produced.
+1: if an IGES BSpline, Spline or CopiousData curve is C0 continuous, it is broken down into pieces of C1 continuous Geom_BSplineCurve.
+2: This option concerns IGES Spline curves only. IGES Spline curves are broken down into pieces of C2 continuity. If C2 cannot be ensured, the Spline curves will be broken down into pieces of C1 continuity.
+Read this parameter with:
+Standard_Integer ic = Interface_Static::IVal(;read.iges.bspline.continuity;);
+Modify this value with:
+if (!Interface_Static::SetIVal (;read.iges.bspline.continuity;,2))
+.. error ..;
+Default value is 1.
+*This parameter does not change the continuity of curves that are used in the construction of IGES BRep entities. In this case, the parameter does not influence the continuity of the resulting OCCT curves (it is ignored). *
+<h4>read.precision.mode</h4>
+reads the precision value.
+ ;File; (0) the precision value is read in the IGES file header (default).
+ ;User; (1) the precision value is that of the read.precision.val parameter.
+Read this parameter with:
+Standard_Integer ic = Interface_Static::IVal(;read.precision.mode;);
+Modify this value with:
+if (!Interface_Static::SetIVal (;read.precision.mode;,1))
+.. error ..;
+Default value is ;File; (0).
+<h4>read.precision.val</h4>
+user precision value. This parameter gives the precision used during translation when the read.precision.mode parameter value is 1.
+ 0.0001: default.
+ any real positive (non null) value.
+This value is a basis value for computation tolerances for TopoDS_Vertex, TopoDS_Edge and TopoDS_Face entities.
+This value is in the measurement unit defined in the IGES file header.
+Read this parameter with:
+Standard_Real rp = Interface_Static::RVal(;read.precision.val;);
+Modify this parameter with:
+if (!Interface_Static::SetRVal (;read.precision.val;,0.001))
+.. error ..;
+Default value is 0.0001.
+*The value given to this parameter is a target value that is applied to TopoDS_Vertex, TopoDS_Edge and TopoDS_Face entities. The processor does its best to reach it. Under certain circumstances, the value you give may not be attached to all of the entities concerned at the end of processing. IGES-to-OCCT translation does not improve the quality of the geometry in the original IGES file. This means that the value you enter may be impossible to attain the given quality of geometry in the IGES file.*
+Value of tolerance used for computation is calculated by multiplying the value of read.precision.val and the value of coefficient of transfer from the file units to millimeters.
+<h4>read.maxprecision.mode</h4>
+defines the mode of applying the maximum allowed tolerance. Its possible values are:
+;Preferred;(0) maximum tolerance is used as a limit but sometimes it can be exceeded (currently, only for deviation of a 3D curve of an edge from its pcurves and from vertices of such edge) to ensure shape validity
+;Forced;(1) maximum tolerance is used as a rigid limit, i.e. it can not be exceeded and, if this happens, tolerance is trimmed to suit the maximum-allowable value.
+Read this parameter with:
+Standard_Integer mv = Interface_Static::IVal(;read.maxprecision.mode;);
+Modify this parameter with:
+if (!Interface_Static::SetIVal (;read.maxprecision.mode;,1))
+.. error ..;
+Default value is ;Preferred; (0).
+
+<h4>read.maxprecision.val</h4>
+defines the maximum allowable tolerance (in mm) of the shape. It should be not less than the basis value of tolerance set in processor (either Resolution from the file or read.precision.val). Actually, the maximum between read.maxprecision.val and basis tolerance is used to define maximum allowed tolerance.
+Read this parameter with:
+Standard_Real rp = Interface_Static::RVal(;read.maxprecision.val;);
+Modify this parameter with:
+if (!Interface_Static::SetRVal (;read.maxprecision.val;,0.1))
+.. error ..;
+Default value is 1.
+
+<h4>read.stdsameparameter.mode</h4>
+defines the using of BRepLib::SameParameter. Its possible values are:
+0 (;Off;) - BRepLib::SameParameter is not called,
+1 (;On;) - BRepLib::SameParameter is called.
+Functionality of BRepLib::SameParameter is used through ShapeFix_Edge::SameParameter. It ensures that the resulting edge will have the lowest tolerance taking pcurves either unmodified from the IGES file or modified by BRepLib::SameParameter.
+Read this parameter with:
+Standard_Integer mv = Interface_Static::IVal(;read.stdsameparameter.mode;);
+Modify this parameter with:
+if (!Interface_Static::SetIVal (;read.stdsameparameter.mode;,1))
+.. error ..;
+Deafault value is 0 (;Off;).
+
+<h4>read.surfacecurve.mode</h4>
+preference for the computation of curves in case of 2D/3D inconsistency in an entity which has both 2D and 3D representations.
+Here we are talking about entity types 141 (Boundary), 142 (CurveOnSurface) and 508 (Loop). These are entities representing a contour lying on a surface, which is translated to a TopoDS_Wire, formed by TopoDS_Edges. Each TopoDS_Edge must have a 3D curve and a 2D curve that reference the surface.
+The processor also decides to re-compute either the 3D or the 2D curve even if both curves are translated successfully and seem to be correct, in case there is inconsistency between them. The processor considers that there is inconsistency if any of the following conditions is satisfied:
+ * the number of sub-curves in the 2D curve is different from the number of sub-curves in the 3D curve. This can be either due to different numbers of sub-curves given in the IGES file or because of splitting of curves during translation.
+ * 3D or 2D curve is a Circular Arc (entity type 100) starting and ending in the same point (note that this case is incorrect according to the IGES standard)
+The parameter read.surfacecurve.mode defines which curve (3D or 2D) is used for re-computing the other one:
+1. ;Default; (0): use the preference flag value in the entity's Parameter Data section. The flag values are:
+ * 0: no preference given,
+ * 1: use 2D for 142 entities and 3D for 141 entities,
+ * 2: use 3D for 142 entities and 2D for 141 entities,
+ * 3: both representations are equally preferred.
+2. ;2DUse_Preferred; (2): the 2D is used to rebuild the 3D in case of their inconsistency,
+3. ;2DUse_Forced; (-2): the 2D is always used to rebuild the 3D (even if 2D is present in the file),
+4. ;3DUse_Preferred; (3): the 3D is used to rebuild the 2D in case of their inconsistency,
+5. ;3DUse_Forced; (-3): the 3D is always used to rebuild the 2D (even if 2D is present in the file),
+If no preference is defined (if the value of read.surfacecurve.mode is ;Default; and the value of the preference flag in the entity's Parameter Data section is 0 or 3), an additional analysis is performed.
+The 3D representation is preferred to the 2D in two cases:
+ * if 3D and 2D contours in the file have a different number of curves,
+ * if the 2D curve is a Circular Arc (entity type 100) starting and ending in the same point and the 3D one is not.
+In any other case, the 2D representation is preferred to the 3D.
+
+If either a 3D or a 2D contour is absent in the file or cannot be translated, then it is re-computed from another contour. If the translation of both 2D and 3D contours fails, the whole curve (type 141 or 142) is not translated. If this curve is used for trimming a face, the face will be translated without this trimming and will have natural restrictions.
+Read this parameter with:
+Standard_Integer ic = Interface_Static::IVal(;read.surfacecurve.mode;);
+Modify this value with:
+if (!Interface_Static::SetIVal (;read.surfacecurve.mode;,3))
+.. error ..;
+Default value is ;Default; (0).
+<h4>read.encoderegularity.angle</h4>
+This parameter is used within the BRepLib::EncodeRegularity() function which is called for a shape read from an IGES or a STEP file at the end of translation process. This function sets the regularity flag of an edge in a shell when this edge is shared by two faces. This flag shows the continuity, which these two faces are connected with at that edge.
+Read this parameter with:
+Standard_Real era = Interface_Static::RVal(;read.encoderegularity.angle;);
+Modify this parameter with:
+if (!Interface_Static::SetRVal (;read.encoderegularity.angle;,0.1))
+.. error ..;
+Default value is 0.01.
+<h4>read.iges.bspline.approxd1.mode</h4>
+This parameter is obsolete (it is rarely used in real practice). If set to True, it affects the translation of bspline curves of degree 1 from IGES: these curves (which geometrically are polylines) are split by duplicated points, and the translator attempts to convert each of the obtained parts to a bspline of a higher continuity.
+Read this parameter with:
+Standard_Real bam = Interface_Static::CVal(;read.iges.bspline.approxd1.mode;);
+Modify this parameter with:
+if (!Interface_Static::SetRVal (;read.encoderegularity.angle;,;On;))
+.. error ..;
+Default value is Off.
+<h4>read.iges.resource.name</h4>
+<h4>read.iges.sequence</h4>
+These two parameters define the name of the resource file and the name of the sequence of operators (defined in that file) for Shape Processing, which is automatically performed by the IGES translator. The Shape Processing is a user-configurable step, which is performed after the translation and consists in application of a set of operators to a resulting shape. This is a very powerful tool allowing to customize the shape and to adapt it to the needs of a receiving application. By default, the sequence consists of a single operator ShapeFix * that is how Shape Healing is called from the IGES translator.
+Please find an example of the resource file for IGES (which defines parameters corresponding to the sequence applied by default, i.e. if the resource file is not found) in the Open CASCADE Technology installation, by the path %CASROOT%/src/XSTEPResource/IGES ($CASROOT/src/XSTEPResource/IGES).
+In order for the IGES translator to use that file, you have to define the environment variable CSF_IGESDefaults, which should point to the directory where the resource file resides. Note that if you change parameter read.iges.resource.name, you should change the name of the resource file and the name of the environment variable correspondingly. The variable should contain a path to the resource file.
+Default values: read.iges.resource.name - IGES, read.iges.sequence - FromIGES.
+<h4>read.scale.unit</h4>
+This parameter is obsolete (the parameter xstep.cascade.unit should be used instead when necessary). If it is set to 'M', the shape is scaled 0.001 times (as if it were in meters) after translation from IGES or STEP.
+Default value is MM.
+<h4>xstep.cascade.unit</h4>
+This parameter defines units to which a shape should be converted when translated from IGES or STEP to CASCADE. Normally it is MM; only those applications that work internally in units other than MM should use this parameter.
+Default value is MM.
+@subsubsection occt_1856844696_804874798_34 Selecting entities
+A list of entities can be formed by invoking the method IGESControl_Reader::GiveList.
+Handle(TColStd_HSequenceOfTransient) list = reader.GiveList();
+Several predefined operators can be used to select a list of entities of a specific type.
+To make a selection, you use the method IGESControl_Reader::GiveList with the selection type in quotation marks as an argument. You can also make cumulative selections. For example, you would use the following syntax:
+1. Requesting the faces in the file:
+faces = Reader.GiveList(;iges-faces;);
+2. Requesting the visible roots in the file
+visibles = Reader.GiveList(;iges-visible-roots;);
+3. Requesting the visible faces
+visfac = Reader.GiveList(;iges-visible-roots;,faces);
+Using a signature, you can define a selection dynamically, filtering the string by means of a criterion. When you request a selection using the method GiveList, you can give either a predefined selection or a selection by signature. You make your selection by signature using the predefined signature followed by your criterion in parentheses as shown in the example below. The syntaxes given are equivalent to each other.
+faces = Reader.GiveList(“xst-type(SurfaceOfRevolution)”);
+faces = Reader.GiveList(“iges-type(120)”);
+You can also look for:
+ * values returned by your signature which match your criterion exactly
+faces = Reader.GiveList(“xst-type(=SurfaceOfRevolution)”);
+ * values returned by your signature which do not contain your criterion
+faces = Reader.GiveList(“xst-type(!SurfaceOfRevolution)”);
+ * values returned by your signature which do not exactly match your criterion.
+faces = Reader.GiveList(“xst-type(!=SurfaceOfRevolution)”);
+
+<h4>List of predefined operators that can be used:</h4>
+ * xst-model-all
+Selects all entities.
+ * xst-model-roots
+Selects all roots.
+ * xst-transferrable-all
+Selects all translatable entities.
+ * xst-transferrable-roots
+Selects all translatable roots (default).
+ * xst-sharing + selection
+Selects all entities sharing at least one entity selected by selection.
+ * xst-shared + selection
+Selects all entities shared by at least one entity selected by selection.
+ * iges-visible-roots
+Selects all visible roots, whether translatable or not.
+ * iges-visible-transf-roots
+Selects all visible and translatable roots.
+ * iges-blanked-roots
+Selects all blank roots, whether translatable or not.
+ * iges-blanked-transf-roots
+Selects all blank and translatable roots.
+ * iges-status-independant
+Selects entities whose IGES Subordinate Status = 0.
+ * iges-bypass-group
+Selects all root entities. If a root entity is a group (402/7 or 402/9), the entities in the group are selected.
+ * iges-bypass-subfigure
+Selects all root entities. If a root entity is a subfigure definition (308), the entities in the subfigure definition are selected.
+ * iges-bypass-group-subfigure
+Selects all root entities. If a root entity is a group (402/7 or 402/9) or a subfigure definition (308), the entities in the group and in the subfigure definition are selected.
+ * iges-curves-3d
+Selects 3D curves, whether they are roots or not (e.g. a 3D curve on a surface).
+ * iges-basic-geom
+Selects 3D curves and untrimmed surfaces.
+ * iges-faces
+Selects face-supporting surfaces (trimmed or not).
+ * iges-surfaces
+Selects surfaces not supporting faces (i.e. with natural bounds).
+ * iges-basic-curves-3d
+Selects the same entities as iges-curves-3d. Composite Curves are broken down into their components and the components are selected.
+@subsubsection occt_1856844696_804874798_35 Performing the IGES file translation
+Perform translation according to what you want to translate:
+1. Translate an entity identified by its rank with:
+Standard_Boolean ok = reader.Transfer (rank);
+-# 2. Translate an entity identified by its handle with:
+Standard_Boolean ok = reader.TransferEntity (ent);
+3. Translate a list of entities in one operation with:
+Standard_Integer nbtrans = reader.TransferList (list);
+reader.IsDone();
+ nbtrans returns the number of items in the list that produced a shape.
+ reader.IsDone() indicates whether at least one entity was translated.
+4. Translate a list of entities, entity by entity:
+Standard_Integer i,nb = list-Length();
+ for (i = 1; i = nb; i ++) {
+ Handle(Standard_Transient) ent = list-Value(i);
+ Standard_Boolean OK = reader.TransferEntity (ent);
+ }
+5. Translate the whole file (all entities or only visible entities) with:
+Standard_Boolean onlyvisible = Standard_True or Standard_False;
+reader.TransferRoots(onlyvisible)
+@subsubsection occt_1856844696_804874798_36 Getting the translation results
+Each successful translation operation outputs one shape. A series of translations gives a series of shapes.
+Each time you invoke TransferEntity, Transfer or Transferlist, their results are accumulated and NbShapes increases. You can clear the results (Clear function) between two translation operations, if you do not do this, the results from the next translation will be added to the accumulation. TransferRoots operations automatically clear all existing results before they start.
+Standard_Integer nbs = reader.NbShapes();
+returns the number of shapes recorded in the result.
+TopoDS_Shape shape = reader.Shape(num);,
+returns the result num, where num is an integer between 1 and NbShapes.
+TopoDS_Shape shape = reader.Shape();
+returns the first result in a translation operation.
+TopoDS_Shape shape = reader.OneShape();
+returns all results in a single shape which is:
+ * a null shape if there are no results,
+ * in case of a single result, a shape that is specific to that result,
+ * a compound that lists the results if there are several results.
+reader.Clear();
+erases the existing results.
+reader.PrintTransferInfo (failsonly, mode);
+displays the messages that appeared during the last invocation of Transfer or TransferRoots.
+If failsonly is IFSelect_FailOnly, only fail messages will be output, if it is IFSelect_FailAndWarn, all messages will be output. Parameter “mode” can have IFSelect_xxx values where xxx can be:
+GeneralCount
+gives general statistics on the transfer (number of translated IGES entities, number of fails and warnings, etc)
+CountByItem
+gives the number of IGES entities with their types per message.
+ListByItem
+gives the number of IGES entities with their type and DE numbers per message.
+ResultCount
+gives the number of resulting OCCT shapes per type
+Mapping
+gives mapping between roots of the IGES file and the resulting OCCT shape per IGES and OCCT type.
+@subsection occt_1856844696_804874798_4 Mapping of IGES entities to Open CASCADE Technology shapes
+***NOTE***
+*IGES entity types that are not given in the following tables are not translatable.*
+@subsubsection occt_1856844696_804874798_41 Points
+@subsubsection occt_1856844696_804874798_42 Curves
+Curves, which form the 2D of face boundaries, are translated as Geom2D_Curves (Geom2D circles, etc.).
+
+The type of OCCT shapes (either TopDS_Edges or TopoDS_Wires) that result from the translation of IGES entities 106, 112 and 126 depends on the continuity of the curve in the IGES file and the value of the read.iges.bspline.continuity translation parameter.
+@subsubsection occt_1856844696_804874798_43 Surfaces
+Translation of a surface outputs either a TopoDS_Face or a TopoDS_Shell.
+If a TopoDS_Face is output, its geometrical support is a Geom_Surface and its outer and inner boundaries (if it has any) are TopoDS_Wires.
+
+@subsubsection occt_1856844696_804874798_44 Boundary Representation Solid Entities
+@subsubsection occt_1856844696_804874798_45 Structure Entities
+@subsubsection occt_1856844696_804874798_46 Subfigures
+
+@subsubsection occt_1856844696_804874798_47 Transformation Matrix
+@subsection occt_1856844696_804874798_5 Messages
+Messages are displayed concerning the normal functioning of the processor (transfer, loading, etc.).
+You must declare an include file:
+#includeInterface_DT.hxx
+You have the choice of the following options for messages:
+IDT_SetLevel (level);
+level modifies the level of messages:
+ * 0: no messages
+ * 1: raise and fail messages are displayed, as are messages concerning file access,
+ * 2: warnings are also displayed.
+IDT_SetFile (“tracefile.log”);
+prints the messages in a file,
+IDT_SetStandard();
+restores screen output.
+@subsection occt_1856844696_804874798_6 Tolerance management
+@subsubsection occt_1856844696_804874798_61 Values used for tolerances during reading IGES
+During the transfer of IGES to Open CASCADE Technology several parameters are used as tolerances and precisions for different algorithms. Some of them are computed from other using specific functions.
+<h4>3D (spatial) tolerances</h4>
+<h5>Package method Precision::Confusion</h5>
+The value is 10-7. It is used as a minimal distance between points, which are considered distinct.
+<h5>Resolution in the IGES file</h5>
+This parameter is defined in the Global section of an IGES file. It is used as a fundamental value of precision during the transfer.
+<h5>User-defined variable read.precision.val</h5>
+It is to be used instead of resolution from the file when parameter read.precision.mode is 1 (“User”).
+<h5>Field EpsGeom of the class IGESToBRep_CurveAndSurface</h5>
+This value is a basic precision for translating an IGES object. It is set for each object of class IGESToBRep_CurveAndSurface and its derived classes. It is initialized for the root of transfer either by value of resolution from the file or by value of read.precision.val*,* depending on the value of read.precision.mode parameter. Returned by call to method IGESToBRep_CurvAndSurface::GetEpsGeom*.*
+NOTE: Since this value is in measurement units of the IGES file, it is usually multiplied by the coefficient UnitFactor (returned by method IGESToBRep_CurvAndSurface::GetUnitFactor) to convert it to Open CASCADE Technology units.
+<h5>Field MaxTol of the class IGESToBRep_CurveAndSurface</h5>
+This value is used as the maximum tolerance for some algorithms.
+Currently, it is computed as the maximum between 1 and GetEpsGeom*GetUnitFactor.
+This field is returned by method IGESToBRep_CurvAndSurface::GetMaxTol*.*
+<h4>2D (parametric) tolerances</h4>
+<h5>Package method Precision::PConfusion</h5>
+This is value 0.01*Precision::Confusion = 10-9. It is used to compare parametric bounds of curves.
+<h5>Field EpsCoeff of the class IGESToBRep_CurveAndSurface</h5>
+This value is a parametric precision for translating an IGES object. It is set for each object of class IGESToBRep_CurveAndSurface and its derived classes. Currently, it always has its default value 10-6. It is returned by call to method IGESToBRep_CurvAndSurface::GetEpsCoeff*.* This value is used for translating 2d objects (for instance, parametric curves).
+<h5>Methods UResolution(tolerance3d), VResolution(tolerance3d) of the class GeomAdaptor_Surface or BRepAdaptor_Surface</h5>
+Return tolerance in parametric space of a surface computed from 3d tolerance.
+* When one tolerance value is to be used for both U and V parametric directions, the maximum or the minimum value of UResolution and VResolution is used.*
+<h5>Methods Resolution(tolerance3d) of the class GeomAdaptor_Curve or BRepAdaptor_Curve</h5>
+Return tolerance in the parametric space of a curve computed from 3d tolerance.
+<h4>Zero-dimensional tolerances</h4>
+<h5>Field Epsilon of the class IGESToBRep_CurveAndSurface</h5>
+Value is set for each object of class IGESToBRep_CurveAndSurface. Returned by call to method GetEpsilon*.* It is used in comparing angles and converting transformation matrices. In most cases, it is reset to a fixed value (10-5 - 10-3) right before use. Default value is 10-4.
+@subsubsection occt_1856844696_804874798_62 Initial setting of tolerances in translating objects
+Transfer starts from one entity treated as a root (either the actual root in the IGES file or an entity selected by the user). The function which performs the transfer (that is IGESToBRep_Actor::Transfer or IGESToBRep_Reader::Transfer) creates an object of the type IGESToBRep_CurveAndSurface, which is intended for translating geometry.
+This object contains three tolerances: Epsilon, EpsGeom and EpsCoeff.
+Parameter Epsilon is set by default to value 10-4. In most cases when it is used in the package IGESToBRep, it is reset to a fixed value, either 10-5 or 10-4 or 10-3. It is used as precision when comparing angles and transformation matrices and does not have influence on the tolerance of the resulting shape.
+Parameter EpsGeom is set right after creating a IGESToBRep_CurveAndSurface object to the value of resolution, taken either from the Global section of an IGES file, or from the XSTEP.readprecision.val parameter*,* depending on the value of XSTEP.readprecision.mode.
+Parameter EpsCoeff is set by default to 10-6 and is not changed.
+During the transfer of a shape, new objects of type IGESToBRep_CurveAndSurface are created for translating subshapes. All of them have the same tolerances as the root object.
+@subsubsection occt_1856844696_804874798_63 Transfer process
+<h4>Translating into Geometry</h4>
+Geometrical entities are translated by classes IGESToBRep_BasicCurve and IGESToBRep_BasicSurface. Methods of these classes convert curves and surfaces of an IGES file to Open CASCADE Technology geometry objects:
+Geom_Curve, Geom_Surface, Geom_Transformation
+Since these objects are not BRep objects, they do not have tolerances. Hence, tolerance parameters are used in these classes only as precisions: to detect specific cases (e.g., to distinguish a circle, an ellipse, a parabola and a hyperbola) and to detect bad cases (such as coincident points).
+Use of precision parameters is reflected in the following classes:
+<h5>Class IGESToBRep_BasicCurve</h5>
+All parameters and points are compared with precision EpsGeom.
+All transformations (except IGESToBRep_BasicCurve::TransferTransformation) are fulfilled with precision Epsilon which is set to 10-3 (in the IGESToBRep_BasicCurve::TransferTransformation the value 10-5 is used).
+ * IGESToBRep_BasicCurve::TransferBSplineCurve
+All weights of BSplineCurve are assumed to be more than Precision::PConfusion (else the curve is not translated).
+<h5>Class IGESToBRep_BasicSurface</h5>
+All parameters and points are compared with precision EpsGeom.
+All transformations are fulfilled with precision Epsilon, which is set to 10-3.
+ * IGESToBRep_BasicSurface::TransferBSplineSurface
+All weights of BSplineSurface are assumed to be more than Precision::PConfusion (else the surface is not translated).
+<h4>Translating into Topology</h4>
+IGES entities represented as topological shapes and geometrical objects are translated into OCCT shapes by use of the following classes:
+IGESToBRep_TopoCurve, IGESToBRep_TopoSurface, IGESToBRep_BRepEntity, ShapeFix_Wire
+Class IGESToBRep_BRepEntity is intended for transferring BRep entities (IGES version ³ 5.1) while the two former are used for translating geometry and topology defined in IGES 5.1. Methods from IGESToBRep_BRepEntity call methods from IGESToBRep_TopoCurve and IGESToBRep_TopoSurface, while those call methods from IGESToBRep_BasicCurve and IGESToBRep_BasicSurface in order to translate IGES geometry into OCCT geometry.
+Although the IGES file contains only one parameter for tolerance in the Global Section, OCCT shapes are produced with different tolerances. As a rule, updating the tolerance is fulfilled according to local distances between shapes (distance between vertices of adjacent edges, deviation of edge’s 3D curve and its parametric curve and so on) and may be less or greater than precision in the file.
+The following classes show what default tolerances are used when creating shapes and how they are updated during transfer.
+<h5>Class IGESToBRep_TopoCurve</h5>
+All the methods which are in charge of transferring curves from IGES curve entities (TransferCompositeCurve, Transfer2dCompositeCurve, TransferCurveOnFace, TransferBoundaryOnFace, TransferOffsetCurve, TransferTopoBasicCurve) if an entity has transformation call to IGESData_ToolLocation::ConvertLocation with Epsilon value set to 10-4.
+ * IGESToBRep_TopoCurve::TransferPoint
+Vertex is constructed from a Point entity with tolerance EpsGeom*UnitFactor.
+ * IGESToBRep_TopoCurve::Transfer2dPoint
+Vertex is constructed from a Point entity with tolerance EpsCoeff.
+ * IGESToBRep_TopoCurve::TransferCompositeCurveGeneral
+Obtains shapes (edges or wires) from other methods and adds them into the resulting wire. Two adjacent edges of the wire can be connected with tolerance up to MaxTol.
+ * IGESToBRep_TopoCurve::TransferCurveOnFace and IGESToBRep_TopoCurve::TransferBoundaryOnFace
+This method builds a wire from 3D and 2D representations of a curve on surface.
+Edges and vertices of the wire cannot have tolerance larger than MaxTol.
+The value EpsGeom*UnitFactor is passed into ShapeFix_Wire::SetPrecision and MaxTol - into ShapeFix_Wire::MaxTolerance. To find out how these parameters affect the resulting tolerance changes, please refer to class ShapeFix_Wire.
+ * IGESToBRep_TopoCurve::TransferTopoBasicCurve and IGESToBRep_TopoCurve::Transfer2dTopoBasicCurve
+The boundary vertices of an edge (or a wire if a curve was of C0 continuity) translated from a basis IGES curve (BSplineCurve, CopiousData, Line, etc.) are built with tolerance EpsGeom*UnitFactor, the tolerance of the edge(s) is (are) Precision::Confusion*.*
+If a curve was divided into several edges, the common vertices of such adjacent edges have tolerance Precision::Confusion*.*
+<h5>Class IGESToBRep_TopoSurface</h5>
+All the faces created by this class have tolerance Precision::Confusion*.*
+<h5>Class IGESToBRep_BRepEntity</h5>
+ * IGESToBRep_BRepEntity::TransferVertex
+The vertices from the VertexList entity are constructed with tolerance EpsGeom*UnitFactor.
+ * IGESToBRep_BRepEntity::TransferEdge
+The edges from the EdgeList entity are constructed with tolerance Precision::Confusion*.*
+ * IGESToBRep_BRepEntity::TransferLoop
+This function works like IGESToBRep_TopoCurve::TransferCurveOnFace* *and* *IGESToBRep_TopoCurve::TransferBoundaryOnFace*.*
+ * IGESToBRep_BRepEntity::TransferFace
+The face from the Face IGES entity is constructed with tolerance Precision::Confusion.
+<h5>Shape Healing classes</h5>
+After performing a simple mapping, shape-healing algorithms are called (class ShapeFix_Shape) by IGESToBRep_Actor::Transfer(). A shape-healing algorithm performs the correction of a resulting OCCT shape.
+Class ShapeFix_Wire can increase the tolerance of a shape. This class is used in IGESToBRep_BRepEntity::TransferLoop*,* IGESToBRep_TopoCurve::TransferBoundaryOnFace and IGESToBRep_TopoCurve::TransferCurveOnFace for correcting a wire. The maximum possible tolerance which edges or vertices will have after invoking the methods of this class is MaxTolerance (set by method ShapeFix_Wire::MaxTolerance()).
+
+@subsection occt_1856844696_804874798_7 Code architecture
+@subsubsection occt_1856844696_804874798_71 List of the classes
+<h5>Package IGESControl</h5>
+IGESControl_Reader
+<h5>Package IGESToBRep</h5>
+IGESToBRep_Reader
+IGESToBRep_Actor
+IGESToBRep_CurveAndSurface
+IGESToBRep_BasicCurve
+IGESToBRep_BasicSurface
+IGESToBRep_TopoCurve
+IGESToBRep_TopoSurface
+IGESToBRep_BRepEntity
+<h5>Package IGESConvGeom</h5>
+For description of classes, refer to CDL.
+@subsubsection occt_1856844696_804874798_72 List of API classes
+<h5>package IGESControl</h5>
+IGESControl_Reader
+<h5>package IGESToBRep</h5>
+IGESToBRep_Reader
+<h5>package IGESData</h5>
+class IGESData_IGESModel
+class IGESData_IGESEntity
+For details, refer to 4 API for reading/writing IGES and CDL.
+@subsubsection occt_1856844696_804874798_73 Graph of calls
+The following diagram illustrates the structure of calls in reading IGES.
+The highlighted classes produce OCCT geometry.
+
+
+@subsection occt_1856844696_804874798_8 Example
+#include “IGESControl_Reader.hxx”
+#include “TColStd_HSequenceOfTransient.hxx”
+#include “TopoDS_Shape.hxx”
+{
+IGESControl_Reader myIgesReader;
+Standard_Integer nIgesFaces,nTransFaces;
+
+myIgesReader.ReadFile (“MyFile.igs”);
+//loads file MyFile.igs
+
+Handle(TColStd_HSequenceOfTransient) myList = myIgesReader.GiveList(“iges-faces”);
+//selects all IGES faces in the file and puts them into a list called //MyList,
+
+nIgesFaces = myList-Length();
+nTransFaces = myIgesReader.TransferList(myList);
+//translates MyList,
+
+cout“IGES Faces: “nIgesFaces“ Transferred:”nTransFacesendl;
+TopoDS_Shape sh = myIgesReader.OneShape();
+//and obtains the results in an OCCT shape.
+}
+
+
+@section occt_1856844696_874243683 Writing IGES
+@subsection occt_1856844696_8742436831 Procedure
+You can translate OCCT shapes to IGES entities in the following steps:
+1. initialize the process.
+2. set the translation parameters,
+3. perform the model translation,
+4. write the output IGES file.
+You can translate several shapes before writing a file. Each shape will be a root entity in the IGES model.
+@subsection occt_1856844696_8742436832 Domain covered
+There are two families of OCCT objects that can be translated:
+ * geometrical,
+ * topological.
+@subsection occt_1856844696_8742436833 Description of the process
+@subsubsection occt_1856844696_87424368331 Initializing the process
+Choose the unit and the mode you want to use to write the output file as follows:
+IGESControl_Controller::Init
+performs standard initialization. Returns False if an error occurred.
+IGESControl_Writer writer;
+uses the default unit (millimeters) and the default write mode (Face).
+IGESControl_Writer writer (UNIT);
+uses the Face write mode and any of the units that are accepted by IGES.
+IGESControl_Writer writer (UNIT,modecr);
+uses the unit (accepted by IGES) and the write mode of your choice.
+ * 0: Faces,
+ * 1: BRep
+The result is an IGESControl_Writer object.
+@subsubsection occt_1856844696_87424368332 Setting the translation parameters
+The following parameters are used for the OCCT-to-IGES translation.
+<h4>write.iges.brep.mode: </h4>
+gives the choice of the write mode. You can choose the following write modes:
+
+;Faces; (0): OCCT TopoDS_Faces will be translated into IGES 144 (Trimmed Surface) entities, no B-Rep entities will be written to the IGES file,
+;BRep; (1): OCCT TopoDS_Faces will be translated into IGES 510 (Face) entities, the IGES file will contain B-Rep entities.
+Read this parameter with:
+Standard_Integer byvalue = Interface_Static::IVal(;write.iges.brep.mode;);
+Modify this parameter with:
+Interface_Static::SetIVal (;write.iges.brep.mode;, 1);
+Default value is ;Faces; (0).
+<h4>write.convertsurface.mode</h4>
+For writing to IGES in the BRep mode (see parameter write.iges.brep.mode), this parameter indicates whether elementary surfaces (cylindrical, conical, spherical, and toroidal) are converted into corresponding IGES 5.3 entities (if parameter's value is On), or written as surfaces of revolution (by default).
+Default value is Off.
+<h4>write.iges.unit:</h4>
+gives the choice of the unit. The default unit for Open CASCADE Technology is the millimeter. You can choose to write your file in any of the units that are accepted by IGES.
+Read this parameter with:
+Standard_String byvalue = Interface_Static::CVal(;write.iges.unit;);
+Modify this parameter with:
+Interface_Static::SetCVal (;write.iges.unit;, ;INCH;);
+Default value is ;MM;.
+<h4>write.iges.header.autor:</h4>
+gives the name of the author of the file.
+Read this parameter with:
+Standard_String byvalue = Interface_Static::CVal(;write.iges.header.author;);
+Modify this value with:
+Interface_Static::SetCVal (;write.iges.header.author;, ;name;);
+Default value is the system name of the user.
+<h4>write.iges.header.company:</h4>
+gives the name of the sending company.
+Read this parameter with:
+Standard_String byvalue = Interface_Static::CVal(;write.iges.header.company;);
+Modify this value with:
+Interface_Static::SetCVal (;write.iges.header.company;, ;MDTV;);
+Default value is ;; (empty).
+<h4>write.iges.header.product:</h4>
+gives the name of the sending product.
+Read this parameter with:
+Standard_String byvalue = Interface_Static::CVal(;write.iges.header.product;);
+Modify this value with:
+Interface_Static::SetCVal (;write.iges.header.product;, ;product name;);
+Default value is ;CAS.CADE IGES processor Vx.x; where x.x means the current version of Open CASCADE Technology.
+<h4>write.iges.header.receiver:</h4>
+gives the name of the receiving company.
+Read this parameter with:
+Standard_String byvalue = Interface_Static::CVal(;write.iges.header.receiver;);
+Modify this value with:
+Interface_Static::SetCVal (;write.iges.header.receiver;, ;reciever name;);
+Default value is ;; (empty).
+<h4>write.precision.mode:</h4>
+specifies the mode of writing the resolution value into the IGES file.
+;Least; (-1): resolution value is set to the minimum tolerance of all edges and all vertices in an OCCT shape,
+;Average; (0): resolution value is set to average between the average tolerance of all edges and the average tolerance of all vertices in an OCCT shape (default),
+;Greatest; (1): resolution value is set to the maximum tolerance of all edges and all vertices in an OCCT shape,
+;Session; (2): resolution value is that of the write.precision.val parameter.
+Read this parameter with:
+Standard_Integer ic = Interface_Static::IVal(;write.precision.mode;);
+Modify this parameter with:
+if (!Interface_Static::SetIVal(;write.precision.mode;,1))
+.. error ..
+Default value is ;Average; (0).
+<h4>write.precision.val:</h4>
+user precision value. This parameter gives the resolution value for an IGES file when the write.precision.mode parameter value is 1.
+ 0.0001: default
+ any real positive (non null) value.
+Read this parameter with:
+Standard_Real rp = Interface_Static::RVal(;write.precision.val;);
+Modify this parameter with:
+if (!Interface_Static::SetRVal(;write.precision.val;,0.01))
+.. error ..
+Default value is 0.0001.
+<h4>write.iges.resource.name</h4>
+<h4>write.iges.sequence</h4>
+The same as read.iges.*, please see above. Note that the default sequence for writing contains one operator – DirectFaces - which converts elementary surfaces based on left-hand axes (valid in CASCADE) to right-hand axes (which are valid only in IGES).
+Default values : write.iges.resource.name – IGES, write.iges.sequence – ToIGES.
+@subsubsection occt_1856844696_87424368333 Performing the Open CASCADE Technology shape translation
+You can perform the translation in one or several operations. Here is how you translate topological and geometrical objects:
+Standard_Boolean ok = writer.AddShape (shape);
+where shape is a TopoDS_Shape.
+ok is True if translation was correctly performed and False if there was at least one entity that was not translated.
+Standard_Boolean ok = writer.AddGeom (geom);
+where geom is either Handle(Geom_Curve) or Handle(Geom_Surface)
+ok is True if the translation was correctly performed and False if there was at least one entity whose geometry was not among the allowed types.
+@subsubsection occt_1856844696_87424368334 Writing the IGES file
+Write the IGES file with:
+Standard_Boolean ok = writer.Write (;filename.igs;);
+to give the file name.
+Standard_Boolean ok = writer.Write (S);
+where S is Standard_OStream
+ok is True if the operation was correctly performed and False if an error occurred (for instance, if the processor could not create the file).
+@subsection occt_1856844696_8742436834 Mapping Open CASCADE Technology shapes to IGES entities
+Translated objects depend on the write mode that you chose. If you chose the Face mode, all of the shapes are translated, but the level of topological entities becomes lower (geometrical one). If you chose the BRep mode, topological OCCT shapes become topological IGES entities.
+@subsubsection occt_1856844696_87424368341 Curves
+@subsubsection occt_1856844696_87424368342 Surfaces
+
+@subsubsection occt_1856844696_87424368343 Topological entities
+<h5>Translation in Face mode</h5>
+
+<h5>Translation in BRep mode</h5>
+@subsection occt_1856844696_8742436835 Tolerance management
+@subsubsection occt_1856844696_87424368351 Setting resolution in an IGES file
+There are several possibilities to set resolution in an IGES file. They are controlled by write.precision.mode parameter; the dependence between the value of this parameter and the set resolution is described in paragraph 3.3.2 Setting the translation parameters.
+If the value of parameter write.precision.mode is -1, 0 or 1, resolution is computed from tolerances of sub-shapes inside the shape to be translated. In this computation, only tolerances of TopoDS_Edges and TopoDS_Vertices participate since they reflect the accuracy of the shape. TopoDS_Faces are ignored in computations since their tolerances may have influence on resulting computed resolution while IGES resolution mainly concerns points and curves but not surfaces.
+
+@subsection occt_1856844696_8742436836 Code architecture
+@subsubsection occt_1856844696_87424368361 List of the classes
+<h5>package IGESControl </h5>
+IGESControl_Controller
+IGESControl_Writer
+<h5>package BRepToIGES </h5>
+BRepToIGES_BREntity
+BRepToIGES_BRWire
+BRepToIGES_BRShell
+BRepToIGES_BRSolid
+<h5>package BRepToIGESBRep </h5>
+BRepToIGESBRep_Entity
+<h5>package GeomToIGES </h5>
+GeomToIGES_GeomPoint
+GeomToIGES_GeomVector
+GeomToIGES_GeomCurve
+GeomToIGES_GeomSurface
+<h5>package Geom2dToIGES </h5>
+Geom2dToIGES_Geom2dCurve
+<h5>package IGESConvGeom </h5>
+IGESConvGeom_GeomBuilder
+For description of classes refer to CDL.
+@subsubsection occt_1856844696_87424368362 List of API classes
+<h5>package IGESControl</h5>
+ * IGESControl_Controller
+ * IGESControl_Writer
+<h5>package IGESData</h5>
+ * class IGESData_IGESModel
+ * class IGESData_IGESEntity
+For details refer to 4. API for reading/writing IGES and CDL.
+@subsubsection occt_1856844696_87424368363 Graph of calls
+The following diagram illustrates the class structure in writing IGES.
+The highlighted classes are intended to translate geometry.
+ <table>
+ <tr>
+ <td>
+
+ </td>
+ </tr>
+ <tr>
+ <td>
+
+ </td>
+ <td>
+ 
+ </td>
+ </tr>
+</table>
+@subsection occt_1856844696_8742436837 Example
+#include IGESControl_Controller.hxx
+#include IGESControl_Writer.hxx
+#include TopoDS_Shape.hxx
+Standard_Integer main()
+{
+ IGESControl_Controller::Init();
+ IGESControl_Writer ICW (;MM;, 0);
+ //creates a writer object for writing in Face mode with millimeters
+ TopoDS_Shape sh;
+ ICW.AddShape (sh);
+ //adds shape sh to IGES model
+ ICW.ComputeModel();
+ Standard_Boolean OK = ICW.Write (;MyFile.igs;);
+ //writes a model to the file MyFile.igs
+}
+@section occt_1856844696_1288309531 API for reading/writing IGES
+@subsection occt_1856844696_12883095311 Overview
+API classes provides the following tools:
+ * loading IGES files into memory,
+ * checking IGES files consistency,
+ * translating IGES files into OCCT shapes,
+ * translating OCCT shapes into IGES files,
+ * accessing the IGES model (which is an image of the IGES file in memory),
+ * selecting entities from the IGES model,
+ * accessing each entity in the IGES model.
+@subsection occt_1856844696_12883095312 Package IGESControl
+@subsubsection occt_1856844696_128830953121 General description
+This package is intended to provide a tool to convert IGES-format entities to OCCT shapes and vice versa.
+The package allows the end-user to perform both import from and export to an IGES file.
+IGES files up to and including IGES version 5.3 can be read.
+IGES files that are produced by this component conform to IGES version 5.3.
+The result of reading IGES files is either a single Open CASCADE Technology shape or a set of them, the result of exporting Open CASCADE Technology geometric or topologic objects is an IGES file which may include one or several root entities (the ones not referenced by others).
+@subsubsection occt_1856844696_128830953122 Class IGESControl_Controller
+<h4>General description </h4>
+This class controls the IGES norm.
+This class is intended to provide an appropriate initialization of the IGES norm, namely it includes a set of necessary parameters for IGES translation and declaration of possible selections for IGES entities.
+After the execution of initialization procedures, the use of IGES norm becomes available.
+Inheritance
+Standard_Transient
+MMgt_TShared
+XSControl_Controller
+<h4>Methods</h4>
+<h5>Constructors</h5>
+IGESControl_Controller(const Standard_Boolean modefnes = Standard_False);
+Purpose: Initializes the use of IGES (if modefnes is False) or FNES (if modefnes is True) norm.
+<h5>Method for performing initialization</h5>
+IGESControl:: Init
+static Standard_Boolean Init() ;
+Purpose: Performs standard initialization creating controller objects for both IGES and FNES norm.
+Returns True when done, False if an error occurred.
+<h5>Method for creating IGES model</h5>
+IGESControl:: NewModel
+Handle_Interface_InterfaceModel NewModel() const;
+Purpose: Creates a new empty model ready to receive data of the norm. The Global section is filled with static parameters (receiver, author, company and unit).
+<h5>Method for getting the actor object</h5>
+IGESControl:: ActorRead
+Handle_Transfer_ActorOfTransientProcess ActorRead( const Handle(Interface_InterfaceModel)& model) const;
+Purpose: Returns the actor object for reading (actually, it is of type IGESToBRep_Actor) with a set parameter of spline continuity taken from static parameter.
+<h5>Method for translating an Open CASCADE Technology shape</h5>
+IGESControl:: TransferWriteShape
+virtual IFSelect_ReturnStatus TransferWriteShape(const TopoDS_Shape& shape, const Handle(Transfer_FinderProcess)& FP, const Handle(Interface_InterfaceModel)& model, const Standard_Integer modetrans = 0) const;
+Purpose: Translates shape into the interface model.
+modetrans: 0 - group of Faces (IGES 5.1) , 1 - for BRep (IGES = 5.1)
+Returns:
+IFSelect_RetDone: OK,
+IFSelect_RetError: if modetrans is not equal to 0 or 1, or model is not an IGES model.
+IFSelect_Fail: if shape is null.
+
+@subsubsection occt_1856844696_128830953123 Class IGESControl_Reader
+<h4>General description</h4>
+This object reads IGES files and translates their contents into OCCT shapes.
+All definitions in IGES version 5.3 are recognized but only geometric and topologic entities can be translated. Data, which cannot be translated, is loaded with the file but during translation it is ignored.
+The translation of the IGES model into the OCCT model goes through the following steps:
+ * loading a file into memory,
+ * checking file consistency,
+ * setting translation parameters,
+ * performing the translation itself,
+ * fetching the results.
+
+The resulting OCCT objects belong to topologic shapes. The geometric objects (2D and 3D) are constructed in intermediate steps and serve as a support for topologic entities.
+Each successful translation operation outputs one shape. A series of translations gives a list of shapes.
+Inheritance
+IGESToBRep_Reader
+This class complements IGESToBRep_Reader class:
+ * deals directly with WorkSession object,
+ * computes the list of IGES entities matching specified criteria,
+ * performs translation of a list of entities and the ones specified by handle,
+ * outputs the results of checking and translating.
+<h4>Methods</h4>
+<h5>Constructors: </h5>
+ * IGESControl_Reader ();
+Purpose: Creates a reader from scratch and with a new WorkSession object.
+ * IGESControl_Reader (const Handle(XSControl_WorkSession)& WS,
+ const Standard_Boolean scratch);
+Purpose: Defines work session for the reader. If scratch is True the new model will be created in the work session.
+<h5>Methods for dealing with WorkSession object </h5>
+ * IGESControl_Reader::SetWS
+void SetWS ( const Handle(XSControl_WorkSession)& WS,
+ const Standard_Boolean scratch = Standard_True);
+Purpose: Defines the work session for the reader.
+ If scratch is True the new model will be created in the work session object.
+ * IGESControl_Reader::WS
+Handle_XSControl_WorkSession() const;
+Purpose: Returns the used work session object.
+<h5>Method for loading an IGES file into memory </h5>
+ * IGESControl_Reader::ReadFile
+IFSelect_ReturnStatus ReadFile(const Standard_CString filename);
+Purpose: Loads and memorizes an IGES file in memory.
+Returns:
+IFSelect_RetDone: the file was successfully read
+IFSelect_RetVoid: no file found
+IFSelect_RetError: an error occurred during reading
+See also:
+ IGESToBRep_Reader::LoadFile()
+
+<h5>Methods for selecting entities to transfer</h5>
+ * IGESControl_Reader::GiveList
+Handle_TColStd_HSequenceOfTransient GiveList( const Standard_CString first = ;;, const Standard_CString second = ;;);
+Purpose: Returns a list of entities from the model according to the following rules:
+ * if first and second are empty - the list of roots for transfer,
+ * if first is a number or label of an entity - this entity itself,
+ * if first is a list of numbers/labels separated by commas - these entities,
+ * if first is a name of a selection in work session and second is not defined - the standard result of this selection,
+ * if first is a name of a selection and second is defined - the criterion defined by second is applied to result of first selection
+Remarks:
+ if second is erroneous it is ignored.
+Handle_TColStd_HSequenceOfTransient GiveList( const Standard_CString first, const Handle(Standard_Transient)& ent) ;
+Purpose: Returns a list of entities from the model according to the following rules:
+ * if first is a selection name and second is an entity or a list of entities (as a HSequenceOfTransient) - the standard result of this selection is applied to this list.
+Remarks:
+ if first is erroneous, a null handle is returned.
+<h5>Methods for performing translation</h5>
+ * IGESControl_Reader::TransferEntity
+Standard_Boolean TransferEntity(const Handle(Standard_Transient)& start) ;
+Purpose: Performs the translation of the entity specified by its handle.
+Returns False if an entity is not in the Model, else returns the result of the transfer.
+ * IGESControl_Reader:: TransferList
+Standard_Integer TransferList( const Handle(TColStd_HSequenceOfTransient)& list) ;
+Purpose: Performs the translation of the list of entities.
+Returns the number of successful transfers.
+<h5>Methods for printing statistics</h5>
+ * IGESControl_Reader:: PrintCheckLoad
+void PrintCheckLoad( const Standard_Boolean failsonly, const IFSelect_PrintCount mode) const ;
+Purpose: Displays the check results on file entities.
+If failsonly is True prints only « Fail » messages, otherwise all messages.
+mode determines the contents and the order of messages:
+IFSelect_ItemsByEntity - sequential list of messages per entity,
+IFSelect_CountByItem - counts the number of entities per message,
+IFSelect_ShortByItem - the same function but also of the first five entities,
+IFSelect_ListByItem - the same but displays the rank numbers of all (not only five) entities,
+IFSelect_EntitiesByItem - the same plus it displays the Directory Entry number for each entity
+ * IGESControl_Reader:: PrintCheckTransfer
+void PrintCheckTransfer( const Standard_Boolean failsonly, const IFSelect_PrintCount mode) const;
+Purpose: Displays the checking results of the last transfer.
+The parameters play the same role as in PrintCheckLoad.
+ * IGESControl_Reader:: PrintStatsTransfer
+void PrintStatsTransfer( const Standard_Integer what, const Standard_Integer mode = 0) const;
+Purpose: Displays all available statistics of the last transfer on the default trace file. The returned information is filtered by giving parameters.
+what defines what kind of statistics are to be printed:
+0 - basic figures,
+1 - root results,
+2 - all recorded (roots, intermediate, checked entities),
+3 - abnormal records,
+4 - warnings and fails messages,
+5 - only fail messages
+mode is used according to what:
+if what is 0 mode is ignored
+if what is 1, 2 or 3 mode defines the following:
+0 - lists numbers of concerned entities in the model,
+1 - for each entity, gives the number, label, type and result type and/or status (fail / warning...),
+2 - for each entity, gives the maximum information (check result),
+3 - counts per type of starting entity (class type),
+4 - counts per result type and/or status,
+5 - counts per couple (starting type / result type/status),
+6 – does the same thing plus gives for each item, the list of numbers of entities in the starting model
+if what is 4 or 5 - mode is treated as enumeration IFSelect_PrintCount.
+ * IGESControl_Reader:: PrintTransferInfo
+void PrintTransferInfo( const IFSelect_PrintFail failwarn, const IFSelect_PrintCount mode) const;
+Purpose: Displays information concerning the last transfer on the default trace file according to the given parameters:
+mode defines what will be printed:
+IFSelect_GeneralCount - general statistics (number of selected IGES entities, number of root IGES entities, number of resulting OCCT shapes, number of fail and warning messages),
+IFSelect_CountByItem - number of IGES entities per each message type and IGES type and form,
+IFSelect_ListByItem - number and a complete list of DE numbers of IGES entities per each message type and IGES type and form,
+IFSelect_ResultCount - number of resulting OCCT shapes per each type of the shape,
+IFSelect_Mapping - mapping of root IGES entities into OCCT shapes per IGES type and form and OCCT shape type.
+failwarn defines if only fail messages (if failwarn is IFSelect_FailOnly) or both fail and warning messages (if it is IFSelect_FailAndWarn) will be printed if mode is IFSelect_CountByItem or IFSelect_ListByItem.
+@subsubsection occt_1856844696_128830953124 Class IGESControl_Writer
+<h4>General description </h4>
+This class is intended to create and write an IGES file out of OCCT models.
+IGES files produced by this component conform to IGES version 5.3.
+This component gives a possibility to write an IGES file containing either geometric entities (conformant to IGES version less than 5.1) only or BRep entities (conformant to IGES version up to and including 5.3) as well. The writing mode is chosen by specifying the appropriate parameter.
+The translation of an OCCT model (which can be a 2D or 3D geometric object or a topologic shape) into an IGES file is fulfilled in the following steps:
+1. initializing the file,
+2. setting the translation parameters,
+3. performing the translation itself,
+4. writing the IGES file.
+Export to the IGES file can be performed on the basis of either an already existing IGES model (representation of the IGES file in memory) or a new one. The former case gives an opportunity to add geometric/topologic OCCT objects into an IGES model (file) that already exists.
+<h4>Methods</h4>
+<h5>Constructors:</h5>
+ * IGESControl_Writer();
+Purpose: Creates a writer object with the default unit and write mode (Face).
+ * IGESControl_Writer( const Standard_CString unit, const Standard_Integer modecr = 0 );
+Purpose: Creates a writer object with the given values for the unit and write mode.
+unit is the name of the units that are accepted by IGES in the upper case (« IN » or « INCH » for inches, « MM » for millimeters and so on),
+modecr corresponds to write mode:
+0 - Face (default),
+1 - BRep
+ * IGESControl_Writer( const Handle(IGESData_IGESModel)& model,
+ const Standard_Integer modecr = 0);
+Purpose: Creates a writer object with an already prepared IGES model and write mode.
+<h5>Methods dealing with IGES models</h5>
+ * IGESControl_Writer:: Model
+Handle_IGESData_IGESModel Model() const;
+Purpose: Returns the produced model.
+ * IGESControl_Writer:: ComputeModel() ;
+void ComputeModel() ;
+Purpose: Prepares the model before writing by setting the required statuses inside the model.
+<h5>Methods dealing with transfer processes</h5>
+ * IGESControl_Writer:: SetTransferProcess
+void SetTransferProcess(const Handle(Transfer_FinderProcess)& TP) ;
+Purpose: Sets the FinderProcess object for the writer.
+ * IGESControl_Writer:: TransferProcess
+Handle_Transfer_FinderProcess TransferProcess() const;
+Purpose: Returns the FinderProcess object (containing final results and messages if any).
+<h5>Methods for performing translation</h5>
+ * IGESControl_Writer:: AddShape
+Standard_Boolean AddShape(const TopoDS_Shape& sh) ;
+Purpose: Translates a shape sh to IGES entities and adds them to the model.
+Returns True if done, False if sh is not suitable for IGES or is null.
+ * IGESControl_Writer:: AddGeom
+Standard_Boolean AddGeom(const Handle(Standard_Transient)& geom) ;
+Purpose: Translates geom (which must be a curve or a surface) to IGES entities and adds them to the model.
+Returns True if done, False if geom is neither a surface nor a curve suitable for IGES or is null.
+ * IGESControl_Writer:: AddEntity
+Standard_Boolean AddEntity(const Handle(IGESData_IGESEntity)& ent) ;
+Purpose: Adds an IGES entity (and the ones it references) to the model.
+Returns False if ent is null.
+<h5>Methods for writing an IGES file</h5>
+ * IGESControl_Writer:: Write
+Standard_Boolean Write( Standard_OStream& S, const Standard_Boolean fnes = Standard_False) ;
+Standard_Boolean Write( const Standard_CString file, const Standard_Boolean fnes = Standard_False) ;
+Purpose: Prepares (call ComputeModel()) and writes the model to the stream S or to the file file.
+Returns True if the operation was correctly performed, False in case of error.
+If mode fnes is equal to True, the resulting file will be written in the FNES format.
+<h5>Method for obtaining statistics</h5>
+ * IGESControl_Writer:: PrintStatsTransfer
+void PrintStatsTransfer( const Standard_Integer what, const Standard_Integer mode = 0) const;
+Purpose: Intended to display all statistics on the last performed translation.
+Remarks: At the present moment does nothing (an empty method).
+Package IGESToBRep
+
+@subsubsection occt_1856844696_128830953125 General description
+Performs the actual translation of IGES entities into OCCT objects.
+This package recognizes an IGES entity, performs its translation into an OCCT object (which can be 2D or 3D geometric objects, topologic shapes or transformation matrices) and returns the resulting shapes with associated messages (if there are any) occurred during the translation.
+Those IGES entities that can be translated into OCCT objects by this package are given in the following table:
+
+Finally, all geometric IGES entities (curves and surfaces) are translated into topologic shapes. OCCT geometric objects serve as a support for topology.
+@subsubsection occt_1856844696_128830953126 Class IGESToBRep_Reader
+<h4>General description</h4>
+This class reads IGES files and translates their contents into OCCT shapes.
+This class provides basic tools for loading, checking and translating IGES files into OCCT topologic shapes. It is complemented with more high-level features by class IGESControl_Reader.
+The functionalities provided by this class are the following:
+ * loading a file into memory,
+ * checking an IGES model in memory,
+ * translating all root entities or one entity specified by its rank number into OCCT shapes,
+ * fetching the results.
+
+<h4>Methods</h4>
+<h5>Constructors: </h5>
+ * IGESToBRep_Reader();
+Purpose: Performs initialization calling IGESAppli::Init() and IGESSolid::Init(), creates a new Actor object for transfer.
+
+<h5>Method for loading an IGES file into memory</h5>
+ * IGESToBRep_Reader:: LoadFile
+Standard_Integer LoadFile(const Standard_CString filename) ;
+Purpose: Loads an IGES file filename into memory calling IGESFile_Read(), sets the returned IGES model (representing the loaded IGES file) calling SetModel().
+<h5>Method for checking an IGES file</h5>
+ * IGESToBRep_Reader:: Check
+Standard_Boolean Check(const Standard_Boolean withprint) const;
+Purpose: Performs checking of a loaded IGES file calling Interface_CheckTool and Interface_CheckIterator. If withprint is True outputs the results of checking to the default trace file.
+<h5>Methods for preparing the transfer process</h5>
+ * IGESToBRep_Reader:: SetModel
+void SetModel(const Handle(IGESData_IGESModel)& model) ;
+Purpose: Sets a new IGES model object. Clears the list of translated shapes (if there are any), sets a new transfer process object.
+ * IGESToBRep_Reader:: Model
+Handle_IGESData_IGESModel Model() const;
+Purpose: Returns the used IGES model object.
+ * IGESToBRep_Reader:: SetTransientProcess
+void SetTransientProcess(const Handle(Transfer_TransientProcess)& TP) ;
+Purpose: Sets the transfer process object.
+ * IGESToBRep_Reader:: TransientProcess
+Handle_Transfer_TransientProcess TransientProcess() const;
+Purpose: Returns the used transfer process object.
+ * IGESToBRep_Reader:: Actor
+Handle_IGESToBRep_Actor Actor() const;
+Purpose: Returns the used actor object.
+ * IGESToBRep_Reader::Clear
+void Clear() ;
+Purpose: Clears the list of translated shapes.
+<h5>Methods for translation</h5>
+ * IGESToBRep_Reader:: TransferRoots
+void TransferRoots(const Standard_Boolean onlyvisible = Standard_True)
+Purpose: Performs the translation of root entities (ones that are not referenced by others). If onlyvisible is True, translates only visible entities (with Blank status equal to 0). Sets the continuity in accordance with the static parameter read.iges.bspline.continuity.
+If parameter read.maxprecision.mode is set to 1, calls to ShapeTool_Utils::LimitTolerance() for the resulting shape with parameters 0 and the maximum between read.maxprecision.val and the basis tolerance of processor.
+ * IGESToBRep_Reader:: Transfer
+Standard_Boolean Transfer(const Standard_Integer num) ;
+Purpose: Performs the translation of an entity specified by its rank number.
+Creates an object of class IGESToBRep_CurveAndSurface and sets:
+3D precision (taking its value either from the file or from the work session in accordance with the static parameter read.precision.mode),
+the approximation mode parameter in accordance with static the parameter read.iges.bspline.approxd1.mode,
+the mode for a preferred computation of curves on a surface in accordance with the static parameter read.surfacecurve.mode,
+the spline continuity parameter in accordance with the static parameter read.iges.bspline.continuity,
+the transfer process object taken from itself.
+Once all the fields have been filled out this method calls method TransferGeometry() with the IGES entity calculated by its rank number to obtain the OCCT shape.
+Like method TransferRoots() this one also limits the tolerance if the static parameter read.maxprecision.mode is set to 1.
+Returns False if num is greater than the number of entities in the model or less than 1, otherwise returns True even if there was an exception during the transfer.
+<h5>Methods for fetching the results</h5>
+ * IGESToBRep_Reader:: IsDone
+Standard_Boolean IsDone() const;
+Purpose: Returns True if the last transfer was successful.
+ * IGESToBRep_Reader:: NbShapes
+Standard_Integer NbShapes() const;
+Purpose: Returns the number of shapes recorded in the result.
+ * IGESToBRep_Reader:: Shape
+TopoDS_Shape Shape(const Standard_Integer num = 1) const;
+Purpose: Returns the result number num where num is an integer between 1 and NbShapes(). If not returns a null shape.
+ * IGESToBRep_Reader:: OneShape
+TopoDS_Shape OneShape() const;
+Purpose: Returns all results in a single shape, which is:
+ * a null shape if there are no results,
+ * in the case of a single result, only that shape,
+ * a compound that lists all the results if there are several resulting shapes.
+@subsection occt_1856844696_12883095313 Package IGESData
+@subsubsection occt_1856844696_128830953131 General description
+This package defines general objects for dealing with the IGES interface.
+It gives a basic description of the IGES interface:
+ * defines the Model for IGES (class IGESData_IGESModel),
+ * defines the Protocol tool specific for IGES (class IGESData_Protocol)
+ * defines the basic class IGESData_IGESEntity describing abstract IGES entity
+ * defines classes derived from IGESEntity and representing general IGES entities (IGESData_LineFontEntity, IGESData_TransfEntity, IGESData_SingleParentEntity, etc.),
+@subsubsection occt_1856844696_128830953132 Class IGESData_IGESModel
+<h4>General description </h4>
+Gives an access to the general data in the Start and the Global sections of an IGES file.
+Defines a model specific for IGES.
+An IGES file includes the following sections:
+Start,
+Global,
+Directory Entry,
+Parameter Data,
+Terminate
+Inheritance:
+Interface_InterfaceModel
+MMgt_TShared
+Standard_Transient
+<h4>Methods</h4>
+<h5>Constructor</h5>
+ * IGESData_IGESModel ();
+Purpose: Creates an empty IGES Model.
+<h5>Methods for initializing</h5>
+ * IGESData_IGESModel::ClearHeader
+void ClearHeader() ;
+Purpose: Erases all the data in the Start and Global sections.
+ * IGESData_IGESModel::NewEmptyModel
+Handle_Interface_InterfaceModel NewEmptyModel() const;
+Purpose: Returns a new Empty Model of the same type as this object, i.e. of type IGESData_IGESModel.
+<h5>Methods for dealing with the Start and the Global sections</h5>
+ * IGESData_IGESModel::DumpHeader
+void DumpHeader(Standard_OStream& S, const Standard_Integer level = 0) const;
+Remark: the Integer parameter is intended to be used as a level indicator, but not used for the moment.
+ * IGESData_IGESModel::StartSection
+Handle_TColStd_HSequenceOfHAsciiString StartSection() const;
+Purpose: Returns the Start section of the Model as a list of lines.
+ * IGESData_IGESModel::NbStartLines
+Standard_Integer NbStartLines() const;
+Purpose: Returns the number of the lines in the Start section.
+ * IGESData_IGESModel::StartLine
+Standard_CString StartLine(const Standard_Integer num) const;
+Purpose: Returns a line from the Start section specified by number num.
+Remark: An empty string is returned if number num is out of range [1, NbStartLines()].
+ * IGESData_IGESModel::ClearStartSection
+void ClearStartSection() ;
+Purpose: Clears the Start section.
+ * IGESData_IGESModel::SetStartSection
+void SetStartSection(const Handle(TColStd_HSequenceOfHAsciiString)& list, const Standard_Boolean copy = Standard_True) ;
+Purpose: Sets a new Start section from the list of strings list, copying it if copy is True (by default) or pointing to the list if copy is False.
+ * IGESData_IGESModel::AddStartLine
+void AddStartLine(const Standard_CString line, const Standard_Integer atnum = 0) ;
+Purpose: Adds a new string to the end of the existing Start section if atnum is 0 or not given, or before the atnum-th line.
+Remark: If a number is out of range [0, NbStartLines()], the line is added at the end of section.
+ * IGESData_IGESModel::GlobalSection
+const IGESData_GlobalSection& GlobalSection() const;
+Purpose: Returns the Global section of the Model.
+ * IGESData_IGESModel::SetGlobalSection.
+void SetGlobalSection(const IGESData_GlobalSection& header) ;
+Purpose: Sets the Model's Global section.
+ * IGESData_IGESModel::ApplyStatic
+Standard_Boolean ApplyStatic(const Standard_CString param = ;;) ;
+Purpose: Sets some parameters of the Global section to those defined by static parameters (see parameters of translation). The allowed values for param (all by default) are: receiver, author and company (these are acronyms of static parameters). Returns True when done and if param is given, False if param is unknown or empty.
+Remark: To set a unit into the Global section use the IGESData_BasicEditor class.
+See also: User’s Guide: Parameters of translation.
+ * IGESData_IGESModel::GetFromAnother
+void GetFromAnother(const Handle(Interface_InterfaceModel)& other) ;
+Purpose: Takes the Global section from another Model.
+ * IGESData_IGESModel::VerifyCheck
+virtual void VerifyCheck(Interface_Check& ach) const;
+Purpose: Checks whether the Global section contains valid data according to the IGES specification. If the Global section is correct this method adds nothing into ach, but if not the method adds fail messages.
+ * IGESData_IGESModel::SetLineWeights
+void SetLineWeights(const Standard_Real defw) ;
+Purpose: Sets LineWeights of entities according to the Global section (MaxLineWeight and LineWeightGrad values) or to a default value (defw) for undefined weights.
+<h5>Methods for dealing with IGES entities</h5>
+ * IGESData_IGESModel::ClearLabels() ;
+void ClearLabels() ;
+Purpose: Erases labels. Not yet implemented.
+ * IGESData_IGESModel::PrintLabel
+void PrintLabel(const Handle(Standard_Transient)& ent, Standard_OStream& S) const;
+Purpose: Prints the Directory Entry number of a given entity, i.e. 'Dnn' where Dnn=2*number-1on the stream S.
+ * IGESData_IGESModel::StringLabel
+Handle_TCollection_HAsciiString StringLabel (const Handle(Standard_Transient)& ent) const;
+Purpose: Returns a string with a Directory Entry number of a given entity, i.e. a string 'Dnn' where Dnn=2*number-1.
+ * IGESData_IGESModel::Entity
+Handle_IGESData_IGESEntity Entity(const Standard_Integer num) const;
+Purpose: Returns an entity given by its rank number.
+ * IGESData_IGESModel::DNum
+Standard_Integer DNum(const Handle(IGESData_IGESEntity)& ent) const;
+Purpose: Returns the DE Number of an entity, i.e. 2*Number(ent)-1, or 0 if ent is unknown from this Model.
+@subsubsection occt_1856844696_128830953133 Class IGESData_IGESEntity
+<h4>General description</h4>
+Represents an abstract IGES entity.
+This class provides an access to common IGES entity fields (TypeNumber, TransformationMatrix,
+etc.).
+This class is a basic one for other classes complementing it to represent a certain IGES entity.
+Refer to the IGES specification for more details.
+Inheritance
+MMgt_TShared
+Standard_Transient
+<h4>Methods</h4>
+<h5>Constructors: </h5>
+ * IGESData_IGESEntity();
+Purpose: Creates an empty object. Sets all values to defaults (calls Clear()).
+<h5>Methods for initializing fields of object.</h5>
+ * IGESData_IGESEntity::Clear
+void Clear() ;
+Purpose: Clears all fields of the object.
+ * IGESData_IGESEntity::InitTypeAndForm
+void InitTypeAndForm( const Standard_Integer typenum, const Standard_Integer formnum) ;
+Purpose: Sets the Type and Form Numbers to new values.
+Remarks: Private method. Reserved for special use.
+ * IGESData_IGESEntity::InitDirFieldEntity
+void InitDirFieldEntity( const Standard_Integer fieldnum, const Handle(IGESData_IGESEntity)& ent) ;
+Purpose: Sets a directory field to an ent of any kind (see DirFieldEntity() for more details).
+Remarks: If fieldnum is not equal to values listed in DirFieldEntity(), this method does nothing.
+ * IGESData_IGESEntity::InitTransf
+void InitTransf(const Handle(IGESData_TransfEntity)& ent) ;
+Purpose: Sets the Transf or erases it if ent is null.
+ * IGESData_IGESEntity::InitView
+void InitView(const Handle(IGESData_ViewKindEntity)& ent) ;
+Purpose: Sets the View or erases it if ent is null.
+ * IGESData_IGESEntity::InitLineFont
+void InitLineFont( const Handle(IGESData_LineFontEntity)& ent, const Standard_Integer rank = 0) ;
+Purpose: Sets the LineFont. If ent is null the RankLineFont is set to rank, otherwise it is set to a negative value.
+ * IGESData_IGESEntity::InitLevel
+void InitLevel( const Handle(IGESData_LevelListEntity)& ent, const Standard_Integer val = 0) ;
+Purpose: Sets the Level. If ent is null the DefLevel is set to val, otherwise it is set to a negative value.
+ * IGESData_IGESEntity::InitColor
+void InitColor( const Handle(IGESData_ColorEntity)& ent, const Standard_Integer rank = 0) ;
+Purpose: Sets the Color. If ent is null the DefColor is set to rank, otherwise it is set to a negative value.
+ * IGESData_IGESEntity::InitStatus
+void InitStatus( const Standard_Integer blank,
+ const Standard_Integer subordinate,
+ const Standard_Integer useflag,
+ const Standard_Integer hierarchy) ;
+Purpose: Sets the flags of the Directory Part.
+ * IGESData_IGESEntity::SetLabel
+void SetLabel( const Handle(TCollection_HAsciiString)& label, const Standard_Integer sub = -1) ;
+Purpose: Sets a new Label to an Entity. If sub is given, it sets the value of SubScriptNumber, else SubScriptNumber is erased.
+ * IGESData_IGESEntity::InitMisc
+void InitMisc( const Handle(IGESData_IGESEntity)& str,
+ const Handle(IGESData_LabelDisplayEntity)& lab,
+ const Standard_Integer weightnum) ;
+Purpose: Sets data or erases it if it is given as null (zero for weightnum):
+ str for Structure,
+ lab for LabelDisplay,
+ weightnum for WeightNumber
+ * IGESData_IGESEntity::SetLineWeight
+void SetLineWeight( const Standard_Real defw,
+ const Standard_Real maxw,
+ const Standard_Integer gradw) ;
+Purpose: Computes and sets the ;true; line weight according to IGES rules from the global data MaxLineWeight (maxw) and LineWeightGrad (gradw), or sets it to defw (Default) if LineWeightNumber is null
+Remarks: If gradw is zero, there is division by zero in this method.
+<h5>Methods for querying the corresponding fields of an IGES entity. </h5>
+ * IGESData_IGESEntity::IGESType
+IGESData_IGESType IGESType() const;
+Purpose: Returns information on the IGES type of an entity including the type and the form of that entity.
+ * IGESData_IGESEntity::TypeNumber
+Standard_Integer TypeNumber() const;
+Purpose: Returns the IGES Type number.
+ * IGESData_IGESEntity::FormNumber
+Standard_Integer FormNumber() const;
+Purpose: Returns the IGES Form number.
+ * IGESData_IGESEntity::DirFieldEntity
+Handle_IGESData_IGESEntity DirFieldEntity(const Standard_Integer fieldnum) const;
+Purpose: Returns the Entity that is recorded for a given Field Number fieldnum where:
+ 3 - Structure
+ 4 - LineFont
+ 5 - LevelList
+ 6 - View
+ 7 - Transf(ormation Matrix)
+ 8 - LabelDisplay
+ 13 - Color.
+ In a case of other values it returns a null handle.
+
+ * IGESData_IGESEntity::HasStructure
+Standard_Boolean HasStructure() const;
+Purpose: Returns True if an IGES entity is defined with a structure (it is normally reserved for certain classes, such as Macros).
+ * IGESData_IGESEntity::Structure
+Handle_IGESData_IGESEntity Structure() const;
+Purpose: Returns the Structure (used by some types of IGES entities only), returns a null handle if Structure is not defined.
+ * IGESData_IGESEntity::DefLineFont
+IGESData_DefType DefLineFont() const;
+Purpose: Returns the definition status of LineFont.
+ * IGESData_IGESEntity::RankLineFont
+Standard_Integer RankLineFont() const;
+Purpose: Returns LineFont definition as an integer if it is defined as Rank. If LineFont is defined as an Entity, returns a negative value
+ * IGESData_IGESEntity::LineFont
+Handle_IGESData_LineFontEntity LineFont() const;
+Purpose: Returns LineFont as an entity if it is defined as Reference. Returns a null handle if DefLineFont is not ;DefReference;.
+ * IGESData_IGESEntity::DefLevel
+IGESData_DefList DefLevel() const;
+Purpose: Returns the definition status of Level.
+ * IGESData_IGESEntity::Level
+Standard_Integer Level() const;
+Purpose: Returns Level definition as an integer.
+ * IGESData_IGESEntity::LevelList
+Handle_IGESData_LevelListEntity LevelList() const;
+Purpose: Returns LevelList if Level is defined as List. Returns a null handle if DefLevel is not ;DefSeveral;.
+ * IGESData_IGESEntity::DefView
+IGESData_DefList DefView() const;
+Purpose: Returns the definition status of View (None,One or Several).
+ * IGESData_IGESEntity::View
+Handle_IGESData_ViewKindEntity View() const;
+Purpose: Returns the View (either Single or List) if it is defined. Returns a null handle if it is not defined.
+
+ * IGESData_IGESEntity::SingleView
+Handle_IGESData_ViewKindEntity SingleView() const;
+Purpose: Returns View as Single, if defined as One. Returns a null handle if DefView is not ;DefOne;.
+ * IGESData_IGESEntity::ViewList
+Handle_IGESData_ViewKindEntity ViewList() const;
+Purpose: Returns View as a List. Returns a null handle if DefView is not ;DefSeveral;.
+ * IGESData_IGESEntity::HasTransf
+Standard_Boolean HasTransf() const;
+Purpose: Returns True if a Transformation Matrix is defined.
+ * IGESData_IGESEntity::Transf
+Handle_IGESData_TransfEntity Transf() const;
+Purpose: Returns the Transformation Matrix (under IGES definition). Returns a null handle if there is none.
+Remarks: For a more complete use, see Location & CompoundLocation.
+ * IGESData_IGESEntity::HasLabelDisplay
+Standard_Boolean HasLabelDisplay() const;
+Purpose: Returns True if the LabelDisplay mode is defined for this entity.
+ * IGESData_IGESEntity::LabelDisplay
+Handle_IGESData_LabelDisplayEntity LabelDisplay() const;
+Purpose: Returns the LabelDisplay, if there is one; else returns a null handle.
+ * IGESData_IGESEntity::BlankStatus
+Standard_Integer BlankStatus() const;
+Purpose: Returns the Blank Status (0 - visible, 1 - blanked).
+ * IGESData_IGESEntity::SubordinateStatus
+Standard_Integer SubordinateStatus() const;
+Purpose: Returns the Subordinate Switch (0-1-2-3)
+ * IGESData_IGESEntity::UseFlag
+Standard_Integer UseFlag() const;
+Purpose: Returns the Use Flag (0 to 5) of an entity.
+ * IGESData_IGESEntity::HierarchyStatus
+Standard_Integer HierarchyStatus() const;
+Purpose: Returns the Hierarchy status (0-1-2).
+ * IGESData_IGESEntity::LineWeightNumber
+Standard_Integer LineWeightNumber() const;
+Purpose: Returns the LineWeight Number (0 if it is not defined).
+See also: LineWeight.
+
+ * IGESData_IGESEntity::LineWeight
+Standard_Real LineWeight() const;
+Purpose: Returns ;true; LineWeight, computed from LineWeightNumber and the global parameter of the Model by call to SetLineWeight.
+ * IGESData_IGESEntity::DefColor
+IGESData_DefType DefColor() const;
+Purpose: Returns the definition status of Color.
+ * IGESData_IGESEntity::RankColor
+Standard_Integer RankColor() const;
+Purpose: Returns the Color definition as an Integer (if defined as Rank). If Color is defined as an Entity, returns a negative value.
+ * IGESData_IGESEntity::Color
+Handle_IGESData_ColorEntity Color() const;
+Purpose: Returns the Color as an Entity (if defined as Reference) or a null handle if Color Definition is not ;DefReference;.
+ * IGESData_IGESEntity::CResValues
+Standard_Boolean CResValues( const Standard_CString res1,
+ const Standard_CString res2) const;
+Purpose: Fills res1 and res2 with inner ;reserved; alphanumeric fields theRes1 and theRes2. Returns False if both are blank, otherwise returns True.
+Warning: Both must be of a length equal to at least 9 characters. The contents of res1 and res2 are modofied. The 9-th character becomes null.
+ * IGESData_IGESEntity::HasShortLabel
+Standard_Boolean HasShortLabel() const;
+Purpose: Returns True if ShortLabel is not null.
+ * IGESData_IGESEntity::ShortLabel
+Handle_TCollection_HAsciiString ShortLabel() const;
+Purpose: Returns label value as a string (null if ShortLabel is blank).
+ * IGESData_IGESEntity::HasSubScriptNumber
+virtualStandard_Boolean HasSubScriptNumber() const;
+Purpose: Returns True if SubScript Number is defined.
+ * IGESData_IGESEntity::SubScriptNumber
+Standard_Integer SubScriptNumber() const;
+Purpose: Returns SubScript Number as an integer (0 if not defined).
+ * IGESData_IGESEntity::HasOneParent()
+Standard_Boolean HasOneParent() const;
+Purpose: Returns True if an entity has one and only one parent, defined by a SingleParentEntity Type Associativity (explicit sharing).
+Remarks: Thus, implicit sharing remains defined at the model level.
+See class ToolLocation.
+ * IGESData_IGESEntity::UniqueParent() const;
+Handle_IGESData_IGESEntity UniqueParent() const;
+Purpose: Returns the Unique Parent (if it is the one).
+Exceptions: Interface_InterfaceError if there are either several or no parents.
+ * IGESData_IGESEntity::Location()
+gp_GTrsf Location() const;
+Purpose: Returns the entity Location given by Transf in the Directory Part (see above). Considers local location only (not taking into account the parent's one - see CompoundLocation for that). If no Transf is defined, returns Identity.
+ * IGESData_IGESEntity::VectorLocation()
+gp_GTrsf VectorLocation() const;
+Purpose: Returns the Translation part of a local location (as for Location).
+ * IGESData_IGESEntity::CompoundLocation()
+gp_GTrsf CompoundLocation() const;
+Purpose: Returns the location of this object combined with CompoundLocation of its Parent (i.e. can be recursive). If the Parent is not single (see HasOneParent) returns Location.
+ * IGESData_IGESEntity::HasName()
+Standard_Boolean HasName() const;
+Purpose: Says if a Name is defined as Short Label or as Name Property. (Property is looked for first, otherwise ShortLabel is considered).
+ * IGESData_IGESEntity::NameValue()
+Handle_TCollection_HAsciiString NameValue() const;
+Purpose: Returns the Name value as a String (Property Name or ShortLabel). If SubNumber is defined, it is concatenated after ShortLabel as follows - label (number). Ignored in case of Property Name.
+<h5>Methods for dealing with associativities and properties.</h5>
+ * IGESData_IGESEntity::ArePresentAssociativities()
+Standard_Boolean ArePresentAssociativities() const;
+Purpose: Returns True if the Entity is defined with an Associativity list, even an empty one (i.e., the file is of 0 length). Otherwise returns False (the file contains no identification concerning this list at all).
+ * IGESData_IGESEntity::NbAssociativities
+Standard_Integer NbAssociativities() const;
+Purpose: Returns the number of recorded associativities (0 if no list is defined).
+ * IGESData_IGESEntity::Associativities
+Interface_EntityIterator Associativities() const;
+Purpose: Returns the Associativity List in the form of an EntityIterator.
+ * IGESData_IGESEntity::NbTypedAssociativities
+Standard_Integer NbTypedAssociativities
+ const Handle(Standard_Type)& atype) const;
+Purpose: Returns information on how many Associativities have the given type.
+
+ * IGESData_IGESEntity::TypedAssociativity
+Handle_IGESData_IGESEntity TypedAssociativity
+ (const Handle(Standard_Type)& atype) const;
+Purpose: Returns the Associativity of a given Type (if one exists)
+Exceptions: Interface_InterfaceError if there is none or more than one associativity.
+ * IGESData_IGESEntity::AddAssociativity
+void AddAssociativity(const Handle(IGESData_IGESEntity)& ent) ;
+Purpose: Adds an Associativity to the list (called by Associate only).
+Exceptions: Standard_NullObject if ent is null.
+ * IGESData_IGESEntity::RemoveAssociativity
+void RemoveAssociativity(const Handle(IGESData_IGESEntity)& ent) ;
+Purpose: Removes an Associativity from the list (called by Dissociate).
+Exceptions: Standard_NullObject if ent is null.
+ * IGESData_IGESEntity::LoadAssociativities
+void LoadAssociativities(const Interface_EntityList& list) ;
+Purpose: Loads a complete List of Asociativities (used during Read or Copy operations).
+ * IGESData_IGESEntity::ClearAssociativities
+void ClearAssociativities() ;
+Purpose: Removes all associativities at once.
+ * IGESData_IGESEntity::Associate
+void Associate(const Handle(IGESData_IGESEntity)& ent) const;
+Purpose: Sets this object to the Associativity list of another Entity. If ent is a null object, method does nothing.
+ * IGESData_IGESEntity::Dissociate
+void Dissociate(const Handle(IGESData_IGESEntity)& ent) const;
+Purpose: Removes this object from the Associativity list of another Entity. If ent is a null object, method does nothing.
+ * IGESData_IGESEntity::ArePresentProperties
+Standard_Boolean ArePresentProperties() const;
+Purpose: Returns True if the Entity is defined with a Property list, even an empty one (i.e., the file is of 0 length). Otherwise, returns False (file contains no identification concerning this list at all).
+ * IGESData_IGESEntity::NbProperties()
+Standard_Integer NbProperties() const;
+Purpose: Returns the number of recorded properties (0 if no list is defined)
+ * IGESData_IGESEntity::Properties()
+Interface_EntityIterator Properties() const;
+Purpose: Returns the Property List in the form of an EntityIterator
+ * IGESData_IGESEntity::NbTypedProperties
+Standard_Integer NbTypedProperties
+ (const Handle(Standard_Type)& atype) const;
+Purpose: Returns information on how many Properties have a given type
+ * IGESData_IGESEntity::TypedProperty
+Handle_IGESData_IGESEntity TypedProperty
+ (const Handle(Standard_Type)& atype) const;
+Purpose: Returns the Property of a given Type (if only one exists)
+Exceptions: Interface_InterfaceError if there is none or more than one Properties.
+ * IGESData_IGESEntity::AddProperty
+void AddProperty(const Handle(IGESData_IGESEntity)& ent) ;
+Purpose: Adds a Property to the list.
+Exceptions: Standard_NullObject if entis null.
+ * IGESData_IGESEntity::RemoveProperty
+void RemoveProperty(const Handle(IGESData_IGESEntity)& ent) ;
+Purpose: Removes a Property from the list.
+Exceptions: Standard_NullObject if entis null.
+ * IGESData_IGESEntity::LoadProperties
+void LoadProperties(const Interface_EntityList& list) ;
+Purpose: Loads a complete List of Properties (used during Read or Copy operations).
+ * IGESData_IGESEntity::ClearProperties() ;
+void ClearProperties() ;
+Purpose: Removes all properties at once
+
+
+
+@section occt_1856844696_722523915 Using XSTEPDRAW
+@subsection occt_1856844696_7225239151 XSDRAWIGES Overview
+XSTEPDRAW UL is intended for creating executables for testing XSTEP interfaces interactively in the DRAW environment. It provides an additional set of DRAW commands specific for the data exchange tasks, which allow loading and writing data files and analysis of resulting data structures and shapes.
+This paragraph 5 is divided into several sections. Sections 5.3 and 5.5 deal with reading and writing of IGES files and are intended specifically for the IGES processor, sections 5.2 and 5.4 describe some general tools for setting parameters and analyzing the data. Most of them are independent of the norm being tested. Additionally, a table of mentioned DRAW commands is provided.
+***NOTE***
+In the description of commands, square brackets ([]) are used to indicate optional parameters. Parameters given in the angle brackets () and sharps (#) are to be substituted by an appropriate value. When several exclusive variants are possible, vertical dash (|) is used.
+@subsection occt_1856844696_7225239152 Setting interface parameters
+A set of parameters for importing and exporting IGES files is defined in the XSTEP resource file. In XSTEPDRAW, these parameters can be viewed or changed using command
+Draw param [parameter_name [value]]
+Command param with no arguments gives a list of all parameters with their values. When argument parameter_name is specified, information about this parameter is printed (current value and short description).
+The third argument is used to set a new value of the given parameter. The result of the setting is printed immediately.
+During all interface operations, the protocol of the process (fail and warning messages, mapping of the loaded entities into OCCT shapes etc.) can be output to the trace file. Two parameters are defined in the DRAW session: trace level (integer value from 0 to 9, default is 0), and trace file (default is a standard output).
+Command xtrace is intended to view and change these parameters:
+Draw xtrace
+- prints current settings (e.g.: ;Level=0 - Standard Output;);
+Draw xtrace #
+- sets the trace level to the value #;
+Draw xtrace tracefile.log
+- sets the trace file as tracefile.log; and
+Draw xtrace .
+- directs all messages to the standard output.
+
+@subsection occt_1856844696_7225239153 Reading IGES files
+For a description of parameters used in reading an IGES file refer to 2.3.3 ;Setting the translation parameters ;.
+These parameters are set by command param:
+
+
+It is possible either only to load an IGES file into memory (i.e. to fill the model with data from the file), or to read it (i.e. to load and convert all entities to OCCT shapes).
+Loading is done by the command
+Draw xload file_name
+Once the file is loaded, it is possible to investigate the structure of the loaded data. To learn how to do it see 5.4 Analyzing the transferred.
+Reading of an IGES file is done by the command
+Draw igesbrep file_name result_shape_name [selection]
+Here a dot can be used instead of a filename if the file is already loaded by **xload** or **igesbrep** command. In that case, only conversion of IGES entities to OCCT shapes will be done.
+Command **igesbrep** will interactively ask the user to select a set of entities to be converted:
+
+
+After the selected set of entities is loaded the user will be asked how loaded entities should be converted into OCCT shapes (e.g., one shape per root or one shape for all the entities). It is also possible to save loaded shapes in files, and to cancel loading.
+The second parameter of the **igesbrep** command defines the name of the loaded shape. If several shapes are created, they will get indexed names. For instance, if the last parameter was ‘s’, they will be s_1, ... s_N.
+selection specifies the scope of selected entities in the model, it is xst-transferrable-roots by default. An asterisk “*” can be specified instead of iges-visible-transf-roots. For possible values for selection refer to 2.3.4.
+Instead of igesbrep the following commands can be used:
+Draw trimport file_name result_shape_name selection
+which outputs the result of translation of each selected entity into one shape,
+Draw trimpcomp file_name result_shape_name selection
+which outputs the result of translation of all selected entities into one shape (TopoDS_Compound for several entities).
+An asterisk “*” can be specified instead of selection, it means xst-transferrable-roots.
+During the IGES translation, a map of correspondence between IGES entities and OCCT shapes is created.
+To get information on the result of translation of the given IGES entity the command
+Draw tpent #
+is used.
+To create an OCCT shape corresponding to an IGES entity the command
+Draw tpdraw #
+is used.
+To get the number of an IGES entity corresponding to an OCCT shape the command
+Draw fromshape shape_name
+is used.
+To clear the map of correspondences between IGES entities and OCCT shapes the command
+Draw tpclear
+is used.
+@subsection occt_1856844696_7225239154 Analyzing the transferred data
+The procedure of analysis of the data import can be divided into two stages:
+1. checking the file contents,
+2. estimation of translation results (conversion and validated ratios).
+@subsubsection occt_1856844696_72252391541 Checking file contents
+General statistics on the loaded data can be obtained by using command
+Draw data symbol
+The information printed by this command depends on the symbol specified:
+
+
+There is a set of special objects, which can be used to operate with the loaded model. They can be of the following types:
+
+A list of these objects defined in the current session can be printed in DRAW by command
+Draw listitems
+In the following commands if several selection arguments are specified the results of each following selection are applied to those of the one preceding it.
+Command
+Draw givelist selection_name [selection_name]
+prints a list of loaded entities defined by selection argument. For possible values of selection_name please refer to 2.3.4.
+Command
+Draw givecount selection_name [selection_name]
+prints a number of loaded entities defined by selection argument. For possible values of selection_name please refer to 2.3.4.
+Three commands are used to calculate statistics on the entities in the model:
+Draw count counter [selection ...]
+Prints only a number of entities per each type matching the criteria defined by arguments.
+Draw sumcount counter [selection ...]
+Prints the total number of entities of all types matching the criteria defined by arguments and the largest number corresponding to one type.
+Draw listcount counter [selection ...]
+Prints a list of entities per each type matching the criteria defined by arguments.
+Optional selection argument, if specified, defines a subset of entities, which are to be taken into account. Argument counter should be one of the currently defined counters:
+
+Command
+Draw listtypes selection_name ...
+gives a list of entity types which were encountered in the last loaded file (with a number of IGES entities of each type). The list can be shown not for all entities but for a subset of them. This subset is defined by an optional selection argument.
+
+Entities in the IGES file are numbered in the succeeding order. An entity can be identified either by its number (#) or by its label. Label is the letter ‘D’ followed by the index of the first line with the data for this entity in the Directory Entry section of the IGES file. The label can be calculated on the basis of the number as ‘D(2*# -1)’. For example, entity # 6 has label D11. To get a label for an entity with a known number, command
+Draw elab #
+can be used.
+In the same way, command
+Draw enum D#
+prints a number for an entity with the given label.
+The content of an IGES entity can be obtained by using command
+Draw entity # level_of_information
+The list of entities referenced by a given entity and the list of entities referencing to it can be obtained by command
+Draw estat #
+@subsubsection occt_1856844696_72252391542 Estimating the results of reading IGES
+All of the following commands are available only after the data are converted into OCCT shapes (i.e. after command **igesbrep**).
+Command
+Draw tpstat [*|?]symbol [selection]
+is provided to get all statistics on the last transfer, including the list of transferred entities with mapping from IGES to OCCT types, as well as fail and warning messages. The parameter *symbol *defines what information will be printed:
+
+
+The sign ‘*’ before the parameters **n**, **s**, **b**, **t**, **r** makes it work on all entities (not only on roots). The sign ‘?’ before **n**, **s**, **b**, **t** limits the scope of information to invalid entities.
+Optional argument selection can limit the action of the command with a selected subset of entities.
+To get help, run this command without arguments.
+Example. Translation ratio on IGES faces.
+Draw: tpstat *l iges-faces
+The second version of the same command is TPSTAT (not capital spelling).
+Draw: TPSTAT symbol
+Symbol can be of the following values:
+
+Sometimes the trimming contours of IGES faces (i.e., entity 141 for 143, 142 for 144) can be lost during translation due to fails. To obtain the number of lost trims and the number of corresponding IGES entities the command
+Draw tplosttrim [IGES_type]
+is used. It outputs the rank and DE numbers of faces that lost their trims and their numbers for each type (143, 144, 510) and their total number. If a face lost several of its trims it is output only once.
+Optional parameter IGES_type can be TrimmedSurface, BoundedSurface or Face to specify the only type of IGES faces.
+Example. Untrimmed 144 entities.
+Draw tplosttrim TrimmedSurface
+To get information on OCCT shape contents the command
+Draw statshape shape_name
+is used.
+It outputs the number of each kind of shapes (vertex, edge, wire, etc.) in a shape and some geometrical data (number of C0 surfaces, curves, indirect surfaces, etc.).
+Note. The number of faces is returned as a number of references. To obtain the number of single instances the standard command (from TTOPOLOGY executable) **nbshapes** can be used.
+To analyze the internal validity of a shape, command
+Draw checkbrep shape_name expurged_shape_name
+is used. It checks the geometry and topology of a shape for different cases of inconsistency, like self-intersecting wires or wrong orientation of trimming contours. If an error is found, it copies bad parts of the shape with the names ; expurged_subshape_name _#; and generates an appropriate message. If possible, this command also tries to find IGES entities the OCCT shape was produced from.
+expurged_shape_name will contain the original shape without invalid subshapes.
+To get information on tolerances of subshapes the command
+Draw tolerance shape_name [min [max] [symbol]]
+is used. It outputs maximum, average and minimum values of tolerances for each kind of subshapes having tolerances or it can output tolerances of all subshapes of the whole shape.
+When specifying min and max arguments this command outputs shapes with names shape_name_... and their total number with tolerances in the range [min, max].
+Symbol is used for specifying the kind of sub-shapes to analyze: v - for vertices, e - for edges, f - for faces, c - for shells and faces.
+@subsection occt_1856844696_7225239155 Writing an IGES file
+For a description of parameters used in reading an IGES file refer to 3.3.2 Setting the translation parameters.
+These parameters are set by command **param**:
+
+
+Several shapes can be written in one file. To start writing a new file, enter command
+Draw newmodel
+Actually, command **newmodel** will clear the InterfaceModel to make it empty, and the next command will convert the specified shapes to IGES entities and put them into the InterfaceModel:
+Draw brepiges shape_name_1 [filename.igs]
+To write the prepared model to a file with name **filename.igs**, enter
+Draw writeall filename.igs
+@subsection occt_1856844696_7225239156 Index of useful commands
+
+
+
+
+@section occt_1856844696_332489123 Reading from and writing to XDE
+@subsection occt_1856844696_3324891231 Description of the process
+@subsubsection occt_1856844696_33248912311 Loading an IGES file
+Before performing any other operation, you must load an IGES file with:
+IGESCAFControl_Reader reader(XSDRAW::Session(), Standard_False);
+IFSelect_ReturnStatus stat = reader.ReadFile(“filename.igs”);
+Loading the file only memorizes, but does not translate the data.
+@subsubsection occt_1856844696_33248912312 Checking the loaded IGES file
+This step is not obligatory. See the description of this step below in paragraph 2.3.2.
+@subsubsection occt_1856844696_33248912313 Setting parameters for translation to XDE
+See the description of this step below in paragraph 2.3.3.
+In addition, the following parameters can be set for XDE translation of attributes:
+• Parameter for transferring colors:
+reader.SetColorMode(mode);
+// mode can be Standard_True or Standard_False
+• Parameter for transferring names:
+reader.SetNameMode(mode);
+// mode can be Standard_True or Standard_False
+@subsubsection occt_1856844696_33248912314 Performing the translation of an IGES file to XDE
+The following function performs a translation of the whole document:
+Standard_Boolean ok = reader.Transfer(doc);
+where ;doc; is a variable which contains a handle to the output document and should have a type Handle(TDocStd_Document).
+@subsubsection occt_1856844696_33248912315 Initializing the process of translation from XDE to IGES
+Here is how the process is initialized:
+IGESCAFControl_Writer aWriter(XSDRAW::Session(),Standard_False);
+@subsubsection occt_1856844696_33248912316 Setting parameters for translation from XDE to IGES
+The following parameters can be set for translation of attributes to IGES:
+• Parameter for transferring colors:
+aWriter.SetColorMode(mode);
+// mode can be Standard_True or Standard_False
+• Parameter for transferring names:
+aWriter.SetNameMode(mode);
+// mode can be Standard_True or Standard_False
+@subsubsection occt_1856844696_33248912317 Performing the translation of an XDE document to IGES
+You can perform the translation of a document by calling the function:
+IFSelect_ReturnStatus aRetSt = aWriter.Transfer(doc);
+where ;doc; is a variable which contains a handle to the input document for transferring and should have a type Handle(TDocStd_Document).
+@subsubsection occt_1856844696_33248912318 Writing an IGES file
+Write an IGES file with:
+IFSelect_ReturnStatus statw = aWriter.WriteFile(;filename.igs;);
+or
+IFSelect_ReturnStatus statw = writer.WriteFile (S);
+where S is OStream
+
+
--- /dev/null
+Modeling Algorithms {#user_guides__modeling_algos}
+=========================
+
+@section occt_modalg_1 Introduction
+
+@subsection occt_modalg_1_1 The Modeling Algorithms Module
+
+
+This manual explains how to use the Modeling Algorithms. It provides basic documentation on modeling algorithms. For advanced information on Modeling Algorithms, see our offerings on our web site at <a href="http://www.opencascade.org/support/training/">www.opencascade.org/support/training/</a>
+
+The Modeling Algorithms module brings together a wide range of topological algorithms used in modeling. Along with these tools, you will find the geometric algorithms, which they call.
+
+The algorithms available are divided into:
+ * Geometric tools
+ * Topological tools
+ * The Topology API
+
+@subsection occt_modalg_1_2 The Topology API
+
+The Topology API of Open CASCADE Technology (**OCCT**) includes the following six packages:
+
+ * BRepAlgoAPI
+ * BRepBuilderAPI
+ * BRepFilletAPI
+ * BRepFeat
+ * BRepOffsetAPI
+ * BRepPrimAPI
+
+The classes in these six packages provide the user with a simple and powerful interface.
+ * A simple interface: a function call works ideally,
+ * A powerful interface: including error handling and access to extra information provided by the algorithms.
+
+As an example, the class BRepBuilderAPI_MakeEdge can be used to create a linear edge from two points.
+
+~~~~~
+gp_Pnt P1(10,0,0), P2(20,0,0);
+TopoDS_Edge E = BRepBuilderAPI_MakeEdge(P1,P2);
+~~~~~
+
+This is the simplest way to create edge E from two points P1, P2, but the developer can test for errors when he is not as confident of the data as in the previous example.
+
+~~~~~
+#include <gp_Pnt.hxx>
+#include <TopoDS_Edge.hxx>
+#include <BRepBuilderAPI_MakeEdge.hxx>
+void EdgeTest()
+{
+gp_Pnt P1;
+gp_Pnt P2;
+BRepBuilderAPI_MakeEdge ME(P1,P2);
+if (!ME.IsDone())
+{
+// doing ME.Edge() or E = ME here
+// would raise StdFail_NotDone
+Standard_DomainError::Raise
+(“ProcessPoints::Failed to createan edge”);
+}
+TopoDS_Edge E = ME;
+}
+~~~~~
+
+In this example an intermediary object ME has been introduced. This can be tested for the completion of the function before accessing the result. More information on **error handling** in the topology programming interface can be found in the next section.
+
+BRepBuilderAPI_MakeEdge provides valuable information. For example, when creating an edge from two points, two vertices have to be created from the points. Sometimes you may be interested in getting these vertices quickly without exploring the new edge. Such information can be provided when using a class. The following example shows a function creating an edge and two vertices from two points.
+
+~~~~~
+void MakeEdgeAndVertices(const gp_Pnt& P1,
+const gp_Pnt& P2,
+TopoDS_Edge& E,
+TopoDS_Vertex& V1,
+TopoDS_Vertex& V2)
+{
+BRepBuilderAPI_MakeEdge ME(P1,P2);
+if (!ME.IsDone()) {
+Standard_DomainError::Raise
+(“MakeEdgeAndVerices::Failed to create an edge”);
+}
+E = ME;
+V1 = ME.Vextex1();
+V2 = ME.Vertex2();
+~~~~~
+
+The BRepBuilderAPI_MakeEdge class provides the two methods Vertex1 and Vertex2, which return the two vertices used to create the edge.
+
+How can BRepBuilderAPI_MakeEdge be both a function and a class? It can do this because it uses the casting capabilities of C++. The BRepBuilderAPI_MakeEdge class has a method called Edge; in the previous example the line E = ME could have been written.
+
+~~~~~
+E = ME.Edge();
+~~~~~
+
+This instruction tells the C++ compiler that there is an **implicit casting **of a BRepBuilderAPI_MakeEdge into a TopoDS_Edge using the Edge method. It means this method is automatically called when a BRepBuilderAPI_MakeEdge is found where a TopoDS_Edge is required.
+
+This feature allows you to provide classes, which have the simplicity of function calls when required and the power of classes when advanced processing is necessary. All the benefits of this approach are explained when describing the topology programming interface classes.
+
+
+@subsubsection occt_modalg_1_2_1 Error Handling in the Topology API
+
+A method can report an error in the two following situations:
+ * The data or arguments of the method are incorrect, i.e. they do not respect the restrictions specified by the methods in its specifications. Typical example: creating a linear edge from two identical points is likely to lead to a zero divide when computing the direction of the line.
+ * Something unexpected happened. This situation covers every error not included in the first category. Including: interruption, programming errors in the method or in another method called by the first method, bad specifications of the arguments (i.e. a set of arguments that was not expected to fail).
+
+The second situation is supposed to become increasingly exceptional as a system is debugged and it is handled by the **exception mechanism**. Using exceptions avoids handling error statuses in the call to a method: a very cumbersome style of programming.
+
+In the first situation, an exception is also supposed to be raised because the calling method should have verified the arguments and if it did not do so, there is a bug. For example if before calling MakeEdge you are not sure that the two points are non-identical, this situation must be tested.
+
+Making those validity checks on the arguments can be tedious to program and frustrating as you have probably correctly surmised that the method will perform the test twice. It does not trust you.
+As the test involves a great deal of computation, performing it twice is also time-consuming.
+
+Consequently, you might be tempted to adopt the *highly inadvisable *style of programming illustrated in the following example:
+
+~~~~~
+#include <Standard_ErrorHandler.hxx>
+try {
+TopoDS_Edge E = BRepBuilderAPI_MakeEdge(P1,P2);
+// go on with the edge
+}
+catch {
+// process the error.
+}
+~~~~~
+
+To help the user, the Topology API classes only raise the exception **StdFail_NotDone**. Any other exception means that something happened which was unforeseen in the design of this API.
+
+The **NotDone **exception is only raised when the user tries to access the result of the computation and the original data is corrupted. At the construction of the class instance, if the algorithm cannot be completed, the internal flag NotDone is set. This flag can be tested and in some situations a more complete description of the error can be queried. If the user ignores the NotDone status and tries to access the result, an exception is raised.
+
+~~~~~
+BRepBuilderAPI_MakeEdge ME(P1,P2);
+if (!ME.IsDone()) {
+// doing ME.Edge() or E = ME here
+// would raise StdFail_NotDone
+Standard_DomainError::Raise
+(“ProcessPoints::Failed to create an edge”);
+}
+TopoDS_Edge E = ME;
+~~~~~
+
+@section occt_modalg_2 Geometric Tools
+
+@subsection occt_modalg_2_1 Overview
+
+Open CASCADE Technology geometric tools include:
+
+ * Computation of intersections
+ * Interpolation laws
+ * Computation of curves and surfaces from constraints
+ * Computation of lines and circles from constraints
+ * Projections
+
+@subsection occt_modalg_2_2 Intersections
+
+The *Geom2dAPI_InterCurveCurve *class allows the evaluation of the intersection points (*gp_Pnt2d*) between two geometric curves (*Geom2d_Curve*)* *and the evaluation of the points of self-intersection of a curve.
+
+
+
+In both cases, the algorithm requires a value for the tolerance (Standard_Real) for the confusion between two points. The default tolerance value used in all constructors is *1.0e-6.*
+
+
+
+The algorithm returns a point in the case of an intersection and a segment in the case of tangent intersection.
+
+@subsubsection occt_modalg_2_2_1 Geom2dAPI_InterCurveCurve
+
+This class may be instantiated either for intersection of curves C1 and C2.
+~~~~~
+Geom2dAPI_InterCurveCurve Intersector(C1,C2,tolerance);
+~~~~~
+
+or for self-intersection of curve C3.
+~~~~~
+Geom2dAPI_InterCurveCurve Intersector(C3,tolerance);
+~~~~~
+
+~~~~~
+Standard_Integer N = Intersector.NbPoints();
+~~~~~
+Calls the number of intersection points
+
+To select the desired intersection point, pass an integer index value in argument.
+~~~~~
+gp_Pnt2d P = Intersector.Point(Index);
+~~~~~
+
+~~~~~
+Standard_Integer M = Intersector.NbSegments();
+~~~~~
+
+Calls the number of intersection segments.
+
+To select the desired intersection segment pass integer index values in argument.
+~~~~~
+Handle(Geom2d_Curve) Seg1, Seg2;
+Intersector.Segment(Index,Seg1,Seg2);
+// if intersection of 2 curves
+Intersector.Segment(Index,Seg1);
+// if self-intersection of a curve
+~~~~~
+
+If you need access to a wider range of functionalities the following method will return the algorithmic object for the calculation of intersections:
+
+~~~~~
+Geom2dInt_GInter& TheIntersector = Intersector.Intersector();
+~~~~~
+
+@subsubsection occt_modalg_2_2_2 Intersection of Curves and Surfaces
+The *GeomAPI_IntCS *class is used to compute the intersection points between a curve and a surface.
+
+This class is instantiated as follows:
+~~~~~
+GeomAPI_IntCS Intersector(C, S);
+~~~~~
+
+~~~~~
+Standard_Integer nb = Intersector.NbPoints();
+~~~~~
+Calls the number of intersection points.
+
+~~~~~
+gp_Pnt& P = Intersector.Point(Index);
+~~~~~
+
+Where *Index *is an integer between *1 *and *nb*, calls the intersection points.
+
+@subsubsection occt_modalg_2_2_3 Intersection of two Surfaces
+The *GeomAPI_IntSS *class is used to compute the intersection of two surfaces from *Geom_Surface *with respect to a given tolerance.
+
+This class is instantiated as follows:
+~~~~~
+GeomAPI_IntSS Intersector(S1, S2, Tolerance);
+~~~~~
+Once the *GeomAPI_IntSS *object has been created, it can be interpreted.
+
+~~~~~
+Standard_Integer nb = Intersector. NbLines();
+~~~~~
+Calls the number of intersection curves.
+
+~~~~~
+Handle(Geom_Curve) C = Intersector.Line(Index)
+~~~~~
+Where *Index *is an integer between *1 *and *nb*, calls the intersection curves.
+
+@subsection occt_modalg_2_3 Interpolations
+*Interpolation* provides functionalities for interpolating BSpline curves, whether in 2D, using *Geom2dAPI_Interpolate*, or 3D using *GeomAPI_Interpolate*.
+
+
+@subsubsection occt_modalg_2_3_1 Geom2dAPI_Interpolate
+This class is used to interpolate a BSplineCurve passing through an array of points. If tangency is not requested at the point of interpolation, continuity will be *C2 *. If tangency is requested at the point, continuity will be *C1*. If Periodicity is requested, the curve will be closed and the junction will be the first point given. The curve will then have a continuity of *C1* only.
+This class may be instantiated as follows:
+~~~~~
+Geom2dAPI_Interpolate
+(const Handle_TColgp_HArray1OfPnt2d& Points,
+const Standard_Boolean PeriodicFlag,
+const Standard_Real Tolerance);
+
+Geom2dAPI_Interpolate Interp(Points, Standard_False,
+ Precision::Confusion());
+~~~~~
+
+
+It is possible to call the BSpline curve from the object defined above it.
+~~~~~
+Handle(Geom2d_BSplineCurve) C = Interp.Curve();
+~~~~~
+
+Note that the *Handle(Geom2d_BSplineCurve)* operator has been redefined by the method Curve(). Consequently, it is unnecessary to pass via the construction of an intermediate object of the *Geom2dAPI_Interpolate *type and the following syntax is correct.
+
+~~~~~
+Handle(Geom2d_BSplineCurve) C =
+Geom2dAPI_Interpolate(Points,
+ Standard_False,
+ Precision::Confusion());
+~~~~~
+
+@subsubsection occt_modalg_2_3_2 GeomAPI_Interpolate
+
+This class may be instantiated as follows:
+~~~~~
+GeomAPI_Interpolate
+(const Handle_TColgp_HArray1OfPnt& Points,
+const Standard_Boolean PeriodicFlag,
+const Standard_Real Tolerance);
+
+GeomAPI_Interpolate Interp(Points, Standard_False,
+ Precision::Confusion());
+~~~~~
+
+It is possible to call the BSpline curve from the object defined above it.
+~~~~~
+Handle(Geom_BSplineCurve) C = Interp.Curve();
+~~~~~
+Note that the *Handle(Geom_BSplineCurve)* operator has been redefined by the method Curve(). Thus, it is unnecessary to pass via the construction of an intermediate object of the GeomAPI_Interpolate type and the following syntax is correct.
+
+Handle(Geom_BSplineCurve) C =
+ GeomAPI_Interpolate(Points,
+ Standard_False,
+ 1.0e-7);
+
+Boundary conditions may be imposed with the method Load.
+~~~~~
+GeomAPI_Interpolate AnInterpolator
+(Points, Standard_False, 1.0e-5);
+AnInterpolator.Load (StartingTangent, EndingTangent);
+~~~~~
+
+@subsection occt_modalg_2_4 Lines and Circles from Constraints
+
+There are two packages to create lines and circles from constraints: *Geom2dGcc *and *GccAna*. *Geom2dGcc* deals with reference-handled geometric objects from the *Geom2d *package while *GccAna* deals with value-handled geometric objects from the *gp* package.
+
+The *Geom2dGcc* package solves geometric constructions of lines and circles expressed by constraints such as tangency or parallelism, that is, a constraint expressed in geometric terms. As a simple example the following figure shows a line which is constrained to pass through a point and be tangent to a circle.
+
+
+
+The *Geom2dGcc *package focuses on algorithms; it is useful for finding results, but it does not offer any management or modification functions, which could be applied to the constraints or their arguments. This package is designed to offer optimum performance, both in rapidity and precision. Trivial cases (for example, a circle centered on one point and passing through another) are not treated.
+
+The *Geom2dGcc *package deals only with 2d objects from the *Geom2d *package. These objects are the points, lines and circles available.
+
+All other lines such as Bezier curves and conic sections - with the exception of circles -are considered general curves and must be differentiable twice.
+
+The *GccAna *package deals with points, lines, and circles from the *gp *package. Apart from constructors for lines and circles, it also allows the creation of conics from the bisection of other geometric objects.
+
+@subsection occt_modalg_2_5 Provided algorithms
+
+The following analytic algorithms using value-handled entities for creation of 2D lines or circles with geometric constraints are available:
+
+ * circle tangent to three elements (lines, circles, curves, points),
+ * circle tangent to two elements and having a radius,
+ * circle tangent to two elements and centered on a third element,
+ * circle tangent to two elements and centered on a point,
+ * circle tangent to one element and centered on a second,
+ * bisector of two points,
+ * bisector of two lines,
+ * bisector of two circles,
+ * bisector of a line and a point,
+ * bisector of a circle and a point,
+ * bisector of a line and a circle,
+ * line tangent to two elements (points, circles, curves),
+ * line tangent to one element and parallel to a line,
+ * line tangent to one element and perpendicular to a line,
+ * line tangent to one element and forming angle with a line.
+
+@subsection occt_modalg_2_6 Types of algorithms
+There are three categories of available algorithms, which complement each other:
+ * analytic,
+ * geometric,
+ * iterative.
+
+An analytic algorithm will solve a system of equations, whereas a geometric algorithm works with notions of parallelism, tangency, intersection and so on.
+
+Both methods can provide solutions. An iterative algorithm, however, seeks to refine an approximate solution.
+
+@subsection occt_modalg_2_7 Performance factors
+
+The appropriate algorithm is the one, which reaches a solution of the required accuracy in the least time. Only the solutions actually requested by the user should be calculated. A simple means to reduce the number of solutions is the notion of a "qualifier". There are four qualifiers, which are:
+
+ * Unqualified: the position of the solution is undefined with respect to this argument.
+ * Enclosing: the solution encompasses this argument.
+ * Enclosed: the solution is encompassed by this argument.
+ * Outside: the solution and argument are outside each other.
+
+
+@subsection occt_modalg_2_8 Conventions
+
+@subsubsection occt_modalg_2_8_1 Exterior/Interior
+It is not hard to define the interior and exterior of a circle. As is shown in the following diagram, the exterior is indicated by the sense of the binormal, that is to say the right side according to the sense of traversing the circle. The left side is therefore the interior (or "material").
+
+
+
+By extension, the interior of a line or any open curve is defined as the left side according to the passing direction, as shown in the following diagram:
+
+
+
+@subsubsection occt_modalg_2_8_2 Orientation of a Line
+It is sometimes necessary to define in advance the sense of travel along a line to be created. This sense will be from first to second argument.
+
+The following figure shows a line, which is first tangent to circle C1 which is interior to the line, and then passes through point P1.
+
+
+
+@subsection occt_modalg_2_9 Examples
+
+@subsubsection occt_modalg_2_9_1 Line tangent to two circles
+The following four diagrams illustrate four cases of using qualifiers in the creation of a line. The fifth shows the solution if no qualifiers are given.
+
+Note that the qualifier "Outside" is used to mean "Mutually exterior".
+
+**Example 1 Case 1**
+
+
+
+Constraints:
+Tangent and Exterior to C1.
+Tangent and Exterior to C2.
+
+Syntax:
+
+~~~~~
+GccAna_Lin2d2Tan
+ Solver(GccEnt::Outside(C1),
+ GccEnt::Outside(C2),
+ Tolerance);
+~~~~~
+
+**Example 1 Case 2**
+
+
+
+Constraints:
+Tangent and Including C1.
+Tangent and Including C2.
+
+Syntax:
+
+~~~~~
+GccAna_Lin2d2Tan
+ Solver(GccEnt::Enclosing(C1),
+ GccEnt::Enclosing(C2),
+ Tolerance);
+~~~~~
+
+**Example 1 Case 3**
+
+
+
+Constraints:
+Tangent and Including C1.
+Tangent and Exterior to C2.
+
+Syntax:
+~~~~~
+GccAna_Lin2d2Tan
+ Solver(GccEnt::Enclosing(C1),
+ GccEnt::Outside(C2),
+ Tolerance);
+~~~~~
+
+**Example 1 Case 4**
+
+
+Constraints:
+Tangent and Exterior to C1.
+Tangent and Including C2.
+
+Syntax:
+~~~~~
+GccAna_Lin2d2Tan
+ Solver(GccEnt::Outside(C1),
+ GccEnt::Enclosing(C2),
+ Tolerance);
+~~~~~
+
+**Example 1 Case 5**
+
+
+
+Constraints:
+Tangent and Undefined with respect to C1.
+Tangent and Undefined with respect to C2.
+
+Syntax:
+~~~~~
+GccAna_Lin2d2Tan
+ Solver(GccEnt::Unqualified(C1),
+ GccEnt::Unqualified(C2),
+ Tolerance);
+~~~~~
+
+@subsubsection occt_modalg_2_9_2 Circle of given radius tangent to two circles
+The following four diagrams show the four cases in using qualifiers in the creation of a circle.
+
+**Example 2 Case 1**
+
+
+Constraints:
+Tangent and Exterior to C1.
+Tangent and Exterior to C2.
+
+Syntax:
+~~~~~
+GccAna_Circ2d2TanRad
+ Solver(GccEnt::Outside(C1),
+ GccEnt::Outside(C2), Rad, Tolerance);
+~~~~~
+
+**Example 2 Case 2**
+
+
+
+Constraints:
+Tangent and Exterior to C1.
+Tangent and Included by C2.
+
+Syntax:
+~~~~~
+GccAna_Circ2d2TanRad
+ Solver(GccEnt::Outside(C1),
+ GccEnt::Enclosed(C2), Rad, Tolerance);
+~~~~~
+
+**Example 2 Case 3**
+
+
+Constraints:
+Tangent and Exterior to C1.
+Tangent and Including C2.
+
+Syntax:
+~~~~~
+GccAna_Circ2d2TanRad
+ Solver(GccEnt::Outside(C1),
+ GccEnt::Enclosing(C2), Rad, Tolerance);
+~~~~~
+
+**Example 2 Case 4**
+
+
+Constraints:
+Tangent and Enclosing C1.
+Tangent and Enclosing C2.
+
+Syntax:
+~~~~~
+GccAna_Circ2d2TanRad
+ Solver(GccEnt::Enclosing(C1),
+ GccEnt::Enclosing(C2), Rad, Tolerance);
+~~~~~
+
+**Example 2 Case 5**
+The following syntax will give all the circles of radius *Rad, *which are tangent to *C1 *and *C2 *without discrimination of relative position:
+
+~~~~~
+GccAna_Circ2d2TanRad Solver(GccEnt::Unqualified(C1),
+ GccEnt::Unqualified(C2),
+ Rad,Tolerance);
+~~~~~
+
+@subsection occt_modalg_2_10 Algorithms
+
+The objects created by this toolkit are non-persistent.
+
+@subsubsection occt_modalg_2_10_1 Qualifiers
+The *GccEnt* package contains the following package methods:
+ * Unqualified,
+ * Enclosing,
+ * Enclosed,
+ * Outside.
+
+This enables creation of expressions, for example:
+~~~~~
+GccAna_Circ2d2TanRad
+ Solver(GccEnt::Outside(C1),
+ GccEnt::Enclosing(C2), Rad, Tolerance);
+~~~~~
+
+The objective in this case is to find all circles of radius *Rad*, which are tangent to both circle *C1* and *C2*, C1 being outside and C2 being inside.
+
+@subsubsection occt_modalg_2_10_2 General Remarks about Algorithms
+
+We consider the following to be the case:
+ * If a circle passes through a point then the circle is tangential to it.
+ * A distinction is made between the trivial case of the center at a point and the complex case of the center on a line.
+
+@subsubsection occt_modalg_2_10_3 Analytic Algorithms
+GccAna package implements analytic algorithms. It deals only with points, lines, and circles from gp package. Here is a list of the services offered:
+
+Creation of a Line
+------------------
+
+~~~~~
+Tangent ( point | circle ) & Parallel ( line )
+Tangent ( point | circle ) & Perpendicular ( line | circle )
+Tangent ( point | circle ) & Oblique ( line )
+Tangent ( 2 { point | circle } )
+Bisector( line | line )
+~~~~~
+
+Creation of Conics
+------------------
+
+~~~~~
+Bisector ( point | point )
+Bisector ( line | point )
+Bisector ( circle | point )
+Bisector ( line | line )
+Bisector ( circle | line )
+Bisector ( circle | circle )
+~~~~~
+
+Creation of a Circle
+--------------------
+~~~~~
+Tangent ( point | line | circle ) & Center ( point )
+Tangent ( 3 { point | line | circle } )
+Tangent ( 2 { point | line | circle } ) & Radius ( real )
+Tangent ( 2 { point | line | circle } ) & Center ( line | circle )
+Tangent ( point | line | circle ) & Center ( line | circle ) & Radius ( real )
+~~~~~
+
+For each algorithm, the tolerance (and angular tolerance if appropriate) is given as an argument. Calculation is done with the highest precision available from the hardware.
+
+@subsubsection occt_modalg_2_10_4 Geometric Algorithms
+
+*Geom2dGcc *package offers algorithms, which produce 2d lines or circles with geometric constraints. For arguments, it takes curves for which an approximate solution is not requested. A tolerance value on the result is given as a starting parameter. The following services are provided:
+
+Creation of a Circle
+--------------------
+
+~~~~~
+Tangent ( curve ) & Center ( point )
+Tangent ( curve , point | line | circle | curve ) & Radius ( real )
+Tangent ( 2 {point | line | circle} ) & Center ( curve )
+Tangent ( curve ) & Center ( line | circle | curve ) & Radius ( real )
+Tangent ( point | line | circle ) & Center ( curve ) & Radius ( real )
+~~~~~
+
+All calculations will be done to the highest precision available from the hardware.
+
+@subsubsection occt_modalg_2_10_5 Iterative Algorithms
+Geom2dGcc package offers iterative algorithms find a solution by refining an approximate solution. It produces 2d lines or circles with geometric constraints. For all geometric arguments except points, an approximate solution may be given as a starting parameter. The tolerance or angular tolerance value is given as an argument. The following services are provided:
+
+Creation of a Line
+------------------
+~~~~~
+Tangent ( curve ) & Oblique ( line )
+Tangent ( curve , { point | circle | curve } )
+~~~~~
+
+Creation of a Circle
+--------------------
+
+~~~~~
+Tangent ( curve , 2 { point | circle | curve } )
+Tangent ( curve , { point | circle | curve } )
+& Center ( line | circle | curve )
+~~~~~
+
+@subsection occt_modalg_2_1 Curves and Surfaces from Constraints
+
+@subsubsection occt_modalg_2_1_1 Fair Curve
+
+*FairCurve* package provides a set of classes to create faired 2D curves or 2D curves with minimal variation in curvature.
+
+Creation of Batten Curves
+-------------------------
+The class Batten allows producing faired curves defined on the basis of one or more constraints on each of the two reference points. These include point, angle of tangency and curvature settings.
+The following constraint orders are available:
+
+ * 0 the curve must pass through a point
+ * 1 the curve must pass through a point and have a given tangent
+ * 2 the curve must pass through a point, have a given tangent and a given curvature.
+
+Only 0 and 1 constraint orders are used.
+The function Curve returns the result as a 2D BSpline curve.
+
+Creation of Minimal Variation Curves
+------------------------------------
+The class MinimalVariation allow producing curves with minimal variation in curvature at each reference point. The following constraint orders are available:
+
+ * 0 the curve must pass through a point
+ * 1 the curve must pass through a point and have a given tangent
+ * 2 the curve must pass through a point, have a given tangent and a given curvature.
+
+Constraint orders of 0, 1 and 2 can be used. The algorithm minimizes tension, sagging and jerk energy.
+
+The function *Curve* returns the result as a 2D BSpline curve.
+
+Specifying the length of the curve
+----------------------------------
+If you want to give a specific length to a batten curve, use:
+
+~~~~~
+b.SetSlidingFactor(L / b.SlidingOfReference())
+~~~~~
+where *b* is the name of the batten curve object
+
+Limitations
+-----------
+Free sliding is generally more aesthetically pleasing than constrained sliding.
+However, the computation can fail with values such as angles greater than p/2, because in this case, the length is theoretically infinite.
+
+In other cases, when sliding is imposed and the sliding factor is too large, the batten can collapse.
+
+Computation Time
+----------------
+The constructor parameters, *Tolerance* and *NbIterations*, control how precise the computation is, and how long it will take.
+
+@subsubsection occt_modalg_2_11_2 Surfaces from Boundary Curves
+
+The *GeomFill* package provides the following services for creating surfaces from boundary curves:
+
+Creation of Bezier surfaces
+---------------------------
+The class *BezierCurves* allows producing a Bezier surface from contiguous Bezier curves. Note that problems may occur with rational Bezier Curves.
+
+Creation of BSpline surfaces
+----------------------------
+The class *BSplineCurves* allows producing a BSpline surface from contiguous BSpline curves. Note that problems may occur with rational BSplines.
+
+Creation of a Pipe
+------------------
+The class *Pipe* allows you producing a pipe by sweeping a curve (the section) along another curve (the path). The result is a BSpline surface.
+
+Filling a contour
+----------------
+The class *GeomFill_ConstrainedFilling* allows filling a contour defined by two, three or four curves as well as by tangency constraints. The resulting surface is a BSpline.
+
+Creation of a Boundary
+----------------------
+The class *GeomFill_SimpleBound* allows you defining a boundary for the surface to be constructed.
+
+Creation of a Boundary with an adjoining surface
+------------------------------------------------
+The class *GeomFill_BoundWithSurf* allows defining a boundary for the surface to be constructed. This boundary will already be joined to another surface.
+
+Filling styles
+--------------
+The enumerations *FillingStyle* specify the styles used to build the surface. These include:
+
+ * *Stretch* - the style with the flattest patches
+ * *Coons* - a rounded style with less depth than *Curved*
+ * *Curved* - the style with the most rounded patches.
+
+![](/user_guides/modeling_algos/images/modeling_algos_image018.jpg "Intersecting filleted edges with different radii leave a gap, is filled by a surface)
+
+
+@subsubsection occt_modalg_2_11_3 Surfaces from curve and point constraints
+The *GeomPlate* package provides the following services for creating surfaces respecting curve and point constraints:
+
+Definition of a Framework
+-------------------------
+The class *BuildPlateSurface* allows creating a framework to build surfaces according to curve and point constraints as well as tolerance settings. The result is returned with the function *Surface*.
+
+Note that you do not have to specify an initial surface at the time of construction. It can be added later or, if none is loaded, a surface will be computed automatically.
+
+Definition of a Curve Constraint
+--------------------------------
+The class *CurveConstraint* allows defining curves as constraints to the surface, which you want to build.
+
+Definition of a Point Constraint
+--------------------------------
+The class *PointConstraint* allows defining points as constraints to the surface, which you want to build.
+
+Applying Geom_Surface to Plate Surfaces
+--------------------------------------
+The class *Surface* allows describing the characteristics of plate surface objects returned by **BuildPlateSurface::Surface** using the methods of *Geom_Surface*
+
+Approximating a Plate surface to a BSpline
+------------------------------------------
+The class *MakeApprox* allows converting a *GeomPlate* surface into a *Geom_BSplineSurface*.
+
+
+
+**Example**
+
+Create a Plate surface and approximate it from a polyline as a curve constraint and a point constraint
+
+~~~~~
+Standard_Integer NbCurFront=4,
+NbPointConstraint=1;
+gp_Pnt P1(0.,0.,0.);
+gp_Pnt P2(0.,10.,0.);
+gp_Pnt P3(0.,10.,10.);
+gp_Pnt P4(0.,0.,10.);
+gp_Pnt P5(5.,5.,5.);
+BRepBuilderAPI_MakePolygon W;
+W.Add(P1);
+W.Add(P2);
+W.Add(P3);
+W.Add(P4);
+W.Add(P1);
+// Initialize a BuildPlateSurface
+GeomPlate_BuildPlateSurface BPSurf(3,15,2);
+// Create the curve constraints
+BRepTools_WireExplorer anExp;
+for(anExp.Init(W); anExp.More(); anExp.Next())
+{
+TopoDS_Edge E = anExp.Current();
+Handle(BRepAdaptor_HCurve) C = new
+BRepAdaptor_HCurve();
+C-ChangeCurve().Initialize(E);
+Handle(BRepFill_CurveConstraint) Cont= new
+BRepFill_CurveConstraint(C,0);
+BPSurf.Add(Cont);
+}
+// Point constraint
+Handle(GeomPlate_PointConstraint) PCont= new
+GeomPlate_PointConstraint(P5,0);
+BPSurf.Add(PCont);
+// Compute the Plate surface
+BPSurf.Perform();
+// Approximation of the Plate surface
+Standard_Integer MaxSeg=9;
+Standard_Integer MaxDegree=8;
+Standard_Integer CritOrder=0;
+Standard_Real dmax,Tol;
+Handle(GeomPlate_Surface) PSurf = BPSurf.Surface();
+dmax = Max(0.0001,10*BPSurf.G0Error());
+Tol=0.0001;
+GeomPlate_MakeApprox
+Mapp(PSurf,Tol,MaxSeg,MaxDegree,dmax,CritOrder);
+Handle (Geom_Surface) Surf (Mapp.Surface());
+// create a face corresponding to the approximated Plate
+Surface
+Standard_Real Umin, Umax, Vmin, Vmax;
+PSurf-Bounds( Umin, Umax, Vmin, Vmax);
+BRepBuilderAPI_MakeFace MF(Surf,Umin, Umax, Vmin, Vmax);
+~~~~~
+
+@subsection occt_modalg_2_12 Projections
+This package provides functionality for projecting points onto 2D and 3D curves and surfaces.
+
+@subsubsection occt_modalg_2_12_1 Projection of a Point onto a Curve
+*Geom2dAPI_ProjectPointOnCurve* allows calculation of all the normals projected from a point (*gp_Pnt2d*) onto a geometric curve (*Geom2d_Curve*). The calculation may be restricted to a given domain.
+
+
+
+
+Note
+----
+The curve does not have to be a *Geom2d_TrimmedCurve*. The algorithm will function with any
+class inheriting Geom2d_Curve.
+
+@subsubsection occt_modalg_2_12_2 Geom2dAPI_ProjectPointOnCurve
+This class may be instantiated as in the following example:
+
+~~~~~
+gp_Pnt2d P;
+Handle(Geom2d_BezierCurve) C =
+ new Geom2d_BezierCurve(args);
+Geom2dAPI_ProjectPointOnCurve Projector (P, C);
+~~~~~
+
+To restrict the search for normals to a given domain *[U1,U2]*, use the following constructor:
+~~~~~
+Geom2dAPI_ProjectPointOnCurve Projector (P, C, U1, U2);
+~~~~~
+Having thus created the *Geom2dAPI_ProjectPointOnCurve* object, we can now interrogate it.
+
+Calling the number of solution points
+-------------------------------------
+~~~~~
+Standard_Integer NumSolutions = Projector.NbPoints();
+~~~~~
+
+Calling the location of a solution point
+----------------------------------------
+The solutions are indexed in a range from *1* to *Projector.NbPoints()*. The point, which corresponds to a given *Index* may be found:
+~~~~~
+gp_Pnt2d Pn = Projector.Point(Index);
+~~~~~
+
+Calling the parameter of a solution point
+-----------------------------------------
+For a given point corresponding to a given *Index*:
+
+~~~~~
+Standard_Real U = Projector.Parameter(Index);
+~~~~~
+
+This can also be programmed as:
+
+~~~~~
+Standard_Real U;
+Projector.Parameter(Index,U);
+~~~~~
+
+Calling the distance between the start and end points
+-----------------------------------------------------
+We can find the distance between the initial point and a point, which corresponds to the given *Index*:
+
+~~~~~
+Standard_Real D = Projector.Distance(Index);
+~~~~~
+
+Calling the nearest solution point
+---------------------------------
+
+This class offers a method to return the closest solution point to the starting point. This solution is accessed as follows:
+~~~~~
+gp_Pnt2d P1 = Projector.NearestPoint();
+~~~~~
+
+Calling the parameter of the nearest solution point
+---------------------------------------------------
+~~~~~
+Standard_Real U = Projector.LowerDistanceParameter();
+~~~~~
+
+Calling the minimum distance from the point to the curve
+-------------------------------------------------------
+~~~~~
+Standard_Real D = Projector.LowerDistance();
+~~~~~
+
+@subsubsection occt_modalg_2_12_3 Redefined operators
+
+Some operators have been redefined to find the closest solution.
+
+*Standard_Real()* returns the minimum distance from the point to the curve.
+
+~~~~~
+Standard_Real D = Geom2dAPI_ProjectPointOnCurve (P,C);
+~~~~~
+
+*Standard_Integer()* returns the number of solutions.
+
+~~~~~
+Standard_Integer N =
+Geom2dAPI_ProjectPointOnCurve (P,C);
+~~~~~
+
+*gp_Pnt2d()* returns the nearest solution point.
+
+~~~~~
+gp_Pnt2d P1 = Geom2dAPI_ProjectPointOnCurve (P,C);
+~~~~~
+
+Using these operators makes coding easier when you only need the nearest point. Thus:
+~~~~~
+Geom2dAPI_ProjectPointOnCurve Projector (P, C);
+gp_Pnt2d P1 = Projector.NearestPoint();
+~~~~~
+can be written more concisely as:
+~~~~~
+gp_Pnt2d P1 = Geom2dAPI_ProjectPointOnCurve (P,C);
+~~~~~
+However, note that in this second case no intermediate *Geom2dAPI_ProjectPointOnCurve* object is created, and thus it is impossible to have access to other solution points.
+
+
+@subsubsection occt_modalg_2_12_4 Access to lower-level functionalities
+
+If you want to use the wider range of functionalities available from the *Extrema* package, a call to the *Extrema()* method will return the algorithmic object for calculating extrema. For example:
+
+~~~~~
+Extrema_ExtPC2d& TheExtrema = Projector.Extrema();
+~~~~~
+
+@subsubsection occt_modalg_2_12_5 GeomAPI_ProjectPointOnCurve
+
+This class is instantiated as in the following example:
+~~~~~
+gp_Pnt P;
+Handle(Geom_BezierCurve) C =
+ new Geom_BezierCurve(args);
+GeomAPI_ProjectPointOnCurve Projector (P, C);
+~~~~~
+If you wish to restrict the search for normals to the given domain [U1,U2], use the following constructor:
+~~~~~
+GeomAPI_ProjectPointOnCurve Projector (P, C, U1, U2);
+~~~~~
+Having thus created the *GeomAPI_ProjectPointOnCurve* object, you can now interrogate it.
+
+Calling the number of solution points
+-------------------------------------
+~~~~~
+Standard_Integer NumSolutions = Projector.NbPoints();
+~~~~~
+
+Calling the location of a solution point
+----------------------------------------
+The solutions are indexed in a range from 1 to *Projector.NbPoints()*. The point, which corresponds to a given index, may be found:
+~~~~~
+gp_Pnt Pn = Projector.Point(Index);
+~~~~~
+
+Calling the parameter of a solution point
+-----------------------------------------
+For a given point corresponding to a given index:
+
+~~~~~
+Standard_Real U = Projector.Parameter(Index);
+~~~~~
+
+This can also be programmed as:
+~~~~~
+Standard_Real U;
+Projector.Parameter(Index,U);
+~~~~~
+
+Calling the distance between the start and end point
+----------------------------------------------------
+The distance between the initial point and a point, which corresponds to a given index, may be found:
+~~~~~
+Standard_Real D = Projector.Distance(Index);
+~~~~~
+
+Calling the nearest solution point
+----------------------------------
+This class offers a method to return the closest solution point to the starting point. This solution is accessed as follows:
+~~~~~
+gp_Pnt P1 = Projector.NearestPoint();
+~~~~~
+
+Calling the parameter of the nearest solution point
+---------------------------------------------------
+~~~~~
+Standard_Real U = Projector.LowerDistanceParameter();
+~~~~~
+
+Calling the minimum distance from the point to the curve
+--------------------------------------------------------
+~~~~~
+Standard_Real D = Projector.LowerDistance();
+~~~~~
+
+Redefined operators
+--------------------
+Some operators have been redefined to find the nearest solution.
+
+*Standard_Real()* returns the minimum distance from the point to the curve.
+
+~~~~~
+Standard_Real D = GeomAPI_ProjectPointOnCurve (P,C);
+~~~~~
+
+*Standard_Integer()* returns the number of solutions.
+~~~~~
+Standard_Integer N = GeomAPI_ProjectPointOnCurve (P,C);
+~~~~~
+
+*gp_Pnt2d()* returns the nearest solution point.
+
+~~~~~
+gp_Pnt P1 = GeomAPI_ProjectPointOnCurve (P,C);
+~~~~~
+Using these operators makes coding easier when you only need the nearest point. In this way,
+
+~~~~~
+GeomAPI_ProjectPointOnCurve Projector (P, C);
+gp_Pnt P1 = Projector.NearestPoint();
+~~~~~
+
+can be written more concisely as:
+~~~~~
+gp_Pnt P1 = GeomAPI_ProjectPointOnCurve (P,C);
+~~~~~
+In the second case, however, no intermediate *GeomAPI_ProjectPointOnCurve* object is created, and it is impossible to access other solutions points.
+
+Access to lower-level functionalities
+-------------------------------------
+If you want to use the wider range of functionalities available from the Extrema package, a call to the *Extrema()* method will return the algorithmic object for calculating the extrema. For example:
+
+~~~~~
+Extrema_ExtPC& TheExtrema = Projector.Extrema();
+~~~~~
+
+@subsubsection occt_modalg_2_12_6 Projection of a Point on a Surface
+
+*GeomAPI_ProjectPointOnSurf* class allows calculation of all normals projected from a point from *gp_Pnt* onto a geometric surface from Geom_Surface.
+
+
+
+
+Note
+----
+Note that the surface does not have to be of *Geom_RectangularTrimmedSurface* type.
+The algorithm will function with any class inheriting Geom_Surface.
+
+*GeomAPI_ProjectPointOnSurf* is instantiated as in the following example:
+~~~~~
+gp_Pnt P;
+Handle (Geom_Surface) S = new Geom_BezierSurface(args);
+GeomAPI_ProjectPointOnSurf Proj (P, S);
+~~~~~
+
+To restrict the search for normals within the given rectangular domain [U1, U2, V1, V2], use the following constructor:
+
+~~~~~
+GeomAPI_ProjectPointOnSurf Proj (P, S, U1, U2, V1, V2);
+~~~~~
+
+The values of U1, U2, V1 and V2 lie at or within their maximum and minimum limits, i.e.:
+~~~~~
+Umin <= U1 < U2 <= Umax
+Vmin <= V1 < V2 <= Vmax
+~~~~~
+Having thus created the *GeomAPI_ProjectPointOnSurf* object, you can interrogate it.
+
+Calling the number of solution points
+-------------------------------------
+
+~~~~~
+Standard_Integer NumSolutions = Proj.NbPoints();
+~~~~~
+
+Calling the location of a solution point
+----------------------------------------
+The solutions are indexed in a range from 1 to *Proj.NbPoints()*. The point corresponding to the given index may be found:
+
+~~~~~
+gp_Pnt Pn = Proj.Point(Index);
+~~~~~
+
+Calling the parameters of a solution point
+------------------------------------------
+For a given point corresponding to the given index:
+
+~~~~~
+Standard_Real U,V;
+Proj.Parameters(Index, U, V);
+~~~~~
+
+Calling the distance between the start and end point
+----------------------------------------------------
+
+The distance between the initial point and a point corresponding to the given index may be found:
+~~~~~
+Standard_Real D = Projector.Distance(Index);
+~~~~~
+
+Calling the nearest solution point
+----------------------------------
+This class offers a method, which returns the closest solution point to the starting point. This solution is accessed as follows:
+~~~~~
+gp_Pnt P1 = Proj.NearestPoint();
+~~~~~
+
+Calling the parameters of the nearest solution point
+----------------------------------------------------
+~~~~~
+Standard_Real U,V;
+Proj.LowerDistanceParameters (U, V);
+~~~~~
+
+Calling the minimum distance from a point to the surface
+--------------------------------------------------------
+~~~~~
+Standard_Real D = Proj.LowerDistance();
+~~~~~
+
+Redefined operators
+-------------------
+Some operators have been redefined to help you find the nearest solution.
+
+*Standard_Real()* returns the minimum distance from the point to the surface.
+
+~~~~~
+Standard_Real D = GeomAPI_ProjectPointOnSurf (P,S);
+~~~~~
+
+*Standard_Integer()* returns the number of solutions.
+
+~~~~~
+Standard_Integer N = GeomAPI_ProjectPointOnSurf (P,S);
+~~~~~
+
+*gp_Pnt2d()* returns the nearest solution point.
+
+~~~~~
+gp_Pnt P1 = GeomAPI_ProjectPointOnSurf (P,S);
+~~~~~
+
+Using these operators makes coding easier when you only need the nearest point. In this way,
+
+~~~~~
+GeomAPI_ProjectPointOnSurface Proj (P, S);
+gp_Pnt P1 = Proj.NearestPoint();
+~~~~~
+
+can be written more concisely as:
+
+~~~~~
+gp_Pnt P1 = GeomAPI_ProjectPointOnSurface (P,S);
+~~~~~
+
+In the second case, however, no intermediate *GeomAPI_ProjectPointOnSurf* object is created, and it is impossible to access other solution points.
+
+@subsubsection occt_modalg_2_12_7 Access to lower-level functionalities
+
+If you want to use the wider range of functionalities available from the Extrema package, a call to the Extrema() method will return the algorithmic object for calculating the extrema as follows:
+
+~~~~~
+Extrema_ExtPS& TheExtrema = Proj.Extrema();
+~~~~~
+
+
+@subsubsection occt_modalg_2_12_8 Switching from 2d and 3d Curves
+The To2d and To3d methods are used to;
+
+ * build a 2d curve from a 3d Geom_Curve lying on a gp_Pln plane
+ * build a 3d curve from a Geom2d_Curve and a gp_Pln plane.
+
+These methods are called as follows:
+~~~~~
+Handle(Geom2d_Curve) C2d = GeomAPI::To2d(C3d, Pln);
+Handle(Geom_Curve) C3d = GeomAPI::To3d(C2d, Pln);
+~~~~~
+
+
+@section occt_modalg_3 Topological Tools
+
+Open CASCADE Technology topological tools include:
+
+ * Standard topological objects combining topological data structure and boundary representation
+ * Geometric Transformations
+ * Conversion to NURBS geometry
+ * Finding Planes
+ * Duplicating Shapes
+ * Checking Validity
+
+
+@subsection occt_modalg_3_1 Creation of Standard Topological Objects
+
+The standard topological objects include
+ * Vertices
+ * Edges
+ * Wires
+ * Faces
+ * Shells
+ * Solids.
+
+There are two root classes for their construction and modification:
+* The deferred class *BRepBuilderAPI_MakeShape* is the root of all *BRepBuilderAPI* classes, which build shapes. It inherits from the class *BRepBuilderAPI_Command* and provides a field to store the constructed shape.
+* The deferred *BRepBuilderAPI_ModifyShape* is used as a root for the shape modifications. It inherits *BRepBuilderAPI_MakeShape* and implements the methods used to trace the history of all sub-shapes.
+
+@subsubsection occt_modalg_3_1_1 Vertex
+
+*BRepBuilderAPI_MakeVertex* creates a new vertex from a 3D point from gp.
+~~~~~
+gp_Pnt P(0,0,10);
+TopoDS_Vertex V = BRepBuilderAPI_MakeVertex(P);
+~~~~~
+
+This class always creates a new vertex and has no other methods.
+
+@subsubsection occt_modalg_3_1_2 Edge
+
+Use *BRepBuilderAPI_MakeEdge* to create from a curve and vertices. The basic method is to construct an edge from a curve, two vertices, and two parameters. All other constructions are derived from this one. The basic method and its arguments are described first, followed by the other methods. The BRepBuilderAPI_MakeEdge class can provide extra information and return an error status.
+
+Basic Edge construction
+-----------------------
+
+~~~~~
+Handle(Geom_Curve) C = ...; // a curve
+TopoDS_Vertex V1 = ...,V2 = ...;// two Vertices
+Standard_Real p1 = ..., p2 = ..;// two parameters
+TopoDS_Edge E = BRepBuilderAPI_MakeEdge(C,V1,V2,p1,p2);
+~~~~~
+
+where C is the domain of the edge; V1 is the first vertex oriented FORWARD; V2 is the second vertex oriented REVERSED; p1 and p2 are the parameters for the vertices V1 and V2 on the curve. The default tolerance is associated with this edge.
+
+
+
+The following rules apply to the arguments:
+
+**The curve**
+ * Must not be a Null Handle.
+ * If the curve is a trimmed curve, the basis curve is used.
+
+**The vertices**
+ * Can be null shapes. When V1 or V2 is Null the edge is open in the corresponding direction and the corresponding parameter p1 or p2 must be infinite (i.e p1 is RealFirst(), p2 is RealLast()).
+ * Must be different vertices if they have different 3d locations and identical vertices if they have the same 3d location (identical vertices are used when the curve is closed).
+
+**The parameters**
+ * Must be increasing and in the range of the curve, i.e.:
+~~~~~
+ C->FirstParameter() <= p1 < p2 <= C->LastParameter()
+~~~~~
+
+* If the parameters are decreasing, the Vertices are switched, i.e. V2 becomes V1 and V1 becomes V2.
+* On a periodic curve the parameters p1 and p2 are adjusted by adding or subtracting the period to obtain p1 in the range of the curve and p2 in the range p1 < p2 <= p1+ Period. So on a parametric curve p2 can be greater than the second parameter, see the figure below.
+* Can be infinite but the corresponding vertex must be Null (see above).
+* The distance between the Vertex 3d location and the point evaluated on the curve with the parameter must be lower than the default precision.
+
+The figure below illustrates two special cases, a semi-infinite edge and an edge on a periodic curve.
+
+
+
+
+Other Edge constructions
+------------------------
+*BRepBuilderAPI_MakeEdge* class provides methods, which are all simplified calls of the previous one:
+
+ * The parameters can be omitted. They are computed by projecting the vertices on the curve.
+ * 3d points (Pnt from gp) can be given in place of vertices. Vertices are created from the points. Giving vertices is useful when creating connected vertices.
+ * The vertices or points can be omitted if the parameters are given. The points are computed by evaluating the parameters on the curve.
+ * The vertices or points and the parameters can be omitted. The first and the last parameters of the curve are used.
+
+The five following methods are thus derived from the basic construction:
+
+~~~~~
+Handle(Geom_Curve) C = ...; // a curve
+TopoDS_Vertex V1 = ...,V2 = ...;// two Vertices
+Standard_Real p1 = ..., p2 = ..;// two parameters
+gp_Pnt P1 = ..., P2 = ...;// two points
+TopoDS_Edge E;
+// project the vertices on the curve
+E = BRepBuilderAPI_MakeEdge(C,V1,V2);
+// Make vertices from points
+E = BRepBuilderAPI_MakeEdge(C,P1,P2,p1,p2);
+// Make vertices from points and project them
+E = BRepBuilderAPI_MakeEdge(C,P1,P2);
+// Computes the points from the parameters
+E = BRepBuilderAPI_MakeEdge(C,p1,p2);
+// Make an edge from the whole curve
+E = BRepBuilderAPI_MakeEdge(C);
+~~~~~
+
+
+Six methods (the five above and the basic method) are also provided for curves from the gp package in place of Curve from Geom. The methods create the corresponding Curve from Geom and are implemented for the following classes:
+
+*gp_Lin* creates a *Geom_Line*
+*gp_Circ* creates a *Geom_Circle*
+*gp_Elips* creates a *Geom_Ellipse*
+*gp_Hypr* creates a *Geom_Hyperbola*
+*gp_Parab* creates a *Geom_Parabola*
+
+There are also two methods to construct edges from two vertices or two points. These methods assume that the curve is a line; the vertices or points must have different locations.
+
+~~~~~
+
+TopoDS_Vertex V1 = ...,V2 = ...;// two Vertices
+gp_Pnt P1 = ..., P2 = ...;// two points
+TopoDS_Edge E;
+
+// linear edge from two vertices
+E = BRepBuilderAPI_MakeEdge(V1,V2);
+
+// linear edge from two points
+E = BRepBuilderAPI_MakeEdge(P1,P2);
+~~~~~
+
+Other information and error status
+----------------------------------
+If BRepBuilderAPI_MakeEdge is used as a class, it can provide two vertices. This is useful when the vertices were not provided as arguments, for example when the edge was constructed from a curve and parameters. The two methods Vertex1 and Vertex2 return the vertices. Note that the returned vertices can be null if the edge is open in the corresponding direction.
+
+The *Error* method returns a term of the *BRepBuilderAPI_EdgeError* enumeration. It can be used to analyze the error when *IsDone* method returns False. The terms are:
+
+ * **EdgeDone** - No error occurred, *IsDone* returns True.
+ * **PointProjectionFailed** - No parameters were given, but the projection of the 3D points on the curve failed. This happens if the point distance to the curve is greater than the precision.
+ * **ParameterOutOfRange** - The given parameters are not in the range *C->FirstParameter()*, *C->LastParameter()*
+ * **DifferentPointsOnClosedCurve** - The two vertices or points have different locations but they are the extremities of a closed curve.
+ * **PointWithInfiniteParameter** - A finite coordinate point was associated with an infinite parameter (see the Precision package for a definition of infinite values).
+ * **DifferentsPointAndParameter** - The distance of the 3D point and the point evaluated on the curve with the parameter is greater than the precision.
+ * **LineThroughIdenticPoints** - Two identical points were given to define a line (construction of an edge without curve), *gp::Resolution* is used to test confusion .
+
+The following example creates a rectangle centered on the origin of dimensions H, L with fillets of radius R. The edges and the vertices are stored in the arrays *theEdges* and *theVertices*. We use class *Array1OfShape* (i.e. not arrays of edges or vertices). See the image below.
+
+
+
+~~~~~
+#include <BRepBuilderAPI_MakeEdge.hxx>
+#include <TopoDS_Shape.hxx>
+#include <gp_Circ.hxx>
+#include <gp.hxx>
+#include <TopoDS_Wire.hxx>
+#include <TopTools_Array1OfShape.hxx>
+#include <BRepBuilderAPI_MakeWire.hxx>
+
+// Use MakeArc method to make an edge and two vertices
+void MakeArc(Standard_Real x,Standard_Real y,
+Standard_Real R,
+Standard_Real ang,
+TopoDS_Shape& E,
+TopoDS_Shape& V1,
+TopoDS_Shape& V2)
+{
+gp_Ax2 Origin = gp::XOY();
+gp_Vec Offset(x, y, 0.);
+Origin.Translate(Offset);
+BRepBuilderAPI_MakeEdge
+ME(gp_Circ(Origin,R), ang, ang+PI/2);
+E = ME;
+V1 = ME.Vertex1();
+V2 = ME.Vertex2();
+}
+
+TopoDS_Wire MakeFilletedRectangle(const Standard_Real H,
+const Standard_Real L,
+const Standard_Real R)
+{
+TopTools_Array1OfShape theEdges(1,8);
+TopTools_Array1OfShape theVertices(1,8);
+
+// First create the circular edges and the vertices
+// using the MakeArc function described above.
+void MakeArc(Standard_Real, Standard_Real,
+Standard_Real, Standard_Real,
+TopoDS_Shape&, TopoDS_Shape&, TopoDS_Shape&);
+
+Standard_Real x = L/2 - R, y = H/2 - R;
+MakeArc(x,-y,R,3.*PI/2.,theEdges(2),theVertices(2),
+theVertices(3));
+MakeArc(x,y,R,0.,theEdges(4),theVertices(4),
+theVertices(5));
+MakeArc(-x,y,R,PI/2.,theEdges(6),theVertices(6),
+theVertices(7));
+MakeArc(-x,-y,R,PI,theEdges(8),theVertices(8),
+theVertices(1));
+// Create the linear edges
+for (Standard_Integer i = 1; i <= 7; i += 2)
+{
+theEdges(i) = BRepBuilderAPI_MakeEdge
+(TopoDS::Vertex(theVertices(i)),TopoDS::Vertex
+(theVertices(i+1)));
+}
+// Create the wire using the BRepBuilderAPI_MakeWire
+BRepBuilderAPI_MakeWire MW;
+for (i = 1; i <= 8; i++)
+{
+MW.Add(TopoDS::Edge(theEdges(i)));
+}
+return MW.Wire();
+}
+~~~~~
+
+@subsubsection occt_modalg_3_1_3 Edge 2D
+
+Use *BRepBuilderAPI_MakeEdge2d* class to make edges on a working plane from 2d curves. The working plane is a default value of the *BRepBuilderAPI* package (see the *Plane* methods).
+
+*BRepBuilderAPI_MakeEdge2d* class is strictly similar to BRepBuilderAPI_MakeEdge, but it uses 2D geometry from gp and Geom2d instead of 3D geometry.
+
+@subsubsection occt_modalg_3_1_4 Polygon
+
+*BRepBuilderAPI_MakePolygon* class is used to build polygonal wires from vertices or points. Points are automatically changed to vertices as in *BRepBuilderAPI_MakeEdge*.
+
+The basic usage of *BRepBuilderAPI_MakePolygon* is to create a wire by adding vertices or points using the Add method. At any moment, the current wire can be extracted. The close method can be used to close the current wire. In the following example, a closed wire is created from an array of points.
+
+~~~~~
+#include <TopoDS_Wire.hxx>
+#include <BRepBuilderAPI_MakePolygon.hxx>
+#include <TColgp_Array1OfPnt.hxx>
+
+TopoDS_Wire ClosedPolygon(const TColgp_Array1OfPnt& Points)
+{
+BRepBuilderAPI_MakePolygon MP;
+for(Standard_Integer i=Points.Lower();i=Points.Upper();i++)
+{
+MP.Add(Points(i));
+}
+MP.Close();
+return MP;
+}
+~~~~~
+
+Short-cuts are provided for 2, 3, or 4 points or vertices. Those methods have a Boolean last argument to tell if the polygon is closed. The default value is False.
+
+Two examples:
+
+Example of a closed triangle from three vertices:
+~~~~~
+TopoDS_Wire W = BRepBuilderAPI_MakePolygon(V1,V2,V3,Standard_True);
+~~~~~
+
+Example of an open polygon from four points:
+~~~~~
+TopoDS_Wire W = BRepBuilderAPI_MakePolygon(P1,P2,P3,P4);
+~~~~~
+
+BRepBuilderAPI_MakePolygon class maintains a current wire. The current wire can be extracted at any moment and the construction can proceed to a longer wire. After each point insertion, the class maintains the last created edge and vertex, which are returned by the methods Edge, FirstVertex and LastVertex.
+
+When the added point or vertex has the same location as the previous one it is not added to the current wire but the most recently created edge becomes Null. The **Added** method can be used to test this condition. The MakePolygon class never raises an error. If no vertex has been added, the Wire is Null. If two vertices are at the same location, no edge is created.
+
+@subsubsection occt_modalg_3_1_5 Face
+
+Use *BRepBuilderAPI_MakeFace* class to create a face from a surface and wires. An underlying surface is constructed from a surface and optional parametric values. Wires can be added to the surface. A planar surface can be constructed from a wire. An error status can be returned after face construction.
+
+Basic face construction
+-----------------------
+
+A face can be constructed from a surface and four parameters to determine a limitation of the UV space. The parameters are optional, if they are omitted the natural bounds of the surface are used. Up to four edges and vertices are created with a wire. No edge is created when the parameter is infinite.
+
+~~~~~
+Handle(Geom_Surface) S = ...; // a surface
+Standard_Real umin,umax,vmin,vmax; // parameters
+TopoDS_Face F = BRepBuilderAPI_MakeFace(S,umin,umax,vmin,vmax);
+~~~~~
+
+
+
+To make a face from the natural boundary of a surface, the parameters are not required:
+
+~~~~~
+Handle(Geom_Surface) S = ...; // a surface
+TopoDS_Face F = BRepBuilderAPI_MakeFace(S);
+~~~~~
+
+Constraints on the parameters are similar to the constraints in *BRepBuilderAPI_MakeEdge*.
+ * umin,umax (vmin,vmax) must be in the range of the surface and must be increasing.
+ * On a U (V) periodic surface umin and umax (vmin,vmax) are adjusted.
+ * umin, umax, vmin, vmax can be infinite. There will be no edge in the corresponding direction.
+
+
+Other face constructions
+------------------------
+The two basic constructions (from a surface and from a surface and parameters) are implemented for all the gp package surfaces, which are transformed in the corresponding Surface from Geom.
+
+*gp_Pln* creates a *Geom_Plane*
+*gp_Cylinder* creates a *Geom_CylindricalSurface*
+*gp_Cone* creates a *Geom_ConicalSurface*
+*gp_Sphere* creates a *Geom_SphericalSurface*
+*gp_Torus* creates a *Geom_ToroidalSurface*
+
+Once a face has been created, a wire can be added using the Add method. For example, the following code creates a cylindrical surface and adds a wire.
+
+~~~~~
+gp_Cylinder C = ..; // a cylinder
+TopoDS_Wire W = ...;// a wire
+BRepBuilderAPI_MakeFace MF(C);
+MF.Add(W);
+TopoDS_Face F = MF;
+~~~~~
+
+More than one wire can be added to a face, provided that they do not cross each other and they define only one area on the surface. (Note that this is not checked). The edges on a Face must have a parametric curve description.
+
+If there is no parametric curve for an edge of the wire on the Face it is computed by projection.
+
+For one wire, a simple syntax is provided to construct the face from the surface and the wire. The above lines could be written:
+
+~~~~~
+TopoDS_Face F = BRepBuilderAPI_MakeFace(C,W);
+~~~~~
+
+A planar face can be created from only a wire, provided this wire defines a plane. For example, to create a planar face from a set of points you can use *BRepBuilderAPI_MakePolygon* and *BRepBuilderAPI_MakeFace*.
+
+~~~~~
+#include <TopoDS_Face.hxx>
+#include <TColgp_Array1OfPnt.hxx>
+#include <BRepBuilderAPI_MakePolygon.hxx>
+#include <BRepBuilderAPI_MakeFace.hxx>
+
+TopoDS_Face PolygonalFace(const TColgp_Array1OfPnt& thePnts)
+{
+BRepBuilderAPI_MakePolygon MP;
+for(Standard_Integer i=thePnts.Lower();
+i<=thePnts.Upper(); i++)
+{
+MP.Add(thePnts(i));
+}
+MP.Close();
+TopoDS_Face F = BRepBuilderAPI_MakeFace(MP.Wire());
+return F;
+}
+~~~~~
+
+The last use of MakeFace is to copy an existing face to add new wires. For example the following code adds a new wire to a face:
+
+~~~~~
+TopoDS_Face F = ...; // a face
+TopoDS_Wire W = ...; // a wire
+F = BRepBuilderAPI_MakeFace(F,W);
+~~~~~
+
+To add more than one wire an instance of the *BRepBuilderAPI_MakeFace* class can be created with the face and the first wire and the new wires inserted with the Add method.
+
+Error status
+------------
+The Error method returns an error status, which is a term from the *BRepBuilderAPI_FaceError* enumeration.
+
+* *FaceDone* - no error occurred.
+* *NoFace* - no initialization of the algorithm; an empty constructor was used.
+* *NotPlanar* - no surface was given and the wire was not planar.
+* *CurveProjectionFailed* - no curve was found in the parametric space of the surface for an edge.
+* *ParametersOutOfRange* - the parameters umin,umax,vmin,vmax are out of the surface.
+
+@subsubsection occt_modalg_3_1_6 Wire
+The wire is a composite shape built not from a geometry, but by the assembly of edges. *BRepBuilderAPI_MakeWire* class can build a wire from one or more edges or connect new edges to an existing wire.
+
+Up to four edges can be used directly, for example:
+
+~~~~~
+TopoDS_Wire W = BRepBuilderAPI_MakeWire(E1,E2,E3,E4);
+~~~~~
+
+For a higher or unknown number of edges the Add method must be used; for example, to build a wire from an array of shapes (to be edges).
+
+~~~~~
+TopTools_Array1OfShapes theEdges;
+BRepBuilderAPI_MakeWire MW;
+for (Standard_Integer i = theEdge.Lower();
+i <= theEdges.Upper(); i++)
+MW.Add(TopoDS::Edge(theEdges(i));
+TopoDS_Wire W = MW;
+~~~~~
+
+The class can be constructed with a wire. A wire can also be added. In this case, all the edges of the wires are added. For example to merge two wires:
+
+~~~~~
+#include <TopoDS_Wire.hxx>
+#include <BRepBuilderAPI_MakeWire.hxx>
+
+TopoDS_Wire MergeWires (const TopoDS_Wire& W1,
+const TopoDS_Wire& W2)
+{
+BRepBuilderAPI_MakeWire MW(W1);
+MW.Add(W2);
+return MW;
+}
+~~~~~
+
+*BRepBuilderAPI_MakeWire* class connects the edges to the wire. When a new edge is added if one of its vertices is shared with the wire it is considered as connected to the wire. If there is no shared vertex, the algorithm searches for a vertex of the edge and a vertex of the wire, which are at the same location (the tolerances of the vertices are used to test if they have the same location). If such a pair of vertices is found, the edge is copied with the vertex of the wire in place of the original vertex. All the vertices of the edge can be exchanged for vertices from the wire. If no connection is found the wire is considered to be disconnected. This is an error.
+
+BRepBuilderAPI_MakeWire class can return the last edge added to the wire (Edge method). This edge can be different from the original edge if it was copied.
+
+The Error method returns a term of the *BRepBuilderAPI_WireError* enumeration:
+*WireDone* - no error occurred.
+*EmptyWire* - no initialization of the algorithm, an empty constructor was used.
+*DisconnectedWire* - the last added edge was not connected to the wire.
+*NonManifoldWire* - the wire with some singularity.
+
+@subsubsection occt_modalg_3_1_7 Shell
+The shell is a composite shape built not from a geometry, but by the assembly of faces.
+Use *BRepBuilderAPI_MakeShell* class to build a Shell from a set of Faces. What may be important is that each face should have the required continuity. That is why an initial surface is broken up into faces.
+
+@subsubsection occt_modalg_3_1_8 Solid
+The solid is a composite shape built not from a geometry, but by the assembly of shells. Use *BRepBuilderAPI_MakeSolid* class to build a Solid from a set of Shells. Its use is similar to the use of the MakeWire class: shells are added to the solid in the same way that edges are added to the wire in MakeWire.
+
+
+@subsubsection occt_modalg_3_2 Modification Operators
+
+@subsubsection occt_modalg_3_2_1 Transformation
+*BRepBuilderAPI_Transform* class can be used to apply a transformation to a shape (see class *gp_Trsf*). The methods have a boolean argument to copy or share the original shape, as long as the transformation allows (it is only possible for direct isometric transformations). By default, the original shape is shared.
+
+The following example deals with the rotation of shapes.
+
+~~~~~
+
+TopoDS_Shape myShape1 = ...;
+// The original shape 1
+TopoDS_Shape myShape2 = ...;
+// The original shape2
+gp_Trsf T;
+T.SetRotation(gp_Ax1(gp_Pnt(0.,0.,0.),gp_Vec(0.,0.,1.)),
+2.*PI/5.);
+BRepBuilderAPI_Transformation theTrsf(T);
+theTrsf.Perform(myShape1);
+TopoDS_Shape myNewShape1 = theTrsf.Shape()
+theTrsf.Perform(myShape2,Standard_True);
+// Here duplication is forced
+TopoDS_Shape myNewShape2 = theTrsf.Shape()
+~~~~~
+
+@subsubsection occt_modalg_3_2_2 Duplication
+
+Use the BRepBuilderAPI_Copy class to duplicate a shape. A new shape is thus created.
+In the following example, a solid is copied:
+
+~~~~~
+TopoDS Solid MySolid;
+....// Creates a solid
+
+TopoDS_Solid myCopy = BRepBuilderAPI_Copy(mySolid);
+~~~~~
+
+@section occt_modalg_4 Construction of Primitives
+@subsection occt_modalg_4_1 Making Primitives
+@subsubsection occt_modalg_4_1_1 Box
+
+BRepPrimAPI_MakeBox class allows building a parallelepiped box. The result is either a Shell or a Solid. There are four ways to build a box:
+
+* From three dimensions dx,dy,dz. The box is parallel to the axes and extends for [0,dx] [0,dy] [0,dz].
+* From a point and three dimensions. The same as above but the point is the new origin.
+* From two points, the box is parallel to the axes and extends on the intervals defined by the coordinates of the two points.
+* From a system of axes (gp_Ax2) and three dimensions. Same as the first way but the box is parallel to the given system of axes.
+
+An error is raised if the box is flat in any dimension using the default precision. The following code shows how to create a box:
+~~~~~
+TopoDS_Solid theBox = BRepPrimAPI_MakeBox(10.,20.,30.);
+~~~~~
+
+The four methods to build a box are shown in the figure:
+
+
+
+@subsubsection occt_modalg_4_1_2 Wedge
+BRepPrimAPI_MakeWedge class allows building a wedge, which is a slanted box, i.e. a box with angles. The wedge is constructed in much the same way as a box i.e. from three dimensions dx,dy,dz plus arguments or from an axis system, three dimensions, and arguments.
+
+The following figure shows two ways to build wedges. One is to add an ltx dimension, which is the length in x of the face at dy. The second is to add xmin, xmax, zmin, zmax to describe the face at dy.
+
+The first method is a particular case of the second with xmin = 0, xmax = ltx, zmin = 0, zmax = dz.
+To make a centered pyramid you can use xmin = xmax = dx / 2, zmin = zmax = dz / 2.
+
+
+
+@subsubsection occt_modalg_4_1_3 Rotation object
+BRepPrimAPI_MakeOneAxis is a deferred class used as a root class for all classes constructing rotational primitives. Rotational primitives are created by rotating a curve around an axis. They cover the cylinder, the cone, the sphere, the torus, and the revolution, which provides all other curves.
+
+The particular constructions of these primitives are described, but they all have some common arguments, which are:
+
+ * A system of coordinates, where the Z axis is the rotation axis..
+ * An angle in the range [0,2*PI].
+ * A vmin, vmax parameter range on the curve.
+
+The result of the OneAxis construction is a Solid, a Shell, or a Face. The face is the face covering the rotational surface. Remember that you will not use the OneAxis directly but one of the derived classes, which provide improved constructions. The following figure illustrates the OneAxis arguments.
+
+
+
+@subsubsection occt_modalg_4_1_4 Cylinder
+BRepPrimAPI_MakeCylinder class allows creating cylindrical primitives. A cylinder is created either in the default coordinate system or in a given coordinate system (gp_Ax2). There are two constructions:
+
+ * Radius and height, to build a full cylinder.
+ * Radius, height and angle to build a portion of a cylinder.
+
+The following code builds the cylindrical face of the figure, which is a quarter of cylinder along the Y axis with the origin at X,Y,Z, a length of DY, and a radius R.
+
+~~~~~
+
+Standard_Real X = 20, Y = 10, Z = 15, R = 10, DY = 30;
+// Make the system of coordinates
+gp_Ax2 axes = gp::ZOX();
+axes.Translate(gp_Vec(X,Y,Z));
+TopoDS_Face F =
+BRepPrimAPI_MakeCylinder(axes,R,DY,PI/2.);
+~~~~~
+
+
+@subsubsection occt_modalg_4_1_5 Cone
+BRepPrimAPI_MakeCone class allows creating conical primitives. Like a cylinder, a cone is created either in the default coordinate system or in a given coordinate system (gp_Ax2). There are two constructions:
+
+ * Two radii and height, to build a full cone. One of the radii can be null to make a sharp cone.
+ * Radii, height and angle to build a truncated cone.
+
+The following code builds the solid cone of the figure, which is located in the default system with radii R1 and R2 and height H.
+
+~~~~~
+Standard_Real R1 = 30, R2 = 10, H = 15;
+TopoDS_Solid S = BRepPrimAPI_MakeCone(R1,R2,H);
+~~~~~
+
+
+
+@subsubsection occt_modalg_4_1_6 Sphere
+BRepPrimAPI_MakeSphere class allows creating spherical primitives. Like a cylinder, a sphere is created either in the default coordinate system or in a given coordinate system (gp_Ax2). There are four constructions:
+
+ * From a radius - builds a full sphere.
+ * From a radius and an angle - builds a lune (digon).
+ * From a radius and two angles - builds a wraparound spherical segment between two latitudes. The angles a1, a2 must follow the relation: PI/2 <= a1 < a2 <= PI/2.
+ * From a radius and three angles - a combination of two previous methods builds a portion of spherical segment.
+
+The following code builds four spheres from a radius and three angles.
+
+~~~~~
+Standard_Real R = 30, ang =
+ PI/2, a1 = -PI/2.3, a2 = PI/4;
+TopoDS_Solid S1 = BRepPrimAPI_MakeSphere(R);
+TopoDS_Solid S2 = BRepPrimAPI_MakeSphere(R,ang);
+TopoDS_Solid S3 = BRepPrimAPI_MakeSphere(R,a1,a2);
+TopoDS_Solid S4 = BRepPrimAPI_MakeSphere(R,a1,a2,ang);
+~~~~~
+
+Note that we could equally well choose to create Shells instead of Solids.
+
+
+
+
+@subsubsection occt_modalg_4_1_7 Torus
+BRepPrimAPI_MakeTorus class allows creating toroidal primitives. Like the other primitives, a torus is created either in the default coordinate system or in a given coordinate system (gp_Ax2). There are four constructions similar to the sphere constructions:
+
+ * Two radii - builds a full torus.
+ * Two radii and an angle - builds an angular torus segment.
+ * Two radii and two angles - builds a wraparound torus segment between two radial planes. The angles a1, a2 must follow the relation 0 < a2 - a1 < 2*PI.
+ * Two radii and three angles - a combination of two previous methods builds a portion of torus segment.
+
+
+
+The following code builds four toroidal shells from two radii and three angles.
+
+~~~~~
+Standard_Real R1 = 30, R2 = 10, ang = PI, a1 = 0,
+ a2 = PI/2;
+TopoDS_Shell S1 = BRepPrimAPI_MakeTorus(R1,R2);
+TopoDS_Shell S2 = BRepPrimAPI_MakeTorus(R1,R2,ang);
+TopoDS_Shell S3 = BRepPrimAPI_MakeTorus(R1,R2,a1,a2);
+TopoDS_Shell S4 =
+ BRepPrimAPI_MakeTorus(R1,R2,a1,a2,ang);
+~~~~~
+
+Note that we could equally well choose to create Solids instead of Shells.
+
+@subsubsection occt_modalg_4_1_8 Revolution
+BRepPrimAPI_MakeRevolution class allows building a uniaxial primitive from a curve. As other uniaxial primitives it can be created in the default coordinate system or in a given coordinate system.
+
+The curve can be any *Geom_Curve*, provided it is planar and lies in the same plane as the Z-axis of local coordinate system. There are four modes of construction:
+
+ * From a curve, use the full curve and make a full rotation.
+ * From a curve and an angle of rotation.
+ * From a curve and two parameters to trim the curve. The two parameters must be growing and within the curve range.
+ * From a curve, two parameters, and an angle. The two parameters must be growing and within the curve range.
+
+
+@subsection occt_modalg_4_2 Sweeping: Prism, Revolution and Pipe
+@subsubsection occt_modalg_4_2_1 Sweeping
+
+Sweeps are the objects you obtain by sweeping a **profile** along a **path**. The profile can be of any topology. The path is usually a curve or a wire. The profile generates objects according to the following rules:
+
+ * Vertices generate Edges
+ * Edges generate Faces.
+ * Wires generate Shells.
+ * Faces generate Solids.
+ * Shells generate Composite Solids
+
+It is forbidden to sweep Solids and Composite Solids. A Compound generates a Compound with the sweep of all its elements.
+
+
+
+*BRepPrimAPI_MakeSweep class* is a deferred class used as a root of the the following sweep classes:
+* *BRepPrimAPI_MakePrism* - produces a linear sweep
+* *BRepPrimAPI_MakeRevol* - produces a rotational sweep
+* *BRepPrimAPI_MakePipe* - produces a general sweep.
+
+
+@subsubsection occt_modalg_4_2_2 Prism
+BRepPrimAPI_MakePrism class allows creating a linear **prism** from a shape and a vector or a direction.
+* A vector allows creating a finite prism;
+* A direction allows creating an infinite or semi-infinite prism. The semi-infinite or infinite prism is toggled by a Boolean argument. All constructors have a boolean argument to copy the original shape or share it (by default).
+The following code creates a finite, an infinite and a semi-infinite solid using a face, a direction and a length
+.
+~~~~~
+TopoDS_Face F = ..; // The swept face
+gp_Dir direc(0,0,1);
+Standard_Real l = 10;
+// create a vector from the direction and the length
+gp_Vec v = direc;
+v *= l;
+TopoDS_Solid P1 = BRepPrimAPI_MakePrism(F,v);
+// finite
+TopoDS_Solid P2 = BRepPrimAPI_MakePrism(F,direc);
+// infinite
+TopoDS_Solid P3 = BRepPrimAPI_MakePrism(F,direc,Standard_False);
+// semi-infinite
+~~~~~
+
+
+
+@subsubsection occt_modalg_4_2_3 Rotation
+BRepPrimAPI_MakeRevol class allows creating a rotational sweep from a shape, an axis (gp_Ax1), and an angle. The angle has a default value of 2*PI which means a closed revolution.
+
+BRepPrimAPI_MakeRevol constructors have a last argument to copy or share the original shape. The following code creates a a full and a partial rotation using a face, an axis and an angle.
+
+~~~~~
+TopoDS_Face F = ...; // the profile
+gp_Ax1 axis(gp_Pnt(0,0,0),gp_Dir(0,0,1));
+Standard_Real ang = PI/3;
+TopoDS_Solid R1 = BRepPrimAPI_MakeRevol(F,axis);
+// Full revol
+TopoDS_Solid R2 = BRepPrimAPI_MakeRevol(F,axis,ang);
+~~~~~
+
+
+
+@section occt_modalg_5 Boolean Operations
+
+Boolean operations are used to create new shapes from the combinations of two shapes.
+|Fuse | all points in S1 or S2 |
+|Common | all points in S1 and S2 |
+|Cut S1 by S2| all points in S1 and not in S2 |
+
+BRepAlgoAPI_BooleanOperation class is the deferred root class for Boolean operations.
+
+
+
+@subsection occt_modalg_5_1 Fuse
+
+BRepAlgoAPI_Fuse performs the Fuse operation.
+~~~~~
+TopoDS_Shape A = ..., B = ...;
+TopoDS_Shape S = BRepAlgoAPI_Fuse(A,B);
+~~~~~
+
+@subsection occt_modalg_5_2 Common
+BRepAlgoAPI_Common performs the Common operation.
+
+~~~~~
+TopoDS_Shape A = ..., B = ...;
+TopoDS_Shape S = BRepAlgoAPI_Common(A,B);
+~~~~~
+
+@subsection occt_modalg_5_3 Cut
+BRepAlgoAPI_Cut performs the Cut operation.
+
+~~~~~
+TopoDS_Shape A = ..., B = ...;
+TopoDS_Shape S = BRepAlgoAPI_Cut(A,B);
+~~~~~
+
+@subsection occt_modalg_5_4 Section
+
+BRepAlgoAPI_Section performs the section, described as a *TopoDS_Compound* made of *TopoDS_Edge*.
+
+
+
+~~~~~
+TopoDS_Shape A = ..., TopoDS_ShapeB = ...;
+TopoDS_Shape S = BRepAlgoAPI_Section(A,B);
+~~~~~
+
+@section occt_modalg_6 Fillets and Chamfers
+@subsection occt_modalg_6_1 Fillets
+@subsection occt_modalg_6_1_1 Fillet on shape
+
+A fillet is a smooth face replacing a sharp edge.
+
+*BRepFilletAPI_MakeFillet* class allows filleting a shape.
+
+To produce a fillet, it is necessary to define the filleted shape at the construction of the class and add fillet descriptions using the *Add* method.
+A fillet description contains an edge and a radius. The edge must be shared by two faces. The fillet is automatically extended to all edges in a smooth continuity with the original edge.
+It is not an error to Add a fillet twice, the last description holds.
+
+
+
+In the following example a filleted box with dimensions a,b,c and radius r is created.
+
+Constant radius
+----------------
+
+~~~~~
+#include <TopoDS_Shape.hxx>
+#include <TopoDS.hxx>
+#include <BRepPrimAPI_MakeBox.hxx>
+#include <TopoDS_Solid.hxx>
+#include <BRepFilletAPI_MakeFillet.hxx>
+#include <TopExp_Explorer.hxx>
+
+TopoDS_Shape FilletedBox(const Standard_Real a,
+ const Standard_Real b,
+ const Standard_Real c,
+ const Standard_Real r)
+{
+ TopoDS_Solid Box = BRepPrimAPI_MakeBox(a,b,c);
+ BRepFilletAPI_MakeFillet MF(Box);
+
+ // add all the edges to fillet
+ TopExp_Explorer ex(Box,TopAbs_EDGE);
+ while (ex.More())
+ {
+ MF.Add(r,TopoDS::Edge(ex.Current()));
+ ex.Next();
+ }
+ return MF.Shape();
+ }
+~~~~~
+
+
+
+Changing radius
+---------------
+
+~~~~~
+void CSampleTopologicalOperationsDoc::OnEvolvedblend1()
+{
+ TopoDS_Shape theBox = BRepPrimAPI_MakeBox(200,200,200);
+
+ BRepFilletAPI_MakeFillet Rake(theBox);
+ ChFi3d_FilletShape FSh = ChFi3d_Rational;
+ Rake.SetFilletShape(FSh);
+
+ TColgp_Array1OfPnt2d ParAndRad(1, 6);
+ ParAndRad(1).SetCoord(0., 10.);
+ ParAndRad(1).SetCoord(50., 20.);
+ ParAndRad(1).SetCoord(70., 20.);
+ ParAndRad(1).SetCoord(130., 60.);
+ ParAndRad(1).SetCoord(160., 30.);
+ ParAndRad(1).SetCoord(200., 20.);
+
+ TopExp_Explorer ex(theBox,TopAbs_EDGE);
+ Rake.Add(ParAndRad, TopoDS::Edge(ex.Current()));
+ TopoDS_Shape evolvedBox = Rake.Shape();
+}
+~~~~~
+
+
+
+@subsection occt_modalg_6_1_2 Chamfer
+
+A chamfer is a rectilinear edge replacing a sharp vertex of the face.
+
+The use of *BRepFilletAPI_MakeChamfer* class is similar to the use of *BRepFilletAPI_MakeFillet*, except for the following:
+
+*The surfaces created are ruled and not smooth.
+*The *Add* syntax for selecting edges requires one or two distances, one edge and one face (contiguous to the edge):
+
+~~~~~
+Add(dist, E, F)
+Add(d1, d2, E, F) with d1 on the face F.
+~~~~~
+
+
+
+@subsection occt_modalg_6_1_3 Fillet on a planar face
+
+BRepFilletAPI_MakeFillet2d class allows constructing fillets and chamfers on planar faces.
+To create a fillet on planar face: define it, indicate, which vertex is to be deleted, and give the fillet radius with *AddFillet* method.
+A chamfer can be calculated with *AddChamfer* method. It can be described by
+ * two edges and two distances
+ * one edge, one vertex, one distance and one angle.
+Fillets and chamfers are calculated when addition is complete.
+
+If face F2 is created by 2D fillet and chamfer builder from face F1, the builder can be rebuilt (the builder recovers the status it had before deletion). To do so, use the following syntax:
+~~~~~
+BRepFilletAPI_MakeFillet2d builder;
+builder.Init(F1,F2);
+~~~~~
+
+Planar Fillet
+-------------
+
+~~~~~
+#include “BRepPrimAPI_MakeBox.hxx”
+#include “TopoDS_Shape.hxx”
+#include “TopExp_Explorer.hxx”
+#include “BRepFilletAPI_MakeFillet2d.hxx”
+#include “TopoDS.hxx”
+#include “TopoDS_Solid.hxx”
+
+TopoDS_Shape FilletFace(const Standard_Real a,
+ const Standard_Real b,
+ const Standard_Real c,
+ const Standard_Real r)
+
+{
+ TopoDS_Solid Box = BRepPrimAPI_MakeBox (a,b,c);
+ TopExp_Explorer ex1(Box,TopAbs_FACE);
+
+ const TopoDS_Face& F = TopoDS::Face(ex1.Current());
+ BRepFilletAPI_MakeFillet2d MF(F);
+ TopExp_Explorer ex2(F, TopAbs_VERTEX);
+ while (ex2.More())
+ {
+ MF.AddFillet(TopoDS::Vertex(ex2.Current()),r);
+ ex2.Next();
+ }
+ // while...
+ return MF.Shape();
+}
+~~~~~
+
+@section occt_modalg_7 Offsets, Drafts, Pipes and Evolved shapes
+@subsection occt_modalg_7_1 Shelling
+
+Shelling is used to offset given faces of a solid by a specific value. It rounds or intersects adjacent faces along its edges depending on the convexity of the edge.
+
+The constructor *BRepOffsetAPI_MakeThickSolid* shelling operator takes the solid, the list of faces to remove and an offset value as input.
+
+~~~~~
+TopoDS_Solid SolidInitial = ...;
+
+Standard_Real Of = ...;
+TopTools_ListOfShape LCF;
+TopoDS_Shape Result;
+Standard_Real Tol = Precision::Confusion();
+
+for (Standard_Integer i = 1 ;i <= n; i++) {
+ TopoDS_Face SF = ...; // a face from SolidInitial
+ LCF.Append(SF);
+}
+
+Result = BRepOffsetAPI_MakeThickSolid (SolidInitial,
+ LCF,
+ Of,
+ Tol);
+~~~~~
+
+
+
+
+@subsection occt_modalg_7_2 Draft Angle
+
+*BRepOffsetAPI_DraftAngle* class allows modifying a shape by applying draft angles to its planar, cylindrical and conical faces.
+The class is created or initialized from a shape, then faces to be modified are added; for each face, three arguments are used:
+
+ * Direction: the direction with which the draft angle is measured
+ * Angle: value of the angle
+ * Neutral plane: intersection between the face and the neutral plane is invariant.
+
+The following code places a draft angle on several faces of a shape; the same direction, angle and neutral plane are used for each face:
+
+~~~~~
+TopoDS_Shape myShape = ...
+// The original shape
+TopTools_ListOfShape ListOfFace;
+// Creation of the list of faces to be modified
+...
+
+gp_Dir Direc(0.,0.,1.);
+// Z direction
+Standard_Real Angle = 5.*PI/180.;
+// 5 degree angle
+gp_Pln Neutral(gp_Pnt(0.,0.,5.), Direc);
+// Neutral plane Z=5
+BRepOffsetAPI_DraftAngle theDraft(myShape);
+TopTools_ListIteratorOfListOfShape itl;
+for (itl.Initialize(ListOfFace); itl.More(); itl.Next()) {
+ theDraft.Add(TopoDS::Face(itl.Value()),Direc,Angle,Neutral);
+ if (!theDraft.AddDone()) {
+ // An error has occurred. The faulty face is given by // ProblematicShape
+ break;
+ }
+}
+if (!theDraft.AddDone()) {
+ // An error has occurred
+ TopoDS_Face guilty = theDraft.ProblematicShape();
+ ...
+}
+theDraft.Build();
+if (!theDraft.IsDone()) {
+ // Problem encountered during reconstruction
+ ...
+}
+else {
+ TopoDS_Shape myResult = theDraft.Shape();
+ ...
+}
+~~~~~
+
+
+
+@subsection occt_modalg_7_3 Pipe Constructor
+
+*BRepOffsetAPI_MakePipe* class allows creating a pipe from a Spine, which is a Wire and a Profile which is a Shape. This implementation is limited to spines with smooth transitions, sharp transitions are precessed by *BRepOffsetAPI_MakePipeShell*. To be more precise the continuity must be G1, which means that the tangent must have the same direction, though not necessarily the same magnitude, at neighboring edges.
+The angle between the spine and the profile is preserved throughout the pipe.
+
+~~~~~
+TopoDS_Wire Spine = ...;
+TopoDS_Shape Profile = ...;
+TopoDS_Shape Pipe = BRepOffsetAPI_MakePipe(Spine,Profile);
+~~~~~
+
+
+
+@subsection occt_modalg_7_4 Evolved Solid
+
+*BRepOffsetAPI_MakeEvolved* class allows creating an evolved solid from a Spine (planar face or wire) and a profile (wire).
+The evolved solid is an unlooped sweep generated by the spine and the profile.
+The evolved solid is created by sweeping the profile’s reference axes on the spine. The origin of the axes moves to the spine, the X axis and the local tangent coincide and the Z axis is normal to the face.
+
+The reference axes of the profile can be defined following two distinct modes:
+
+* The reference axes of the profile are the origin axes.
+* The references axes of the profile are calculated as follows:
+ + the origin is given by the point on the spine which is the closest to the profile
+ + the X axis is given by the tangent to the spine at the point defined above
+ + the Z axis is the normal to the plane which contains the spine.
+
+~~~~~
+TopoDS_Face Spine = ...;
+TopoDS_Wire Profile = ...;
+TopoDS_Shape Evol =
+BRepOffsetAPI_MakeEvolved(Spine,Profile);
+~~~~~
+
+@section occt_modalg_8 Sewing operators
+@subsection occt_modalg_8_1 Sewing
+
+*BRepOffsetAPI_Sewing* class allows sewing TopoDS Shapes together along their common edges. The edges can be partially shared as in the following example.
+
+
+
+The constructor takes as arguments the tolerance (default value is 10-6) and a flag, which is used to mark the degenerate shapes.
+The following methods are used in this class:
+* *Add* adds shapes, as it is needed;
+* *Perform* forces calculation of the sewed shape.
+* *SewedShape* returns the result.
+Additional methods can be used to give information on the number of free boundaries, multiple edges and degenerate shapes.
+
+@subsection occt_modalg_8_2 Find Contiguous Edges
+*BRepOffsetAPI_FindContiguousEdges* class is used to find edges, which coincide among a set of shapes within the given tolerance; these edges can be analyzed for tangency, continuity (C1, G2, etc.)...
+
+The constructor takes as arguments the tolerance defining the edge proximity (10-6 by default) and a flag used to mark degenerated shapes.
+The following methods are used in this class:
+* *Add* adds shapes, which are to be analyzed;
+* *NbEdges* returns the total number of edges;
+* *NbContiguousEdges* returns the number of contiguous edges within the given tolerance as defined above;
+* *ContiguousEdge* takes an edge number as an argument and returns the *TopoDS* edge contiguous to another edge;
+* *ContiguousEdgeCouple* gives all edges or sections, which are common to the edge with the number given above.
+* *SectionToBoundary* finds the original edge on the original shape from the section.
+
+@section occt_modalg_9 Features
+
+@subsection occt_modalg_9_1 The BRepFeat Classes and their use
+BRepFeat package is used to manipulate extensions of the classical boundary representation of shapes closer to features. In that sense, BRepFeat is an extension of BRepBuilderAPI package.
+
+@subsubsection occt_modalg_9_1_1 Form classes
+The Form from BRepFeat class is a deferred class used as a root for form features. It inherits MakeShape from BRepBuilderAPI and provides implementation of methods keep track of all sub-shapes.
+
+MakePrism
+---------
+MakePrism from BRepFeat class is used to build a prism interacting with a shape. It is created or initialized from
+ * a shape (the basic shape),
+ * the base of the prism,
+ * a face (the face of sketch on which the base has been defined and used to determine whether the base has been defined on the basic shape or not),
+ * a direction,
+ * a Boolean indicating the type of operation (fusion=protrusion or cut=depression) on the basic shape,
+ * another Boolean indicating if the self-intersections have to be found (not used in every case).
+
+There are six Perform methods:
+
+|Perform(Height) | The resulting prism is of the given length. |
+|Perform(Until) | The prism is defined between the position of the base and the given face. |
+|Perform(From, Until) | The prism is defined between the two faces From and Until. |
+|PerformUntilEnd() | The prism is semi-infinite, limited by the actual position of the base. |
+|PerformFromEnd(Until) | The prism is semi-infinite, limited by the face Until. |
+| PerformThruAll() | The prism is infinite. In the case of a depression, the result is similar to a cut with an infinite prism. In the case of a protrusion, infinite parts are not kept in the result. |
+
+**Note** *Add* method can be used before *Perform* methods to indicate that a face generated by an edge slides onto a face of the base shape.
+
+In the following sequence, a protrusion is performed, i.e. a face of the shape is changed into a prism.
+
+~~~~~
+TopoDS_Shape Sbase = ...; // an initial shape
+TopoDS_Face Fbase = ....; // a base of prism
+
+gp_Dir Extrusion (.,.,.);
+
+// An empty face is given as the sketch face
+
+BRepFeat_MakePrism thePrism(Sbase, Fbase, TopoDS_Face(), Extrusion, Standard_True, Standard_True);
+
+thePrism, Perform(100.);
+if (thePrism.IsDone()) {
+ TopoDS_Shape theResult = thePrism;
+ ...
+}
+~~~~~
+
+
+
+
+
+MakeDPrism
+----------
+MakeDPrism from BRepFeat class is used to build draft prism topologies interacting with a basis shape . These can be depressions or protrusions. A class object is created or initialized from
+ * a shape (basic shape),
+ * the base of the prism,
+ * a face (face of sketch on which the base has been defined and used to determine whether the base has been defined on the basic shape or not),
+ * an angle,
+ * a Boolean indicating the type of operation (fusion=protrusion or cut=depression) on the basic shape,
+ * another Boolean indicating if self-intersections have to be found (not used in every case).
+
+Evidently the input data for MakeDPrism are the same as for MakePrism except for a new parameter Angle and a missing parameter Direction: the direction of the prism generation is determined automatically as the normal to the base of the prism.
+The semantics of draft prism feature creation is based on the construction of shapes:
+ * along a length
+ * up to a limiting face
+ * from a limiting face to a height.
+
+The shape defining construction of the draft prism feature can be either the supporting edge or the concerned area of a face.
+
+In case of the supporting edge, this contour can be attached to a face of the basis shape by binding. When the contour is bound to this face, the information that the contour will slide on the face becomes available to the relevant class methods.
+In case of the concerned area of a face, it is possible to cut it out and move it to a different height, which will define the limiting face of a protrusion or depression direction .
+
+The *Perform* methods are the same as for *MakePrism*.
+
+~~~~~
+TopoDS_Shape S = BRepPrimAPI_MakeBox(400.,250.,300.);
+TopExp_Explorer Ex;
+Ex.Init(S,TopAbs_FACE);
+Ex.Next();
+Ex.Next();
+Ex.Next();
+Ex.Next();
+Ex.Next();
+TopoDS_Face F = TopoDS::Face(Ex.Current());
+Handle(Geom_Surface) surf = BRep_Tool::Surface(F);
+gp_Circ2d
+c(gp_Ax2d(gp_Pnt2d(200.,130.),gp_Dir2d(1.,0.)),50.);
+BRepBuilderAPI_MakeWire MW;
+Handle(Geom2d_Curve) aline = new Geom2d_Circle(c);
+MW.Add(BRepBuilderAPI_MakeEdge(aline,surf,0.,PI));
+MW.Add(BRepBuilderAPI_MakeEdge(aline,surf,PI,2.*PI));
+BRepBuilderAPI_MakeFace MKF;
+MKF.Init(surf,Standard_False);
+MKF.Add(MW.Wire());
+TopoDS_Face FP = MKF.Face();
+BRepLib::BuildCurves3d(FP);
+BRepFeat_MakeDPrism MKDP (S,FP,F,10*PI180,Standard_True,
+ Standard_True);
+MKDP.Perform(200);
+TopoDS_Shape res1 = MKDP.Shape();
+~~~~~
+
+
+
+MakeRevol
+---------
+The MakeRevol from BRepFeat class is used to build a revolution interacting with a
+shape. It is created or initialized from
+
+ * a shape (the basic shape,)
+ * the base of the revolution,
+ * a face (the face of sketch on which the base has been defined and used to determine whether the base has been defined on the basic shape or not),
+ * an axis of revolution,
+ * a boolean indicating the type of operation (fusion=protrusion or cut=depression) on the basic shape,
+ * another boolean indicating whether the self-intersections have to be found (not used in every case).
+
+There are four Perform methods:
+|Perform(Angle) | The resulting revolution is of the given magnitude. |
+|Perform(Until) |The revolution is defined between the actual position of the base and the given face. |
+|Perform(From, Until) | The revolution is defined between the two faces, From and Until. |
+|PerformThruAll() | The result is similar to Perform(2*PI). |
+
+**Note** *Add* method can be used before *Perform* methods to indicate that a face generated by an edge slides onto a face of the base shape.
+
+
+In the following sequence, a face is revolved and the revolution is limited by a face of the base shape.
+
+~~~~~
+TopoDS_Shape Sbase = ...; // an initial shape
+TopoDS_Face Frevol = ....; // a base of prism
+TopoDS_Face FUntil = ....; // face limiting the revol
+
+gp_Dir RevolDir (.,.,.);
+gp_Ax1 RevolAx(gp_Pnt(.,.,.), RevolDir);
+
+// An empty face is given as the sketch face
+
+BRepFeat_MakeRevol theRevol(Sbase, Frevol, TopoDS_Face(), RevolAx, Standard_True, Standard_True);
+
+theRevol.Perform(FUntil);
+if (theRevol.IsDone()) {
+ TopoDS_Shape theResult = theRevol;
+ ...
+}
+~~~~~
+
+MakePipe
+--------
+This method constructs compound shapes with pipe features: depressions or protrusions. A class object is created or initialized from
+ * a shape (basic shape),
+ * a base face (profile of the pipe)
+ * a face (face of sketch on which the base has been defined and used to determine whether the base has been defined on the basic shape or not),
+ * a spine wire
+ * a Boolean indicating the type of operation (fusion=protrusion or cut=depression) on the basic shape,
+ * another Boolean indicating if self-intersections have to be found (not used in every case).
+
+There are three Perform methods:
+
+| Perform() | The pipe is defined along the entire path (spine wire) |
+| Perform(Until) | The pipe is defined along the path until a given face |
+| Perform(From, Until) | The pipe is defined between the two faces From and Until |
+
+~~~~~
+TopoDS_Shape S = BRepPrimAPI_MakeBox(400.,250.,300.);
+TopExp_Explorer Ex;
+Ex.Init(S,TopAbs_FACE);
+Ex.Next();
+Ex.Next();
+TopoDS_Face F1 = TopoDS::Face(Ex.Current());
+Handle(Geom_Surface) surf = BRep_Tool::Surface(F1);
+BRepBuilderAPI_MakeWire MW1;
+gp_Pnt2d p1,p2;
+p1 = gp_Pnt2d(100.,100.);
+p2 = gp_Pnt2d(200.,100.);
+Handle(Geom2d_Line) aline = GCE2d_MakeLine(p1,p2).Value();
+
+MW1.Add(BRepBuilderAPI_MakeEdge(aline,surf,0.,p1.Distance(p2)));
+p1 = p2;
+p2 = gp_Pnt2d(150.,200.);
+aline = GCE2d_MakeLine(p1,p2).Value();
+
+MW1.Add(BRepBuilderAPI_MakeEdge(aline,surf,0.,p1.Distance(p2)));
+p1 = p2;
+p2 = gp_Pnt2d(100.,100.);
+aline = GCE2d_MakeLine(p1,p2).Value();
+
+MW1.Add(BRepBuilderAPI_MakeEdge(aline,surf,0.,p1.Distance(p2)));
+BRepBuilderAPI_MakeFace MKF1;
+MKF1.Init(surf,Standard_False);
+MKF1.Add(MW1.Wire());
+TopoDS_Face FP = MKF1.Face();
+BRepLib::BuildCurves3d(FP);
+TColgp_Array1OfPnt CurvePoles(1,3);
+gp_Pnt pt = gp_Pnt(150.,0.,150.);
+CurvePoles(1) = pt;
+pt = gp_Pnt(200.,100.,150.);
+CurvePoles(2) = pt;
+pt = gp_Pnt(150.,200.,150.);
+CurvePoles(3) = pt;
+Handle(Geom_BezierCurve) curve = new Geom_BezierCurve
+(CurvePoles);
+TopoDS_Edge E = BRepBuilderAPI_MakeEdge(curve);
+TopoDS_Wire W = BRepBuilderAPI_MakeWire(E);
+BRepFeat_MakePipe MKPipe (S,FP,F1,W,Standard_False,
+Standard_True);
+MKPipe.Perform();
+TopoDS_Shape res1 = MKPipe.Shape();
+~~~~~
+
+
+
+@subsubsection occt_modalg_9_1_2 Linear Form
+--------------
+*MakeLinearForm* class creates a rib or a groove along a planar surface.
+The semantics of mechanical features is built around giving thickness to a contour. This thickness can either be symmetrical - on one side of the contour - or dissymmetrical - on both sides. As in the semantics of form features, the thickness is defined by construction of shapes in specific contexts.
+
+The development contexts differ, however, in the case of mechanical features.
+Here they include extrusion:
+ * to a limiting face of the basis shape;
+ * to or from a limiting plane;
+ * to a height.
+A class object is created or initialized from
+ * a shape (basic shape);
+ * a wire (base of rib or groove);
+ * a plane (plane of the wire);
+ * direction1 (a vector along which thickness will be built up);
+ * direction2 (vector opposite to the previous one along which thickness will be built up, may be null);
+ * a Boolean indicating the type of operation (fusion=rib or cut=groove) on the basic shape;
+ * another Boolean indicating if self-intersections have to be found (not used in every case).
+
+There is one Perform() method, which performs a prism from the wire along the direction1 and direction2 interacting base shape Sbase. The height of the prism is Magnitude(Direction1)+Magnitude(direction2).
+
+~~~~~
+BRepBuilderAPI_MakeWire mkw;
+gp_Pnt p1 = gp_Pnt(0.,0.,0.);
+gp_Pnt p2 = gp_Pnt(200.,0.,0.);
+mkw.Add(BRepBuilderAPI_MakeEdge(p1,p2));
+p1 = p2;
+p2 = gp_Pnt(200.,0.,50.);
+mkw.Add(BRepBuilderAPI_MakeEdge(p1,p2));
+p1 = p2;
+p2 = gp_Pnt(50.,0.,50.);
+mkw.Add(BRepBuilderAPI_MakeEdge(p1,p2));
+p1 = p2;
+p2 = gp_Pnt(50.,0.,200.);
+mkw.Add(BRepBuilderAPI_MakeEdge(p1,p2));
+p1 = p2;
+p2 = gp_Pnt(0.,0.,200.);
+mkw.Add(BRepBuilderAPI_MakeEdge(p1,p2));
+p1 = p2;
+mkw.Add(BRepBuilderAPI_MakeEdge(p2,gp_Pnt(0.,0.,0.)));
+TopoDS_Shape S = BRepBuilderAPI_MakePrism(BRepBuilderAPI_MakeFace
+ (mkw.Wire()),gp_Vec(gp_Pnt(0.,0.,0.),gp_P
+ nt(0.,100.,0.)));
+TopoDS_Wire W = BRepBuilderAPI_MakeWire(BRepBuilderAPI_MakeEdge(gp_Pnt
+ (50.,45.,100.),
+gp_Pnt(100.,45.,50.)));
+Handle(Geom_Plane) aplane =
+ new Geom_Plane(gp_Pnt(0.,45.,0.), gp_Vec(0.,1.,0.));
+BRepFeat_MakeLinearForm aform(S, W, aplane, gp_Dir
+ (0.,5.,0.), gp_Dir(0.,-3.,0.), 1, Standard_True);
+aform.Perform();
+TopoDS_Shape res = aform.Shape();
+~~~~~
+
+
+
+@subsubsection occt_modalg_9_1_3 Gluer
+
+The Gluer from BRepFeat class allows gluing two solids along faces. The contact faces of the glued shape must not have parts outside the contact faces of the basic shape.
+The class is created or initialized from two shapes: the “glued” shape and the basic shape (on which the other shape is glued).
+Two Bind methods are used to bind a face of the glued shape to a face of the basic shape and an edge of the glued shape to an edge of the basic shape.
+
+**Note** Every face and edge has to be bounded, if two edges of two glued faces are coincident they must be explicitly bounded.
+
+~~~~~
+TopoDS_Shape Sbase = ...; // the basic shape
+TopoDS_Shape Sglued = ...; // the glued shape
+
+TopTools_ListOfShape Lfbase;
+TopTools_ListOfShape Lfglued;
+// Determination of the glued faces
+...
+
+BRepFeat_Gluer theGlue(Sglue, Sbase);
+TopTools_ListIteratorOfListOfShape itlb(Lfbase);
+TopTools_ListIteratorOfListOfShape itlg(Lfglued);
+for (; itlb.More(); itlb.Next(), itlg(Next()) {
+const TopoDS_Face& f1 = TopoDS::Face(itlg.Value());
+const TopoDS_Face& f2 = TopoDS::Face(itlb.Value());
+theGlue.Bind(f1,f2);
+// for example, use the class FindEdges from LocOpe to
+// determine coincident edges
+LocOpe_FindEdge fined(f1,f2);
+for (fined.InitIterator(); fined.More(); fined.Next()) {
+theGlue.Bind(fined.EdgeFrom(),fined.EdgeTo());
+}
+}
+theGlue.Build();
+if (theGlue.IsDone() {
+TopoDS_Shape theResult = theGlue;
+...
+}
+~~~~~
+
+@subsubsection occt_modalg_9_1_3 Split Shape
+
+SplitShape from BRepFeat class is used to split faces of a shape with wires or edges. The shape containing the new entities is rebuilt, sharing the unmodified ones.
+
+The class is created or initialized from a shape (the basic shape).
+Three Add methods are available:
+
+| Add(Wire, Face) | Adds a new wire on a face of the basic shape. |
+| Add(Edge, Face) | Adds a new edge on a face of the basic shape. |
+| Add(EdgeNew, EdgeOld) | Adds a new edge on an existing one (the old edge must contain the new edge). |
+
+**Note** The added wires and edges must define closed wires on faces or wires located between two existing edges. Existing edges must not be intersected.
+
+~~~~~
+TopoDS_Shape Sbase = ...; // basic shape
+TopoDS_Face Fsplit = ...; // face of Sbase
+TopoDS_Wire Wsplit = ...; // new wire contained in Fsplit
+BRepFeat_SplitShape Spls(Sbase);
+Spls.Add(Wsplit, Fsplit);
+TopoDS_Shape theResult = Spls;
+...
+~~~~~
+
+
+@section occt_modalg_10 Hidden Line Removal
+
+To provide the precision required in industrial design, drawings need to offer the possibility of removing lines, which are hidden in a given projection.
+
+For this the Hidden Line Removal component provides two algorithms: HLRBRep_Algo and HLRBRep_PolyAlgo.
+
+These algorithms are based on the principle of comparing each edge of the shape to be visualized with each of its faces, and calculating the visible and the hidden parts of each edge. Note that these are not the algorithms used in generating shading, which calculate the visible and hidden parts of each face in a shape to be visualized by comparing each face in the shape with every other face in the same shape.
+These algorithms operate on a shape and remove or indicate edges hidden by faces. For a given projection, they calculate a set of lines characteristic of the object being represented. They are also used in conjunction with extraction utilities, which reconstruct a new, simplified shape from a selection of the results of the calculation. This new shape is made up of edges, which represent the shape visualized in the projection.
+
+HLRBRep_Algo takes the shape itself into account whereas HLRBRep_PolyAlgo works with a polyhedral simplification of the shape. When you use HLRBRep_Algo, you obtain an exact result, whereas, when you use HLRBRep_PolyAlgo, you reduce the computation time.
+
+No smoothing algorithm is provided. Consequently, a polyhedron will be treated as such and the algorithms will give the results in form of line segments conforming to the mathematical definition of the polyhedron. This is always the case with HLRBRep_PolyAlgo.
+
+HLRBRep_Algo and HLRBRep_PolyAlgo can deal with any kind of object, for example, assemblies of volumes, surfaces, and lines, as long as there are no unfinished objects or points within it.
+
+However, there some restrictions in HLR use:
+ * Points are not processed;
+ * Z-clipping planes are not used;
+ * Infinite faces or lines are not processed.
+
+
+
+
+
+
+
+
+
+
+
+@subsection occt_modalg_10_2 Services
+The following services are related to Hidden Lines Removal :
+
+Loading Shapes
+--------------
+To pass a *TopoDS_Shape* to an *HLRBRep_Algo* object, use *HLRBRep_Algo::Add*. With an *HLRBRep_PolyAlgo* object, use *HLRBRep_PolyAlgo::Load*. If you wish to add several shapes, use Add or Load as often as necessary.
+
+Setting view parameters
+-----------------------
+HLRBRep_Algo::Projector and HLRBRep_PolyAlgo::Projector set a projector object which defines the parameters of the view. This object is an HLRAlgo_Projector.
+
+Computing the projections
+-------------------------
+HLRBRep_PolyAlgo::Update launches the calculation of outlines of the shape visualized by the HLRBRep_PolyAlgo framework.
+In the case of HLRBRep_Algo, use HLRBRep_Algo::Update. With this algorithm, you must also call the method HLRBRep_Algo::Hide to calculate visible and hidden lines of the shape to be visualized. With an HLRBRep_PolyAlgo object, visible and hidden lines are computed by HLRBRep_PolyHLRToShape.
+
+Extracting edges
+----------------
+The classes HLRBRep_HLRToShape and HLRBRep_PolyHLRToShape present a range of extraction filters for an HLRBRep_Algo object and an HLRBRep_PolyAlgo object, respectively. They highlight the type of edge from the results calculated by the algorithm on a shape. With both extraction classes, you can highlight the following types of output:
+ * visible/hidden sharp edges;
+ * visible/hidden smooth edges;
+ * visible/hidden sewn edges;
+ * visible/hidden outline edges.
+
+To perform extraction on an *HLRBRep_PolyHLRToShape* object, use *HLRBRep_PolyHLRToShape::Update* function.
+For an *HLRBRep_HLRToShape* object built from an *HLRBRepAlgo* object you can also highlight:
+ * visible isoparameters and
+ * hidden isoparameters.
+
+@subsection occt_modalg_10_3 Examples
+
+HLRBRep_Algo
+------------
+~~~~~
+// Build The algorithm object
+myAlgo = new HLRBRep_Algo();
+
+// Add Shapes into the algorithm
+TopTools_ListIteratorOfListOfShape anIterator(myListOfShape);
+for (;anIterator.More();anIterator.Next())
+myAlgo-Add(anIterator.Value(),myNbIsos);
+
+// Set The Projector (myProjector is a
+HLRAlgo_Projector)
+myAlgo-Projector(myProjector);
+
+// Build HLR
+myAlgo->Update();
+
+// Set The Edge Status
+myAlgo->Hide();
+
+// Build the extraction object :
+HLRBRep_HLRToShape aHLRToShape(myAlgo);
+
+// extract the results :
+TopoDS_Shape VCompound = aHLRToShape.VCompound();
+TopoDS_Shape Rg1LineVCompound =
+aHLRToShape.Rg1LineVCompound();
+TopoDS_Shape RgNLineVCompound =
+aHLRToShape.RgNLineVCompound();
+TopoDS_Shape OutLineVCompound =
+aHLRToShape.OutLineVCompound();
+TopoDS_Shape IsoLineVCompound =
+aHLRToShape.IsoLineVCompound();
+TopoDS_Shape HCompound = aHLRToShape.HCompound();
+TopoDS_Shape Rg1LineHCompound =
+aHLRToShape.Rg1LineHCompound();
+TopoDS_Shape RgNLineHCompound =
+aHLRToShape.RgNLineHCompound();
+TopoDS_Shape OutLineHCompound =
+aHLRToShape.OutLineHCompound();
+TopoDS_Shape IsoLineHCompound =
+aHLRToShape.IsoLineHCompound();
+~~~~~
+
+HLRBRep_PolyAlgo
+----------------
+
+~~~~~
+
+// Build The algorithm object
+myPolyAlgo = new HLRBRep_PolyAlgo();
+
+// Add Shapes into the algorithm
+TopTools_ListIteratorOfListOfShape
+anIterator(myListOfShape);
+for (;anIterator.More();anIterator.Next())
+myPolyAlgo-Load(anIterator.Value());
+
+// Set The Projector (myProjector is a
+HLRAlgo_Projector)
+myPolyAlgo->Projector(myProjector);
+
+// Build HLR
+myPolyAlgo->Update();
+
+// Build the extraction object :
+HLRBRep_PolyHLRToShape aPolyHLRToShape;
+aPolyHLRToShape.Update(myPolyAlgo);
+
+// extract the results :
+TopoDS_Shape VCompound =
+aPolyHLRToShape.VCompound();
+TopoDS_Shape Rg1LineVCompound =
+aPolyHLRToShape.Rg1LineVCompound();
+TopoDS_Shape RgNLineVCompound =
+aPolyHLRToShape.RgNLineVCompound();
+TopoDS_Shape OutLineVCompound =
+aPolyHLRToShape.OutLineVCompound();
+TopoDS_Shape HCompound =
+aPolyHLRToShape.HCompound();
+TopoDS_Shape Rg1LineHCompound =
+aPolyHLRToShape.Rg1LineHCompound();
+TopoDS_Shape RgNLineHCompound =
+aPolyHLRToShape.RgNLineHCompound();
+TopoDS_Shape OutLineHCompound =
+aPolyHLRToShape.OutLineHCompound();
+~~~~~
+
+@section occt_modalg_10_4 Meshing of Shapes
+
+The *HLRBRep_PolyAlgo* algorithm works with triangulation of shapes. This is provided by the function *BRepMesh::Mesh*, which adds a triangulation of the shape to its topological data structure. This triangulation is computed with a given deflection.
+
+~~~~~
+Standard_Real radius=10. ;
+Standard_Real height=25. ;
+BRepBuilderAPI_MakeCylinder myCyl (radius, height) ;
+TopoDS_Shape myShape = myCyl.Shape() ;
+Standard_Real Deflection = 0.01 ;
+BRepMesh::Mesh (myShape, Deflection);
+~~~~~
+
+Meshing covers a shape with a triangular mesh. Other than hidden line removal, you can use meshing to transfer the shape to another tool: a manufacturing tool, a shading algorithm, a finite element algorithm, or a collision algorithm, for example.
+
+You can obtain information on the shape by first exploring it. To then access triangulation of a face in the shape, use *BRepTool::Triangulation*. To access a polygon which is the approximation of an edge of the face, use *BRepTool::PolygonOnTriangulation*.
\ No newline at end of file
--- /dev/null
+Modeling Data {#user_guides__modeling_data}
+========================
+
+@section occt_modat_1 Introduction
+
+Modeling Data supplies data structures to represent 2D and 3D geometric models. This manual explains how to use Modeling Data. For advanced information on modeling data, see our offerings on our web site at <a href="http://www.opencascade.org/support/training/">www.opencascade.org/support/training/</a>
+
+
+
+@section occt_modat_1 Geometry Utilities
+
+Geometry Utilities provide the following services:
+ * Creation of shapes by interpolation and approximation
+ * Direct construction of shapes
+ * Conversion of curves and surfaces to Bspline curves and surfaces
+ * Computation of the coordinates of points on 2D and 3D curves
+ * Calculation of extrema between shapes.
+
+@subsection occt_modat_1_1 Interpolations and Approximations
+
+In modeling, it is often required to approximate or interpolate points into curves and surfaces. In interpolation, the process is complete when the curve or surface passes through all the points; in approximation, when it is as close to these points as possible. This component provides both high and low level services to approximate or interpolate points into curves and surfaces. The lower level services allow performing parallel approximation of groups of points into groups of Bezier or B-spline curves.
+
+@subsubsection occt_modat_1_1_1 Analysis of a set of points
+
+The class *PEquation* from *GProp* package allows analyzng a collection or cloud of points and verifying if they are coincident, collinear or coplanar within a given precision. If they are, the algorithm computes the mean point, the mean line or the mean plane of the points. If they are not, the algorithm computes the minimal box, which includes all the points.
+
+@subsubsection occt_modat_1_1_2 Basic Interpolation and Approximation
+
+Packages *Geom2dAPI* and *GeomAPI* provide simple methods for approximation and interpolation with minimal programming
+
+2D Interpolation
+----------------
+The class *Interpolate* from *Geom2dAPI* package allows building a constrained 2D BSpline curve, defined by a table of points through which the curve passes. If required, the parameter values and vectors of the tangents can be given for each point in the table.
+
+3D Interpolation
+----------------
+The class *Interpolate* from *GeomAPI* package allows building a constrained 3D BSpline curve, defined by a table of points through which the curve passes. If required, the parameter values and vectors of the tangents can be given for each point in the table.
+
+
+
+This class may be instantiated as follows:
+~~~~~
+GeomAPI_Interpolate Interp(Points);
+~~~~~
+
+From this object, the BSpline curve may be requested as follows:
+~~~~~
+Handle(Geom_BSplineCurve) C = Interp.Curve();
+~~~~~
+
+2D Approximation
+----------------
+The class *PointsToBSpline* from *Geom2dAPI* package allows building a 2DBSpline curve, which approximates a set of points. You have to define the lowest and highest degree of the curve, its continuity and a tolerance value for it.The tolerance value is used to check that points are not too close to each other, or tangential vectors not too small. The resulting BSpline curve will beC2 or second degree continuous, except where a tangency constraint is defined on a point through which the curve passes. In this case, it will be only C1continuous.
+
+3D Approximation
+---------------
+The class *PointsToBSpline* from GeomAPI package allows building a 3D BSplinecurve, which approximates a set of points. It is necessary to define the lowest and highest degree of the curve, its continuity and tolerance. The tolerance value is used to check that points are not too close to each other,or that tangential vectors are not too small.
+
+The resulting BSpline curve will be C2 or second degree continuous, except where a tangency constraint is defined on a point, through which the curve passes. In this case, it will be only C1 continuous. This class is instantiated as follows:
+
+~~~~~
+GeomAPI_PointsToBSpline
+Approx(Points,DegMin,DegMax,Continuity, Tol);
+~~~~~
+
+From this object, the BSpline curve may be requested as follows:
+~~~~~
+Handle(Geom_BSplineCurve) K = Approx.Curve();
+~~~~~
+
+Surface Approximation
+---------------------
+The class **PointsToBSplineSurface** from GeomAPI package allows building a BSpline surface, which approximates or interpolates a set of points.
+
+@subsubsection occt_modat_1_1_3 Advanced Approximation
+
+Packages *AppDef* and *AppParCurves* provide low-level functions, allowing more control over the approximations.
+
+Approximation by multiple point constraints
+-------------------------------------------
+*AppDef* package provides low-level tools to allow parallel approximation of groups of points into Bezier or B-Spline curves using multiple point constraints.
+
+The following low level services are provided:
+* Definition of an array of point constraints:
+The class *MultiLine* allows defining a given number of multipoint constraints in order to build the multi-line, multiple lines passing through ordered multiple point constraints.
+
+
+
+In this image:
+ * *Pi*, *Qi*, *Ri* ... *Si* can be 2D or 3Dpoints.
+ * Defined as a group: *Pn*, *Qn*, *Rn,* ... *Sn* form a MultipointConstraint. They possess the same passage, tangency and curvature constraints.
+ * *P1*, *P2*, ... *Pn*, or the *Q*, *R*, ... or *S* series represent the lines to be approximated.
+
+* Definition of a set of point constraints:
+The class **MultiPointConstraint** allows defining a multiple point constraint and computing the approximation of sets of points to several curves.
+
+* Computation of an approximation of a Bezier curve from a set of points:
+The class *Compute* allows making an approximation of a set of points to a Bezier curve
+
+* Computation of an approximation of a BSpline curve from a set of points:
+The class **BSplineCompute** allows making an approximation of a set of points to a BSpline curve.
+
+* Definition of Variational Criteria:
+The class *TheVariational* allows fairing the approximation curve to a given number of points using a least squares method in conjunction with a variational criterion, usually the weights at each constraint point.
+
+Approximation by parametric or geometric constraints
+----------------------------------------------------
+
+*AppParCurves* package provides low-level tools to allow parallel approximation of groups of points into Bezier or B-Spline curve with parametric or geometric constraints, such as a requirement for the curve to pass through given points, or to have a given tangency or curvature at a particular point.
+
+The algorithms used include:
+- the least squares method
+- a search for the best approximation within a given tolerance value.
+
+The following low-level services are provided:
+
+* Association of an index to an object:
+The class *ConstraintCouple* allows you associating an index to an object to compute faired curves using *AppDef_TheVariational*.
+
+* Definition of a set of approximations of Bezier curves:
+The class *MultiCurve* allows defining the approximation of a multi-line made up of multiple Bezier curves.
+
+* Definition of a set of approximations of BSpline curves:
+The class *MultiBSpCurve* allows defining the approximation of a multi-line made up of multiple BSpline curves.
+
+* Definition of points making up a set of point constraints
+The class *MultiPoint* allows defining groups of 2D or 3D points making up a multi-line.
+
+@subsection occt_modat_1_2 Direct Construction
+
+Direct Construction methods from *gce*, *GC* and *GCE2d* packages provide simplified algorithms to build elementary geometric entities such as lines, circles and curves. They complement the reference definitions provided by the *gp*, *Geom* and *Geom2d *packages.
+
+For example, to construct a circle from a point and a radius using the *gp* package, it is necessary to construct axis *Ax2d* before creating the circle. If *gce* package is used, and *Ox* is taken for the axis, it is possible to create a circle directly from a point and a radius.
+
+@subsubsection occt_modat_1_2_1 Non-persistent entities
+
+The following algorithms used to build entities from non-persistent *gp* entities are provided by *gce* package.
+- 2D line parallel to another at a distance,
+- 2D line parallel to another passing through a point,
+- 2D circle passing through two points,
+- 2D circle parallel to another at a distance,
+- 2D circle parallel to another passing through a point,
+- 2D circle passing through three points,
+- 2D circle from a center and a radius,
+- 2D hyperbola from five points,
+- 2D hyperbola from a center and two apexes,
+- 2D ellipse from five points,
+- 2D ellipse from a center and two apexes,
+- 2D parabola from three points,
+- 2D parabola from a center and an apex,
+- line parallel to another passing through a point,
+- line passing through two points,
+- circle coaxial to another passing through a point,
+- circle coaxial to another at a given distance,
+- circle passing through three points,
+- circle with its center, radius, and normal to the plane,
+- circle with its axis (center + normal),
+- hyperbola with its center and two apexes,
+- ellipse with its center and two apexes,
+- plane passing through three points,
+- plane from its normal,
+- plane parallel to another plane at a given distance,
+- plane parallel to another passing through a point,
+- plane from an array of points,
+- cylinder from a given axis and a given radius,
+- cylinder from a circular base,
+- cylinder from three points,
+- cylinder parallel to another cylinder at a given distance,
+- cylinder parallel to another cylinder passing through a point,
+- cone from four points,
+- cone from a given axis and two passing points,
+- cone from two points (an axis) and two radii,
+- cone parallel to another at a given distance,
+- cone parallel to another passing through a point,
+- all transformations (rotations, translations, mirrors,scaling transformations, etc.).
+
+Each class from *gp* package, such as *Circ, Circ2d, Mirror, Mirror2d*, etc., has the corresponding *MakeCirc, MakeCirc2d, MakeMirror, MakeMirror2d*, etc. class from *gce* package.
+
+It is possible to create a point using a *gce* package class, then question it to recover the corresponding *gp* object.
+
+**Example **
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ gp_Pnt2d Point1,Point2;
+ ...
+ //Initialization of Point1 and Point2
+ gce_MakeLin2d L = gce_MakeLin2d(Point1,Point2);
+ if (L.Status() == gce_Done() ){
+ gp_Lin2d l = L.Value();
+ }
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+This is useful if you are uncertain as to whether the arguments can create the *gp* object without raising an exception. In the case above, if *Point1* and *Point2* are closer than the tolerance value required by *MakeLin2d*, the function *Status* will return the enumeration *gce_ConfusedPoint*. This tells you why the *gp* object cannot be created. If you know that the points *Point1* and *Point2*are separated by the value exceeding the tolerance value, then you may create the *gp* object directly, as follows:
+
+**Example **
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+gp_Lin2d l = gce_MakeLin2d(Point1,Point2);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@subsubsection occt_modat_1_2_2 Persistent entities
+
+*GC* and *GCE2d* packages provides an implementation of algorithms used to build entities from *Geom* and *Geom2D* packages. They implement the same algorithms as the *gce* package but create **persistent** entities, and also contain algorithms for trimmed surfaces and curves. The following algorithms are available:
+- arc of a circle trimmed by two points,
+- arc of a circle trimmed by two parameters,
+- arc of a circle trimmed by one point and one parameter,
+- arc of an ellipse from an ellipse trimmed by two points,
+- arc of an ellipse from an ellipse trimmed by two parameters,
+- arc of an ellipse from an ellipse trimmed by one point and one parameter,
+- arc of a parabola from a parabola trimmed by two points,
+- arc of a parabola from a parabola trimmed by two parameters,
+- arc of a parabola from a parabola trimmed by one point and one parameter,
+- arc of a hyperbola from a hyperbola trimmed by two points,
+- arc of a hyperbola from a hyperbola trimmed by two parameters,
+- arc of a hyperbola from a hyperbola trimmed by one point and one parameter,
+- segment of a line from two points,
+- segment of a line from two parameters,
+- segment of a line from one point and one parameter,
+- trimmed cylinder from a circular base and a height,
+- trimmed cylinder from three points,
+- trimmed cylinder from an axis, a radius, and a height,
+- trimmed cone from four points,
+- trimmed cone from two points (an axis) and a radius,
+- trimmed cone from two coaxial circles.
+
+Each class from *GCE2d* package, such as *Circle, Ellipse, Mirror*, etc., has the corresponding *MakeCircle, MakeEllipse, MakeMirror*, etc. class from *Geom2d* package.
+Besides, the class *MakeArcOfCircle* returns an object of type *TrimmedCurve* from *Geom2d*.
+
+Each class from *GC* package, such as *Circle, Ellipse, Mirror*, etc., has the corresponding *MakeCircle, MakeEllipse, MakeMirror*, etc. class from *Geom* package.
+The following classes return objects of type *TrimmedCurve* from *Geom*:
+- *MakeArcOfCircle*
+- *MakeArcOfEllipse*
+- *MakeArcOfHyperbola*
+- *MakeArcOfParabola*
+- *MakeSegment*
+
+@subsection occt_modat_1_3 Conversion to and from BSplines
+
+The following algorithms to convert geometric curves or surfaces into their BSpline or Bezier equivalents are provided by *GeomConvert*, *Geom2dConvert* and *Convert* packages:
+- Conversion of a conic into a rational BSpline.
+- Conversion of an elementary surface into a rational Bspline.
+- Conversion of a BSpline or Bezier curve into two or more Bezier curves or surfaces.
+- Conversion of a BSpline curve or surface into two or more BSplinecurves or surfaces with constraints on continuity.
+- Conversion of a set of joining Bezier curves into a BSplinecurve.
+- Conversion of a polynomial representation into a BSpline curve.
+
+@subsection occt_modat_1_4 Points on Curves
+
+The following characteristic points exist on parameterized curves in 3d space:
+- points equally spaced on a curve,
+- points distributed along a curve with equal chords,
+- a point at a given distance from another point on a curve.
+
+*GCPnts* package provides algorithms to calculate such points:
+- *AbscissaPoint* calculates a point on a curve at a given distance from another point on the curve.
+- *UniformAbscissa* calculates a set of points at a given abscissa on a curve.
+- *UniformDeflection* calculates a set of points at maximum constant deflection between the curve and the polygon that results from the computed points.
+
+Example: Visualizing a curve.
+-----------------------------
+
+Let us take an adapted curve **C**, i.e. an object which is an interface between the services provided by either a 2D curve from the package Geom2d (in case of an Adaptor_Curve2d curve) or a 3D curve from the package Geom (in case of an Adaptor_Curve curve), and the services required on the curve by the computation algorithm. The adapted curve is created in the following way:
+
+**case 2D:**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ Handle(Geom2d_Curve) mycurve = ... ;
+ Geom2dAdaptor_Curve C (mycurve) ;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+**case 3D:**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ Handle(Geom_Curve) mycurve = ... ;
+ GeomAdaptor_Curve C (mycurve) ;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The algorithm is then constructed with this object:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ GCPnts_UniformDeflection myAlgo () ;
+ Standard_Real Deflection = ... ;
+ myAlgo.Initialize ( C , Deflection ) ;
+ if ( myAlgo.IsDone() )
+ {
+ Standard_Integer nbr = myAlgo.NbPoints() ;
+ Standard_Real param ;
+ for ( Standard_Integer i = 1 ; i = nbr ; i++ )
+ {
+ param = myAlgo.Parameter (i) ;
+ ...
+ }
+ }
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+@subsection occt_modat_1_5 Extrema
+
+The classes to calculate the minimum distance between points, curves, and surfaces in 2d and 3d are provided by *GeomAPI* and *Geom2dAPI* packages.
+
+These packages calculate the extrema of distance between:
+- point and a curve,
+- point and a surface,
+- two curves,
+- a curve and a surface,
+- two surfaces.
+
+@subsubsection occt_modat_1_5_1 Extrema between Curves
+
+The *Geom2dAPI_ExtremaCurveCurve* class allows calculation of all extrema between two 2D geometric curves. Extrema are the lengths of the segments orthogonal to two curves.
+
+The *GeomAPI_ExtremaCurveCurve* class allows calculation of all extrema between two 3D geometric curves. Extrema are the lengths of the segments orthogonal to two curves.
+
+@subsubsection occt_modat_1_5_2 Extrema between Curve and Surface
+
+The *GeomAPI_ExtremaCurveSurface* class allows calculation of all extrema between a 3D curve and a surface. Extrema are the lengths of the segments orthogonal to the curve and the surface.
+
+@subsubsection occt_modat_1_5_3 Extrema between Surfaces
+
+The *GeomAPI_ExtremaSurfaceSurface* class allows calculation of all extrema between two surfaces. Extrema are the lengths of the segments orthogonal to two surfaces.
+
+@section occt_modat_2 2D Geometry
+
+*Geom2d* package defines geometric objects in 2dspace. All geometric entities are STEP processed. The objects are non-persistent and are handled by reference. The following objects are available:
+- point,
+- Cartesian point,
+- vector,
+- direction,
+- vector with magnitude,
+- axis,
+- curve,
+- line,
+- conic: circle, ellipse, hyperbola, pparabola,
+- rounded curve: trimmed curve, NURBS curve, Bezier curve.
+- offset curve
+
+Before creating a geometric object, it is necessary to decide how the object is handled.
+The objects provided by *Geom2d* package are handled by reference rather than by value. Copying an instance copies the handle, not the object, so that a change to one instance is reflected in each occurrence of it.
+If a set of object instances is needed rather than a single object instance, *TColGeom2d* package can be used. This package provides standard and frequently used instantiations of one-dimensional arrays and sequences for curves from *Geom2d* package. All objects are available in two versions:
+- handled by reference and
+- handled by value.
+
+@section occt_modat_3 3D Geometry
+
+The *Geom* package defines geometric objects in 3d space and contains all basic geometric transformations, such as identity, rotation, translation, mirroring, scale transformations, combinations of transformations, etc. as well as special functions depending on the reference definition of the geometric object (e.g. addition of a control point on a B-Spline curve,modification of a curve, etc.). All geometrical entities are STEP processed. The following non-persistent and reference-handled objects are available:
+- Point
+- Cartesian point
+- Vector
+- Direction
+- Vector with magnitude
+- Axis
+- Curve
+- Line
+- Conic: circle, ellipse, hyperbola, parabola
+- Offset curve
+- Elementary surface: plane, cylinder, cone, sphere, torus
+- Bounded curve: trimmed curve, NURBS curve, Bezier curve
+- Bounded surface: rectangular trimmed surface, NURBS surface,Bezier surface
+- Swept surface: surface of linear extrusion, surface of revolution
+- Offset surface.
+
+If a set of object instances is needed rather than a single object instance, *TColGeom* package can be used. This package provides instantiations of one- and two-dimensional arrays and sequences for curves from *Geom* package. All objects are available in two versions:
+- handled by reference and
+- handled by value.
+
+@subsection occt_modat_4 Local Properties of Curves and Surfaces
+
+Packages **GeomLProp**, **Geom2dLProp** provide algorithms calculating the local properties of curves and surfaces
+
+A curve (for one parameter) has the following local properties:
+- Point
+- Derivative
+- Tangent
+- Normal
+- Curvature
+- Center of curvature.
+
+A surface (for two parameters U and V) has the following local properties:
+- point
+- derivative for U and V)
+- tangent line (for U and V)
+- normal
+- max curvature
+- min curvature
+- main directions of curvature
+- mean curvature
+- Gaussian curvature
+
+The following methods are available:
+* *CLProps* - calculates the local properties of a curve (tangency, curvature,normal);
+* *CurAndInf2d* - calculates the maximum and minimum curvatures and the inflection points of 2d curves;
+* *SLProps* - calculates the local properties of a surface (tangency, the normal and curvature).
+* *Continuity* - calculates regularity at the junction of two curves.
+
+Note that the B-spline curve and surface are accepted but they are not cut into pieces of the desired continuity. It is the global continuity, which is seen.
+
+
+@section occt_modat_5 Topology
+
+Open CASCADE Technology Topology allows accessing and manipulating objects data without dealing with their 2D or 3D representations. Whereas OCCT Geometry provides a description of objects in terms of coordinates or parametric values, Topology describes data structures of objects in parametric space. These descriptions use location in and restriction of parts of this space.
+
+To provide its descriptions, OCCT abstract topology offers the following services:
+- Keeping track of Location of shapes
+- Naming shapes, sub-shapes, their orientations and states
+- Manipulating shapes and sub-shapes
+- Exploring topological data structures
+- Using lists and maps of shapes
+
+
+@subsection occt_modat_5_1 Shape Location
+
+A local coordinate system can be viewed as either of the following:
+- A right-handed trihedron with an origin and three orthonormal vectors. The **gp_Ax2** package corresponds to this definition.
+- A transformation of a +1 determinant, allowing the transformation of coordinates between local and global references frames. This corresponds to the **gp_Trsf**.
+
+*TopLoc* package distinguishes two notions:
+- *TopLoc_Datum3D* class provides the elementary reference coordinate, represented by a right-handed orthonormal system of axes or by a right-handed unitary transformation.
+- *TopLoc_Location* class provides the composite reference coordinate made from elementary ones. It is a marker composed of a chain of references to elementary markers. The resulting cumulative transformation is stored in order to avoid recalculating the sum of the transformations for the whole list.
+
+
+
+Two reference coordinates are equal if they are made up of the same elementary coordinates in the same order. There is no numerical comparison. Two coordinates can thus correspond to the same transformation without being equal if they were not built from the same elementary coordinates.
+
+For example, consider three elementary coordinates:
+R1, R2, R3
+The composite coordinates are:
+C1 = R1 * R2,
+C2 = R2 * R3
+C3 = C1 * R3
+C4 = R1 * C2
+
+**NOTE** C3 and C4 are equal because they are both R1 * R2 * R3.
+
+The TopLoc package is chiefly targeted at the topological data structure, but it can be used for other purposes.
+
+Change of coordinates
+---------------------
+
+*TopLoc_Datum3D* class represents a change of elementary coordinates. Such changes must be shared so this class inherits from *MMgt_TShared*. The coordinate is represented by a transformation *gp_Trsfpackage*. This transformation has no scaling factor.
+
+
+@subsection occt_modat_5_2 Naming shapes, sub-shapes, their orientation and state
+
+The **TopAbs** package provides general enumerations describing the basic concepts of topology and methods to handle these enumerations. It contains no classes. This package has been separated from the rest of the topology because the notions it contains are sufficiently general to be used by all topological tools. This avoids redefinition of enumerations by remaining independent of modeling resources. The TopAbs package defines three notions:
+- Topological type (TopAbs_ShapeEnum)
+- Orietation (TopAbs_Orientation)
+- StateTopAbs_State)
+
+
+@subsubsection occt_modat_5_2_1 Topological types
+
+TopAbs contains the *TopAbs_ShapeEnum* enumeration,which lists the different topological types:
+- COMPOUND - a group of any type of topological objects.
+- COMPSOLID - a composite solid is a set of solids connected by their faces. It expands the notions of WIRE and SHELL to solids.
+- SOLID - a part of space limited by shells. It is three dimensional.
+- SHELL - a set of faces connected by their edges. A shell can be open or closed.
+- FACE - in 2D it is a part of a plane; in 3D it is a part of a surface. Its geometry is constrained (trimmed) by contours. It is two dimensional.
+- WIRE - a set of edges connected by their vertices. It can be an open or closed contour depending on whether the edges are linked or not.
+- EDGE - a topological element corresponding to a restrained curve. An edge is generally limited by vertices. It has one dimension.
+- VERTEX - a topological element corresponding to a point. It has zero dimension.
+- SHAPE - a generic term covering all of the above.
+
+A topological model can be considered as a graph of objects with adjacency relationships. When modeling a part in 2D or 3D space it must belong to one of the categories listed in the ShapeEnum enumeration. The TopAbspackage lists all the objects, which can be found in any model. It cannot be extended but a subset can be used. For example, the notion of solid is useless in 2D.
+
+The terms of the enumeration appear in order from the most complex to the most simple, because objects can contain simpler objects in their description. For example, a face references its wires, edges, and vertices.
+
+
+@subsubsection occt_modat_5_2_2 Orientation
+
+The notion of orientation is represented by the **TopAbs_Orientation** enumeration. Orientation is a generalized notion of the sense of direction found in various modelers. This is used when a shape limits a geometric domain; and is closely linked to the notion of boundary. The three cases are the following:
+- Curve limited by a vertex.
+- Surface limited by an edge.
+- Space limited by a face.
+
+In each case the topological form used as the boundary of a geometric domain of a higher dimension defines two local regions of which one is arbitrarily considered as the **default region**.
+
+For a curve limited by a vertex the default region is the set of points with parameters greater than the vertex. That is to say it is the part of the curve after the vertex following the natural direction along the curve.
+
+For a surface limited by an edge the default region is on the left of the edge following its natural direction. More precisely it is the region pointed to by the vector product of the normal vector to the surface and the vector tangent to the curve.
+
+For a space limited by a face the default region is found on the negative side of the normal to the surface.
+
+Based on this default region the orientation allows definition of the region to be kept, which is called the *interior* or *material*. There are four orientations defining the interior.
+
+|FORWARD | The interior is the default region.|
+|REVERSED | The interior is the region complementary to the default.|
+|INTERNAL | The interior includes both regions. The boundary lies inside the material. For example a surface inside a solid.|
+|EXTERNAL | The interior includes neither region. The boundary lies outside the material. For example an edge in a wire-frame model.|
+
+
+
+The notion of orientation is a very general one, and it can be used in any context where regions or boundaries appear. Thus, for example, when describing the intersection of an edge and a contour it is possible to describe not only the vertex of intersection but also how the edge crosses the contour considering it as a boundary. The edge would therefore be divided into two regions - exterior and interior - with the intersection vertex as the boundary. Thus an orientation can be associated with an intersection vertex as in the following figure:
+
+|FORWARD | Entering |
+|REVERSED | Exiting |
+|INTERNAL | Touching from inside |
+|EXTERNAL | Touching from outside |
+
+
+
+
+Along with the Orientation enumeration the *TopAbs* package defines four methods:
+
+@subsubsection occt_modat_5_2_3 State
+
+The **TopAbs_State** enumeration described the position of a vertex or a set of vertices with respect to a region. There are four terms:
+|IN | The point is interior. |
+|OUT | The point is exterior. |
+|ON | The point is on the boundary(within tolerance). |
+|UNKNOWN | The state of the point is indeterminate. |
+The UNKNOWN term has been introduced because this enumeration is often used to express the result of a calculation, which can fail. This term can be used when it is impossible to know if a point is inside or outside, which is the case with an open wire or face.
+
+
+
+The State enumeration can also be used to specify various parts of an object. The following figure shows the parts of an edge intersecting a face.
+
+
+
+@subsection occt_modat_5_3 Manipulating shapes and sub-shapes
+
+The *TopoDS* package describes the topological data structure with the following characteristics:
+- reference to an abstract shape with neither orientation nor location.
+- Access to the data structure through the tool classes.
+
+As stated above, OCCT Topology describes data structures of objects in parametric space. These descriptions use localization in and restriction of parts of this space. The types of shapes, which can be described in these terms, are the vertex, the face and the shape. The vertex is defined in terms of localization in parametric space, and the face and shape, in terms of restriction of this space.
+
+OCCT topological descriptions also allow the simple shapes defined in these terms to be combined into sets. For example, a set of edges forms a wire; a set of faces forms a shell, and a set of solids forms a composite solid (CompSolid in Open CASCADE Technology). You can also combine shapes of either sort into compounds. Finally, you can give a shape an orientation and a location.
+
+Listing shapes in order of complexity from vertex to composite solid leads us to the notion of the data structure as knowledge of how to break a shape down into a set of simpler shapes. This is in fact, the purpose of the *TopoDS* package.
+
+The model of a shape is a shareable data structure because it can be used by other shapes. (An edge can be used by more than one face of a solid). A shareable data structure is handled by reference. When a simple reference is insufficient, two pieces of information are added - an orientation and a local coordinate reference.
+- An orientation tells how the referenced shape is used in a boundary (*Orientation* from *TopAbs*).
+- A local reference coordinate (*Location* from *TopLoc*) allows referencing a shape at a position different from that of its definition.
+
+The **TopoDS_TShape** class is the root of all shape descriptions. It contains a list of shapes. Classes inheriting **TopoDS_TShape** can carry the description of a geometric domain if necessary (for example, a geometric point associated with a TVertex). A **TopoDS_TShape** is a description of a shape in its definition frame of reference. This class is manipulated by reference.
+
+The **TopoDS_Shape** class describes a reference to a shape. It contains a reference to an underlying abstract shape, an orientation,and a local reference coordinate. This class is manipulated by value and thus cannot be shared.
+
+The class representing the underlying abstract shape is never referenced directly. The *TopoDS_Shape* class is always used to refer to it.
+
+The information specific to each shape (the geometric support) is always added by inheritance to classes deriving from **TopoDS_TShape**.The following figures show the example of a shell formed from two faces connected by an edge.
+
+
+
+
+
+In the previous diagram, the shell is described by the underlying shape TS, and the faces by TF1 and TF2. There are seven edges from TE1 to TE7 and six vertices from TV1 to TV6.
+
+The wire TW1 references the edges from TE1 to TE4; TW2 references from TE4 to TE7.
+
+The vertices are referenced by the edges as follows:TE1(TV1,TV4), TE2(TV1,TV2), TE3(TV2,TV3), TE4(TV3,TV4), TE5(TV4,TV5), TE6(T5,TV6),TE7(TV3,TV6).
+
+**Note** that this data structure does not contain any *back references*. All references go from more complex underlying shapes to less complex ones. The techniques used to access the information are described later. The data structure is as compact as possible. Sub-objects can be shared among different objects.
+
+Two very similar objects, perhaps two versions of the same object, might share identical sub-objects. The usage of local coordinates in the data structure allows the description of a repetitive sub-structure to be shared.
+
+The compact data structure avoids the loss of information associated with copy operations which are usually used in creating a new version of an object or when applying a coordinate change.
+
+The following figure shows a data structure containing two versions of a solid. The second version presents a series of identical holes bored at different positions. The data structure is compact and yet keeps all information on the sub-elements.
+
+The three references from *TSh2* to the underlying face *TFcyl* have associated local coordinate systems, which correspond to the successive positions of the hole.
+
+
+Classes inheriting TopoDS_Shape
+------------------------------
+*TopoDS* is based on class *TopoDS_Shape* and the class defining its underlying shape. This has certain advantages, but the major drawback is that these classes are too general. Different shapes they could represent do not type them (Vertex, Edge, etc.) hence it is impossible to introduce checks to avoid incoherences such as inserting a face in an edge.
+
+ *TopoDS* package offers two sets of classes, one set inheriting the underlying shape with neither orientation nor location and the other inheriting *TopoDS_Shape*, which represent the standard topological shapes enumerated in *TopAbs* package.
+
+The following classes inherit Shape : *TopoDS_Vertex, TopoDS_Edge, TopoDS_Wire, TopoDS_Face, TopoDS_Shell, TopoDS_Solid,TopoDS_CompSolid,* and *TopoDS_Compound*. In spite of the similarity of names with those inheriting from **TopoDS_TShape** there is a profound difference in the way they are used.
+
+*TopoDS_Shape* class and the classes, which inherit from it, are the natural means to manipulate topological objects. *TopoDS_TShape* classes are hidden. *TopoDS_TShape* describes a class in its original local coordinate system without orientation. *TopoDS_Shape* is a reference to *TopoDS_TShape* with an orientation and a local reference.
+
+*TopoDS_TShape* class is deferred; *TopoDS_Shape* class is not. Using *TopoDS_Shape* class allows manipulation of topological objects without knowing their type. It is a generic form. Purely topological algorithms often use the *TopoDS_Shape* class.
+
+*TopoDS_TShape* class is manipulated by reference; TopoDS_Shape class by value. A TopoDS_Shape is nothing more than a reference enhanced with an orientation and a local coordinate. The sharing of *TopoDS_Shapes* is meaningless. What is important is the sharing of the underlying *TopoDS_TShapes*. Assignment or passage in argument does not copy the data structure: this only creates new *TopoDS_Shapes* which refer to the same *TopoDS_TShape*.
+
+Although classes inheriting *TopoDS_TShape* are used for adding extra information, extra fields should not be added in a class inheriting from TopoDS_Shape. Classes inheriting from TopoDS_Shape serve only to specialize a reference in order to benefit from static type control (carried out by the compiler). For example, a routine that receives a *TopoDS_Face* in argument is more precise for the compiler than the one, which receives a *TopoDS_Shape*. It is pointless to derive other classes than those found inTopoDS. All references to a topological data structure are made with the Shape class and its inheritors defined in *TopoDS*.
+
+There are no constructors for the classes inheriting from the *TopoDS_Shape* class, otherwise the type control would disappear through **implicit casting** (a characteristic of C++). The TopoDS package provides package methods for **casting** an object of the TopoDS_Shape class in one of these sub-classes, with type verification.
+
+The following example shows a routine receiving an argument of the *TopoDS_Shape* type, then putting it into a variable V if it is a vertex or calling the method ProcessEdge if it is an edge.
+
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ #include TopoDS_Vertex.hxx
+ #include TopoDS_Edge.hxx
+ #include TopoDS_Shape.hxx
+
+
+ voidProcessEdge(const TopoDS_Edge&);
+
+ voidProcess(const TopoDS_Shape& aShape) {
+ if (aShape.Shapetype() == TopAbs_VERTEX) {
+ TopoDS_Vertex V;
+ V = TopoDS::Vertex(aShape); // Also correct
+ TopoDS_Vertex V2 = aShape;// Rejected by compiler
+ TopoDS_Vertex V3 = TopoDS::Vertex(aShape); // Correct
+ }
+ else if (aShape.ShapeType() == TopAbs_EDGE){
+ ProcessEdge(aShape) ;// Thisis rejected
+ ProcessEdge(TopoDS::Edge(aShape)) ; // Correct
+ }
+ else {
+ cout *Neither a vertex nor an edge ?* ;
+ ProcessEdge(TopoDS::Edge(aShape)) ;
+ // OK for compiler but anexception will be raised at run-time
+ }
+ }
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+
+@subsection occt_modat_5_4 Exploration of Topological Data Structures
+
+The *TopExp* package provides tools for exploring the data structure described with the *TopoDS* package. Exploring a topological structure means finding all sub-objects of a given type, for example, finding all the faces of a solid.
+
+The TopExp package provides the class *TopExp_Explorer* to find all sub-objects of a given type. An explorer is built with:
+- The shape to be explored.
+- The type of shapes to be found e.g. VERTEX, EDGE with the exception of SHAPE, which is not allowed.
+- The type of Shapes to avoid. e.g. SHELL, EDGE. By default, this type is SHAPE. This default value means that there is no restriction on the exploration.
+
+
+
+The Explorer visits the whole structure in order to find the shapes of the requested type not contained in the type to avoid. The example below shows how to find all faces in the shape *S*:
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ void test() {
+ TopoDS_Shape S;
+ TopExp_Explorer Ex;
+ for (Ex.Init(S,TopAbs_FACE); Ex.More(); Ex.Next()) {
+ ProcessFace(Ex.Current());
+ }
+ }
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To find all the vertices which are not in an edge:
+
+**Example **
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+for (Ex.Init(S,TopAbs_VERTEX,TopAbs_EDGE); ...)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+To find all the faces in a SHELL, then all the faces not in a SHELL:
+
+
+**Example **
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ void test() {
+ TopExp_Explorer Ex1, Ex2;
+ TopoDS_Shape S;
+ for (Ex1.Init(S,TopAbs_SHELL);Ex1.More(); Ex1.Next()){
+ // visit all shells
+ for (Ex2.Init(Ex1.Current(),TopAbs_FACE);Ex2.More();
+ Ex2.Next()){
+ //visit all the faces of the current shell
+ ProcessFaceinAshell(Ex2.Current());
+ ...
+ }
+ }
+ for(Ex1.Init(S,TopAbs_FACE,TopAbs_SHELL);Ex1.More(); Ex1.Next()){
+ // visit all faces not ina shell.
+ ProcessFace(Ex1.Current());
+ }
+ }
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The Explorer presumes that objects contain only objects of an equal or inferior type. For example, if searching for faces it does not lookat wires, edges, or vertices to see if they contain faces.
+
+The *MapShapes* method from *TopExp* package allows filling a Map. An exploration using the Explorer class can visit an object more than once if it is referenced more than once. For example, an edge of a solid is generally referenced by two faces. To process objects only once, they have to be placed in a Map.
+
+**Example **
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ void TopExp::MapShapes (const TopoDS_Shape& S,
+ const TopAbs_ShapeEnum T,
+ TopTools_IndexedMapOfShape& M)
+ {
+ TopExp_Explorer Ex(S,T);
+ while (Ex.More()) {
+ M.Add(Ex.Current());
+ Ex.Next();
+ }
+ }
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In the following example all faces and all edges of an object are drawn in accordance with the following rules:
+- The faces are represented by a network of *NbIso* iso-parametric lines with *FaceIsoColor* color.
+- The edges are drawn in a color, which indicates the number of faces sharing the edge:
+1. FreeEdgeColor for edges, which do not belong to a face (i.e. wireframe element).
+2. BorderEdgeColor for an edge belonging to a single face.
+3. SharedEdgeColor for an edge belonging to more than one face.
+- The methods **DrawEdge** and **DrawFaceIso** are also available to display individual edges and faces.
+
+The following steps are performed:
+1. Storing the edges in a map and create in parallel an array of integers to count the number of faces sharing the edge. This array is initialized to zero.
+2. Exploring the faces. Each face is drawn.
+3. Exploring the edges and for each of them increment the counter of faces in the array.
+4. From the Map of edges, drawing each edge with the color corresponding to the number of faces.
+
+
+**Example **
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ void DrawShape ( const TopoDS_Shape& aShape,
+ const Standard_Integer nbIsos,
+ const Color FaceIsocolor,
+ const Color FreeEdgeColor,
+ const Color BorderEdgeColor,
+ const Color SharedEdgeColor)
+ {
+ // Store the edges in aMap.
+ TopTools_IndexedMapOfShape edgemap;
+ TopExp::MapShapes(aShape,TopAbs_EDGE,edgeMap);
+ // Create an array set to zero.
+ TColStd_Array1OfInteger faceCount(1,edgeMap.Extent());
+ faceCount.Init (0);
+ // Explore the faces.
+ TopExp_Explorer expFace(aShape,TopAbs_FACE);
+ while (expFace.More()) {
+ //Draw the current face.
+ DrawFaceIsos(TopoDS::Face(expFace.Current()),nbIsos,FaceIsoColor);
+ // Explore the edges ofthe face.
+ TopExp_Explorer expEdge(expFace.Current(),TopAbs_EDGE);
+ while (expEdge.More()) {
+ //Increment the face count for this edge.
+ faceCount(edgemap.FindIndex(expEdge.Current()))++;
+ expEdge.Next();
+ }
+ expFace.Next();
+ }
+ //Draw the edges of theMap
+ Standard_Integer i;
+ for (i=1;i=edgemap.Extent();i++) {
+ switch (faceCount(i)) {
+ case 0 :
+ DrawEdge(TopoDS::Edge(edgemap(i)),FreeEdgeColor);
+ break;
+ case 1 :
+ DrawEdge(TopoDS::Edge(edgemap(i)),BorderEdgeColor);
+ break;
+ default :
+ DrawEdge(TopoDS::Edge(edgemap(i)),SharedEdgeColor);
+ break;
+ }
+ }
+ }
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@subsection occt_modat_5_5 Lists and Maps of Shapes
+
+**TopTools** package contains tools for exploiting the *TopoDS* data structure. It is an instantiation of the tools from *TCollection* package with the Shape classes of *TopoDS*.
+
+| *TopTools_Array1OfShape, HArray1OfShape* | Instantiation of the *TCollection_Array1* and *TCollection_HArray1* with *TopoDS_Shape*. |
+| *TopTools_SequenceOfShape* | Instantiation of the *TCollection_Sequence* with *TopoDS_Shape*. |
+| *TopTools_MapOfShape* | Instantiation of the *TCollection_Map*. Allows the construction of sets of shapes. |
+| *TopTools_IndexedMapOfShape* | Instantiation of the *TCollection_IndexedMap*. Allows the construction of tables of shapes and other data structures. |
+
+With a **TopTools_Map**, a set of references to Shapes can be kept without duplication.
+The following example program counts the size of a data structure as a number of TShapes.
+
+**Example **
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ #include TopoDS_Iterator.hxx
+ Standard_Integer Size(const TopoDS_Shape& aShape)
+ {
+ // This is a recursive method.
+ // The size of a shape is1 + the sizes of the subshapes.
+ TopoDS_Iterator It;
+ Standard_Integer size = 1;
+ for (It.Initialize(aShape);It.More();It.Next()) {
+ size += Size(It.Value());
+ }
+ return size;
+ }
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This program is incorrect if there is sharing in the data structure.
+Thus for a contour of four edges it should count 1 wire + 4 edges +4 vertices
+with the result 9, but as the vertices are each shared by two edges this program will return 13.
+One solution is to put all the Shapes in a Map so as to avoid counting them twice, as in the following example:
+
+**Example **
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ #include TopoDS_Iterator.hxx
+ #includeTopTools_MapOfShape.hxx
+
+ void MapShapes(const TopoDS_Shape& aShape,
+ TopTools_MapOfShape& aMap)
+ {
+ //This is a recursive auxiliary method. It stores all subShapes of aShape in a Map.
+ if (aMap.Add(aShape)) {
+ //Add returns True if aShape was not already in the Map.
+ TopoDS_Iterator It;
+ for (It.Initialize(aShape);It.More();It.Next()){
+ MapShapes(It.Value(),aMap);
+ }
+ }
+ }
+
+ Standard_Integer Size(const TopoDS_Shape& aShape)
+ {
+ // Store Shapes in a Mapand return the size.
+ TopTools_MapOfShape M;
+ MapShapes(aShape,M);
+ return M.Extent();
+ }
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+**Note** For more details about Maps see the TCollection documentation.(Foundation Classes Reference Manual)
+
+The following example is more ambitious and writes a program which copies a data structure using an IndexedMap. The copy is an identical structure but it shares nothing with the original. The principal algorithm is as follows:
+- All Shapes in the structure are put into an IndexedMap.
+- A table of Shapes is created in parallel with the map to receive the copies.
+- The structure is copied using the auxiliary recursive function,which copies from the map to the array.
+
+**Example **
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ #include TopoDS_Shape.hxx
+ #include TopoDS_Iterator.hxx
+ #include TopTools_IndexedMapOfShape.hxx
+ #include TopTools_Array1OfShape.hxx
+ #include TopoDS_Location.hxx
+
+ TopoDS_Shape Copy(const TopoDS_Shape& aShape,
+ const TopoDS_Builder& aBuilder)
+ {
+ // Copies the wholestructure of aShape using aBuilder.
+ // Stores all thesub-Shapes in an IndexedMap.
+ TopTools_IndexedMapOfShape theMap;
+ TopoDS_Iterator It;
+ Standard_Integer i;
+ TopoDS_Shape S;
+ TopLoc_Location Identity;
+ S = aShape;
+ S.Location(Identity);
+ S.Orientation(TopAbs_FORWARD);
+ theMap.Add(S);
+ for (i=1; i= theMap.Extent(); i++) {
+ for(It.Initialize(theMap(i)); It.More(); It.Next()) {
+ S=It.Value();
+ S.Location(Identity);
+ S.Orientation(TopAbs_FORWARD);
+ theMap.Add(S);
+ }
+ }
+ }
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+In the above example, the index *i* is that of the first object not treated in the Map. When *i* reaches the same size as the Map this means that everything has been treated. The treatment consists of inserting in the Map all the sub-objects, if they are not yet in the Map, they are inserted with an index greater than *i*.
+
+**Note** that the objects are inserted with a local reference set to the identity and a FORWARD orientation. Only the underlying TShape is of great interest.
+
+**Example **
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ //Create an array to store the copies.
+ TopTools_Array1OfShapetheCopies(1,theMap.Extent());
+
+ // Use a recursivefunction to copy the first element.
+ void AuxiliaryCopy (Standard_Integer,
+ const TopTools_IndexedMapOfShape &,
+ TopTools_Array1OfShape &,
+ const TopoDS_Builder&);
+
+ AuxiliaryCopy(1,theMap,theCopies,aBuilder);
+
+ // Get the result with thecorrect local reference and orientation.
+ S = theCopies(1);
+ S.Location(aShape.Location());
+ S.Orientation(aShape.Orientation());
+ return S;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Below is the auxiliary function, which copies the element of rank *i* from the map to the table. This method checks if the object has been copied; if not copied, then an empty copy is performed into the table and the copies of all the sub-elements are inserted by finding their rank in the map.
+
+**Example **
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ void AuxiliaryCopy(Standard_Integer index,
+ const TopTools_IndexedMapOfShapes&sources,
+ TopTools_Array1OfShape&copies,
+ const TopoDS_Builder&aBuilder)
+ {
+ //If the copy is a null Shape the copy is not done.
+ if (copies(index).IsNull()) {
+ copies(index) =sources(index).EmptyCopied();
+ //Insert copies of the sub-shapes.
+ TopoDS_Iterator It;
+ TopoDS_Shape S;
+ TopLoc_Location Identity;
+ for(It.Initialize(sources(index)),It.More(), It.Next ()) {
+ S = It.Value();
+ S.Location(Identity);
+ S.Orientation(TopAbs_FORWARD);
+ AuxiliaryCopy(sources.FindIndex(S),sources,copies,aBuilder);
+ S.Location(It.Value().Location());S.Orientation(It.Value().Orientation()); aBuilder.Add(copies(index),S);
+ }
+ }
+ }
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@subsubsection occt_modat_5_5_1 Wire Explorer
+
+BRepTools_WireExplorer class can access edges of a wire in their order of connection.
+
+For example, in the wire in the image we want to recuperate the edges in the order {e1, e2, e3,e4, e5} :
+
+
+
+TopExp_Explorer, however, recuperates the lines in any order.
+
+**Example **
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ TopoDS_Wire W = ...;
+ BRepTools_WireExplorer Ex;
+ for(Ex.Init(W); Ex.More(); Ex.Next()) {
+ ProcessTheCurrentEdge(Ex.Current());
+ ProcessTheVertexConnectingTheCurrentEdgeToThePrevious
+ One(Ex.CurrentVertex());
+ }
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
\ No newline at end of file
--- /dev/null
+OCAF {#user_guides__ocaf}
+========================
+
+@section occt_ocaf_1 Introduction
+
+This manual explains how to use the Open CASCADE Application Framework (OCAF).
+It provides basic documentation on using OCAF. For advanced information on OCAF
+and its applications, see our offerings on our web site at
+<a href="http://www.opencascade.org/support/training/">www.opencascade.org/support/training/</a>
+
+OCAF (the Open CASCADE Application Framework) is a RAD (Rapid Application Development) framework used for
+specifying and organizing application data. To do this, OCAF provides:
+
+ * Ready-to-use data common to most CAD/CAM applications,
+ * A scalable extension protocol for implementing new application specific data,
+ * An infrastructure
+ * To attach any data to any topological element
+ * To link data produced by different applications (*associativity of data*)
+ * To register the modeling process - the creation history, or parametrics, used to carry out the modifications.
+
+Using OCAF, the application designer concentrates on the functionality and its specific algorithms. In this way, he avoids architectural problems notably implementing Undo-redo and saving application data.
+
+In OCAF, all of the above are already handled for the application designer, allowing him to reach a significant increase in productivity.
+
+In this respect, OCAF is much more than just one toolkit among many in the CAS.CADE Object Libraries. Since it can handle any data and algorithms in these libraries - be it modeling algorithms, topology or geometry - OCAF is a logical supplement to these libraries.
+
+The table below contrasts the design of a modeling application using object libraries alone and using OCAF.
+
+**Table 1: Services provided by OCAF**
+
+|Development tasks |Comments | Without OCAF | With OCAF |
+|------------------:|---------:|---------------:|-----------:|
+|Creation of geometry| Algorithm Calling the modeling libraries | To be created by the user | To be created by the user|
+| Data organization | Including specific attributes and modeling process | To be created by the user | Simplified|
+| Saving data in a file | Notion of document | To be created by the user | Provided |
+| Document-view management | | To be created by the user | Provided |
+| Application infrastructure | New, Open, Close, Save and Save As File menus | To be created by the user | Provided |
+| Undo-Redo | Robust, multi-level | To be created by the user | Provided |
+| Application-specific dialog boxes | | To be created by the user | To be created by the user |
+
+
+
+The relationship between OCAF and the Open CASCADE Technology (**OCCT**) Object Libraries can be seen in the image below.
+
+
+
+In the image, the OCAF (Open CASCADE Application Framework) is shown with black rectangles and OCCT Object Libraries required by OCAF are shown with white rectangles.
+
+The subsequent chapters of this document explain the concepts and show how to use the services of OCAF.
+
+@section occt_ocaf_2 Basic Concepts
+
+@subsection occt_ocaf_2_1 Overview
+
+In most existing geometric modeling systems, the data structure is shape driven. They usually use a brep model, where solids and surfaces are defined by a collection of entities such as faces, edges etc., and by attributes such as application data. These attributes are attached to the entities. Examples of application data include:
+
+ * color,
+ * material,
+ * information that a particular edge is blended.
+
+A shape, however, is inevitably tied to its underlying geometry. And geometry is highly subject to change in applications such as parametric modeling or product development. In this sort of application, using a brep (boundary representation) data structure proves to be a not very effective solution. A solution other than the shape must be found, i.e. a solution where attributes are attached to a deeper invariant structure of the model. Here, the topology itself will be one attribute among many.
+
+In OCAF, data structure is reference key-driven. The reference key is implemented in the form of labels. Application data is attached to these labels as attributes. By means of these labels and a tree structure they are organized in, the reference key aggregates all user data, not just shapes and their geometry. These attributes have similar importance; no attribute is master in respect of the others.
+
+The reference keys of a model - in the form of labels - have to be kept together in a single container. This container is called a document.
+
+|opology-driven approach | reference key-driven approach |
+|-----------------------:|------------------------------:|
+
+
+
+@subsection occt_ocaf_2_2 Applications and documents
+
+OCAF documents are in turn managed by an OCAF application, which is in charge of:
+
+ * Creating new documents
+ * Saving documents and opening them
+ * Initializing document views.
+
+Apart from their role as a container of application data, documents can refer to each other; Document A, for example, can refer to a specific label in Document B. This functionality is made possible by means of the reference key.
+
+@subsection occt_ocaf_23 The document and the data framework
+
+Inside a document, there is a data framework, a model, for example. This is a set of labels organized in a tree structure characterized by the following features:
+ * The first label in a framework is the root of the tree;
+ * Each label has a tag expressed as an integer value;
+ * Sub-labels of a label are called its children;
+ * Each label which is not the root has one father – label from an upper level of the framework;
+ * Labels which have the same father are called brothers;
+ * Brothers cannot share the same tag;
+ * A label is uniquely defined by an entry expressed as a list of tags (entry) of fathers from the root: this list of tags is written from right to left: tag of label, tag of its father, tag of father of its father,..., 0 (tag of the root label).
+
+
+
+In the above figure inside the circles are the tags of corresponding labels. Under the circles are the lists of tags. The root label always has a zero tag.
+
+The children of a root label are middle-level labels with tags 1 and 3. These labels are brothers.
+
+List of tags of the right-bottom label is «0:3:4»: this label has tag 4, its father (with entry «0:3») has tag 3, father of father has tag 0 (the root label always has «0» entry).
+
+For example, an application for designing table lamps will first allocate a label for the lamp unit (the lamp is illustrated below). The root label never has brother labels, so, for a lot of lamps in the framework allocation, one of the root label sub-labels for the lamp unit is used. By doing so, you would avoid any confusion between table lamps in the data framework. Parts of the lamp have different material, color and other attributes, so, for each sub-unit of the lamp a child label of the lamp label with specified tags is allocated:
+
+ * a lamp-shade label with tag 1
+ * a bulb label with tag 2
+ * a stem label with tag 3
+
+Label tags are chosen at will. They are just identifiers of the lamp parts. Now you can refine all units: set to the specified label geometry, color, material and other information about the lamp or it’s parts. This information is placed into special attributes of the label: the pure label contains no data – it is only a key to access data.
+
+The thing to remember is that tags are private addresses without any meaning outside the data framework. It would, for instance, be an error to use part names as tags. These might change or be removed from production in next versions of the application, whereas the exact form of that part might be what you wanted to use in your design, the part name could be integrated into the framework as an attribute.
+
+
+
+So, after the user changes the lamp design, only corresponding attributes are changed, but the label structure is maintained. The lamp shape must be recreated by new attribute values and attributes of the lamp shape must refer to a new shape.
+
+
+
+
+The previous figure shows the table-lamps document structure: each child of the root label contains a lamp shape attribute and refers to the sub-labels, which contain some design information about corresponding sub-units.
+
+The data framework structure allows to create more complex structures: each lamp label sub-label may have children labels with more detailed information about parts of the table lamp and its components.
+
+Note that the root label can have attributes too, usually global attributes: the name of the document, for example.
+
+As in the case of the table lamp example above, OCAF documents aggregate a battery of ready-to-use attributes, which represent typical data used in CAD. This data includes not only the Shape attribute, but a wide range of Standard attributes corresponding to the following types (see paragraph 6):
+
+ * Geometric attributes
+ * General attributes
+ * Relationship attributes
+ * Auxiliary attributes
+
+@subsubsection occt_ocaf_2_3_1 Documents
+
+Documents offer access to the data framework and manage the following items:
+
+ * Manage the notification of changes
+ * Update external links
+ * Manage the saving and restoring of data
+ * Store the names of software extensions.
+ * Manage command transactions
+ * Manage Undo and Redo options.
+
+@subsubsection occt_ocaf_2_3_2 Shape attribute
+
+The shape attribute implements the functionality of the OCCT topology manipulation:
+
+ * reference to the shapes
+ * tracking of shape evolution
+
+@subsubsection occt_ocaf_2_3_3 Standard attributes
+
+Several ready-to-use base attributes already exist. These allow operating with simple common data in the data framework (for example: integer, real, string, array kinds of data), realize auxiliary functions (for example: tag sources attribute for the children of the label counter), create dependencies (for example: reference, tree node)....
+
+@subsubsection occt_ocaf_2_3_4 Visualization attributes
+
+These attributes allow placing viewer information to the data framework, visual representation of objects and other auxiliary visual information, which is needed for graphical data representation.
+
+@subsubsection occt_ocaf_2_3_5 Function services
+
+Where the document manages the notification of changes, a function manages propagation of these changes. The function mechanism provides links between functions and calls to various algorithms.
+
+
+
+@section occt_ocaf_3_ Data Framework Services
+
+@subsection occt_ocaf_3_1 Overview
+
+The data framework offers a single environment in which data from different application components can be handled.
+
+This allows you to exchange and modify data simply, consistently, with a maximum level of information, and with stable semantics.
+
+The building blocks of this approach are:
+
+ * The tag
+ * The label
+ * The attribute
+
+As it has been mentioned earlier, the first label in a framework is the root label of the tree. Each label has a tag expressed as an integer value, and a label is uniquely defined by an entry expressed as a list of tags from the root, 0:1:2:1, for example.
+
+Each label can have a list of attributes, which contain data, and several attributes can be attached to a label. Each attribute is identified by a GUID, and although a label may have several attributes attached to it, it must not have more than one attribute of a single GUID.
+
+The sub-labels of a label are called its children. Conversely, each label, which is not the root, has a father. Brother labels cannot share the same tag.
+
+The most important property is that a label’s entry is its persistent address in the data framework.
+
+
+
+@subsection occt_ocaf_3_2 The Tag
+
+A tag is an integer, which identifies a label in two ways:
+
+ * Relative identification
+ * Absolute identification.
+
+In relative identification, a label’s tag has a meaning relative to the father label only. For a specific label, you might, for example, have four child labels identified by the tags 2, 7, 18, 100. In using relative identification, you ensure that you have a safe scope for setting attributes.
+
+In absolute identification, a label’s place in the data framework is specified unambiguously by a colon-separated list of tags of all the labels from the one in question to the root of the data framework. This list is called an entry. TDF_Tool::TagList allows you to retrieve the entry for a specific label.
+
+In both relative and absolute identification, it is important to remember that the value of an integer has no intrinsic semantics whatsoever. In other words, the natural sequence that integers suggest, i.e. 0, 1, 2, 3, 4 ... - has no importance here. The integer value of a tag is simply a key.
+
+The tag can be created in two ways:
+
+ * Random delivery
+ * User-defined delivery
+
+As the names suggest, in random delivery, the tag value is generated by the system in a random manner. In user-defined delivery, you assign it by passing the tag as an argument to a method.
+
+@subsubsection occt_ocaf_3_2_1 Creating child labels using random delivery of tags
+
+To append and return a new child label, you use TDF_TagSource::NewChild. In the example below, the argument *level2, which is passed to NewChild,* is a TDF_Label.
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+TDF_Label child1 = TDF_TagSource::NewChild (level2);
+TDF_Label child2 = TDF_TagSource::NewChild (level2);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@subsubsection occt_ocaf_3_2_2 Creation of a child label by user delivery from a tag
+
+The other way to create a child label from a tag is by user delivery. In other words, you specify the tag, which you want your child label to have.
+
+To retrieve a child label from a tag which you have specified yourself, you need to use TDF_Label::FindChild and TDF_Label::Tag as in the example below. Here, the integer 3 designates the tag of the label you are interested in, and the Boolean false is the value for the argument *create*. When this argument is set to *false*, no new child label is created.
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+TDF_Label achild = root.FindChild(3,Standard_False);
+if (!achild.IsNull()) {
+Standard_Integer tag = achild.Tag();
+}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@subsection occt_ocaf_3_3 The Label
+
+The tag gives a persistent address to a label. The label – the semantics of the tag – is a place in the data framework where attributes, which contain data, are attached. The data framework is, in fact, a tree of labels with a root as the ultimate father label (refer to the following figure):
+
+
+
+
+Label can not be deleted from the data framework, so, the structure of the data framework that has been created can not be removed while the document is opened. Hence any kind of reference to an existing label will be actual while an application is working with the document.
+
+@subsubsection occt_ocaf_3_3_1 Label creation
+
+Labels can be created on any labels, compared with brother labels and retrieved. You can also find their depth in the data framework (depth of the root label is 0, depth of child labels of the root is 1 and so on), whether they have children or not, relative placement of labels, data framework of this label. It is the class TDF_Label that offers the above services.
+
+@subsubsection occt_ocaf_3_3_2 Creating child labels
+
+To create a new child label in the data framework using explicit delivery of tags, use TDF_Label::FindChild.
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+//creating a label with tag 10 at Root
+TDF_Label lab1 = aDF->Root().FindChild(10);
+
+//creating labels 7 and 2 on label 10
+TDF_Label lab2 = lab1.FindChild(7);
+
+TDF_Label lab3 = lab1.FindChild(2);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+You could also use the same syntax but add the Boolean *true *as a value of the argument **create**. This ensures that a new child label will be created if none is found. Note that in the previous syntax, this was also the case since *create *is *true *by default.
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+TDF_Label level1 = root.FindChild(3,Standard_True);
+TDF_Label level2 = level1.FindChild(1,Standard_True);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+@subsubsection occt_ocaf_3_3_3 Retrieving child labels
+
+You can retrieve child labels of your current label by iteration on the first level in the scope of this label.
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+TDF_Label current;
+//
+for (TDF_ChildIterator it1 (current,Standard_False); it1.More(); it1.Next()) {
+achild = it1.Value();
+//
+// do something on a child (level 1)
+//
+}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+You can also retrieve all child labels in every descendant generation of your current label by iteration on all levels in the scope of this label.
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+for (TDF_ChildIterator itall (current,Standard_True); itall.More(); itall.Next()) {
+achild = itall.Value();
+//
+// do something on a child (all levels)
+//
+}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Using TDF_Tool::Entry with TDF_ChildIterator you can retrieve the entries of your current label’s child labels as well.
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+void DumpChildren(const TDF_Label& aLabel)
+{
+ TDF_ChildIterator it;
+ TCollection_AsciiString es;
+ for (it.Initialize(aLabel,Standard_True); it.More(); it.Next()){
+ TDF_Tool::Entry(it.Value(),es);
+ cout = as.ToCString() = endl;
+ }
+}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+@subsubsection occt_ocaf_3_3_4 Retrieving the father label
+
+Retrieving the father label of a current label.
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+TDF_Label father = achild.Father();
+isroot = father.IsRoot();
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+@subsection occt_ocaf_3_4 The Attribute
+
+The label itself contains no data. All data of any type whatsoever - application or non-application - is contained in attributes. These are attached to labels, and there are different types for different types of data. OCAF provides many ready-to-use standard attributes such as integer, real, constraint, axis and plane. There are also attributes for topological naming, functions and visualization. Each type of attribute is identified by a GUID.
+
+The advantage of OCAF is that all of the above attribute types are handled in the same way. Whatever the attribute type is, you can create new instances of them, retrieve them, attach them to and remove them from labels, «forget» and «remember» the attributes of a particular label.
+
+@subsubsection occt_ocaf_3_4_1 Retrieving an attribute from a label
+
+To retrieve an attribute from a label, you use TDF_Label::FindAttribute. In the example below, the GUID for integer attributes, and *INT*, a handle to an attribute are passed as arguments to FindAttribute for the current label.
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+if(current.FindAttribute(TDataStd_Integer::GetID(),INT))
+{
+ // the attribute is found
+}
+else
+{
+ // the attribute is not found
+}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+@subsubsection occt_ocaf_3_4_2 Identifying an attribute using a GUID
+
+You can create a new instance of an attribute and retrieve its GUID. In the example below, a new integer attribute is created, and its GUID is passed to the variable *guid *by the method ID inherited from TDF_Attribute.
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+Handle(TDataStd_Integer) INT = new TDataStd_Integer();
+Standard_GUID guid = INT->ID();
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+@subsubsection occt_ocaf_3_4_3 Attaching an attribute to a label
+
+To attach an attribute to a label, you use TDF_Label::Add. Repetition of this syntax raises an error message because there is already an attribute with the same GUID attached to the current label.
+
+TDF_Attribute::Label for *INT *then returns the label *attach *which *INT *is attached to.
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+current.Add (INT); // INT is now attached to current
+current.Add (INT); // causes failure
+TDF_Label attach = INT->Label();
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+@subsubsection occt_ocaf_3_4_4 Testing the attachment to a label
+
+You can test whether an attribute is attached to a label or not by using TDF_Attribute::IsA with the GUID of the attribute as an argument. In the example below, you test whether the current label has an integer attribute, and then, if that is so, how many attributes are attached to it. TDataStd_Integer::GetID provides the GUID argument needed by the method IsAttribute.
+
+TDF_Attribute::HasAttribute tests whether there is an attached attribute, and TDF_Tool::NbAttributes returns the number of attributes attached to the label in question, *current *here,
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+// Testing of attribute attachment
+//
+if (current.IsA(TDataStd_Integer::GetID())) {
+// the label has an Integer attribute attached
+}
+if (current.HasAttribute()) {
+// the label has at least one attribute attached
+Standard_Integer nbatt = current.NbAttributes();
+// the label has nbatt attributes attached
+}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+@subsubsection occt_ocaf_3_4_5 Removing an attribute from a label
+
+To remove an attribute from a label, you use TDF_Label::Forget with the GUID of the deleted attribute. To remove all attributes of a label, TDF_Label::ForgetAll.
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+current.Forget(TDataStd_Integer::GetID());
+// integer attribute is now not attached to current label
+current.ForgetAll();
+// current has now 0 attributes attached
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+@subsubsection occt_ocaf_3_4_6 Specific attribute creation
+
+If the set of existing and ready to use attributes implementing standard data types does not cover the needs of a specific data presentation task, the user can build his own data type and the corresponding new specific attribute implementing this new data type.
+
+There are two ways to implement a new data type: create a new attribute (standard approach), or use the notion of User Attribute by means of a combination of standard attributes (alternative way)
+
+In order to create a new attribute in the standard way do the following:
+* Create a class inherited from TDF_Attribute and implement all purely virtual and necessary virtual methods:
++ **ID()** – returns a unique GUID of a given attribute
++ **Restore(attribute)** – sets fields of this attribute equal to the fields of a given attribute of the same type
++ **Paste(attribute, relocation_table)** – sets fields of a given attribute equal to the field values of this attribute ; if the attribute has references to some objects of the data framework and relocation_table has this element, then the given attribute must also refer to this object .
++ **NewEmpty()** - returns a new attribute of this class with empty fields
++ **Dump(stream)** - outputs information about a given attribute to a given stream debug (usually outputs an attribute of type string only)
+* Create the persistence classes for this attribute according to the file format chosen for the document (see below).
+
+Methods NewEmpty, Restore and Paste are used for the common transactions mechanism (Undo/Redo commands). If you don’t need this attribute to react to undo/redo commands, you can write only stubs of these methods, else you must call the Backup method of the TDF_Attribute class every time attribute fields are changed.
+
+If you use a standard file format and you want your new attributes to be stored during document saving and retrieved to the data framework whenever a document is opened, you must do the following:
+
+ * If you place an attribute to a new package, it is desirable (although not mandatory) if your package name starts with letter «T» (transient), for example: attribute TMyAttributePackage_MyAttribute in the package TMyAttributePackage
+ * Create a new package with name «P[package name]» (for example PMyAttributePackage) with class PMyAttributePackage_MyAttribute inside. The new class inherits the PDF_Attribute class and contains fields of attributes, which must be saved or retrieved («P» - persistent).
+ * Create a new package with name «M[package name]» (for example MMyAttributePackage) with classes MMyAttributePackage_MyAttributeRetrievalDriver and MMyAttributePackage_MyAttributeStorageDriver inside. The new classes inherit MDF_ARDriver and MDF_ASDriver classes respectively and contain the translation functionality: from T... attribute to P... and vice versa (M - middle) (see the realization of the standard attributes).
+ * M... package must contain AddStorageDrivers(aDriverSeq : ASDriverHSequence from MDF) and AddRetrievalDrivers(aDriverSeq : ASDriverHSequence from MDF) methods, which append to the given sequence <aDriverSeq> of drivers a sequence of all new attribute drivers (see the previous point), which will be used for the attributes storage/retrieval.
+ * Use the standard schema (StdSchema unit) or create a new one to add your P-package and compile it.
+
+If you use the XML format, do the following:
+ * Create a new package with the name Xml[package name] (for example XmlMyAttributePackage) containing class XmlMyAttributePackage_MyAttributeDriver. The new class inherits XmlMDF_ADriver class and contains the translation functionality: from transient to persistent and vice versa (see the realization of the standard attributes in the packages XmlMDataStd, for example). Add package method AddDrivers which adds your class to a driver table (see below).
+ * Create a new package (or do it in the current one) with two package methods: Factory, which loads the document storage and retrieval drivers; and AttributeDrivers, which calls the methods AddDrivers for all packages responsible for persistence of the document.
+ * Create a plug-in implemented as an executable (see example XmlPlugin). It calls a macro PLUGIN with the package name where you implemented the method Factory.
+If you use the binary format, do the following:
+ * Create a new package with name Bin[package name] (for example BinMyAttributePackage) containing a class BinMyAttributePackage_MyAttributeDriver. The new class inherits BinMDF_ADriver class and contains the translation functionality: from transient to persistent and vice versa (see the realization of the standard attributes in the packages BinMDataStd, for example). Add package method AddDrivers which adds your class to a driver table (see below).
+ * Create a new package (or do it in the current one) with two package methods: Factory, which loads the document storage and retrieval drivers; and AttributeDrivers, which calls the methods AddDrivers for all packages responsible for persistence of the document.
+ * Create a plug-in implemented as an executable (see example BinPlugin). It calls a macro PLUGIN with the package name where you implemented the method Factory.
+
+See «Saving the document» on page 23 and «Opening the document from a file» on page 25 for the description of a document save/open mechanisms.
+
+If you decided to use the alternative way (create a new attribute by means of UAttribute and a combination of other standard attributes), do the following:
+ * Set a TDataStd_UAttribute with a unique GUID attached to a label. This attribute defines the semantics of the data type (identifies the data type).
+ * Create child labels and allocate all necessary data through standard attributes at the child labels.
+ * Define an interface class for access to the data of the child labels.
+
+Choosing the alternative way of implementation of new data types allows to forget about creating persistence classes for your new data type. Standard persistence classes will be used instead.Besides, this way allows separating the data and the methods for access to the data (interfaces). It can be used for rapid development in all cases when requirements to application performance are not very high.
+
+Let’s study the implementation of the same data type in both ways by the example of transformation represented by gp_Trsf class. The class gp_Trsf defines the transformation according to the type (gp_TrsfForm) and a set of parameters of the particular type of transformation (two points or a vector for translation, an axis and an angle for rotation, and so on).
+
+1. The first way: creation of a new attribute. The implementation of the transformation by creation of a new attribute is represented in the <a href="#_10._APPENDIX">Appendix</a>.
+
+2. The second way: creation of a new data type by means of combination of standard attributes. Depending on the type of transformation it may be kept in data framework by different standard attributes. For example, a translation is defined by two points. Therefore the data tree for translation looks like this:
+ * Type of transformation (gp_Translation) as TDataStd_Integer;
+ * First point as TDataStd_RealArray (three values: X1, Y1 and Z1);
+ * Second point as TDataStd_RealArray (three values: X2, Y2 and Z2).
+
+
+
+If the type of transformation is changed to rotation, the data tree looks like this:
+ * Type of transformation (gp_Rotation) as TDataStd_Integer;
+ * Point of axis of rotation as TDataStd_RealArray (three values: X, Y and Z);
+ * Axis of rotation as TDataStd_RealArray (three values: DX, DY and DZ);
+ * Angle of rotation as TDataStd_Real.
+
+
+
+The attribute TDataStd_UAttribute with the chosen unique GUID identifies the data type. The interface class initialized by the label of this attribute allows access to the data container (type of transformation and the data of transformation according to the type).
+
+
+@section occt_ocaf_4_ Standard Document Services
+
+@subsection occt_ocaf_4_1 Overview
+
+Standard documents offer ready-to-use documents containing a TDF-based data framework. Each document can contain only one framework.
+
+The documents themselves are contained in the instantiation of a class inheriting from TDocStd_Application. This application manages the creation, storage and retrieval of documents.
+
+You can implement undo and redo in your document, and refer from the data framework of one document to that of another one. This is done by means of external link attributes, which store the path and the entry of external links.
+
+To sum up, standard documents alone provide access to the data framework. They also allow you to:
+
+ * Update external links
+ * Manage the saving and opening of data
+ * Manage the undo/redo functionality.
+
+
+@subsection occt_ocaf_4_2 The Application
+
+As a container for your data framework, you need a document, and your document must be contained in your application. This application will be a class inheriting from TDocStd_Application.
+
+@subsubsection occt_ocaf_4_2_1 Creating an application
+
+To create an application, use the following syntax.
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+Handle(TDocStd_Application) app
+= new MyApplication_Application ();
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Note that MyApplication_Application is a class, which you have to create and which will inherit from TDocStd_Application.
+
+@subsubsection occt_ocaf_4_2_2 Creating a new document
+
+To the application which you declared in the previous example (4.2.1), you must add the document *doc *as an argument of TDocStd_Application::NewDocument.
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+Handle(TDocStd_Document) doc;
+app->NewDocument("NewDocumentFormat", doc);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+@subsubsection occt_ocaf_4_2_3 Retrieving the application to which the document belongs
+
+To retrieve the application containing your document, you use the syntax below.
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+app = Handle(TDocStd_Application)::DownCast
+(doc->Application());
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+@subsection occt_ocaf_4_3 The Document
+
+The document contains your data framework, and allows you to retrieve this framework, recover its main label, save it in a file, and open or close this file.
+
+@subsubsection occt_ocaf_4_3_1 Accessing the main label of the framework
+
+To access the main label in the data framework, you use TDocStd_Document::Main as in the example below. The main label is the first child of the root label in the data framework, and has the entry 0:1.
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+TDF_Label label = doc->Main();
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+@subsubsection occt_ocaf_4_3_2 Retrieving the document from a label in its framework
+
+To retrieve the document from a label in its data framework, you use TDocStd_Document::Get as in the example below. The argument *label *passed to this method is an instantiation of TDF_Label.
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+doc = TDocStd_Document::Get(label);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+@subsubsection occt_ocaf_4_3_3 Saving the document
+
+If in your document you use only standard attributes (from the packages TDF, TDataStd, TNaming, TFunction, TPrsStd and TDocStd), you just do the following steps:
+
+* In your application class (which inherits class TDocStd_Application) implement two methods:
++ Formats (TColStd_SequenceOfExtendedString& theFormats), which append to a given sequence <theFormats> your document format string, for example, «NewDocumentFormat» – this string is also set in the document creation command
++ ResourcesName(), which returns a string with a name of resources file (this file contains a description about the extension of the document, storage/retrieval drivers GUIDs...), for example, «NewFormat»
+* Create the resource file (with name, for example, «NewFormat») with the following strings:
+
+~~~~~
+formatlist:NewDocumentFormat
+NewDocumentFormat: New Document Format Version 1.0
+NewDocumentFormat.FileExtension: ndf
+NewDocumentFormat.StoragePlugin: bd696000-5b34-11d1-b5ba-00a0c9064368
+NewDocumentFormat.RetrievalPlugin: bd696001-5b34-11d1-b5ba-00a0c9064368
+NewDocumentFormatSchema: bd696002-5b34-11d1-b5ba-00a0c9064368
+NewDocumentFormat.AttributeStoragePlugin:57b0b826-d931-11d1-b5da-00a0c9064368
+NewDocumentFormat.AttributeRetrievalPlugin:57b0b827-d931-11d1-b5da-00a0c9064368
+~~~~~
+
+* Create the resource file «Plugin» with GUIDs and corresponding plugin libraries, which looks like this:
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+! Description of available plugins
+! ************
+
+b148e300-5740-11d1-a904-080036aaa103.Location: libFWOSPlugin.so
+!
+! standard document drivers plugin
+!
+bd696000-5b34-11d1-b5ba-00a0c9064368.Location: libPAppStdPlugin.so
+bd696001-5b34-11d1-b5ba-00a0c9064368.Location: libPAppStdPlugin.so
+!
+! standard schema plugin
+!
+bd696002-5b34-11d1-b5ba-00a0c9064368.Location: libPAppStdPlugin.so
+!
+! standard attribute drivers plugin
+!
+57b0b826-d931-11d1-b5da-00a0c9064368.Location: libPAppStdPlugin.so
+57b0b827-d931-11d1-b5da-00a0c9064368.Location: libPAppStdPlugin.so
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In order to set the paths for these files it is necessary to set the environments: CSF_PluginDefaults and CSF_NewFormatDefaults. For example, set the files in the directory "MyApplicationPath/MyResources":
+
+~~~~~
+setenv CSF_PluginDefaults MyApplicationPath/MyResources
+setenv CSF_NewFormatDefaults MyApplicationPath/MyResources
+~~~~~
+
+Once these steps are taken you may run your application, create documents and Save/Open them. These resource files already exist in the OCAF (format «Standard»).
+
+If you use your specific attributes from packages, for example, P-, M- and TMyAttributePackage, see «Specific attribute creation» on page 20; you must take some additional steps for the new plugin implementation:
+
+* Add our «P» package to the standard schema. You can get an already existing (in Open CASCADE Technology sources) schema from StdSchema unit and add your package string to the cdl-file: «package PMyAttributePackage».
+* Next step consists of implementation of an executable, which will connect our documents to our application and open/save them. Copy the package PAppStdPlugin and change its name to MyTheBestApplicationPlugin. In the PLUGIN macros type the name of your factory which will be defined in the next step.
+* Factory is a method, which returns drivers (standard drivers and our defined drivers from the "M" package) by a GUID. Copy the package where the standard factory is defined (it is PAppStd in the OCAF sources). Change its name to MyTheBestSchemaLocation. The Factory() method of the PappStd package checks the GUID set as its argument and returns the corresponding table of drivers. Set two new GUIDs for your determined storage and retrieval drivers. Append two "if" declarations inside the Factory() method which should check whether the set GUID coincides with GUIDs defined by the Factory() method as far as our storage and retrieval drivers are concerned. If the GUID coincides with one of them, the method should return a table of storage or retrieval drivers respectively.
+* Recompile all. Add the strings with GUIDs – in accordance with your plugin library GUID - to the «Plugin» file.
+
+@subsubsection occt_ocaf_4_3_4 Opening the document from a file
+
+To open the document from a file where it has been previously saved, you use TDocStd_Application::Open as in the example below. The arguments are the path of the file and the document saved in this file.
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+app->Open("/tmp/example.caf", doc);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@subsection occt_ocaf_4_4 External Links
+
+External links refer from one document to another. They allow you to update the copy of data framework later on.
+
+
+
+Note that documents can be copied with or without a possibility of updating an external link.
+
+@subsubsection occt_ocaf_4_4_1 Copying the document
+
+With a possibility of updating it later
+---------------------------------------
+
+To copy a document with a possibility of updating it later, you use TDocStd_XLinkTool::CopyWithLink.
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+Handle(TDocStd_Document) doc1;
+Handle(TDocStd_Document) doc2;
+
+TDF_Label source = doc1->GetData()->Root();
+TDF_Label target = doc2->GetData()->Root();
+TDocStd_XLinkTool XLinkTool;
+
+XLinkTool.CopyWithLink(target,source);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Now the target document has a copy of the source document. The copy also has a link in order to update the content of the copy if the original changes.
+
+In the example below, something has changed in the source document. As a result, you need to update the copy in the target document. This copy is passed to TDocStd_XLinkTool::UpdateLink as the argument *target*.
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+XLinkTool.UpdateLink(target);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+With no link between the copy and the original
+----------------------------------------------
+
+You can also create a copy of the document with no link between the original and the copy. The syntax to use this option is TDocStd_XLinkTool::Copy; the copied document is again represented by the argument *target*, and the original – by *source.*
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+XLinkTool.Copy(target, source);
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+@section occt_ocaf_5_ OCAF Shape Attributes
+@subsection occt_ocaf_5_1 Overview
+
+OCAF shape attributes are used for topology objects and their evolution access. All topological objects are stored in one TNaming_UsedShapes attribute at the root label of the data framework. This attribute contains a map with all topological shapes used in a given document.
+
+The user can add the TNaming_NamedShape attribute to other labels. This attribute contains references (hooks) to shapes from the TNaming_UsedShapes attribute and an evolution of these shapes. The TNaming_NamedShape attribute contains a set of pairs of hooks: to the *Old* shape and to a *New* shape (see the following figure). It allows not only to get the topological shapes by the labels, but also to trace the evolution of the shapes and to correctly update dependent shapes by the changed one.
+
+If a shape is newly created, then the old shape of a corresponding named shape is an empty shape. If a shape is deleted, then the new shape in this named shape is empty.
+
+
+
+Different algorithms may dispose sub-shapes of the result shape at the individual labels depending on whether it is necessary to do so:
+
+* If a sub-shape must have some extra attributes (material of each face or color of each edge). In this case a specific sub-shape is placed to a separate label (usually to a sub-label of the result shape label) with all attributes of this sub-shape.
+* If the topological naming algorithm is needed, a necessary and sufficient set of sub-shapes is placed to child labels of the result shape label. As usual, for a basic solid and closed shells, all faces of the shape are disposed.
+
+
+TNaming_NamedShape may contain a few pairs of hooks with the same evolution. In this case the topology shape, which belongs to the named shape is a compound of new shapes.
+
+Consider the following example. Two boxes (solids) are fused into one solid (the result one). Initially each box was placed to the result label as a named shape, which has evolution PRIMITIVE and refers to the corresponding shape of the TNaming_UsedShapes map. The box result label has a material attribute and six child labels containing named shapes of Box faces.
+
+
+
+After the fuse operation a modified result is placed to a separate label as a named shape, which refers to the old shape – one of the boxes, as well as to the new shape – the shape resulting from the fuse operation – and has evolution MODIFY (see the following figure).
+
+Named shapes, which contain information about modified faces, belong to the fuse result sub-labels: sub-label with tag 1 – modified faces of the first box, sub-label with tag 2 – generated faces of the box 2.
+
+
+
+This is necessary and sufficient information for the functionality of the right naming mechanism: any sub-shape of the result can be identified unambiguously by name type and set of labels, which contain named shapes:
+
+ * face F1’ as a modification of F11 face
+ * face F1’’ as generation of F12 face
+ * edges as an intersection of two contiguous faces
+ * vertices as an intersection of three contiguous faces
+
+After any modification of source boxes the application must automatically rebuild the naming entities: recompute the named shapes of the boxes (solids and faces) and fuse the resulting named shapes (solids and faces) that reference to the new named shapes.
+
+@subsection occt_ocaf_5_2 Services provided
+
+@subsubsection occt_ocaf_5_2_1 Registering shapes and their evolution
+
+When using TNaming_NamedShape to create attributes, the following fields of an attribute are filled:
+
+* A list of shapes called the «old» and the «new» shapes A new shape is recomputed as the value of the named shape. The meaning of this pair depends on the type of evolution.
+* The type of evolution: a term of the TNaming_Evolution enumeration:
+* PRIMITIVE – newly created topology, with no previous history
+* GENERATED – as usual, this evolution of a named shape means, that the new shape is created from a low-level old shape ( a prism face from an edge, for example )
+* MODIFY – the new shape is a modified old shape
+* DELETE – the new shape is empty; the named shape with this evolution just indicates that the old shape topology is deleted from the model
+ * SELECTED – a named shape with this evolution has no effect on the history of the topology; it is
+used for the selected shapes that are placed to the separate label
+
+Only pairs of shapes with equal evolution can be stored in one named shape.
+
+@subsubsection occt_ocaf_5_2_2 Using naming resources
+
+The class TNaming_Builder allows you to create a named shape attribute. It has a label of a future attribute as an argument of the constructor. Respective methods are used for the evolution and setting of shape pairs. If for the same TNaming_Builder object a lot of pairs of shapes with the same evolution are given, then these pairs would be placed in the resulting named shape. After the creation of a new object of the TNaming_Builder class, an empty named shape is created at the given label.
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+// a new empty named shape is created at «label»
+TNaming_Builder builder(label);
+// set a pair of shapes with evolution GENERATED
+builder.Generated(oldshape1,newshape1);
+// set another pair of shapes with the same evolution
+builder.Generated(oldshape2,newshape2);
+// get the result – TNaming_NamedShape attribute
+Handle(TNaming_NamedShape) ns = builder.NamedShape();
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+@subsubsection occt_ocaf_5_2_3 Reading the contents of a named shape attribute
+
+You can use TNaming_NamedShape class to get evolution of this named shape (method TNaming_NamedShape::Evolution()) and «value» of the named shape – compound of new shapes of all pairs of this named shape (method TNaming_NamedShape::Get()).
+
+More detailed information about the contents of the named shape or about the modification history of a topology can be obtained with the following:
+
+* TNaming_Tool provides a common high-level functionality for access to the named shapes contents:
+* GetShape(Handle(TNaming_NamedShape)) method returns a compound of new shapes of the given named shape
+* CurrentShape(Handle(TNaming_NamedShape)) method returns a compound of the shapes – last modifications ( latest versions ) of the shapes from the given named shape
+* NamedShape(TopoDS_Shape,TDF_Label) method returns a named shape, which contains a given shape as a new shape. Given label is any label from the data framework – it just gives access to it
+* TNaming_Iterator given access to the named shape hooks pairs.
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+// create an iterator for a named shape
+TNaming_Iterator iter(namedshape);
+// iterate while some pairs are not iterated
+while(iter.More()) {
+// get the new shape from the current pair
+TopoDS_Shape newshape = iter.NewShape();
+// get the old shape from the current pair
+TopoDS_Shape oldshape = iter.OldShape();
+// do something...
+
+// go to the next pair
+iter.Next();
+}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+@subsubsection occt_ocaf_5_2_4 Selection Mechanism
+
+One of user interfaces for topological naming resources is the TNaming_Selector class. You can use this class to:
+
+ * Store a selected shape on a label
+ * Access the named shape
+ * Update this naming
+
+Selector places a new named shape with evolution SELECTED to the given label. By the given context shape (main shape, which contains a selected sub-shape), its evolution and naming structure the selector creates a «name» of the selected shape – unique description how to find a selected topology.
+
+After any modification of a context shape and updating of the corresponding naming structure, you must call the TNaming_Selector::Solve method. If the naming structure is right, then the selector automatically updates the selected shape in the corresponding named shape, else it fails.
+
+@subsubsection occt_ocaf_5_2_5 Exploring shape evolution
+
+The class TNaming_Tool provides a toolkit to read current data contained in the attribute.
+
+If you need to create a topological attribute for existing data, use the method NamedShape.
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+class MyPkg_MyClass
+{
+public: Standard_Boolean SameEdge (const Handle(CafTest_Line)& L1, const Handle(CafTest_Line)& L2);
+};
+
+Standard_Boolean CafTest_MyClass::SameEdge (const Handle(CafTest_Line)& L1, const Handle(CafTest_Line)& L2)
+{
+ Handle(TNaming_NamedShape) NS1 = L1->NamedShape();
+ Handle(TNaming_NamedShape) NS2 = L2->NamedShape();
+ return BRepTools::Compare(NS1,NS2);
+}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@section occt_ocaf_6_ Standard Attributes
+
+@subsection occt_ocaf_6_1 Overview
+
+There are several ready-to-use attributes, which allow creating and modifying attributes for many basic data types. They are available in the packages TDataStd, TDataXtd and TDF. Each attribute belongs to one of four types:
+
+ * Geometric attributes
+ * General attributes
+ * Relationship attributes
+ * Auxiliary attributes
+
+Geometric attributes
+--------------------
+
+ * Axis – simply identifies, that the concerned TNaming_NamedShape attribute with an axis shape inside belongs to the same label
+ * Constraint – contains information about a constraint between geometries: used geometry attributes, type, value (if exists), plane (if exists), «is reversed», «is inverted» and «is verified» flags
+ * Geometry – simply identifies, that the concerned TNaming_NamedShape attribute with a specified-type geometry belongs to the same label
+ * Plane – simply identifies, that the concerned TNaming_NamedShape attribute with a plane shape inside belongs to the same label
+ * Point – simply identifies, that the concerned TNaming_NamedShape attribute with a point shape inside belongs to the same label
+ * Shape – simply identifies, that the concerned TNaming_NamedShape attribute belongs to the same label
+ * PatternStd – identifies one of five available pattern models (linear, circular, rectangular, circular rectangular and mirror)
+ * Position – identifies the position in 3d global space
+
+General attributes
+------------------
+
+ * AsciiString – contains AsciiString value
+ * BooleanArray – contains an array of Boolean
+ * BooleanList – contains a list of Boolean
+ * ByteArray – contains an array of Byte (unsigned char) values
+ * Comment – contains a string – some comment for a given label (or attribute)
+ * Expression – contains an expression string and a list of used variables attributes
+ * ExtStringArray – contains an array of ExtendedString values
+ * ExtStringList – contains a list of ExtendedString values
+ * Integer – contains an integer value
+ * IntegerArray – contains an array of integer values
+ * IntegerList – contains a list of integer values
+ * IntPackedMap – contains a packed map of integers
+ * Name – contains a string – some name of a given label (or attribute)
+ * NamedData – may contain up to 6 of the following named data sets (vocabularies): DataMapOfStringInteger, DataMapOfStringReal, DataMapOfStringString, DataMapOfStringByte, DataMapOfStringHArray1OfInteger, DataMapOfStringHArray1OfReal
+ * NoteBook – contains a NoteBook object attribute
+ * Real – contains a real value
+ * RealArray – contains an array of real values
+ * RealList – contains a list of real values
+ * Relation – contains a relation string and a list of used variables attributes
+ * Tick – defines a boolean attribute
+ * Variable – simply identifies, that a variable belongs to this label; contains the «is constraint» flag and a string of used units («mm», «m»...)
+ * UAttribute – attribute with a user-defined GUID. As a rule, this attribute is used as a marker, which is independent of attributes at the same label (note, that attributes with the same GUIDs can not belong to the same label)
+
+Relationship attributes
+-----------------------
+
+ * Reference – contains reference to the label of its own data framework
+ * ReferenceArray – contains an array of references
+ * ReferenceList – contains a list of references
+ * TreeNode – this attribute allows to create an internal tree in the data framework; this tree consists of nodes with the specified tree ID; each node contains references to the father, previous brother, next brother, first child nodes and tree ID.
+
+Auxiliary attributes
+--------------------
+ * Directory – hi-level tool attribute for sub-labels management
+ * TagSource – this attribute is used for creation of new children: it stores the tag of the last-created child of the label and gives access to the new child label creation functionality.
+
+All of these attributes inherit class TDF_Attribute, so, each attribute has its own GUID and standard methods for attribute creation, manipulation, getting access to the data framework.
+
+
+@subsection occt_ocaf_6_2 Services common to all attributes
+
+@subsubsection occt_ocaf_6_2_1 Accessing GUIDs
+
+To access the GUID of an attribute, you can use two methods:
+
+ * Method **GetID**: this is the static method of a class. It returns the GUID of any attribute, which is an object of a specified class (for example, TDataStd_Integer returns the GUID of an integer attribute). Only two classes from the list of standard attributes do not support these methods: TDataStd_TreeNode and TDataStd_Uattribute, because the GUIDs of these attributes are variable.
+ * Method **ID**: this is the method of an object of an attribute class. It returns the GUID of this attribute. Absolutely all attributes have this method: only by this identifier you can discern the type of an attribute.
+
+@subsubsection occt_ocaf_6_2_2 Conventional Interface of Standard Attributes
+
+It is usual to create standard named methods for the attributes:
+
+ * Method Set(label, [value]) – it is the static method, which allows to add an attribute to a given label. If an attribute is characterized by one value this method may set it.
+ * Method Get() returns the value of an attribute if it is characterized by one value.
+ * Method Dump(Standard_OStream) outputs debug information about a given attribute to a given stream.
+
+@section occt_ocaf_7_ Visualization Attributes
+
+@subsection occt_ocaf_7_1 Overview
+
+Standard visualization attributes implement the Application Interactive Services (see Open CASCADE Technology Visualization User’s Guide) in the context of Open CASCADE Technology Application Framework. Standard visualization attributes are AISViewer and Presentation and belong to the TPrsStd package.
+
+@subsection occt_ocaf_7_2 Services provided
+
+@subsubsection occt_ocaf_7_2_1 Defining an interactive viewer attribute
+
+The class TPrsStd_AISViewer allows you to define an interactive viewer attribute. There may be only one such attribute per one data framework and it is always placed to the root label. So, it could be set or found by any label («access label») of the data framework. Nevertheless the default architecture can be easily extended and the user can manage several Viewers per one framework by himself.
+
+To initialize the AIS viewer as in the example below, use method Find.
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+// «access» is any label of the data framework
+Handle(TPrsStd_AISViewer) viewer = TPrsStd_AISViewer::Find(access)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@subsection occt_ocaf_7_2_2 Defining a presentation attribute
+
+The class TPrsStd_AISPresentation allows you to define the visual presentation of document labels contents. In addition to various visual fields (color, material, transparency, «isDisplayed», etc.), this attribute contains its driver GUID. This GUID defines the functionality, which will update the presentation every time when needed.
+
+@subsubsection occt_ocaf_7_2_3 Creating your own driver
+
+The abstract class TPrsStd_Driver allows you to define your own driver classes. Simply redefine the Update method in your new class, which will rebuild the presentation.
+
+If your driver is placed to the driver table with the unique driver GUID, then every time the viewer updates presentations with a GUID identical to your driver’s GUID, the Update method of your driver for these presentations must be called:
+
+
+As usual, the GUID of a driver and the GUID of a displayed attribute are the same.
+
+@subsubsection occt_ocaf_7_2_4 Using a container for drivers
+
+You frequently need a container for different presentation drivers. The class TPrsStd_DriverTable provides this service. You can add a driver to the table, see if one is successfully added, and fill it with standard drivers.
+
+To fill a driver table with standard drivers, first initialize the AIS viewer as in the example above, and then pass the return value of the method InitStandardDrivers to the driver table returned by the method Get. Then attach a TNaming_NamedShape to a label and set the named shape in the presentation attribute using the method Set. Then attach the presentation attribute to the named shape attribute, and the AIS_InteractiveObject, which the presentation attribute contains, will initialize its drivers for the named shape. This can be seen in the example below.
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+DriverTable::Get() -> InitStandardDrivers();
+// next, attach your named shape to a label
+TPrsStd_AISPresentation::Set(NS};
+// here, attach the AISPresentation to NS.
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@section occt_ocaf_8_ Function Services
+
+@subsection occt_ocaf_8_1 Overview
+
+Function services aggregate data necessary for regeneration of a model. The function mechanism - available in the package TFunction - provides links between functions and any execution algorithms, which take their arguments from the data framework, and write their results inside the same framework.
+
+When you edit any application model, you have to regenerate the model by propagating the modifications. Each propagation step calls various algorithms. To make these algorithms independent of your application model, you need to use function services.
+
+Take, for example, the case of a modeling sequence made up of a box with the application of a fillet on one of its edges. If you change the height of the box, the fillet will need to be regenerated as well.
+
+@subsection occt_ocaf_8_2 Services provided
+
+@subsubsection occt_ocaf_8_2_1 Finding functions, their owners and roots
+
+The class TFunction_Function is an attribute, which stores a link to a function driver in the data framework. In the static table TFunction_DriverTable correspondence links between function attributes and drivers are stored.
+
+You can write your function attribute, a driver for such attribute (which updates the function result in accordance to a given map of changed labels), and set your driver with the GUID to the driver table.
+
+Then the solver algorithm of a data model can find the Function attribute on a corresponding label and call the Execute driver method to update the result of the function.
+
+@subsubsection occt_ocaf_8_2_2 Storing and accessing information about function status
+
+For updating algorithm optimization, each function driver has access to the TFunction_Logbook object that is a container for a set of touched, impacted and valid labels. Using this object a driver gets to know which arguments of the function were modified.
+
+@subsubsection occt_ocaf_8_2_3 Propagating modifications
+
+An application must implement its functions, function drivers and the common solver for parametric model creation. For example, check the following model (see the following illustration):
+
+
+
+The procedure of its creation is as follows:
+ * create a rectangular planar face F with height 100 and width 200
+ * create prism P using face F as a basis
+ * create fillet L at the edge of the prism
+ * change the width of F from 200 to 300:
+ * the solver for the function of face F starts
+ * the solver detects that an argument of the face *F* function has been modified
+ * the solver calls the driver of the face F function for a regeneration of the face
+ * the driver rebuilds face F and adds the label of the face *width* argument to the logbook as touched and the label of the function of face F as impacted
+
+ * the solver detects the function of P – it depends on the function of F
+ * the solver calls the driver of the prism P function
+ * the driver rebuilds prism P and adds the label of this prism to the logbook as impacted
+ * the solver detects the function of L – it depends on the function of P
+ * the solver calls the L function driver
+ * the driver rebuilds fillet L and adds the label of the fillet to the logbook as impacted
+
+@section occt_ocaf_9 XML Support
+
+Writing and reading XML files in OCCT is provided by LDOM package, which constitutes an integral part
+of XML OCAF persistence, which is the optional component provided on top of Open CASCADE Technology.
+
+The Light DOM (LDOM) package contains classes maintaining a data structure whose main principles conform to W3C DOM Level 1 Recommendations. The purpose of these classes as required by XML OCAF persistence schema is to:
+* Maintain a tree structure of objects in memory representing the XML document. The root of the structure is an object of the LDOM_Document type. This object contains all the data corresponding to a given XML document and contains one object of the LDOM_Element type named "document element". The document element contains other LDOM_Element objects forming a tree. Other types of nodes (LDOM_Attr, LDOM_Text, LDOM_Comment, LDOM_CDATASection) represent the corresponding XML types and serve as branches of the tree of elements.
+* Provide class LDOM_Parser to read XML files and convert them to LDOM_Document objects.
+* Provide class LDOM_XmlWriter to convert LDOM_Document to a character stream in XML format and store it in file.
+
+This package covers the functionality provided by numerous products known as "DOM parsers". Unlike most of them, LDOM was specifically developed to meet the following requirements:
+* To minimize the virtual memory allocated by DOM data structures. In average, the amount of memory of LDOM is the same as the XML file size (UTF-8).
+* To minimize the time required for parsing and formatting XML, as well as for access to DOM data structures.
+
+Both these requirements are important when XML files are processed by applications if these files are relatively large (occupying megabytes and even hundreds of megabytes). To meet the requirements, some limitations were imposed on the DOM Level 1 specification; these limitations are insignificant in applications like OCAF. Some of these limitations can be overridden in the course of future developments. The main limitations are:
+* No Unicode support as well as various other encodings; only ASCII strings are used in DOM/XML. Note: There is a data type TCollection_ExtendedString for wide character data. This type is supported by LDOM_String as a sequence of numbers.
+* Some superfluous methods are deleted: getPreviousSibling, getParentNode, etc.
+* No resolution of XML Entities of any kind
+* No support for DTD: the parser just checks for observance of general XML rules and never validates documents.
+* Only 5 available types of DOM nodes: LDOM_Element, LDOM_Attr, LDOM_Text, LDOM_Comment, LDOM_CDATASection.
+* No support of Namespaces; prefixed names are used instead of qualified names.
+* No support of the interface DOMException (no exception when attempting to remove a non-existing node).
+
+LDOM is dependent on Kernel OCCT classes only. Therefore, it can be used outside OCAF persistence in various algorithms where DOM/XML support may be required.
+
+@subsection occt_ocaf_9_1 Document Drivers
+
+The drivers for document storage and retrieval manage conversion between a transient OCAF
+Document in memory and its persistent reflection in a container (disk, memory, network ...). For XML Persistence, they are defined in the package XmlDrivers.
+
+The main methods (entry points) of these drivers are:
+* *Write()* - for a storage driver;
+* *Read()* - for a retrieval driver.
+
+The most common case (which is implemented in XML Persistence) is writing/reading document to/from a regular OS file. Such conversion is performed in two steps:
+
+First it is necessary to convert the transient document into another form (called persistent), suitable for writing into a file, and vice versa.
+In XML Persistence LDOM_Document is used as the persistent form of an OCAF Document and the DOM_Nodes are the persistent objects.
+An OCAF Document is a tree of labels with attributes. Its transformation into a persistent form can be functionally divided into two parts:
+* Conversion of the labels structure, which is performed by the method XmlMDF::FromTo()
+* Conversion of the attributes and their underlying objects, which is performed by the corresponding attribute drivers (one driver per attribute type).
+
+The driver for each attribute is selected from a table of drivers, either by attribute
+type (on storage) or by the name of the corresponding DOM_Element (on retrieval).
+The table of drivers is created by by methods *XmlDrivers_DocumentStorageDriver::AttributeDrivers()*
+and *XmlDrivers_DocumentRetrievalDriver::AttributeDrivers()*.
+
+Then the persistent document is written into a file (or read from a file).
+In standard persistence Storage and FSD packages contain classes for writing/reading the persistent document into a file. In XML persistence LDOMParser and LDOM_XmlWriter are used instead.
+
+Usually, the library containing document storage and retrieval drivers is loaded at run time by a plugin mechanism. To support this in XML Persistence, there is a plugin XmlPlugin and a Factory()method in the XmlDrivers package. This method compares passed GUIDs with known GUIDs and returns the corresponding driver or generates an exception if the GUID is unknown.
+
+The application defines which GUID is needed for document storage or retrieval and in which library it should be found. This depends on document format and application resources. Resources for XML Persistence and also for standard persistence are found in the StdResource unit. They are written for the XmlOcaf document format.
+
+@subsection occt_ocaf_9_2 Attribute Drivers
+
+There is one attribute driver for XML persistence for each transient attribute from a set of standard OCAF attributes, with the exception of attribute types, which are never stored (pure transient). Standard OCAF attributes are collected in six packages, and their drivers also follow this distribution. Driver for attribute T*_* is called XmlM*_*. Conversion between transient and persistent form of attribute is performed by two methods Paste() of attribute driver.
+
+*XmlMDF_ADriver* is the root class for all attribute drivers.
+
+At the beginning of storage/retrieval process, one instance of each attribute driver is created and appended to driver table implemented as XmlMDF_ADriverTable. During OCAF Data storage, attribute drivers are retrieved from the driver table by the type of attribute. In the retrieval step, a data map is created linking names of DOM_Elements and attribute drivers, and then attribute drivers are sought in this map by DOM_Element qualified tag names.
+
+Every transient attribute is saved as a DOM_Element (root element of OCAF attribute) with attributes and possibly sub-nodes. The name of the root element can be defined in the attribute driver as a string passed to the base class constructor. The default is the attribute type name. Similarly, namespace prefixes for each attribute can be set. There is no default value, but it is possible to pass NULL or an empty string to store attributes without namespace prefixes.
+
+The basic class XmlMDF_ADriver supports errors reporting via the method *WriteMessage(const TCollection_ExtendedString&)*. It sends a message string to its message driver which is initialized in the constructor with a Handle(CDM_MessageDriver) passed from the application by Document Storage/Retrieval Driver.
+
+@subsection occt_ocaf_9_3 XML Document Structure
+
+Every XML Document has one root element, which may have attributes and contain other nodes. In OCAF XML Documents the root element is named "document" and has attribute "format" with the name of the OCAF Schema used to generate the file. The standard XML format is "XmlOcaf". The following elements are sub-elements of <document> and should be unique entries as its sub-elements, in a specific order. The order is:
+* **Element info** - contains strings identifying the format version and other parameters of the OCAF XML document. Normally, data under the element is used by persistence algorithms to correctly retrieve and initialize an OCAF document. The data also includes a copyright string.
+* **Element comments** - consists of an unlimited number of <comment> sub-elements containing necessary comment strings.
+* **Element label** is the root label of the document data structure, with the XML attribute "tag" equal to 0. It contains all the OCAF data (labels, attributes) as tree of XML elements. Every sub-label is identified by a tag (positive integer) defining a unique key for all sub-labels of a label. Every label can contain any number of elements representing OCAF attributes (see OCAF Attributes Representation below).
+* **Element shapes** - contains geometrical and topological entities in BRep format. These entities being referenced by OCAF attributes written under the element <label>. This element is empty if there are no shapes in the document. It is only output if attribute driver XmlMNaming_NamedShapeDriver has been added to drivers table by the DocumentStorageDriver.
+
+OCAF Attributes Representation
+-------------------------------
+
+In XML documents, OCAF attributes are elements whose name identifies the OCAF attribute type. These elements may have a simple (string or number) or complex (sub-elements) structure, depending on the architecture of OCAF attribute. Every XML type for OCAF attribute possesses a unique positive integer "id" XML attribute identifying the OCAF attribute throughout the document. To ensure "id" uniqueness, the attribute name "id" is reserved and is only used to indicate and identify elements which may be referenced from other parts of the OCAF XML document.
+For every standard OCAF attribute, its XML name matches the name of a C++ class in Transient data model. Generally, the XML name of OCAF attribute can be specified in the corresponding attribute driver.
+XML types for OCAF attributes are declared with XML W3C Schema in a few XSD files where OCAF attributes are grouped by the package where they are defined.
+
+Example of resulting XML file
+-----------------------------
+The following example is a sample text from an XML file obtained by storing an OCAF document with two labels (0: and 0:2) and two attributes - TDataStd_Name (on label 0:) and TNaming_NamedShape (on label 0:2). The <shapes> section contents are replaced by an ellipsis.
+
+~~~~~
+<?xml version="1.0" encoding="UTF-8"?>
+<document format="XmlOcaf" xmlns="http://www.opencascade.org/OCAF/XML" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+xsi:schemaLocation="http://www.opencascade.org/OCAF/XML http://www.opencascade.org/OCAF/XML/XmlOcaf.xsd">
+
+<info date="2001-10-04" schemav="0" objnb="3">
+<iitem>Copyright: Open Cascade, 2001</iitem>
+<iitem>STORAGE_VERSION: PCDM_ReadWriter_1</iitem>
+<iitem>REFERENCE_COUNTER: 0</iitem>
+<iitem>MODIFICATION_COUNTER: 1</iitem>
+</info>
+<comments/>
+<label tag="0">
+<TDataStd_Name id="1">Document_1</TDataStd_Name>
+<label tag="2">
+<TNaming_NamedShape id="2" evolution="primitive">
+<olds/>
+<news>
+<shape tshape="+34" index="1"/>
+</news>
+</TNaming_NamedShape>
+</label>
+</label>
+<shapes>
+...
+</shapes>
+</document>
+
+~~~~~
+
+@subsection occt_ocaf_9_4 XML Schema
+
+The XML Schema defines the class of a document.
+
+The full structure of OCAF XML documents is described as a set of XML W3C Schema files with definitions of all XML element types. The definitions provided cannot be overridden. If any application defines new persistence schemas, it can use all the definitions from the present XSD files but if it creates new or redefines existing types, the definition must be done under other namespace(s).
+
+There are other ways to declare XML data, different from W3C Schema, and it should be possible to use them to the extent of their capabilities of expressing the particular structure and constraints of our XML data model. However, it must be noted that the W3C Schema is the primary format for declarations and as such, it is the format supported for future improvements of Open CASCADE Technology, including the development of specific applications using OCAF XML persistence.
+
+The Schema files (XSD) are intended for two purposes:
+* documenting the data format of files generated by OCAF;
+* validation of documents when they are used by external (non-OCAF) applications, e.g., to generate reports.
+
+The Schema definitions are not used by OCAF XML Persistence algorithms when saving and restoring XML documents. There are internal checks to ensure validity when processing every type of data.
+
+Management of Namespaces
+------------------------
+Both the XML format and the XML OCAF persistence code are extensible in the sense that every new development can reuse everything that has been created in previous projects. For the XML format, this extensibility is supported by assigning names of XML objects (elements) to different XML Namespaces. Hence, XML elements defined in different projects (in different persistence libraries) can easily be combined into the same XML documents. An example is the XCAF XML persistence built as an extension to the Standard OCAF XML persistence [File XmlXcaf.xsd]. For the correct management of Namespaces it is necessary to:
+* Define targetNamespace in the new XSD file describing the format.
+* Declare (in XSD files) all elements and types in the targetNamespace to appear without a namespace prefix; all other elements and types use the appropriate prefix (such as "ocaf:").
+* Add (in the new DocumentStorageDriver) the targetNamespace accompanied with its prefix, using method XmlDrivers_DocumentStorageDriver::AddNamespace. The same is done for all namespaces objects which are used by the new persistence, with the exception of the "ocaf" namespace.
+* Pass (in every OCAF attribute driver) the namespace prefix of the targetNamespace to the constructor of XmlMDF_ADriver.
+
+@section occt_ocaf_10 GLOSSARY
+
+**Application** - a document container holding all documents containing all application data.
+**Application data** - the data produced by an application, as opposed to data referring to it.
+**Associativity of data** - the ability to propagate modifications made to one document to other documents, which refer to such document. Modification propagation is:
+ * unidirectional, that is, from the referenced to the referencing document(s), or
+ * bi-directional, from the referencing to the referenced document and vice-versa.
+**Attribute** - a container for application data. An attribute is attached to a label in the hierarchy of the data framework.
+**Child** - a label created from another label, which by definition, is the father label.
+**Compound document** - a set of interdependent documents, linked to each other by means of external references. These references provide the associativity of data.
+**Data framework** - a tree-like data structure which in OCAF, is a tree of labels with data attached to them in the form of attributes. This tree of labels is accessible through the services of the *TDocStd_Document* class.
+Document - a container for a data framework which grants access to the data, and is, in its turn, contained by an application. A document also allows you to:
+* Manage modifications, providing Undo and Redo functions
+* Manage command transactions
+* Update external links
+* Manage save and restore options
+* Store the names of software extensions.
+**Driver** - an abstract class, which defines the communications protocol with a system.
+**Entry** - an ASCII character string containing the tag list of a label.
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+0:3:24:7:2:7
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+**External links** - references from one data structure to another data structure in another document.
+To store these references properly, a label must also contain an external link attribute.
+**Father** - a label, from which other labels have been created. The other labels are, by definition, the children of this label.
+**Framework** - a group of co-operating classes which enable a design to be re-used for a given category of problem. The framework guides the architecture of the application by breaking it up into abstract classes, each of which has different responsibilities and collaborates in a predefined way.
+
+Application developer creates a specialized framework by:
+
+ * defining new classes which inherit from these abstract classes
+ * composing framework class instances
+ * implementing the services required by the framework.
+
+In C++, the application behavior is implemented in virtual functions redefined in these derived classes. This is known as overriding.
+
+**GUID** - Global Universal ID. A string of 37 characters intended to uniquely identify an object.
+
+**Example**
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+2a96b602-ec8b-11d0-bee7-080009dc3333
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+**Label** - a point in the data framework, which allows data to be attached to it by means of attributes. It has a name in the form of an entry, which identifies its place in the data framework.
+
+**Modified label** - containing attributes whose data has been modified.
+**Reference key** - an invariant reference, which may refer to any type of data used in an application. In its transient form, it is a label in the data framework, and the data is attached to it in the form of attributes. In its persistent form, it is an entry of the label. It allows an application to recover any entity in the current session or in a previous session.
+**Resource file** - a file containing a list of each document’s schema name and the storage and retrieval plug-ins for that document.
+**Root** - the starting point of the data framework. This point is the top label in the framework. It is represented by the [0] entry and is created at the same time with the document you are working on.
+**Scope** - the set of all the attributes and labels which depend on a given label.
+**Tag list** - a list of integers, which identify the place of a label in the data framework. This list is displayed in an entry.
+**Topological naming** - systematic referencing of topological entities so that these entities can still be identified after the models they belong to have gone through several steps in modeling. In other words, topological naming allows you to track entities through the steps in the modeling process.
+This referencing is needed when a model is edited and regenerated, and can be seen as a mapping of labels and name attributes of the entities in the old version of a model to those of the corresponding entities in its new version.
+Note that if the topology of a model changes during the modeling, this mapping may not fully coincide. A Boolean operation, for example, may split edges.
+**Topological tracking** - following a topological entity in a model through the steps taken to edit and regenerate that model.
+**Valid label** - in a data framework, this is a label, which is already recomputed in the scope of regeneration sequence and includes the label containing a feature which is to be recalculated.
+
+Consider the case of a box to which you first add a fillet, then a protrusion feature. For recalculation purposes, only valid labels of each construction stage are used. In recalculating a fillet, they are only those of the box and the fillet, not the protrusion feature which was added afterwards.
+See also: modified
+
+@section occt_ocaf_11 Implementation of attribute Transformation (in a CDL file).
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+class Transformation from MyPackage inherits Attribute from TDF
+
+ ---Purpose: This attribute implements a transformation data container.
+
+uses
+
+ Attribute from TDF,
+ Label from TDF,
+ GUID from Standard,
+ RelocationTable from TDF,
+ Pnt from gp,
+ Ax1 from gp,
+ Ax2 from gp,
+ Ax3 from gp,
+ Vec from gp,
+ Trsf from gp,
+ TrsfForm from gp
+
+is
+
+ ---Category: Static methods
+ -- ===============
+
+ GetID (myclass)
+ ---C++: return const &
+ ---Purpose: The method returns a unique GUID of this attribute.
+ -- By means of this GUID this attribute may be identified
+ -- among other attributes attached to the same label.
+ returns GUID from Standard;
+
+ Set (myclass; theLabel : Label from TDF)
+ ---Purpose: Finds or creates the attribute attached to <theLabel>.
+ -- The found or created attribute is returned.
+ returns Transformation from MyPackage;
+
+
+ ---Category: Methods for access to the attribute data
+ -- ========================================
+
+ Get (me)
+ ---Purpose: The method returns the transformation.
+ returns Trsf from gp;
+
+
+ ---Category: Methods for setting the data of transformation
+ -- ==============================================
+
+ SetRotation (me : mutable;
+ theAxis : Ax1 from gp;
+ theAngle : Real from Standard);
+ ---Purpose: The method defines a rotation type of transformation.
+
+ SetTranslation (me : mutable;
+ theVector : Vec from gp);
+ ---Purpose: The method defines a translation type of transformation.
+
+ SetMirror (me : mutable;
+ thePoint : Pnt from gp);
+ ---Purpose: The method defines a point mirror type of transformation
+ -- (point symmetry).
+
+ SetMirror (me : mutable;
+ theAxis : Ax1 from gp);
+ ---Purpose: The method defines an axis mirror type of transformation
+ -- (axial symmetry).
+
+ SetMirror (me : mutable;
+ thePlane : Ax2 from gp);
+ ---Purpose: The method defines a point mirror type of transformation
+ -- (planar symmetry).
+
+ SetScale (me : mutable;
+ thePoint : Pnt from gp;
+ theScale : Real from Standard);
+ ---Purpose: The method defines a scale type of transformation.
+
+ SetTransformation (me : mutable;
+ theCoordinateSystem1 : Ax3 from gp;
+ theCoordinateSystem2 : Ax3 from gp);
+ ---Purpose: The method defines a complex type of transformation
+ -- from one co-ordinate system to another.
+
+
+ ---Category: Overridden methods from TDF_Attribute
+ -- =====================================
+
+ ID (me)
+ ---C++: return const &
+ ---Purpose: The method returns a unique GUID of the attribute.
+ -- By means of this GUID this attribute may be identified
+ -- among other attributes attached to the same label.
+ returns GUID from Standard;
+
+ Restore (me: mutable;
+ theAttribute : Attribute from TDF);
+ ---Purpose: The method is called on Undo / Redo.
+ -- It copies the content of <theAttribute>
+ -- into this attribute (copies the fields).
+
+ NewEmpty (me)
+ ---Purpose: It creates a new instance of this attribute.
+ -- It is called on Copy / Paste, Undo / Redo.
+ returns mutable Attribute from TDF;
+
+ Paste (me;
+ theAttribute : mutable Attribute from TDF;
+ theRelocationTable : mutable RelocationTable from TDF);
+ ---Purpose:: The method is called on Copy / Paste.
+ -- It copies the content of this attribute into
+ -- <theAttribute> (copies the fields).
+
+ Dump(me; anOS : in out OStream from Standard)
+ ---C++: return;
+ ---Purpose: Prints the content of this attribute into the stream.
+ returns OStream from Standard is redefined;
+
+
+ ---Category: Constructor
+ -- ===========
+
+ Create
+ ---Purpose: The C++ constructor of this atribute class.
+ -- Usually it is never called outside this class.
+ returns mutable Transformation from MyPackage;
+
+
+fields
+
+ -- Type of transformation
+ myType : TrsfForm from gp;
+
+ -- Axes (Ax1, Ax2, Ax3)
+ myAx1 : Ax1 from gp;
+ myAx2 : Ax2 from gp;
+ myFirstAx3 : Ax3 from gp;
+ mySecondAx3 : Ax3 from gp;
+
+ -- Scalar values
+ myAngle : Real from Standard;
+ myScale : Real from Standard;
+
+ -- Points
+ myFirstPoint : Pnt from gp;
+ mySecondPoint : Pnt from gp;
+
+
+end Transformation;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@subsection occt_1564296469_5683787762 Implementation of attribute Transformation, (CPP file).
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+#include MyPackage_Transformation.ixx;
+
+//=======================================================================
+//function : GetID
+//purpose : The method returns a unique GUID of this attribute.
+// By means of this GUID this attribute may be identified
+// among other attributes attached to the same label.
+//=======================================================================
+const Standard_GUID& MyPackage_Transformation::GetID()
+{
+ static Standard_GUID ID("4443368E-C808-4468-984D-B26906BA8573");
+ return ID;
+}
+
+//=======================================================================
+//function : Set
+//purpose : Finds or creates the attribute attached to <theLabel>.
+// The found or created attribute is returned.
+//=======================================================================
+Handle(MyPackage_Transformation) MyPackage_Transformation::Set(const TDF_Label& theLabel)
+{
+ Handle(MyPackage_Transformation) T;
+ if (!theLabel.FindAttribute(MyPackage_Transformation::GetID(), T))
+ {
+ T = new MyPackage_Transformation();
+ theLabel.AddAttribute(T);
+ }
+ return T;
+}
+
+//=======================================================================
+//function : Get
+//purpose : The method returns the transformation.
+//=======================================================================
+gp_Trsf MyPackage_Transformation::Get() const
+{
+ gp_Trsf transformation;
+ switch (myType)
+ {
+ case gp_Identity:
+ {
+ break;
+ }
+ case gp_Rotation:
+ {
+ transformation.SetRotation(myAx1, myAngle);
+ break;
+ }
+ case gp_Translation:
+ {
+ transformation.SetTranslation(myFirstPoint, mySecondPoint);
+ break;
+ }
+ case gp_PntMirror:
+ {
+ transformation.SetMirror(myFirstPoint);
+ break;
+ }
+ case gp_Ax1Mirror:
+ {
+ transformation.SetMirror(myAx1);
+ break;
+ }
+ case gp_Ax2Mirror:
+ {
+ transformation.SetMirror(myAx2);
+ break;
+ }
+ case gp_Scale:
+ {
+ transformation.SetScale(myFirstPoint, myScale);
+ break;
+ }
+ case gp_CompoundTrsf:
+ {
+ transformation.SetTransformation(myFirstAx3, mySecondAx3);
+ break;
+ }
+ case gp_Other:
+ {
+ break;
+ }
+ }
+ return transformation;
+}
+
+//=======================================================================
+//function : SetRotation
+//purpose : The method defines a rotation type of transformation.
+//=======================================================================
+void MyPackage_Transformation::SetRotation(const gp_Ax1& theAxis, const Standard_Real theAngle)
+{
+ Backup();
+ myType = gp_Rotation;
+ myAx1 = theAxis;
+ myAngle = theAngle;
+}
+
+//=======================================================================
+//function : SetTranslation
+//purpose : The method defines a translation type of transformation.
+//=======================================================================
+void MyPackage_Transformation::SetTranslation(const gp_Vec& theVector)
+{
+ Backup();
+ myType = gp_Translation;
+ myFirstPoint.SetCoord(0, 0, 0);
+ mySecondPoint.SetCoord(theVector.X(), theVector.Y(), theVector.Z());
+}
+
+//=======================================================================
+//function : SetMirror
+//purpose : The method defines a point mirror type of transformation
+// (point symmetry).
+//=======================================================================
+void MyPackage_Transformation::SetMirror(const gp_Pnt& thePoint)
+{
+ Backup();
+ myType = gp_PntMirror;
+ myFirstPoint = thePoint;
+}
+
+//=======================================================================
+//function : SetMirror
+//purpose : The method defines an axis mirror type of transformation
+// (axial symmetry).
+//=======================================================================
+void MyPackage_Transformation::SetMirror(const gp_Ax1& theAxis)
+{
+ Backup();
+ myType = gp_Ax1Mirror;
+ myAx1 = theAxis;
+}
+
+//=======================================================================
+//function : SetMirror
+//purpose : The method defines a point mirror type of transformation
+// (planar symmetry).
+//=======================================================================
+void MyPackage_Transformation::SetMirror(const gp_Ax2& thePlane)
+{
+ Backup();
+ myType = gp_Ax2Mirror;
+ myAx2 = thePlane;
+}
+
+//=======================================================================
+//function : SetScale
+//purpose : The method defines a scale type of transformation.
+//=======================================================================
+void MyPackage_Transformation::SetScale(const gp_Pnt& thePoint, const Standard_Real theScale)
+{
+ Backup();
+ myType = gp_Scale;
+ myFirstPoint = thePoint;
+ myScale = theScale;
+}
+
+//=======================================================================
+//function : SetTransformation
+//purpose : The method defines a complex type of transformation
+// from one co-ordinate system to another.
+//=======================================================================
+void MyPackage_Transformation::SetTransformation(const gp_Ax3& theCoordinateSystem1,
+ const gp_Ax3& theCoordinateSystem2)
+{
+ Backup();
+ myFirstAx3 = theCoordinateSystem1;
+ mySecondAx3 = theCoordinateSystem2;
+}
+
+//=======================================================================
+//function : ID
+//purpose : The method returns a unique GUID of the attribute.
+// By means of this GUID this attribute may be identified
+// among other attributes attached to the same label.
+//=======================================================================
+const Standard_GUID& MyPackage_Transformation::ID() const
+{
+ return GetID();
+}
+
+//=======================================================================
+//function : Restore
+//purpose : The method is called on Undo / Redo.
+// It copies the content of <theAttribute>
+// into this attribute (copies the fields).
+//=======================================================================
+void MyPackage_Transformation::Restore(const Handle(TDF_Attribute)& theAttribute)
+{
+ Handle(MyPackage_Transformation) theTransformation = Handle(MyPackage_Transformation)::DownCast(theAttribute);
+ myType = theTransformation->myType;
+ myAx1 = theTransformation->myAx1;
+ myAx2 = theTransformation->myAx2;
+ myFirstAx3 = theTransformation->myFirstAx3;
+ mySecondAx3 = theTransformation->mySecondAx3;
+ myAngle = theTransformation->myAngle;
+ myScale = theTransformation->myScale;
+ myFirstPoint = theTransformation->myFirstPoint;
+ mySecondPoint = theTransformation->mySecondPoint;
+}
+
+//=======================================================================
+//function : NewEmpty
+//purpose : It creates a new instance of this attribute.
+// It is called on Copy / Paste, Undo / Redo.
+//=======================================================================
+Handle(TDF_Attribute) MyPackage_Transformation::NewEmpty() const
+{
+ return new MyPackage_Transformation();
+}
+
+//=======================================================================
+//function : Paste
+//purpose : The method is called on Copy / Paste.
+// It copies the content of this attribute into
+// <theAttribute> (copies the fields).
+//=======================================================================
+void MyPackage_Transformation::Paste(const Handle(TDF_Attribute)& theAttribute,
+ const Handle(TDF_RelocationTable)& ) const
+{
+ Handle(MyPackage_Transformation) theTransformation = Handle(MyPackage_Transformation)::DownCast(theAttribute);
+ theTransformation->myType = myType;
+ theTransformation->myAx1 = myAx1;
+ theTransformation->myAx2 = myAx2;
+ theTransformation->myFirstAx3 = myFirstAx3;
+ theTransformation->mySecondAx3 = mySecondAx3;
+ theTransformation->myAngle = myAngle;
+ theTransformation->myScale = myScale;
+ theTransformation->myFirstPoint = myFirstPoint;
+ theTransformation->mySecondPoint = mySecondPoint;
+}
+
+//=======================================================================
+//function : Dump
+//purpose : Prints the content of this attribute into the stream.
+//=======================================================================
+Standard_OStream& MyPackage_Transformation::Dump(Standard_OStream& anOS) const
+{
+ anOS = "Transformation: ";
+ switch (myType)
+ {
+ case gp_Identity:
+ {
+ anOS = "gp_Identity";
+ break;
+ }
+ case gp_Rotation:
+ {
+ anOS = "gp_Rotation";
+ break;
+ }
+ case gp_Translation:
+ {
+ anOS = "gp_Translation";
+ break;
+ }
+ case gp_PntMirror:
+ {
+ anOS = "gp_PntMirror";
+ break;
+ }
+ case gp_Ax1Mirror:
+ {
+ anOS = "gp_Ax1Mirror";
+ break;
+ }
+ case gp_Ax2Mirror:
+ {
+ anOS = "gp_Ax2Mirror";
+ break;
+ }
+ case gp_Scale:
+ {
+ anOS = "gp_Scale";
+ break;
+ }
+ case gp_CompoundTrsf:
+ {
+ anOS = "gp_CompoundTrsf";
+ break;
+ }
+ case gp_Other:
+ {
+ anOS = "gp_Other";
+ break;
+ }
+ }
+ return anOS;
+}
+
+//=======================================================================
+//function : MyPackage_Transformation
+//purpose : A constructor.
+//=======================================================================
+MyPackage_Transformation::MyPackage_Transformation():myType(gp_Identity){
+
+}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
\ No newline at end of file
--- /dev/null
+Shape Healing {#user_guides__shape_healing}
+===================
+
+@section occt_shg_1 Overview
+
+This manual explains how to use Shape Healing. It provides basic documentation on its operation. For advanced information on Shape Healing and its applications, see our offerings on our web site at <a href="http://www.opencascade.org/support/training/">www.opencascade.org/support/training/</a>
+
+The **Shape Healing** toolkit provides a set of tools to work on the geometry and topology of Open CASCADE Technology (**OCCT**) shapes. Shape Healing adapts shapes so as to make them as appropriate for use by Open CASCADE Technology as possible.
+**Shape Healing** currently includes several packages that are designed to help you to:
+ * analyze shape characteristics and, in particular, identify shapes that do not comply with Open CASCADE Technology validity rules
+ * fix some of the problems shapes may have
+ * upgrade shape characteristics for users needs, for example a C0 supporting surface can be upgraded so that it becomes C1 continuous.
+
+The following diagram shows dependencies of API packages:
+
+
+Each sub-domain has its own scope of functionality:
+* analysis - exploring shape properties, computing shape features, detecting violation of OCCT requirements (shape itself is not modified);
+* fixing - fixing shape to meet the OCCT requirements (the shape may change its original form: modifying, removing, constructing sub-shapes, etc.);
+* upgrade - shape improvement for better usability in Open CASCADE Technology or other algorithms (the shape is replaced with a new one, but geometrically they are the same);
+* customization - modifying shape representation to fit specific needs (shape is not modified, only the form of its representation is modified);
+* processing - mechanism of managing shape modification via a user-editable resource file.
+
+Message management is used for creating messages, filling them with various parameters and storing them in the trace file. This tool provides functionality for attaching messages to the shapes for deferred analysis of various run-time events. In this document only general principles of using Shape Healing will be described. For more detailed information please see the corresponding CDL files.
+Tools responsible for analysis, fixing and upgrading of shapes can give the information about how these operations were performed. This information can be obtained by the user with the help of mechanism of status querying.
+
+@subsection occt_shg_1_1 Querying the statuses
+
+Each fixing and upgrading tool has its own status, which is reset when their methods are called. The status can contain several flags, which give the information about how the method was performed. For exploring the statuses, a set of methods named *Status...()* is provided. These methods accept enumeration *ShapeExtend_Status* and return True if the status has the corresponding flag set. The meaning of flags for each method is described below.
+The status may contain a set of Boolean flags (internally represented by bits). Flags are coded by enumeration ShapeExtend_Status. This enumeration provides the following families of statuses:
+| *ShapeExtend_OK* | The situation is OK, no operation is necessary and has not been performed. |
+| *ShapeExtend_DONE* | The operation has been successfully performed. |
+| *ShapeExtend_FAIL* | An error has occurred during operation. |
+
+It is possible to test the status for the presence of some flag(s), using Status...() method(s) provided by the class:
+
+~~~~~
+if ( object.Status.. ( ShapeExtend_DONE ) ) {// something was done
+}
+~~~~~
+
+8 'DONE' and 8 'FAIL' flags, named ShapeExtend_DONE1 ... ShapeExtend_FAIL8, are defined for a detailed analysis of the encountered situation. Each method assigns its own meaning to each flag, documented in the CDL for that method. There are also three enumerative values used for testing several flags at a time:
+| *ShapeExtend_OK* | if no flags have been set; |
+| *ShapeExtend_DONE* | if at least one ShapeExtend_DONEi has been set; |
+| *ShapeExtend_FAIL* | if at least one ShapeExtend_FAILi has been set; |
+
+@section occt_shg_2 Repair
+
+Algorithms for fixing problematic (violating the OCCT requirements) shapes are placed in package ShapeFix.
+Each class of package ShapeFix deals with one certain type of shapes or with some family of problems.
+There is no necessity for you to detect problems before using ShapeFix because all components of package ShapeFix make an analysis of existing problems before fixing them by a corresponding tool from package of ShapeAnalysis and then fix the discovered problems.
+The ShapeFix package currently includes functions that:
+ * add a 2D curve or a 3D curve where one is missing,
+ * correct a deviation of a 2D curve from a 3D curve when it exceeds a given tolerance value,
+ * limit the tolerance value of shapes within a given range,
+ * set a given tolerance value for shapes,
+ * repair the connections between adjacent edges of a wire,
+ * correct self–intersecting wires,
+ * add seam edges,
+ * correct gaps between 3D and 2D curves,
+ * merge and remove small edges,
+ * correct orientation of shells and solids.
+
+@subsection occt_shg_2_1 Basic Shape Repair
+
+The simplest way for fixing shapes is to use classes *ShapeFix_Shape* and *ShapeFix_Wireframe* on a whole shape with default parameters. A combination of these tools can fix most of the problems that shapes may have.
+The sequence of actions is as follows :
+
+1. Create tool *ShapeFix_Shape* and initialize it by shape:
+
+~~~~~
+Handle(ShapeFix_Shape) sfs = new ShapeFix_Shape;
+sfs->Init ( shape );
+~~~~~
+
+2. Set the basic precision and the maximum allowed tolerance:
+
+~~~~~
+sfs->SetPrecision ( Prec );
+sfs->SetMaxTolerance ( maxTol );
+~~~~~
+
+Where *Prec* – basic precision, *maxTol* – maximum allowed tolerance.
+
+All problems will be detected for cases when a dimension of invalidity is larger than the basic precision or a tolerance of sub-shape on that problem is detected.
+The maximum tolerance value limits the increasing tolerance for fixing a problem. If a value larger than the maximum allowed tolerance is necessary for correcting a detected problem the problem can not be fixed.
+
+3. Launch fixing:
+
+~~~~~
+sfs->Perform();
+~~~~~
+
+4. Get the result:
+
+~~~~~
+TopoDS_Shape aResult = sfs-Shape();
+~~~~~
+
+In some cases using only *ShapeFix_Shape* can be insufficient. It is possible to use tools for merging and removing small edges and fixing gaps between 2D and 3D curves.
+
+5. Create *ShapeFix_Wireframe* tool and initialize it by shape:
+
+~~~~~
+Handle(ShapeFix_Wirefarme) SFWF = new ShapeFix_Wirefarme(shape);
+Or
+Handle(ShapeFix_Wirefarme) SFWF = new ShapeFix_Wirefarme;
+SFWF->Load(shape);
+~~~~~
+
+6. Set the basic precision and the maximum allowed tolerance:
+~~~~~
+sfs->SetPrecision ( Prec );
+sfs->SetMaxTolerance ( maxTol );
+~~~~~
+
+See the description for Prec and maxTol above.
+
+7. Merge and remove small edges:
+~~~~~
+SFWF-DropSmallEdgesMode() = Standard_True;
+SFWF-FixSmallEdges();
+~~~~~
+
+**Note:** Small edges are not removed with the default mode, but in many cases removing small edges is very useful for fixing a shape.
+
+8. Fix gaps for 2D and 3D curves
+~~~~~
+SFWF-FixWireGaps();
+~~~~~
+
+9. Get the result
+~~~~~
+TopoDS_Shape Result = SFWF-Shape();
+~~~~~
+
+
+@subsection occt_shg_2_2 Shape Correction.
+
+If you do not want to make fixes on the whole shape or make a definite set of fixes you can set flags for separate fix cases (marking them ON or OFF) and you can also use classes for fixing specific types of sub-shapes such as solids, shells, faces, wires, etc.
+For each type of sub-shapes there are specific types of fixing tools such as *ShapeFix_Solid, ShapeFix_Shell, ShapeFix_Face, ShapeFix_Wire,* etc.
+
+@subsubsection occt_shg_2_2_1 Fixing sub-shapes
+If you want to make a fix on one subshape of a certain shape it is possible to take the following steps:
+ * create a tool for a specified subshape type and initialize this tool by the subshape;
+ * create a tool for rebuilding the shape and initialize it by the whole shape (section 5.1);
+ * set a tool for rebuilding the shape in the tool for fixing the subshape;
+ * fix the subshape;
+ * get the resulting whole shape containing a new corrected subshape.
+
+For example, in the following way it is possible to fix face Face1 of shape Shape1
+
+~~~~~
+//create tools for fixing a face
+Handle(ShapeFix_Face) SFF= new ShapeFix_Face;
+
+// create tool for rebuilding a shape and initialize it by shape
+Handle(ShapeBuild_ReShape) Context = new ShapeBuild_ReShape;
+Context-Apply(Shape1);
+
+//set a tool for rebuilding a shape in the tool for fixing
+SFF-SetContext(Context);
+
+//initialize the fixing tool by one face
+SFF-Init(Face1);
+
+//fix the set face
+SFF-Perform();
+
+//get the result
+TopoDS_Shape NewShape = Context-Apply(Shape1);
+//Resulting shape contains the fixed face.
+~~~~~
+
+A set of required fixes and invalid sub-shapes can be obtained with the help of tools responsible for the analysis of shape validity (section 3.2).
+
+@subsection occt_shg_2_3 Repairing tools
+
+Each class of package ShapeFix deals with one certain type of shapes or with a family of problems. Each repairing tool makes fixes for the specified shape and its sub-shapes with the help of method *Perform()* containing an optimal set of fixes. The execution of these fixes in the method Perform can be managed with help of a set of control flags (fixes can be either forced or forbidden).
+
+@subsubsection occt_shg_2_3_1 General Workflow
+
+The following sequence of actions should be applied to perform fixes:
+1. Create a tool.
+2. Set the following values:
+ + the working precision by method *SetPrecision()* (default 1.e-7)
+ + set the maximum allowed tolerance by method *SetMaxTolerance()* (by default it is equal to the working precision).
+ + set the minimum tolerance by method *SetMinTolerance()* (by default it is equal to the working precision).
+ + set a tool for rebuilding shapes after the modification (tool *ShapeBuild_ReShape*) by method *SetContext()*. For separate faces, wires and edges this tool is set optionally.
+ + to force or forbid some of fixes, set the corresponding flag to 0 or 1.
+3. Initialize the tool by the shape with the help of methods Init or Load
+4. Use method *Perform()* or create a custom set of fixes.
+5. Check the statuses of fixes by the general method *Status* or specialized methods *Status_*(for example *StatusSelfIntersection* (*ShapeExtentd_DONE*)). See the description of statuses below.
+6. Get the result in two ways :
+ - with help of a special method *Shape(),Face(),Wire().Edge()*.
+ - from the rebuilding tool by method *Apply* (for access to rebuilding tool use method *Context()*):
+~~~~~
+ TopoDS_Shape resultShape = fixtool-Context()-Apply(initialShape);
+~~~~~
+Modification fistory for the shape and its sub-shapes can be obtained from the tool for shape re-building (*ShapeBuild_ReShape*).
+
+~~~~~
+TopoDS_Shape modifsubshape = fixtool-Context()
+-Apply(initsubshape);
+~~~~~
+
+
+@subsubsection occt_shg_2_3_2 Flags Management
+
+The flags *Fix...Mode()* are used to control the execution of fixing procedures from the API fixing methods. By default, these flags have values equal to -1, this means that the corresponding procedure will either be called or not called, depending on the situation. If the flag is set to 1, the procedure is executed anyway; if the flag is 0, the procedure is not executed. The name of the flag corresponds to the fixing procedure that is controlled. For each fixing tool there exists its own set of flags. To set a flag to the desired value, get a tool containing this flag and set the flag to the required value.
+
+For example, it is possible to forbid performing fixes to remove small edges - *FixSmall*
+
+~~~~~
+Handle(ShapeFix_Shape) Sfs = new ShapeFix_Shape(shape);
+Sfs- FixWireTool ()-FixSmallMode () =0;
+if(Sfs-Perform())
+ TopoDS_Shape resShape = Sfs-Shape();
+~~~~~
+
+
+@subsubsection occt_shg_2_3_3 Repairing tool for shapes
+
+Class ShapeFix_Shape allows using repairing tools for all sub-shapes of a shape. It provides access to all repairing tools for fixing sub-shapes of the specified shape and to all control flags from these tools.
+
+For example, it is possible to force the removal of invalid 2D curves from a face.
+
+~~~~~
+TopoDS_Face face … // face with invalid 2D curves.
+//creation of tool and its initialization by shape.
+Handle(ShapeFix_Shape) sfs = new ShapeFix_Shape(face);
+//set work precision and max allowed tolerance.
+sfs->SetPrecision(prec);
+sfs->SetMaxTolerance(maxTol);
+//set the value of flag for forcing the removal of 2D curves
+sfs->FixWireTool()-FixRemovePCurveMode() =1;
+//reform fixes
+sfs->Perform();
+//getting the result
+if(sfs->Status(ShapeExtend_DONE) ) {
+ cout << Shape was fixed << endl;
+ TopoDS_Shape resFace = sfs->Shape();
+}
+else if(sfs->Status(ShapeExtend_FAIL)) {
+cout<< Shape could not be fixed << endl;
+}
+else if(sfs->Status(ShapeExtent_OK)) {
+cout<< Initial face is valid with specified precision =<< precendl;
+}
+~~~~~
+
+@subsubsection occt_shg_2_3_4 Repairing tool for solids
+
+Class *ShapeFix_Solid* allows fixing solids and building a solid from a shell to obtain a valid solid with a finite volume. The tool *ShapeFix_Shell* is used for correction of shells belonging to a solid.
+
+This tool has the following control flags:
+* *FixShellMode* - Mode for applying fixes of ShapeFix_Shell, True by default.
+* *CreateOpenShellMode* - If it is equal to true solids are created from open shells, else solids are created from closed shells only, False by default.
+
+@subsubsection occt_shg_2_3_5 Repairing tool for shells
+Class *ShapeFix_Shell* allows fixing wrong orientation of faces in a shell. It changes the orientation of faces in the shell so that all faces in the shell have coherent orientations. If it is impossible to orient all faces in the shell (like in case of Mebious tape), then a few manifold or non-manifold shells will be created depending on the specified Non-manifold mode. The ShapeFix_Face tool is used to correct faces in the shell.
+This tool has the following control flags:
+* *FixFaceMode * - mode for applying the fixes of ShapeFix_Face, True by default.
+* *FixOrientationMode* - mode for applying a fix for the orientation of faces in the shell.
+
+@subsubsection occt_shg_2_3_6 Repairing tool for faces
+
+Class ShapeFix_Face allows fixing the problems connected with wires of a face. It allows controlling the creation of a face (adding wires), and fixing wires by means of tool *ShapeFix_Wire*.
+When a wire is added to a face, it can be reordered and degenerated edges can be fixed. This is performed or not depending on the user-defined flags (by default, False).
+The following fixes are available:
+ * fixing of wires orientation on the face. If the face has no wire, the natural bounds are computed. If the face is on a spherical surface and has two or more wires on it describing holes, the natural bounds are added. In case of a single wire, it is made to be an outer one. If the face has several wires, they are oriented to lay one outside another (if possible). If the supporting surface is periodic, 2D curves of internal wires can be shifted on integer number of periods to put them inside the outer wire.
+ * fixing the case when the face on the closed surface is defined by a set of closed wires, and the seam is missing (this is not valid in Open CASCADE Technology). In that case, these wires are connected by means of seam edges into the same wire.
+
+This tool has the following control flags:
+* *FixWireMode* - mode for applying fixes of a wire, True by default.
+* *FixOrientationMode* - mode for orienting a wire to border a limited square, True by default.
+* *FixAddNaturalBoundMode* - mode for adding natural bounds to a face, False by default.
+* *FixMissingSeamMode* – mode to fix a missing seam, True by default. If True, tries to insert a seam.
+* *FixSmallAreaWireMode * - mode to fix a small-area wire, False by default. If True, drops wires bounding small areas.
+
+~~~~~
+
+TopoDS_Face face = ...;
+TopoDS_Wire wire = ...;
+
+//Creates a tool and adds a wire to the face
+ShapeFix_Face sff (face);
+sff.Add (wire);
+
+//use method Perform to fix the wire and the face
+sff.Perfom();
+
+//or make a separate fix for the orientation of wire on the face
+sff.FixOrientation();
+
+//Get the resulting face
+TopoDS_Face newface = sff.Face();
+~~~~~
+
+@subsubsection occt_shg_2_3_7 Repairing tool for wires ()
+
+Class ShapeFix_Wire allows fixing a wire. Its method Perform() performs all the available fixes in addition to the geometrical filling of gaps. The geometrical filling of gaps can be made with the help of the tool for fixing the wireframe of shape *ShapeFix_Wireframe*.
+
+The fixing order and the default behavior of *Perform()* is as follows:
+ * Edges in the wire *FixReorder* are reordered; in case it is forbidden, the analysis of whether the wire is ordered or not is performed anyway (this information is used for determining the default behavior of other methods).
+ * Small edges *FixSmall *are removed.
+ * Edges in the wire are connected (topologically) *FixConnected* (if the wire is ordered).
+ * Edges (3Dcurves and 2D curves) *FixEdgeCurves* (without *FixShifted* if the wire is not ordered) are fixed.
+ * Degenerated edges *FixDegenerated* are added (if the wire is ordered).
+ * Self-intersection *FixSelfIntersection* is fixed (if the wire is ordered and *ClosedMode* is True).
+ * Lacking edges *FixLacking* are fixed (if the wire is ordered).
+
+Most of fixing methods expect edges in a wire to be ordered, so it is necessary to make call to *FixReorder()* before making any other fixes.
+
+Some fixes can be made in three ways:
+ * Increasing the tolerance of an edge or a vertex.
+ * Changing topology (adding/removing/replacing an edge in the wire and/or replacing the vertex in the edge, copying the edge etc.).
+ * Changing geometry (shifting a vertex or adjusting ends of an edge curve to vertices, or re-computing a 3D curve or 2D curves of the edge).
+
+When it is possible to make a fix in more than one way (e.g., either by increasing the tolerance or shifting a vertex), it is chosen according to the user-defined flags:
+* *ModifyTopologyMode* - allows modifying topology, False by default.
+* *ModifyGeometryMode* - allows modifying geometry. Now this flag is used only in fixing self-intersecting edges (allows to modify 2D curves) and is True by default.
+
+The methods of this class correct the following problems. They:
+ * fix disordered edges in the wire (reorder),
+ * fix small edges (remove edges with a length less than the given value),
+ * fix disconnected edges (adjacent edges having different vertices),
+ * fix the consistency of edge curves,
+ * fix degenerated edges,
+ * fix intersections of 2D curves of the edges,
+ * fix lacking edges to fill gaps in the parametrical space of a surface,
+ * fix gaps in 2D and 3D wires by means of geometrical filling.
+
+Fixing disordered edges
+-----------------------
+This fix is necessary for most other fixes (but is not necessary for Open CASCADE Technology). It checks whether edges in the wire go in a sequential order (the end of a preceding edge is the start of a following one). If it is not so, an attempt to reorder the edges is made.
+
+Fixing small edges
+------------------
+This fixing method searches for the edges, which have a length less than the given value (degenerated edges are ignored). If such an edge is found, it is removed provided that one of the following conditions is satisfied:
+ * both end vertices of that edge are one and the same vertex,
+ * end vertices of the edge are different, but the flag *ModifyTopologyMode* is True. In the latter case, method *FixConnected* is applied to the preceding and the following edges to ensure their connection.
+
+Fixing disconnected edges
+-------------------------
+This method forces two adjacent edges to share the same common vertex (if they do not have a common one). It checks whether the end vertex of the preceding edge coincides with the start vertex of the following edge with the given precision, and then creates a new vertex and sets it as a common vertex for the fixed edges. At that point, edges are copied, hence the wire topology is changed (regardless of the *ModifyTopologyMode* flag). If the vertices do not coincide, this method fails.
+
+Fixing the consistency of edge curves
+-------------------------------------
+This method performs a set of fixes dealing with 3D curves and 2D curves of edges in a wire.
+These fixes will be activated with the help of a set of fixes from the repairing tool for edges called *ShapeFix_Edge*. Each of these fixes can be forced or forbidden by means of setting the corresponding flag to either True or False. The mentioned fixes and the conditions of their execution are:
+ * fixing a disoriented 2D curve by call to *ShapeFix_Edge::FixReversed2d* - if not forbidden,
+ * removing a wrong 2D curve by call to *ShapeFix_Edge::FixRemovePCurve* - only if forced,
+ * fixing a missing 2D curve by call to *ShapeFix_Edge::FixAddPCurve* - if not forbidden,
+ * removing a wrong 3D curve by call to *ShapeFix_Edge::FixRemoveCurve3d* - only if forced,
+ * fixing a missing 3D curve by call to *ShapeFix_Edge::FixAddCurve3d* - if not forbidden,
+ * fixing 2D curves of seam edges - if not forbidden.
+ * fixing 2D curves which can be shifted at an integer number of periods on the closed surface - if not forbidden. This fix is required if 2D curves of some edges in a wire lying on a closed surface were recomputed from 3D curves. In that case, the 2D curve for the edge, which goes along the seam of the surface, can be incorrectly shifted at an integer number of periods. The method detects such cases and shifts wrong 2D curves back, ensuring that the 2D curves of the edges in the wire are connected,
+ * fixing the SameParameter problem by call to *ShapeFix_Edge::FixSameParameter* - if not forbidden.
+
+Fixing degenerated edges
+------------------------
+This method checks whether an edge in a wire lies on a degenerated point of the supporting surface, or whether there is a degenerated point between the edges. If one of these cases is detected for any edge, a new degenerated edge is created and it replaces the current edge in the first case or is added to the wire in the second case. The newly created degenerated edge has a straight 2D curve, which goes from the end of the 2D curve of the preceding edge to the start of the following one.
+
+Fixing intersections of 2D curves of the edges
+----------------------------------------------
+This method detects and fixes the following problems:
+ * self-intersection of 2D curves of individual edges. If the flag *ModifyGeometryMode()* is False this fix will be performed by increasing the tolerance of one of end vertices to a value less then *MaxTolerance()*.
+ * intersection of 2D curves of each of the two adjacent edges (except the first and the last edges if the flag ClosedWireMode is False). If such intersection is found, the common vertex is modified in order to comprise the intersection point. If the flag *ModifyTopologyMode* is False this fix will be performed by increasing the tolerance of the vertex to a value less then *MaxTolerance()*.
+ * intersection of 2D curves of non-adjacent edges. If such intersection is found the tolerance of the nearest vertex is increased to comprise the intersection point. If such increase cannot be done with a tolerance less than MaxTolerance this fix will not be performed.
+
+
+Fixing a lacking edge
+---------------------
+This method checks whether a wire is not closed in the parametrical space of the surface (while it can be closed in 3D). This is done by checking whether the gap between 2D curves of each of the two adjacent edges in the wire is smaller than the tolerance of the corresponding vertex. The algorithm computes the gap between the edges, analyses positional relationship of the ends of these edges and (if possible) tries to insert a new edge into the gap or increases the tolerance.
+
+Fixing gaps in 2D and 3D wire by geometrical filling
+----------------------------------------------------
+These methods check gaps between the ends of 2D or 3D curves of adjacent edges. Boolean flag *FixGapsByRanges* is used to activate an additional mode applied before converting to B-Splines. When this mode is on, methods try to find the most precise intersection of curves, or the most precise projection of a target point, or an extremity point between two curves (to modify their parametric range accordingly). This mode is off by default. Independently of the additional mode described above, if gaps remain, these methods convert curves to B-Spline form and shift their ends if a gap is detected.
+Method *FixGap2d* moves the ends of 2D curves to the middle point. Method *FixGaps3d* moves the ends of 3D curves to a common vertex.
+
+This tool has the following control flags:
+* *ClosedWireMode* -specifies whether the wire is (or should be) closed or not. If that flag is True (by default), fixes that require or force connection between edges are executed for the last and the first edges also, otherwise they are not.
+* *FixReorderMode, *
+* *FixSmallMode, *
+* *FixConnectedMode, *
+* *FixEdgeCurvesMode, *
+* *FixDegeneratedMode, *
+* *FixSelfIntersectionMode,*
+* *FixLackingMode.*
+
+The following flags are defined for method *FixEdgeCurves()*:
+* *FixReversed2dMode, *
+* *FixRemovePCurveMode, *
+* *FixRemoveCurve3dMode, *
+* *FixAddPCurveMode, *
+* *FixAddCurve3dMode, *
+* *FixSeamMode, *
+* *FixShiftedMode, *
+* *FixSameParameterMode. *
+
+The following flags are defined for method *FixSelfIntersection()*:
+* *FixSelfIntersectingEdgeMode, *
+* *FixIntersectingEdgesMode*.
+
+Example: A custom set of fixes
+------------------------------
+
+Let us create a custom set of fixes as an example.
+~~~~~
+TopoDS_Face face = ...;
+TopoDS_Wire wire = ...;
+Standard_Real precision = 1e-04;
+ShapeFix_Wire sfw (wire, face, precision);
+//Creates a tool and loads objects into it
+sfw.FixReorder();
+//Orders edges in the wire so that each edge
+//starts at the end of the one before it
+sfw.FixConnected();
+//Forces all adjacent edges to share
+//the same vertex
+Standard_Boolean LockVertex = Standard_True;
+if (sfw.FixSmall (LockVertex, precision)) {
+ //Removes all edges which are shorter than
+ //the given precision and have the same vertex at both ends
+}
+if (sfw.FixSelfIntersection()) {
+ //Fixes self-intersecting edges and intersecting
+ //adjacent edges
+ cout;Wire was slightly self-intersecting. Repaired;endl;
+}
+if ( sfw.FixLacking ( Standard_False ) ) {
+ //Inserts edges to connect adjacent
+ //non-continuous edges
+}
+TopoDS_Wire newwire = sfw.Wire();
+//Returns the corrected wire
+~~~~~
+
+Example: Correction of a wire
+-----------------------------
+
+Let us correct the following wire:
+
+
+
+It is necessary to apply the <a href="occt_shg_3_1_2">Tools for the analysis of validity of wires</a> to check that:
+* the edges are correctly oriented;
+* there are no edges that are too short;
+* there are no intersecting adjacent edges;
+and then immediately apply fixing tools.
+
+~~~~~
+TopoDS_Face face = ...;
+TopoDS_Wire wire = ...;
+Standard_Real precision = 1e-04;
+ShapeAnalysis_Wire saw (wire, face, precision);
+ShapeFix_Wire sfw (wire, face, precision);
+if (saw.CheckOrder()) {
+ cout<<“Some edges in the wire need to be reordered”<<endl;
+ // Two edges are incorrectly oriented
+ sfw.FixReorder();
+ cout<<“Reordering is done”<<endl;
+}
+// their orientation is corrected
+if (saw.CheckSmall (precision)) {
+ cout<<“Wire contains edge(s) shorter than “<<precision<<endl;
+ // An edge that is shorter than the given
+ // tolerance is found
+ Standard_Boolean LockVertex = Standard_True;
+ if (sfw.FixSmall (LockVertex, precision)) {
+ cout<<“Edges shorter than “<<precision<<“ have been removed”
+<<endl;
+ //The edge is removed
+ }
+}
+if (saw.CheckSelfIntersection()) {
+ cout<<“Wire has self-intersecting or intersecting
+adjacent edges”<<endl;
+ // Two intersecting adjacent edges are found
+ if (sfw.FixSelfIntersection()) {
+ cout<<“Wire was slightly self-intersecting. Repaired”<<endl;
+ // The edges are cut at the intersection point so
+ // that they no longer intersect
+ }
+}
+~~~~~
+
+As the result all failures have been fixed.
+
+
+
+@subsubsection occt_shg_2_3_8 Repairing tool for edges
+
+Class *ShapeFix_Edge* provides tools for fixing invalid edges. The following geometrical and/or topological inconsistencies are detected and fixed:
+ * missing 3D curve or 2D curve,
+ * mismatching orientation of a 3D curve and a 2D curve,
+ * incorrect SameParameter flag (curve deviation is greater than the edge tolerance).
+Each fixing method first checks whether the problem exists using methods of the *ShapeAnalysis_Edge* class. If the problem is not detected, nothing is done.
+This tool does not have the method *Perform()*.
+
+To see how this tool works, it is possible to take an edge, where the maximum deviation between the 3D curve and 2D curve P1 is greater than the edge tolerance.
+
+
+
+First it is necessary to apply the <a href="occt_shg_3_1_3">Tool for checking the validity of edges</a> to find that maximum deviation between pcurve and 3D curve is greater than tolerance. Then we can use the repairing tool to increase the tolerance and make the deviation acceptable.
+
+~~~~~
+ShapeAnalysis_Edge sae;
+TopoDS_Face face = ...;
+TopoDS_Wire wire = ...;
+Standard_Real precision = 1e-04;
+ShapeFix_Edge sfe;
+Standard_Real maxdev;
+if (sae.CheckSameParameter (edge, maxdev)) {
+ cout<<“Incorrect SameParameter flag”<<endl;
+ cout<<“Maximum deviation “<<maxdev<< “, tolerance “
+<<BRep_Tool::Tolerance(edge)<<endl;
+ sfe.FixSameParameter();
+ cout<<“New tolerance “<<BRep_Tool::Tolerance(edge)<<endl;
+}
+~~~~~
+
+
+
+As the result, the edge tolerance has been increased.
+
+
+@subsubsection occt_shg_2_3_9 Repairing tool for the wireframe of a shape
+
+Class *ShapeFix_Wireframe provides methods for geometrical fixing of gaps and merging small edges in a shape. This class performs the following operations:
+ * fills gaps in the 2D and 3D wireframe of a shape.
+ * merges and removes small edges.
+
+Fixing of small edges can be managed with the help of two flags:
+ * *ModeDropSmallEdges()* – mode for removing small edges that can not be merged, by default it is equal to Standard_False.
+ * *LimitAngle* – maximum possible angle for merging two adjacent edges, by default no limit angle is applied (-1).
+To perform fixes it is necessary to:
+ * create a tool and initialize it by shape,
+ * set the working precision problems will be detected with and the maximum allowed tolerance
+ * perform fixes
+
+~~~~~
+//creation of a tool
+Handle(ShapeFix_Wireframe) sfwf = new ShapeFix_Wireframe(shape);
+//sets the working precision problems will be detected with and
+//the maximum allowed tolerance
+sfwf->SetPrecision(prec);
+sfwf->SetMaxTolerance(maxTol);
+//fixing of gaps
+sfwf->FixWireGaps();
+//fixing of small edges
+//setting of the drop mode for the fixing of small edges and max possible angle between merged edges.
+sfwf->ModeDropSmallEdges = Standard_True;
+sfwf->SetLimliteAngle(angle);
+//performing the fix
+sfwf->FixSmallEdges();
+//getting the result
+TopoDS_Shape resShape = sfwf->Shape();
+~~~~~
+
+It is desirable that a shape is topologically correct before applying the methods of this class.
+
+@subsubsection occt_shg_2_3_10 Tool for removing small faces from a shape
+
+Class ShapeFix_FixSmallFaceThis tool is intended for dropping small faces from the shape. The following cases are processed:
+* Spot face: if the size of the face is less than the given precision;
+* Strip face: if the size of the face in one dimension is less then the given precision.
+
+The sequence of actions for performing the fix is the same as for the fixes described above:
+
+~~~~~
+//creation of a tool
+Handle(ShapeFix_FixSmallFace) sff = new ShapeFix_FixSmallFace(shape);
+//setting of tolerances
+sff->SetPrecision(prec);
+sff->SetMaxTolerance(maxTol);
+//performing fixes
+sff.Perform();
+//getting the result
+TopoDS_Shape resShape = sff.FixShape();
+~~~~~
+
+@subsubsection occt_shg_2_3_11 Tool to modify tolerances of shapes (Class ShapeFix_ShapeTolerance).
+
+This tool provides a functionality to set tolerances of a shape and its sub-shapes.
+In Open CASCADE Technology only vertices, edges and faces have tolerances.
+
+This tool allows processing each concrete type of sub-shapes or all types at a time.
+You set the tolerance functionality as follows:
+ * set a tolerance for sub-shapes, by method SetTolerance,
+ * limit tolerances with given ranges, by method LimitTolerance.
+
+~~~~~
+//creation of a tool
+ShapeFix_ShapeTolerance Sft;
+//setting a specified tolerance on shape and all of its sub-shapes.
+Sft.SetTolerance(shape,toler);
+//setting a specified tolerance for vertices only
+Sft.SetTolerance(shape,toler,TopAbs_VERTEX);
+//limiting the tolerance on the shape and its sub-shapes between minimum and
+//maximum tolerances
+Sft.LimitTolerance(shape,tolermin,tolermax);
+~~~~~
+
+
+@section occt_shg_3 Analysis
+
+@section occt_shg_3_1 Analysis of shape validity
+
+The *ShapeAnalysis* package provides tools for the analysis of topological shapes.
+It is not necessary to check a shape by these tools before the execution of repairing tools because these tools are used for the analysis before performing fixes inside the repairing tools.
+However, if you want, these tools can be used for detecting some of shape problems independently from the repairing tools.
+ It can be done in the following way:
+ * create an analysis tool.
+ * initialize it by shape and set a tolerance problems will be detected with if it is necessary.
+ * check the problem that interests you.
+
+~~~~~
+TopoDS_Face face = ...;
+ShapeAnalysis_Edge sae;
+//Creates a tool for analyzing an edge
+for(TopExp_Explorer Exp(face,TopAbs_EDGE);Exp.More();Exp.Next()) {
+ TopoDS_Edge edge = TopoDS::Edge (Exp.Current());
+ if (!sae.HasCurve3d (edge)) {
+ cout *Edge has no 3D curve* endl; }
+}
+~~~~~
+
+@subsubsection occt_shg_3_1_1 Analysis of orientation of wires on a face.
+
+It is possible to check whether a face has an outer boundary with the help of method *ShapeAnalysis::IsOuterBound*.
+
+~~~~~
+TopoDS_Face face … //analyzed face
+if(!ShapeAnalysis::IsOuterBound(face)) {
+cout*Face has not outer boundary**endl;
+}
+~~~~~
+
+@subsubsection occt_shg_3_1_2 Analysis of wire validity
+
+Class *ShapeAnalysis_Wire* is intended to analyze a wire. It provides functionalities both to explore wire properties and to check its conformance to Open CASCADE Technology requirements.
+These functionalities include:
+ * checking the order of edges in the wire,
+ * checking for the presence of small edges (with a length less than the given value),
+ * checking for the presence of disconnected edges (adjacent edges having different vertices),
+ * checking the consistency of edge curves,
+ * checking for the presence or missing of degenerated edges,
+ * checking for the presence of self-intersecting edges and intersecting edges (edges intersection is understood as intersection of their 2D curves),
+ * checking for lacking edges to fill gaps in the surface parametrical space,
+ * analyzing the wire orientation (to define the outer or the inner bound on the face),
+ * analyzing the orientation of the shape (edge or wire) being added to an already existing wire.
+
+*Note* that all checking operations except for the first one are based on the assumption that edges in the wire are ordered. Thus, if the wire is detected as non-ordered it is necessary to order it before calling other checking operations. This can be done, for example, with the help of the *ShapeFix_Wire::FixOrder()* method.
+This tool should be initialized with wire, face (or a surface with a location) or precision.
+Once the tool has been initialized, it is possible to perform the necessary checking operations. In order to obtain all information on a wire at a time the global method *Perform* is provided. It calls all other API checking operations to check each separate case.
+API methods check for corresponding cases only, the value and the status they return can be analyzed to understand whether the case was detected or not.
+Some methods in this class are:
+ * *CheckOrder* checks whether edges in the wire are in the right order
+ * *CheckConnected* checks whether edges are disconnected
+ * *CheckSmall* checks whether there are edges that are shorter than the given value
+ * *CheckSelfIntersection* checks, whether there are self-intersecting or adjacent intersecting edges. If the intersection takes place due to nonadjacent edges, it is not detected.
+This class maintains status management. Each API method stores the status of its last execution which can be queried by the corresponding Status..() method. In addition, each API method returns a Boolean value, which is True when a case being analyzed is detected (with the set ShapeExtend_DONE status), otherwise it is False.
+
+~~~~~
+TopoDS_Face face = ...;
+TopoDS_Wire wire = ...;
+Standard_Real precision = 1e-04;
+ShapeAnalysis_Wire saw (wire, face, precision);
+//Creates a tool and loads objects into it
+if (saw.CheckOrder()) {
+ cout*Some edges in the wire need to be reordered*endl;
+ cout*Please ensure that all the edges are correctly
+ordered before further analysis*endl;
+ return;
+}
+if (saw.CheckSmall (precision)) {
+ cout*Wire contains edge(s) shorter than *precisionendl;
+}
+if (saw.CheckConnected()) {
+ cout*Wire is disconnected*endl;
+}
+if (saw.CheckSelfIntersection()) {
+ cout*Wire has self-intersecting or intersecting
+adjacent edges* endl;
+}
+~~~~~
+
+@subsubsection occt_shg_3_1_3 Analysis of edge validity
+
+Class *ShapeAnalysis_Edge* is intended to analyze edges. It provides the following functionalities to work with an edge:
+ * querying geometrical representations (3D curve and pcurve(s) on a given face or surface),
+ * querying topological sub-shapes (bounding vertices),
+ * checking overlapping edges,
+ * analyzing the curves consistency:
+ + mutual orientation of the 3D curve and 2D curve (co-directions or opposite directions),
+ + correspondence of 3D and 2D curves to vertices.
+
+This class supports status management described above.
+
+~~~~~
+TopoDS_Face face = ...;
+ShapeAnalysis_Edge sae;
+//Creates a tool for analyzing an edge
+for(TopExp_Explorer Exp(face,TopAbs_EDGE);Exp.More();Exp.Next()) {
+ TopoDS_Edge edge = TopoDS::Edge (Exp.Current());
+ if (!sae.HasCurve3d (edge)) {
+ cout *Edge has no 3D curve* endl;
+ }
+ Handle(Geom2d_Curve) pcurve;
+ Standard_Real cf, cl;
+ if (sae.PCurve (edge, face, pcurve, cf, cl, Standard_False)) {
+ //Returns the pcurve and its range on the given face
+ cout*Pcurve range [*cf*, *cl*]* endl;
+ }
+ Standard_Real maxdev;
+ if (sae.CheckSameParameter (edge, maxdev)) {
+ //Checks the consistency of all the curves
+ //in the edge
+ cout*Incorrect SameParameter flag*endl;
+ }
+ cout*Maximum deviation *maxdev*, tolerance*
+ BRep_Tool::Tolerance(edge)endl;
+}
+//checks the overlapping of two edges
+if(sae.CheckOverlapping(edge1,edge2,prec,dist)) {
+ cout*Edges are overlapped with tolerance = *precendl;
+ cout*Domain of overlapping =*distendl;
+}
+~~~~~
+
+@subsubsection occt_shg_3_1_4 Analysis of presence of small faces
+
+Class *ShapeAnalysis_CheckSmallFace* class is intended for analyzing small faces from the shape using the following methods:
+* *CheckSpotFace()* checks if the size of the face is less than the given precision;
+* *CheckStripFace* checks if the size of the face in one dimension is less than the given precision.
+
+~~~~~
+TopoDS_Shape shape … // checked shape
+//Creation of a tool
+ShapeAnalysis_CheckSmallFace saf;
+//exploring the shape on faces and checking each face
+Standard_Integer numSmallfaces =0;
+for(TopExp_Explorer aExp(shape,TopAbs_FACE); aExp.More(); aExp.Next()) {
+ TopoDS_Face face = TopoDS::Face(aexp.Current());
+ TopoDS_Edge E1,E2;
+if(saf.CheckSpotFace(face,prec) ||
+saf.CheckStripFace(face,E1,E2,prec))
+NumSmallfaces++;
+}
+if(numSmallfaces)
+ cout*Number of small faces in the shape =* numSmallfaces endl;
+~~~~~
+
+@subsubsection occt_shg_3_1_5 Analysis of shell validity and closure
+
+Class *ShapeAnalysis_Shell* allows checking the orientation of edges in a manifold shell. With the help of this tool, free edges (edges entered into one face) and bad edges (edges entered into the shell twice with the same orientation) can be found. By occurrence of bad and free edges a conclusion about the shell validity and the closure of the shell can be made.
+
+~~~~~
+TopoDS_Shell shell // checked shape
+ShapeAnalysis_Shell sas(shell);
+//analysis of the shell , second parameter is set to True for //getting free edges,(default False)
+sas.CheckOrientedShells(shell,Standard_True);
+//getting the result of analysis
+if(sas.HasBadEdges()) {
+cout<<"Shell is invalid"<<endl;
+TopoDS_Compound badEdges = sas.BadEdges();
+}
+if(sas.HasFreeEdges()) {
+ cout<<"Shell is open"<<endl;
+ TopoDS_Compound freeEdges = sas.FreeEdges();
+}
+~~~~~
+
+@subsection occt_shg_3_2 Analysis of shape properties.
+@subsubsection occt_shg_3_2_1 Analysis of tolerance on shape
+
+Class *ShapeAnalysis_ShapeTolerance* allows computing tolerances of the shape and its sub-shapes. In Open CASCADE Technology only vertices, edges and faces have tolerances:
+
+This tool allows analyzing each concrete type of sub-shapes or all types at a time.
+The analysis of tolerance functionality is the following:
+ * computing the minimum, maximum and average tolerances of sub-shapes,
+ * finding sub-shapes with tolerances exceeding the given value,
+ * finding sub-shapes with tolerances in the given range.
+
+~~~~~
+TopoDS_Shape shape = ...;
+ShapeAnalysis_ShapeTolerance sast;
+Standard_Real AverageOnShape = sast.Tolerance (shape, 0);
+cout*Average tolerance of the shape is *AverageOnShapeendl;
+Standard_Real MinOnEdge = sast.Tolerance (shape,-1,TopAbs_EDGE);
+cout*Minimum tolerance of the edges is *MinOnEdgeendl;
+Standard_Real MaxOnVertex = sast.Tolerance (shape,1,TopAbs_VERTEX);
+cout*Maximum tolerance of the vertices is *MaxOnVertexendl;
+Standard_Real MaxAllowed = 0.1;
+if (MaxOnVertex MaxAllowed) {
+ cout*Maximum tolerance of the vertices exceeds
+ maximum allowed*endl;
+}
+~~~~~
+
+@subsubsection occt_shg_3_2_2 Analysis of free boundaries.
+
+Class ShapeAnalysis_FreeBounds is intended to analyze and output the free bounds of a shape. Free bounds are wires consisting of edges referenced only once by only one face in the shape.
+This class works on two distinct types of shapes when analyzing their free bounds:
+* Analysis of possible free bounds taking the specified tolerance into account. This analysis can be applied to a compound of faces. The analyzer of the sewing algorithm (*BRepAlgo_Sewing*) is used to forecast what free bounds would be obtained after the sewing of these faces is performed. The following method should be used for this analysis:
+~~~~~
+ShapeAnalysis_FreeBounds safb(shape,toler);
+~~~~~
+* Analysis of already existing free bounds. Actual free bounds (edges shared by the only face in the shell) are output in this case. *ShapeAnalysis_Shell* is used for that.
+~~~~~
+ShapeAnalysis_FreeBounds safb(shape);
+~~~~~
+When connecting edges into wires this algorithm tries to build wires of maximum length. Two options are provided for the user to extract closed sub-contours out of closed and/or open contours. Free bounds are returned as two compounds, one for closed and one for open wires. To obtain a result it is necessary to use methods:
+~~~~~
+TopoDS_Compound ClosedWires = safb.GetClosedWires();
+TopoDS_Compound OpenWires = safb.GetOpenWires();
+~~~~~
+This class also provides some static methods for advanced use: connecting edges/wires to wires, extracting closed sub-wires from wires, distributing wires into compounds for closed and open wires.
+
+~~~~~
+TopoDS_Shape shape = ...;
+Standard_Real SewTolerance = 1.e-03;
+//Tolerance for sewing
+Standard_Boolean SplitClosed = Standard_False;
+Standard_Boolean SplitOpen = Standard_True;
+//in case of analysis of possible free boundaries
+ShapeAnalysis_FreeBounds safb (shape, SewTolerance,
+SplitClosed, SplitOpen);
+//in case of analysis of existing free bounds
+ShapeAnalysis_FreeBounds safb (shape, SplitClosed, SplitOpen);
+//getting the results
+TopoDS_Compound ClosedWires = safb.GetClosedWires();
+//Returns a compound of closed free bounds
+TopoDS_Compound OpenWires = safb.GetClosedWires();
+//Returns a compound of open free bounds
+~~~~~
+
+@subsubsection occt_shg_3_2_3 Analysis of shape contents
+
+Class ShapeAnalysis_ShapeContents provides tools counting the number of sub-shapes and selecting a sub-shape by the following criteria:
+Methods for getting the number of sub-shapes:
+ * number of solids,
+ * number of shells,
+ * number of faces,
+ * number of edges,
+ * number of vertices.
+Methods for calculating the number of geometrical objects or sub-shapes with a specified type:
+ * number of free faces,
+ * number of free wires,
+ * number of free edges,
+ * number of C0 surfaces,
+ * number of C0 curves,
+ * number of BSpline surfaces,… etc
+and selecting sub-shapes by various criteria.
+
+The corresponding flags should be set to True for storing a shape by a specified criteria:
+ * faces based on indirect surfaces - *safc.MofifyIndirectMode() = Standard_True*;
+ * faces based on offset surfaces - *safc.ModifyOffsetSurfaceMode() = Standard_True*;
+ * edges if their 3D curves are trimmed - *safc.ModifyTrimmed3dMode() = Standard_True*;
+ * edges if their 3D curves and 2D curves are offset curves - *safc.ModifyOffsetCurveMode() = Standard_True*;
+ * edges if their 2D curves are trimmed - *safc.ModifyTrimmed2dMode() = Standard_True*;
+
+Let us, for example, select faces based on offset surfaces.
+
+~~~~~
+ShapeAnalysis_ShapeContents safc;
+//set a corresponding flag for storing faces based on the offset surfaces
+safc.ModifyOffsetSurfaceMode() = Standard_True;
+safc.Perform(shape);
+//getting the number of offset surfaces in the shape
+Standard_Integer NbOffsetSurfaces = safc.NbOffsetSurf();
+//getting the sequence of faces based on offset surfaces.
+Handle(TopTools_HSequenceOfShape) seqFaces = safc.OffsetSurfaceSec();
+~~~~~
+
+@section occt_shg_4 Upgrading
+
+Upgrading tools are intended for adaptation of shapes for better use by Open CASCADE Technology or for customization to particular needs, i.e. for export to another system. This means that not only it corrects and upgrades but also changes the definition of a shape with regard to its geometry, size and other aspects. Convenient API allows you to create your own tools to perform specific upgrading. Additional tools for particular cases provide an ability to divide shapes and surfaces according to certain criteria.
+
+@subsection occt_shg_4_1 Tools for splitting a shape according to a specified criterion
+
+@subsubsection occt_shg_4_1_1 Overview
+
+These tools provide such modifications when one topological object can be divided or converted to several ones according to specified criteria. Besides, there are high level API tools for particular cases which:
+ * Convert the geometry of shapes up to a given continuity,
+ * split revolutions by U to segments less than the given value,
+ * convert to Bezier surfaces and Bezier curves,
+ * split closed faces,
+ * convert C0 BSpline curve to a sequence of C1 BSpline curves.
+All tools for particular cases are based on general tools for shape splitting but each of them has its own tools for splitting or converting geometry in accordance with the specified criteria.
+
+General tools for shape splitting are:
+ * tool for splitting the whole shape,
+ * tool for splitting a face,
+ * tool for splitting wires.
+Tools for shape splitting use tools for geometry splitting:
+ * tool for splitting surfaces,
+ * tool for splitting 3D curves,
+ * tool for splitting 2D curves.
+
+@subsubsection occt_shg_4_1_2 Using tools available for shape splitting.
+If it is necessary to split a shape by a specified continuity, split closed faces in the shape, split surfaces of revolution in the shape by angle or to convert all surfaces, all 3D curves, all 2D curves in the shape to Bezier, it is possible to use the existing/available tools.
+The usual way to use these tools exception for the tool of converting a C0 BSpline curve is the following:
+ * a tool is created and initialized by shape.
+ * work precision for splitting and the maximum allowed tolerance are set
+ * the value of splitting criterion Is set (if necessary)
+ * splitting is performed.
+ * splitting statuses are obtained.
+ * result is obtained
+ * the history of modification of the initial shape and its sub-shapes is output (this step is optional).
+
+Let us, for example, split all surfaces and all 3D and 2D curves having a continuity of less the C2.
+
+~~~~~
+//create a tool and initializes it by shape.
+ShapeUpgrade_ShapeDivideContinuity ShapeDivedeCont(initShape);
+
+//set the working 3D and 2D precision and the maximum allowed //tolerance
+ShapeDivideCont.SetTolerance(prec);
+ShapeDivideCont.SetTolerance2D(prec2d);
+ShapeDivideCont.SetMaxTolerance(maxTol);
+
+//set the values of criteria for surfaces, 3D curves and 2D curves.
+ShapeDivideCont.SetBoundaryCriterion(GeomAbs_C2);
+ShapeDivideCont.SetPCurveCriterion(GeomAbs_C2);
+ShapeDivideCont.SetSurfaceCriterion(GeomAbs_C2);
+
+//perform the splitting.
+ShapeDivideCont.Perform();
+
+//check the status and gets the result
+if(ShapeDivideCont.Status(ShapeExtend_DONE)
+ TopoDS_Shape result = ShapeDivideCont.GetResult();
+//get the history of modifications made to faces
+for(TopExp_Explorer aExp(initShape,TopAbs_FACE); aExp.More(0; aExp.Next()) {
+ TopoDS_Shape modifShape = ShapeDivideCont.GetContext()-
+Apply(aExp.Current());
+}
+~~~~~
+
+@subsubsection occt_shg_4_1_3 Creation of a new tool for splitting a shape.
+To create a new splitting tool it is necessary to create tools for geometry splitting according to a desirable criterion. These new tools should be inherited from basic tools for geometry splitting. Then these new tools should be set into corresponding tools for shape splitting.
+ * a new tool for surface splitting should be set into the tool for face splitting
+ * new tools for splitting of 3D and 2D curves should be set into the splitting tool for wires.
+In order to be able to change the value of criterion of shape splitting it is necessary to create a new tool for shape splitting that should be inherited from the general splitting tool for shapes.
+
+Let us split a shape according to a specified criterion.
+
+~~~~~
+//creation of new tools for geometry splitting by a specified //criterion.
+Handle(MyTools_SplitSurfaceTool) MySplitSurfaceTool =
+new MyTools_SplitSurfaceTool;
+Handle(MyTools_SplitCurve3DTool) MySplitCurve3Dtool =
+new MyTools_SplitCurve3DTool;
+Handle(MyTools_SplitCurve2DTool) MySplitCurve2Dtool =
+new MyTools_SplitCurve2DTool;
+
+//creation of a tool for splitting the shape and initialization of //that tool by shape.
+TopoDS_Shape initShape
+MyTools_ShapeDivideTool ShapeDivide (initShape);
+
+//setting of work precision for splitting and maximum allowed //tolerance.
+ShapeDivide.SetPrecision(prec);
+ShapeDivide.SetMaxTolerance(MaxTol);
+
+//setting of new splitting geometry tools in the shape splitting //tools
+Handle(ShapeUpgrade_FaceDivide) FaceDivide =
+ShapeDivide-GetSplitFaceTool();
+Handle(ShapeUpgrade_WireDivide) WireDivide =
+FaceDivide-GetWireDivideTool();
+FaceDivide-SetSplitSurfaceTool(MySplitSurfaceTool);
+WireDivide-SetSplitCurve3dTool(MySplitCurve3DTool);
+WireDivide-SetSplitCurve2dTool(MySplitCurve2DTool);
+
+//setting of the value criterion.
+ ShapeDivide.SetValCriterion(val);
+
+//shape splitting
+ShapeDivide.Perform();
+
+//getting the result
+TopoDS_Shape splitShape = ShapeDivide.GetResult();
+
+//getting the history of modifications of faces
+for(TopExp_Explorer aExp(initShape,TopAbs_FACE); aExp.More(0; aExp.Next()) {
+TopoDS_Shape modifShape = ShapeDivide.GetContext()-
+Apply(aExp.Current());
+}
+~~~~~
+
+@subsection occt_shg_4_2 General splitting tools.
+
+@subsubsection occt_shg_4_2_1 General tool for shape splitting
+
+Class *ShapeUpgrade_ShapeDivide* provides shape splitting and converting according to the given criteria. It performs these operations for each face with the given tool for face splitting (*ShapeUpgrade_FaceDivide* by default).
+This tool provides access to the tool for dividing faces with the help of the following methods:
+*SetSplitFaceTool*;
+*GetSpliFaceTool.*
+
+@subsubsection occt_shg_4_2_2 General tool for face splitting
+Class *ShapeUpgrade_FaceDivide* divides a Face (edges in the wires, by splitting 3D and 2D curves, as well as the face itself, by splitting the supporting surface) according to the given criteria.
+The area of the face intended for division is defined by 2D curves of the wires on the Face.
+All 2D curves are supposed to be defined (in the parametric space of the supporting surface).
+The result is available after the call to the *Perform* method. It is a Shell containing all resulting Faces. All modifications made during the splitting operation are recorded in the external context (*ShapeBuild_ReShape*).
+This tool provides access to the tool for wire division and surface splitting by means of methods:
+*SetWireDivideTool,*
+*GetWireDivideTool,*
+*SetSurfaceSplitTool,*
+*GetSurfaceSplitTool*.
+
+@subsubsection occt_shg_4_2_3 General tool for wire splitting
+Class *ShapeUpgrade_WireDivide* divides edges in the wire lying on the face or free wires or free edges with a given criterion. It splits the 3D curve and 2D curve(s) of the edge on the face. Other 2D curves, which may be associated with the edge, are simply copied. If the 3D curve is split then the 2D curve on the face is split as well, and vice-versa. The original shape is not modified. Modifications made are recorded in the context (*ShapeBuild_ReShape*).
+This tool provides access to the tool for dividing and splitting 3D and 2D curves by means of methods:
+*SetEdgeDivdeTool,*
+*GetEdgeDivideTool,*
+*SetSplitCurve3dTool,*
+*GetSplitCurve3dTool,*
+*SetSplitCurve2dTool,*
+*GetSplitCurve2dTool*
+and it also provides access to the mode for splitting edges by methods:
+*SetEdgeMode,*
+*GetEdgeMode*
+This mode sets whether only free edges, only shared edges or all edges are split.
+
+@subsubsection occt_shg_4_2_4 General tool for edge splitting
+Class *ShapeUpgrade_EdgeDivide* divides edges and their geometry according to the specified criteria. It is used in the wire-dividing tool.
+This tool provides access to the tool for dividing and splitting 3D and 2D curves by the following methods:
+*SetSplitCurve3dTool,*
+*GetSplitCurve3dTool,*
+*SetSplitCurve2dTool,*
+*GetSplitCurve2dTool*.
+
+@subsubsection occt_shg_4_2_5 General tools for geometry splitting
+There are three general tools for geometry splitting.
+ * General tool for surface splitting.(*ShapeUpgrade_SplitSurface*)
+ * General tool for splitting 3D curves.(*ShapeUpgrade_SplitCurve3d*)
+ * General tool for splitting 2D curves.(*ShapeUpgrade_SplitCurve2d*)
+All these tools are constructed the same way:
+They have methods:
+ * for initializing by geometry (method *Init*)
+ * for splitting (method *Perform*)
+ * for getting the status after splitting and the results:
+ + *Status – *for getting the result status*,*
+ + *ResSurface* - for splitting surfaces.
+ + *GetCurves* - for splitting 3D and 2D curves.
+During the process of splitting in the method *Perform* :
+ * splitting values in the parametric space are computed according to a specified criterion (method *Compute*)
+ * splitting is made in accordance with the values computed for splitting (method *Build*).
+
+To create new tools for geometry splitting it is enough to inherit a new tool from the general tool for splitting a corresponding type of geometry and to re-define the method for computation of splitting values according to the specified criterion in them. (method *Compute*).
+
+Header file for the tool for surface splitting by continuity:
+
+~~~~~
+class ShapeUpgrade_SplitSurfaceContinuity : public ShapeUpgrade_SplitSurface {
+Standard_EXPORT ShapeUpgrade_SplitSurfaceContinuity();
+
+//methods to set the criterion and the tolerance into the splitting //tool
+Standard_EXPORT void SetCriterion(const GeomAbs_Shape Criterion) ;
+Standard_EXPORT void SetTolerance(const Standard_Real Tol) ;
+
+//re-definition of method Compute
+Standard_EXPORT virtual void Compute(const Standard_Boolean Segment) ;
+Standard_EXPORT ~ShapeUpgrade_SplitSurfaceContinuity();
+private:
+GeomAbs_Shape myCriterion;
+Standard_Real myTolerance;
+Standard_Integer myCont;
+};
+~~~~~
+
+@subsection occt_shg_4_3 Specific splitting tools.
+
+@subsubsection occt_shg_4_3_1 Conversion of shape geometry to the target continuity
+Class *ShapeUpgrade_ShapeDivideContinuity* allows converting geometry with continuity less than the specified continuity to geometry with target continuity. If converting is not possible than geometrical object is split into several ones, which satisfy the given criteria. A topological object based on this geometry is replaced by several objects based on the new geometry.
+
+~~~~~
+ShapeUpgrade_ShapeDivideContinuity sdc (shape);
+sdc.SetTolerance (tol3d);
+sdc.SetTolerance3d (tol2d); // if known, else 1.e-09 is taken
+sdc.SetBoundaryCriterion (GeomAbs_C2); // for Curves 3D
+sdc.SetPCurveCriterion (GeomAbs_C2); // for Curves 2D
+sdc.SetSurfaceCriterion (GeomAbs_C2); // for Surfaces
+sdc.Perform ();
+TopoDS_Shape bshape = sdc.Result();
+.. to also get the correspondances before/after
+Handle(ShapeBuild_ReShape) ctx = sdc.Context();
+.. on a given shape
+if (ctx.IsRecorded (sh)) {
+ TopoDS_Shape newsh = ctx->Value (sh);
+// if there are several results, they are re-recorded inside a Compound
+// .. process as needed
+}
+~~~~~
+
+@subsubsection occt_shg_4_3_2 Splitting by angle
+Class *ShapeUpgrade_ShapeDivideAngle* allows splitting all surfaces of revolution, cylindrical, toroidal, conical, spherical surfaces in the given shape so that each resulting segment covers not more than the defined angle (in radians).
+
+@subsubsection occt_shg_4_3_3 Conversion of 2D, 3D curves and surfaces to Bezier
+
+Class *ShapeUpgrade_ShapeConvertToBezier* is an API tool for performing a conversion of 3D, 2D curves to Bezier curves and surfaces to Bezier based surfaces (Bezier surface, surface of revolution based on Bezier curve, offset surface based on any of previous types).
+This tool provides access to various flags for conversion of different types of curves and surfaces to Bezier by methods:
+For 3D curves:
+*Set3dConversion,*
+*Get3dConversion,*
+*Set3dLineConversion,*
+*Get3dLineConversion,*
+*Set3dCircleConversion,*
+*Get3dCircleConversion,*
+*Set3dConicConversion,*
+*Get3dConicConversion*
+For 2D curves:
+*Set2dConversion,*
+*Get2dConversion*
+For surfaces :
+*GetSurfaceConversion,*
+*SetPlaneMode,*
+*GetPlaneMode,*
+*SetRevolutionMode,*
+*GetRevolutionMode,*
+*SetExtrusionMode,*
+*GetExtrusionMode,*
+*SetBSplineMode,*
+*GetBSplineMode,*
+
+Let us attempt to produce a conversion of planes to Bezier surfaces.
+~~~~~
+//Creation and initialization of a tool.
+ShapeUpgrade_ShapeConvertToBezier SCB (Shape);
+//setting tolerances
+…..
+//setting mode for conversion of planes
+SCB.SetSurfaceConversion (Standard_True);
+SCB.SetPlaneMode(Standard_True);
+SCB.Perform();
+If(SCB.Status(ShapeExtend_DONE)
+ TopoDS_Shape result = SCB.GetResult();
+~~~~~
+
+@subsubsection occt_shg_4_3_4 Tool for splitting closed faces
+
+Class *ShapeUpgrade_ShapeDivideClosed* provides splitting of closed faces in the shape to a defined number of components by the U and V parameters. It topologically and (partially) geometrically processes closed faces and performs splitting with the help of class *ShapeUpgrade_ClosedFaceDivide*.
+
+~~~~~
+TopoDS_Shape aShape = …;
+ShapeUpgrade_ShapeDivideClosed tool (aShape );
+Standard_Real closeTol = …;
+tool.SetPrecision(closeTol);
+Standard_Real maxTol = …;
+tool.SetMaxTolerance(maxTol);
+Standard_Integer NbSplitPoints = …;
+tool.SetNbSplitPoints(num);
+if ( ! tool.Perform() && tool.Status (ShapeExtend_FAIL) ) {
+ cout;Splitting of closed faces failed;endl;
+ . . .
+}
+TopoDS_Shape aResult = tool.Result();
+~~~~~
+
+@subsubsection occt_shg_4_3_5 Tool for splitting a C0 BSpline 2D or 3D curve to a sequence C1 BSpline curves
+
+The API methods for this tool is a package of methods *ShapeUpgrade::C0BSplineToSequenceOfC1BsplineCurve*, which converts a C0 B-Spline curve into a sequence of C1 B-Spline curves. This method splits a B-Spline at the knots with multiplicities equal to degree, it does not use any tolerance and therefore does not change the geometry of the B-Spline. The method returns True if C0 B-Spline was successfully split, otherwise returns False (if BS is C1 B-Spline).
+
+@subsubsection occt_shg_4_3_6 Tool for splitting faces
+
+*ShapeUpgrade_ShapeDivideArea* can work with compounds, solids, shells and faces.
+During the work this tool examines each face of a specified shape and if the face area exceeds the specified maximal area, this face is divided. Face splitting is performed in the parametric space of this face. The values of splitting in U and V directions are calculated with the account of translation of the bounding box form parametric space to 3D space. Such calculations are necessary to avoid creation of strip faces. In the process of splitting the holes on the initial face are taken into account. After the splitting all new faces are checked by area again and the splitting procedure is repeated for the faces whose area still exceeds the max allowed area. Sharing between faces in the shape is preserved and the resulting shape is of the same type as the source shape.
+An example of using this tool is presented in the figures below:
+
+
+
+
+
+
+*ShapeUpgrade_ShapeDivideArea* is inherited from the base class *ShapeUpgrade_ShapeDivide* and should be used in the following way:
+* This class should be initialized on a shape with the help of the constructor or method *Init()* from the base class.
+* The maximal allowed area should be specified by the method *MaxArea()*.
+* To produce a splitting use method Perform from the base class.
+* The result shape can be obtained with the help the method *Result()*.
+
+~~~~~
+ShapeUpgrade_ShapeDivideArea tool (inputShape);
+tool.MaxArea() = aMaxArea;
+tool.Perform();
+if(tool.Status(ShapeExtend_DONE)) {
+ TopoDS_Shape ResultShape = tool.Result();
+ ShapeFix::SameParameter ( ResultShape, Standard_False );
+}
+~~~~~
+
+**Note** that the use of method *ShapeFix::SameParameter* is necessary, otherwise the parameter edges obtained as a result of splitting can be different.
+
+Additional methods
+------------------
+* Class *ShapeUpgrade_FaceDivideArea* inherited from *ShapeUpgrade_FaceDivide* is intended for splitting a face by the maximal area criterion.
+* Class *ShapeUpgrade_SplitSurfaceArea* inherited from *ShapeUpgrade_SplitSurface* calculates the parameters of face splitting in the parametric space.
+
+
+@subsection occt_shg_4_4 Customization of shapes
+
+Customization tools are intended for adaptation of shape geometry in compliance with the customer needs. They modify a geometrical object to another one in the shape.
+
+To implement the necessary shape modification it is enough to initialize the appropriate tool by the shape and desirable parameters and to get the resulting shape. For example for conversion of indirect surfaces in the shape do the following:
+
+~~~~~
+TopoDS_Shape initialShape ..
+TopoDS_Shape resultShape = ShapeCustom::DirectFaces(initialShape);
+~~~~~
+
+@subsubsection occt_shg_4_2_1 Conversion of indirect surfaces.
+
+~~~~~
+ShapeCustom::DirectFaces
+ static TopoDS_Shape DirectFaces(const TopoDS_Shape& S);
+~~~~~
+
+This method provides conversion of indirect elementary surfaces (elementary surfaces with left-handed coordinate systems) in the shape into direct ones. New 2d curves (recomputed for converted surfaces) are added to the same edges being shared by both the resulting shape and the original shape S.
+
+@subsubsection occt_shg_4_2_2 Shape Scaling
+
+~~~~~
+ShapeCustom::ScaleShape
+ TopoDS_Shape ShapeCustom::ScaleShape(const TopoDS_Shape& S,
+ const Standard_Real scale);
+~~~~~
+
+This method returns a new shape, which is a scaled original shape with a coefficient equal to the specified value of scale. It uses the tool *ShapeCustom_TrsfModification*.
+
+@subsubsection occt_shg_4_2_3 Conversion of curves and surfaces to BSpline
+*ShapeCustom_BSplineRestriction.* allows approximation of surfaces, curves and 2D curves with a specified degree, max number of segments, 2d tolerance and 3d tolerance. If the approximation result cannot be achieved with the specified continuity, the latter can be reduced.
+
+The method with all parameters looks as follows:
+~~~~~
+ShapeCustom::BsplineRestriction
+ TopoDS_Shape ShapeCustom::BSplineRestriction (const TopoDS_Shape& S,
+ const Standard_Real Tol3d, const Standard_Real Tol2d,
+ const Standard_Integer MaxDegree,
+ const Standard_Integer MaxNbSegment,
+ const GeomAbs_Shape Continuity3d,
+ const GeomAbs_Shape Continuity2d,
+ const Standard_Boolean Degree,
+ const Standard_Boolean Rational,
+ const Handle(ShapeCustom_RestrictionParameters)& aParameters)
+~~~~~
+
+Returns a new shape with all surfaces, curves and 2D curves which type is BSpline/Bezier or based on the two latter, converted with Degree less than MaxDegree or with a number of spans less then *NbMaxSegment* depending on priority parameter Degree. If this parameter is equal to True then Degree will be increased to the value *GmaxDegree*, otherwise *NbMaxSegments* will be increased to the value *GmaxSegments*. *GmaxDegree* and *GMaxSegments* are the maximum possible degree and the number of spans correspondingly. These values will be used in those cases when an approximation with specified parameters is impossible and one of *GmaxDegree* or *GMaxSegments* is selected depending on priority.
+Note that if approximation is impossible with *GMaxDegree*, even then the number of spans can exceed the specified *GMaxSegment*. Rational specifies whether Rational BSpline/Bezier should be converted into polynomial B-Spline.
+Also note that the continuity of surfaces in the resulting shape can be less than the given value.
+
+Flags
+-----
+To convert other types of curves and surfaces to BSpline with required parameters it is necessary to use flags from class ShapeCustom_RestrictionParameters, which is just a container of flags.
+The following flags define whether a specified-type geometry has been converted to BSpline with the required parameters:
+*ConvertPlane, *
+*ConvertBezierSurf, *
+*ConvertRevolutionSurf*
+*ConvertExtrusionSurf,.*
+*ConvertOffsetSurf,*
+*ConvertCurve3d,*
+*ConvertOffsetCurv3d,*
+*ConvertCurve2d,*
+*ConvertOffsetCurv2d,*
+*SegmentSurfaceMode*
+
+Parameters *ConvertCurve3d* and *ConvertCurve2d* are responsible for conversion of all types of 3D and 2D curves.
+Parameters *ConvertOffsetCurv3d* and *ConvertOffsetCurv2d* are responsible for conversion of offset 3D and 2D curves.
+Parameter *SegmentSurfaceMode* defines whether the surface would be approximated within the boundaries of the face lying on this surface.
+
+@subsubsection occt_shg_4_2_4 Conversion of elementary surfaces into surfaces of revolution
+
+~~~~~
+ShapeCustom::ConvertToRevolution()
+ TopoDS_Shape ShapeCustom::ConvertToRevolution(const TopoDS_Shape& S) ;
+~~~~~
+
+This method returns a new shape with all elementary periodic surfaces converted to *Geom_SurfaceOfRevolution*. It uses the tool *ShapeCustom_ConvertToRevolution.*
+
+@subsubsection occt_shg_4_2_5 Conversion of elementary surfaces into Bspline surfaces
+
+~~~~~
+ShapeCustom::ConvertToBSpline()
+ TopoDS_Shape ShapeCustom::ConvertToBSpline( const TopoDS_Shape& S,
+ const Standard_Boolean extrMode,
+ const Standard_Boolean revolMode,
+ const Standard_Boolean offsetMode);
+This method returns a new shape with all surfaces of linear extrusion, revolution and offset surfaces converted according to flags to Geom_BSplineSurface (with the same parameterization). It uses the tool *ShapeCustom_ConvertToBSpline.*
+
+@subsubsection occt_shg_4_2_6 Getting the history of modification of sub-shapes.
+If, in addition to the resulting shape, you want to get the history of modification of sub-shapes you should not use the package methods described above and should use your own code instead:
+1. Create a tool that is responsible for the necessary modification.
+2. Create the tool BRepTools_Modifier that performs a specified modification in the shape.
+3. To get the history and to keep the assembly structure use the method *ShapeCustom::ApplyModifier*.
+
+
+The general calling syntax for scaling is
+~~~~~
+TopoDS_Shape scaled_shape = ShapeCustom::ScaleShape(shape, scale);
+~~~~~
+
+Note that scale is a real value. You can refine your mapping process by using additional calls to follow shape mapping subshape by subshape. The following code along with pertinent includes can be used:
+
+~~~~~
+p_Trsf T;
+Standard_Real scale = 100; // for example!
+T.SetScale (gp_Pnt (0, 0, 0), scale);
+Handle(ShapeCustom_TrsfModification) TM = new
+ShapeCustom_TrsfModification(T);
+TopTools_DataMapOfShapeShape context;
+BRepTools_Modifier MD;
+TopoDS_Shape res = ShapeCustom::ApplyModifier (
+Shape, TM, context,MD );
+~~~~~
+
+The map, called context in our example, contains the history.
+Substitutions are made one by one and all shapes are transformed.
+To determine what happens to a particular subshape, it is possible to use:
+
+~~~~~
+TopoDS_Shape oneres = context.Find (oneshape);
+//In case there is a doubt, you can also add:
+if (context.IsBound(oneshape)) oneres = context.Find(oneshape);
+//You can also sweep the entire data map by using:
+TopTools_DataMapIteratorOfDataMapOfShapeShape
+//To do this, enter:
+for(TopTools_DataMapIteratorOfDataMapOfShapeShape
+iter(context);iter(more ();iter.next ()) {
+ TopoDs_Shape oneshape = iter.key ();
+ TopoDs_Shape oneres = iter.value ();
+}
+~~~~~
+
+
+@subsubsection occt_shg_4_2_7 Remove internal wires
+
+*ShapeUpgrade_RemoveInternalWires* tool removes internal wires with contour area less than the specified minimal area. It can work with compounds, solids, shells and faces.
+If the flag *RemoveFaceMode* is set to TRUE, separate faces or a group of faces with outer wires, which consist only of edges that belong to the removed internal wires, are removed (seam edges are not taken into account). Such faces can be removed only for a sewed shape.
+Internal wires can be removed by the methods *Perform*. Both methods *Perform* can not be carried out if the class has not been initialized by the shape. In such case the status of *Perform* is set to FAIL .
+The method *Perform* without arguments removes from all faces in the specified shape internal wires whose area is less than the minimal area.
+The other method *Perform* has a sequence of shapes as an argument. This sequence can contain faces or wires.
+If the sequence of shapes contains wires, only the internal wires are removed.
+If the sequence of shapes contains faces, only the internal wires from these faces are removed.
+* The status of the performed operation can be obtained using method *Status()*;
+* The resulting shape can be obtained using method *GetResult()*.
+
+An example of using this tool is presented in the figures below:
+
+
+
+
+After the processing three internal wires with contour area less than the specified minimal area have been removed. One internal face has been removed. The outer wire of this face consists of the edges belonging to the removed internal wires and a seam edge.
+Two other internal faces have not been removed because their outer wires consist not only of edges belonging to the removed wires.
+
+
+
+
+After the processing six internal wires with contour area less than the specified minimal area have been removed. Six internal faces have been removed. These faces can be united into groups of faces. Each group of faces has an outer wire consisting only of edges belonging to the removed internal wires. Such groups of faces are also removed.
+
+The example of method application is also given below:
+
+~~~~~
+//Initialisation of the class by shape.
+Handle(ShapeUpgrade_RemoveInternalWires) aTool = new ShapeUpgrade_RemoveInternalWires(inputShape);
+//setting parameters
+aTool-MinArea() = aMinArea;
+aTool-RemoveFaceMode() = aModeRemoveFaces;
+
+//when method Perform is carried out on separate shapes.
+aTool-Perform(aSeqShapes);
+
+//when method Perform is carried out on whole shape.
+aTool-Perform();
+//check status set after method Perform
+if(aTool-Status(ShapeExtend_FAIL) {
+ cout*Operation failed* ;;\n;;
+ return;
+}
+
+if(aTool-Status(ShapeExtend_DONE1)) {
+ const TopTools_SequenceOfShape& aRemovedWires =aTool-RemovedWires();
+ coutaRemovedWires.Length(); internal wires were removed;;\n;;
+
+ }
+
+ if(aTool-Status(ShapeExtend_DONE2)) {
+ const TopTools_SequenceOfShape& aRemovedFaces =aTool-RemovedFaces();
+ coutaRemovedFaces.Length(); small faces were removed;;\n;;
+
+ }
+ //getting result shape
+ TopoDS_Shape res = aTool-GetResult();
+~~~~~
+
+@subsubsection occt_shg_4_2_8 Conversion of surfaces
+
+Class ShapeCustom_Surface allows:
+ * converting BSpline and Bezier surfaces to the analytical form (using method *ConvertToAnalytical())*
+ * converting closed B-Spline surfaces to periodic ones.(using method *ConvertToPeriodic*)
+
+To convert surfaces to analytical form this class analyzes the form and the closure of the source surface and defines whether it can be approximated by analytical surface of one of the following types:
+* *Geom_Plane,*
+* *Geom_SphericalSurface,*
+* *Geom_CylindricalSurface,*
+* *Geom_ConicalSurface,*
+* *Geom_ToroidalSurface*.
+
+The conversion is done only if the new (analytical) surface does not deviate from the source one more than by the given precision.
+
+~~~~~
+Handle(Geom_Surface) initSurf;
+ShapeCustom_Surface ConvSurf(initSurf);
+//conversion to analytical form
+Handle(Geom_Surface) newSurf = ConvSurf.ConvertToAnalytical(allowedtol,Standard_False);
+//or conversion to a periodic surface
+Handle(Geom_Surface) newSurf = ConvSurf.ConvertToPeriodic(Standard_False);
+//getting the maximum deviation of the new surface from the initial surface
+Standard_Real maxdist = ConvSurf.Gap();
+~~~~~
+
+@section occt_shg_5_ Auxiliary tools for repairing, analysis and upgrading
+.
+@subsection occt_shg_5_1 Tool for rebuilding shapes
+
+*ShapeBuild_ReShape* rebuilds a shape by making pre-defined substitutions on some of its components. During the first phase, it records requests to replace or remove some individual shapes. For each shape, the last given request is recorded. Requests may be applied as *Oriented* (i.e. only to an item with the same orientation) or not (the orientation of the replacing shape corresponds to that of the original one). Then these requests may be applied to any shape, which may contain one or more of these individual shapes.
+This tool has a flag for taking the location of shapes into account (for keeping the structure of assemblies) (*ModeConsiderLocation*). If this mode is equal to Standard_True, the shared shapes with locations will be kept. If this mode is equal to Standard_False, some different shapes will be produced from one shape with different locations after rebuilding. By default, this mode is equal to Standard_False.
+To use this tool for the reconstruction of shapes it is necessary to take the following steps:
+1. Create this tool and use method *Apply()* for its initialization by the initial shape. Parameter *until* sets the level of shape type and requests are taken into account up to this level only. Sub-shapes of the type standing beyond the *line* set by parameter until will not be rebuilt and no further exploration will be done
+2. Replace or remove sub-shapes of the initial shape. Each sub-shape can be replaced by a shape of the same type or by shape containing shapes of that type only (for example, *TopoDS_Edge* can be replaced by *TopoDS_Edge, TopoDS_Wire* or *TopoDS_Compound* containing *TopoDS_Edges*). If an incompatible shape type is encountered, it is ignored and flag FAIL1 is set in Status.
+For a sub-shape it is recommended to use method *Apply* before methods *Replace* and *Remove*, because the sub-shape has already been changed for the moment by its previous modifications or modification of its sub-shape (for example *TopoDS_Edge* can be changed by a modification of its *TopoDS_Vertex*, etc.).
+3. Use method *Apply* for the initial shape again to get the resulting shape after all modifications have been made.
+4. Use method *Apply* to obtain the history of sub-shape modification.
+
+**Note** that in fact class *ShapeBuild_ReShape* is an alias for class *BRepTools_ReShape*. They differ only in queries of statuses in the *ShapeBuild_ReShape* class.
+
+Let us use the tool to get the result shape after modification of sub-shapes of the initial shape:
+
+~~~~~
+TopoDS_Shape initialShape…
+//creation of a rebuilding tool
+Handle(ShapeBuild_ReShape) Context = new ShapeBuild_ReShape.
+
+//next step is optional. It can be used for keeping
+//the assembly structure.
+Context- ModeConsiderLocation = Standard_True;
+
+//initialization of this tool by the initial shape
+Context-Apply(initialShape);
+…
+//getting the intermediate result for replacing subshape1 with
+//the modified subshape1.
+TopoDS_Shape tempshape1 = Context-Apply(subshape1);
+
+//replacing the intermediate shape obtained from subshape1 with the //newsubshape1.
+Context-Replace(tempsubshape1,newsubshape1);
+…
+//for removing the subshape
+TopoDS_Shape tempshape2 = Context-Apply(subshape2);
+Context-Remove(tempsubshape2);
+
+//getting the result and the history of modification
+TopoDS_Shape resultShape = Context-Apply(initialShape);
+
+//getting the resulting subshape from the subshape1 of the initial //shape.
+TopoDS_Shape result_subshape1 = Context-Apply(subshape1);
+~~~~~
+
+@subsection occt_shg_5_2 Status definition
+
+*ShapExtend_Status* is used to report the status after executing some methods that can either fail, do something, or do nothing. The status is a set of flags DONEi, FAILi, any combination of them can be set at the same time. For exploring the status, enumeration is used.
+The values have the following meaning:
+|*OK,* | Nothing is done, everything OK |
+|*DONE1,* | Something was done, case 1 |
+|*DONE8*, | Something was done, case 8 |
+|*DONE*, | Something was done (any of DONE#) |
+|*FAIL1*, | The method failed, case 1 |
+|*FAIL8*, | The method failed, case 8 |
+|*FAIL* | The method failed (any of FAIL# occurred) |
+
+
+@subsection occt_shg_5_3 Tool representing a wire
+Class *ShapeExtend_WireData* provides a data structure necessary to work with the wire as with an ordered list of edges, and that is required for many algorithms. The advantage of this class is that it allows to work with incorrect wires.
+The object of the class *ShapeExtend_WireData* can be initialized by *TopoDS_Wire* and converted back to *TopoDS_Wire*.
+An edge in the wire is defined by its rank number. Operations of accessing, adding and removing an edge at/to the given rank number are provided. Operations of circular permutation and reversing (both orientations of all edges and the order of edges) are provided on the whole wire as well.
+This class also provides a method to check if the edge in the wire is a seam (if the wire lies on a face).
+Let us remove edges from the wire and define whether it is seam edge
+
+~~~~~
+TopoDS_Wire ini = ..
+Handle(ShapeExtend_Wire) asewd = new ShapeExtend_Wire(initwire);
+//Removing edge Edge1 from the wire.
+
+Standard_Integer index_edge1 = asewd->Index(Edge1);
+asewd.Remove(index_edge1);
+//Definition of whether Edge2 is a seam edge
+Standard_Integer index_edge2 = asewd->Index(Edge2);
+asewd->IsSeam(index_edge2);
+~~~~~
+
+
+@subsection occt_shg_5_4 Tool for exploring shapes
+Class *ShapeExtend_Explorer* is intended to explore shapes and convert different representations (list, sequence, compound) of complex shapes. It provides tools for:
+ * obtaining the type of the shapes in the context of *TopoDS_Compound*,
+ * exploring shapes in the context of *TopoDS_Compound*,
+ * converting different representations of shapes (list, sequence, compound).
+
+@subsection occt_shg_5_5 Tool for attaching messages to objects
+Class *ShapeExtend_MsgRegistrator* attaches messages to objects (generic Transient or shape). The objects of this class are transmitted to the Shape Healing algorithms so that they could collect messages occurred during shape processing. Messages are added to the Maps (stored as a field) that can be used, for instance, by Data Exchange processors to attach those messages to initial file entities.
+
+Let us send and get a message attached to object:
+
+~~~~~
+Handle(ShapeExtend_MsgRegistrator) MessageReg = new ShapeExtend_MsgRegistrator;
+//attaches messages to an object (shape or entity)
+Message_Msg msg..
+TopoDS_Shape Shape1…
+MessageReg-Send(Shape1,msg,Message_WARNING);
+Handle(Standard_Transient) ent ..
+MessageReg-Send(ent,msg,Message_WARNING);
+//gets messages attached to shape
+const ShapeExtend_DataMapOfShapeListOfMsg& msgmap =
+MessageReg-MapShape();
+if (msgmap.IsBound (Shape1)) {
+ const Message_ListOfMsg &msglist = msgmap.Find (Shape1);
+ for (Message_ListIteratorOfListOfMsg iter (msglist);
+iter.More(); iter.Next()) {
+ Message_Msg msg = iter.Value();
+ }
+ }
+~~~~~
+
+@subsection occt_shg_5_6 Tools for performance measurement
+
+Classes *MoniTool_Timer* and *MoniTool_TimerSentry* are used for measuring the performance of a current operation or any part of code, and provide the necessary API. Timers are used for debugging and performance optimizing purposes.
+
+Let us try to use timers in *XSDRAWIGES.cxx* and *IGESBRep_Reader.cxx* to analyse the performance of command *igesbrep*:
+
+~~~~~
+XSDRAWIGES.cxx
+ ...
+ #include <MoniTool_Timer.hxx>
+ #include <MoniTool_TimerSentry.hxx>
+ ...
+ MoniTool_Timer::ClearTimers();
+ ...
+ MoniTool_TimerSentry MTS("IGES_LoadFile");
+ Standard_Integer status = Reader.LoadFile(fnom.ToCString());
+ MTS.Stop();
+ ...
+ MoniTool_Timer::DumpTimers(cout);
+ return;
+
+
+IGESBRep_Reader.cxx
+ ...
+ #include <MoniTool_TimerSentry.hxx>
+ ...
+ Standard_Integer nb = theModel->NbEntities();
+ ...
+ for (Standard_Integer i=1; i<=nb; i++) {
+ MoniTool_TimerSentry MTS("IGESToBRep_Transfer");
+ ...
+ try {
+ TP.Transfer(ent);
+ shape = TransferBRep::ShapeResult (theProc,ent);
+ }
+ ...
+ }
+~~~~~
+
+The result of *DumpTimer()* after translation of a file is as follows:
+
+| TIMER: *IGES_LoadFile* | Elapsed: 1.0 sec CPU User: 0.9 sec CPU Sys: 0.0 sec hits: 1 |
+| TIMER: IGESToBRep_Transfer | Elapsed: 14.5 sec CPU User: 4.4 sec CPU Sys: 0.1 sec hits: 1311 |
+
+
+@section occt_shg_6 Shape Processing
+
+@subsection occt_shg_6_1 Usage Workflow
+
+The Shape Processing module allows defining and applying the general Shape Processing as a customizable sequence of Shape Healing operators. The customization is implemented via the user-editable resource file, which defines the sequence of operators to be executed and their parameters.
+The Shape Processing functionality is implemented with the help of the *XSAlgo* interface. The main function *XSAlgo_AlgoContainer::ProcessShape()* does shape processing with specified tolerances and returns the resulting shape and associated information in the form of *Transient*.
+
+This function is used in the following way:
+
+~~~~~
+TopoDS_Shape aShape = …;
+Standard_Real Prec = …,
+Standard_Real MaxTol = …;
+TopoDS_Shape aResult;
+Handle(Standard_Transient) info;
+TopoDS_Shape aResult = XSAlgo::AlgoContainer()-ProcessShape(aShape,
+ Prec, MaxTol., *Name of ResourceFile*, *NameSequence*, info );
+~~~~~
+
+Let us create a custom sequence of operations:
+
+1. Create a resource file with the name ResourceFile, which includes the following string:
+~~~~~
+NameSequence.exec.op: MyOper
+~~~~~
+where *MyOper* is the name of operation.
+
+2. Input a custom parameter for this operation in the resource file, for example:
+~~~~~
+NameSequence.MyOper.Tolerance: 0.01
+~~~~~
+
+where Tolerance is the name of the parameter and 0.01 is its value.
+
+3. Add the following string into *void ShapeProcess_OperLibrary::Init()*:
+
+~~~~~
+ShapeProcess::RegisterOperator(;MyOper;,
+new ShapeProcess_UOperator(myfunction));
+~~~~~
+where *myfunction* is a function which implements the operation.
+
+4. Create this function in *ShapeProcess_OperLibrary* as follows:
+~~~~~
+static Standard_Boolean myfunction (const
+ Handle(ShapeProcess_Context)& context)
+{
+ Handle(ShapeProcess_ShapeContext) ctx =
+ Handle(ShapeProcess_ShapeContext)::DownCast(context);
+ if(ctx.IsNull()) return Standard_False;
+ TopoDS_Shape aShape = ctx->Result();
+ //receive our parameter:
+ Standard_Real toler;
+ ctx->GetReal(;Tolerance;, toler);
+~~~~~
+
+Now it is possible to make the necessary operations with *aShape* using the received value of parameter *Tolerance* from the resource file.
+
+~~~~~
+ return Standard_True;
+}
+~~~~~
+
+It is possible to define some operations (with their parameters) *MyOper1, MyOper2, MyOper3*, etc. and describe the corresponding functions in *ShapeProcess_OperLibrary*. After that it will be possible to perform the required sequence using the specified name of operations and values of parameters in the resource file.
+
+For example: input of the following string:
+~~~~~
+NameSequence.exec.op: MyOper1,MyOper3
+~~~~~
+means that the corresponding functions from *ShapeProcess_OperLibrary* will be performed with the original shape *(aShape)* using parameters defined for *MyOper1* and *MyOper3* in the resource file.
+It is necessary to note that these operations will be performed step by step and the result obtained after performing the first operation will be used as the initial shape for the second operation.
+
+@subsection occt_shg_6_2 Operators
+**DirectFaces** sets all faces based on indirect surfaces, defined with left-handed coordinate systems as direct faces. This concerns surfaces defined by Axis Placement (Cylinders, etc). Such Axis Placement may be indirect, which is allowed in Cascade, but not allowed in some other systems. This operator reverses indirect placements and recomputes PCurves accordingly.
+**SameParameter** is required after calling some other operators, according to the computations they do. Its call is explicit, so each call can be removed according to the operators, which are either called or not afterwards. This mainly concerns splitting operators that can split edges.
+The operator applies the computation *SameParameter* which ensures that various representations of each edge (its 3d curve, the pcurve on each of the faces on which it lies) give the same 3D point for the same parameter, within a given tolerance. For each edge coded as ;same parameter;, deviation of curve representation is computed and if the edge tolerance is less than that deviation, the tolerance is increased so that it satisfies the deviation. No geometry modification, only an increase of tolerance is possible. For each edge coded as ;not same parameter; the deviation is computed like in the first case. Then an attempt is made to achieve the edge equality to ;same parameter; by means of modification of 2d curves. If the deviation of this modified edge is less than the original deviation then this edge is returned, otherwise the original edge (with non-modified 2d curves) is returned with an increased (if necessary) tolerance. Computation is done by call to the standard algorithm *BRepLib::SameParameter*.
+This operator can be called with the following parameters:
+ * *Boolean : Force* (optional) - if True, encodes all edges as *not same parameter* then runs the computation. Else, the computation is done only for those edges already coded as *not same parameter*.
+ * *Real : Tolerance3d* (optional) - if not defined, the local tolerance of each edge is taken for its own computation. Else, this parameter gives the global tolerance for the whole shape.
+**BSplineRestriction** is used for conversion of surfaces, curves 2d curves to BSpline surfaces with a specified degree and a specified number of spans.
+This operator performs approximations on surfaces, curves and 2d curves with a specified degree, max number of segments, 2d tolerance, 3d tolerance. The specified continuity can be reduced if the approximation with a specified continuity was not done successfully.
+This operator can be called with the following parameters:
+* *Boolean : SurfaceMode* allows considering the surfaces;
+* *Boolean : Curve3dMode* allows considering the 3d curves;
+* *Boolean : Curve2dMode* allows considering the 2d curves;
+* *Real : Tolerance3d* defines 3d tolerance to be used in computation;
+* *Real : Tolerance2d* defines 2d tolerance to be used when computing 2d curves;
+* *GeomAbs_Shape (C0 G1 C1 G2 C2 CN) : Continuity3d* is the continuity required in 2d;
+* *GeomAbs_Shape (C0 G1 C1 G2 C2 CN) : Continuity2d* is the continuity required in 3d;
+* *Integer : RequiredDegree* gives the required degree;
+* *Integer : RequiredNbSegments* gives the required number of segments;
+* *Boolean : PreferDegree* if true, *RequiredDegree* has a priority, else *RequiredNbSegments* has a priority;
+* *Boolean : RationalToPolynomial* serves for conversion of BSplines to polynomial form;
+* *Integer : MaxDegree* gives the maximum allowed Degree, if *RequiredDegree* cannot be reached;
+* *Integer : MaxNbSegments* gives the maximum allowed NbSegments, if *RequiredNbSegments* cannot be reached;
+
+The following flags allow to manage the conversion of special types of curves or surfaces, in addition to BSpline. They are controlled by *SurfaceMode, Curve3dMode* or *Curve2dMode* respectively. By default, only BSplines and Bezier Geometries are considered.
+*Boolean : OffsetSurfaceMode*
+*Boolean : LinearExtrusionMode*
+*Boolean : RevolutionMode*
+*Boolean : OffsetCurve3dMode*
+*Boolean : OffsetCurve2dMode*
+*Boolean : PlaneMode*
+*Boolean : BezierMode*
+*Boolean : ConvCurve3dMode*
+*Boolean : ConvCurve2dMode*
+For each of the Mode parameters listed above, if it is True, the specified geometry is converted to BSpline, otherwise only its basic geometry is checked and converted (if necessary) keeping the original type of geometry (revolution, offset, etc.).
+*Boolean :SegmentSurfaceMode* has effect only for Bsplines and Bezier surfaces. When False a surface will be replaced by a Trimmed Surface, else new geometry will be created by splitting the original Bspline or Bezier surface.
+
+**ElementaryToRevolution** converts elementary periodic surfaces to SurfaceOfRevolution.
+
+**SplitAngle** splits surfaces of revolution, cylindrical, toroidal, conical, spherical surfaces in the given shape so that each resulting segment covers not more than the defined number of degrees.
+This operator can be called with the following parameters:
+* *Real : Angle* - the maximum allowed angle for resulting faces;
+* *Real : MaxTolerance* - the maximum tolerance used in computations.
+
+**SurfaceToBSpline** converts some specific types of Surfaces, to BSpline (according to parameters).
+This operator can be called with the following parameters:
+* *Boolean : LinearExtrusionMode* allows converting surfaces of Linear Extrusion;
+* *Boolean : RevolutionMode* allows converting surfaces of Revolution;
+* *Boolean : OffsetMode* allows converting Offset Surfaces
+
+**ToBezier** is used for data supported as Bezier only and converts various types of geometries to Bezier
+This operator can be called with the following parameters used in computation of conversion :
+* *Boolean : SurfaceMode*
+* *Boolean : Curve3dMode*
+* *Boolean : Curve2dMode*
+* *Real : MaxTolerance*
+*Boolean : SegmentSurfaceMode* (default is True) has effect only for Bsplines and Bezier surfaces. When False a surface will be replaced by a Trimmed Surface, else new geometry will be created by splitting the original Bspline or Bezier surface.
+
+The following parameters are controlled by *SurfaceMode, Curve3dMode* or *Curve2dMode* (according to the case):
+* *Boolean : Line3dMode*
+* *Boolean : Circle3dMode*
+* *Boolean : Conic3dMode*
+* *Boolean : PlaneMode*
+* *Boolean : RevolutionMode*
+* *Boolean : ExtrusionMode*
+* *Boolean : BSplineMode*
+
+**SplitContinuity** splits a shape in order to have each geometry (surface, curve 3d, curve 2d) correspond the given criterion of continuity.
+This operator can be called with the following parameters:
+* *Real : Tolerance3d*
+* *Integer (GeomAbs_Shape ) : CurveContinuity*
+* *Integer (GeomAbs_Shape ) : SurfaceContinuity*
+* *Real : MaxTolerance*
+
+
+Because of algorithmic limitations in the operator *BSplineRestriction* (in some particular cases, this operator can produce unexpected C0 geometry), if *SplitContinuity* is called, it is recommended to call it after *BSplineRestriction*.
+Continuity Values will be set as *GeomAbs_Shape* (i.e. C0 G1 C1 G2 C2 CN) besides direct integer values (resp. 0 1 2 3 4 5).
+
+**SplitClosedFaces** splits faces, which are closed even if they are not revolutionary or cylindrical, conical, spherical, toroidal. This corresponds to BSpline or Bezier surfaces which can be closed (whether periodic or not), hence they have a seam edge. As a result, no more seam edges remain. The number of points allows to control the minimum count of faces to be produced per input closed face.
+This operator can be called with the following parameters:
+* *Integer : NbSplitPoints* gives the number of points to use for splitting (the number of intervals produced is *NbSplitPoints+1*);
+* *Real : CloseTolerance* tolerance used to determine if a face is closed;
+* *Real : MaxTolerance* is used in the computation of splitting.
+
+**FixGaps** must be called when **FixFaceSize** and/or **DropSmallEdges** are called. Using Surface Healing may require an additional call to **BSplineRestriction** to ensure that modified geometries meet the requirements for BSpline.
+This operators repairs geometries which contain gaps between edges in wires (always performed) or gaps on faces, controlled by parameter *SurfaceMode*, Gaps on Faces are fixed by using algorithms of Surface Healing
+This operator can be called with the following parameters:
+* *Real : Tolerance3d* sets the tolerance to reach in 3d. If a gap is less than this value, it is not fixed.
+* *Boolean : SurfaceMode* sets the mode of fixing gaps between edges and faces (yes/no) ;
+* *Integer : SurfaceAddSpans* sets the number of spans to add to the surface in order to fix gaps ;
+* *GeomAbs_Shape (C0 G1 C1 G2 C2 CN) : SurfaceContinuity* sets the minimal continuity of a resulting surface ;
+* *Integer : NbIterations* sets the number of iterations
+* *Real : Beta* sets the elasticity coefficient for modifying a surface [1-1000] ;
+* *Reals : Coeff1 to Coeff6* sets energy coefficients for modifying a surface [0-10000] ;
+* *Real : MaxDeflection* sets maximal deflection of surface from an old position.
+
+This operator may change the original geometry. In addition, it is CPU consuming, and it may fail in some cases. Also **FixGaps** can help only when there are gaps obtained as a result of removal of small edges that can be removed by **DropSmallEdges** or **FixFaceSize**.
+
+**FixFaceSize** removes faces, which are small in all directions (spot face) or small in one direction (strip face)
+This operator can be called with the parameter *Real : Tolerance*, which sets the minimal dimension, which is used to consider a face, is small enough to be removed.
+
+**DropSmallEdges** drops edges in a wire, and merges them with adjacent edges, when they are smaller than the given value (*Tolerance3d*) and when the topology allows such merging (i.e. same adjacent faces for each of the merged edges). Free (non-shared by adjacent faces) small edges can be also removed in case if they share the same vertex Parameters.
+This operator can be called with the parameter *Real : Tolerance3d*, which sets the dimension used to determine if an edge is small.
+
+**FixShape** may be added for fixing invalid shapes. It performs various checks and fixes, according to the modes listed hereafter. Management of a set of fixes can be performed by flags as follows:
+if the flag for a fixing tool is set to 0 , it is not performed if set to 1 , it is performed in any case if not set, or set to -1 , for each shape to be applied on, a check is done to evaluate whether a fix is needed. The fix is performed if the check is positive
+By default, they are not set, i.e. evaluated for each individual shape.
+This operator can be called with the following parameters:
+* *Real : Tolerance3d* sets basic tolerance used for fixing;
+* *Real : MaxTolerance3d* sets maximum allowed value for the resulting tolerance;
+* *Real : MinTolerance3d* sets minimum allowed value for the resulting tolerance.
+* *Boolean : FixFreeShellMode*
+* *Boolean : FixFreeFaceMode*
+* *Boolean : FixFreeWireMode*
+* *Boolean : FixSameParameterMode*
+* *Boolean : FixSolidMode*
+* *Boolean : FixShellMode*
+* *Boolean : FixFaceMode*
+* *Boolean : FixWireMode*
+* *Boolean : FixOrientationMode*
+* *Boolean : FixMissingSeamMode*
+* *Boolean : FixSmallAreaWireMode*
+* *Boolean (not checked) : ModifyTopologyMode* specifies the mode for modifying topology. Should be False (default) for shapes with shells and can be True for free faces.
+* *Boolean (not checked) : ModifyGeometryMode* specifies the mode for modifying geometry. Should be False if geometry is to be kept and True if it can be modified.
+* *Boolean (not checked) : ClosedWireMode* specifies the mode for wires. Should be True for wires on faces and False for free wires.
+* *Boolean (not checked) : PreferencePCurveMode (not used)* specifies the preference of 3d or 2d representations for an edge
+* *Boolean : FixReorderMode*
+* *Boolean : FixSmallMode*
+* *Boolean : FixConnectedMode*
+* *Boolean : FixEdgeCurvesMode*
+* *Boolean : FixDegeneratedMode*
+* *Boolean : FixLackingMode*
+* *Boolean : FixSelfIntersectionMode*
+* *Boolean : FixGaps3dMode*
+* *Boolean : FixGaps2dMode*
+* *Boolean : FixReversed2dMode*
+* *Boolean : FixRemovePCurveMode*
+* *Boolean : FixRemoveCurve3dMode*
+* *Boolean : FixAddPCurveMode*
+* *Boolean : FixAddCurve3dMode*
+* *Boolean : FixSeamMode*
+* *Boolean : FixShiftedMode*
+* *Boolean : FixEdgeSameParameterMode*
+* *Boolean : FixSelfIntersectingEdgeMode*
+* *Boolean : FixIntersectingEdgesMode*
+* *Boolean : FixNonAdjacentIntersectingEdgesMode*
+
+**SplitClosedEdges** handles closed edges i.e. edges with one vertex. Such edges are not supported in some receiving systems. This operator splits topologically closed edges (i.e. edges having one vertex) into two edges. Degenerated edges and edges with a size of less than Tolerance are not processed.
+
+@section occt_shg_7_ Messaging mechanism
+
+Various messages about modification, warnings and fails can be generated in the process of shape fixing or upgrade. The messaging mechanism allows generating messages, which will be sent to the chosen target medium a file or the screen. The messages may report failures and/or warnings or provide information on events such as analysis, fixing or upgrade of shapes.
+
+@subsection occt_shg_7_2 Message Gravity
+Enumeration *Message_Gravity* is used for defining message gravity.
+It provides the following message statuses:
+* *Message_FAIL* - the message reports a fail;
+* *Message_WARNING* - the message reports a warning;
+* *Message_INFO* - the message supplies information.
+
+@subsection occt_shg_7_3 Tool for loading a message file into memory
+Class *Message_MsgFile* allows defining messages by loading a custom message file into memory. It is necessary to create a custom message file before loading it into memory, as its path will be used as the argument to load it. Each message in the message file is identified by a key. The user can get the text content of the message by specifying the message key.
+
+Format of the message file
+--------------------------
+The message file is an ASCII file, which defines a set of messages. Each line of the file must have a length of less than 255 characters.
+All lines in the file starting with the exclamation sign (perhaps preceded by spaces and/or tabs) are considered as comments and are ignored.
+A message file may contain several messages. Each message is identified by its key (string).
+Each line in the file starting with the *dot* character (perhaps preceded by spaces and/or tabs) defines the key. The key is a string starting with a symbol placed after the dot and ending with the symbol preceding the ending of the newline character *\n*.
+All the lines in the file after the key and before the next keyword (and which are not comments) define the message for that key. If the message consists of several lines, the message string will contain newline symbols *\n* between each line (but not at the end).
+The following example illustrates the structure of a message file:
+
+~~~~~
+!This is a sample message file
+!------------------------------
+!Messages for ShapeAnalysis package
+!
+.SampleKeyword
+Your message string goes here
+!
+!...
+!
+!End of message file
+~~~~~
+
+Loading the message file
+------------------------
+A custom file can be loaded into memory using the method *Message_MsgFile::LoadFile*, taking as an argument the path to your file as in the example below:
+~~~~~
+Standard_CString MsgFilePath = ;(path)/sample.file;;
+Message_MsgFile::LoadFile (MsgFilePath);
+~~~~~
+
+@subsection occt_shg_7_4 Tool for managing filling messages
+
+The class *Message_Msg* allows using the message file loaded as a template. This class provides a tool for preparing the message, filling it with parameters, storing and outputting to the default trace file.
+A message is created from a key: this key identifies the message to be created in the message file. The text of the message is taken from the loaded message file (class *Message_MsgFile* is used).
+The text of the message can contain places for parameters, which are to be filled by the proper values when the message is prepared. These parameters can be of the following types:
+* string - coded in the text as *%s*,
+* integer - coded in the text as *%d*,
+* real - coded in the text as *%f*.
+The parameter fields are filled by the message text by calling the corresponding methods *AddInteger, AddReal* and *AddString*. Both the original text of the message and the input text with substituted parameters are stored in the object. The prepared and filled message can be output to the default trace file. The text of the message (either original or filled) can be also obtained.
+~~~~~
+Message_Msg msg01 (;SampleKeyword;);
+//Creates the message msg01, identified in the file by the keyword SampleKeyword
+msg1.AddInteger (73);
+msg1.AddString (;SampleFile;);
+//fills out the code areas
+~~~~~
+
+
+@subsection occt_shg_7_5 Tool for managing trace files
+
+Class *Message_TraceFile* is intended to manage the trace file (or stream) for outputting messages and the current trace level. Trace level is an integer number, which is used when messages are sent. Generally, 0 means minimum, 0 various levels. If the current trace level is lower than the level of the message it is not output to the trace file. The trace level is to be managed and used by the users.
+There are two ways of using trace files:
+* define an object of *Message_TraceFile*, with its own definition (file name or cout, trace level), and use it where it is defined,
+* use the default trace file (file name or cout, trace level), usable from anywhere.
+Use the constructor method to define the target file and the level of the messages as in the example below:
+~~~~~
+Message_TraceFile myTF
+ (tracelevel, *tracefile.log*, Standard_False);
+~~~~~
+The parameters are as follows:
+* *tracelevel* is a Standard_Integer and modifies the level of messages. It has the following values and semantics:
+ + 0: gives general information such as the start and end of process;
+ + 1: gives exceptions raised and fail messages;
+ + 2: gives the same information as 1 plus warning messages.
+* *filename* is the string containing the path to the log file.
+The Boolean set to False will rewrite the existing file. When set to True, new messages will be appended to the existing file.
+
+A new default log file can be added using method *SetDefault* with the same arguments as in the constructor.
+The default trace level can be changed by using method *SetDefLevel*. In this way, the information received in the log file is modified.
+It is possible to close the log file and set the default trace output to the screen display instead of the log file using the method *SetDefault* without any arguments.
+
+
+@section occt_211336372_61271129 Appendix B
+@subsection occt_211336372_612711291 Examples of use
+@subsubsection occt_211336372_6127112911 ShapeAnalysis_Edge and ShapeFix_Edge
+ <table>
+ <tr>
+ <td>
+
+ </td>
+ </tr>
+ <tr>
+ <td>
+
+ </td>
+ <td>
+ 
+ </td>
+ </tr>
+</table> In this example an edge is shown where the maximum deviation between the 3D curve and 2D curve P1 is greater than the edge tolerance.
+
+<h5>Example</h5>
+ShapeAnalysis_Edge sae;
+TopoDS_Face face = ...;
+TopoDS_Wire wire = ...;
+Standard_Real precision = 1e-04;
+ShapeFix_Edge sfe;
+Standard_Real maxdev;
+if (sae.CheckSameParameter (edge, maxdev)) {
+ cout*Incorrect SameParameter flag*endl;
+ cout*Maximum deviation *maxdev *, tolerance *
+BRep_Tool::Tolerance(edge)endl;
+ // Maximum deviation between pcurve and
+ // 3D curve is greater than tolerance
+ sfe.FixSameParameter();
+ cout*New tolerance *BRep_Tool::Tolerance(edge)endl;
+ // Tolerance is increased to englobe the deviation
+}
+
+ <table>
+ <tr>
+ <td>
+
+ </td>
+ </tr>
+ <tr>
+ <td>
+
+ </td>
+ <td>
+ 
+ </td>
+ </tr>
+</table> The result is an increased edge tolerance:
+
+@subsubsection occt_211336372_6127112912 ShapeAnalysis_Wire and ShapeFix_Wire
+This wire is first analyzed to check that:
+ * the edges are correctly oriented
+ * there are no edges that are too short and
+ * that there are no intersecting adjacent edges.
+
+
+ <table>
+ <tr>
+ <td>
+
+ </td>
+ </tr>
+ <tr>
+ <td>
+
+ </td>
+ <td>
+ 
+ </td>
+ </tr>
+</table>
+<h5>Example</h5>
+
+ShapeAnalysis_Edge sae;
+TopoDS_Face face = ...;
+TopoDS_Wire wire = ...;
+Standard_Real precision = 1e-04;
+ShapeFix_Edge sfe;
+Standard_Real maxdev;
+if (sae.CheckSameParameter (edge, maxdev)) {
+ cout<<“Incorrect SameParameter flag”<<endl;
+ cout<<“Maximum deviation “<<maxdev<< “, tolerance “
+<<BRep_Tool::Tolerance(edge)<<endl;
+ // Maximum deviation between pcurve and
+ // 3D curve is greater than tolerance
+ sfe.FixSameParameter();
+ cout<<“New tolerance “<<BRep_Tool::Tolerance(edge)<<endl;
+ // Tolerance is increased to englobe the deviation
+}
+
+
+
+ShapeAnalysis_Wire saw (wire, face, precision);
+ShapeFix_Wire sfw (wire, face, precision);
+if (saw.CheckOrder()) {
+ cout*Some edges in the wire need to be reordered*endl;
+ // Two edges are incorrectly oriented
+ sfw.FixReorder();
+ cout*Reordering is done*endl;
+}
+// their orientation is corrected
+if (saw.CheckSmall (precision)) {
+ cout*Wire contains edge(s) shorter than *precisionendl;
+ // An edge that is shorter than the given
+ // tolerance is found
+ Standard_Boolean LockVertex = Standard_True;
+ if (sfw.FixSmall (LockVertex, precision)) {
+ cout*Edges shorter than *precision* have been removed*
+endl;
+ //The edge is removed
+ }
+}
+if (saw.CheckSelfIntersection()) {
+ cout*Wire has self-intersecting or intersecting
+adjacent edges*endl;
+ // Two intersecting adjacent edges are found
+ if (sfw.FixSelfIntersection()) {
+ cout*Wire was slightly self-intersecting. Repaired*endl;
+ // The edges are cut at the intersection point so
+ // that they no longer intersect
+ }
+}
+Here is the result:
+
+@subsubsection occt_211336372_6127112913 MoniTool_Timer
+Using timers in XSDRAWIGES.cxx and IGESBRep_Reader.cxx for analysis performance command ;igesbrep;:
+
+XSDRAWIGES.cxx
+ ...
+ #include MoniTool_Timer.hxx
+ #include MoniTool_TimerSentry.hxx
+ ...
+ MoniTool_Timer::ClearTimers();
+ ...
+ MoniTool_TimerSentry MTS(;IGES_LoadFile;);
+ Standard_Integer status = Reader.LoadFile(fnom.ToCString());
+ MTS.Stop();
+ ...
+ MoniTool_Timer::DumpTimers(cout);
+ return;
+
+
+IGESBRep_Reader.cxx
+ ...
+ #include MoniTool_TimerSentry.hxx
+ ...
+ Standard_Integer nb = theModel-NbEntities();
+ ...
+ for (Standard_Integer i=1; i=nb; i++) {
+ MoniTool_TimerSentry MTS(;IGESToBRep_Transfer;);
+ ...
+ try {
+ TP.Transfer(ent);
+ shape = TransferBRep::ShapeResult (theProc,ent);
+ }
+ ...
+ }
+
+**Result**
+DumpTimer() after translation file:
\ No newline at end of file
--- /dev/null
+STEP processor {#user_guides__step}
+========================
+
+@section occt_1624647986_1317425384 Overview
+
+This manual is intended to provide technical documentation on the Open CASCADE Technology (**OCCT**) STEP processor and to help Open CASCADE Technology users with the use of the STEP processor (to read and write STEP files). STEP files conforming to AP 214, AP 203 and partially AP 209 can be read. STEP files that are produced by this interface conform to STEP AP 214 or AP 203, according to the user option.
+Only geometrical, topological STEP entities (shapes) and assembly structures are translated by the basic translator described in sections 2 to 6. Data that cannot be translated on this level are also loaded from a STEP file and can be translated later. XDE STEP translator (see section 7 *<a href="#_Reading_from_and_writing to XDE">Reading from and writing to XDE</a>*) translates names, colors, layers, validation properties and other data associated with shapes and assemblies into XDE document.
+File translation is performed in the programming mode, via C++ calls.
+For testing the STEP component in DRAW Test Harness, a set of commands for reading and writing STEP files and analysis of relevant data are provided by the TKXSDRAW plugin.
+
+@section occt_1624647986_24898012 Reading STEP
+@subsection occt_1624647986_248980121 Procedure
+You can translate a STEP file into an OCCT shape in the following steps:
+1. load the file,
+2. check file consistency,
+3. set the translation parameters,
+4. perform the translation,
+5. fetch the results.
+@subsection occt_1624647986_248980122 Domain covered
+@subsubsection occt_1624647986_2489801221 Assemblies
+The ;ProSTEP Round Table Agreement Log; (version July 1998), item 21, defines two alternatives for the implementation of assembly structure representations: using mapped_item entities and using representation_relationship_with_transformation entities. Both these alternative representations are recognized and processed at reading. On writing, the second alternative is always employed.
+Handling of assemblies is implemented in two separate levels: firstly STEP assembly structures are translated into OCCT shapes, and secondly the OCCT shape representing the assembly is converted into any data structure intended for representing assemblies (for example, OCAF).
+The first part of this document describes the basic STEP translator implementing translation of the first level, i.e. translation to OCCT Shapes. On this level, the acyclic graph representing the assembly structure in a STEP file is mapped into the structure of nested TopoDS_Compounds in Open CASCADE Technology. The (sub)assemblies become (sub)compounds containing shapes which are the results of translating components of that (sub)assembly. The sharing of components of assemblies is preserved as Open CASCADE Technology sharing of subshapes in compounds.
+The attributive information attached to assembly components in a STEP file (such as names and descriptions of products, colors, layers etc.) can be translatd after the translation of the shape itself by parsing the STEP model (loaded in memory). Several tools from the package STEPConstruct provide functionalities to read styles (colors), validation properties, product information etc.
+Implementation of the second level of translation (conversion to XDE data structure) is provided by XDE STEP translator and is described in section 7.
+@subsubsection occt_1624647986_2489801222 Shape representations
+Length units, plane angle units and the uncertainty value are taken from shape_representation entities. This data is used in the translation process.
+The types of STEP representation entities that are recognized are:
+ * advanced_brep_shape_representation
+ * faceted_brep_shape_representation
+ * manifold_surface_shape_representation
+ * geometrically_bounded_wireframe_shape_representation
+ * geometrically_bounded_surface_shape_representation
+ * hybrid representations (shape_representation containing models of different type)
+@subsubsection occt_1624647986_2489801223 Topological entities
+The types of STEP topological entities that can be translated are:
+ * vertices
+ * edges
+ * loops
+ * faces
+ * shells
+ * solids
+For further information see 2.4 Mapping STEP entities to Open CASCADE Technology shapes.
+@subsubsection occt_1624647986_2489801224 Geometrical entities
+The types of STEP geometrical entities that can be translated are:
+ * points
+ * vectors
+ * directions
+ * curves
+ * surfaces
+For further information see 2.4 Mapping STEP entities to Open CASCADE Technology shapes.
+@subsection occt_1624647986_248980123 Description of the process
+@subsubsection occt_1624647986_2489801231 Loading the STEP file
+Before performing any other operation you have to load the file with:
+STEPControl_Reader reader;
+IFSelect_ReturnStatus stat = reader.ReadFile(;filename.stp;);
+Loading the file only memorizes the data, it does not translate it.
+@subsubsection occt_1624647986_2489801232 Checking the STEP file
+This step is not obligatory. Check the loaded file with:
+reader.PrintCheckLoad(failsonly,mode);
+Error messages are displayed if there are invalid or incomplete STEP entities, giving you the information on the cause of error.
+Only fail messages are displayed if failsonly is true. All messages are displayed if failsonly is false. Your analysis of the file can be either message-oriented or entity-oriented. Choose your preference with:
+IFSelect_PrintCount mode = IFSelect_xxx
+Where xxx can be one of the following:
+ItemsByEntity - gives a sequential list of all messages per STEP entity,
+CountByItem - gives the number of STEP entities with their types per message
+ListByItem - gives the number of STEP entities with their types and rank numbers per message
+@subsubsection occt_1624647986_2489801233 Setting the translation parameters
+The following parameters can be used to translate a STEP file into an OCCT shape.
+If you give a value that is not within the range of possible values it will simply be ignored.
+<h4>read.precision.mode</h4>
+Defines which precision value will be used during translation (see section 2.5 below for details on precision and tolerances).
+;File; (0): the precision value is set to length_measure in uncertainty_measure_with_unit from STEP file.
+;User; (1): the precision value is that of the read.precision.val parameter.
+Read this parameter with:
+Standard_Integer ic = Interface_Static::IVal(;read.precision.mode;);
+Modify this parameter with:
+if(!Interface_Static::SetIVal(;read.precision.mode;,1))
+.. error ..
+Default value is ;File; (0).
+<h4>read.precision.val:</h4>
+User defined precision value. This parameter gives the precision for shape construction when the read.precision.mode parameter value is 1.
+ 0.0001: default
+ any real positive (non null) value.
+This value is a basic value of tolerance in the processor. The value is in millimeters, independently of the length unit defined in the STEP file.
+Read this parameter with:
+Standard_Real rp = Interface_Static::RVal(;read.precision.val;);
+Modify this parameter with:
+if(!Interface_Static::SetRVal(;read.precision.val;,0.01))
+.. error ..
+Default value is 0.0001.
+The value given to this parameter is a basic value for ShapeHealing algorithms and the processor. It does its best to reach it. Under certain circumstances, the value you give may not be attached to all of the entities concerned at the end of processing. STEP-to-OpenCASCADE translation does not improve the quality of the geometry in the original STEP file. This means that the value you enter may be impossible to attach to all shapes with the given quality of the geometry in the STEP file.
+<h4>read.maxprecision.val</h4>
+Defines the maximum allowed tolerance (in mm) of the shape. It should be not less than the basic value of tolerance set in the processor (either the uncertainty from the file or read.precision.val). Actually, the maximum between read.maxprecision.val and the basis tolerance is used to define the maximum allowed tolerance.
+Read this parameter with:
+Standard_Real rp = Interface_Static::RVal(;read.maxprecision.val;);
+Modify this parameter with:
+if(!Interface_Static::SetRVal(;read.maxprecision.val;,0.1))
+.. error ..
+Default value is 1.
+Note that maximum tolerance even explicitly defined by the user may be insufficient to ensure the validity of the shape (if real geometry is of bad quality). Therefore the user is provided with an additional parameter, which allows him to choose: either he prefers to ensure the shape validity or he rigidly sets the value of maximum tolerance. In the first case there is a possibility that the tolerance will not have any upper limit, in the second case the shape may be invalid.
+<h4>read.maxprecision.mode:</h4>
+Defines the mode of applying the maximum allowed tolerance. Its possible values are:
+0 (;Preferred;) - maximum tolerance is used as a limit but sometimes it can be exceeded (currently, only for deviation of a 3D curve and pcurves of an edge, and vertices of such edge) to ensure the shape validity,
+1 (;Forced;) - maximum tolerance is used as a rigid limit, i.e. no tolerance can exceed it and if it is the case, the tolerance is trimmed by the maximum tolerance.
+Read this parameter with:
+Standard_Integer ic = Interface_Static::IVal(;read.maxprecision.mode;);
+Modify this parameter with:
+if(!Interface_Static::SetIVal(;read.maxprecision.mode;,1))
+.. error ..
+Default value is 0 (;Preferred;).
+<h4>read.stdsameparameter.mode</h4>
+defines the use of BRepLib::SameParameter. Its possible values are:
+0 (;Off;) - BRepLib::SameParameter is not called,
+1 (;On;) - BRepLib::SameParameter is called.
+The functionality of BRepLib::SameParameter is used through ShapeFix_Edge::SameParameter. It ensures that the resulting edge will have the lowest tolerance taking pcurves either unmodified from the STEP file or modified by BRepLib::SameParameter.
+Read this parameter with:
+Standard_Integer mv = Interface_Static::IVal(;read.stdsameparameter.mode;);
+Modify this parameter with:
+if (!Interface_Static::SetIVal (;read.stdsameparameter.mode;,1))
+.. error ..;
+Deafault value is 0 (;Off;).
+<h4>read.surfacecurve.mode:</h4>
+a preference for the computation of curves in an entity which has both 2D and 3D representation.
+Each TopoDS_Edge in TopoDS_Face must have a 3D and 2D curve that references the surface.
+If both 2D and 3D representation of the entity are present, the computation of these curves depends on the following values of parameter:
+;Default; (0): no preference, both curves are taken (default value),
+;3DUse_Preferred; (3): 3D curves are used to rebuild 2D ones.
+Read this parameter with:
+Standard_Integer rp = Interface_Static::IVal(;read.surfacecurve.mode;);
+Modify this parameter with:
+if(!Interface_Static::SetIVal(;read.surfacecurve.mode;,3))
+.. error ..
+Default value is (0).
+<h4>read.encoderegularity.angle</h4>
+This parameter is used for call to BRepLib::EncodeRegularity() function which is called for the shape read from an IGES or a STEP file at the end of translation process. This function sets the regularity flag of the edge in the shell when this edge is shared by two faces. This flag shows the continuity these two faces are connected with at that edge.
+Read this parameter with:
+Standard_Real era = Interface_Static::RVal(;read.encoderegularity.angle;);
+Modify this parameter with:
+if (!Interface_Static::SetRVal (;read.encoderegularity.angle;,0.1))
+.. error ..;
+Default value is 0.01.
+<h4>step.angleunit.mode</h4>
+This parameter is obsolete (it was required in the past for STEP files with a badly encoded angle unit). It indicates what angle units should be used when a STEP file is read: the units from file (default), or forced RADIANS or DEGREES.
+Default value is File
+<h4>read.step.resource.name</h4>
+<h4>read.step.sequence</h4>
+These two parameters define the name of the resource file and the name of the sequence of operators (defined in that file) for Shape Processing, which is automatically performed by the STEP translator. Shape Processing is a user-configurable step, which is performed after translation and consists in applying a set of operators to a resulting shape. This is a very powerful tool allowing customizing the shape and adapting it to the needs of a receiving application. By default the sequence consists of a single operator ShapeFix - that is how Shape Healing is called from the STEP translator.
+Please find an example of the resource file for STEP (which defines parameters corresponding to the sequence applied by default, i.e. if the resource file is not found) in the Open CASCADE Technology installation, by the path %CASROOT%/src/XSTEPResource/STEP ($CASROOT/src/XSTEPResource/STEP).
+In order for the STEP translator to use that file, you have to define the CSF_STEPDefaults environment variable, which should point to the directory where the resource file resides. Note that if you change parameter read.step.resource.name, you will change the name of the resource file and the environment variable correspondingly.
+Default values: read.step.resource.name - STEP, read.step.sequence - FromSTEP.
+<h4>read.scale.unit</h4>
+This parameter is obsolete (the parameter xstep.cascade.unit should be used instead when necessary). If it is set to 'M', the shape is scaled 0.001 times (as if it were in meters) after translation from IGES or STEP.
+Default value is MM.
+<h4>xstep.cascade.unit</h4>
+This parameter defines units to which a shape should be converted when translated from IGES or STEP to CASCADE. Normally it is MM; only those applications that work internally in units other than MM should use this parameter.
+Default value is MM.
+<h4>read.step.product.mode:</h4>
+Defines the approach used for selection of top-level STEP entities for translation, and for recognition of assembly structures
+1 (;ON;) - PRODUCT_DEFINITION entities are taken as top-level ones; assembly structure is recognized by NEXT_ASSEMBLY_USAGE_OCCURRENCE entities. This is regular mode for reading valid STEP files conforming to AP 214, AP203 or AP 209.
+0 (;OFF;) - SHAPE_DEFINITION_REPRESENTATION entities are taken as top-level ones; assembly is recognized by CONTEXT_DEPENDENT_SHAPE_REPRESENTATION entities. This is compatibility mode, which can be used for reading legacy STEP files produced by older versions of STEP translators and having incorrect or incomplete product information.
+Read this parameter with:
+Standard_Integer ic = Interface_Static::IVal(;read.step.product.mode;);
+Modify this parameter with:
+if(!Interface_Static::SetIVal(;read.step.product.mode;,1))
+.. error ..
+Default value is 1 (;ON;).
+Note that the following parameters have effect only if read.step.product.mode is ON.
+<h4>read.step.product.context:</h4>
+When reading AP 209 STEP files, allows selecting either only ‘design’ or ‘analysis’, or both types of products for translation
+1 (;all;) - translate all products
+2 (;design;) - translate only products that have PRODUCT_DEFINITION_CONTEXT with field life_cycle_stage set to ‘design’
+3 (*analysis*) - translate only products associated with PRODUCT_DEFINITION_CONTEXT entity whose field life_cycle_stage set to ‘analysis’
+Note that in AP 203 and AP214 files all products should be marked as ‘design’, so if this mode is set to ‘analysis’, nothing will be read.
+Read this parameter with:
+Standard_Integer ic = Interface_Static::IVal(;read.step.product.context;);
+Modify this parameter with:
+if(!Interface_Static::SetIVal(;read.step.product.context;,1))
+.. error ..
+Default value is 1 (;all;).
+<h4>read.step.shape.repr:</h4>
+Specifies preferred type of representation of the shape of the product, in case if a STEP file contains more than one representation (i.e. multiple PRODUCT_DEFINITION_SHAPE entities) for a single product
+1 (;All;) - Translate all representations (if more than one, put in compound).
+2 (;ABSR;) - Prefer ADVANCED_BREP_SHAPE_REPRESENTATION
+3 (;MSSR;) - Prefer MANIFOLD_SURFACE_SHAPE_REPRESENTATION
+4 (;GBSSR;) - Prefer GEOMETRICALLY_BOUNDED_SURFACE_SHAPE_REPRESENTATION
+5 (;FBSR;) - Prefer FACETTED_BREP_SHAPE_REPRESENTATION
+6 (;EBWSR;) - Prefer EDGE_BASED_WIREFRAME_SHAPE_REPRESENTATION
+7 (;GBWSR;) - Prefer GEOMETRICALLY_BOUNDED_WIREFRAME _SHAPE_REPRESENTATION
+When this option is not equal to 1, for products with multiple representations the representation having a type closest to the selected one in this list will be translated.
+Read this parameter with:
+Standard_Integer ic = Interface_Static::IVal(;read.step.shape.repr;);
+Modify this parameter with:
+if(!Interface_Static::SetIVal(;read.step.shape.repr;,1))
+.. error ..
+Default value is 1 (;All;).
+<h4>read.step.assembly.level:</h4>
+Specifies which data should be read for the products found in the STEP file:
+1 (;All;) - Translate both the assembly structure and all associated shapes. If both shape and sub-assemblies are associated with the same product, all of them are read and put in a single compound.
+ Note that this situation is confusing, as semantics of such configuration is not defined clearly by the STEP standard (whether this shape is an alternative representation of the assembly or is an addition to it), therefore warning will be issued in such case.
+2 (;assembly;) - Translate the assembly structure and shapes associated with parts only (not with sub-assemblies).
+3 (;structure;) - Translate only the assembly structure without shapes (a structure of empty compounds). This mode can be useful as an intermediate step in applications requiring specialized processing of assembly parts.
+4 (;shape;) - Translate only shapes associated with the product, ignoring the assembly structure (if any). This can be useful to translate only a shape associated with specific product, as a complement to *assembly* mode.
+Read this parameter with:
+Standard_Integer ic = Interface_Static::IVal(;read.step.assembly.level;);
+Modify this parameter with:
+if(!Interface_Static::SetIVal(;read.step.assembly.level ;,1))
+.. error ..
+Default value is 1 (;All;).
+<h4>read.step.shape.relationship:</h4>
+Defines whether shapes associated with the main SHAPE_DEFINITION_REPRESENTATION entity of the product via SHAPE_REPRESENTATIONSHIP_RELATION should be translated. This kind of association is used for the representation of hybrid models (i.e. models whose shape is composed of different types of representations) in AP 203 files since 1998, but it can be also used to associate auxiliary data with the product. This parameter allows to avoid translation of such auxiliary data.
+1 (;ON;) - translate
+0 (;OFF;) - do not translate
+Read this parameter with:
+Standard_Integer ic = Interface_Static::IVal(;read.step.shape.relationship;);
+Modify this parameter with:
+if(!Interface_Static::SetIVal(;read.step.shape.relationship;,1))
+.. error ..
+Default value is 1 (;ON;).
+<h4>read.step.shape.aspect:</h4>
+Defines whether shapes associated with the PRODUCT_DEFINITION_SHAPE entity of the product via SHAPE_ASPECT should be translated. This kind of association was used for the representation of hybrid models (i.e. models whose shape is composed of different types of representations) in AP 203 files before 1998, but it is also used to associate auxiliary information with the sub-shapes of the part. Though STEP translator tries to recognize such cases correctly, this parameter may be useful to avoid unconditionally translation of shapes associated via SHAPE_ASPECT entities.
+1 (;ON;) - translate
+0 (;OFF;) - do not translate
+Read this parameter with:
+Standard_Integer ic = Interface_Static::IVal(;read.step.shape.aspect;);
+Modify this parameter with:
+if(!Interface_Static::SetIVal(;read.step.shape.aspect;,1))
+.. error ..
+Default value is 1 (;ON;).
+@subsubsection occt_1624647986_2489801234 Performing the STEP file translation
+Perform the translation according to what you want to translate. You can choose either root entities (all or selected by the number of root), or select any entity by its number in the STEP file. There is a limited set of types of entities that can be used as starting entities for translation. Only the following entities are recognized as transferable:
+ * product_definition
+ * next_assembly_usage_occurrence
+ * shape_definition_representation
+ * subtypes of shape_representation (only if referred representation is transferable)
+ * manifold_solid_brep
+ * brep_with_voids
+ * faceted_brep
+ * faceted_brep_and_brep_with_voids
+ * shell_based_surface_model
+ * geometric_set and geometric_curve_set
+ * mapped_item
+ * subtypes of face_surface (including advanced_face)
+ * subtypes of shape_representation_relationship
+ * context_dependent_shape_representation
+<h5>The following methods are used for translation:</h5>
+ * Translate a root entity identified by its rank with:
+Standard_Boolean ok = reader.TransferRoot(rank);
+ * Translate an entity identified by its rank with:
+Standard_Boolean ok = reader.TransferOne(rank);
+ * Translate a list of entities in one operation with (this method returns the number of successful translations):
+Standard_Integer num = reader.TransferList(list);
+ * Translate all transferable roots with:
+Standard_Integer NbRoots = reader.NbRootsForTransfer();
+Standard_Integer num = reader.TransferRoots();
+@subsubsection occt_1624647986_2489801235 Getting the translation results
+Each successful translation operation outputs one shape. A series of translations gives a set of shapes.
+Each time you invoke TransferOne(), TransferRoot() or TransferList(), their results are accumulated and the counter of results increases. You can clear the results with:
+reader.ClearShapes();
+between two translation operations, if you do not, the results from the next translation will be added to the accumulation.
+TransferRoots() operations automatically clear all existing results before they start.
+ * Get the number of shapes recorded in the result with:
+Standard_Integer num = reader.NbShapes();
+ * Get the result identified by its rank, where rank is an integer between 1 and NbShapes, with:
+TopoDS_Shape shape = reader.Shape(rank);
+ * Get the first result of translation with:
+TopoDS_Shape shape = reader.Shape();
+ * Get all of results in a single shape which is:
+a null shape if there are no results,
+in case of a single result, a shape that is specific to that result,
+a compound that lists the results if there are several results.
+TopoDS_Shape shape = reader.OneShape();
+<h5>Clearing the accumulation of results</h5>
+If several individual translations follow each other, the results give a list that can be purged with:
+reader.ClearShapes();
+which erases the existing results.
+<h5>Checking that translation was correctly performed</h5>
+Each time you invoke Transfer… or TransferRoots(), you can display the related messages with the help of:
+reader.PrintCheckTransfer(failsonly,mode);
+This check concerns the last invocation of Transfer… or TransferRoots() only.
+@subsubsection occt_1624647986_2489801236 Selecting STEP entities for translation
+<h4>Selection possibilities</h4>
+There are three selection possibilities. You can select:
+ * the whole file,
+ * a list of entities,
+ * one entity.
+<h4>Whole file</h4>
+Transferring the whole file means transferring all root entities. The number of roots can be evaluated when the file is loaded:
+Standard_Integer NbRoots = reader.NbRootsForTransfer();
+Standard_Integer num = reader.TransferRoots();
+<h4>Lists of entities</h4>
+A list of entities can be formed by invoking STEP214Control_Reader::GiveList (this is a method of the parent class).
+Here is a simple example of how a list is translated:
+Handle(TColStd_HSequenceOfTransient) list = reader.GiveList();
+The result is a TColStd_HSequenceOfTransient.
+You can either translate a list entity by entity or all at once. An entity-by-entity operation lets you check each individual entity translated.
+<h5>Translating a whole list in one operation</h5>
+Standard_Integer nbtrans = reader.TransferList (list);
+nbtrans gives the number of items in the list that produced a shape.
+<h5>Translating a list entity by entity:</h5>
+Standard_Integer i,nb = list-Length();
+for (i = 1; i = nb; i ++) {
+ Handle(Standard_Transient) ent = list-Value(i);
+ Standard_Boolean OK = reader.TransferEntity (ent);
+}
+<h4>Selections</h4>
+There is a number of predefined operators that can be used. They are:
+ * step214-placed-items
+Selects all mapped_items or context_depended_shape_representations.
+ * step214-shape-def-repr
+Selects all shape_definition_representations.
+ * step214-shape-repr
+ Selects all shape_representations.
+ * step214-type(entity_type)
+Selects all entities of a given type
+ * step214-faces
+Selects all faces_surface, advanced_face entities and the surface entity or any sub type if these entities are not shared by any face entity or shared by geometric_set entity.
+ * step214-derived(entity_type)
+Selects entities of a given type or any subtype.
+ * step214-GS-curves
+Selects all curve entities or any subtype except the composite_curve if these entities are shared by the geometric_set entity.
+ * step214-assembly
+Selects all mapped_items or context_depended_shape_representations involved into the assembly structure.
+ * xst-model-all
+Selects all entities.
+ * xst-model-roots
+Selects all roots.
+ * xst-shared + selection
+Selects all entities shared by at least one entity selected by selection.
+ * xst-sharing + selection
+Selects all entities sharing at least one entity selected by selection.
+ * xst-transferrable-all
+Selects all transferable entities.
+ * xst-transferrable-roots
+Selects all translatable roots.
+Cumulative lists can be used too.
+<h4>Single entities</h4>
+You can select an entity either by its rank or by its handle (an entity’s handle can be obtained by invoking the StepData_StepModel::Entity function).
+<h5>Selection by rank</h5>
+Use method StepData_StepModel::NextNumberForLabel to find its rank with the following:
+Standard_CString label = ‘#...’;
+StepData_StepModel model = reader.StepModel();
+rank = model-NextNumberForLabe(label, 0, Standard_False);
+Translate an entity specified by its rank:
+Standard_Boolean ok = reader.Transfer (rank);
+<h5>Direct selection of an entity</h5>
+ent is the entity. The argument is a Handle(Standard_Transient).
+Standard_Boolean ok = reader.TransferEntity (ent);
+@subsection occt_1624647986_248980124 Mapping STEP entities to Open CASCADE Technology shapes
+Tables given in this paragraph show the mapping of STEP entities to OCCT objects. Only topological and geometrical STEP entities and entities defining assembly structures are described in this paragraph. For a full list of STEP entities please refer to Appendix A.
+@subsubsection occt_1624647986_2489801241 Assembly structure representation entities
+Not all entities defining the assembly structure in the STEP file are translated to OCCT shapes, but they are used to identify the relationships between assemblies and their components. Since the graph of ‘natural’ dependencies of entities based on direct references between them does not include the references from assemblies to their components, these dependencies are introduced in addition to the former ones. This is made basing on the analysis of the following entities describing the structure of the assembly.
+
+@subsubsection occt_1624647986_2489801242 Models
+
+@subsubsection occt_1624647986_2489801243 Topological entities
+
+
+@subsubsection occt_1624647986_2489801244 Geometrical entities
+3D STEP entities are translated into geometrical objects from the Geom package while 2D entities are translated into objects from the Geom2d package.
+
+@subsection occt_1624647986_248980125 Tolerance management
+@subsubsection occt_1624647986_2489801251 Values used for tolerances during reading STEP
+During the STEP = OCCT translation several parameters are used as tolerances and precisions for different algorithms. Some of them are computed from other tolerances using specific functions.
+<h4>3D (spatial) tolerance</h4>
+<h5>Package method Precision::Confusion()</h5>
+Value is 10-7. It is used as the minimal distance between points, which are considered to be distinct.
+<h5>Uncertainty in STEP file</h5>
+This parameter is attached to each shape_representation entity in a STEP file and defined as length_measure in uncertainty_measure_with_unit. It is used as a fundamental value of precision during translation.
+<h5>User - defined variable read.precision.val</h5>
+It is used instead of uncertainty from a STEP file when parameter read.precision.mode is 1 (*User*).
+<h4>2D (parametric) tolerances</h4>
+<h5>Package method Precision::PConfusion()</h5>
+This is a value of 0.01* Precision::Confusion(). It is used to compare parametric bounds of curves.
+<h5>Methods UResolution, VResolution (tolerance3d) of the class GeomAdaptor_Surface or BRepAdaptor_Surface</h5>
+Return tolerance in parametric space of a surface computed from 3d tolerance.
+When one tolerance value is to be used for both U and V parametric directions, the maximum or the minimum value of UResolution and VResolution is used.
+<h4>Methods Resolution (tolerance3d) of the class GeomAdaptor_Curve or BRepAdaptor_Curve</h4>
+Returns tolerance in parametric space of a curve computed from 3d tolerance.
+@subsubsection occt_1624647986_2489801252 Initial setting of tolerances in translating objects
+In the STEP processor, the basic value of tolerance is set in method STEPControl_ActorRead::Transfer() to either value of uncertainty in shape_representation in STEP file (if parameter read.precision.mode is 0), or to a value of parameter read.precision.val (if read.precision.mode is 1 or if the uncertainty is not attached to the current entity in the STEP file).
+Translation starts from one entity translated as a root. Function which performs the translation (STEPControl_ActorRead::Transfer() ) creates an object of the type StepToTopoDS_Builder, which is intended to translate topology.
+This object gets the initial tolerance value that is equal to read.precision.val or the uncertainty from shape_representation. During the translation of the entity, new objects of types StepToTopoDS_Translate... are created for translating sub-entities. All of them use the same tolerances as a StepToTopoDS_Builder object.
+@subsubsection occt_1624647986_2489801253 Transfer process
+<h4>Evolution of shape tolerances during transfer</h4>
+Let us follow the evolution of tolerances during the translation of STEP entities into an OCCT shape.
+If the starting STEP entity is a geometric_curve_set all the edges and vertices are constructed with Precision::Confusion().
+If the starting STEP entity is not a geometric_curve_set the sub-shapes of the resulting shape have the following tolerance:
+ * all the faces are constructed with Precision::Confusion(),
+ * edges are constructed with Precision::Confusion(). It can be modified later by:
+1.ShapeFix::SameParameter() - the tolerance of edge shows real deviation of the 3D curve and pcurves.
+2.ShapeFix_Wire::FixSelfIntersection() in case if a pcurve of a self-intersecting edge is modified.
+ * vertices are constructed with Precision::Confusion(). It can be modified later by:
+1.StepToTopoDS_TranslateEdge
+2.ShapeFix::SameParameter()
+3.ShapeFix_Wire::FixSelfIntersection()
+4.ShapeFix_Wire::FixLacking()
+5.ShapeFix_Wire::Connected()
+So, the final tolerance of sub-shapes shows the real local geometry of shapes (distance between vertices of adjacent edges, deviation of a 3D curve of an edge and its parametric curves and so on) and may be less or greater than the basic value of tolerance in the STEP processor.
+<h4>Translating into Geometry</h4>
+Geometrical entities are translated by classes StepToGeom_Make... Methods of these classes translate STEP geometrical entities into OCCT geometrical objects. Since these objects are not BRep objects, they do not have tolerances. Tolerance is used only as precision for detecting bad cases (such as points coincidence).
+<h4>Translating into Topology</h4>
+STEP topological entities are translated into OCCT shapes by use of the following classes (package StepToTopoDS):
+ * StepToTopoDS_TranslateVertex
+ * StepToTopoDS_TranslateEdge
+ * StepToTopoDS_TranslateVertexLoop
+ * StepToTopoDS_TranslateEdgeLoop
+ * StepToTopoDS_TranslatePolyLoop
+ * StepToTopoDS_TranslateFace
+ * StepToTopoDS_TranslateShell
+ * StepToTopoDS_TranslateCompositeCurve
+ * StepToTopoDS_TranslateCurveBoundedSurface
+ * StepToTopoDS_Builder
+ * StepToTopoDS_MakeTransformed
+Although in a STEP file the uncertainty value is assigned to shape_representation entities and this value is applied to all entities in this shape_representation, OCCT shapes are produced with different tolerances. As a rule, updating the tolerance is fulfilled according to the local geometry of shapes (distance between vertices of adjacent edges, deviation of edge's 3D curve and its parametric curves and so on) and may be either less or greater than the uncertainty value assigned to the entity.
+The following paragraphs show what default tolerances are used when creating shapes and how they are updated during translation.
+<h5>Class StepToTopoDS_TranslateVertex</h5>
+TopoDS_Vertex is constructed from a STEP vertex_point entity with Precision::Confusion().
+<h5>Class StepToTopoDS_TranslateVertexLoop</h5>
+Degenerated TopoDS_Edge in TopoDS_Wire is created with tolerance Precision::Confusion(). TopoDS_Vertex of a degenerated edge is constructed with the initial value of tolerance.
+<h5>Class StepToTopoDS_TranslateEdge</h5>
+TopoDS_Edge is constructed only on the basis of 3D curve with Precision::Confusion().. Tolerance of the vertices can be increased up to a distance between their positions and ends of 3D curve.
+<h5>Class StepToTopoDS_TranslateEdgeLoop</h5>
+TopoDS_Edges in TopoDS_Wire are constructed with the help of class StepToTopoDS_TranslateEdge. Pcurves from a STEP file are translated if they are present and read.surfacecurve.mode is 0. For each edge method ShapeFix_Edge::FixSameParameter() is called. If the resulting tolerance of the edge is greater than the maximum value between 1.0 and 2*Value of basis precision, then the pcurve is recomputed. The best of the original and the recomputed pcurve is put into TopoDS_Edge. The resulting tolerance of TopoDS_Edge is a maximal deviation of its 3D curve and its pcurve(s).
+<h5>Class StepToTopoDS_TranslatePolyLoop</h5>
+TopoDS_Edges in TopoDS_Wire are constructed with the help of class StepToTopoDS_TranslateEdge. Their tolerances are not modified inside this method.
+<h5>Class StepToTopoDS_TranslateFace</h5>
+TopoDS_Face is constructed with the initial value of tolerance.
+TopoDS_Wire on TopoDS_Face is constructed with the help of classes StepToTopoDS_TranslatePolyLoop, StepToTopoDS_TranslateEdgeLoop or StepToTopoDS_TranslateVertexLoop.
+<h5>Class StepToTopoDS_TranslateShell</h5>
+This class calls StepToTopoDS_TranslateFace::Init for each face. This class does not modify the tolerance value.
+<h5>Class StepToTopoDS_TranslateCompositeCurve</h5>
+TopoDS_Edges in TopoDS_Wire are constructed with the help of class BRepAPI_MakeEdge and have a tolerance 10-7. Pcurves from a STEP file are translated if they are present and if read.surfacecurve.mode is not -3. The connection between segments of a composite curve (edges in the wire) is ensured by call to method ShapeFix_Wire::FixConnected() with a precision equal to the initial value of tolerance.
+<h5>Class StepToTopoDS_TranslateCurveBoundedSurface</h5>
+TopoDS_Face is constructed with tolerance Precision::Confusion().
+TopoDS_Wire on TopoDS_Face is constructed with the help of class StepToTopoDS_TranslateCompositeCurve. Missing pcurves are computed using projection algorithm with the help of method ShapeFix_Face::FixPcurves(). For resulting face method ShapeFix::SameParameter() is called. It calls standard BRepLib::SameParameter for each edge in each wire, which can either increase or decrease the tolerances of the edges and vertices. SameParameter writes the tolerance corresponding to the real deviation of pcurves from 3D curve which can be less or greater than the tolerance in a STEP file.
+<h5>Class StepToTopoDS_Builder</h5>
+Class StepToTopoDS_Builder is a high level class. Its methods perform translation with the help of the classes listed above. If the value of read.maxprecision.mode is set to 1 then the tolerance of subshapes of the resulting shape is limited by 0 and read.maxprecision.val. Else this class does not change the tolerance value.
+<h5>Class StepToTopoDS_MakeTransformed</h5>
+This class performs a translation of mapped_item entity and indirectly uses class StepToTopoDS_Builder. The tolerance of the resulting shape is not modified inside this method.
+<h4>Healing of resulting shape in ShapeHealing component</h4>
+<h5>Class ShapeFix_Wire</h5>
+1. ShapeFix_Wire::FixSelfIntersection()
+This method is intended for detecting and fixing self-intersecting edges and intersections of adjacent edges in a wire. It fixes self-intersections by cutting edges at the intersection point and/or by increasing the tolerance of the vertex (so that the vertex comprises the point of intersection). There is a maximum tolerance that can be set by this method transmitted as a parameter, currently is read.maxprecision.value.
+When a self-intersection of one edge is found, it is fixed by one of the two methods:
+ * tolerance of the vertex of that edge which is nearest to the point of self-intersection is increased so that it comprises both its own old position and the intersection point
+ * the self-intersecting loop on the pcurve is cut out and a new pcurve is constructed. This can increase the tolerance of the edge.
+The method producing a smaller tolerance is selected.
+When an intersection of two adjacent edges is detected, edges are cut at that point. Tolerance of the common vertex of these edges is increased in order to comprise both the intersection point and the old position.
+This method can increase the tolerance of the vertex up to a value of read.maxprecision.value.
+2. ShapeFix_Wire::FixLacking()
+This method is intended to detect gaps between pcurves of adjacent edges (with the precision of surface UVResolution computed from tolerance of a corresponding vertex) and to fix these gaps either by increasing the tolerance of the vertex, or by inserting a new degenerated edge (straight in parametric space).
+If it is possible to compensate a gap by increasing the tolerance of the vertex to a value of less than the initial value of tolerance, the tolerance of the vertex is increased. Else, if the vertex is placed in a degenerated point then a degenerated edge is inserted.
+3. ShapeFix_Wire::FixConnected()
+This method is intended to force two adjacent edges in the wire to share the same vertex. This method can increase the tolerance of the vertex. The maximal value of tolerance is read.maxprecision.value.
+@subsection occt_1624647986_248980126 Code architecture
+@subsubsection occt_1624647986_2489801261 List of the classes
+<h4>package STEPControl </h4>
+STEPControl_Reader
+STEPControl_ActorRead
+<h4>package StepToTopoDS </h4>
+StepToTopoDS_Builder
+StepToTopoDS_MakeTransformed
+StepToTopoDS_TranslateShell
+StepToTopoDS_TranslateFace
+StepToTopoDS_TranslateEdgeLoop
+StepToTopoDS_TranslatePolyLoop
+StepToTopoDS_TranslateVertexLoop
+StepToTopoDS_TranslateEdge
+StepToTopoDS_TranslateVertex
+<h4>package StepToGeom </h4>
+StepToGeom_MakeCartesianPoint
+StepToGeom_MakeCurve
+StepToGeom_MakeLine
+StepToGeom_MakeSurface
+For more information refer to CDL.
+@subsubsection occt_1624647986_2489801262 API classes
+<h4>package STEPControl </h4>
+ STEPControl_Controller
+ STEPControl_Reader
+ STEPControl_ActorRead
+
+For a description of these classes refer to the chapter 4. API for reading/writing STEP.
+@subsubsection occt_1624647986_2489801263 Graph of calls
+The following diagram illustrates the structure of calls in reading STEP.
+
+
+@subsection occt_1624647986_248980127 Example
+#include STEPControl_Reader.hxx
+#include TopoDS_Shape.hxx
+#include BRepTools.hxx
+
+Standard_Integer main()
+{
+ STEPControl_Reader reader;
+ reader.ReadFile(;MyFile.stp;);
+
+ // Loads file MyFile.stp
+ Standard_Integer NbRoots = reader.NbRootsForTransfer();
+
+ // gets the number of transferable roots
+ cout;Number of roots in STEP file: ; NbRootsendl;
+
+ Standard_Integer NbTrans = reader.TransferRoots();
+ // translates all transferable roots, and returns the number of //successful translations
+ cout;STEP roots transferred: ; NbTransendl;
+ cout;Number of resulting shapes is: ;reader.NbShapes()endl;
+
+ TopoDS_Shape result = reader.OneShape();
+ // obtain the results of translation in one OCCT shape
+
+ . . .
+
+}
+
+@section occt_1624647986_604379675 Writing STEP
+@subsection occt_1624647986_6043796751 Procedure
+You can translate OCCT shapes into STEP entities in the following steps:
+ 1.initialize the process,
+ 2.set the translation parameters,
+ 3.perform the shape translation,
+ 4.write the output file.
+You can translate several shapes before writing a file. All these translations output a separate shape_representation entity in STEP file.
+The user-defined option (parameter ;write.step.schema;) is provided to define which version of schema (AP214 CD or DIS, or AP203) is used for the output STEP file.
+@subsection occt_1624647986_6043796752 Domain covered
+@subsubsection occt_1624647986_60437967521 Writing geometry and topology
+There are two families of OCCT objects that can be translated:
+ * geometrical objects,
+ * topological shapes.
+@subsubsection occt_1624647986_60437967522 Writing assembly structures
+The shapes organized in a structure of nested compounds can be translated either as simple compound shapes, or into the assembly structure, depending on the parameter ;write.step.assembly;, which is described below.
+
+The assembly structure placed in the produced STEP file corresponds to the structure described in the ProSTEP Agreement Log (item 21) as the second alternative (assembly structure through representation_relationship / item_defined_transformation). To represent an assembly it uses entities of the representation_relationship_with_transformation type. Transformation operators used for locating assembly components are represented by item_defined_transformation entities.
+If mode ;write.step.assembly; is set to the values ON or Auto then an OCC shape consisting of nested compounds will be written as an assembly, otherwise it will be written as separate solids.
+
+Please see also the sub-chapter ;Mapping OCCT shapes to STEP entities;.
+@subsection occt_1624647986_6043796753 Description of the process
+@subsubsection occt_1624647986_60437967531 Initializing the process
+Before performing any other operation you have to create a writer object:
+STEPControl_Writer writer;
+@subsubsection occt_1624647986_60437967532 Setting the translation parameters
+The following parameters are used for the OCCT-to-STEP translation.
+<h4>write.precision.mode</h4>
+writes the precision value.
+;Least; (-1) : the uncertainty value is set to the minimum tolerance of an OCCT shape
+;Average; (0) : the uncertainty value is set to the average tolerance of an OCCT shape.
+;Greatest; (1) : the uncertainty value is set to the maximum tolerance of an OCCT shape
+;Session; (2) : the uncertainty value is that of the write.precision.val parameter.
+Read this parameter with:
+Standard_Integer ic = Interface_Static::IVal(;write.precision.mode;);
+Modify this parameter with:
+if(!Interface_Static::SetIVal(;write.precision.mode;,1))
+.. error ..
+Default value is 0.
+<h4>write.precision.val</h4>
+a user-defined precision value. This parameter gives the uncertainty for STEP entities constructed from OCCT shapes when the write.precision.mode parameter value is 1.
+ * 0.0001: default
+ * any real positive (non null) value.
+This value is stored in shape_representation in a STEP file as an uncertainty.
+Read this parameter with:
+Standard_Real rp = Interface_Static::RVal(;write.precision.val;);
+Modify this parameter with:
+if(!Interface_Static::SetRVal(;write.precision.val;,0.01))
+.. error ..
+Default value is 0.0001.
+<h4>write.step.assembly</h4>
+writing assembly mode.
+0 (Off) : (default) writes STEP files without assemblies.
+1 (On) : writes all shapes in the form of STEP assemblies.
+2 (Auto) : writes shapes having a structure of (possibly nested) TopoDS_Compounds in the form of STEP assemblies, single shapes are written without assembly structures.
+Read this parameter with:
+Standard_Integer rp = Interface_Static::IVal(;write.step.assembly;);
+Modify this parameter with:
+if(!Interface_Static::SetIVal(;write.step.assembly;,1))
+.. error ..
+Default value is 0.
+<h4>write.step.schema</h4>
+defines the version of schema used for the output STEP file:
+ 1 or ;AP214CD; (default): AP214, CD version (dated 26 November 1996),
+ 2 or ;AP214DIS;: AP214, DIS version (dated 15 September 1998).
+ 3 or ;AP203;: AP203, possibly with modular extensions (depending on data written to a file).
+ 4 or *AP214IS*: AP214, IS version (dated 2002)
+This parameter affects the following entities written to the STEP file:
+
+
+
+In addition, in AP203 mode more product and organizational entities are generated (entities like PERSON_AND_ORGANIZATION, SECURITY_CLASSIFICATION etc., as required by AP203).
+Read this parameter with:
+TCollection_AsciiString schema = Interface_Static::CVal(;write.step.schema;);
+Modify this parameter with:
+if(!Interface_Static::SetCVal(;write.step.schema;,;DIS;))
+.. error ..
+Default value is 1 (;CD;).
+For the parameter ;write.step.schema; to take effect, method STEPControl_Writer::Model(Standard_True) should be called after changing this parameter (corresponding command in DRAW is ;newmodel;).
+<h4>write.step.product.name</h4>
+Defines the text string that will be used for field ‘name’ of PRODUCT entities written to the STEP file.
+Default value: *OCCT STEP translator 6.1* (the 6.1 stands for Open CASCADE Technology version number).
+<h4>write.surfacecurve.mode</h4>
+This parameter indicates whether parametric curves (curves in parametric space of surface) should be written into the STEP file. This parameter can be set to Off in order to minimize the size of the resulting STEP file.
+Off (0) : writes STEP files without pcurves. This mode decreases the size of the resulting STEP file .
+On (1) : (default) writes pcurves to STEP file
+Read this parameter with:
+Standard_Integer wp = Interface_Static::IVal(;write.surfacecurve.mode;);
+Modify this parameter with:
+if(!Interface_Static::SetIVal(;write.surfacecurve.mode;,1))
+.. error ..
+Default value is On.
+<h4>write.step.unit</h4>
+Defines a unit in which the STEP file should be written. If set to unit other than MM, the model is converted to these units during the translation.
+Default value is MM.
+<h4>write.step.resource.name</h4>
+<h4>write.step.sequence</h4>
+These two parameters define the name of the resource file and the name of the sequence of operators (defined in that file) for Shape Processing, which is automatically performed by the STEP translator before translating a shape to a STEP file. Shape Processing is a user-configurable step, which is performed before the translation and consists in applying a set of operators to a resulting shape. This is a very powerful tool allowing customizing the shape and adapting it to the needs of a receiving application. By default the sequence consists of two operators: SplitCommonVertex and DirectFaces, which convert some geometry and topological constructs valid in Open CASCADE Technology but not in STEP to equivalent definitions conforming to STEP format.
+See description of parameter read.step.resource.name above for more details on using resource files.
+Default values: read.step.resource.name - STEP, read.step.sequence - ToSTEP.
+@subsubsection occt_1624647986_60437967533 Performing the Open CASCADE Technology shape translation
+An OCCT shape can be translated to STEP using one of the following models (shape_representations):
+ * manifold_solid_brep (advanced_brep_shape_representation)
+ * brep_with_voids (advanced_brep_shape_representation)
+ * faceted_brep (faceted_brep_shape_representation)
+ * shell_based_surface_model (manifold_surface_shape_representation)
+ * geometric_curve_set (geometrically_bounded_wireframe_shape_representation)
+The enumeration **STEPControl_StepModelType** is intended to define a particular transferring model.
+The following values of enumeration are allowed:
+
+The following table shows which shapes can be translated in which mode:
+If TopoDS_Compound contains any other types besides the ones mentioned in the table, these sub-shapes will be ignored.
+In case if an OCCT shape cannot be translated according to its mode the result of translation is void.
+For further information see *Mapping Open CASCADE Technology shapes to STEP entities* below.
+STEP214Control_StepModelTope mode = STEP214Control_ManifoldSolidBrep;
+IFSelect_ReturnStatus stat = writer.Transfer(shape,mode);
+@subsubsection occt_1624647986_60437967534 Writing the STEP file
+Write the STEP file with:
+IFSelect_ReturnStatus stat = writer.Write(;filename.stp;);
+to give the file name.
+@subsection occt_1624647986_6043796754 Mapping Open CASCADE Technology shapes to STEP entities
+Only STEP entities that have a corresponding OCCT object and mapping of assembly structures are described in this paragraph. For a full list of STEP entities please refer to Appendix A.
+@subsubsection occt_1624647986_60437967541 Assembly structures and product information
+The assembly structures are written to the STEP file if parameter write.step.assembly is 1 or 2.
+Each TopoDS_Compound is written as an assembly with subshapes of that compound being components of the assembly. The structure of nested compounds is translated to the structure of nested assemblies. Shared subshapes are translated into shared components of assemblies. Shapes that are not compounds are translated into subtypes of shape_representation according to their type (see the next subchapter for details).
+A set of STEP entities describing general product information is written to the STEP file together with the entities describing the product geometry, topology and assembly structure. Most of these entities are attached to the entities being subtypes of shape_representation, but some of them are created only one per STEP file.
+The table below describes STEP entities, which are created when the assembly structure and product information are written to the STEP file, and shows how many of these entities are created. Note that the appearance of some of these entities depends on the version of the schema (AP214, CD, DIS or IS, or AP203).
+
+@subsubsection occt_1624647986_60437967542 Topological shapes
+
+@subsubsection occt_1624647986_60437967543 Geometrical objects
+
+
+@subsection occt_1624647986_6043796755 Tolerance management
+There are four possible values for the uncertainty when writing a STEP file:
+ * user-defined value of the uncertainty
+ * minimal value of sub-shapes tolerances
+ * average value of sub-shapes tolerances
+ * maximal value of sub-shapes tolerances
+The chosen value of the uncertainty is the final value that will be written into the STEP file.
+See parameter write.precision.mode.
+@subsection occt_1624647986_6043796756 Code architecture
+@subsubsection occt_1624647986_60437967561 List of the classes
+<h4>package STEPControl </h4>
+STEPControl_Controller
+STEPControl_Writer
+STEPControl_ActorWrite
+<h4>package TopoDSToStep</h4>
+TopoDSToStep_Builder
+TopoDSToStep_WireframeBuilder
+TopoDSToStep_MakeBrepWithVoids
+TopoDSToStep_MakeFacetedBrep
+TopoDSToStep_MakeFacetedBrepAndBrepWithVoids
+TopoDSToStep_MakeGeometricCurveSet
+TopoDSToStep_MakeManifoldSolidBrep
+TopoDSToStep_MakeShellBasedSurfaceModel
+TopoDSToStep_FacetedTool
+TopoDSToStep_MakeStepFace
+TopoDSToStep_MakeStepWire
+TopoDSToStep_MakeStepEdge
+TopoDSToStep_MakeStepVertex
+<h4>package GeomToStep </h4>
+GeomToStep_MakeCartesianPoint
+GeomToStep_MakeCurve
+GeomToStep_MakePolyline
+GeomToStep_MakeSurface
+For more information refer to CDL.
+@subsubsection occt_1624647986_60437967562 API classes
+<h4>package STEPControl </h4>
+STEPControl_Controller
+STEPControl_Writer
+STEPControl_ActorWrite
+
+For a description of these classes refer to the chapter 4. API for reading/writing STEP.
+@subsubsection occt_1624647986_60437967563 Graph of calls
+The following diagram illustrates the structure of calls in writing STEP.
+The highlighted classes are intended to translate geometry.
+
+
+
+ <table>
+ <tr>
+ <td>
+
+ </td>
+ </tr>
+ <tr>
+ <td>
+
+ </td>
+ <td>
+ 
+ </td>
+ </tr>
+</table>
+@subsection occt_1624647986_6043796757 Example
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+#include STEPControl.hxx
+#include STEPControl_Writer.hxx
+#include TopoDS_Shape.hxx
+#include BRepTools.hxx
+#include BRep_Builder.hxx
+
+Standard_Integer main()
+{
+TopoDS_Solid source;
+. . .
+
+STEPControl_Writer writer;
+writer.Transfer(source, STEPControl_ManifoldSolidBrep);
+
+// Translates TopoDS_Shape into manifold_solid_brep entity
+writer.Write(;Output.stp;);
+// writes the resulting entity in the STEP file
+
+}
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+@section occt_1624647986_1430038387 API for reading/writing STEP
+@subsection occt_1624647986_14300383871 Overview
+This chapter contains a description of packages, which provide API for translating OCCT shapes into STEP files and vice versa.
+Package STEPControl provides API for reading and writing STEP files. This package deals with OCCT shapes. It includes five API classes:
+ * STEPControl_Controller - for initializing the STEP norm,
+ * STEPControl_Reader - for reading STEP files,
+ * STEPControl_Writer - for writing STEP files,
+ * STEPControl_ActorRead - actor which performs translation of a STEP entity into an OCCT shape,
+ * STEPControl_ActorWrite – actor, which performs translation of an OCCT shape into a STEP entity.
+@subsection occt_1624647986_14300383872 Package STEPControl
+@subsubsection occt_1624647986_143003838721 General description
+This package provides tools to translate STEP entities to OCCT shapes and vice versa.
+STEP AP 214 and AP 203 entities can be read and translated.
+File that is produced by this component conforms to either STEP AP214 (CD, DIS or IS version) or AP203 schema, according to parameter write.step.schema.
+The result of importing a STEP file is an OCCT shape. The result of exporting an OCCT geometrical or topological object is a STEP file that conforms to AP 214 or AP203.
+The package contains the following classes:
+class STEPControl_Controller
+class STEPControl_Reader
+class STEPControl_Writer
+class STEPControl_ActorRead
+class STEPControl_ActorWrite
+@subsubsection occt_1624647986_143003838722 Enumeration STEPControl_StepModelType
+enum STEPControl_StepModelType {
+STEPControl_AsIs,
+STEPControl_ManifoldSolidBrep,
+STEPControl_BrepWithVoids,
+STEPControl_FacetedBrep,
+STEPControl_FacetedBrepAndBrepWithVoids,
+STEPControl_ShellBasedSurfaceModel,
+STEPControl_GeometricCurveSet,
+STEPControl_Hybrid
+}
+Purpose: This enumeration is intended to define a particular transferring model for writing STEP. The following values of enumeration are allowed:
+
+@subsubsection occt_1624647986_143003838723 Class STEPControl_Controller
+<h4>General description</h4>
+This class is intended to provide an appropriate initialization of the STEP norm, namely it includes a set of necessary parameters for STEP translation.
+After completing the initialization the STEP norm can be used.
+Inheritance
+XSControl_Controller
+MMgt_TShared
+Standard_Trancient
+
+<h4>Methods</h4>
+<h5>Constructors</h5>
+ * STEPControl_Controller();
+Purpose: Initializes the use of the STEP norm in the first call. Creates an object with default parameters.
+<h5>Method for performing initialization </h5>
+ * STEPControl_Controller::Init
+static Standard_Boolean Init();
+Purpose: Performs standard initialization creating a controller object for the STEP norm. Returns True.
+<h5>Method for creating a STEP Model object </h5>
+ * STEPControl_Controller::NewModel
+Handle_Interface_InterfaceModel NewModel() const;
+Purpose: Creates a new empty model ready to receive data of the STEP norm. Sets the Header of the model to default values from the STEP template).
+.
+<h5>Method for getting the actor object</h5>
+ * STEPControl_Controller::ActorRead
+Handle_Transfer_ActorOfTransientProcess ActorRead(
+const Handle(Interface_InterfaceModel)& model) const;
+Purpose: Returns the actor object for reading (actually, it is of the type STEPControl_ActorRead).
+<h5>Method for translating an Open CASCADE Technology shape </h5>
+ * STEPControl_Controller::TransferWriteShape
+virtual IFSelect_ReturnStatus TransferWriteShape(const TopoDS_Shape& shape,
+const Handle(Transfer_FinderProcess)& FP,
+const Handle(Interface_InterfaceModel)& model,
+const Standard_Integer modetrans = 0) const;
+Purpose: Translates an OCCT shape into a STEP entity and adds it to the interface model model. modetrans defines the type of the resulting STEP entity:
+0 - autodetect according to the type of the shape.
+1 - faceted_brep
+2 - shell_based_surface_model
+3 - manifold_solid_brep
+4 - geometric_curve_set
+Returns:
+ IFSelect_RetDone: OK
+ IFSelect_RetError: if modetrans is not equal to 0,1,2,3,4, or model is not a STEP one.
+ IFSelect_Fail: if result is null.
+@subsubsection occt_1624647986_143003838724 Class STEPControl_Reader
+<h4>General description</h4>
+This high level class performs the reading of a STEP file and translating its contents into an OCCT shape. Only geometrical and topological entities conformant to the STEP AP 214 and the AP 203 formats can be translated into OCCT shapes. The result of translation is an OCCT topological shape.
+Inheritance
+XSControl_Reader
+This class complements the XSControl_Reader class (deals directly with WorkSession object).
+<h4>Methods</h4>
+<h5>Constructors </h5>
+STEPControl_Reader();
+Purpose: Creates a reader and initializes a new controller with the help of STEPControl_Controller::Init().
+STEPControl_Reader( const Handle(XSControl_WorkSession)& WS,
+const Standard_Boolean scratch = Standard_True);
+Purpose: Creates a reader and defines its work session. If scratch is true the method sets a new interface model.
+<h5>Method for dealing with STEP Model </h5>
+ * STEPControl_Reader::StepModel
+Handle_StepData_StepModel StepModel() const;
+Purpose: Returns a STEP Model.
+<h5>Method for performing translation </h5>
+ * STEPControl_Reader::TransferRoot
+Standard_Boolean TransferRoot(const Standard_Integer num = 1)
+Purpose: Translates a STEP root specified by its rank. Performs translation with the help of method XSControl_Reader::TransferOneRoot.
+@subsubsection occt_1624647986_143003838725 Class STEPControl_Writer
+<h4>General description</h4>
+This class is intended to create and write a file compliant to STEP AP 214 or to AP203 out of OCCT shapes. The file produced by this component conforms to STEP AP214 or AP203. This component gives a possibility to write a STEP file containing the following models (shape_representations):
+ faceted_brep
+ shell_based_surface_model
+ manifold_solid_brep
+ geometric_curve_set
+The write mode is selected by specifying the appropriate parameter.
+Export into a STEP file can be performed on the basis of either an already existing STEP model (its representation in the memory) or a new one.
+The translation of OCCT shapes (which can be a 2D or a 3D geometrical or topological object) into a STEP file is fulfilled in the following steps:
+ * Setting the translation parameters
+ * The translation. It can be performed in one or several operations. Each operation defines a root in the STEP file.
+ * Writing the STEP file. The output file is specified by its name.
+<h4>Methods</h4>
+<h5>Constructors </h5>
+STEPControl_Writer();
+Purpose: Creates a writer, initializes a default STEPControl_Controller and sets a new work session.
+STEPControl_Writer( const Handle(XSControl_WorkSession)& WS,
+const Standard_Boolean scratch = Standard_True);
+Purpose: Creates a writer, initializes a default STEPControl_Controller with an already existing WorkSession object. If scratch if True, this method clears the already recorded data.
+<h5>Methods for dealing with the uncertainty value </h5>
+ * STEPControl_Writer::SetTolerance
+void SetTolerance(const Standard_Real Tol) ;
+Purpose: Sets the value of tolerance, which will be written into a file as a value of uncertainty.
+ * STEPControl_Writer::UnsetTolerance
+void UnsetTolerance() ;
+Purpose: Unsets the tolerance set by method SetTolerance. The value of uncertainty will be then calculated as an average tolerance of the OCCT shape.
+<h5>Methods for dealing with a WorkSession object</h5>
+ * STEPControl_Writer::SetWS
+void SetWS( const Handle(XSControl_WorkSession)& WS,
+const Standard_Boolean scratch = Standard_True) ;
+Purpose: Sets an existing WorkSession WS.
+ * STEPControl_Writer::WS
+Handle_XSControl_WorkSession WS() const;
+Purpose: Returns a current WorkSession object.
+<h5>Method for obtaining a model object </h5>
+ * STEPControl_Writer::Model
+Handle_StepData_StepModel Model(
+const Standard_Boolean newone = Standard_False) ;
+Purpose: Returns a produced Model. Produces a new one if such is not yet produced or if newone is True.
+<h5>Method for performing the transfer process </h5>
+ * STEPControl_Writer::Transfer
+IFSelect_ReturnStatus Transfer( const TopoDS_Shape& sh,
+const STEPControl_StepModelType mode) ;
+Purpose: Translates a shape sh to STEP entities. Allowed modes are:
+STEPControl_AsIs to select the resulting entity type automatically, according to the type of the OCCT shape to translate it into its highest possible model,
+STEPControl_ManifoldSolidBrep to translate into manifold_solid_brep or brep_with_voids,
+STEPControl_ShellBasedSurfaceModel to translate into shell_based_surface_model,
+STEPControl_FacetedBrep to translate into faceted_brep,
+STEPControl_GeometricCurveSet to translate into geometric_curve_set.
+Returns the transfer status (see Controller from STEPControl)
+<h5>Method for creating a STEP file </h5>
+ * STEPControl_Writer::Write
+IFSelect_ReturnStatus Write(const Standard_CString filename) ;
+Purpose: Writes a model into the file filename. Performs this operation with the help of method XSControl_WorkSession::SendAll.
+<h5>Method for obtaining statistics</h5>
+ * STEPControl_Writer::PrintStatsTransfer
+void PrintStatsTransfer( const Standard_Integer what,
+const Standard_Integer mode = 0) const;
+Purpose: Intended to display all statistics on the last translation performed. Calls method XSControl_TransferWriter::PrintStats.
+@subsubsection occt_1624647986_143003838726 Class STEPControl_ActorRead
+<h4>General description</h4>
+This class is intended for translation of AP214 and AP203 entities of the following types:
+ faceted_brep
+ brep_wiht_voids
+ manifold_solid_brep
+ shell_based_surface_model
+ geometric_curve_set
+ mapped_item
+ face_surface
+It can also translate assembly structures, shape_definition_representation and shape_representation referencing to the mentioned entities.
+The result of translation is Transfer Binder with the resulting OCCT shape.
+Inheritance
+Transfer_ActorOfTransientProcess
+Transfer_ActorOfProcessForTransient
+MMgt_TShared
+Standard_Trancient
+<h4>Methods</h4>
+<h5>Constructor</h5>
+STEPControl_ActorRead();
+Purpose: Empty constructor.
+<h5>Method for recognizing entities </h5>
+ * STEPControl_ActorRead::Recognize
+virtual Standard_Boolean Recognize(
+const Handle(Standard_Transient)& start) ;
+Purpose: Returns True if entity start can be translated by this Actor class, i.e. if entity type is one of the types listed above.
+<h5>Method for performing translation </h5>
+ * STEPControl_ActorRead::Transfer
+virtual Handle_Transfer_Binder Transfer(
+const Handle(Standard_Transient)& start,
+const Handle(Transfer_TransientProcess)& TP) ;
+Purpose: Performs access to transferable entities and translates them with the help of the class StepToTopoDS_Builder. Sets translation parameters with the help of method PrepareUnits.
+ * STEPControl_ActorRead::PrepareUnits
+void PrepareUnits( const Handle(Standard_Transient)& start,
+const Handle(Transfer_TransientProcess)& TP) ;
+Purpose: If start is shape_definition_representation or shape_repesentation entity, this method sets the length and plane angle units taken from entity for performing translation. Sets the tolerance value to uncertainty if read.precision.mode is ;File;.
+@subsubsection occt_1624647986_143003838727 Class STEPControl_ActorWrite
+<h4>General description</h4>
+This class provides an actor for performing the translation of OCCT shapes to STEP AP203 or AP214 entities according to the write mode and schema version (CD , DIS or IS).
+An OCCT shape can be translated to STEP using one of the following models (shape_representations):
+ manifold_solid_brep (advanced_brep_shape_representation)
+ brep_with_voids (advanced_brep_shape_representation)
+ faceted_brep (faceted_brep_shape_representation)
+ shell_based_surface_model (manifold_surface_shape_representation)
+ geometric_curve_set (geometrically_bounded_wireframe_shape_representation)
+During the translation the actor computes the uncertainty value to be applied to the resulting model (shape_representation).
+This actor also writes STEP assembly structures (according to group mode, which is initialised by the value of parameter write.step.assembly).
+This parameter is used to create a STEP entity with or without assemblies. If write.step.assembly is 1, assemblies are created, if it is 0 assemblies are not created. If it is 2, assemblies are created for compound shapes containing more than one component.
+The transfer mode is enumeration STEPControl_StepModeType, which defiles the resulting model.
+Inheritance
+Transfer_ActorOfFinderProcess
+Transfer_ActorOfProcessForFinder
+MMgt_TShared
+Standard_Transient
+<h4>Methods</h4>
+<h5>Constructors </h5>
+STEPControl_ActorWrite();
+Purpose: Sets the write mode to shell_based_surface_model, group mode to 0 and the default value for the uncertainty that will be computed as an average tolerance for each shape.
+<h5>Method for setting and obtaining translation parameters: </h5>
+ * STEPControl_ActorWrite::SetMode
+void SetMode(const STEPControl_StepModelType M) ;
+Purpose: Sets the write mode. M can be of the following values:
+STEPControl_AsIs to select the resulting entity type automatically, according to the type of OCCT shape to translate it into its highest possible model,
+STEPControl_ManifoldSolidBrep to translate into manifold_solid_brep or brep_with_voids,
+STEPControl_ShellBasedSurfaceModel to translate into shell_based_surface_model,
+STEPControl_FacetedBrep to translate into faceted_brep,
+STEPControl_GeometricCurveSet to translate into geometric_curve_set.
+ * STEPControl_ActorWrite::Mode
+STEPControl_StepModelType Mode();
+Purpose: Returns the write mode.
+ * STEPControl_ActorWrite::SetGroupMode
+void SetGroupMode(const Standard_Integer mode) ;
+Purpose. Sets the group mode, which determines whether assemblies should be created or not. mode can be one of the following values:
+0 - result of translating OCCT shape does not contain assemblies,
+1 - result of translating OCCT shape contains assemblies,
+1 - result of translating OCCT shape can either contain assemblies or not, depending on the original shape.
+ * STEPControl_ActorWrite::GroupMode
+Standard_Integer GroupMode() const;
+Purpose: Returns the group mode.
+ * STEPControl_ActorWrite::SetTolerance
+void SetTolerance(const Standard_Real Tol) ;
+Purpose: Sets the value of uncertainty for STEP entities. If Tol is more than zero, then Tol will be taken as an uncertainty, if Tol is less than the zero value of the uncertainty it will be calculated as an average tolerance of the shape.
+<h5>Method for recognizing entities </h5>
+ * STEPControl_ActorWrite::Recognize
+virtual Standard_Boolean Recognize(const Handle(Transfer_Finder)& start) ;
+Purpose. Checks whether a shape can be translated into a STEP entity according to a defined model. This method returns True if the shape referenced by start can be translated and False if it cannot.
+TopoDS_Solid, TopoDS_Shell can be translated into manifold_solid_brep.
+TopoDS_Solid can be translated into brep_with_voids.
+TopoDS_Solid can be translated into faceted_brep if all its surfaces are planes and all its curves are lines.
+TopoDS_Solid, TopoDS_Shell, TopoDS_Face can be translated into shell_based_surface_model.
+Any OCCT shape can be translated into geometric_curve_set.
+<h5>Method for performing the translation</h5>
+ * STEPControl_ActorWrite::Transfer
+virtual Handle_Transfer_Binder Transfer(
+const Handle(Transfer_Finder)& start,
+const Handle(Transfer_FinderProcess)& FP) ;
+Purpose: Translates a single OCCT shape referenced by start into a STEP entity according to the tolerance, the write mode and the group mode.
+Performs translation with the help of package TopoDSToStep and its Make... classes. Returns the transfer binder.
+See also: Package TopoDSToStep, classes TopoDSToStep_Make...
+@subsection occt_1624647986_14300383873 Package STEPConstruct
+@subsubsection occt_1624647986_143003838731 General description
+This package defines tools for creation and investigation of specific STEP constructs used for representing various kinds of data, such as product and assembly structure, unit contexts, and associated information. These structures are created according to the current schema (AP203, AP214 CD2, DIS or IS), which is defined by the parameter write.step.schema.
+The package contains the following classes:
+class STEPConstruct_Styles
+class STEPConstruct_Part
+@subsubsection occt_1624647986_143003838732 Class STEPConstruct_Styles
+<h4>General description</h4>
+This class provides a mechanism for reading and writing shape styles (such as color) to and from a STEP file. This tool maintains a list of styles, either taking them from the STEP model (when reading), or filling it by calls to AddStyle or directly (for writing). Some methods deal with general structures of styles and presentations in STEP, but there are methods dealing with a particular implementation of colors (implemented in accordance with the ;Recommended Practices for colors and layers;).
+<h4>Methods</h4>
+<h5>Constructors </h5>
+STEPConstruct_Styles();
+Purpose: Empty constructor
+STEPConstruct_Styles(const Handle(XSControl_WorkSession)& WS);
+Purpose: Creates an object and calls Init
+<h5>Method for initializing the object </h5>
+ * STEPConstruct_Styles::Init
+Standard_Boolean Init(const Handle(XSControl_WorkSession)& WS) ;
+Purpose: Initializes a tool; returns True if succeeded. The XSControl_WorkSession object is used to access data
+<h5>Methods for dealing with styles </h5>
+ * STEPConstruct_Styles::NbStyles
+Standard_Integer NbStyles() const;
+Purpose: Returns the number of defined styles.
+ * STEPConstruct_Styles::Style
+Handle_StepVisual_StyledItem Style(const Standard_Integer i) const;
+Purpose: Returns a style with a given index
+ * STEPConstruct_Styles::ClearStyles
+void ClearStyles() ;
+Purpose: Clears all defined styles
+ * STEPConstruct_Styles::AddStyle
+void AddStyle(const Handle(StepVisual_StyledItem)& style) ;
+Purpose: Adds a style to a sequence (defines a style).
+ * STEPConstruct_Styles::AddStyle
+Handle_StepVisual_StyledItem AddStyle(
+const Handle(StepRepr_RepresentationItem)& item,
+const Handle(StepVisual_PresentationStyleAssignment)& PSA,
+const Handle(StepVisual_StyledItem)& Override) ;
+Purpose: Creates a style linking giving PSA (presentation_style_assignment) to the item, and adds it to the sequence of stored styles. If Override is not Null, then the resulting style will be of the subtype overriding_styled_item (else just simple styled_item).
+ * STEPConstruct_Styles::AddStyle
+Handle_StepVisual_StyledItem AddStyle( const TopoDS_Shape& Shape,
+const Handle(StepVisual_PresentationStyleAssignment)& PSA,
+const Handle(StepVisual_StyledItem)& Override) ;
+Purpose: Creates a style linking giving PSA (presentation_style_assignment) to the Shape, and adds it to the sequence of stored styles. If Override is not Null, then the resulting style will be of the subtype overriding_styled_item (else just simple styled_item). The Shape is used to find a corresponding STEP entity by call to STEPConstruct::FindEntity(), then the previous method is called.
+ * STEPConstruct_Styles::CreateMDGPR
+Standard_Boolean CreateMDGPR(const Handle(StepRepr_RepresentationContext)& Context) ;
+Purpose: Creates MDGPR (MECHANICAL_DESIGN_GEOMETRIC_PRESENTATION_ REPRESENTATION), fills it with all the styles previously defined, and adds it to the model.
+ * STEPConstruct_Styles::FindContext
+Handle_StepRepr_RepresentationContext FindContext(const TopoDS_Shape& Shape) const;
+Purpose: Searches the STEP model for the RepresentationContext in which given shape is defined. This context (if found) can be used then in call to CreateMDGPR()
+ * STEPConstruct_Styles::LoadStyles
+Standard_Boolean LoadStyles() ;
+Purpose: Searches the STEP model for the MDGPR (MECHANICAL_DESIGN_GEOMETRIC_ PRESENTATION_REPRESENTATION) or DM (draughting_model) entities (which bring styles) and reads styles from these entities, thus filling the sequence of styles.
+<h5>Methods for dealing with colors </h5>
+ * STEPConstruct_Styles::MakeColorPSA
+Handle_StepVisual_PresentationStyleAssignment MakeColorPSA(
+const Handle(StepRepr_RepresentationItem)& item,
+const Handle(StepVisual_Colour)& SurfCol,
+const Handle(StepVisual_Colour)& CurveCol) const;
+Purpose: Creates a presentation_style_assignment entity defining two colors (for filling surfaces and curves)
+ * STEPConstruct_Styles::GetColorPSA
+Handle_StepVisual_PresentationStyleAssignment GetColorPSA(
+const Handle(StepRepr_RepresentationItem)& item,
+const Handle(StepVisual_Colour)& Col) ;
+Purpose: Returns a PresentationStyleAssignment entity, which defines the surface and curve colors as Col. This PSA is either created or taken from the internal map where all PSAs are created by this method are remembered.
+ * STEPConstruct_Styles::GetColors
+Standard_Boolean GetColors(
+const Handle(StepVisual_StyledItem)& style,
+Handle(StepVisual_Colour)& SurfCol,
+Handle(StepVisual_Colour)& BoundCol,
+Handle(StepVisual_Colour)& CurveCol) const;
+Purpose: Extract color definitions from the style entity. For each type of color supported, the result can be either NULL if it is not defined by that style, or the last definition (if they are one or more)
+<h5>Methods for converting a STEP and Open CASCADE Technology color definition </h5>
+ * STEPConstruct_Styles::EncodeColor
+Handle_StepVisual_Colour EncodeColor(const Quantity_Color& Col) ;
+Purpose: Creates a STEP color entity from a given Quantity_Color. The analysis is performed for whether the color corresponds to the one of standard colors predefined in STEP. In that case, draughting_predefined_colour entity is created instead of rgb_colour.
+ * STEPConstruct_Styles::DecodeColor
+Standard_Boolean DecodeColor(const Handle(StepVisual_Colour)& Colour,Quantity_Color& Col) ;
+Purpose: Decodes STEP color and fills the Quantity_Color. Returns True if OK or False if color is not recognized
+@subsubsection occt_1624647986_143003838733 Class STEPConstruct_Part
+<h4>General description</h4>
+Provides tools for creating STEP structures associated with shape_definition_representation, such as product, product_definition_formation etc., as required by the current schema (parameter write.step.schema). Also allows investigating and modifying this data.
+<h4>Methods</h4>
+<h5>Constructors </h5>
+STEPConstruct_Part();
+Purpose: Empty constructor
+<h5>Methods for initializing and obtaining shape_definition_representation </h5>
+ * STEPConstruct_Part::MakeSDR
+void MakeSDR( const Handle(StepShape_ShapeRepresentation)& aShape,
+const Handle(TCollection_HAsciiString)& aName,
+const Handle(StepBasic_ApplicationContext)& AC) ;
+Purpose: Creates shape_definition_representation according to the currently active schema (AP203 or AP214 CD2, DIS or IS), which is taken from parameter write.step.schema. Creates all necessary product description entities as well.
+ * STEPConstruct_Part::ReadSDR
+void ReadSDR(const Handle(StepShape_ShapeDefinitionRepresentation)& aSDR) ;
+Purpose: Sets the current SDR (shape_definition_representation) to the specified shape_definition_ representation aSDR
+ * STEPConstruct_Part::SDRValue
+Handle_StepShape_ShapeDefinitionRepresentation SDRValue() const;
+Purpose: Returns the current SDR or Null if no SDR is set or created
+<h5>Method for obtaining the done status </h5>
+ * STEPConstruct_Part::IsDone
+Standard_Boolean IsDone() const;
+Purpose: Returns the done status
+<h5>Method for obtaining shape_representation </h5>
+ * STEPConstruct_Part::SRValue
+Handle_StepShape_ShapeRepresentation SRValue() const;
+Purpose: Returns used_representation from the current SDR or Null if not done
+<h5>Methods for dealing with product_context </h5>
+ * STEPConstruct_Part::PC
+Handle_StepBasic_ProductContext PC() const;
+Purpose: Returns the product_context associated with the current SDR
+ * STEPConstruct_Part::PCname
+Handle_TCollection_HAsciiString PCname() const;
+Purpose: Returns the Name of the product_context associated with the current SDR
+ * STEPConstruct_Part::PCdisciplineType
+Handle_TCollection_HAsciiString PCdisciplineType() const;
+Purpose: Returns the discipline type of the product_context associated with the current SDR
+ * STEPConstruct_Part::SetPCname
+void SetPCname(const Handle(TCollection_HAsciiString)& name) ;
+Purpose: Sets the Name of the product_context associated with the current SDR
+ * STEPConstruct_Part::SetPCdisciplineType
+void SetPCdisciplineType(const Handle(TCollection_HAsciiString)& label);
+Purpose: Sets the discipline type of the product_context associated with the current SDR
+<h5>Methods dealing with application_context </h5>
+ * STEPConstruct_Part::AC
+Handle_StepBasic_ApplicationContext AC() const;
+Purpose: Returns the application_context associated with the current SDR
+ * STEPConstruct_Part::ACapplication
+Handle_TCollection_HAsciiString ACapplication() const;
+Purpose: Returns the application of the application_context associated with the current SDR
+ * STEPConstruct_Part::SetACapplication
+void SetACapplication(const Handle(TCollection_HAsciiString)& text) ;
+Purpose: Sets the application of the application_context associated with the current SDR
+ * STEPConstruct_Part::PDC
+Handle_StepBasic_ProductDefinitionContext PDC() const;
+Purpose: Returns the product_definition_context associated with the current SDR
+ * STEPConstruct_Part::PDCname
+Handle_TCollection_HAsciiString PDCname() const;
+Purpose: Returns the name of the product_definition_context associated with the current SDR
+ * STEPConstruct_Part::PDCstage
+Handle_TCollection_HAsciiString PDCstage() const;
+Purpose: Returns the life cycle stage of the product_definition_context associated with the current SDR
+ * STEPConstruct_Part::SetPDCname
+void SetPDCname(const Handle(TCollection_HAsciiString)& label) ;
+Purpose: Sets the name of the product_definition_context associated with the current SDR
+ * STEPConstruct_Part::SetPDCstage
+void SetPDCstage(const Handle(TCollection_HAsciiString)& label) ;
+Purpose: Sets the life cycle stage of the product_definition_context associated with the current SDR
+<h5>Methods dealing with the product </h5>
+ * STEPConstruct_Part::Product
+Handle_StepBasic_Product Product() const;
+Purpose: Returns the product associated with the current SDR
+ * STEPConstruct_Part::Pid
+Handle_TCollection_HAsciiString Pid() const;
+Purpose: Returns ID of the product associated with the current SDR
+ * STEPConstruct_Part::Pname
+Handle_TCollection_HAsciiString Pname() const;
+Purpose: Returns the name of the product associated with the current SDR
+ * STEPConstruct_Part::Pdescription
+Handle_TCollection_HAsciiString Pdescription() const;
+Purpose: Returns the description of the product associated with the current SDR
+ * STEPConstruct_Part::SetPid
+void SetPid(const Handle(TCollection_HAsciiString)& id) ;
+Purpose: Sets ID of the product associated with the current SDR
+ * STEPConstruct_Part::SetPname
+void SetPname(const Handle(TCollection_HAsciiString)& label) ;
+Purpose: Sets the name of the product associated with the current SDR
+ * STEPConstruct_Part::SetPdescription
+void SetPdescription(const Handle(TCollection_HAsciiString)& text) ;
+Purpose: Sets the description of the product associated with the current SDR
+<h5>Methods dealing with product_definition_formation </h5>
+ * STEPConstruct_Part::PDF
+Handle_StepBasic_ProductDefinitionFormation PDF() const;
+Purpose: Returns the product_definition_formation associated with the current SDR
+ * STEPConstruct_Part::PDFid
+Handle_TCollection_HAsciiString PDFid() const;
+Purpose: Returns the ID of the product_definition_formation associated with the current SDR
+ * STEPConstruct_Part::PDFdescription
+Handle_TCollection_HAsciiString PDFdescription() const;
+Purpose: Returns the description of the product_definition_formation associated with the current SDR
+ * STEPConstruct_Part::SetPDFid
+void SetPDFid(const Handle(TCollection_HAsciiString)& id) ;
+Purpose: Sets the ID of the product_definition_formation associated with the current SDR
+ * STEPConstruct_Part::SetPDFdescription
+void SetPDFdescription(const Handle(TCollection_HAsciiString)& text) ;
+Purpose: Sets the description of the product_definition_formation associated with the current SDR
+<h5>Methods dealing with product_definition </h5>
+ * STEPConstruct_Part::PD
+Handle_StepBasic_ProductDefinition PD() const;
+Purpose: Returns the product_definition associated with the current SDR
+ * STEPConstruct_Part::PDdescription
+Handle_TCollection_HAsciiString PDdescription() const;
+Purpose: Returns the description of the product_definition associated with the current SDR
+ * STEPConstruct_Part::SetPDdescription
+void SetPDdescription(const Handle(TCollection_HAsciiString)& text) ;
+Purpose: Sets the description of the product_definition associated with the current SDR
+<h5>Methods dealing with product_definition_shape </h5>
+ * STEPConstruct_Part::PDS
+Handle_StepRepr_ProductDefinitionShape PDS() const;
+Purpose: Returns the product_definition_shape associated with the current SDR
+ * STEPConstruct_Part::PDSname
+Handle_TCollection_HAsciiString PDSname() const;
+Purpose: Returns the name of the product_definition_shape associated with the current SDR
+ * STEPConstruct_Part::PDSdescription
+Handle_TCollection_HAsciiString PDSdescription() const;
+Purpose: Returns the description of the product_definition_shape associated with the current SDR
+ * STEPConstruct_Part::SetPDSname
+void SetPDSname(const Handle(TCollection_HAsciiString)& label) ;
+Purpose: Sets the name of the product_definition_shape associated with the current SDR
+ * STEPConstruct_Part::SetPDSdescription
+void SetPDSdescription(const Handle(TCollection_HAsciiString)& text) ;
+Purpose: Sets the description of the product_definition_shape associated with the current SDR
+<h5>Methods dealing with product_related_product_category </h5>
+ * STEPConstruct_Part::PRPC
+Handle_StepBasic_ProductRelatedProductCategory PRPC() const;
+Purpose: Returns the product_related_product_category associated with the current SDR
+ * STEPConstruct_Part::PRPCname
+Handle_TCollection_HAsciiString PRPCname() const;
+Purpose: Returns the name of the product_related_product_category associated with the current SDR
+ * STEPConstruct_Part::PRPCdescription
+Handle_TCollection_HAsciiString PRPCdescription() const;
+Purpose: Returns the description of the product_related_product_category associated with the current SDR
+ * STEPConstruct_Part::SetPRPCname
+void SetPRPCname(const Handle(TCollection_HAsciiString)& label) ;
+Purpose: Sets the name of the product_related_product_category associated with the current SDR
+ * STEPConstruct_Part::SetPRPCdescription
+void SetPRPCdescription(const Handle(TCollection_HAsciiString)& text) ;
+Purpose: Sets the description of the product_related_product_category associated with the current SDR
+@section occt_1624647986_383610185 Physical STEP file reading and writing
+The following paragraphs describe the loading of data from a physical STEP file into a STEP model and data writing from a STEP model to a STEP file.
+@subsection occt_1624647986_3836101851 Architecture of STEP Read and Write classes
+@subsubsection occt_1624647986_38361018511 General principles
+To perform data loading from a STEP file and to translate this data it is necessary to create correspondence between the EXPRESS schema and the structure of CDL classes. There are two possibilities to organize such correspondence: the so-called early binding and late binding.
+Late binding means that the processor works with a description of the schema. The processor builds a dictionary of entities and can recognize and read any entity that is described in the schema. To change the behavior and the scope of processor based on late binding it is enough to change the description of the schema. However, this binding has some disadvantages (for example low speed of reading process).
+In case of early binding, the structure of CDL classes is created beforehand with the help of a specific automatic tool or manually. If the processor finds an entity that is not found in this schema, it will simply be ignored. The processor calls constructors of appropriate classes and their read methods. To add a new type in the scope of the processor it is necessary to create a class corresponding to the new entity.
+The STEP processor is based on early binding principles. It means that specific classes for each EXPRESS type have been created with the help of an automatic tool from the EXPRESS schema. There are two CDL classes for each EXPRESS type. The first class (named the representing class) represents the STEP entity in memory. The second one (RW - class) is intended to perform the initialization of the representing class and to output data to an intermediate structure to be written in a STEP file.
+@subsubsection occt_1624647986_38361018512 Complex entities
+EXPRESS schema allows multiple inheritance. Entities that are built on the basis of multiple inheritance are called complex entities. Multiple inheritance is not available in CDL. EXPRESS enables any type of complex entities that can be inherited from any EXPRESS type. In the manner of early binding it is not possible to create a CDL class for any possible complex type. Thus, only widespread complex entities have corresponding representing classes and RW-classes that are created manually beforehand.
+@subsection occt_1624647986_3836101852 Physical file reading
+Physical file reading consists of the following steps:
+ 1.Loading a STEP file and syntactic analysis of its contents
+ 2.Mapping STEP entities to the array of strings
+ 3.Creating empty OCCT objects representing STEP entities
+ 4.Initializing OCCT objects
+ 5.Building a references graph
+@subsubsection occt_1624647986_38361018521 Loading a STEP file and syntactic analysis of its contents
+In the first phase, a STEP file is syntactically checked and loaded in memory as a sequence of strings.
+Syntactic check is performed on the basis of rules defined in step.lex and step.yacc files. Files step.lex and step.yacc are located in the StepFile nocdlpack development unit. These files describe text encoding of STEP data structure (for additional information see ISO 10303 Part 21). The step.lex file describes the lexical structure of the STEP file. It describes identifiers, numbers, delimiters, etc. The step.yacc file describes the syntactic structure of the file, such as entities, parameters, and headers.
+These files have been created only once and need to be updated only when norm ISO 10303-21 is changed.
+@subsubsection occt_1624647986_38361018522 Mapping STEP entities to arrays of strings
+For each entity specified by its rank number the arrays storing its identifier, STEP type and parameters are filled.
+@subsubsection occt_1624647986_38361018523 Creating empty Open CASCADE Technology objects that represent STEP entities
+For each STEP entity an empty OCCT object representing this entity is created. A map of correspondence between entity rank and OCCT object is created and filled out. If a STEP entity is not recognized by the STEP processor then the StepData_UndefinedEntity object is created.
+@subsubsection occt_1624647986_38361018524 Initializing Open CASCADE Technology objects
+Each OCCT object (including StepData_UndefinedEntity) is initialized by its parameters with the help of the appropriate RW - class. If some entity has another entity as its parameter, the object that represents the latter entity will be initialized immediately. All initialized objects are put into a special map to avoid repeated initialization.
+@subsubsection occt_1624647986_38361018525 Building a graph
+The final phase is building a graph of references between entities. For each entity its RW-class is used to find entities referenced by this entity. Back references are built on the basis of direct references. In addition to explicit references defined in the STEP entities some additional (implicit) references are created for entities representing assembly structures (links from assemblies to their components).
+@subsection occt_1624647986_3836101853 How to add a new entity in scope of the STEP processor
+If it is necessary to read and translate a new entity by the STEP processor the Reader and Actor scope should be enhanced. Note that some actions to be made for adding a new type are different for simple and complex types.
+The following steps should be taken:
+1. Create a CDL class representing a new entity. This can be the Stepxxx_NewEntity class where xxx currently are the following:
+ Basic
+ Geom
+ Shape
+ Visual
+ Repr
+ AP214
+ AP203
+Each field of a STEP entity should be represented by a corresponding field of this class. The class should have methods for initializing, setting and obtaining fields and it should also have the default constructor.
+2. Create the RWStepxxx_RWNewEntity class with a default constructor and methods ReadStep(), WriteStep() and if the entity references other entities, then method Share().
+3. Update file StepAP214_Protocol.cxx. In the constructor StepAP214_Protocol:: StepAP214_Protocol() add the new type to the map of registered types and associate the unique integer identifier with this type.
+4. Update file RWStepAP214_ReadWriteModule.cxx. The changes should be the following:
+ For simple types:
+ * Add a static object of class TCollection_AsciiString with name Reco_NewEntity and initialize it with a string containing the STEP type.
+ * In constructor RWStepAP214_ReadWriteModule::RWStepAP214_ReadWriteModule() add this object onto the list with the unique integer identifier of the new entity type.
+ * In function RWStepAP214_ReadWriteModule::StepType() add a new C++ case operator for this identifier.
+ For complex types:
+ * In the method RWStepAP214_ReadWriteModule::CaseStep() add a code for recognition the new entity type returning its unique integer identifier.
+ * In the method RWStepAP214_ReadWriteModule::IsComplex() return True for this type.
+ * In the method RWStepAP214_ReadWriteModule::ComplexType() fill the list of subtypes composing this complex type.
+ For both simple and complex types:
+ * In function RWStepAP214_ReadWriteModule::ReadStep() add a new C++ case operator for the new identifier and call the RWStepxxx_RWNewEntity class, method ReadStep to initialize the new class.
+5. Update file RWStepAP214_GeneralModule.cxx. Add new C++ case operators to functions NewVoid() and FillSharedCase(), and in the method CategoryNumber() add a line defining a category of the new type.
+6. Enhance the STEPControl_ActorRead class (methods Recognize() and Transfer()), or class(es) translating some entities, to translate the new entity into an OCCT shape.
+@subsection occt_1624647986_3836101854 Physical file writing
+Physical file writing consists of the following steps:
+ 1.Building a references graph
+ 2.Transferring data from a model to a sequence of strings
+ 3.Writing the sequence of strings into the file
+@subsubsection occt_1624647986_38361018541 Building a references graph
+Physical writing starts when STEP model, which was either loaded from a STEP file or created from OCCT shape with the help of translator, is available together with corresponding graph of references.
+During this step the graph of references can be recomputed.
+@subsubsection occt_1624647986_38361018542 Transferring data from the model to a sequence of strings
+For each representing entity from the model a corresponding RW - class is called. RW - class performs the writing of data that is contained in the representing class into an intermediate data structure. The mentioned structure is a sequence of strings in memory.
+@subsubsection occt_1624647986_38361018543 Writing the sequence of strings into the file
+The sequence of strings is written into the file. This is the last phase of physical STEP writing.
+@subsection occt_1624647986_3836101855 How to add a new entity to write in the STEP file.
+If it is necessary to write and translate an OCCT shape into a new entity by the STEP processor the Writer and Actor scope should be enhanced.
+For a description of steps, which should be taken for adding a new entity type to the STEP processor, see the previous chapter ;Physical file reading;. Then, enhance the STEPControl_ActorWrite class i.e. methods Recognize() and Transfer(), or other classes from TopoDSToStep, to translate the OCCT shape into a new STEP entity.
+@section occt_1624647986_1896912212 Using DRAW
+@subsection occt_1624647986_18969122121 DRAW STEP Commands Overview
+TKXSDRAW toolkit provides commands for testing XSTEP interfaces interactively in the DRAW environment. It provides an additional set of DRAW commands specific for data exchange tasks, which allows loading and writing data files and an analysis of the resulting data structures and shapes.
+This section is divided into five parts. Two of them deal with reading and writing a STEP file and are specific for the STEP processor. The first and the forth parts describe some general tools for setting parameters and analyzing the data. Most of them are independent of the norm being tested. Additionally, a table of mentioned DRAW commands is provided.
+In the description of commands, square brackets ([]) are used to indicate optional parameters. Parameters given in the angle brackets () and sharps (#) are to be substituted by an appropriate value. When several exclusive variants are possible, a vertical dash (|) is used.
+@subsection occt_1624647986_18969122122 Setting the interface parameters
+A set of parameters for importing and exporting STEP data is defined in the XSTEP resource file. In XSDRAW, these parameters can be viewed or changed using the command
+Draw: param [parameter_name [value]]
+Command param with no arguments gives a list of all parameters with their values. When the argument parameter_name is specified, information about this parameter is printed (current value and short description).
+The third argument is used to set a new value of the given parameter. The result of the setting is printed immediately.
+During all interface operations, the protocol of the process (fail and warning messages, mapping of loaded entities into OCCT shapes etc.) can be output to the trace file. Two parameters are defined in the DRAW session: trace level (integer value from 0 to 9, default is 0), and trace file (default is standard output).
+Command xtrace is intended to view and change these parameters:
+Draw: xtrace
+- prints current settings (e.g.: `Level=1 - Standard Output');
+Draw: xtrace #
+- sets trace level to the value #;
+Draw: xtrace tracefile.log
+- sets the trace file as tracefile.log; and
+Draw: xtrace .
+- directs all messages to the standard output.
+@subsection occt_1624647986_18969122123 Reading a STEP file
+For a description of parameters used in reading a STEP file refer to 2.3.3
+For reading a STEP file, the following parameters are defined (see above, the command param):
+It is possible either only to load a STEP file into memory (i.e. fill the *InterfaceModel* with data from the file), or to read it (i.e. load and convert all entities to OCCT shapes).
+Loading is done by the command
+Draw: xload file_name
+Once the file is loaded, it is possible to investigate the structure of the loaded data. To find out how you do it, look in the beginning of the analysis subsection.
+Reading a STEP file is done by the command
+Draw: stepread file_name result_shape_name [selection]
+Here a dot can be used instead of a filename if the file is already loaded by xload or stepread.
+The optional selection (see below for a description of selections) specifies a set of entities to be translated. If an asterisk `*' is given, all transferable roots are translated. If a selection is not given, the user is prompted to define a scope of transfer interactively:
+* root is an entity in the STEP file which is not referenced by another entities
+Second parameter of the stepread command defines the name of the loaded shape.
+During the STEP translation, a map of correspondence between STEP entities and OCCT shapes is created.
+To get information on the result of translation of a given STEP entity use the command
+Draw: tpent #
+is used.
+To create an OCCT shape, corresponding to a STEP entity, use the command
+Draw: tpdraw #
+is used.
+To get the number of a STEP entity, corresponding to an OCCT shape, use the command
+Draw: fromshape shape_name
+is used.
+To clear the map of correspondences between STEP entities and OCCT shapes the command
+Draw: tpclear
+is used.
+@subsection occt_1624647986_18969122124 Analyzing the data transferred
+The procedure of analysis of data import can be divided into two stages:
+ 1.to check the file contents,
+ 2.to estimate the translation results (conversion and validated ratios).
+@subsubsection occt_1624647986_189691221241 Checking file contents
+General statistics on the loaded data can be obtained by using the command
+Draw: data symbol
+Information printed by this command depends on the symbol specified:
+
+There is a set of special objects, which can be used to operate with a loaded model. They can be of the following types:
+A list of these objects defined in the current session can be printed in DRAW by command
+Draw: listitems
+Command
+Draw: givelist selection_name
+prints a list of a subset of loaded entities defined by the selection argument:
+
+
+The command listtypes gives a list of entity types, which were encountered in the last loaded file (with a number of STEP entities of each type).
+The list cannot be shown for all entities but for a subset of them. This subset is defined by an optional selection argument (for the list of possible values for STEP, see the table above).
+Two commands are used to calculate statistics on the entities in the model:
+Draw: count counter [selection]
+Draw: listcount counter [selection]
+The former only prints a count of entities while the latter also gives a list of them.
+The optional selection argument, if specified, defines a subset of entities, which are to be taken into account. The first argument should be one of the currently defined counters:
+Entities in the STEP file are numbered in the succeeding order. An entity can be identified either by its number or by its label. Label is the letter `#' followed by the rank. To get a label for an entity with a known number, command
+Draw: elab #
+can be used.
+In the same way, command
+Draw: enum #
+prints a number for the entity with a given label.
+The contents of a STEP entity can be obtained by command
+Draw: entity # level_of_information
+The list of entities referenced by a given entity and the list of entities referencing to it can be obtained by command
+Draw: estat #
+A STEP assembly can be printed as a tree using the following DRAW command:
+Draw: dumpassembly
+Information about product names, next_assembly_usage_occurence, shape_definition_representation, context_dependent_shape_representation or mapped_item entities that are involved into the assembly structure will be printed.
+@subsubsection occt_1624647986_189691221242 Estimating the results of reading STEP
+All the following commands are available only after data is converted into OCCT shapes (i.e. after command 214read).
+Command
+Draw: tpstat [*|?]symbol [selection]
+is provided to get all statistics on the last transfer, including a list of transferred entities with mapping from STEP to OCCT types, as well as fail and warning messages. The parameter symbol defines what information will be printed:
+
+The sign `*' before parameters n, s, b, t, r makes it work on all entities (not only on roots). The sign ‘?' before n, s, b, t limits the scope of information to invalid entities.
+Optional argument selection can limit the action of the command to the selection, not to all entities.
+To get help, run this command without arguments.
+Example: The following command gives statistics on the result of translation of different types of entities (taking check messages into account) and calculates summary translation ratios.
+Draw: tpstat *l
+To get information on OCCT shape contents the command
+Draw: statshape shape_name
+is used.
+It outputs the number of each kind of shapes (vertex, edge, wire, etc.) in the shape and some geometrical data (number of C0 surfaces, curves, indirect surfaces, etc.).
+The number of faces is returned as a number of references. To obtain the number of single instances, the standard command (from TTOPOLOGY executable) nbshapes can be used.
+To analyze the internal validity of the shape, command
+Draw: checkbrep shape_name expurged_shape_name
+is used. It checks shape geometry and topology for different cases of inconsistency, like self-intersecting wires or wrong orientation of trimming contours. If an error is found, it copies bad parts of the shape with the names ;expurged_subshape_name _#; and generates an appropriate message. If possible this command also tries to find STEP entities the OCCT shape was produced from.
+expurged_shape_name will contain the original shape without invalid subshapes.
+To get information on tolerances of the shape the command
+Draw: tolerance shape_name [min [max] [symbol]]
+is used. It outputs maximum, average and minimum values of tolerances for each kind of subshapes having tolerances and for the whole shape in general.
+When specifying min and max arguments this command saves shapes with tolerances in the range [min, max] with names shape_name_... and gives their total number.
+Symbol is used for specifying the kind of sub-shapes to analyze: v - for vertices, e - for edges, f - for faces, c - for shells and faces.
+@subsection occt_1624647986_18969122125 Writing a STEP file
+For writing shapes to a STEP file, the following parameters are defined (see above, the command param):
+Several shapes can be written in one file. To start writing a new file, enter command
+Draw: newmodel
+Actually, command newmodel will clear the InterfaceModel to empty it, and the next command will convert the specified shape to STEP entities and add them to the InterfaceModel:
+Draw: stepwrite mode shape_name [file_name]
+The available modes are following:
+ a - ;as is; mode
+ m - manifold_solid_brep or brep_with_voids
+ f - faceted_brep
+ w - geometric_curve_set
+ s - shell_based_surface_model
+For further information, see ;Performing the OCCT shape translation;.
+After a successful translation, if file_name parameter is not specified, the procedure asks you whether to write a STEP model in the file or not:
+execution status : 1
+Mode (0 end, 1 file) :
+It is necessary to call command
+newmodel
+in order to perform a new translation of the next OCCT shape.
+@subsection occt_1624647986_18969122126 Index of useful XSDRAW commands
+
+@section occt_1624647986_241758891 Reading from and writing to XDE
+The STEPCAFControl package (TKXDESTEP toolkit) provides tools to read and write STEP files to and from XDE format (see XDE User’s Guide).
+In addition to the translation of shapes implemented in basic translator, it provides the following:
+ * STEP assemblies, read as OCCT compounds by basic translator, are translated to XDE assemblies
+ * Names of products are translated and assigned to assembly components and instances in XDE
+ * STEP external references are recognized and translated (if external documents are STEP files)
+ * Colors, layers, materials and validation properties assigned to parts or subparts are translated
+ * STEP dimensional tolerances are translated
+@subsection occt_1624647986_2417588911 Description of the process
+@subsubsection occt_1624647986_24175889111 Loading a STEP file
+Before performing any other operation, you must load a STEP file with:
+STEPCAFControl_Reader reader(XSDRAW::Session(), Standard_False);
+IFSelect_ReturnStatus stat = reader.ReadFile(*filename.stp*);
+Loading the file only memorizes the data, it does not translate it.
+@subsubsection occt_1624647986_24175889112 Checking the loaded STEP file
+This step is not obligatory. See a description of this step in paragraph 2.3.2.
+@subsubsection occt_1624647986_24175889113 Setting the parameters for translation to XDE
+See a description of this step in paragraph 2.3.3.
+In addition, the following parameters can be set for XDE translation of attributes:
+ * Parameter for transferring colors:
+reader.SetColorMode(mode);
+// mode can be Standard_True or Standard_False
+ * Parameter for transferring names:
+reader.SetNameMode(mode);
+// mode can be Standard_True or Standard_False
+@subsubsection occt_1624647986_24175889114 Performing the translation of a STEP file to XDE
+The following function performs a translation of the whole document:
+Standard_Boolean ok = reader.Transfer(doc);
+where ;doc; is a variable which contains a handle to the output document and should have a type Handle(TDocStd_Document).
+@subsubsection occt_1624647986_24175889115 Initializing the process of translation from XDE to STEP
+Here is how to initialize the process:
+STEPCAFControl_Writer aWriter(XSDRAW::Session(),Standard_False);
+@subsubsection occt_1624647986_24175889116 Setting the parameters for translation from XDE to STEP
+The following parameters can be set for a translation of attributes to STEP:
+ * Parameter for transferring colors:
+aWriter.SetColorMode(mode);
+// mode can be Standard_True or Standard_False
+ * Parameter for transferring names:
+aWriter.SetNameMode(mode);
+// mode can be Standard_True or Standard_False
+@subsubsection occt_1624647986_24175889117 Performing the translation of an XDE document to STEP
+You can perform the translation of document by calling the function:
+IFSelect_ReturnStatus aRetSt = aWriter.Transfer(doc);
+where ;doc; is a variable, which contains a handle to the input document for transferring and should have a type Handle(TDocStd_Document).
+@subsubsection occt_1624647986_24175889118 Writing a STEP file
+Write a STEP file with:
+IFSelect_ReturnStatus statw = aWriter.WriteFile(;filename.stp;);
+or
+IFSelect_ReturnStatus statw = writer.WriteFile (S);
+where S is OStream
+
+
+
--- /dev/null
+TObj Package {#user_guides__tobj}
+==================
+
+@section occt_1746122829_591811643 Introduction
+
+This document describes the package TObj, which is an add-on
+to the Open CASCADE Application Framework (OCAF).
+This package provides a set of classes and auxiliary tools facilitating
+the creation of object-oriented data models on top of low-level OCAF data structures.
+This includes:
+
+ * Definition of classes representing data objects. Data objects store their data using primitive OCAF attributes, taking advantage of OCAF mechanisms for Undo/Redo and persistence. At the same time they provide a higher level abstraction over the pure OCAF document structure (labels / attributes).
+ * Organization of the data model as a hierarchical (tree-like) structure of objects.
+ * Support of cross-references between objects within one model or among different models. In case of cross-model references the models should depend hierarchically.
+ * Persistence mechanism for storing *TObj* objects in OCAF files, which allows storing and retrieving objects of derived types without re-generating the schema.
+
+This document describes basic principles of logical and physical organization
+of TObj-based data models and typical approaches to implementation of classes representing model objects.
+
+@subsection occt_1746122829_5918116431 Applicability
+
+The main purpose of the *TObj* data model is rapid development
+of the object-oriented data models for applications, using the existing
+functionality provided by OCAF (Undo/Redo and persistence)
+without the necessity to re-develop such functionality from scratch.
+As opposed to using bare OCAF (at the level of labels and attributes),
+TObj facilitates dealing with higher level abstracts, which are closer
+to the application domain. It works best when the application data are naturally
+organized in hierarchical structures, and is especially useful for complex data
+models with dependencies between objects belonging to different parts of the model.
+It should be noted that *TObj* is efficient for representing data structures containing
+a limited number of objects at each level of the data structure (typically less than 1000).
+A greater number of objects causes performance problems due to list-based organization of OCAF documents.
+Therefore, other methods of storage, such as arrays, are advisable for data models or their
+sub-parts containing a great number of uniform objects. However, these methods
+can be combined with the usage of *TObj* to represent the high-level structure of the model.
+
+@section occt_1746122829_361293797 *TObj* Model
+
+@subsection occt_1746122829_3612937971 *TObj* Model structure
+
+In the *TObj* data model the data are separated from the interfaces that manage them.
+It should be emphasized that *TObj* package defines only the interfaces and the basic structure of the model and objects,
+while the actual contents and structure of the model of a particular application
+are defined by its specific classes inherited from *TObj* classes. The
+implementation can add its own features or even change the default behaviour
+and the data layout, though this is not recommended. Logically the *TObj* data model is represented as a tree of model
+objects, with upper-level objects typically being collections of other objects
+(called *partitions*, represented by the class *TObj_Partition*). The root object of the model
+is called the *Main partition* and is maintained by the model itself. This partition contains a list
+of sub-objects called its *children* each sub-object may contain its own children (according to its type), etc.
+
+
+
+Picture 1 *TObj* Data Model
+
+As the *TObj* Data Model is based on OCAF (Open CASCADE Application Framework) technology,
+it stores its data in the underlying OCAF document. The OCAF document consists of a tree of
+items called *labels*. Each label has some data attached to it in the form of *attributes*,
+and may contain an arbitrary number of sub-labels. Each sub-label is identified by its sequential
+number called the *tag*. The complete sequence of tag numbers of the label
+and its parents starting from the document root constitutes the complete *entry*
+of the label, which uniquely identifies its position in the document.
+
+Generally the structure of the OCAF tree of the *TObj* data
+model corresponds to the logical structure of the model and can be presented as in the following picture:
+
+
+
+Picture 2 *TObj* Data Model mapped on OCAF document
+All data of the model are stored in the root label (0:1) of the OCAF document.
+An attribute TObj_TModel is located in this root label. It
+stores the object of type *TObj_Model*. This object serves as a main interface tool
+to access all data and functionalities of the data model.
+
+In simple cases all data needed by the application may be
+contained in a single data model. Moreover, *TObj* gives the possibility to
+distribute the data between several interconnected data models. This can be
+especially useful for the applications dealing with great amounts of data. because
+only the data required for the current operation is loaded in the memory at one time.
+It is presumed that the models have a hierarchical (tree-like) structure,
+where the objects of the child models can refer to the objects of the parent
+models, not vice-versa. Provided that the correct order of loading and closing
+of the models is ensured, the *TObj* classes will maintain references between the objects automatically.
+
+@subsection occt_1746122829_3612937972 Data Model basic features
+
+The class *TObj_Model* describing the data model provides the following functionalities:
+
+ * Loading and saving of the model from or in a file (methods *Load* and *Save*)
+ * Closing and removal of the model from memory (method *Close*)
+ * Definition of the full file name of the persistence storage for this model (method *GetFile*)
+ * Tools to organize data objects in partitions and iterate on objects (methods *GetObjects*, *GetMainPartition*, *GetChildren*, *getPartition*, *getElementPartition*)
+ * Mechanism to give unique names to model objects
+ * Copy (*clone*) of the model (methods *NewEmpty* and *Paste*)
+ * Support of earlier model formats for proper conversion of a model loaded from a file written by a previous version of the application (methods *GetFormatVersion* and *SetFormatVersion*)
+ * Interface to check and update the model if necessary (method *Update*)
+ * Support of several data models in one application. For this feature use OCAF multi-transaction manager, unique names and GUIDs of the data model (methods *GetModelName*, *GetGUID*)
+
+@subsection occt_1746122829_3612937973 Model Persistence
+
+The persistent representation of any OCAF model is contained in an XML or a binary file,
+which is defined by the format string returned by the method *GetFormat*.
+The default implementation works with a binary OCAF document format (*BinOcaf*).
+The other available format is *XmlOcaf*. The class **TObj_Model** declares and provides a default
+implementation of two virtual methods:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ virtual Standard_Boolean Load (const char* theFile);
+ virtual Standard_Boolean SaveAs (const char* theFile);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+which retrieve and store the model from or
+in the OCAF file. The descendants
+should define the following protected method to support Load and Save operations:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ virtual Standard_Boolean initNewModel (const Standard_Boolean IsNew);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This method is called by *Load* after creation of a new model
+or after its loading from the file; its purpose is to perform
+the necessary initialization of the model (such as creation of necessary top-level
+partitions, model update due to version changes etc.). Note that if
+the specified file does not exist, method *Load* will create
+a new document and call *initNewModel* with the argument **True**.
+If the file has been normally loaded, the argument **False** is passed.
+Thus, a new empty *TObj* model is created by calling *Load* with an empty
+string or the path to a nonexistent file as argument.
+
+The method *Load* returns **True** if the model has been retrieved successfully
+(or created a new), or **False** if the model could not be loaded.
+If no errors have been detected during initialization (model retrieval or creation),
+the virtual method *AfterRetrieval* is invoked for all objects of the model.
+This method initializes or updates the objects immediately after the model initialization.
+It could be useful when some object data should be imported from an OCAF attribute into transient
+fields which could be changed outside of the OCAF transaction mechanism.
+Such fields can be stored into OCAF attributes for saving into persistent storage during the save operation.
+
+To avoid memory leaks, the *TObj_Model* class destructor invokes *Close* method
+which clears the OCAF document and removes all data from memory before the model is destroyed.
+For XML and binary persistence of the *TObj* data model the corresponding drivers are implemented
+in *BinLDrivers*, *BinMObj* and *XmlLDrivers*, *XmlMObj* packages.
+These packages contain retrieval and storage drivers for the model, model objects and custom attributes
+from the *TObj* package. The schemas support persistence for the standard OCAF and *TObj* attributes.
+This is sufficient for the implementation of simple data models, but
+in some cases it can be reasonable to add specific OCAF attributes to
+facilitate the storage of the data specific to the application.
+In this case the schema should be extended using the standard OCAF mechanism.
+
+@subsection occt_1746122829_3612937974 Access to the objects in the model
+
+All objects in the model are stored in the main partition and accessed by iterators.
+To access all model objects use:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ virtual Handle(TObj_ObjectIterator) GetObjects () const;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This method returns a recursive iterator on all objects stored in the model.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ virtual Handle(TObj_ObjectIterator) GetChildren () const;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This method returns an iterator on child objects of the main partition.
+Use the following method to get the main partition:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ Handle(TObj_Partition) GetMainPartition() const;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To receive the iterator on objects of a specific type *AType* use the following call:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ GetMainPartition()->GetChildren(STANDARD_TYPE(AType) );
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The set of protected methods is provided for descendant classes to deal with partitions:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ virtual Handle(TObj_Partition) getPartition (const TDF_Label, const Standard_Boolean theHidden) const;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This method returns (creating if necessary) a partition in the specified label of the document.
+The partition can be created as hidden (*TObj_HiddenPartition* class).
+A hidden partition can be useful to distinguish the data that
+should not be visible to the user when browsing the model in the application.
+
+The following two methods allow getting (creating) a partition
+in the sub-label of the specified label in the document
+(the label of the main partition for the second method) and with the given name:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ virtual Handle(TObj_Partition) getPartition (const TDF_Label, const Standard_Integer theIndex, const TCollection_ExtendedString& theName, const Standard_Boolean theHidden) const;
+ virtual Handle(TObj_Partition) getPartition (const Standard_Integer theIndex, const TCollection_ExtendedString& theName, const Standard_Boolean theHidden) const;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If the default object naming and the name register mechanism
+is turned on, the object can be found in the model by its unique name:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ Handle(TObj_Object) FindObject (const Handle(TCollection_HExtendedString)& theName, const Handle(TObj_TNameContainer)& theDictionary) const;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@subsection occt_1746122829_3612937975 Own model data
+
+The model object can store its own data in the Data label
+of its main partition, however, there is no standard API for
+setting and getting these data types. The descendants can add
+their own data using standard OCAF methods. The enumeration DataTag is defined
+in *TObj_Model* to avoid conflict of data labels used by this class
+and its descendants, similarly to objects (see below).
+
+@subsection occt_1746122829_3612937976 Object naming
+
+The basic implementation of *TObj_Model* provides the default
+naming mechanism: all objects must have unique names,
+which are registered automatically in the data model dictionary.
+The dictionary is a *TObj_TNameContainer*
+attribute whose instance is located in the model root label.
+If necessary, the developer can add several dictionaries into
+the specific partitions, providing the name registration in the
+correct name dictionary and restoring the name map after document is loaded from file.
+To ignore name registering it is necessary to redefine the methods *SetName*,
+*AfterRetrieval* of the *TObj_Object* class and skip the registration of the object name.
+Use the following methods for the naming mechanism:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ Standard_Boolean IsRegisteredName (const Handle(TCollection_HExtendedString)& theName, const Handle(TObj_TNameContainer)& theDictionary ) const;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Returns **True** if the object name is already registered in the indicated (or model) dictionary.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ void RegisterName (const Handle(TCollection_HExtendedString)& theName, const TDF_Label& theLabel, const Handle(TObj_TNameContainer)& theDictionary ) const;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Registers the object name with the indicated label where the object
+is located in the OCAF document. Note that the default implementation
+of the method *SetName* of the object registers the new name automatically
+(if the name is not yet registered for any other object)
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ void UnRegisterName (const Handle(TCollection_HExtendedString)& theName, const Handle(TObj_TNameContainer)& theDictionary ) const;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Unregisters the name from the dictionary. Ther names of *TObj* model
+objects are removed from the dictionary when the objects are deleted from the model.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ Handle(TObj_TNameContainer) GetDictionary() const;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Returns a default instance of the model dictionary (located at the model root label).
+The default implementation works only with one dictionary.
+If there are a necessity to have more than one dictionary for the model objects,
+it is recommended to redefine the corresponding virtual method of TObj_Object
+that returns the dictionary where names of objects should be registered.
+
+@subsection occt_1746122829_3612937977 API for transaction mechanism
+
+Class *TObj_Model* provides the API for transaction mechanism (supported by OCAF):
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ Standard_Boolean HasOpenCommand() const;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Returns True if a Command transaction is open
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ void OpenCommand() const;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Opens a new command transaction.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ void CommitCommand() const;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Commits the Command transaction. Does nothing If there is no open Command transaction.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ void AbortCommand() const;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Aborts the Command transaction. Does nothing if there is no open Command transaction.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ Standard_Boolean IsModified() const;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Returns True if the model document has a modified status (has changes after the last save)
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ void SetModified( const Standard_Boolean );
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Changes the modified status by force. For synchronization of transactions
+within several *TObj_Model* documents use class *TDocStd_MultiTransactionManager*.
+
+@subsection occt_1746122829_3612937978 Model format and version
+
+Class *TObj_Model* provides the descendant classes with a means to control
+the format of the persistent file by choosing the schema used to store or retrieve operations.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ virtual TCollection_ExtendedString GetFormat () const;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Returns the string *TObjBin* or *TObjXml* indicating
+the current persistent mechanism. The default value is *TObjBin*.
+Due to the evolution of functionality of the developed application,
+the contents and the structure of its data model vary from version to version.
+*TObj* package provides a basic mechanism supporting backward versions compatibility,
+which means that newer versions of the application will be able to read
+Data Model files created by previous versions (but not vice-versa) with a minimum loss of data.
+For each type of Data Model, all known versions of the data format
+should be enumerated in increasing order, incremented with every change
+of the model format. The current version of the model
+format is stored in the model file and can be checked upon retrieval.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ Standard_Integer GetFormatVersion() const;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Returns the format version stored in the model file
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ void SetFormatVersion(const Standard_Integer theVersion);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Defines the format version used for save.
+
+Upon loading a model, the method *initNewModel()*, called immediately
+after opening a model from disk (on the level of the OCAF document),
+provides a specific code that checks the format version stored in that model.
+If it is older than the current version of the application, the data update can be performed.
+Each model can have its own specific conversion code
+that performs the necessary data conversion to make them compliant with the current version.
+
+When the conversion ends the user is advised of that by the messenger interface
+provided by the model (see messaging chapter for more details),
+and the model version is updated. If the version of data model is not supported
+(it is newer than the current or too old), the load operation should fail.
+The program updating the model after version change can be implemented as static
+methods directly in C++ files of the corresponding Data Model classes,
+not exposing it to the other parts of the application.
+These codes can use direct access to the model and objects data (attributes)
+not using objects interfaces, because the data model API and object classes
+could have already been changed.
+
+Note that this mechanism has been designed to maintain version compatibility
+for the changes of data stored in the model, not for the changes of
+low-level format of data files (such as the storage format of a specific OCAF attribute).
+If the format of data files changes, a specific treatment on a case-by-case basis will be required.
+
+@subsection occt_1746122829_3612937979 Model update
+
+The following methods are used for model update to ensure its consistency
+with respect to the other models in case of cross-model dependencies:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ virtual Standard_Boolean Update();
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This method is usually called after loading of the model.
+The default implementation does nothing and returns **True**.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ virtual Standard_Boolean initNewModel( const Standard_Boolean IsNew);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This method performs model initialization, check and updates (as described above).
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ virtual void updateBackReferences( const Handle(TObj_Object)& theObj);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This method is called from the previous method to update back references
+of the indicated object after the retrieval of the model from file
+(see data model - object relationship chapter for more details)
+
+@subsection occt_1746122829_36129379710 Model copying
+
+To copy the model between OCAF documents use the following methods:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ virtual Standard_Boolean Paste (Handle(*TObj_Model*) theModel, Handle(TDF_RelocationTable) theRelocTable = 0 );
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Pastes the current model to the new model. The relocation table
+ensures correct copying of the sub-data shared by several parts of the model.
+It stores a map of processed original objects of relevant types in their copies.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ virtual Handle(*TObj_Model*) NewEmpty() = 0;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Redefines a pure virtual method to create a new empty instance of the model.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ void CopyReferences ( const Handle(*TObj_Model*)& theTarget, const Handle(TDF_RelocationTable)& theRelocTable);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Copies the references from the current model to the target model.
+
+@subsection occt_1746122829_36129379711 Messaging
+
+The messaging is organised using Open CASCADE Messenger from the package Message.
+The messenger is stored as the field of the model instance
+and can be set and retrieved by the following methods:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ void SetMessenger( const Handle(Message_Messenger)& );
+ Handle(Message_Messenger) Messenger() const;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+A developer should create his own instance of the Messenger
+bound to the application user interface, and attribute it to the model
+for future usage. In particular the messenger is used for reporting
+errors and warnings in the persistence mechanism.
+Each message has a unique string identifier (key).
+All message keys are stored in a special resource file TObj.msg.
+This file should be loaded at the start of the application
+by call to the appropriate method of the class *Message_MsgFile*.
+
+@section occt_1746122829_87267338 Model object
+
+Class *TObj_Object* provides basic interface and default implementation
+of important features of *TObj* model objects. This implementation defines
+basic approaches that are recommended for all descendants,
+and provides tools to facilitate their usage.
+
+
+
+Picture 3 *TObj* objects hierarchy
+
+@subsection occt_1746122829_872673381 Separation of data and interface
+
+In the *TObj* data model, the data are separated from the interfaces that manage them.
+The data belonging to a model object are stored in its root label and sub-labels
+in the form of standard OCAF attributes. This allows using standard OCAF mechanisms
+for work with these data, and eases the implementation of the persistence mechanism.
+The instance of the interface which serves as an API for managing object data
+(e.g. represents the model object) is stored in the root label of the object,
+and typically does not bring its own data. The interface classes are organized in a hierarchy
+corresponding to the natural hierarchy of the model objects according to the application.
+In the text below the term 'object' is used to denote either the instance
+of the interface class or the object itself (both interface and data stored in OCAF).
+The special type of attribute *TObj_TObject* is used for storing instances of objects interfaces
+in the OCAF tree. *TObj_TObject* is a simple container for the object of type *TObj_Object*.
+All objects (interfaces) of the data model inherit this class.
+
+
+
+Picture 4 *TObj* object stored on OCAF label
+
+@subsection occt_1746122829_872673382 Basic features
+
+The *TObj_Object* class provides some basic features that can be inherited (or, if necessary, redefined) by the descendants:
+
+ * Gives access to the model to which the object belongs (method *GetModel*) and to the OCAF label in which the object is stored (method *GetLabel*).
+ * Supports references (and back references) to other objects in the same or in another model (methods *getReference*, *setReference*, *addReference*, *GetReferences*, *GetBackReferences*, *AddBackReference*, *RemoveBackReference*, *ReplaceReference*)
+ * Provides the ability to contain child objects, as it is actual for partition objects (methods *GetChildren*, *GetFatherObject*)
+ * Organizes its data in the OCAF structure by separating the sub-labels of the main label intended for various kinds of data and providing tools to organize these data (see <a href="../../../../Documents%20and%20Settings/TEMP/obj-inher">below</a>). The kinds of data stored separately are:
+ * Child objects stored in the label returned by the method *GetChildLabel*
+ * References to other objects stored in the label returned by the method* GetReferenceLabel*
+ * Other data, both common to all objects and specific for each subtype of the model object, are stored in the label returned by the method *GetDataLabel*
+ * Provides unique names of all objects in the model (methods *GetDictionary*, *GetName*, *SetName*)
+ * Provides unified means to maintain persistence (implemented in descendants with the help of macros *DECLARE_TOBJOCAF_PERSISTENCE* and *IMPLEMENT_TOBJOCAF_PERSISTENCE*)
+ * Allows an object to remove itself from the OCAF document and check the depending objects can be deleted according to the back references (method *Detach*)
+ * Implements methods for identification and versioning of objects
+ * Manages the object interaction with OCAF Undo/Redo mechanism (method *IsAlive*, *AfterRetrieval*, *BeforeStoring*)
+ * Allows make a clone (methods *Clone*, *CopyReferences*, *CopyChildren*, *copyData*)
+ * Contains additional word of bit flags (methods *GetFlags*, *SetFlags*, *TestFlags*, *ClearFlags*)
+ * Defines the interface to sort the objects by rank (methods *GetOrder*, *SetOrder*)
+ * Provides a number of auxiliary methods for descendants to set/get the standard attribute values, such as int, double, string, arrays etc.
+
+An object can be received from the model by the following methods:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ static Standard_Boolean GetObj ( const TDF_Label& theLabel, Handle(TObj_Object)& theResObject, const Standard_Boolean isSuper = Standard_False );
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Returns **True** if the object has been found in the indicated label (or in the upper level label if isSuper is **True)**.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ Handle(TObj_Object) GetFatherObject ( const Handle(Standard_Type)& theType = NULL ) const;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Returns the father object of the indicated type
+for the current object (the direct father object if the type is NULL).
+
+@subsection occt_1746122829_872673383 Data layout and inheritance
+
+As far as the data objects are separated from the interfaces and stored in the OCAF tree,
+the functionality to support inheritance is required. Each object has its own data
+and references stored in the labels in the OCAF tree. All data are stored in the sub-tree
+of the main object label. If it is necessary to inherit a class from the base class,
+the descendant class should use different labels for data and references than its ancestor.
+Therefore each *TObj* class can reserve the range of tags in each of
+*Data*, *References*, and *Child* sub-labels.
+The reserved range is declared by the enumeration defined
+in the class scope (called DataTag, RefTag, and ChildTag, respectively).
+The item *First* of the enumeration of each type is defined via the *Last* item
+of the corresponding enumeration of the parent class, thus ensuring that the tag numbers
+do not overlap. The item *Last* of the enumeration defines the last tag reserved by this class.
+Other items of the enumeration define the tags used for storing particular data items of the object.
+See the declaration of the TObj_Partition class for the example.
+
+*TObj_Object* class provides a set of auxiliary methods for descendants
+to access the data stored in sub-labels by their tag numbers:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ TDF_Label getDataLabel (const Standard_Integer theRank1, const Standard_Integer theRank2 = 0) const;
+ TDF_Label getReferenceLabel (const Standard_Integer theRank1, const Standard_Integer theRank2 = 0) const;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Returns the label in *Data* or *References* sub-labels at a given tag number (theRank1).
+The second argument, theRank2, allows accessing the next level of hierarchy
+(theRank2-th sub-label of theRank1-th data label).
+This is useful when the data to be stored are represented by multiple OCAF attributes
+of the same type (e.g. sequences of homogeneous data or references).
+The get/set methods allow easily accessing the data located in the specified data label
+for the most widely used data types (*Standard_Real*, *Standard_Integer*, *TCollection_HExtendedString*,
+ *TColStd_HArray1OfReal*, *TColStd_HArray1OfInteger*, *TColStd_HArray1OfExtendedString*).
+For instance, methods provided for real numbers are:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ Standard_Real getReal (const Standard_Integer theRank1, const Standard_Integer theRank2 = 0) const;
+ Standard_Boolean setReal (const Standard_Real theValue, const Standard_Integer theRank1, const Standard_Integer theRank2 = 0, const Standard_Real theTolerance = 0.) const;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Similar methods are provided to access references to other objects:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ Handle(TObj_Object) getReference (const Standard_Integer theRank1, const Standard_Integer theRank2 = 0) const;
+ Standard_Boolean setReference (const Handle(TObj_Object) &theObject, const Standard_Integer theRank1, const Standard_Integer theRank2 = 0);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The method *addReference* gives an easy way to store a sequence of homogeneous references in one label.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ TDF_Label addReference (const Standard_Integer theRank1, const Handle(TObj_Object) &theObject);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Note that while references to other objects should be defined by descendant classes
+individually according to the type of object, *TObj_Object* provides methods
+to manipulate (check, remove, iterate) the existing references in the uniform way, as described below.
+
+@subsection occt_1746122829_872673384 Persistence
+
+The persistence of the *TObj* Data Model is implemented with the help
+of standard OCAF mechanisms (a schema defining necessary plugins, drivers, etc.).
+This implies the possibility to store/retrieve all data that are stored
+as standard OCAF attributes., The corresponding handlers are added
+to the drivers for *TObj*-specific attributes.
+The special tool is provided for classes inheriting from *TObj_Object*
+to add the new types of persistence without regeneration of the OCAF schema.
+The class *TObj_Persistence* provides basic means for that:
+
+ * automatic run-time registration of object types
+ * creation of a new object of the specified type (one of the registered types)
+
+Two macros defined in the file TObj_Persistence.hxx have to be included in the definition
+of each model object class inheriting TObj_Object to activate the persistence mechanism:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ DECLARE_TOBJOCAF_PERSISTENCE (classname, ancestorname)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Should be included in the private section of declaration of each class inheriting
+*TObj_Object* (hxx file). This macro adds an additional constructor to the object class,
+and declares an auxiliary (private) class inheriting *TObj_Persistence*
+that provides a tool to create a new object of the proper type.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ IMPLEMENT_TOBJOCAF_PERSISTENCE (classname)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Should be included in .cxx file of each object class that should be saved and restored.
+This is not needed for abstract types of objects. This macro implements the functions
+declared by the previous macro and creates a static member
+that automatically registers that type for persistence.
+
+When the attribute *TObj_TObject* that contains the interface object is saved,
+its persistence handler stores the runtime type of the object class.
+When the type is restored the handler dynamically recognizes the type
+and creates the corresponding object using mechanisms provided by *TObj_Persistence*.
+
+@subsection occt_1746122829_872673385 Names of objects
+
+All *TObj* model objects have names by which the user can refer to the object.
+Upon creation, each object receives a default name, constructed
+from the prefix corresponding to the object type (more precisely, the prefix is defined
+by the partition to which the object belongs), and the index of the object in the current partition.
+The user has the possibility to change this name. The uniqueness of the name in the model is ensured
+by the naming mechanism (if the name is already used, it cannot be attributed to another object).
+This default implementation of *TObj* package works with a single instance of the name container (dictionary)
+for name registration of objects and it is enough in most simple projects.
+If necessary, it is easy to redefine a couple of object methods
+(for instance *GetDictionary*()) and to take care of construction and initialization of containers.
+This functionality is provided by the following methods:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ virtual Handle(TObj_TNameContainer) GetDictionary() const;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Returns the name container where the name of object should be registered.
+The default implementation returns the model name container.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ Handle(TCollection_HExtendedString) GetName() const;
+ Standard_Boolean GetName( TCollection_ExtendedString& theName ) const;
+ Standard_Boolean GetName( TCollection_AsciiString& theName ) const;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Returns the object name. The methods with in / out argument return False if the object name is not defined.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ virtual Standard_Boolean SetName ( const Handle(TCollection_HExtendedString)& theName ) const;
+ Standard_Boolean SetName ( const Handle(TCollection_HAsciiString)& theName ) const;
+ Standard_Boolean SetName ( const Standard_CString theName ) const;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Attributes a new name to the object and returns **True** if the name has been attributed successfully.
+Returns False if the name has been already attributed to another object.
+The last two methods are short-cuts to the first one.
+
+@subsection occt_1746122829_872673386 References between objects
+
+Class *TObj_Object* allows creating references to other objects in the model.
+Such references describe relations among objects which are not adequately reflected
+by the hierarchical objects structure in the model (parent-child relationship).
+The references are stored internally using the attribute TObj_TReference.
+This attribute is located in the sub-label of the referring object (called *master*)
+and keeps reference to the main label of the referred object.
+At the same time the referred object can maintain the back reference to the master object.
+
+
+
+Picture 5 Objects relationship
+
+The back references are stored not in the OCAF document but as a transient field
+of the object; they are created when the model is restored from file,
+and updated automatically when the references are manipulated.
+The class *TObj_TReference* allows storing references between objects
+from different *TObj* models, facilitating the construction of complex relations between objects.
+The most used methods for work with references are:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ virtual Standard_Boolean HasReference( const Handle(TObj_Object)& theObject) const;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Returns True if the current object refers to the indicated object.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ virtual Handle(TObj_ObjectIterator) GetReferences ( const Handle(Standard_Type)& theType = NULL ) const;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Returns an iterator on the object references. The optional argument *theType*
+restricts the types of referred objects, or does not if it is NULL.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ virtual void RemoveAllReferences();
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Removes all references from the current object.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ virtual void RemoveReference( const Handle(TObj_Object)& theObject );
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Removes the reference to the indicated object.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ virtual Handle(TObj_ObjectIterator) GetBackReferences ( const Handle(Standard_Type)& theType = NULL ) const;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Returns an iterator on the object back references.
+The argument theType restricts the types of master objects, or does not if it is NULL.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ virtual void ReplaceReference ( const Handle(TObj_Object)& theOldObject, const Handle(TObj_Object)& theNewObject );
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Replaces the reference to theOldObject by the reference to *theNewObject*.
+The handle theNewObject may be NULL to remove the reference.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ virtual Standard_Boolean RelocateReferences ( const TDF_Label& theFromRoot, const TDF_Label& theToRoot, const Standard_Boolean theUpdateackRefs = Standard_True );
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Replaces all references to a descendant label of *theFromRoot*
+by the references to an equivalent label under *theToRoot*.
+Returns **False** if the resulting reference does not point at a *TObj_Object*.
+Updates back references if theUpdateackRefs is **True**.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ virtual Standard_Boolean CanRemoveReference ( const Handle(TObj_Object)& theObj) const;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Returns **True** if the reference can be removed and the master object
+will remain valid (*weak* reference).
+Returns **False** if the master object cannot be valid without the referred object (*strong* reference).
+This affects the behaviour of objects removal from the model – if the reference cannot be removed,
+either the referred object will not be removed, or both the referred
+and the master objects will be removed (depends on the deletion mode in the method **Detach**)
+
+@subsection occt_1746122829_872673387 Creation and deletion of objects
+
+It is recommended that all objects inheriting from *TObj_Object*
+ should implement the same approach to creation and deletion.
+The object of the *TObj* data model cannot be created independently
+of the model instance, as far as it stores the object data in OCAF data structures.
+Therefore an object class cannot be created directly as its constructor is protected.
+Instead, each object should provide a static method *Create*(), which accepts the model,
+with the label, which stores the object and other type-dependent parameters
+necessary for proper definition of the object. This method creates a new object with its data
+(a set of OCAF attributes) in the specified label, and returns a handle to the object's interface.
+The method *Detach*() is provided for deletion of objects from OCAF model.
+Object data are deleted from the corresponding OCAF label; however,
+the handle on object remains valid. The only operation available after object deletion
+is the method *IsAlive*() checking whether the object has been deleted or not,
+which returns False if the object has been deleted.
+
+When the object is deleted from the data model, the method checks
+whether there are any alive references to the object.
+Iterating on references the object asks each referring (master) object
+whether the reference can be removed. If the master object can be unlinked,
+the reference is removed, otherwise the master object will be removed too
+or the referred object will be kept alive. This check is performed by the method *Detach* ,
+but the behavior depends on the deletion mode *TObj_DeletingMode*:
+
+ * **TObj_FreeOnly** – the object will be destroyed only if it is free, i.e. there are no references to it from other objects
+ * **TObj_KeepDepending** – the object will be destroyed if there are no strong references to it from master objects (all references can be unlinked)
+ * **TObj_Force** – the object and all depending master objects that have strong references to it will be destroyed.
+
+The most used methods for object removing are:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ virtual Standard_Boolean CanDetachObject (const TObj_DeletingMode theMode = TObj_FreeOnly );
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Returns **True** if the object can be deleted with the indicated deletion mode.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ virtual Standard_Boolean Detach ( const TObj_DeletingMode theMode = TObj_FreeOnly );
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Removes the object from the document if possible
+(according to the indicated deletion mode).
+Unlinks references from removed objects.
+Returns **True** if the objects have been successfully deleted.
+
+@subsection occt_1746122829_872673388 Transformation and replication of object data
+
+*TObj_Object* provides a number of special virtual methods to support replications of objects. These methods should be redefined by descendants when necessary.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ virtual Handle(TObj_Object) Clone (const TDF_Label& theTargetLabel, Handle(TDF_RelocationTable) theRelocTable = 0);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Copies the object to theTargetLabel. The new object will have all references of its original.
+Returns a handle to the new object (null handle if fail). The data are copied directly,
+but the name is changed by adding the postfix *_copy*.
+To assign different names to the copies redefine the method:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ virtual Handle(TCollection_HExtendedString) GetNameForClone ( const Handle(TObj_Object)& ) const;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Returns the name for a new object copy. It could be useful to return the same object name
+if the copy will be in the other model or in the other partition with its own dictionary.
+The method *Clone* uses the following public methods for object data replications:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ virtual void CopyReferences (const const Handle(TObj_Object)& theTargetObject, const Handle(TDF_RelocationTable) theRelocTable);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Adds to the copy of the original object its references.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ virtual void CopyChildren (TDF_Label& theTargetLabel, const Handle(TDF_RelocationTable) theRelocTable);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Copies the children of an object to the target child label.
+
+@subsection occt_1746122829_872673389 Object flags
+
+Each instance of TObj_Object stores a set of bit flags,
+which facilitate the storage of auxiliary logical information assigned to the objects
+(object state). Several typical state flags are defined in the enumeration ObjectState:
+
+ * ObjectState_Hidden – the object is marked as hidden
+ * ObjectState_Saved – the object has (or should have) the corresponding saved file on disk
+ * ObjectState_Imported – the object is imported from somewhere
+ * ObjectState_ImportedByFile – the object has been imported from file and should be updated to have correct relations with other objects
+ * ObjectState_Ordered – the partition contains objects that can be ordered.
+
+The user (developer) can define any new flags in descendant classes.
+To set/get an object, the flags use the following methods:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ Standard_Integer GetFlags() const;
+ void SetFlags( const Standard_Integer theMask );
+ Stadnard_Boolean TestFlags( const Standard_Integer theMask ) const;
+ void ClearFlags( const Standard_Integer theMask = 0 );
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In addition, the generic virtual interface stores the logical properties
+of the object class in the form of a set of bit flags.
+Type flags can be received by the method:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ virtual Standard_Integer GetTypeFlags() const;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The default implementation returns the flag **Visible**
+defined in the enumeration TypeFlags. This flag is used to define visibility
+of the object for the user browsing the model (see class TObj_HiddenPartition).
+Other flags can be added by the applications.
+
+@subsection occt_1746122829_8726733810 Partitions
+
+The special kind of objects defined by the class *TObj_Partition*
+(and its descendant *TObj_HiddenPartition*) is provided for partitioning
+the model into a hierarchical structure. This object represents the container
+of other objects. Each *TObj* model contains the main partition that is placed
+in the same OCAF label as the model object, and serves as a root of the object's tree.
+A hidden partition is a simple partition with a predefined hidden flag.
+The main partition object methods:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ TDF_Label NewLabel() const;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Allocates and returns a new label for creation of a new child object.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ void SetNamePrefix ( const Handle(TCollection_HExtendedString)& thePrefix);
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Defines the prefix for automatic generation of names of the newly created objects.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ Handle(TCollection_HExtendedString) GetNamePrefix() const;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Returns the current name prefix.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ Handle(TCollection_HExtendedString) GetNewName ( const Standard_Boolean theIsToChangeCount) const;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Generates the new name and increases the internal counter of child objects if theIsToChangeCount is **True**.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ Standard_Integer GetLastIndex() const;
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Returns the last reserved child index.
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+ void SetLastIndex( const Standard_Integer theIndex );
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Sets the last reserved index.
+
+@section occt_1746122829_819520128 Auxiliary classes
+
+Apart from the model and the object, package *TObj* provides a set of auxiliary classes:
+
+ * TObj_Application - defines OCAF application supporting existence and operation with *TObj* documents.
+ * TObj_Assistant – class provides an interface to the static data to be used during save and load operations on models. In particular, in case of cross-model dependencies it allows passing information on the parent model to the OCAF loader to correctly resolve the references when loading a dependent model.
+ * TObj_TReference - OCAF attribute describes the references between objects in the *TObj* model(s). This attribute stores the label of the referred model object, and provides transparent cross-model references. At runtime, these references are simple Handles; in persistence mode, the cross-model references are automatically detected and processed by the persistence mechanism of TObj_TReference attribute.
+ * Other classes starting with TObj_T... - define OCAF attributes used to store TObj-specific classes and some types of data on OCAF labels.
+ * Iterators – a set of classes implementing TObj_ObjectIterator interface, used for iterations on *TObj* objects:
+ * TObj_ObjectIterator – a basic abstract class for other *TObj* iterators. Iterates on TObj_Object instances.
+ * TObj_LabelIterator – iterates on object labels in the *TObj* model document
+ * TObj_ModelIterator – iterates on all objects in the model. Works with sequences of other iterators.
+ * TObj_OcafObjectIterator – Iterates on *TObj* data model objects. Can iterate on objects of a specific type.
+ * TObj_ReferenceIterator – iterates on object references.
+ * TObj_SequenceIterator – iterates on a sequence of *TObj* objects.
+ * TObj_CheckModel - a tool that checks the internal consistency of the model. The basic implementation checks only the consistency of references between objects.
+
+The structure of *TObj* iterators hierarchy is presented below:
+
+
+
+Picture 6: Hierarchy of iterators
+
+@section occt_1746122829_579029274 Packaging
+
+The *TObj* sources are distributed in the following packages:
+
+ * TObj - defines basic classes that implement *TObj* interfaces for OCAF-based modelers.
+ * BinLDrivers, XmlLDrivers – binary and XML driver of *TObj* package
+ * BinLPlugin, XmlLPlugin – plugin for binary and XML persistence
+ * BinMObj, XmlMObj – binary and XML drivers to store and retrieve specific *TObj* data to or from OCAF document
+ * TKBinL, TKXmlL – toolkits of binary and XML persistence
+
+
--- /dev/null
+User Guides {#user_guides}
+===========
+
+\subpage user_guides__foundation_classes "user_guides__foundation_classes"
+
+\subpage user_guides__modeling_data "user_guides__modeling_data"
+
+\subpage user_guides__modeling_algos "user_guides__modeling_algos"
+
+\subpage user_guides__visualization "user_guides__visualization"
+
+\subpage user_guides__iges "user_guides__iges"
+\subpage user_guides__step "user_guides__step"
+\subpage user_guides__xde "user_guides__xde"
+
+\subpage user_guides__ocaf "user_guides__ocaf"
+\subpage user_guides__tobj "user_guides__tobj"
+
+\subpage user_guides__shape_healing "user_guides__shape_healing"
+
+\subpage user_guides__test_harness "user_guides__test_harness"
+
+\subpage user_guides__wok "user_guides__wok"
--- /dev/null
+Visualization {#user_guides__visualization}
+===================
+
+@section occt_1621831385_591811643 Introduction
+
+
+This manual explains how to use Open CASCADE Technology Visualization. It provides basic documentation on setting up and using Visualization. For advanced information on Visualization and its applications, see our offerings on our web site
+(Training and E-Learning) at <a href="http://www.opencascade.org/support/training/">http://www.opencascade.org/support/training/</a>
+
+Visualization in Open CASCADE Technology is based on the separation of:
+ * on the one hand - the data which stores the geometry and topology of the entities you want to display and select, and
+ * on the other hand - its *presentation* (what you see when an object is displayed in a scene) and *selection* (possibility to choose the whole object or its sub-parts interactively in order to apply some application-defined operations to the selected entities).
+
+@subsection occt_1621831385_5918116431 Open CASCADE Technology Visualization and the Organization of this guide
+
+Presentations are managed through the Presentation component, and selection through the Selection component.
+
+To make management of these functionalities in 3D more intuitive and consequently, more transparent, **Application Interactive Services** have been created. **AIS** use the notion of the *interactive object*, a displayable and selectable entity, which represents an element from the application data. As a result, in 3D, you, the user, have no need to be familiar with any functions underlying AIS unless you want to create your own interactive objects or selection filters.
+
+If, however, you require types of interactive objects and filters other than those provided, you will need to know the mechanics of presentable and selectable objects, specifically how to implement their virtual functions. To do this requires familiarity with such fundamental concepts as the sensitive primitive and the presentable object.
+
+The packages used to display 3D objects are the following:
+ * AIS
+ * StdPrs
+ * Prs3d
+ * PrsMgr
+ * V3d
+ * Graphic3d
+
+If you are concerned with 2D visualization, you must familiarize yourself with the fundamental concepts of presentation as outlined in the section on this subject in chapter 1, Fundamental Concepts. In brief, the packages used to display 2D objects are the following:
+ * AIS2D
+ * Prs2d
+ * PrsMgr
+ * V2d
+ * Graphic2d.
+
+Figure 1 below presents a schematic overview of the relations between the key concepts and packages in visualization. AIS stands for both AIS and AIS2D packages. Naturally, *Geometry & Topology* is just an example of application data that can be handled by AIS, and application-specific interactive objects can deal with any kind of data.
+
+
+**Figure 1. Key concepts and packages in visualization**
+
+To answer different needs of CASCADE users, this user’s guide offers the following three paths in reading it.
+
+ * If the 3D services proposed in AIS meet your requirements, you need only read chapter 3, *AIS: Application Interactive Services*.
+
+ * If the services provided do not satisfy your requirements - if for example, you need a selection filter on another type of entity - you should read chapter 2 *Fundamental Concepts*, chapter 3 *AIS: Application Interactive Services*, and possibly chapters 4 and 5 *3D Presentations *and *3D Resources*. You may want to begin with the chapter presenting AIS.
+
+ * If your display will be in 2D, you should read chapter 1 *Fundamental Concepts*, chapter 6 *2D Presentations* and chapter 7 *2D Resources*.
+
+
+@section occt_1621831385_1633708282 Fundamental Concepts
+
+@subsection occt_1621831385_16337082821 Presentation
+
+In Open CASCADE Technology, presentation services are separated from the data, which they represent, which is generated by applicative algorithms. This division allows you to modify a geometric or topological algorithm and its resulting objects without modifying the visualization services.
+
+@subsubsection occt_1621831385_163370828211 Key difference in implementation of 2D and 3D visualization
+Current implementation of 3D visualization services is based on OpenGL.
+2D visualization packages use native window system API (Win32 GDI API on Windows, Xlib API on Unix and Linux).
+@subsubsection occt_1621831385_163370828212 Structure of the Presentation
+
+Displaying an object on the screen involves three kinds of entity:
+ * a presentable object, the *AIS_InteractiveObject *
+ * a viewer
+ * an interactive context, the *AIS_InteractiveContext*.
+
+<h4>The presentable object </h4>
+The purpose of a presentable object is to provide the graphical representation of an object in the form of Graphic2d or Graphic3d structure. On the first display request, it creates this structure by calling the appropriate algorithm and retaining this framework for further display.
+Standard presentation algorithms are provided in the StdPrs and Prs3d packages. You can, however, write specific presentation algorithms of your own, provided that they create presentations made of structures from the Graphic2d or Graphic3d packages. You can also create several presentations of a single presentable object: one for each visualization mode supported by your application.
+Each object to be presented individually must be presentable or associated with a presentable object.
+
+<h4>The viewer </h4>
+The viewer allows you to interactively manipulate views of the object. When you zoom, translate or rotate a view, the viewer operates on the graphic structure created by the presentable object and not on the data model of the application. Creating Graphic2d and Graphic3d structures in your presentation algorithms allows you to use the 2D and 3D viewers provided in Open CASCADE Technology.
+
+<h4>The Interactive Context </h4>
+(see chapter 2, AIS: Application Interactive Services) The interactive context controls the entire presentation process from a common high-level API. When the application requests the display of an object, the interactive context requests the graphic structure from the presentable object and sends it to the viewer for displaying.
+
+<h4>Presentation packages </h4>
+Presentation involves at least the AIS, AIS2D, PrsMgr, StdPrs, V3d and V2d packages. Additional packages such as Prs3d, Prs2d, Graphic3d and Graphic2d may be used if you need to implement your own presentation algorithms.
+
+<h4>AIS and AIS2D</h4>
+See chapter 2, **AIS: Application Interactive Services **The *AIS* package provides all classes to implement interactive objects (presentable and selectable 2D or 3D entities).
+
+<h4>PrsMgr </h4>
+The *PrsMgr* package provides all the classes needed to implement the presentation process: the *Presentation* and *PresentableObject* abstract classes and the *PresentationManager2d* and *PresentationManager3d* concrete classes.
+
+<h4>StdPrs </h4>
+The *StdPrs* package provides ready-to-use standard presentation algorithms of points, curves and shapes of the geometry and topology toolkits.
+
+<h4>V2d and V3d </h4>
+The *V2d* and *V3d* packages provide the services supported by the 2D and 3D viewers.
+
+<h4>Prs3d and Prs2d</h4>
+The *Prs3d* package provides some generic presentation algorithms such as wireframe, shading and hidden line removal associated with a Drawer class which controls the attributes of the presentation to be created in terms of color, line type, thickness, and so on.
+
+<h4>Graphic2d and Graphic3d </h4>
+The *Graphic2d* and *Graphic3d* packages provide resources to create 2D and 3D graphic structures (please refer to chapters on 3D Resources and 2D Resources for more information).
+
+
+@subsubsection occt_1621831385_163370828213 A Basic Example: How to display a 3D object
+<h4>Example </h4>
+
+Void Standard_Real dx = ...; //Parameters Void Standard_Real dy = ...; //to build a wedge Void Standard_Real dz = ...; Void Standard_Real ltx = ...;
+
+Handle(V3d_Viewer)aViewer = ...; Handle(AIS_InteractiveContext)aContext; aContext = new AIS_InteractiveContext(aViewer);
+BRepPrimAPI_MakeWedge w(dx, dy, dz, ltx); TopoDS_Solid & = w.Solid(); Handle(AIS_Shape) anAis = new AIS_Shape(S); //creation of the presentable object aContext - Display(anAis); //Display the presentable object in the 3d viewer.
+
+The shape is created using the *BRepPrimAPI_MakeWedge* command. An AIS_Shape is then created from the shape. When calling the *Display *command, the interactive context calls the Compute method of the presentable object to calculate the presentation data and transfer it to the viewer. See Figure 2 below.
+
+** **
+
+
+
+
+
+
+
+
+
+**Figure 2. Processes involved in displaying a presentable shape**
+
+@subsection occt_1621831385_16337082822 Selection
+This chapter deals with the process used for selecting entities, which are displayed in the 2D space of the selection view.
+
+@subsubsection occt_1621831385_163370828221 The Selection Principle
+
+Objects that may be selected graphically, are displayed as sets of sensitive primitives, which provide sensitive zones in 2D graphic space. These zones are sorted according to their position on the screen when starting the selection process.
+The position of the mouse is also associated with a sensitive zone. When moving within the window where objects are displayed, the areas touched by the zone of the mouse are analyzed. The owners of these areas are then highlighted or signaled by other means such as the name of the object highlighted in a list. That way, you are informed of the identity of the element detected.
+
+
+**Figure 3. A model **
+
+
+**Figure 4. Modeling faces with sensitive primitives **
+
+
+**Figure 5. In a dynamic selection, each sensitive polygon is represented by its bounding rectangle**
+
+
+Figure 6. Reference to the sensitive primitive, then to the owner
+
+@subsubsection occt_1621831385_163370828222 The Sensitive Primitive
+
+The sensitive primitive - along with the entity owner - allow you to define what can be made selectable, and in so doing, provide the link between the applicative object and the sensitive zones defined by the 2D bounding boxes. For an object to be dynamically selectable, it has to be represented either as a sensitive primitive or a set of them. These give 2D boxes that will be included in a sorting algorithm.
+The use of 2D boxes allows a pre-selection of the detected entities. After pre-selection, the algorithm checks which sensitive primitives are actually detected. When detected, the primitives provide their owners’ identity.
+<h4>Example </h4>
+
+The sensitive line segment below proposes a bounding box to the selector. During selection, positions 1 and 2 of the mouse detect the box but after sorting, only position 2 retains the line segment as selected by the algorithm.
+
+
+**Figure 7. Example of sensitive primitives **
+
+When the 2D box associated with the position of the mouse intersects the 2D box of a sensitive primitive, the owner of the sensitive primitive is called and its presentation is highlighted.
+The notion of sensitive primitive is important for the developer when defining his own classes of sensitive primitives for the chosen selection modes. The classes must contain *Areas* and *Matches* functions. The former provides the list of 2D sensitive boxes representing the sensitive primitive at pre-selection and the latter determines if the detection of the primitive by the 2D boxes is valid.
+@subsubsection occt_1621831385_163370828223 The Principles of Dynamic Selection
+
+Dynamic selection causes objects in a view to be automatically highlighted as the mouse cursor moves over them. This allows the user to be certain that the picked object is the correct one. Dynamic Selection is based on the following two concepts:
+ * a Selectable Object (see *AIS_InteractiveObject*)
+ * an Interactive Context
+
+<h4>Selectable Object </h4>
+A selectable object presents a given number of selection modes which can be redefined, and which will be activated or deactivated in the selection manager’s selectors.
+
+*The term, selection mode of a selectable object, can refer to the selection mode of the object itself or to that of one of its parts.*
+
+For each selection mode, a *SelectMgr_Selection* object class is included in the selectable object. (Each selection mode establishes a priority of selection for each class of selectable object defined.)
+
+The notion of SELECTION is comparable to the notion of DISPLAY. Just as a display contains a set of graphic primitives that allow display of the entity in a specific display mode, a SELECTION contains a set of sensitive primitives, which allow detection of the entities they are associated with.
+
+<h4>Interactive Context</h4>
+See chapter 2, AIS: Application Interactive Services, Section 2.4
+
+The interactive context is used to manage both selectable objects and selection processes.
+
+Selection modes may be activated or de-activated for given selectable objects. Information is then provided about the status of activated/de-activated selection modes for a given object in a given selector.
+<h4>Example </h4>
+
+Let’s consider the 3D selectable shape object, which corresponds to a topological shape.
+
+For this class, seven selection modes can be defined:
+
+mode 0 - selection of the shape itself
+mode 1 - selection of vertices
+mode 2 - selection of edges
+mode 3 - selection of wires
+mode 4 - selection of faces
+mode 5 - selection of shells
+mode 6 - selection of solids
+mode 7 - selection of compounds
+
+Selection 2 includes the sensitive primitives that model all the edges of the shape. Each of these primitives contains a reference to the edge it represents.
+
+The selections may be calculated before any activation and are graph independent as long as they are not activated in a given selector. Activation of selection mode 3 in a selector associated with a view V leads to the projection of the 3D sensitive primitives contained in the selection; then the 2D areas which represent the 2D bounding boxes of these primitives are provided to the sorting process of the selector containing all the detectable areas.
+
+To deactivate selection mode 3 remove all those 2D areas.
+
+
+*Selection Packages *
+The selection packages are the following: *SelectBasics*, *SelectMgr*, *Select2D*, *Select3D*, *StdSelect*.
+
+*SelectBasics *
+The *SelectBasics* package contains the basic classes of the selection:
+ * the main definition of a sensitive primitive: *SensitiveEntity *
+ * the definition of a sensitive primitive owner: *EntityOwner *
+ * the algorithm used for sorting sensitive boxes: *SortAlgo *
+
+*EntityOwner* is used to establish a link from *SensitiveEntity* to application-level objects. For example, *SelectMgr_EntityOwner* (see below) class holds a pointer to corresponding *SelectableObject*.
+
+*SelectMgr *
+The *SelectMgr* package is used to manage the whole dynamic selection process. It contains the *SelectableObject**, Entity Owner containing a link to its SelectableObject,* *Selection*, *SelectionManager*, and *ViewSelector* classes.
+There are also implementations of *ViewerSelector* interface for 2D and 3D selection: *ViewerSelector2d* and *ViewerSelector3d*, respectively.
+
+*Select2D *
+The *Select2D* package contains the basic classes of 2D sensitive primitives such as Points, Segments, and Circles, which inherit from *SensitiveEntity* from *SelectBasics* and used to represent 2D selectable objects from a dynamic selection viewpoint.
+
+*Select3D *
+The *Select3D* package contains all 3D standard sensitive primitives such as point, curve and face. All these classes inherit from 3D *SensitiveEntry* from *SelectBasics* with an additional method, which allows recovery of the bounding boxes in the 2D graphic selection space, if required. This package also includes the 3D-2D projector.
+
+*StdSelect *
+The *StdSelect* package provides standard uses of the classes described above and main tools used to prevent the developer from redefining the selection objects. In particular, *StdSelect* includes standard means for selection of topological objects (shapes).
+
+@subsubsection occt_1621831385_163370828224 Methodology
+
+Several operations must be performed prior to using dynamic selection:
+**1. **Implement specific sensitive primitives if those defined in Select2D and Select3D are not sufficient. These primitives must inherit from *SensitiveEntity* from *SelectBasics* or from a suitable Select3D sensitive entity class when a projection from 3D to 2D is necessary.
+**2. **Define all the owner types, which will be used, and the classes of selectable objects, i.e. the number of possible selection modes for these objects and the calculation of the decomposition of the object into sensitive primitives of all the primitives describing this mode. It is possible to define only one default selection mode for a selectable object if this object is to be selectable in a unique way.
+**3. **Install the process, which provides the user with the identity of the owner of the detected entities in the selection loop.
+
+When all these steps have been carried out, follow the procedure below:
+**1. **Create an interactive context.
+**2. **Create the selectable objects and calculate their various possible selections.
+**3. **Load these selectable objects in the interactive context. The objects may be common to all the selectors, i.e. they will be seen by all the selectors in the selection manager, or local to one selector or more.
+**4. **Activate or deactivate the objects’ selection modes in the selector(s). When activating a selection mode in a selector for a given object, the manager sends the order to make the sensitive primitives in this selector selectable. If the primitives are to projected from 3D to 2D, the selector calls the specific method used to carry out this projection.
+
+At this stage, the selection of selectable entities in the selectors is available.
+The selection loop informs constantly the selectors with the position of the mouse and questions them about the detected entities.
+
+
+@subsubsection occt_1621831385_163370828225 Example of Use
+
+Let’s suppose you are creating an application that displays houses in a viewer of the V3d package and you want to select houses or parts of these houses (windows, doors, etc.) in the graphic window.
+You define a selectable object called *House* and propose four possible selection modes for this object:
+**1 -** selection of the house itself
+**2 -** selection of the rooms
+**3 -** selection of the walls
+**4 - **selection of the doors.
+
+You have to write the method, which calculates the four selections above, i.e. the sensitive primitives which are activated when the mode is.
+You must define the class *Owner* specific to your application. This class will contain the reference to the house element it represents: wall, door or room. It inherits from *EntityOwner* from *SelectMgr*.
+For example, let’s consider a house with the following representation:
+
+**Figure 8. Selection of the rooms of a house**
+
+To build the selection, which corresponds to the mode *selection of the rooms* (selection 2 in the list of selection modes) use the following procedure:
+<h4>Example </h4>
+
+Void House::ComputeSelection
+(Const Handle(SelectMgr_Selection)& Sel,
+ const Standard_Integer mode {
+ switch(mode){ case 0: //Selection of the rooms { for(Standard_Integer i = 1; i = myNbRooms; i++) { //for every room, create an instance of the owner
+ //along with the given room and its name. Handle(RoomOwner) aRoomOwner = new RoomOwner (Room(i), NameRoom(i)); //Room() returns a room and NameRoom() returns its name.
+Handle(Select3d_SensitiveBox) aSensitiveBox;
+aSensitiveBox = new Select3d_SensitiveBox
+(aRoomOwner, Xmin, Ymin, Zmin, Xmax, Ymax, Zmax);
+ Sel - Add(aSensitiveBox); } break; Case 1: ... //Selection of the doors } //Switch
+) // ComputeSelection
+
+
+
+**Figure 9. Activated sensitive boxes corresponding to selection mode 0 (selection of the rooms)**
+
+
+
+**Figure 11. Activated sensitive polygons corresponding to selection mode 1.**
+
+**(selection of the doors)**
+
+
+**Figure 12. Sensitive rectangles in the selector during dynamic selection in view 2**
+@section occt_1621831385_810308609 AIS: Application Interactive Services
+Application Interactive Services (**AIS**) offers a set of general services beyond those offered by basic Selection and Presentation packages such as **PrsMgr**, **SelectMgr** and **StdSelect**. These allow you to manage presentations and dynamic selection in a viewer simply and transparently. To use these services optimally, you should know various rules and conventions. Section I provides an overview of the important classes which you need to manipulate AIS well. Sections 2 and 3 explain in detail how to use them and how to implement them, as well as the rules and conventions to respect. The annexes offer various standard Interactive Objects in AIS, an example of an implementation of AIS and a reminder of how to manage presentation and selection.
+
+@subsection occt_1621831385_8103086091 Overview
+
+@subsubsection occt_1621831385_81030860911 Interactive Context/Local Context
+<h4>AIS_InteractiveContext </h4>
+The central entity, which pilots visualizations and selections, is the Interactive Context. It is linked to a main viewer (and if need be, a trash bin viewer.) It has two operating modes: the Neutral Point and the local visualization and selection context. The neutral point, which is the default mode, allows you to easily visualize and select interactive objects, which have been loaded into the context. Opening Local Contexts allows you to prepare and use a temporary selection environment without disturbing the neutral point. A set of functions allows you to choose the interactive objects, which you want to act on, the selection modes, which you want to activate, and the temporary visualizations, which you will execute. When the operation is finished, you close the current local context and return to the state in which you were before opening it (neutral point or previous local context).
+
+@subsubsection occt_1621831385_81030860912 The Interactive Object
+
+<h4>AIS_InteractiveObject</h4>
+Entities, which are visualized and selected, are Interactive Objects. You can use classes of standard interactive objects for which all necessary functions have already been programmed, or you can implement your own classes of interactive objects, by respecting a certain number of rules and conventions described below.
+
+@subsubsection occt_1621831385_81030860913 Graphic Attributes Manager or *Drawer*
+
+
+An Interactive Object can have a certain number of graphic attributes specific to it (such as visualization mode, color and material) By the same token, the Interactive Context has a drawer which is valid by default for the objects it controls. When an interactive object is visualized, the required graphic attributes are first taken from its own Drawer if it has the ones required, or from the context drawer if it does not have them.
+
+@subsubsection occt_1621831385_81030860914 Selection Filters
+
+
+
+An important need in selection is the filtering of entities, which you want to select. Consequently there are FILTER entities, which 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 only in an open local context. A user will be able to program his own filters and load them into the interactive context.
+
+@subsection occt_1621831385_8103086092 Rules and Conventions Governing Interactive Objects
+ An interactive object is a *virtual* entity, which can be presented and selected. It can also have its own visualization aspects such as color, material, and mode of visualization. In order to create and manipulate the interactive objects with ease, you must know the rules and conventions, which have been established. Several *virtual* functions must be implemented for these objects to have the behavior expected of them. A certain number of standard interactive objects, which respect the rules and conventions described below, have been implemented in AIS. The current list of them can be found in ANNEX I. The services that concern manipulation of presentations, selection and graphic attributes will be treated separately.
+
+
+@subsubsection occt_1621831385_81030860921 Presentations:
+
+
+*Conventions *
+ * Either in 2D or in 3D, an interactive object can have as many presentations as its creator wants to give it.
+ * 3D presentations are managed by PresentationManager3D; 2D presentations by PresentationManager2D. As this is transparent in AIS, the user does not have to worry about it.
+ * A presentation is identified by an index and by the reference to the Presentation Manager which it depends on.
+ * By convention, the default mode of representation for the Interactive Object has index 0.
+
+*Virtual functions *
+
+Calculation of different presentations of an interactive object is done in the *Compute *functions inheriting from *PrsMgr_ PresentableObject::Compute *functions. They are automatically called by *PresentationManager* at a visualization or an update request.
+
+If you are creating your own type of interactive object, you must implement the Compute function in one of the following ways:
+
+ * **For 2D: **
+<h4>Example </h4>
+
+void PackageName_ClassName::Compute
+(const Handle(PrsMgr_PresentationManager2d)&
+aPresentationManager,
+ const Handle(Graphic2d_GraphicObject)& aGraphicObject,
+ const Standard_Integer aMode = 0);
+ * **For 3D: **
+<h4>Example </h4>
+
+void PackageName_ClassName::Compute
+(const Handle(PrsMgr_PresentationManager3d)&
+aPresentationManager,
+ const Handle(Prs3d_Presentation)& aPresentation,
+ const Standard_Integer aMode = 0);
+
+ * **For hidden line removal (HLR) mode in 3D (*): **
+<h4>Example </h4>
+
+void PackageName_ClassName::Compute
+(const Handle(Prs3d_Projector)& aProjector,
+ const Handle(Prs3d_Presentation)& aPresentation);
+
+
+*WARNING (*) *
+As its call is automatically ordered by a view, this function requires explanation; the view has two states: degenerate mode (normal mode) and non-degenerate mode (Hidden line mode). When the latter is active, the view looks for all presentations displayed in normal mode, which have been signaled as accepting hidden line mode. An internal mechanism allows us to call the interactive object’s own *Compute*, that is, projector, function. How do you declare that such and such a presentation will accept an *equivalent* in hidden line mode? By convention, it is the Interactive Object, which accepts or rejects the representation of hidden-line mode. You can make this declaration in one of two ways, either initially by using one of the values of the enumeration PrsMgr_TypeOfPresentation:
+ * PrsMgr_TOP_AllView,
+ * PrsMgr_TOP_ProjectorDependant
+
+or later on, by using the function:
+ * * PrsMgr_PresentableObject::SetTypeOfPresentation
+
+@subsubsection occt_1621831385_81030860922 Important Specifics of AIS:
+
+There are four types of interactive object in AIS:
+ * the *construction element* or Datum,
+ * the Relation (dimensions and constraints)
+ * the Object
+ * the None type (when the object is of an unknown type).
+
+Inside these categories, additional characterization is available by means of a signature (an index.) By default, the interactive object has a NONE type and a signature of 0 (equivalent to NONE.) If you want to give a particular type and signature to your interactive object, you must redefine two virtual functions:
+
+ * AIS_InteractiveObject::Type
+ * AIS_InteractiveObject::Signature.
+
+
+<h4>WARNING </h4>
+Some signatures have already been used by *standard* objects delivered in AIS. (see the list of standard objects, Annex I.)
+
+As will be seen below, the interactive context can have a default mode of representation for the set of interactive objects. This mode may not be accepted by a given class of objects. Consequently, a virtual function allowing you to get information about this class must be implemented:
+ * AIS_InteractiveObject::AcceptDisplayMode.
+
+<h5>Services You Should Know </h5>
+Display Mode: An object can have its own display mode, which is different from that proposed by the interactive context. The functions to use are:
+ * AIS_InteractiveContext::SetDisplayMode
+ * AIS_InteractiveContext::UnsetDisplayMode.
+
+Hilight Mode: At dynamic detection, the presentation echoed by the Interactive Context, is by default the presentation already on the screen. You can always specify the display mode used for highlighting purposes (so called highlight mode), which is valid no matter what the active representation of the object. It makes no difference whether this choice is temporary or definitive. To do this, you use the following functions:
+ * AIS_InteractiveObject::SetHilightMode
+ * AIS_InteractiveObject::UnSetHilightMode
+
+Note that the same presentation (and consequently the same highlight mode) is used for highlighting *detected* objects and for highlighting *selected* objects, the latter being drawn with a special *selection color *(refer to the section related to *Interactive Context* services).
+
+An example: For a shape - whether it is visualized in wireframe presentation or with shading - you want to systematically highlight the wireframe presentation. Consequently, you set the highlight mode to *0 *in the constructor of the interactive object. You mustn’t forget to effect the implementation of this representation mode in the *Compute* functions.
+
+Infinite Status: If you don’t want an object to be affected by a FitAll view, you must declare it infinite; you can cancel its *infinite* status in the same way.
+ * AIS_InteractiveObject::SetInfiniteState
+ * AIS_InteractiveObject::IsInfinite
+<h4>Example </h4>
+
+Let’s take the case of a class called IShape, representing an interactive object
+myPk_IShape::myPK_IShape
+(const TopoDS_Shape& SH, PrsMgr_TypeOfPresentation aType):
+
+AIS_InteractiveObject(aType), myShape(SH), myDrwr(new AIS_Drawer()) {
+SetHilightMode(0);
+}
+void myPk_IShape::Compute
+(const Handle(PrsMgr_PresentationManager3d) & PM, const Handle(Prs3d_Presentation)& P, const Standard_Integer TheMode)
+{
+switch (TheMode){
+
+case 0:
+StdPrs_WFDeflectionShape::Add (P,myShape,myDrwr);
+//algo for calculation of wireframe presentation break;
+
+case 1:
+StdPrs_ShadedShape::Add (P,myShape,myDrwr); //algo for calculation of shading presentation. break;
+}
+}
+void myPk_IsShape::Compute
+(const Handle(Prs3d_Projector)& Prj,
+const Handle(Prs3d_Presentation) P)
+{
+StdPrs_HLRPolyShape::Add(P,myShape,myDrwr);
+//Cas-cade hidden line mode calculation algorithm
+}
+
+
+
+@subsection occt_1621831385_8103086093 Selections
+@subsubsection occt_1621831385_81030860931 Conventions
+
+An interactive object can have an indefinite number of modes of selection, each representing a *decomposition* into sensitive primitives; each primitive has an Owner (*SelectMgr_EntityOwner*) which allows us to identify the exact entity which has been detected (see ANNEX II).
+
+The set of sensitive primitives, which correspond to a given mode, is stocked in a SELECTION (*SelectMgr_Selection*).
+
+Each Selection mode is identified by an index. By Convention, the default selection mode that allows us to grasp the Interactive object in its entirety is mode *0*.
+
+@subsubsection occt_1621831385_81030860932 Virtual functions
+
+The calculation of Selection primitives (or sensitive primitives) is done by the intermediary of a virtual function, *ComputeSelection*. This should be implemented for each type of interactive object on which you want to make different type selections using the following function:
+
+ * AIS_ConnectedInteractive::ComputeSelection
+
+A detailed explanation of the mechanism and the manner of implementing this function has been given in ANNEX II.
+
+Moreover, just as the most frequently manipulated entity is TopoDS_Shape, the most used Interactive Object is AIS_Shape. You will see below that activation functions for standard selection modes are proposed in the Interactive context (selection by vertex, by edges etc.). To create new classes of interactive object with the same behavior as AIS_Shape - such as vertices and edges - you must redefine the virtual function:
+
+ * AIS_ConnectedInteractive::AcceptShapeDecomposition.
+
+
+
+@subsubsection occt_1621831385_81030860933 Other Services
+You can change the default selection mode index of an Interactive Object. For instance, you can:
+ * check to see if there is a selection mode
+ * check the current selection mode
+ * set a selection mode
+ * unset a selection mode.
+ The following functions are concerned:
+
+ * AIS_InteractiveObject::HasSelectionMode
+ * AIS_InteractiveObject::SelectionMode
+ * AIS_InteractiveContext::SetSelectionMode
+ * AIS_InteractiveContext::UnsetSelectionMode
+
+These functions are only of interest if you decide that the *0* mode adopted by convention will not do. In the same way, you can temporarily change the priority of certain interactive objects for selection of 0 mode. You could do this to make it easier to detect them graphically. You can:
+ * check to see if there is a selection priority setting for the owner
+ * check the current priority
+ * set a priority
+ * unset the priority.
+
+To do this, you use the following functions:
+ * AIS_InteractiveObject::HasSelectionPriority
+ * AIS_InteractiveObject::SelectionPriority
+ * AIS_InteractiveObject::SetSelectionPriority
+ * AIS_InteractiveObject::UnsetSelectionPriority
+
+
+
+@subsection occt_1621831385_8103086094 Graphic attributes of an interactive object
+
+Keep in mind the following points concerning graphic attributes:
+ * Each interactive object can have its own visualization attributes.
+ * The set of graphic attributes of an interactive object is stocked in an *AIS_Drawer*, which is only a *Prs3d_Drawer* with the possibility of a link to another drawer
+ * By default, the interactive object takes the graphic attributes of the context in which it is visualized (visualization mode, deflection values for the calculation of presentations, number of isoparameters, color, type of line, material, etc.)
+ * In the *AIS_InteractiveObject* abstract class, several standard attributes have been privileged. These include: color, thickness of line, material, and transparency. Consequently, a certain number of virtual functions, which allow us to act on these attributes, have been proposed. Each new class of interactive object can redefine these functions in order to bring about the changes it should produce in the behavior of the class.
+
+
+
+**Figure 13. Redefinition of virtual functions for changes in AIS_Point **
+
+
+**Figure 14. **Redefinition** of virtual functions for changes in AIS_Shape.**
+
+The virtual functions concerned here allow you to provide settings for:
+ * color
+ * width
+ * material
+ * transparency
+
+The functions concerned are the following:
+
+ * AIS_InteractiveObject::UnsetColor
+ * AIS_InteractiveObject::SetWidth
+ * AIS_InteractiveObject::UnsetWidth
+ * AIS_InteractiveObject::SetMaterial (const Graphic3d_NameOfPhysicalMaterial & aName)
+ * AIS_InteractiveObject::SetMaterial (const Graphic3d_MaterialAspect & aMat)
+ * AIS_InteractiveObject::UnsetMaterial
+ * AIS_InteractiveObject::SetTransparency
+ * AIS_InteractiveObject::UnsetTransparency
+
+For other types of attribute, it is appropriate to change the Drawer of the object directly using:
+
+ * AIS_InteractiveObject::SetAttributes
+ * AIS_InteractiveObject::UnsetAttributes
+
+
+@subsubsection occt_1621831385_81030860941 Manipulation of Attributes
+
+Some of these functions may imply the recalculation of presentations of the object. It is important to know which ones. If an interactive object’s presentation mode is to be updated, a flag from *PrsMgr_PresentableObject* indicates this. The mode should be updated using the functions *Display* and *Redisplay* in *AIS_InteractiveContext*.
+
+@subsection occt_1621831385_8103086095 Complementary Services - Precautions
+
+@subsubsection occt_1621831385_81030860951 Changing an interactive object’s location
+
+When using complementary services for interactive objects, pay special attention to the following cases:
+Functions allowing us to temporarily *move* the representation and selection of Interactive Objects in a view without recalculation.
+ * AIS_InteractiveContext::SetLocation
+ * AIS_InteractiveContext::ResetLocation
+ * AIS_InteractiveContext::HasLocation
+ * AIS_InteractiveContext::Location
+
+How you link applicative entities to interactive objects.
+
+
+@subsubsection occt_1621831385_810308609552 Connecting an interactive object to an applicative entity
+
+Each Interactive Object has functions that allow us to attribute it an Owner in the form of a Transient.
+ * AIS_InteractiveObject::SetOwner
+ * AIS_InteractiveObject::HasOwner
+ * AIS_InteractiveObject::Owner
+
+An interactive object can therefore be associated with an applicative entity or not, without this affecting its behavior.
+
+@subsubsection occt_1621831385_810308609553 Resolving coincident topology
+
+Due to the fact that the accuracy of three-dimensional graphics coordinates has a finite resolution the elements of topological objects can coincide producing the effect of *popping* some elements one over another.
+
+To avoid such kind of a problem when the elements of two or more InteractiveObjects are coincident you can apply the polygon offset. It is a sort of graphics computational offset, or depth buffer offset, that allows you to arrange elements (by modifying their depth value) without changing their coordinates. The graphical elements that accept this kind of offsets are solid polygons or displayed as boundary lines and points. The polygons could be displayed as lines or points by setting the appropriate interior style.
+
+The following method allows you to set up the polygon offsets:
+ * void AIS_InteractiveObject::SetPolygonOffsets
+(const Standard_Integer aMode,
+ const Standard_Real aFactor,
+ const Standard_Real aUnits)
+The parameter aMode can contain various combinations of Aspect_PolygonOffsetMode enumeration elements. The enumeration has the following elements:
+ * Aspect_POM_None
+ * Aspect_POM_Off
+ * Aspect_POM_Fill
+ * Aspect_POM_Line
+ * Aspect_POM_Point
+ * Aspect_POM_All
+
+The combination of these elements defines the polygon display modes that will use the given offsets. You can switch off the polygon offsets by passing the Aspect_POM_Off. Passing Aspect_POM_None allows you to change the aFactor and aUnits values without changing the mode. If aMode is different from Aspect_POM_Off, the aFactor and aUnits arguments are used by the graphics renderer to calculate the depth offset value:
+ offset = aFactor * m + aUnits * r,
+ where m – maximum depth slope for the polygons currently being displayed, r – minimum depth resolution (implementation-specific)
+
+Negative offset values move polygons closer to the viewer while positive values shift polygons away.
+
+**WARNING**
+This method has a side effect – it creates its own shading aspect if not yet created, so it is better to set up the object shading aspect first.
+
+You can use the following functions to obtain the current settings for polygon offsets:
+ * void AIS_InteractiveObject::PolygonOffsets
+(Standard_Integer &aMode,
+ Standard_Real &aFactor,
+ Standard_Real &aUnits)
+ * Standard_Boolean
+AIS_InteractiveObject::HasPolygonOffsets()
+
+The same operation could be performed for the interactive object known by the AIS_InteractiveContext with the following methods:
+ * void AIS_InteractiveContext::SetPolygonOffsets
+(const Handle(AIS_InteractiveObject) &anObj,
+ const Standard_Integer aMode,
+ const Standard_Real aFactor,
+ const Standard_Real aUnits)
+ * void AIS_InteractiveContext::PolygonOffsets
+(const Handle(AIS_InteractiveObject) &anObj,
+ Standard_Integer &aMode,
+ Standard_Real &aFactor,
+ Standard_Real &aUnits)
+ * Standard_Boolean AIS_InteractiveContext::HasPolygonOffsets
+(const Handle(AIS_InteractiveObject) &anObj)
+
+@subsection occt_1621831385_8103086096 The Interactive Context
+
+@subsubsection occt_1621831385_810308609661 Preliminary Rules
+
+The Interactive Context allows us to manage in a transparent way, the graphic and *selectable* behavior of interactive objects in one or more viewers. Most functions which allow us to modify the attributes of interactive objects, and which were presented in the preceding chapter, will be looked at again here.
+
+There is one essential rule to follow: the modification of an interactive object, which is already known by the Context, must be done using Context functions. You can only directly call the functions available for an interactive object if it has not been loaded into an Interactive Context.
+
+<h4>Example </h4>
+
+Handle (AIS_Shape) TheAISShape = new AIS_Shape (ashape); myIntContext-Display(TheAISShape);
+myIntContext-SetDisplayMode(TheAISShape ,1);
+myIntContext-SetColor(TheAISShape,Quantity_NOC_RED);
+
+//but you can write
+
+Handle (AIS_Shape) TheAISShape = new AIS_Shape (ashape); TheAISShape-SetColor(Quantity_NOC_RED);
+TheAISShape-SetDisplayMode(1);
+myIntContext-Display(TheAISShape);
+
+
+@subsubsection occt_1621831385_810308609662 Groups of functions
+
+You must distinguish two states in the Interactive Context:
+§ No Open Local Context; which will be referred to as Neutral Point.
+§ One or several open local contexts, each representing a temporary state of selection and presentation.
+
+Some functions can only be used in open Local Context; others in closed local context; others do not have the same behavior in one state as in the other.
+
+The Interactive Context is composed of a great many functions, which can be conveniently grouped according to theme:
+ * management proper to the context
+ * management in the local context
+ * presentations and selection in open/closed context
+ * selection strictly speaking
+
+
+@subsubsection occt_1621831385_810308609663 Management proper to the Interactive Context
+
+The Interactive Context is made up of a Principal Viewer and, optionally, a trash bin or *Collector* Viewer. It also has a group of adjustable settings allowing you to personalize the behavior of presentations and selections:
+ * Default Drawer, containing all the color and line attributes which can be used by interactive objects, which do not have their own attributes.
+ * Default Visualization Mode for interactive objects
+Default: mode 0
+ * Highlight color of entities detected by mouse movement
+Default: Quantity_NOC_CYAN1
+ * Preselection color
+Default: Quantity_NOC_GREEN
+ * Selection color (when you click on a detected object)
+Default: Quantity_NOC_GRAY80
+ * Sub-Intensity color
+Default: Quantity_NOC_GRAY40
+
+All of these settings can be modified by functions proper to the Context.
+
+When you change a graphic attribute pertaining to the Context (visualization mode, for example), all interactive objects, which do not have the corresponding appropriate attribute, are updated.
+<h4>Example </h4>
+
+//obj1, obj2: 2 interactive objects.
+
+TheCtx-Display(obj1,Standard_False); // False = no update
+of viewer.
+TheCtx-Display(obj2,Standard_True); // True = Update of
+Viewer
+TheCtx-SetDisplayMode(obj1,3,Standard_False);
+TheCtx-SetDisplayMode(2);
+// obj2 is visualised in mode 2 (if it accepts this mode)
+// obj1 stays visualised in its mode 3.
+
+To the main Viewer, are associated a *PresentationManager3D* and a *Selector3D *which manage the presentation and selection of present interactive objects. The same is true of the optional Collector. As we shall see, this management is completely transparent for the user.
+
+
+@subsection occt_1621831385_8103086097 Management of Local Context
+
+@subsubsection occt_1621831385_810308609771 Rules and Conventions
+
+ * Opening a local context allows you to prepare an environment for temporary presentations and selections, which will disappear once the local context is closed.
+ * It is possible to open several local contexts, but only the last one will be active.
+ * When you close a local context, the one before, which is still on the stack, reactivates. If none is left, you return to Neutral Point.
+ * Each local context has an index created when the context opens. You should close the local context, which you have opened.
+
+@subsubsection occt_1621831385_810308609772 Important functionality
+
+The interactive object, which is used the most by applications, is *AIS_Shape*. Consequently, standard functions are available which allow you to easily prepare selection operations on the constituent elements of shapes (selection of vertices, edges, faces etc) in an open local context. The selection modes specific to *Shape* type objects are called **Standard Activation Mode**. These modes are only taken into account in open local context and only act on interactive objects which have redefined the virtual function *AcceptShapeDecomposition() *so that it returns *TRUE*.
+ * Objects, which are temporarily in a local context, are not recognized by other local contexts a priori. Only objects visualized in Neutral Point are recognized by all local contexts.
+ * The state of a temporary interactive object in a local context can only be modified while another local context is open (except for one special case - see III.4.2)
+
+<h4>WARNING </h4>
+The specific modes of selection only concern the interactive objects, which are present in the Main Viewer. In the Collector, you can only locate interactive objects, which answer positively to the positioned filters when a local context is open. Under no circumstances are they decomposed in standard mode etc.
+
+@subsubsection occt_1621831385_810308609773 Use
+Opening and closing a local context are easy to put into operation:
+
+ * AIS_InteractiveContext::OpenLocalContext
+
+The options available allow you to control what you want to do:
+ * *UseDisplayedObjects*: allows you to load or not load the interactive objects visualized at Neutral Point in the local context, which you open. If* FALSE*, the local context is empty after being opened. If *TRUE*, the objects at Neutral Point are modified by their default selection mode.
+ * *AllowShapeDecomposition*: AIS_Shape allows or prevents decomposition in standard shape location mode of objects at Neutral Point, which are type-*privileged* (see selection chapter). This Flag is only taken into account when *UseDisplayedObjects* is *TRUE*.
+ * *AcceptEraseOfObjects*: authorises other local contexts to erase the interactive objects present in this context. This option is rarely used. The last option has no current use.
+
+This function returns the index of the created local context. It should be kept and used when the context is closed.
+
+To load objects visualized at Neutral Point into a local context or remove them from one:
+ * AIS_InteractiveContext::UseDisplayedObjects
+ * AIS_InteractiveContext::NotUseDisplayedObjects
+
+Closing Local Contexts is done by:
+ * AIS_InteractiveContext::CloseLocalContext
+ * AIS_InteractiveContext::CloseAllContexts
+
+*WARNING *
+
+When the index isn’t specified in the first function, the current Context is closed. This option can be dangerous, as other Interactive Functions can open local contexts without necessarily warning the user. For greater security, you have to close the context with the index given on opening.
+
+To get the index of the current context, use the following function:
+
+ * AIS_InteractiveContext::IndexOfCurrentLocal
+
+The second function allows you to close all open local contexts at one go. In this case, you find yourself directly at Neutral Point.
+
+When you close a local context, all temporary interactive objects are erased (deleted), all selection modes concerning the context are cancelled, and all content filters are emptied.
+
+
+
+@subsubsection occt_1621831385_810308609774 Management of Presentations and Selections
+
+You must distinguish between the Neutral Point and the Open Local Context states. Although the majority of visualization functions can be used in both situations, their behavior is different:
+
+@subsubsection occt_1621831385_810308609775 Presentation in Neutral Point
+
+Neutral Point should be used to visualize the interactive objects, which represent and select an applicative entity. Visualization and Erasing orders are straightforward:
+
+ * AIS_InteractiveContext::Display
+(const Handle(AIS_InteractiveObject)& anIobj,
+ const Standard_Boolean updateviewer=Standard_True);
+
+ * AIS_InteractiveContext::Display
+(const Handle(AIS_InteractiveObject)& anIobj,
+ const Standard_Integer amode,
+ const Standard_Integer aSelectionMode,
+ const Standard_Boolean
+updateviewer = Standard_True,
+ const Standard_Boolean
+allowdecomposition = Standard_True);
+
+ * AIS_InteractiveContext::Erase
+ * AIS_InteractiveContext::EraseMode
+ * AIS_InteractiveContext::ClearPrs
+ * AIS_InteractiveContext::Redisplay
+ * AIS_InteractiveContext::Remove
+ * AIS_InteractiveContext::EraseAll
+ * AIS_InteractiveContext::Hilight
+ * AIS_InteractiveContext::HilightWithColor
+
+@subsubsection occt_1621831385_810308609776 Important Remarks:
+
+Bear in mind the following points:
+ * It is recommended to display and erase interactive objects when no local context is opened, and open a local context for local selection only.
+ * The first **Display** function among the two ones available in *InteractiveContext* visualizes the object in its default mode (set with help of SetDisplayMode() method of InteractiveObject prior to Display() call), or in the default context mode, if applicable. If it has neither, the function displays it in 0 presentation mode. The object’s default selection mode is automatically activated (0 mode by convention).
+ * Activating the displayed object by default can be turned off with help of **SetAutoActivateSelection**() method. This might be efficient if you are not interested in selection immediately after displaying an object.
+ * The second **Display** function should only be used in Neutral Point to visualize a supplementary mode for the object, which you can erase by EraseMode (...). You activate the selection mode. This is passed as an argument. By convention, if you do not want to activate a selection mode, you must set the *SelectionMode *argument to the value of -1. This function is especially interesting in open local context, as we will see below.
+ * In Neutral Point, it is unadvisable to activate other selection modes than the default selection one. It is preferable to open a local context in order to activate particular selection modes.
+ * When you call **Erase **(Interactive object) function, the *PutIncollector* argument, which is FALSE by default, allows you to visualize the object directly in the Collector and makes it selectable (by activation of 0 mode). You can nonetheless block its passage through the Collector by changing the value of this option. In this case, the object is present in the Interactive Context, but is not seen anywhere.
+ * **Erase**() with *putInCollector* = Standard_True** might be slow as it re-computes the objects presentation in the Collector. Set putInCollector to Standard_False if you simply want to hide the object’s presentation temporarily.
+ * Modifications of visualization attributes and graphic behavior is effected through a set of functions similar to those which are available for the interactive object (color, thickness of line, material, transparency, locations etc.) The context then manages immediate and deferred updates.
+ * Call **Remove**() method of *InteractiveContext* as soon as the interactive object is no longer needed and you want to destroy it.. Otherwise, references to *InteractiveObject* are kept by *InteractiveContext*, and the *Object* is not destroyed that results in memory leaks. In general, if some interactive object’s presentation can be computed quickly, it is recommended to **Remove**() it instead of **Erase**()-ing.
+
+@subsubsection occt_1621831385_810308609777 Presentation in Local Context
+
+In open local context, the Display functions presented above apply as well.
+
+<h4>WARNING </h4>
+The function, AIS_InteractiveObject::Display, automatically activates the object’s default selection mode. When you only want to visualize an Interactive Object in open Context, you must call the second function:
+
+AIS_InteractiveContext::Display.
+
+You can activate or deactivate specific selection modes in local open context in several different ways:
+Use the Display functions with the appropriate modes
+Activate standard mode:
+
+ * AIS_InteractiveContext::ActivateStandardMode
+only if a local Context is opened
+
+ * AIS_InteractiveContext::DeactivateStandardMode
+
+ * AIS_InteractiveContext::ActivatedStandardModes
+
+ * AIS_InteractiveContext::SetShapeDecomposition
+
+This has the effect of activating the corresponding selection mode for all objects in Local Context, which accept decomposition into sub-shapes. Every new Object which has been loaded into the interactive context and which answers these decomposition criteria is automatically activated according to these modes.
+
+<h4>WARNING </h4>
+If you have opened a local context by loading an object with the default options (AllowShapeDecomposition = Standard_True), all objects of the *Shape* type are also activated with the same modes. You can act on the state of these *Standard* objects by using SetShapeDecomposition(Status).
+
+Load an interactive object by the following function:
+
+ * AIS_InteractiveContext::Load.
+
+This function allows you to load an Interactive Object whether it is visualized or not with a given selection mode, and/or with the desired decomposition option. If *AllowDecomp=TRUE* and obviously, if the interactive object is of the *Shape* type, these *standard* selection modes will be automatically activated as a function of the modes present in the Local Context.
+
+Directly activate/deactivate selection modes on an object:
+
+ * AIS_InteractiveContext::Activate
+ * AIS_InteractiveContext::Deactivate.
+
+
+
+
+
+
+
+
+@subsubsection occt_1621831385_810308609778 Use of Filters
+
+When Interactive objects have been *prepared* in local context, you can add rejection filters. The root class of objects is *SelectMgr_Filter*. The principle behind it is straightforward: a filter tests to see whether the owners (*SelectMgr_EntityOwner*) detected in mouse position by the Local context selector answer *OK*. If so, it is kept; if not, it is rejected.
+
+You can therefore create your own class of filter objects by implementing the deferred function *IsOk()*:
+<h4>Example </h4>
+
+class MyFilter : public SelectMgr_Filter {
+};
+virtual Standard_Boolean MyFilter::IsOk
+(const Handle(SelectMgr_EntityOwner)& anObj) const = 0;
+
+
+In *SelectMgr*, there are also Composition filters (AND Filters, OR Filters), which allow you to combine several filters. In InteractiveContext , all filters that you add are stocked in an OR filter (which answers *OK* if at least one filter answers *OK*).
+
+There are Standard filters, which have already been implemented in several packages:
+
+ * StdSelect_EdgeFilter
+Filters acting on edges such as lines and circles
+ * StdSelect_FaceFilter
+Filters acting on faces such as planes, cylinders and spheres
+ * StdSelect_ShapeTypeFilter
+Filters shape types such as compounds, solids, shells and wires
+ * AIS_TypeFilter
+Acts on types of interactive objects
+ * AIS_SignatureFilter
+Acts on types and signatures of interactive objects
+ * AIS_AttributeFilter
+Acts on attributes of Interactive Objects such as color and width
+
+Because there are specific behaviors on shapes, each new Filter class must, if necessary, redefine a function, which allows a Local Context to know if it acts on specific types of sub-shapes:
+
+ * AIS_LocalContext::ActsOn.
+
+By default, this function answers *FALSE*.
+
+*WARNING *
+Only type filters are activated in Neutral Point. This is to make it possible to identify a specific type of visualized object. For filters to come into play, one or more object selection modes must be activated.
+
+There are several functions to manipulate filters:
+
+ * AIS_InteractiveContext::AddFilter
+
+to add a filter passed as an argument.
+
+ * AIS_InteractiveContext::RemoveFilter
+
+to remove a filter passed as an argument.
+
+ * AIS_InteractiveContext::RemoveFilters
+
+to remove all filters present.
+
+ * AIS_InteractiveContext::Filters
+
+to get the list of filters active in a local context.
+<h4>Example </h4>
+
+myContext-OpenLocalContext(Standard_False);
+// no object in neutral point is loaded
+
+myContext-ActivateStandardMode(TopAbs_Face);
+//activates decomposition of shapes into faces.
+Handle (AIS_Shape) myAIShape = new AIS_Shape ( ATopoShape);
+
+myContext-Display(myAIShape,1,-1,Standard_True,Standard_True); //shading visualization mode, no specific mode, authorization for //decomposition into sub-shapes. At this Stage, myAIShape is decomposed into faces...
+
+Handle(StdSelect_FaceFilter) Fil1= new
+StdSelect_FaceFilter(StdSelect_Revol);
+Handle(StdSelect_FaceFilter) Fil2= new
+ StdSelect_FaceFilter(StdSelect_Plane);
+
+myContext-AddFilter(Fil1); myContext-AddFilter(Fil2); //only faces of revolution or planar faces will be selected
+ *
+myContext-MoveTo( xpix,ypix,Vue);
+// detects of mouse position
+
+
+@subsubsection occt_1621831385_810308609779 Selection Strictly Speaking.
+Dynamic detection and selection are put into effect in a straightforward way. There are only a few conventions and functions to be familiar with. The functions are the same in neutral point and in open local context:
+
+ * AIS_InteractiveContext::MoveTo
+passes mouse position to Interactive Context selectors
+ * AIS_InteractiveContext::Select
+stocks what has been detected on the last MoveTo. Replaces the previously selected object. Empties the stack if nothing has been detected at the last move
+ * AIS_InteractiveContext::ShiftSelect
+if the object detected at the last move was not already selected , it is added to the list of those selected. If not, it is withdrawn. Nothing happens if you click on an empty area.
+ * AIS_InteractiveContext::Select
+selects everything found in the surrounding area
+ * AIS_InteractiveContext::ShiftSelect
+selects what was not previously in the list of selected, deselects those already present.
+
+Highlighting of detected and selected entities is automatically managed by the Interactive Context, whether you are in neutral point or Local Context. The Highlight colors are those dealt with above. You can nonetheless disconnect this automatic mode if you want to manage this part yourself:
+
+ * AIS_InteractiveContext::SetAutomaticHilight
+ * AIS_InteractiveContext::AutomaticHilight
+
+
+If there is no open local context, the objects selected are called CURRENT OBJECTS; SELECTED OBJECTS if there is one. Iterators allow entities to be recovered in either case. A set of functions allows you to manipulate the objects, which have been placed in these different lists.
+
+*WARNING *
+When a Local Context is open, you can select entities other than interactive objects (vertices, edges etc.) from decompositions in standard modes, or from activation in specific modes on specific interactive objects. Only interactive objects are stocked in the list of selected objects. You can question the Interactive context by moving the mouse. The following functions will allow you to:
+ * tell whether something has been detected
+ * tell whether it is a shape
+ * get the shape if the detected entity is one
+ * get the interactive object if the detected entity is one.
+
+The following functions are concerned:
+ * AIS_InteractiveContext::HasDetected
+ * AIS_InteractiveContext::HasDetectedShape
+ * AIS_InteractiveContext::DetectedShape
+ * AIS_InteractiveContext::DetectedInteractive
+
+After using the Select and ShiftSelect functions in Neutral Point, you can explore the list of selections, referred to as current objects in this context. You can:
+ * initiate a scan of this list
+ * extend the scan
+ * resume the scan
+ * get the name of the current object detected in the scan.
+
+The following functions are concerned:
+ * AIS_InteractiveContext::InitCurrent
+ * AIS_InteractiveContext::MoreCurrent
+ * AIS_InteractiveContext::NextCurrent
+ * AIS_InteractiveContext::Current
+
+You can:
+ * get the first current interactive object
+ * highlight current objects
+ * remove highlight from current objects
+ * empty the list of current objects in order to update it
+ * find the current object.
+
+The following functions are concerned:
+ * AIS_InteractiveContext::FirstCurrentObject
+ * AIS_InteractiveContext::HilightCurrents
+ * AIS_InteractiveContext::UnhilightCurrents
+ * AIS_InteractiveContext::ClearCurrents
+ * AIS_InteractiveContext::IsCurrent.
+
+In Local Context, you can explore the list of selected objects available. You can:
+ * initiate,
+ * extend,
+ * resume a scan, and then
+ * get the name of the selected object.
+
+The following functions are concerned:
+
+ * AIS_InteractiveContext::InitSelected
+ * AIS_InteractiveContext::MoreSelected
+ * AIS_InteractiveContext::NextSelected
+ * AIS_InteractiveContext::SelectedShape.
+
+You can:
+ * check to see if you have a selected shape, and if not,
+ * get the picked interactive object,
+ * check to see if the applicative object has an owner from Interactive attributed to it
+ * get the owner of the detected applicative entity
+ * get the name of the selected object.
+
+The following functions are concerned:
+
+ * AIS_InteractiveContext::HasSelectedShape
+ * AIS_InteractiveContext::Interactive
+ * AIS_InteractiveContext::HasApplicative
+ * AIS_InteractiveContext::Applicative
+ * AIS_InteractiveContext::IsSelected.
+
+<h4>Example </h4>
+
+
+myAISCtx-InitSelected();
+while (myAISCtx-MoreSelected())
+{
+if (myAISCtx-HasSelectedShape)
+{
+TopoDS_Shape ashape = myAISCtx-SelectedShape();
+// to be able to use the picked shape
+ }
+else
+{
+Handle_AIS_InteractiveObject aniobj = myAISCtx-Interactive();
+// to be able to use the picked interactive object
+}
+myAISCtx-NextSelected(); }
+
+
+@subsubsection occt_1621831385_8103086097710 Remarks:
+
+In Local Context and in the iteration loop, which allows you to recover selected entities, you have to ask whether you have selected a shape or an interactive object before you can recover the entity. If you have selected a Shape from TopoDS on decomposition in standard mode, the *Interactive ()* function returns the interactive object, which provided the selected shape. Other functions allow you to manipulate the content of Selected or Current Objects:
+ * erase selected objects
+ * display them,
+ * put them in the list of selections
+
+The following functions are concerned:
+
+ * AIS_InteractiveContext::EraseSelected
+ * AIS_InteractiveContext::DisplaySelected
+ * AIS_InteractiveContext::SetSelected
+
+
+You can also:
+
+ * take the list of selected objects from a local context and put it into the list of current objects in Neutral Point,
+ * add or remove an object from the list of selected entities,
+ * highlight and
+ * remove highlighting from a selected object
+ * empty the list of selected objects.
+
+The following functions are concerned:
+
+ * AIS_InteractiveContext::SetSelectedCurrent
+ * AIS_InteractiveContext::AddOrRemoveSelected
+ * AIS_InteractiveContext::HilightSelected
+ * AIS_InteractiveContext::UnhilightSelected
+ * AIS_InteractiveContext::ClearSelected
+
+You can highlight and remove highlighting from a current object, and empty the list of current objects.
+
+ * AIS_InteractiveContext::HilightCurrents
+ * AIS_InteractiveContext::UnhilightCurrents
+ * AIS_InteractiveContext::ClearCurrents
+
+When you are in open Local Context, you may be lead to keep *temporary* interactive objects. This is possible using the following functions:
+
+ * AIS_InteractiveContext::KeepTemporary
+ * AIS_InteractiveContext::SetSelectedCurrent
+
+The first function transfers the characteristics of the interactive object seen in its local context (visualization mode etc.) to the neutral point. When the local context is closed, the object does not disappear. The second allows the selected object to become the current object when you close the local context.
+You can also want to modify in a general way the state of the local context before continuing a selection (emptying objects, removing filters, standard activation modes). To do that, you must use the following function:
+
+ * AIS_InteractiveContext::ClearLocalContext
+
+@subsubsection occt_1621831385_8103086097711 Advice on Using Local Contexts
+
+The possiblities of use for local contexts are numerous depending on the type of operation that you want to perform:
+ * working on all visualized interactive objects,
+ * working on only a few objects,
+ * working on a single object.
+
+1. When you want to work on one type of entity, you should open a local context with the option UseDisplayedObjects set to FALSE. Some functions which allow you to recover the visualized interactive objects, which have a given Type, and Signature from the *Neutral Point* are:
+
+AIS_InteractiveContext::DisplayedObjects
+(AIS_ListOfInteractive& aListOfIO) const;
+
+AIS_InteractiveContext::DisplayedObjects
+(const AIS_KindOfInteractive WhichKind,
+ const Standard_Integer WhichSignature,
+AIS_ListOfInteractive& aListOfIO) const;
+
+At this stage, you only have to load the functions Load, Activate, and so on.
+
+2. When you open a Local Context with default options, you must keep the following points in mind:
+
+The Interactive Objects visualized at Neutral Point are activated with their default selection mode. You must deactivate those, which you do not want to use.
+
+The Shape Type Interactive Objects are automatically decomposed into sub-shapes when standard activation modes are launched.
+
+The *temporary* Interactive Objects present in the Local Contexts are not automatically taken into account. You have to load them manually if you want to use them.
+
+The stages could be the following:
+1. Open a Local Context with the right options;
+2. Load/Visualize the required complementary objects with the desired activation modes.
+3. Activate Standard modes if necessary
+4. Create its filters and add them to the Local Context
+5. Detect/Select/recover the desired entities
+6. Close the Local Context with the adequate index.
+
+It is useful to create an INTERACTIVE EDITOR, to which you pass the Interactive Context. This will take care of setting up the different contexts of selection/presentation according to the operation, which you want to perform.
+<h4>Example </h4>
+
+
+You have visualized several types of interactive objects: *AIS_Points*, *AIS_Axes*, *AIS_Trihedrons*, and *AIS_Shapes*.
+
+For your applicative function, you need an axis to create a revolved object. You could obtain this axis by identifying:
+ * an axis which is already visualized,
+ * 2 points,
+ * a rectilinear edge on the shapes which are present,
+ * a cylindrical face on the shapes (You will take the axis of this face)
+
+myIHMEditor::myIHMEditor
+(const Handle(AIS_InteractiveContext)& Ctx,
+ ....) :
+ myCtx(Ctx),
+...
+
+{
+}
+
+myIHMEditor::PrepareContext()
+{
+myIndex =myCtx-OpenLocalContext();
+
+//the filters
+
+Handle(AIS_SignatureFilter) F1 = new
+ AIS_SignatureFilter(AIS_KOI_Datum,AIS_SD_Point);
+//filter on the points
+
+Handle(AIS_SignatureFilter) F2 = new
+AIS_SignatureFilter(AIS_KOI_Datum,AIS_SD_Axis);
+//filters on the axes.
+
+Handle(StdSelect_FaceFilter) F3 = new
+ StdSelect_FaceFilter(AIS_Cylinder);
+//cylindrical face filters
+
+//...
+
+// activation of standard modes on the shapes..
+myCtx-ActivateStandardMode(TopAbs_FACE);
+myCtx-ActivateStandardMode(TopAbs_VERTEX);
+myCTX-Add(F1);
+myCTX-Add(F2);
+myCTX-Add(F3);
+
+// at this point, you can call the selection/detection function
+}
+
+void myIHMEditor::MoveTo(xpix,ypix,Vue)
+
+{ myCTX-MoveTo(xpix,ypix,vue); // the highlight of what is detected is automatic. }
+Standard_Boolean myIHMEditor::Select() { // returns true if you should continue the selection
+myCTX-Select(); myCTX-InitSelected(); if(myCTX-MoreSelected())
+ { if(myCTX-HasSelectedShape())
+{ const TopoDS_Shape& sh = myCTX-SelectedShape();
+if( vertex){
+if(myFirstV...)
+{
+//if it’s the first vertex, you stock it, then you deactivate the faces and only keep the filter on the points:
+mypoint1 = ....;
+myCtx-RemoveFilters();
+myCTX-DeactivateStandardMode(TopAbs_FACE);
+myCtx-Add(F1);
+// the filter on the AIS_Points
+myFirstV = Standard_False;
+return Standard_True;
+ } else {
+ mypoint2 =...;
+// construction of the axis return Standard_False;
+}
+ }
+ else
+ {
+//it is a cylindrical face : you recover the axis; visualize it; and stock it.
+return Standard_False;
+}
+ }
+// it is not a shape but is no doubt a point.
+else
+{
+Handle(AIS_InteractiveObject)
+SelObj = myCTX-SelectedInteractive();
+if(SelObj-Type()==AIS_KOI_Datum)
+{
+if(SelObj-Signature()==1)
+{
+if (firstPoint)
+{
+mypoint1 =...
+return Standard_True;
+}
+else
+{
+mypoint2 = ...;
+//construction of the axis, visualization, stocking
+return Standard_False;
+}
+}
+
+else
+{
+// you have selected an axis; stock the axis
+return Standard_False;
+}
+}
+}
+}
+}
+@subsection occt_1621831385_810308609111 ANNEX I: Standard Interactive Object Classes in AIS DATUMS:
+
+AIS_Point AIS_Axis AIS_Line AIS_Circle AIS_Plane AIS_Trihedron : 4 selection modes
+ * mode 0 : selection of a trihedron
+ * mode 1 : selection of the origin of the trihedron
+ * mode 2 : selection of the axes
+ * mode 3 : selection of the planes XOY, YOZ, XOZ
+
+when you activate one of modes 1 2 3 4 , you pick AIS objects of type:
+ * AIS_Point
+ * AIS_Axis (and information on the type of axis)
+ * AIS_Plane (and information on the type of plane).
+
+AIS_PlaneTrihedron offers 3 selection modes:
+ * mode 0 : selection of the whole trihedron
+ * mode 1 : selection of the origin of the trihedron
+ * mode 2 : selection of the axes - same remarks as for the Trihedron.
+
+<h4>Warning </h4>
+For the presentation of planes and trihedra, the default unit of length is millimeter, and the default value for the representation of axes is 100. If you modify these dimensions, you must temporarily recover the object DRAWER. From inside it, take the Aspects in which the values for length are stocked (PlaneAspect for the plane, FirstAxisAspect for trihedra), and change these values inside these Aspects. Finally, recalculate the presentation.
+
+@subsubsection occt_1621831385_8103086092222 OBJECTS
+AIS_Shape : 3 visualization modes :
+ * mode 0 : Line (default mode)
+ * mode 1 : Shading (depending on the type of shape)
+ * mode 2 : Bounding Box
+
+7 maximum selection modes, depending on the complexity of the shape :
+ * * mode 0 : selection of the AIS_Shape
+ * * mode 1 : selection of the vertices
+ * * mode 2 : selection of the edges
+ * * mode 3 : selection of the wires
+ * * mode 4 : selection of the faces
+ * * mode 5 : selection of the shells
+ * * mode 6 : selection of the constituent solids.
+
+AIS_Triangulation: Simple interactive object for displaying triangular mesh contained in Poly_Triangulation container.
+
+AIS_ConnectedInteractive: Interactive Object connecting to another interactive object reference, and located elsewhere in the viewer makes it possible not to calculate presentation and selection, but to deduce them from your object reference.
+
+AIS_ConnectedShape: Object connected to interactive objects having a shape; this class has the same decompositions as AIS_Shape. What’s more, it allows a presentation of hidden parts, which are calculated automatically from the shape of its reference.
+
+AIS_MultipleConnectedInteractive: Object connected to a list of interactive objects (which can also be Connected objects. It does not require memory hungry calculations of presentation)
+
+AIS_MultipleConnectedShape: Interactive Object connected to a list of interactive objects having a Shape (AIS_Shape, AIS_ConnectedShape, AIS_MultipleConnectedShape). The presentation of hidden parts is calculated automatically.
+
+AIS_TexturedShape: Interactive Object that supports texture mapping. It is constructed as a usual AIS_Shape, but has additional methods that allow to map a texture on it.
+
+MeshVS_Mesh: Interactive Object that represents meshes, it has a data source that provides geometrical information (nodes, elements) and can be built up from the source data with a custom presentation builder.
+
+@subsubsection occt_1621831385_8103086093333 RELATIONS
+The list is not exhaustive.
+AIS_ConcentricRelation
+AIS_FixRelation
+AIS_IdenticRelation
+AIS_ParallelRelation
+AIS_PerpendicularRelation
+AIS_Relation
+AIS_SymmetricRelation
+AIS_TangentRelation
+
+@subsubsection occt_1621831385_810308609444 DIMENSIONS
+AIS_AngleDimension
+AIS_Chamf2dDimension
+AIS_Chamf3dDimension
+AIS_DiameterDimension
+AIS_DimensionOwner
+AIS_LengthDimension
+AIS_OffsetDimension
+AIS_RadiusDimension
+
+@subsubsection occt_1621831385_810308609555 MeshVS_Mesh
+MeshVS_Mesh is an Interactive Object that represents meshes.
+This object differs from the AIS_Shape as its geometrical data is supported by the data source (*MeshVS_DataSource*) that describes nodes and elements of the object. As a result, you can provide your own data source.
+However, the *DataSource* does not provide any information on attributes, for example nodal colors, but you can apply them in a special way – by choosing the appropriate presentation builder.
+The presentations of MeshVS_Mesh are built with the presentation builders (*MeshVS_PrsBuilder*). You can choose between the builders to represent the object in a different way. Moreover, you can redefine the base builder class and provide your own presentation builder.
+You can add/remove builders using the following methods:
+ * MeshVS_Mesh::AddBuilder
+ (const Handle (MeshVS_PrsBuilder) &Builder,
+ Standard_Boolean TreatAsHilighter)
+ * MeshVS_Mesh::RemoveBuilder (const Standard_Integer Index)
+ * MeshVS_Mesh::RemoveBuilderById
+ (const Standard_Integer Id)
+
+There is a set of reserved display and highlighting mode flags for MeshVS_Mesh. Mode value is a number of bits that allows you to select additional display parameters and combine the following mode flags:
+ * MeshVS_DMF_WireFrame
+ * MeshVS_DMF_Shading
+ * MeshVS_DMF_Shrink
+base modes: display mesh in wireframe, shading, shrink modes.
+
+ * MeshVS_DMF_VectorDataPrs
+ * MeshVS_DMF_NodalColorDataPrs
+ * MeshVS_DMF_ElementalColorDataPrs
+ * MeshVS_DMF_TextDataPrs
+ * MeshVS_DMF_EntitiesWithData
+represent different kinds of data
+
+ * MeshVS_DMF_DeformedPrsWireFrame
+ * MeshVS_DMF_DeformedPrsShading
+ * MeshVS_DMF_DeformedPrsShrink
+display deformed mesh in wireframe, shading or shrink modes
+
+ * MeshVS_DMF_SelectionPrs
+ * MeshVS_DMF_HilightPrs
+selection and hilighting
+
+ * MeshVS_DMF_User
+user-defined mode
+
+These values will be used by the presentation builder.
+There is also a set of selection modes flags that can be grouped in a combination of bits:
+ * MeshVS_SMF_0D
+ * MeshVS_SMF_Link
+ * MeshVS_SMF_Face
+ * MeshVS_SMF_Volume
+ * MeshVS_SMF_Element
+Element: 0D, Link, Face and Volume grouped as a bit mask
+
+ * MeshVS_SMF_Node
+ * MeshVS_SMF_All
+All: Element and Node grouped as a bit mask
+
+ * MeshVS_SMF_Mesh
+ * MeshVS_SMF_Group
+
+Such an object, for example, can be used for displaying the object, stored in the STL file format:
+<h4>Example </h4>
+
+**// read the data and create a data source**
+Handle (StlMesh_Mesh) aSTLMesh = RWStl::ReadFile (aFileName);
+Handle (XSDRAWSTLVRML_DataSource) aDataSource =
+ new XSDRAWSTLVRML_DataSource (aSTLMesh);
+
+**// create mesh**
+Handle (MeshVS_Mesh) aMesh = new MeshVS();
+aMesh-SetDataSource (aDataSource);
+
+**// use default presentation builder**
+Handle (MeshVS_MeshPrsBuilder) aBuilder =
+ new MeshVS_MeshPrsBuilder (aMesh);
+aMesh-AddBuilder (aBuilder, Standard_True);
+
+MeshVS_NodalColorPrsBuilder allows you to represent a mesh with a color scaled texture mapped on it. To do this you should define a color map for the color scale, pass this map to the presentation builder, and define an appropriate value in the range of 0.0 – 1.0 for every node.
+The following example demonstrates how you can do this (**please check,** if the view has been set up to display textures):
+<h4>Example </h4>
+
+**// assign nodal builder to the mesh**
+Handle (MeshVS_NodalColorPrsBuilder) aBuilder =
+ new MeshVS_NodalColorPrsBuilder
+ (aMesh,MeshVS_DMF_NodalColorDataPrs | MeshVS_DMF_OCCMask);
+aBuilder-UseTexture (Standard_True);
+
+**// prepare color map**
+Aspect_SequenceOfColor aColorMap;
+aColorMap.Append ((Quantity_NameOfColor) Quantity_NOC_RED);
+aColorMap.Append ((Quantity_NameOfColor) Quantity_NOC_BLUE1);
+
+**// assign color scale map values (0..1) to nodes**
+TColStd_DataMapOfIntegerReal aScaleMap;
+**…**
+** // iterate through the nodes and add an node id and an appropriate **
+** // value to the map**
+ aScaleMap.Bind (anId, aValue);
+
+**// pass color map and color scale values to the builder**
+aBuilder-SetColorMap (aColorMap);
+aBuilder-SetInvalidColor (Quantity_NOC_BLACK);
+aBuilder-SetTextureCoords (aScaleMap);
+aMesh-AddBuilder (aBuilder, Standard_True);
+
+@subsection occt_1621831385_810308609666 ANNEX II : Principles of Dynamic Selection
+
+
+The idea of dynamic selection is to represent the entities, which you want to select by a bounding box in the actual 2D space of the selection view. The set of these zones is ordered by a powerful sorting algorithm. To then find the applicative entities actually detected at this position, all you have to do is read which rectangles are touched at mouse position (X,Y) of the view, and judiciously reject some of the entities which have provided these rectangles.
+
+
+@subsubsection occt_1621831385_81030860912222 How to go from the objects to 2D boxes
+
+
+An intermediary stage consists in representing what you can make selectable by means of sensitive primitives and owners, entities of a high enough level to be known by the selector mechanisms.
+
+The sensitive primitive is capable of:
+ * giving a 2D bounding box to the selector.
+ * answering the rejection criteria positively or negatively by a *Matches* function.
+ * being projected from 3D in the 2D space of the view if need be.
+ * returning the owner which it will represent in terms of selection.
+
+A set of standard sensitive primitives exists in Select3D packages for 3D primitives, and Select2D for 2D primitives.
+
+The owner is the entity, which makes it possible to link the sensitive primitives and the objects that you really wanted to detect. It stocks the diverse information, which makes it possible to find objects. An owner has a priority (*5* by default), which you can modulate, so as to make one entity more selectable than another.
+
+
+@subsubsection occt_1621831385_81030860912341 Implementation in an interactive/selectable object
+
+1. Define the number of selection modes possible, i.e. what you want to identify by activating each of the selection modes. Example: for an interactive object representing a topological shape,
+mode 0: selection of the interactive object itself
+mode 1: selection of the vertices
+mode 2: selection of the edges
+mode 3: selection of the wires
+mode 4: selection of the faces detectable
+
+2. For each selection mode of an interactive object, *model* the set of entities, which you want to locate by these primitives and these owners.
+
+3. There exists an *owner* root class, *SelectMgr_EntityOwne*r, containing a reference to a selectable object, which has created it. If you want to stock its information, you have to create classes derived from this root class. Example: for shapes, there is the *StdSelect_BRepOwner *class, which can save a TopoDS shape as a field as well as the Interactive Object.
+
+4. The set of sensitive primitives which has been calculated for a given mode is stocked in *SelectMgr_Selection*.
+
+5. For an Interactive object, the modeling is done in the *ComputeSelection *virtual function.
+
+<h4>Example </h4>
+
+Let an interactive object represent a box.
+We are interested in having 2 location modes:
+ * mode 0: location of the whole box.
+ * mode 1: location of the edges on the box.
+
+ For the first mode, all sensitive primitives will have the same owner, which will represent the interactive object. In the second case, we have to create an owner for each edge, and this owner will have to contain the index for the edge, which it represents. You will create a class of owner, which derives from *SelectMgr_EntityOwner*.
+
+The *ComputeSelection* function for the interactive box can have the following form:
+
+void InteractiveBox::ComputeSelection
+(const Handle(SelectMgr_Selection)& Sel,
+ const Standard_Integer Mode)
+{
+switch(Mode)
+{ case 0: //locating the whole box by making its faces sensitive...
+{
+Handle(SelectMgr_EntityOwner) Ownr = new
+ SelectMgr_EntityOwner(this,5);
+for(Standard_Integer I=1;I=Nbfaces;I++)
+{
+//Array is a TColgp_Array1OfPnt: which represents the array of vertices. Sensitivity is
+Select3D_TypeOfSensitivity value
+Sel-Add(new
+Select3D_SensitiveFace(Ownr,Array,Sensitivity));
+}
+break;
+ }
+ case 1:
+// locates the edges { for(Standard_Integer i=1;i=12;i++)
+{
+// 1 owner per edge...
+Handle(mypk_EdgeOwner) Ownr =
+new mypk_EdgeOwner(this,i,6);
+//6-priority
+Sel-Add(new Select3D_SensitiveSegment
+ (Ownr,firstpt(i),lastpt(i)));
+}
+break;
+}
+}
+}
+
+
+@subsubsection occt_1621831385_81030860912432 How It Works Concretely
+
+Selectable objects are loaded in the selection manager, which has one or more selectors; in general, we suggest assigning one selector per viewer. All you have to do afterwards is to activate or deactivate the different selection modes for selectable objects. The *SelectionManager* looks after the call to the *ComputeSelection* functions for different objects. NOTE: This procedure is completely hidden if you use the interactive contexts of AIS (see section 3.3, Contexts)
+
+<h4>Example </h4>
+
+//We have several * interactive boxes * box1, box2, box3;
+
+Handle(SelectMgr_SelectionManager) SM = new SelectMgr_SelectionManager();
+Handle(StdSelect_ViewerSelector3d) VS = new StdSelect_ViewerSelector3d();
+
+SM-Add(VS);
+SM-Load(box1);SM-Load(box2);SM-Load(box3);
+// box load.
+SM-Activate(box1,0,VS);
+// activates mode 0 of box 1 in the selector VS
+SM-Activate(box1,1,VS);
+M-Activate(box3,1,VS);
+
+VS-Pick(xpix,ypix,vue3d)
+// detection of primitives by mouse position.
+
+Handle(EntityOwner) POwnr = VS-OnePicked();
+// picking of the *best* owner detected
+
+for(VS-Init();VS-More();VS-Next())
+{
+VS-Picked();
+// picking of all owners detected
+ }
+SM-Deactivate(box1);
+// deactivate all active modes of box1
+
+
+1st activation of the box’s mode 1: calculation of sensitive primitives + 3D/2D projection + sorting
+
+deactivation of mode: only updated by sorting
+
+rotation of the view: only projection + sorting of active primitives
+
+modification of the box - Recalculation of the active selection, recalculation flag on the inactive ones + 3D/2D projection + sorting
+
+@section occt_1621831385_1539918866 3D Presentations
+
+@subsection occt_1621831385_15399188661 Glossary of 3D terms
+
+@subsubsection occt_1621831385_153991886611 From Graphic3d
+
+
+
+@subsubsection occt_1621831385_153991886612 From V3d
+
+
+** **
+
+
+@subsection occt_1621831385_15399188662 Creating a 3D scene
+
+To create 3D graphic objects and display them on the screen, follow the procedure below:
+**1. **Create attributes.
+**2. **Create a 3D viewer..
+**3. **Create a view.
+**4. **Create an interactive context.
+**5. **Create interactive objects.
+**6. **Create primitives in the interactive object
+**7. **Display the interactive object.
+
+@subsubsection occt_1621831385_153991886621 Create attributes
+
+Create colors.
+<h4>Example </h4>
+
+Quantity_Color Black (Quantity_NOC_BLACK);
+Quantity_Color Blue (Quantity_NOC_MATRABLUE);
+Quantity_Color Brown (Quantity_NOC_BROWN4);
+Quantity_Color Firebrick (Quantity_NOC_FIREBRICK);
+Quantity_Color Forest (Quantity_NOC_FORESTGREEN);
+Quantity_Color Gray (Quantity_NOC_GRAY70);
+Quantity_Color
+MyColor (0.99, 0.65, 0.31, Quantity_TOC_RGB);
+Quantity_Color Beet (Quantity_NOC_BEET);
+Quantity_Color White (Quantity_NOC_WHITE);
+
+
+
+Create line attributes.
+
+<h4>Example </h4>
+
+Handle(Graphic3d_AspectLine3d) CTXLBROWN =
+new Graphic3d_AspectLine3d ();
+Handle(Graphic3d_AspectLine3d) CTXLBLUE =
+new Graphic3d_AspectLine3d ();
+Handle(Graphic3d_AspectLine3d) CTXLWHITE =
+new Graphic3d_AspectLine3d();
+CTXLBROWN-SetColor (Brown);
+CTXLBLUE-SetColor (Blue);
+CTXLWHITE-SetColor (White);
+
+
+Create marker attributes.
+<h4>Example </h4>
+
+Handle(Graphic3d_AspectMarker3d) CTXMFIREBRICK =
+new Graphic3d_AspectMarker3d();
+CTXMFIREBRICK-SetColor (Firebrick);
+CTXMFIREBRICK-SetScale (1.0);
+CTXMFIREBRICK-SetType (Aspect_TOM_BALL);
+
+
+Create facet attributes.
+<h4>Example </h4>
+
+Handle(Graphic3d_AspectFillArea3d) CTXF =
+new Graphic3d_AspectFillArea3d ();
+Graphic3d_MaterialAspect BrassMaterial
+(Graphic3d_NOM_BRASS);
+Graphic3d_MaterialAspect GoldMaterial
+(Graphic3d_NOM_GOLD);
+CTXF-SetInteriorStyle (Aspect_IS_SOLID);
+CTXF-SetInteriorColor (MyColor);
+CTXF-SetDistinguishOn ();
+CTXF-SetFrontMaterial (GoldMaterial);
+CTXF-SetBackMaterial (BrassMaterial);
+CTXF-SetEdgeOn ();
+
+
+Create text attributes.
+<h4>Example </h4>
+
+Handle(Graphic3d_AspectText3d) CTXT =
+new Graphic3d_AspectText3d
+(Forest, Graphic3d_NOF_ASCII_MONO, 1., 0.);
+
+@subsubsection occt_1621831385_153991886622 Create a 3D Viewer (a Windows example)
+<h4>Example </h4>
+
+Handle(Graphic3d_WNTGraphicDevice) TheGraphicDevice = ...;
+TCollection_ExtendedString aName(*3DV*);
+myViewer =
+new V3d_Viewer (TheGraphicDevice,aName.ToExtString (), **);
+myViewer - SetDefaultLights ();
+myViewer - SetLightOn ();
+@subsubsection occt_1621831385_153991886623 Create a 3D view (a Windows example)
+
+It is assumed that a valid Windows window may already be accessed via the method GetSafeHwnd().
+<h4>Example </h4>
+
+
+
+@subsubsection occt_1621831385_153991886624 Create an interactive context
+<h4>Example </h4>
+
+myAISContext = new AIS_InteractiveContext (myViewer);
+
+
+You are now able to display interactive objects such as an AIS_Shape.
+<h4>Example </h4>
+
+TopoDS_Shape aShape = BRepAPI_MakeBox(10,20,30)_Solid();
+Handle (AIS_Shape) aAISShape = new AIS_Shape(aShape);
+myAISContext - Display (aAISShape);
+
+@subsubsection occt_1621831385_153991886625 Create your own interactive object
+
+Follow the procedure below to compute the presentable object:
+
+**1. **Build a presentable object inheriting from AIS_InteractiveObject (refer to the Chapter on Presentable Objects).
+
+**2. **Reuse the Prs3d_Presentation provided as an argument of the compute methods.
+
+*NOTE*
+*There are two compute methods: one for a ‘standard representation, and the other for a ‘degenerated representation, i.e. in hidden line removal and wireframe modes.*
+<h4>Example of the compute methods</h4>
+
+Void
+myPresentableObject::Compute
+(const Handle(PrsMgr_PresentationManager3d)&
+aPresentationManager,
+const Handle(Prs3d_Presentation)& aPrs,
+const Standard_Integer aMode)
+(
+//...
+)
+
+
+
+void
+myPresentableObject::Compute
+(const Handle(Prs3d_Projector)&,
+const Handle(Prs3d_Presentation)& aPrs)
+(
+//...
+)
+
+
+@subsubsection occt_1621831385_153991886626 Create primitives in the interactive object
+
+Get the group used in Prs3d_Presentation.
+<h4>Example </h4>
+
+Handle(Graphic3d_Group) TheGroup = Prs3d_Root::CurrentGroup(aPrs);
+
+
+Update the group attributes.
+
+<h4>Example </h4>
+
+TheGroup - SetPrimitivesAspect(CTXLBLUE);
+
+
+Create two triangles in group TheGroup.
+<h4>Example </h4>
+
+Standard_Integer aNbTria = 2;
+Handle(Graphic3d_ArrayOfTriangles) aTriangles = new Graphic3d_ArrayOfTriangles(3 * aNbTria, 0, Standard_True);
+Standard_Integer anIndex;
+for (anIndex = 1; anIndex = aNbTria; nt++)
+{
+ aTriangles-AddVertex(anIndex * 5., 0., 0., 1., 1., 1.);
+ aTriangles-AddVertex(anIndex * 5 + 5, 0., 0., 1., 1., 1.);
+ aTriangles-AddVertex(anIndex * 5 + 2.5, 5., 0., 1., 1., 1.);
+}
+TheGroup-BeginPrimitives ();
+mygroup-AddPrimitiveArray(aTriangles);
+TheGroup-EndPrimitives ();
+
+
+The BeginPrimitives () and EndPrimitives () methods are used when creating a set of various primitives in the same group.
+Use the polyline function to create a boundary box for the Struct structure in group TheGroup.
+<h4>Example </h4>
+
+Standard_Real Xm, Ym, Zm, XM, YM, ZM;
+Struct-MinMaxValues (Xm, Ym, Zm, XM, YM, ZM);
+
+Handle(Graphic3d_ArrayOfPolylines) aPolylines = new Graphic3d_ArrayOfPolylines(16, 4);
+aPolylines-AddBound (4);
+aPolylines-AddVertex (Xm, Ym, Zm);
+aPolylines-AddVertex (Xm, Ym, ZM);
+aPolylines-AddVertex (Xm, YM, ZM);
+aPolylines-AddVertex (Xm, YM, Zm);
+aPolylines-AddBound (4);
+aPolylines-AddVertex (Xm, Ym, Zm);
+aPolylines-AddVertex (XM, Ym, Zm);
+aPolylines-AddVertex (XM, Ym, ZM);
+aPolylines-AddVertex (XM, YM, ZM);
+aPolylines-AddBound (4);
+aPolylines-AddVertex (XM, YM, Zm);
+aPolylines-AddVertex (XM, Ym, Zm);
+aPolylines-AddVertex (XM, YM, Zm);
+aPolylines-AddVertex (Xm, YM, Zm);
+aPolylines-AddBound (4);
+aPolylines-AddVertex (Xm, YM, ZM);
+aPolylines-AddVertex (XM, YM, ZM);
+aPolylines-AddVertex (XM, Ym, ZM);
+aPolylines-AddVertex (Xm, Ym, ZM);
+
+TheGroup-BeginPrimitives ();
+TheGroup-AddPrimitiveArray(aPolylines);
+TheGroup-EndPrimitives ();
+
+
+Create text and markers in group TheGroup.
+<h4>Example </h4>
+
+static char *texte[3] = { *Application title*,
+*My company*,
+*My company address.* };
+Graphic3d_Array1OfVertex Tpts8 (0, 1);
+Tpts8(0).SetCoord (-40.0, -40.0, -40.0);
+Tpts8(1).SetCoord (40.0, 40.0, 40.0);
+TheGroup-MarkerSet (Tpts8);
+Graphic3d_Vertex Marker (0.0, 0.0, 0.0);
+
+for (i=0; i=2; i++) {
+ Marker.SetCoord (-(Standard_Real)i*4 + 30,
+ (Standard_Real)i*4,
+ -(Standard_Real)i*4);
+ TheGroup-Text (texte[i], Marker, 20.);
+}
+
+@section occt_1621831385_1435012457 3D Resources
+
+The 3D resources include the Graphic3d and V3d packages.
+
+@subsection occt_1621831385_14350124571 Graphic3D
+
+@subsubsection occt_1621831385_143501245711 Overview
+
+The **Graphic3d** package is used to create 3D graphic objects in a 3D viewer. These objects called **structures** are made up of groups of primitives and attributes. A group is the smallest editable element of a structure. A transformation can be applied to a structure. Structures can be connected to form a tree of structures, composed by transformations. Structures are globally manipulated by the viewer.
+
+@subsubsection occt_1621831385_143501245712 Provided services
+
+Graphic structures can be:
+ * Displayed,
+ * Highlighted,
+ * Erased,
+ * Transformed,
+ * Connected to form a tree.
+ There are classes for:
+ * Visual attributes for lines, faces, markers, text, materials,
+ * Vectors and vertices,
+ * Defining an Advanced Graphic Device,
+ * Graphic objects, groups, and structures.
+
+@subsubsection occt_1621831385_143501245713 About the primitives
+** **
+** **Markers** **
+ * Have one or more vertices,
+ * Have a type, a scale factor, and a color,
+ * Have a size, shape, and orientation independent of transformations.
+*Polygons *
+ * Have one closed boundary,
+ * Have at least three vertices,
+ * Are planar and have a normal,
+ * Have interior attributes - style, color, front and back material, texture and reflection ratio,
+ * Have a boundary with the following attributes - type, width scale factor, color. The boundary is only drawn when the interior style is hollow.
+
+*Polygons with holes *
+ * Have multiple closed boundaries, each one with at least three vertices,
+ * Are planar and have a normal,
+ * Have interior attributes - style, color, front and back material,
+ * Have a boundary with the following attributes - type, width scale factor, color. The boundary is only drawn when the interior style is hollow.
+
+*Polylines *
+ * Have two or more vertices,
+ * Have the following attributes - type, width scale factor, color.
+
+*Text *
+ * Has geometric and non-geometric attributes,
+ * Geometric attributes - character height, character up vector, text path, horizontal and vertical alignment, orientation, three-dimensional position, zoomable flag
+ * Non-geometric attributes - text font, character spacing, character expansion factor, color.
+
+@subsubsection occt_1621831385_143501245714 Primitive arrays
+
+Primitive arrays are a more efficient approach to describe and display the primitives from the aspects of memory usage and graphical performance. The key feature of the primitive arrays is that the primitive data is not duplicated. For example, two polygons could share the same vertices, so it is more efficient to keep the vertices in a single array and specify the polygon vertices with indices of this array. In addition to such kind of memory savings, the OpenGl graphics driver provides the Vertex Buffer Objects (VBO). VBO is a sort of video memory storage that can be allocated to hold the primitive arrays, thus making the display operations more efficient and releasing the RAM memory.
+
+The Vertex Buffer Objects are enabled by default, but VBOs availability depends on the implementation of OpenGl. If the VBOs are unavailable or there is not enough video memory to store the primitive arrays, the RAM memory will be used to store the arrays.
+
+The Vertex Buffer Objects can be disabled at the application level. You can use the following method to enable/disable VBOs:
+ * void Graphic3d_GraphicDriver::EnableVBO
+ (const Standard_Boolean status)
+
+The following example shows how to disable the VBO support:
+<h4>Example </h4>
+
+**// get the graphic driver**
+Handle (Aspect_GraphicDriver) aDriver =
+ myAISContext-CurrentViewer()-Device()-GraphicDriver();
+
+**// disable VBO support**
+Handle (Graphic3d_GraphicDriver)::
+ DownCast (aDriver)-EnableVBO (Standard_False);
+
+**Please note** that the use of Vertex Buffer Objects requires the application level primitive data provided by the Graphic3d_ArrayOfPrimitives to be transferred to the video memory. TKOpenGl transfers the data and releases the Graphic3d_ArrayOfPrimitives internal pointers to the primitive data. Thus it might be necessary to pay attention to such kind of behaviour, as the pointers could be modified (nullified) by the TKOpenGl.
+
+The different types of primitives could be presented with the following primitive arrays:
+ * Graphic3d_ArrayOfPoints,
+ * Graphic3d_ArrayOfPolygons,
+ * Graphic3d_ArrayOfPolylines,
+ * Graphic3d_ArrayOfQuadrangles,
+ * Graphic3d_ArrayOfQuadrangleStrips,
+ * Graphic3d_ArrayOfSegments,
+ * Graphic3d_ArrayOfTriangleFans,
+ * Graphic3d_ArrayOfTriangles,
+ * Graphic3d_ArrayOfTriangleStrips.
+
+The Graphic3d_ArrayOfPrimitives is a base class for these primitive arrays.
+
+There is a set of similar methods to add vertices to the primitive array:
+ * Standard_Integer Graphic3d_ArrayOfPrimitives::AddVertex
+
+These methods take vertex coordinates as an argument and allow you to define the color, the normal and the texture coordinates assigned to the vertex. The return value is the actual number of vertices in the array.
+
+You can also modify the values assigned to the vertex or query these values by the vertex index:
+ * void Graphic3d_ArrayOfPrimitives::SetVertice
+ * void Graphic3d_ArrayOfPrimitives::SetVertexColor
+ * void Graphic3d_ArrayOfPrimitives::SetVertexNormal
+ * void Graphic3d_ArrayOfPrimitives::SetVertexTexel
+ * gp_Pnt Graphic3d_ArrayOfPrimitives::Verticie
+ * gp_Dir Graphic3d_ArrayOfPrimitives::VertexNormal
+ * gp_Pnt2d Graphic3d_ArrayOfPrimitives::VertexTexel
+ * Quantity_Color Graphic3d_ArrayOfPrimitives::VertexColor
+ * void Graphic3d_ArrayOfPrimitives::Verticie
+ * void Graphic3d_ArrayOfPrimitives::VertexNormal
+ * void Graphic3d_ArrayOfPrimitives::VertexTexel
+ * void Graphic3d_ArrayOfPrimitives::VertexColor
+
+The following example shows how to define an array of points:
+<h4>Example </h4>
+
+**// create an array**
+Handle (Graphic3d_ArrayOfPoints) anArray =
+ new Graphic3d_ArrayOfPoints (aVerticiesMaxCount);
+
+**// add vertices to the array**
+anArray-AddVertex (10.0, 10.0, 10.0);
+anArray-AddVertex (0.0, 10.0, 10.0);
+
+**// add the array to the structure **
+Handle (Graphic3d_Group) aGroup =
+ Prs3d_Root::CurrentGroup (aPrs);
+aGroup-BeginPrimitives ();
+aGroup-AddPrimitiveArray (anArray);
+aGroup-EndPrimitives ();
+
+If the primitives share the same vertices (polygons, triangles, etc) then you can define them as indices of the vertices array. The following method allows you to define the primitives by the indices:
+ * Standard_Integer Graphic3d_ArrayOfPrimitives::AddEdge
+
+This method adds an *edge* in the range [1, VertexNumber() ] in the array.
+It is also possible to query the vertex defined by an edge:
+ * Standard_Integer Graphic3d_ArrayOfPrimitives::Edge
+
+The following example shows how to define an array of triangles:
+<h4>Example </h4>
+
+**// create an array**
+Standard_Boolean IsNormals = Standard_False;
+Standard_Boolean IsColors = Standard_False;
+Standard_Boolean IsTextureCrds = Standard_False;
+Handle (Graphic3d_ArrayOfTriangles) anArray =
+ new Graphic3d_ArrayOfTriangles (aVerticesMaxCount,
+ aEdgesMaxCount,
+ IsNormals,
+ IsColors,
+ IsTextureCrds);
+**// add vertices to the array**
+anArray-AddVertex (-1.0, 0.0, 0.0); **// vertex 1**
+anArray-AddVertex ( 1.0, 0.0, 0.0); **// vertex 2**
+anArray-AddVertex ( 0.0, 1.0, 0.0); **// vertex 3**
+anArray-AddVertex ( 0.0,-1.0, 0.0); **// vertex 4**
+
+**// add edges to the array**
+anArray-AddEdge (1); **// first triangle**
+anArray-AddEdge (2);
+anArray-AddEdge (3);
+anArray-AddEdge (1); **// second triangle**
+anArray-AddEdge (2);
+anArray-AddEdge (4);
+
+**// add the array to the structure**
+Handle (Graphic3d_Group) aGroup =
+ Prs3d_Root::CurrentGroup (aPrs);
+aGroup-BeginPrimitives ();
+aGroup-AddPrimitiveArray (anArray);
+aGroup-EndPrimitives ();
+
+If the primitive array presents primitives built from sequential sets of vertices, for example polygons, then you can specify the bounds, or the number of vertices for each primitive. You can use the following method to define the bounds and the color for each bound:
+ * Standard_Integer Graphic3d_ArrayOfPrimitives::AddBound
+
+This method returns the actual number of bounds.
+It is also possible to set the color and query the number of edges in the bound and bound color:
+ * Standard_Integer Graphic3d_ArrayOfPrimitives::Bound
+ * Quantity_Color Graphic3d_ArrayOfPrimitives::BoundColor
+ * void Graphic3d_ArrayOfPrimitives::BoundColor
+
+The following example shows how to define an array of polygons:
+<h4>Example </h4>
+
+**// create an array**
+Standard_Boolean IsNormals = Standard_False;
+Standard_Boolean IsVertexColors = Standard_False;
+Standard_Boolean IsFaceColors = Standard_False;
+Standard_Boolean IsTextureCrds = Standard_False;
+Handle (Graphic3d_ArrayOfPolygons) anArray =
+ new Graphic3d_ArrayOfPolygons (aVerticesMaxCount,
+ aBoundsMaxCount,
+ aEdgesMaxCount,
+ IsNormals,
+ IsVertexColors,
+ IsFaceColors,
+ IsTextureCrds);
+
+**// add bounds to the array, first polygon**
+anArray-AddBound (3);
+anArray-AddVertex (-1.0, 0.0, 0.0);
+anArray-AddVertex ( 1.0, 0.0, 0.0);
+anArray-AddVertex ( 0.0, 1.0, 0.0);
+
+**// add bounds to the array, second polygon**
+anArray-AddBound (4);
+anArray-AddVertex (-1.0, 0.0, 0.0);
+anArray-AddVertex ( 1.0, 0.0, 0.0);
+anArray-AddVertex ( 1.0,-1.0, 0.0);
+anArray-AddVertex (-1.0,-1.0, 0.0);
+
+**// add the array to the structure **
+Handle (Graphic3d_Group) aGroup =
+ Prs3d_Root::CurrentGroup (aPrs);
+aGroup-BeginPrimitives ();
+aGroup-AddPrimitiveArray (anArray);
+aGroup-EndPrimitives ();
+
+There are also several helper methods. You can get the type of the primitive array:
+ * Graphic3d_TypeOfPrimitiveArray Graphic3d_ArrayOfPrimitives::Type
+ * Standard_CString Graphic3d_ArrayOfPrimitives::StringType
+
+and check if the primitive array provides normals, vertex colors, vertex texels (texture coordinates):
+ * Standard_Boolean Graphic3d_ArrayOfPrimitives::HasVertexNormals
+ * Standard_Boolean Graphic3d_ArrayOfPrimitives::HasVertexColors
+ * Standard_Boolean Graphic3d_ArrayOfPrimitives::HasVertexTexels
+
+or get the number of vertices, edges and bounds:
+ * Standard_Integer Graphic3d_ArrayOfPrimitives::VertexNumber
+ * Standard_Integer Graphic3d_ArrayOfPrimitives::EdgeNumber
+ * Standard_Integer Graphic3d_ArrayOfPrimitives::BoundNumber
+
+@subsubsection occt_1621831385_143501245715 About materials
+
+A **material** is defined by coefficients of:
+ * Transparency,
+ * Diffuse reflection,
+ * Ambient reflection,
+ * Specular reflection.
+
+Two properties define a given material:
+ * Transparency
+ * Reflection properties - its absorption and reflection of light.
+
+**Diffuse reflection** is seen as a component of the color of the object.
+
+**Specular reflection** is seen as a component of the color of the light source.
+
+The following items are required to determine the three colors of reflection:
+ * Color,
+ * Coefficient of diffuse reflection,
+ * Coefficient of ambient reflection,
+ * Coefficient of specular reflection.
+
+
+
+@subsubsection occt_1621831385_143501245716 About textures
+
+A **texture **is defined by a name.
+Three types of texture are available:
+ * 1D,
+ * 2D,
+ * Environment mapping.
+
+@subsubsection occt_1621831385_143501245717 Graphic3d text
+
+The OpenGl graphics driver uses advanced text rendering powered by FTGL library. This library provides vector text rendering, as a result the text can be rotated and zoomed without quality loss.
+Graphic3d text primitives have the following features:
+ * fixed size (non-zoomable) or zoomable,
+ * can be rotated to any angle in the view plane,
+ * support unicode charset.
+
+The text attributes for the group could be defined with the Graphic3d_AspectText3d attributes group.
+To add any text to the graphic structure you can use the following methods:
+ * void Graphic3d_Group::Text
+(const Standard_CString AText,
+ const Graphic3d_Vertex& APoint,
+ const Standard_Real AHeight,
+ const Quantity_PlaneAngle AAngle,
+ const Graphic3d_TextPath ATp,
+ const Graphic3d_HorizontalTextAlignment AHta,
+ const Graphic3d_VerticalTextAlignment AVta,
+ const Standard_Boolean EvalMinMax),
+AText parameter is the text string, APoint is the three-dimensional position of the text, AHeight is the text height, AAngle is the orientation of the text (at the moment, this parameter has no effect, but you can specify the text orientation through the Graphic3d_AspectText3d attributes).
+ATp parameter defines the text path, AHta is the horizontal alignment of the text, AVta is the vertical alignment of the text.
+You can pass Standard_False as EvalMinMax if you don’t want the graphic3d structure boundaries to be affected by the text position.
+**Please note** that the text orientation angle can be defined by Graphic3d_AspectText3d attributes.
+
+ * void Graphic3d_Group::Text
+(const Standard_CString AText,
+ const Graphic3d_Vertex& APoint,
+ const Standard_Real AHeight,
+ const Standard_Boolean EvalMinMax)
+ * void Graphic3d_Group::Text
+(const TCcollection_ExtendedString &AText,
+const Graphic3d_Vertex& APoint,
+ const Standard_Real AHeight,
+ const Quantity_PlaneAngle AAngle,
+ const Graphic3d_TextPath ATp,
+ const Graphic3d_HorizontalTextAlignment AHta,
+ const Graphic3d_VerticalTextAlignment AVta,
+ const Standard_Boolean EvalMinMax)
+ * void Graphic3d_Group::Text
+(const TCcollection_ExtendedString &AText,
+ const Graphic3d_Vertex& APoint,
+ const Standard_Real AHeight,
+ const Standard_Boolean EvalMinMax)
+
+<h4>Example </h4>
+
+**// get the group**
+Handle (Graphic3d_Group) aGroup =
+ Prs3d_Root::CurrentGroup (aPrs);
+
+**// change the text aspect**
+Handle(Graphic3d_AspectText3d) aTextAspect =
+ new Graphic3d_AspectText3d ();
+aTextAspect-SetTextZoomable (Standard_True);
+aTextAspect-SetTextAngle (45.0);
+aGroup-SetPrimitivesAspect (aTextAspect);
+
+**// add a text primitive to the structure**
+Graphic3d_Vertex aPoint (1, 1, 1);
+aGroup-Text (Standard_CString (*Text*), aPoint, 16.0);
+
+
+@subsubsection occt_1621831385_143501245718 Display priorities
+
+Structure display priorities control the order in which structures are drawn. When you display a structure you specify its priority. The lower the value, the lower the display priority. When the display is regenerated the structures with the lowest priority are drawn first. For structures with the same display priority the order in which they were displayed determines the drawing order. CAS.CADE supports eleven structure display priorities.
+
+@subsubsection occt_1621831385_143501245719 About structure hierarchies
+
+The root is the top of a structure hierarchy or structure network. The attributes of a parent structure are passed to its descendants. The attributes of the descendant structures do not affect the parent. Recursive structure networks are not supported.
+
+@subsection occt_1621831385_14350124572 V3d
+@subsubsection occt_1621831385_143501245721 Overview
+The **V3d** package provides the resources to define a 3D viewer and the views attached to this viewer (orthographic, perspective). This package provides the commands to manipulate the graphic scene of any 3D object visualized in a view on screen.
+A set of high-level commands allows the separate manipulation of parameters and the result of a projection (Rotations, Zoom, Panning, etc.) as well as the visualization attributes (Mode, Lighting, Clipping, Depth-cueing, etc) in any particular view.
+
+@subsubsection occt_1621831385_143501245722 Provided services
+The V3d package is basically a set of tools directed by commands from the viewer front-end. This tool set contains methods for creating and editing classes of the viewer such as:
+ * Default parameters of the viewer,
+ * Views (orthographic, perspective),
+ * Lighting (positional, directional, ambient, spot, headlight),
+ * Clipping planes (note that only Z-clipping planes can work with the Phigs interface),
+ * Instantiated sequences of views, planes, light sources, graphic structures, and picks,
+ * Various package methods.
+
+@subsubsection occt_1621831385_143501245723 A programming example
+<h4>Example </h4>
+
+This sample TEST program for the V3d Package uses primary packages Xw and Graphic3d and secondary packages Visual3d, Aspect, Quantity, Phigs, math.
+
+**//Create a Graphic Device from the default DISPLAY **
+Handle(Graphic3d_GraphicDevice) GD =
+new Graphic3d_GraphicDevice(**) ;
+
+**// Create a Viewer to this Device **
+Handle(V3d_Viewer) VM = new V3d_Viewer(GD, 400.,
+// Space size
+V3d_Xpos,// Default projection Quantity_NOC_DARKVIOLET,
+// Default background
+V3d_ZBUFFER,
+// Type of visualization
+V3d_GOURAUD,
+// Shading model
+V3d_WAIT);
+// Update mode
+**// Create a structure in this Viewer **
+Handle(Graphic3d_Structure) S =
+new Graphic3d_Structure(VM-Viewer()) ;
+
+**// Type of structure **
+S-SetVisual (Graphic3d_TOS_SHADING);
+
+**// Create a group of primitives in this structure**
+Handle(Graphic3d_Group) G = new Graphic3d_Group(S) ;
+
+**// Fill this group with one polygon of size 100**
+Graphic3d_Array1OfVertex Points(0,3) ;
+Points(0).SetCoord(-100./2.,-100./2.,-100./2.) ;
+Points(1).SetCoord(-100./2., 100./2.,-100./2.) ;
+Points(2).SetCoord( 100./2., 100./2.,-100./2.) ;
+Points(3).SetCoord( 100./2.,-100./2.,-100./2.) ; Normal.SetCoord(0.,0.,1.) ;
+G-Polygon(Points,Normal) ;
+
+**// Create Ambient and Infinite Lights in this Viewer**
+Handle(V3d_AmbientLight) L1 = new V3d_AmbientLight
+(VM,Quantity_NOC_GRAY50) ;
+Handle(V3d_DirectionalLight) L2 = new V3d_DirectionalLight
+(VM,V3d_XnegYnegZneg,Quantity_NOC_WHITE) ;
+
+**// Create a 3D quality Window from the same GraphicDevice**
+Handle(Xw_Window) W =
+new Xw_Window(GD,*Test V3d*,0.5,0.5,0.5,0.5) ;
+
+**// Map this Window to this screen**
+ W-Map() ;
+
+**// Create a Perspective View in this Viewer**
+Handle(V3d_PerspectiveView) V =
+new V3d_PerspectiveView(VM);
+
+**// Set the Eye position**
+V-SetEye(100.,100.,100.) ;
+
+**// Associate this View with the Window **
+V-SetWindow(W) ;
+
+**// Activate ALL defined Lights in this View **
+V-SetLightOn() ;
+
+**// Display ALL structures in this View **
+(VM-Viewer())-Display() ;
+
+**// Finally update the Visualization in this View **
+V-Update() ;
+
+@subsubsection occt_1621831385_143501245724 Glossary of view transformations
+The following terms are used to define view orientation, i.e. transformation from World Coordinates (WC) to the View Reference Coordinates system (VRC)
+
+The following terms are used to define view mapping, i.e. transformation from View Reference Coordinates (VRC) to the Normalized Projection Coordinates (NPC)
+
+The V3d_View API uses the following terms to define view orientation and mapping
+
+
+@subsubsection occt_1621831385_143501245725 Management of perspective projection
+The perspective projection allows definition of viewing volume as a truncated pyramid (frustum) with apex at the Projection Reference Point. In the View Reference Coordinate system it can be presented by the following picture:
+
+
+Figure 1 View Reference Coordinate System, perspective viewing volume and view mapping parameters
+
+During panning, window limits are changed, as if a sort of *frame* through which the user sees a portion of the view plane was moved over the view. The perspective frustum itself remains unchanged.
+
+The perspective projection is defined by two parameters:
+ * **Depth** value defines distance between Projection Reference Point and the nearest (front) clipping plane.
+ * **ZSize** defines distance between Front and Back clipping planes. The influence of this parameter is caused by the OCCT specific to center viewing volume around View Reference Point so the front and back plane distances were the same: FPD = BPD = ZSize / 2.
+**Note** that the closer the displayed object to the Projection Reference Point the more visible its perspective distortion. Thus, in order to get a good perspective it is recommended to set ZSize value comparable with the expected model size and small Depth value.
+
+However, very small Depth values might lead to inaccuracy of *fit all* operation and to non-realistic perspective distortion.
+<h4>Example </h4>
+
+**// Create a Perspective View in Viewer VM**
+Handle(V3d_PerspectiveView) V =
+new V3d_PerspectiveView(VM);
+
+**// Set the ZSize **
+V-SetZSize(2000.) ;
+
+**// Set the Depth value**
+V-SetDepth(20.) ;
+
+**// Set the current mapping as default**
+**// to be used by Reset() operation**
+V-SetViewMappingDefault() ;
+
+As an alternative to manual setting of perspective parameters the *V3d_View::DepthFitAll* function can be used.
+<h4>Example </h4>
+
+**// Display shape in Viewer VM**
+Handle(AIS_InteractiveContext) aContext =
+new AIS_InteractiveContext(VM);
+aContext-Display(shape);
+
+**// Create a Perspective View in Viewer VM**
+Handle(V3d_PerspectiveView) V =
+new V3d_PerspectiveView(VM);
+
+**// Set automatically the perspective parameters**
+V-DepthFitAll() ;
+
+**// Fit view to object size **
+V-FitAll();
+
+**// Set the current mapping as default**
+**// to be used by Reset() operation**
+V-SetViewMappingDefault() ;
+
+
+It is necessary to take into account that during rotation Z size of the view might be modified automatically to fit the model into the viewing volume.
+Make sure the Eye point never gets between the Front and Back clipping planes.
+In perspective view, changing Z size results in changed perspective effect. To avoid this, an application should specify the maximum expected Z size using V3d_View::SetZSize() method in advance.
+V3d_View::FitAll() with FitZ = Standard_True and V3d_View::ZFitAll() also change the perspective effect and should therefore be used with precautions similar to those for rotation.
+
+@subsubsection occt_1621831385_143501245726 Underlay and overlay layers management
+In addition to interactive 3d graphics displayed in the view you can display an underlying and overlying graphics: text, color scales, drawings.
+
+All of the v3d view’s graphical objects in the overlay are managed by the default layer manager (*V3d_LayerMgr*). The v3d view has a basic layer manager capable of displaying the color scale, but you can redefine this class to provide your own overlay and underlay graphics.
+
+You can assign your own layer manager to the v3d view using the following method:
+ * void V3d_View::SetLayerMgr
+(const Handle (V3d_LayerMgr)& aMgr)
+
+There are three virtual methods to prepare graphics in the manager for further drawing (set up layer dimensions, draw static graphics). These methods could be redefined:
+ * void V3d_LayerMgr::Begin ()
+ * void V3d_LayerMgr::Redraw ()
+ * void V3d_LayerMgr::End ()
+
+The layer manager controls layers* *(*Visual3d_Layer*) and layer items* *(*Visual3d_LayerItem*). Both the overlay and underlay layers can be created by the layer manager.
+
+The layer entity is presented by the *Visual3d_Layer* class. This entity provides drawing services in the layer, for example:
+ * void Visual3d_Layer::DrawText
+ * void Visual3d_Layer::DrawRectangle
+ * void Visual3d_Layer::SetColor
+ * void Visual3d_Layer::SetViewport
+
+The following example demonstrates how to draw overlay graphics by the V3d_LayerMgr:
+<h4>Example </h4>
+
+**// redefined method of V3d_LayerMgr**
+void MyLayerMgr::Redraw ()
+{
+ Quantity_Color aRed (Quantity_NOC_RED);
+ myOverlayLayer-SetColor (aRed);
+ myOverlayLayer-DrawRectangle (0, 0, 100, 100);
+}
+
+The layer contains layer items that will be displayed on view redraw. Such items are the Visual3d_LayerItem entities. To manipulate Visual3d_LayerItem entities assigned to the layer’s internal list you can use the following methods:
+ * void Visual3d_Layer::AddLayerItem
+(const Handle (Visual3d_LayerItem)& Item)
+ * void Visual3d_Layer::RemoveLayerItem
+(const Handle (Visual3d_LayerItem)& Item)
+ * void Visual3d_Layer::RemoveAllLayerItems ()
+ * const Visual3d_NListOfLayerItem&
+Visual3d_Layer::GetLayerItemList ()
+
+The layer’s items are rendered when the following method is called by the graphical driver:
+ * void Visual3d_Layer::RenderLayerItems ()
+
+The *Visual3d_LayerItem* has virtual methods that are used to render the item:
+ * void Visual3d_LayerItem::RedrawLayerPrs ()
+ * void Visual3d_LayerItem::ComputeLayerPrs ()
+
+The item’s presentation can be computed before drawing by the ComputeLayerPrs method to save time on redraw. It also has an additional flag that is used to tell that the presentation should be recomputed:
+ * void Visual3d_LayerItem::SetNeedToRecompute
+(const Standard_Boolean NeedToRecompute)
+ * Standard_Boolean Visual3d_LayerItem::IsNeedToRecompute
+
+An example of Visual3d_LayerItem is *V3d_ColorScaleLayerItem* that represents the color scale entity as the layer’s item.
+The *V3d_ColorScaleLayerItem* sends render requests to the color scale entity represented by it. As this entity (*V3d_ColorScale*) is assigned to the *V3d_LayerMgr* it uses its overlay layer’s services for drawing:
+<h4>Example </h4>
+
+**// tell V3d_ColorScale to draw itself**
+void V3d_ColorScaleLayerItem::RedrawLayerPrs ()
+{
+ Visual3d_LayerItem::RedrawLayerPrs ()
+ if (!MyColorScale.IsNull ())
+ MyColorScale-DrawScale ();
+}
+
+**// V3d_ColorScale has a reference to a LayerMgr**
+void V3d_ColorScale::DrawScale ()
+{
+ **// calls *V3d_ColorScale::PaintRect, V3d_ColorScale::PaintText*, etc …**
+}
+
+**// PaintRect method uses overlay layer of LayerMgr to draw a rectangle **
+void V3d_ColorScale::PaintRect
+ (const Standard_Integer X, const Standard_Integer Y,
+ const Standard_Integer W, const Standard_Integer H,
+ const Quantity_Color aColor,
+ const Standard_Boolean aFilled)
+{
+ const Handle (Visual3d_Layer)& theLayer =
+ myLayerMgr-Overlay ();
+** …**
+
+** **theLayer-SetColor (aColor);
+ theLayer-DrawRectangle (X, Y, W, H);
+** …**
+}
+
+
+@subsubsection occt_1621831385_143501245727 View background styles
+There are three types of background styles available for V3d_view: solid color, gradient color and image.
+
+To set solid color for the background you can use the following methods:
+ * void V3d_View::SetBackgroundColor
+(const Quantity_TypeOfColor Type,
+ const Quantity_Parameter V1,
+ const Quantity_Parameter V2,
+ const Quantity_Parameter V3)
+This method allows you to specify the background color in RGB (red, green, blue) or HLS (hue, lightness, saturation) color spaces, so the appropriate values of the Type parameter are Quantity_TOC_RGB and Quantity_TOC_HLS. **Note** that the color value parameters V1,V2,V3 should be in the range between 0.0-1.0.
+
+ * void V3d_View::SetBackgroundColor
+(const Quantity_Color &Color)
+ * void V3d_View::SetBackgroundColor
+(const Quantity_NameOfColor Name)
+
+The gradient background style could be set up with the following methods:
+ * void V3d_View::SetBgGradientColors
+(const Quantity_Color& Color1,
+ const Quantity_Color& Color2,
+ const Aspect_GradientFillMethod FillStyle,
+ const Standard_Boolean update)
+ * void V3d_View::SetBgGradientColors
+(const Quantity_NameOfColor Color1,
+ const Quantity_NameOfColor Color2,
+ const Aspect_GradientFillMethod FillStyle,
+ const Standard_Boolean update)
+The Color1 and Color2 parameters define the boundary colors of interpolation, the FillStyle parameter defines the direction of interpolation. You can pass Standard_True as the last parameter to update the view.
+
+The fill style can be also set with the following method:
+ * void V3d_View::SetBgGradientStyle
+(const Aspect_GradientFillMethod AMethod,
+const Standard_Boolean update)
+
+To get the current background color you can use the following methods:
+ * void V3d_View::BackgroundColor
+(const Quantity_TypeOfColor Type,
+ Quantity_Parameter &V1,
+ Quantity_Parameter &V2,
+ Quantity_Parameter &V3)
+ * Quantity_Color V3d_View::BackgroundColor()
+ * void V3d_View::GradientBackgroundColors
+(Quantity_Color& Color1,
+ Quantity_Color& Color2)
+ * Aspect_GradientBackground GradientBackground()
+
+To set the image as a background and change the background image style you can use the following methods:
+ * void V3d_View::SetBackgroundImage
+(const Standard_CString FileName,
+ const Aspect_FillMethod FillStyle,
+ const Standard_Boolean update)
+ * void V3d_View::SetBgImageStyle
+(const Aspect_FillMethod FillStyle,
+ const Standard_Boolean update)
+
+The FileName parameter defines the image file name and the path to it, the FillStyle parameter defines the method of filling the background with the image. The methods are:
+ * Aspect_FM_NONE: draw the image in the default position
+ * Aspect_FM_CENTERED: draw the image at the center of the view
+ * Aspect_FM_TILED: tile the view with the image
+ * Aspect_FM_STRETCH: stretch the image over the view
+
+@subsubsection occt_1621831385_143501245728 User-defined clipping planes
+The ability to define custom clipping planes could be very useful for some tasks. The v3d view provides such an opportunity.
+
+The V3d_Plane class provides the services of clipping planes: it holds the plane equation coefficients and provides its graphical representation. To set and get plane equation coefficients you can use the following methods:
+ * void V3d_Plane::SetPlane
+(const Quantity_Parameter A,
+ const Quantity_Parameter B,
+ const Quantity_Parameter C,
+ const Quantity_Parameter D)
+ * void V3d_Plane::Plane
+(Quantity_Parameter& A,
+ Quantity_Parameter& B,
+ Quantity_Parameter& C,
+ Quantity_Parameter& D)
+
+ V3d_Plane also provides display services:
+ * void V3d_Plane::Display
+(const Handle(V3d_View)& aView,
+ const Quantity_Color& aColor)
+ * void V3d_Plane::Erase ()
+ * Standard_Boolean V3d_Plane::IsDisplayed ()
+The Display method could be redefined to provide custom representation of the clipping plane.
+
+The clipping planes could be activated with the following methods:
+ * void V3d_View::SetPlaneOn
+(const Handle(V3d_Plane)& MyPlane)
+ * void V3d_View::SetPlaneOn ()
+The first method appends the given V3d_Plane to the internal list of user-defined clipping planes of a view and activates it. If the plane is already in the list, it becomes activated. The second method activates all of the planes defined for the view.
+
+The clipping planes could be deactivated with the similar methods:
+ * void V3d_View::SetPlaneOff
+(const Handle(V3d_Plane)& MyPlane)
+ * void V3d_View::SetPlaneOff ()
+
+The only difference is that these methods remove the user-defined clipping planes from the internal list. Thus, the view retains only active clipping planes.
+
+You can iterate through the active planes using the following methods:
+ * void V3d_View::InitActivePlanes ()
+sets the iterator to the beginning of the internal list of clipping planes
+ * Standard_Boolean V3d_View::MoreActivePlanes ()
+returns Standard_True if there are more active planes to return
+ * void V3d_View::NextActivePlanes ()
+sets the iterator to the next active plane in the list
+ * Handle(V3d_Plane) V3d_View::ActivePlane ()
+returns the active plane
+
+or check if a certain clipping plane has been activated:
+ * Standard_Boolean V3d_View::IsActivePlane
+(const Handle (V3d_Plane)& aPlane)The number of clipping planes is limited. The following method allows you to check if it is possible to activate at least one more plane in the view or the limit has been reached:
+ * Standard_Boolean V3d_View::IfMorePlanes ()
+<h4>Example </h4>
+
+**// try to use an existing clipping plane or create a new one**
+Handle(V3d_Plane) aCustomPlane;
+myView-InitActivePlanes ();
+if (myView-MoreActivePlanes ())
+ aCustomPlane = myView-ActivePlane ();
+else
+ aCustomPlane = new V3d_Plane ();
+
+**// calculate new coefficients**
+Standard_Real a, b, c, d;
+Standard_Real x = 0.0, y = 0.0, z = 10.0;
+Standard_Real dx = 0.0, dy = 0.0, dz = 1.0;
+gp_Pln aPln (gp_Pnt (x, y, z), gp_Dir (dx, dy, dz));
+aPln.Coefficients (a, b, c, d);
+
+**// update plane**
+aCustomPlane-SetPlane (a, b, c, d);
+myView-SetPlaneOn (aCustomPlane);
+
+@subsubsection occt_1621831385_143501245729 Dumping a 3D scene into an image file
+The 3D scene displayed in the view could be dumped in high resolution into an image file. The high resolution (8192x8192 on some implementations) is achieved using the Frame Buffer Objects (FBO) provided by the graphic driver. Frame Buffer Objects enable off-screen rendering into a virtual view to produce images in the background mode (without displaying any graphics on the screen).
+
+The V3d_View has the following methods for dumping the 3D scene:
+ * Standard_Boolean V3d_View::Dump
+(const Standard_CString theFile,
+ const Image_TypeOfImage theBufferType)
+ * Standard_Boolean V3d_View::Dump
+(const Standard_CString theFile,
+ const Aspect_FormatOfSheetPaper theFormat,
+ const Image_TypeOfImage theBufferType)
+These methods dump the 3D scene into an image file passed by its name and path as theFile.
+The raster image data handling algorithm is based on the Image_PixMap class. The supported extensions are *.png*, *.bmp*, *.jpg*, *.png*.
+The first method dumps the scene into an image file with the view dimensions. The second method allows you to make the dimensions of the output image compatible to a certain format of printing paper passed by theFormat argument.
+The value passed as theBufferType argument defines the type of the buffer for an output image (RGB, RGBA, floating-point, RGBF, RGBAF). Both methods return Standard_True if the scene has been successfully dumped.
+**Please note** that dumping the image for a paper format with large dimensions is a memory consuming operation, it might be necessary to take care of preparing enough free memory to perform this operation.
+
+ * Handle_Image_PixMap V3d_View::ToPixMap
+(const Standard_Integer theWidth,
+ const Standard_Integer theHeight,
+ const Image_TypeOfImage theBufferType,
+ const Standard_Boolean theForceCentered)
+This method allows you to dump the displayed 3d scene into a pixmap with a width and height passed as theWidth and theHeight arguments.
+The value passed as theBufferType argument defines the type of the buffer for a pixmap (RGB, RGBA, floating-point, RGBF, RGBAF).
+The last parameter allows you to center the 3D scene on dumping.
+
+All these methods assume that you have created a view and displayed a 3d scene in it. However, the window used for such a view could be virtual, so you can dump the 3d scene in the background mode without displaying it on the screen. To use such an opportunity you can perform the following steps:
+1) Create a graphic device;
+2) Create a window;
+3) Set up the window as virtual, Aspect_Window::SetVirtual ();
+4) Create a view and an interactive context;
+5) Assign the virtual window to the view;
+6) Display a 3D scene;
+7) Use one of the functions described above to dump the 3D scene.
+
+The following example demonstrates this procedure for the WNT_Window:
+<h4>Example </h4>
+
+**// create a graphic device**
+Handle (WNT_GraphicDevice) aDevice =
+ new Graphic3d_WNTGraphicDevice ();
+
+**// create a window**
+Standard_Integer aDefWidth = 800;
+Standard_Integer aDefHeight = 600;
+Handle (WNT_WClass) aWClass =
+ new WNT_WClass (*Virtual Class*,DefWindowProc,
+ CS_VREDRAW | CS_HREDRAW, 0, 0,
+ ::LoadCursor (NULL, IDC_ARROW));
+Handle (WNT_Window) aWindow =
+ new WNT_Window (aDevice, *VirtualWnd*, aWClass,
+ WS_OVERLAPPEDWINDOW, 0, 0,
+ aDefWidth, aDefHeight);
+
+**// set up the window as virtual**
+aWindow-SetVirtual (Standard_True);
+
+**// create a view and an interactive context**
+Handle (V3d_Viewer) aViewer =
+ new V3d_Viewer (aDevice,
+ Standard_ExtString (*Virtual*));
+Handle (AIS_InteractiveContext) aContext =
+ new AIS_InteractiveContext (aViewer);
+Handle (V3d_View) aView = aViewer-CreateView ();
+
+**// assign the virtual window to the view**
+aView-SetWindow (aWindow);
+
+**// display a 3D scene**
+Handle (AIS_Shape) aBox =
+ new AIS_Shape (BRepPrimAPI_MakeBox (5, 5, 5));
+aContext-Display (aBox);
+aView-FitAll();
+
+**// dump the 3D scene into an image file**
+aView-Dump (*3dscene.png*);
+
+@subsubsection occt_1621831385_1435012457210 Printing a 3D scene
+The contents of a view can be printed out. Moreover, the OpenGl graphic driver used by the v3d view supports printing in high resolution. The print method uses the OpenGl frame buffer (Frame Buffer Object) for rendering the view contents and advanced print algorithms that allow printing in, theoretically, any resolution.
+
+The following method prints the view contents:
+ * void V3d_View::Print
+(const Aspect_Handle hPrnDC,
+ const Standard_Boolean showDialog,
+ const Standard_Boolean showBackground,
+ const Standard_CString filename,
+ const Aspect_PrintAlgo printAlgorithm)
+The hPrnDC is the printer device handle. You can pass your own printer handle or *NULL* to select the printer by the default dialog. In that case you can use the default dialog or pass *Standard_False* as the showDialog argument to select the default printer automatically.
+You can define the filename for the printer driver if you want to print out the result into a file.
+If you do not want to print the background, you can pass *Standard_False* as the showBackground argument.
+The printAlgorithm argument allows you to choose between two print algorithms that define how the 3d scene is mapped to the print area when the maximum dimensions of the frame buffer are smaller than the dimensions of the print area. You can pass the following values as the printAlgorithm argument:
+ * Aspect_PA_STRETCH,
+ * Aspect_PA_TILE
+
+The first value defines the stretch algorithm: the scene is drawn with the maximum possible frame buffer dimensions and then is stretched to the whole printing area. The second value defines TileSplit algorithm: covering the whole printing area by rendering multiple parts of the viewer.
+
+**Please note** that at the moment printing is implemented only for Windows.
+
+@subsubsection occt_1621831385_1435012457211 Vector image export
+The 3D content of a view can be exported to the vector image file format. The vector image export is powered by the GL2PS library. You can export your 3D scenes into a file format supported by the GL2PS library: PostScript (PS), Encapsulated PostScript (EPS), Portable Document Format (PDF), Scalable Vector Graphics (SVG), LaTeX file format and Portable LaTeX Graphics (PGF).
+
+The following method of Visual3d_View class allows you to export your 3D scene:
+ * void Visual3d_View::Export
+(const Standard_CString FileName,
+ const Graphic3d_ExportFormat Format,
+ const Graphic3d_SortType aSortType,
+ const Standard_Real Precision,
+ const Standard_Address ProgressBarFunc,
+ const Standard_Address ProgressObject)
+The FileName defines the output image file name and the Format argument defines the output file format:
+ * Graphic3d_EF_PostScript (PS),
+ * Graphic3d_EF_EhnPostScript (EPS),
+ * Graphic3d_EF_TEX (TEX),
+ * Graphic3d_EF_PDF (PDF),
+ * Graphic3d_EF_SVG (SVG),
+ * Graphic3d_EF_PGF (PGF)
+
+The aSortType parameter defines the GL2PS sorting algorithm for the primitives. The Precision, ProgressBarFunc and ProgressObject parameters are implemented for future uses and at the moment have no effect.
+
+The Export method supports only basic 3d graphics and has several limitations:
+ * Rendering large scenes could be slow and can lead to large output files;
+ * Transparency is only supported for PDF and SVG output;
+ * Textures and some effects are not supported by the GL2PS library.
+@section occt_1621831385_1090976821 2D Presentations
+@subsection occt_1621831385_10909768211 Glossary of 2D terms
+
+@subsubsection occt_1621831385_10909768212 Creating a 2D scene
+
+To create 2D graphic objects and display them on the screen, follow the procedure below:
+**1. **Create the marker map.
+**2. **Create the attribute maps.
+**3. **Define the connection to a graphic device.
+**4. **Create a window.
+**5. **Create a window driver.
+**6. **Install the maps.
+**7. **Create a view.
+**8. **Create a view mapping.
+**9. **Create one or more graphic objects associated with a view.
+**10. **Create primitives and associate them with a graphic object.
+**11. **Get the workspace of the driver.
+**12. **Update the view in the driver.
+
+@subsubsection occt_1621831385_109097682121 Creating the marker map
+
+The marker map defines a set of markers available to the application. Markers may be predefined, Aspect_Tom_X for example, or user-defined.
+
+
+Figure 15. Markers.
+
+The markers are manipulated by an index.
+A marker map is defined as follows:
+<h4>Example </h4>
+
+Handle(Aspect_MarkMap) mkrmap = new Aspect_MarkMap;
+Aspect_MarkMapEntry mkrmapentry1 (1, Aspect_TOM_X)
+Aspect_MarkMapEntry mkrmapentry2 (2, Aspect_TOM_PLUS)
+Aspect_MarkMapEntry mkrmapentry3 (3, Aspect_O_PLUS)
+
+mkrmap-AddEntry (mkrmapentry1);
+mkrmap-AddEntry (mkrmapentry2);
+mkrmap-AddEntry (mkrmapentry3);
+
+
+@subsubsection occt_1621831385_109097682122 Creating the attribute maps
+
+Maps are created for color, line type, line width, and text font. A map is used to reference a given attribute by an integer value.
+
+
+
+Figure 16. Attributes
+
+The color map
+The hardware system will certainly have default colors available but to make the application portable and durable, it must be insulated from external factors by defining the set of colors to be used.
+
+A color map is defined as follows:
+
+<h4>Example </h4>
+
+Handle(Aspect_GenericColorMap) colmap =
+new Aspect_GenericColorMap;
+Aspect_ColorMapEntry colmapentry;
+Quantity_Color YELLOW (Quantity_NOC_YELLOW); colmapentry.SetValue (1, YELLOW);
+colmap-AddEntry (colmapentry);
+Quantity_Color RED (Quantity_NOC_RED);
+colmapentry.SetValue (2, RED);
+colmap-AddEntry (colmapentry);
+Quantity_Color GREEN (Quantity_NOC_GREEN); colmapentry.SetValue (3, GREEN);
+colmap-AddEntry (colmapentry);
+
+You can include as many colors in your color map as you like, though there are some restrictions related to the hardware.
+
+<h4>The type map </h4>
+Lines can be solid, dotted, dashed, dot-dashed, or user defined. For a user-defined type the pattern of solid and blank sections is listed.
+
+A type map is defined as follows:
+
+<h4>Example </h4>
+
+Handle(Aspect_TypeMap) typmap = new Aspect_TypeMap;
+{TColQuantity_Array1OfLength myLineStyle(1,2); myLineStyle.SetValue(1, 2); // the solid part is 2 mm myLineStyle.SetValue(2, 3); // the blank part is 3 mm Aspect_LineStyle linestyle1 (Aspect_TOL_SOLID); Aspect_LineStyle linestyle2 (Aspect_TOL_DASH); Aspect_LineStyle linestyle3 (myLineStyle);
+Aspect_LineStyle linestyle4 (Aspect_TOL_DOTDASH); Aspect_TypeMapEntry typmapentry1 (1, linestyle1); Aspect_TypeMapEntry typmapentry2 (2, linestyle2); Aspect_TypeMapEntry typmapentry3 (3, linestyle3); Aspect_TypeMapEntry typmapentry4 (4, linestyle4);
+typmap-AddEntry (typmapentry1);
+typmap-AddEntry (typmapentry2);
+typmap-AddEntry (typmapentry3);
+typmap-AddEntry (typmapentry4);
+
+
+*NOTE*
+*The line type enumeration and all the other enumerations are available from the Aspect package.*
+
+<h4>The width map </h4>
+The width map defines a set of levels of line thickness available to your application. Widths and all other distances are specified in mms or as members of an enumeration.
+
+A width map is defined as follows:
+<h4>Example </h4>
+
+Handle(Aspect_WidthMap) widmap = new Aspect_WidthMap; Aspect_WidthMapEntry widmapentry1 (1,Aspect_WOL_THIN); Aspect_WidthMapEntry widmapentry2 (2,Aspect_WOL_MEDIUM); Aspect_WidthMapEntry widmapentry3 (3, 3); Aspect_WidthMapEntry widmapentry4 (4, 40); widmap-AddEntry (widmapentry1); widmap-AddEntry (widmapentry2); widmap-AddEntry (widmapentry3); widmap-AddEntry (widmapentry4);
+
+The font map
+The font map defines a set of text fonts available to your application. Default fonts enumerated in Aspect may be used with addition of any other font known to the X driver, specifying the size and slant angle desired.
+
+A font map is defined as follows:
+
+<h4>Example </h4>
+
+Handle(Aspect_FontMap) fntmap = new Aspect_FontMap; Aspect_FontStyle fontstyle1 (*Courier-Bold*, 3, 0.0); Aspect_FontStyle fontstyle2 (*Helvetica-Bold*, 3, 0.0); Aspect_FontStyle fontstyle3 (Aspect_TOF_DEFAULT); Aspect_FontMapEntry fntmapentry1 (1, fontstyle1); Aspect_FontMapEntry fntmapentry2 (2, fontstyle2); Aspect_FontMapEntry fntmapentry3 (3, fontstyle3); fntmap-AddEntry (fntmapentry1); fntmap-AddEntry (fntmapentry2); fntmap-AddEntry (fntmapentry3);
+
+
+@subsubsection occt_1621831385_109097682123 Creating a 2D driver (a Windows example)
+
+<h4>Example </h4>
+
+Handle(WNT_GraphicDevice) TheGraphicDevice = ...; TCollection_ExtendedString aName(*2DV*);
+my2DViewer = new V2d_Viewer(TheGraphicDevice,
+aName.ToExtString());
+@subsubsection occt_1621831385_109097682124 Installing the maps
+
+When the 2D viewer has been created, you may install the maps created earlier.
+<h4>Example </h4>
+
+my2DViewer-SetColorMap(colormap);
+my2DViewer-SetTypeMap(typmap);
+my2DViewer-SetWidthMap(widthmap);
+my2DViewer-SetFontMap(fntmap);
+
+
+@subsubsection occt_1621831385_109097682125 Creating a view (a Windows example)
+
+It is assumed that a valid Windows window may be accessed via the method GetSafeHwnd().
+<h4>Example </h4>
+
+Handle(WNT_Window) aWNTWindow;
+aWNTWindow = new
+WNT_Window(TheGraphicDevice, GetSafeHwnd());
+aWNTWindow-SetBackground(Quantity_NOC_MATRAGRAY); Handle(WNT_WDriver) aDriver = new
+WNT_WDriver(aWNT_Window);
+myV2dView = new V2d_View(aDriver, my2dViewer, 0,0,50);
+// 0,0: view center and 50: view size
+
+
+@subsubsection occt_1621831385_109097682126 Creating the presentable object
+
+Follow the procedure below to compute the presentable object.
+**1. **Build a presentable object inheriting from AIS_InteractiveObject (refer to Chapter 1 Fundamental Concepts, Section Presentable objects)
+**2. **Re-use the graphic object provided as an argument of the Compute method for your presentable object.
+<h4>Example </h4>
+
+void
+myPresentableObject::Compute (
+const Handle(Prs_Mgr_PresentationManager2D)&
+aPresentationManager,
+const Handle(Graphic2d_GraphicObject)& aGrObj,
+const Standard_Integer aMode)
+{
+...
+}
+
+
+@subsubsection occt_1621831385_109097682127 Creating a primitive
+
+Primitives may be created using the resources of the Graphic2d package. Here for example an array is instantiated and filled with a set of three circles with different radii, line widths, and colors, centered on given origin coordinates (4.0, 1.0) and passed to the specified graphic object (go).
+<h4>Example </h4>
+
+Handle(Graphic2d_Circle) tcircle[4]; Quantity_Length radius; for (i=1; i=4; i++) { radius = Quantity_Length (i); tcircle[i-1] = new Graphic2d_Circle (aGrObj, 4.0, 1.0, radius);
+tcircle[i-1]-SetColorIndex (i);
+tcircle[i-1]-SetWidthIndex (1); }
+
+Add a filled rectangle to your graphic object. It will be put outside of your view mapping.
+<h4>Example </h4>
+
+TColStd_Array1OfReal aListX (1, 5);
+TColStd_Array1OfReal aListY (1, 5);
+aListX (1) = -7.0; aListY (1) = -1.0;
+aListX (2) = -7.0; aListY (2) = 1.0;
+aListX (3) = -5.0; aListY (3) = 1.0;
+aListX (4) = -5.0; aListY (4) = -1.0;
+aListX (5) = -7.0; aListY (5) = -1.0;
+Handle(Graphic2d_Polyline) rectangle =
+new Graphic2d_Polyline (go, 0., 0., aListX, aListY); rectangle-SetColorIndex (6);
+rectangle-SetWidthIndex (1);
+rectangle-SetTypeOfPolygonFilling(Graphic2d_TOPF_FILLED); rectangle-SetDrawEdge(Standard_True);
+*A given primitive can only be assigned to a single graphic object.*
+
+
+Figure 17. Graphic object and view mapping in the space model.
+
+@subsection occt_1621831385_10909768213 Dealing with images
+
+@subsubsection occt_1621831385_109097682131 General case
+
+Images are primitives too. The graphic resources can currently accept all image types described in the *AlienImage* package. In the following example only **.xwd **formats are accepted.
+
+Define the primitive Image in the GraphicObject.
+<h4>Example </h4>
+
+Handle(Image_Image) anImage; if (XwdImage || RgbImage) { anImage = AlienUser-ToImage (); Handle(Graphic2d_Image) gImage = new Graphic2d_Image
+(aGrObj, anImage, 0., 0., 0., 0., Aspect_CP_CENTER); }
+
+
+<h4>NOTE</h4>
+*The above constructor for image takes as arguments the graphic object which will contain the image, the image itself, XY coordinates for the center, XY offsets in the device space, and a cardinal point value to give a direction of display. *
+
+Now update the view in the driver. In other words, draw the image.
+
+<h4>Example </h4>
+
+Standard_Boolean clear = Standard_True
+view-Update (driver, viewmapping, W/2., H/2., scale, clear);
+
+
+@subsubsection occt_1621831385_109097682132 Specific case: xwd format
+
+When the manipulated image is stored with the xwd format, a special class Graphic2d_ImageFile may be used to increase performance.
+<h4>Example </h4>
+
+OSD_Path aPath (*C:/test.xwd*);
+OSD_File aFile (aPath);
+Handle(Graphic2d_ImageFile)gImageFile =
+new Graphic2d_ImageFile (aGrObj,
+aFile,
+0.,0.,
+0.,0.,
+Aspect_CP_Center, 1);
+gImageFile-SetZoomable(Standard_True);
+
+
+The graphic contains now an image, which is manipulated as a primitive.
+
+
+@subsection occt_1621831385_10909768214 Dealing with text
+
+The constructor for the Graphic2d_Text takes a reference point in the space model and an angle (in radians) as its arguments, as well as the graphic object to which it is assigned. Note that the angle is ignored unless the Xdps driver, which allows angled text, is in use.
+<h4>Example </h4>
+
+TCollection_ExtendedString str1 (*yellow Courier-bold*); TCollection_ExtendedString str2 (*red Helevetica-bold*); TCollection_ExtendedString str3 (*green Aspect_TOF_DEFAULT*); Handle(Graphic2d_Text) t1 = new Graphic2d_Text
+(aGrObj, str1, 0.3, 0.3, 0.0);
+Handle(Graphic2d_Text) t2 = new Graphic2d_Text
+(aGrObj, str2, 0.0, 0.0, 0.0);
+Handle(Graphic2d_Text) t3 = new Graphic2d_Text
+(aGrObj, str3, -0.3, -0.3, 0.0);
+t1-SetFontIndex (1); t1-SetColorIndex (1);
+t2-SetFontIndex (2); t2-SetColorIndex (2);
+t3-SetFontIndex (3); t3-SetColorIndex (3);
+
+
+@subsection occt_1621831385_10909768215 Dealing with markers
+
+A marker is a primitive that retains its original size when the view is zoomed. Markers can be used, for example, as references to dimensions.
+
+@subsubsection occt_1621831385_109097682151 Vectorial markers
+Every marker takes an XY point as its reference point. The constructor also takes another pair of XY values as an offset from this reference point. For CircleMarker and EllipsMarker this offset point is its center. For PolylineMarker this offset point is its origin i.e. the first point in its list.
+In the example below, a rectangle is created using Graphic2d_Polyline.
+<h4>Example </h4>
+
+TColStd_Array1OfReal rListX (1, 5);
+TColStd_Array1OfReal rListY (1, 5);
+rListX (1) = -0.3; rListY (1) = -0.3;
+rListX (2) = -0.3; rListY (2) = 0.3;
+rListX (3) = 0.3; rListY (3) = 0.3;
+rListX (4) = 0.3; rListY (4) = -0.3;
+rListX (5) = -0.3; rListY (5) = -0.3;
+Handle(Graphic2d_Polyline) rp =
+new Graphic2d_Polyline (aGrObj, rListX, rListY);
+
+
+Two Graphic2d_CircleMarkers are created. The first one has no offset from its center. The second is constrained to be a given offset from a reference point.
+<h4>Example </h4>
+
+Handle(Graphic2d_CircleMarker) rc1 = new
+Graphic2d_CircleMarker
+(aGrObj, 0.04, 0.03, 0.0, 0.0, 0.01); Handle(Graphic2d_CircleMarker) rc2 = new
+Graphic2d_CircleMarker
+(aGrObj, 0.03, -0.03, 0.01, 0.0, 0.01);
+window-Clear ();
+
+
+Figure 18. Figure of zoom and attachment point of a marker.
+
+
+@subsubsection occt_1621831385_109097682152 Indexed markers
+
+Once the marker map has been created, indexed markers may be added to a graphic object.
+<h4>Example </h4>
+
+Handle (Graphic2d_Marker) xmkr = new Graphic2d_Marker
+(aGrObj, 1, 0.04, 0.03, 0.0, 0.0, 0.0);
+Handle (Graphic2d_Marker) plusmkr = new Graphic2d_Marker
+(aGrObj, 2, 0.04, 0.0, 0.0, 0.0, 0.0);
+Handle (Graphic2d_Marker) oplusmkr = new Graphic2d_Marker
+(aGrObj, 3, 0.04, -0.03, 0.0, 0.0, 0.0);
+
+@subsection occt_1621831385_10909768216 Dragging with Buffers
+
+A **buffer** is used to draw very quickly a partial area of the scene without deleting the background context.
+ A buffer contains a set of graphic objects or primitives which are to be moved, rotated or scaled above the scene in the front planes of the view (in this case, double-buffering is not active). For example:
+
+**1. **Draw a very complex scene in the view.
+**2. **Create a buffer of primitives with the primitive color index 10 and the font index 4:
+buffer = new Graphic2d_Buffer (view, 0., 0., 10, 4);
+
+**3. **Add graphic objects or primitives:
+buffer-Add (go);
+buffer-Add (tcircle[1]);
+buffer-Add (t1);
+
+**4. **Post the buffer in the view:
+buffer-Post ();
+
+**5. **Move, rotate or scale the buffer above the view:
+buffer-Move (x,y); buffer-Rotate (alpha);
+buffer-Scale (zoom_factor);
+
+**6. **Unpost the buffer from the view:
+buffer-Unpost ();
+@section occt_1621831385_86393950 2D Resources
+
+
+The 2D resources include the Graphic2d, Image, AlienImage, and V2d packages.
+
+
+@subsection occt_1621831385_863939501 Graphic2d
+
+
+@subsubsection occt_1621831385_8639395011 Overview
+
+The **Graphic2d** package is used to create a 2D graphic object. Each object, called a GraphicObject, is composed of primitives. Each primitive is a class and contains attributes. Each primitive has its own Draw method.
+
+A Graphic2d_Image is created from an Image from the Image package.
+
+
+@subsubsection occt_1621831385_8639395012 The services provided
+
+The **Graphic2d** packages provides classes for creating the following primitives:
+ * Circle
+ * Curve
+ * Ellips
+ * InfiniteLine
+ * Polyline
+ * Segment
+ * SetOfSegments
+ * Text
+ * Marker
+ * SetOfMarkers
+ * VectorialMarker
+ * CircleMarker
+
+**2D Resources **
+ * PolylineMarker
+ * EllipsMarker
+ * Image
+ * ImageFile
+ * SetOfCurves
+
+
+
+@subsection occt_1621831385_863939502 Image
+
+@subsubsection occt_1621831385_8639395021 Overview
+
+The **Image** package provides the resources to produce and manage bitmap images. It has two purposes:
+ * To define what is an image on the CAS.CADE platform.
+ * To define operations which can be carried out on an image.
+
+The package allows the user to manipulate images without knowing their type. For various functionalities such as zoom, pan, and rotation, an application does not need to know the type nor the format of the image. Consequently, the image could be stored as an integer, real, or object of the Color type.
+
+Another important asset of the package is to make the handling of images independent of the type of pixel. Thus a new image based on a different pixel type can be created without rewriting any of the algorithms.
+
+@subsubsection occt_1621831385_8639395022 The services provided
+
+The classes **ColorImage** and **PseudoColorImage** define the two types of image, which can be handled by the Image toolkit. These classes support different types of operations, such as zoom and rotate. The **PixMap** class defines system-independent bitmaps. It stores raster image data and provides special services, such as saving the image data into an image file. The PixMaps are powered by the FreeImage library.
+
+**ColorImage** is used to create 24-bit TrueColor images:
+ * Create a ColorImage object with a given background color.
+ * Request the type of the image.
+ * Request or set the color of a given pixel.
+ * Zoom, rotating, translating, simple and refining transformations.
+ * Set position and size.
+ * Transpose, shift, clip, shift, clear.
+ * Draw line and rectangle.
+
+**PseudoColorImage** is used to create 32-bit images:
+ * Create a PseudoColorImage object with a given background color associated with a given ColorMap (Generic, ColorCube, ColorRamp)
+ * Ask or set the color of a given pixel, row, or column.
+ * Find the maximum & minimum pixel values of an image.
+ * Change the pixel values by scaling.
+ * Change the pixel values below a threshold value.
+ * Zoom, rotating, translating, simple and refining transformations.
+ * Set position and size.
+ * Transpose, shift, clip, shift, clear.
+ * * Draw line and rectangle.
+
+**PixMap **provides support for system-independent bitmaps:
+ * Supports different kinds of raster images, such as 24-bit, 32-bit, 96-bit, 128-bit, or RGB, RGBA, floating-point RGB and RGBA.
+ * Provides direct access to the pixel buffer.
+ * Provides image dump services. The use of FreeImage library enhances these services with the capability of saving raster images into different image file formats. **Note** that without FreeImage library support, the raster images could be dumped into the PPM format only.
+ * PixMaps could be used for handling system bitmaps and dumping window contents.
+
+**Convertor** is used to:
+ * Change an image from a ColorImage to a PseudoColorImage. Select between two dithering algorithms for the change.
+ * Change an image from a PseudoColorImage to a ColorImage.
+ * Change a PseudoColorImage into one with a different ColorMap.
+
+**LookupTable** is used to:
+ * Transform the pixels of a PseudoColorImage.
+
+Various **PixelInterpolation** classes are available for dealing with pixel values at non-integer coordinates.
+
+The package also includes a number of **package methods** for zooming, rotation, translation, as well as simple and refining transformations.
+
+@subsection occt_1621831385_863939503 AlienImage
+
+@subsubsection occt_1621831385_8639395031 Overview
+
+The **AlienImage** package is used to import 2D images from some other format into the CAS.CADE format.
+
+@subsubsection occt_1621831385_8639395032 Available Services
+ * Reads the content of an AlienImage object from a file.
+ * Writes the content of an AlienImage object to a file.
+ * Converts an AlienImage object to an Image object.
+ * Converts an Image object to an AlienImage object.
+
+@subsection occt_1621831385_863939504 V2d
+
+@subsubsection occt_1621831385_8639395041 Overview
+
+This package is used to build a 2D mono-view viewer in a windowing system. It contains the commands available within the viewer (zoom, pan, pick, etc).
+
+@subsubsection occt_1621831385_8639395042 The services provided
+
+The **V2d** package contains the **View** class. **View** is used to:
+ * Create a view in an window.
+ * Handle the view:
+ * zoom
+ * fit all
+ * pan
+ * translate
+ * erase
+ * pick
+ * highlight
+ * set drawing precision
+ * Postscript output
+
+@section occt_1621831385_1676618855 Graphic Attributes
+@subsection occt_1621831385_16766188551 Aspect
+
+@subsubsection occt_1621831385_167661885511 Overview
+
+The **Aspect** package provides classes for the graphic elements, which are common to all 2D and 3D viewers - screen background, windows, edges, groups of graphic attributes that can be used in describing 2D and 3D objects.
+
+@subsubsection occt_1621831385_167661885512 The services provided
+
+The **Aspect** package provides classes to implement:
+ * Color maps,
+ * Pixels,
+ * Groups of graphic attributes,
+ * Edges, lines, background,
+ * Font classes,
+ * Width map classes,
+ * Marker map classes,
+ * Type of Line map classes,
+ * Window,
+ * Driver, PlotterDriver (inherited by PS_Driver), WindowDriver,
+ * Graphic device (inherited by Xw_GraphicDevice, Graphic3d_GraphicDevice),
+ * Enumerations for many of the above,
+ * Array instantiations for edges,
+ * Array instantiations for map entries for color, type, font, width, and marker.
+
+
--- /dev/null
+Workshop Organisation Toolkit {#user_guides__wok}
+==============================
+
+@section occt_wok_1_ Introduction Glossary
+
+@subsection occt_wok_1_1 About the Development Environment
+
+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.
+
+
+
+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**.
+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 *Glossary* 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.
+@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.
+
+
+@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
+
+
+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.
+
+
+
+@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.
+
+
+@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 *Workbenches* section for further details on the workbench structure.
+@subsubsection occt_wok_2_1_2 Files in a Development Unit
+
+Source Files
+------------
+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 *Building an Executable* 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
+
+To create the Development Unit structure for a package use the following syntax:
+~~~~~
+ucreate –p MyPackage
+~~~~~
+
+The package description has the following CDL syntax:
+~~~~~
+package PackageName
+[uses AnotherPackage {‘,’ YetAnotherPackage}]
+is
+[{type-declaration}]
+[{package-method}]
+end [PackageName]’:’
+~~~~~
+
+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*.
+
+@subsubsection occt_wok_2_1_4 Schema
+
+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.
+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.
+
+
+
+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.
+@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 *%MyWorkbench_RootName*.
+
+**Note** that default values help to define various roots.
+
+@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.
+
+
+
+
+@subsection occt_wok_2_23 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.
+
+
+
+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.
+
+
+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 *Configuring Your Account for Tcl and WOK* 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.
+
+@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*** *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 (Hidden step.) Extracts a template for implementation of methods.
+* 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. This file must list all the C, C++, Fortran, lex, and yacc sources.
+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.
+
+
+*FILES: * Is a nomenclature file for a nocdlpack. It is a list of Fortran, C, C++, lex, and yacc files (one per line).
+
+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 the 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
+----------------
+* Primary Files for an Executable
++ <Exec>.cdl Primary executable file
+* C++ Files for an Executable
++ <AnExe>.cxx Source file
++ <AnExe>_[1-9].cxx Other source 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. See the *Building an Executable* section for details.
+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
+~~~~~
+
+Sample Construction of a Test Executable
+----------------------------------------
+The overall process of constructing a test executable is the same as for any other executable. For a sample, refer to the *Construction of an Executable* section.
+
+Setting up a Test Environment
+-----------------------------
+To set up a test environment, move to the * /drv* subdirectory that corresponds to the current profile (e.g. the directory: * /MyExec/drv/DFLT/sun* directory) 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:
+
+* *$STATION* - The current station.
+* *$TARGET_DBMS* - The current database platform.
+* *$PATH* - The current path, plus the bin directories of the parcels.
+* *$LD_LIBRARY_PATH* 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*. *$ORIGDELIVUNITHOME* 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.
+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 *-s*. 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 commands 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 below 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:
+No TOOLKITS file found:
+All toolkits are candidates for substitution. To find out which toolkits are candidates, use the command *w_info -k*.
+Empty TOOLKITS file found:
+No toolkit is a candidate for substitution.
+Non-empty TOOLKITS file found:
+Only those toolkits listed in the TOOLKITS file are candidates for substitution.
+
+Toolkit Substitution
+--------------------
+Toolkit substitution is performed as follows:
+MyEngine uses:
+ A, B and C
+The toolkit TK provides:
+ A and D
+ D uses: E
+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
+---------------
+Primary files for an interface
+
+<Interface>.cdl - 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
+~~~~~
+Jni Files
+---------
+Primary jni file is *Jni.cdl*
+
+Derived Java files for a Jni
+----------------------------
+*<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
+---------------------------
+*<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.
+You display the current profile using the command *> wokprofile*
+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.
+This includes commands for:
+ * Navigation
+ * Managing parameters
+ * Managing profiles.
+wokcd **Navigates** between different WOK entities.
+wokclose **Closes **and reopens entities.
+wokenv **Gets information **about the current WOK environment.
+wokinfo **Displays **information common to all entities.
+woklocate **Locates **files within the development units.
+wokparam **Queries **parameters.
+wokprofile **Modifies **the parameters of the session.
+
+@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.
+Options:
+**-a** 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 *Test Environments* 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.
+*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.
+Options:
+**-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, 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 workshop 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.
+Options:
+**-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 *Development Units* 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.
+
+Specifying Targets (-t)
+-----------------------
+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_5 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 *Tcl Overview* 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 *Writing Tcl Steps for a WOK Build* 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 *$env(WOK_LIBRARY)/wstore_trigger.example*.
+**-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 <Report_ID>.
+**-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** - List 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** 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 */tmp/MyReport* 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** 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 mark are listed in the order they were created. Otherwise, they are listed in order 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 } { ...}* with **comments **being a string containing all the comments on the integration between n1 and n2, and **table**, 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** 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 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.
+
+
+The following enumeration 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** - Move to the src directory of the specified development unit.
+**wdrv** - Move to the drv/DBMS/Station directory of the current development unit.
+**wls** - List the development units in the current workbench.
+**wsrc** - Move 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
+
+
+@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,
+
+ * **umake**, gives access to all available umake options plus compilation options,
+
+ * **CDL browser**, provides information on the class structure or translated classes,
+
+ * **parameters**, allows displaying and editing all EDL files.
+
+
+**Note:** for further information on CDL, refer to the CDL Reference Manual.
+
+@subsubsection occt_wok_5_1_3 Display management
+Click on the Matra Datavision 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.
+
+
+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.
+
+In the right window you get the selection popup menu for the item types:
+
+
+@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** *\@uses* 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:
+~~~~~
+==
+!=
+||
+\&\&
+file
+notfile
+defined
+notdefined
+~~~~~
+**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 *<file>.mygen* and generates a *<file>.c*. 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. Argument: a file ID.
+*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
+Argument: none.
+*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
+Argument: none.
+*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
--- /dev/null
+ Extended Data Exchange (XDE) {#user_guides__xde}
+============================
+
+@section occt_1819379545_842050006 Introduction
+@subsection occt_1819379545_8420500061 Overview of the Extended Data Exchange (XDE)
+This manual explains how to use the Extended Data Exchange (XDE). It provides basic documentation on setting up and using XDE. For advanced information on XDE and its applications, see our offerings on our web site at <a href="http://www.opencascade.com/support/training.html">http://www.opencascade.com/support/training.html</a> * *
+Based on document architecture, XDE allows processing of various types of data to and from external files.
+XDE is available for users of Open CASCADE Technology on all supported platforms (Linux, Windows).
+@subsubsection occt_1819379545_84205000611 Prerequisite
+The Extended Data Exchange (XDE) component requires Advanced Shape Healing for operation.
+@subsubsection occt_1819379545_84205000612 Environment variables
+To use XDE you have to set the environment variables properly. Make sure that two important environment variables are set as follows:
+ * CSF_PluginDefaults points to sources of %CASROOT%/src/XCAFResources ($CASROOT/src/XCAFResources).
+ * CSF_XCAFDefaults points to sources of %CASROOT%/src/XCAFResources ($CASROOT/src/XCAFResources).
+@subsubsection occt_1819379545_84205000613 Basic terms
+For better understanding of XDE, certain key terms are defined:
+ * **Shape **A (simple) shape is a standalone shape, which does not belong to the assembly structure.
+ * **Instance **An instance (of a shape) is a replication of another shape with a location that can be the same location or a different one.
+*Assembly *An assembly defines a construction that is either a root or a sub-assembly.
+@subsubsection occt_1819379545_84205000614 XDE Data Types
+The following types of data are currently supported:
+ * assemblies
+ * validation properties
+ * names
+ * colors
+ * layers
+It is also possible to add new types of data by using tools as prototypes. This makes XDE a basically extensible framework.
+In addition, XDE provides reading and writing tools to read and write the data supported by STEP and IGES files.
+@subsubsection occt_1819379545_84205000615 XDE Organization
+The basis of XDE, called XCAF, is a framework based on OCAF (Open CASCADE Technology Application Framework) and is intended to be used with assemblies and with various kinds of attached data (attributes). Attributes can be Individual attributes for a shape, specifying some characteristics of a shape, or they can be Grouping attributes, specifying that a shape belongs to a given group whose definition is specified apart from the shapes.
+XDE works in an OCAF document with a specific organization defined in a dedicated XCAF module. This organization is used by various functions of XDE to exchange standardized data other than shapes and geometry.
+The Assembly Structure and attributes assigned to shapes are stored in the OCAF tree. It is possible to obtain TopoDS representation for each level of the assembly in the form of TopoDS_Compound or TopoDS_Shape using the API.
+Basic elements used by XDE are introduced in the XCAF sub-module by the package XCAFDoc. These elements consist in descriptions of commonly used data structures (apart from the shapes themselves) in normalized data exchanges. They are not attached to specific applications and do not bring specific semantics, but are structured according to the use and needs of data exchanges.
+The Document used by XDE usually starts as a TDocStd_Document.
+@subsubsection occt_1819379545_84205000616 Assemblies
+XDE supports assemblies by separating shape definitions and their locations. Shapes are simple OCAF objects without a location definition. An assembly consists of several components. Each of these components references one and the same specified shape with different locations. All this provides an increased flexibility in working on multi-level assemblies.
+For example, a mechanical assembly can be defined as follows:
+
+
+Figure 1. Assembly Description and View
+
+XDE defines the specific organization of the assembly content. Shapes are stored on sub-labels of label 0:1:1. There can be one or more roots (called free shapes) whether they are true trees or simple shapes. A shape can be considered to be an Assembly (such as AS1 under 0:1:1:1 in Figure1) if it is defined with Components (sub-shapes, located or not).
+XCAFDoc_ShapeTool is a tool that allows you to manage the Shape section of the XCAF document. This tool is implemented as an attribute and located at the root label of the shape section.
+@subsubsection occt_1819379545_84205000617 Validation Properties
+Validation properties are geometric characteristics of Shapes (volume, centroid, surface area) written to STEP files by the sending system. These characteristics are read by the receiving system to validate the quality of the translation. This is done by comparing the values computed by the original system with the same values computed by the receiving system on the resulting model.
+Advanced Data Exchange supports both reading and writing of validation properties, and provides a tool to check them.
+ <table>
+ <tr>
+ <td>
+
+ </td>
+ </tr>
+ <tr>
+ <td>
+
+ </td>
+ <td>
+ 
+ </td>
+ </tr>
+</table>
+Figure 2. Validation Property Descriptions
+
+Check logs contain deviations of computed values from the values stored in a STEP file. A typical example appears as follows:
+
+In our example, it can be seen that no errors were detected for either area, volume or positioning data.
+@subsubsection occt_1819379545_84205000618 Names
+XDE supports reading and writing the names of shapes to and from IGES and STEP file formats. This functionality can be switched off if you do not need this type of data, thereby reducing the size of the document.
+@subsubsection occt_1819379545_84205000619 Colors and Layers
+XDE can read and write colors and layers assigned to shapes or their subparts (down to the level of faces and edges) to and from both IGES and STEP formats. Three types of colors are defined in the enumeration XCAFDoc_ColorType:
+ * generic color (XCAFDoc_ColorGen)
+ * surface color (XCAFDoc_ColorSurf)
+ * curve color (XCAFDoc_ColorCurv)
+ <table>
+ <tr>
+ <td>
+
+ </td>
+ </tr>
+ <tr>
+ <td>
+
+ </td>
+ <td>
+ 
+ </td>
+ </tr>
+</table>
+Figure 3. Colors and Layers
+
+@section occt_1819379545_1936904462 Basic Concepts
+@subsection occt_1819379545_19369044621 Overview
+As explained in the last chapter, XDE uses TDocStd_Documents as a starting point. The general purpose of XDE is:
+ * Checking if an existing document is fit for XDE
+ * Getting an application and initialized document
+ * Initializing a document to fit it for XDE
+ * Adding, setting and finding data
+ * Querying and managing shapes
+ * Attaching properties to shapes
+The Document used by XDE usually starts as a TDocStd_Document.
+@subsubsection occt_1819379545_193690446211 General Check
+Before working with shapes, properties, and other types of information, the global organization of an XDE Document can be queried or completed to determine if an existing Document is actually structured for use with XDE.
+To find out if an existing TDocStd_Document is suitable for XDE, use:
+Handle(TDocStd_Document) doc...
+if ( XCAFDoc_DocumentTool::IsXCAFDocument (doc) ) { .. yes .. }
+If the Document is suitable for XDE, you can perform operations and queries explained in this guide. However, if a Document is not fully structured for XDE, it must be initialized. See 2.2.1 Initializing an XDE Document (Shapes).
+@subsubsection occt_1819379545_193690446212 Getting an Application or an Initialized Document
+If you want to retrieve an existing application or an existing document (known to be correctly structured for XDE), use:
+Handle(TDocStd_Document) aDoc;
+Handle(XCAFApp_Application) anApp =
+XCAFApp_Application::GetApplication();
+anApp-NewDocument(;MDTV-XCAF;,aDoc);
+@subsection occt_1819379545_19369044622 Shapes and Assemblies
+@subsubsection occt_1819379545_193690446221 Initializing an XDE Document (Shapes)
+An XDE Document begins with a TDocStd_Document. Assuming you have a TDocStd_Document already created, you can ensure that it is correctly structured for XDE by initializing the XDE structure as follows:
+Handle(TDocStd_Document) doc...
+Handle (XCAFDoc_ShapeTool) myAssembly =
+XCAFDoc_DocumentTool::ShapeTool (Doc-Main());
+TDF_Label aLabel = myAssembly-NewShape()
+*NOTE **The method XCAFDoc_DocumentTool::ShapeTool* *returns the XCAFDoc_ShapeTool**. The first time this method is used, it creates the XCAFDoc_ShapeTool**. In our example, a handle is used for the TDocStd_Document**.*
+@subsubsection occt_1819379545_193690446222 Getting a Node considered as an Assembly
+To get a node considered as an Assembly from an XDE structure, you can use the Label of the node. Assuming that you have a properly initialized TDocStd_Document, use:
+Handle(TDocStd_Document) doc...
+Handle(XCAFDoc_ShapeTool) myAssembly =
+XCAFDoc_DocumentTool::ShapeTool (aLabel);
+In the previous example, you can also get the Main Item of an XDE document, which records the root shape representation (as a Compound if it is an Assembly) by using ShapeTool(Doc-Main()) instead of ShapeTool(aLabel).
+You can then query or edit this Assembly node, the Main Item or another one (myAssembly in our examples).
+*NOTE **For the examples in the rest of this guide, myAssembly* *is always presumed to be accessed this way, so this information will not be repeated.*
+@subsubsection occt_1819379545_193690446223 Updating the Assembly after Filling or Editing
+Some actions in this chapter affect the content of the document, considered as an Assembly. As a result, you will sometimes need to update various representations (including the compounds).
+To update the representations, use:
+myAssembly-UpdateAssembly(aLabel);
+Since this call is always used by the editing functions, you need not apply it for such functions. However, you will need this call if special edits, not using XCAF functions, are used on the document.
+@subsubsection occt_1819379545_193690446224 Adding or Setting Top Level Shapes
+Shapes can be added as top-level shapes. Top level means that they can be added to an upper level assembly or added on their own at the highest level as a component or referred by a located instance. Therefore two types of top-level shapes can be added:
+ * shapes with upper level references
+ * free shapes (that correspond to roots) without any upper reference
+*NOTE **Several top-level shapes can be added to the same component.*
+A shape to be added can be defined as a compound (if required), with the following interpretations:
+ * The Shape is a compound
+According to the user choice, it may or may not be interpreted as representing an Assembly. If it is an Assembly, each of its subshapes defines a sub-label.
+ * The Shape is not a compound
+ The Shape is taken as a whole, without breaking it down.
+To break down a Compound in the assembly structure, use:
+Standard_Boolean makeAssembly;
+// True to interpret a Compound as an Assembly,
+// False to take it as a whole
+aLabel = myAssembly-AddShape(aShape, makeAssembly);
+Each node of the assembly therefore refers to its sub-shapes.
+Concerning located instances of sub-shapes, the corresponding shapes, (without location) appear at distinct sub-labels. They are referred to by a shape instance, which associates a location.
+@subsubsection occt_1819379545_193690446225 Setting a given Shape at a given Label
+A top-level shape can be changed. In this example, no interpretation of compound is performed:
+Standard_CString LabelString ...;
+// identifies the Label (form ;0:i:j...;)
+TDF_Label aLabel...;
+// A label must be present
+myAssembly-SetShape(aLabel, aShape);
+@subsubsection occt_1819379545_193690446226 Getting a Shape from a Label
+To get a shape from its Label from the top-level, use:
+TDF_Label aLabel...
+// A label must be present
+if (aLabel.IsNull()) {
+ // no such label : abandon
+}
+TopoDS_Shape aShape;
+aShape = myAssembly-GetShape(aLabel);
+if (aShape.IsNull()) {
+ // this label is not for a Shape
+}
+*NOTE: **If the label corresponds to an assembly, then the result is a compound.*
+@subsubsection occt_1819379545_193690446227 Getting a Label from a Shape
+To get a Label which is attached to a Shape from the top-level, use:
+Standard_Boolean findInstance = Standard_False;
+// (this is default value)
+aLabel = myAssembly-FindShape(aShape [,findInstance]);
+if (aLabel.IsNull()) {
+ // no label found for this shape
+}
+If findInstance is True, a search is made for the shape with the same location. If False (default value), a search is made among original, non-located shapes.
+@subsubsection occt_1819379545_193690446228 Other Queries on a Label
+Various other queries can be made from a Label within the Main Item of XDE:
+<h4>Main Shapes</h4>
+To determine if a Shape is recorded (or not), use:
+if ( myAssembly-IsShape(aLabel) ) { .. yes .. }
+
+To determine if the shape is ;top-level; (was added by the AddShape method), use:
+if ( myAssembly-IsTopLevel(aLabel) ) { .. yes .. }
+
+To get a list of top-level shapes (added by the AddShape method), use:
+TDF_LabelSequence frshapes;
+myAssembly-GetShapes(frshapes);
+
+To get all free shapes at once if the list above has only one item, use:
+TopoDS_Shape result = myAssembly-GetShape(frshapes.Value(1));
+
+If there is more than one item, you must create and fill a compound, use:
+TopoDS_Compound C;
+BRep_Builder B;
+B.MakeCompound(C);
+for(Standard_Integer i=1; i=frshapes.Length(); i++) {
+ TopoDS_Shape S = myAssembly-GetShape(frshapes.Value(i));
+ B.Add(C,S);
+}
+
+In our example, the result is the compound C.
+To determine if a shape is a free shape (no reference or super-assembly), use:
+if ( myAssembly-IsFree(aLabel) ) { .. yes .. }
+
+To get a list of Free Shapes (roots), use:
+TDF_LabelSequence frshapes;
+myAssembly-GetFreeShapes(frshapes);
+
+To get the shapes, which use a given shape as a component, use:
+TDF_LabelSequence users;
+Standard_Integer nbusers = myAssembly-GetUsers(aLabel,users);
+The count of users is contained with nbusers. It contains 0 if there are no users.
+<h4>Assembly and Components</h4>
+To determine if a label is attached to the main part or to a sub-part (component), use:
+if (myAssembly-IsComponent(aLabel)) { .. yes .. }
+
+To determine whether a label is a node of a (sub-) assembly or a simple shape, use:
+if ( myAssembly-IsAssembly(aLabel) ) { .. yes .. }
+
+If the label is a node of a (sub-) assembly, you can get the count of components, use:
+Standard_Boolean subchilds = Standard_False; //default
+Standard_Integer nbc = myAssembly-NbComponents (aLabel
+[,subchilds]);
+If subchilds is True, commands also consider sub-levels. By default, only level one is checked.
+
+To get component Labels themselves, use:
+Standard_Boolean subchilds = Standard_False; //default
+TDF_LabelSequence comps;
+Standard_Boolean isassembly = myAssembly-GetComponents
+(aLabel,comps[,subchilds]);
+@subsubsection occt_1819379545_193690446229 Instances and References for Components
+To determine if a label is a simple shape, use:
+if ( myAssembly-IsSimpleShape(aLabel) ) { .. yes .. }
+
+To determine if a label is a located reference to another one, use:
+if ( myAssembly-IsReference(aLabel) ) { .. yes .. }
+
+If the label is a located reference, you can get the location, use:
+TopLoc_Location loc = myAssembly-GetLocation (aLabel);
+
+To get the label of a referenced original shape (also tests if it is a reference), use:
+Standard_Boolean isref = myAssembly-GetReferredShape
+(aLabel, refLabel);
+*NOTE **isref* *returns False if aLabel* *is not for a reference.*
+@subsection occt_1819379545_19369044623 Editing Shapes
+In addition to the previously described AddShape and SetShape, several shape edits are possible.
+
+To remove a Shape, and all its sub-labels, use:
+Standard_Boolean remsh = myAssembly-RemoveShape(aLabel);
+// remsh is returned True if done
+*NOTE: **This operation will fail if the shape is neither free nor top level.*
+
+To add a Component to the Assembly, from a new shape, use:
+Standard_Boolean expand = Standard_False; //default
+TDF_Label aLabel = myAssembly-AddComponent (aShape
+[,expand]);
+If expand is True and if aShape is a Compound, it is broken down to produce sub-components, one for each of its sub-shapes.
+
+To add a component to the assembly, from a previously recorded shape (the new component is defined by the label of the reference shape, and its location), use:
+TDF_Label refLabel ...; // the label of reference shape
+TopLoc_Location loc ...; // the desired location
+TDF_Label aLabel = myAssembly-AddComponent (refLabel, loc);
+
+To remove a component from the assembly, use:
+myAssembly-RemoveComponent (aLabel);
+@subsection occt_1819379545_19369044624 Management of Sub-Shapes
+In addition to components of a (sub-)assembly, it is possible to have individual identification of some sub-shapes inside any shape. Therefore, you can attach specific attributes such as Colors. Some additional actions can be performed on sub-shapes that are neither top-level, nor components:
+
+To add a sub-shape to a given Label, use:
+TDF_Label subLabel = myAssembly-AddSubShape (aLabel,
+subShape);
+
+To find the Label attached to a given sub-shape, use:
+TDF_Label subLabel; // new label to be computed
+if ( myAssembly- FindSubShape (aLabel, subShape,
+subLabel)) { .. yes .. }
+If the sub-shape is found (yes), subLabel is filled by the correct value.
+
+To find the top-level simple shape (not a compound whether free or not), which contains a given sub-shape, use:
+TDF_Label mainLabel = myAssembly-FindMainShape(subShape);
+*NOTE: **There should be only one shape for a valid model. In any case, the search stops on the first one found.*
+
+To get the sub-shapes of a shape, which are recorded under a label, use:
+TDF_LabelSequence subs;
+Standard_Boolean hassubs = myAssembly-GetSubShapes
+(aLabel,subs);
+@subsection occt_1819379545_19369044625 Properties
+Some properties can be attached directly to shapes. These properties are:
+ * Name (standard definition from OCAF)
+ * Centroid (for validation of transfer)
+ * Volume (for validation of transfer)
+ * Area (for validation of transfer)
+Some other properties can also be attached, and are also managed by distinct tools for Colors and Layers. Colors and Layers are managed as an alternative way of organizing data (by providing a way of identifying groups of shapes).
+Colors are put into a table of colors while shapes refer to this table. There are two ways of attaching a color to a shape:
+ * By attaching an item from the table.
+ * Adding the color directly.
+When the color is added directly, a search is performed in the table of contents to determine if it contains the requested color. Once this search and initialize operation is done, the first way of attaching a color to a shape is used.
+@subsubsection occt_1819379545_193690446251 Name
+Name is implemented and used as a TDataStd_Name, which can be attached to any label. Before proceeding, consider that:
+ * In IGES, every entity can have a name with an optional numeric part called a Subscript Label. For example, ;MYCURVE; is a name, and ;MYCURVE(60); is a name with a Subscript Label.
+ * In STEP, there are two levels: Part Names and Entity Names:
+Part Names are attached to ;main shapes; such as parts and assemblies. These Part Names are specifically supported by XDE.
+Entity Names can be attached to every Geometric Entity. This option is rarely used, as it tends to overload the exploitation of the data structure. Only some specific cases justify using this option: for example, when the sending system can really ensure the stability of an entity name after each STEP writing. If such stability is ensured, you can use this option to send an Identifier for external applications using a database.
+*NOTE: **Both IGES or STEP files handle names as pure ASCII strings.*
+These considerations are not specific to XDE. What is specific to data exchange is the way names are attached to entities.
+
+To get the name attached to a label (as a reminder using OCAF), use:
+Handle(TDataStd_Name) N;
+if ( !aLabel.FindAttribute(TDataStd_Name::GetID(),N)) {
+ // no name is attached
+}
+TCollection_ExtendedString name = N-Get();
+Don't forget to consider Extended String as ASCII, for the exchange file.
+
+To set a name to a label (as a reminder using OCAF), use:
+TCollection_ExtendedString aName ...;
+// contains the desired name for this Label (ASCII)
+TDataStd_Name::Set (aLabel, aName);
+@subsubsection occt_1819379545_193690446252 Centroid
+A Centroid is defined by a Point to fix its position. It is handled as a property, item of the class XCAFDoc_Centroid, sub-class of TDF_Attribute. However, global methods give access to the position itself.
+This notion has been introduced in STEP, together with that of Volume, and Area, as defining the ;Validation Properties;: this feature allows exchanging the geometries and some basic attached values, in order to perform a synthetic checking on how they are maintained after reading and converting the exchange file. This exchange depends on reliable exchanges of Geometry and Topology. Otherwise, these values can be considered irrelevant.
+Along with Volume (see 2.5.4), it can be determined at any level of an assembly, thereby allowing a check of both individual simple shapes and their combinations including locations.
+To get a Centroid attached to a Shape, use:
+gp_Pnt pos;
+Handle(XCAFDoc_Centroid) C;
+aLabel.FindAttribute ( XCAFDoc_Centroid::GetID(), C );
+if ( !C.IsNull() ) pos = C-Get();
+
+To set a Centroid to a Shape, use:
+gp_Pnt pos (X,Y,Z);
+// the position previously computed for the centroid
+XCAFDoc_Centroid::Set ( aLabel, pos );
+@subsubsection occt_1819379545_193690446253 Area
+An Area is defined by a Real, it corresponds to the computed Area of a Shape, provided that it contains surfaces. It is handled as a property, item of the class XCAFDoc_Area, sub-class of TDF_Attribute.
+This notion has been introduced in STEP but it is usually disregarded for a Solid, as Volume is used instead. In addition, it is attached to simple shapes, not to assemblies.
+
+To get an area attached to a Shape, use:
+Standard_Real area;
+Handle(XCAFDoc_Area) A;
+L.FindAttribute ( XCAFDoc_Area::GetID(), A );
+if ( !A.IsNull() ) area = A-Get();
+
+To set an area value to a Shape, use:
+Standard_Real area ...;
+// value previously computed for the area
+XCAFDoc_Area::Set ( aLabel, area );
+@subsubsection occt_1819379545_193690446254 Volume
+A Volume is defined by a Real and corresponds to the computed volume of a Shape, provided that it contains solids. It is handled as a property, an item of the class XCAFDoc_Volume, sub-class of TDF_Attribute.
+This notion has been introduced in STEP. It may be attached to simple shapes or their assemblies for computing cumulated volumes and centers of gravity (see also 2.5.2 Centroid).
+
+To get a Volume attached to a Shape, use:
+Standard_Real volume;
+Handle(XCAFDoc_Volume) V;
+L.FindAttribute ( XCAFDoc_Volume::GetID(), V );
+if ( !V.IsNull() ) volume = V-Get();
+
+To set a volume value to a Shape, use:
+Standard_Real volume ...;
+// value previously computed for the volume
+XCAFDoc_Volume::Set ( aLabel, volume );
+@subsection occt_1819379545_19369044626 Colors
+In an XDE document, colors are managed by the class XCAFDoc_ColorTool. This is done with the same principles as for ShapeTool with Shapes, and with the same capability of having a tool on the Main Label, or on any sub-label. The Property itself is defined as an XCAFDoc_Color, sub-class of TDF_Attribute.
+Colors are stored in a child of the starting document label: it is the second level (0.1.2), while Shapes are at the first level. Each color then corresponds to a dedicated label, the property itself is a Quantity_Color, which has a name and value for Red, Green, Blue. A Color may be attached to Surfaces (flat colors) or to Curves (wireframe colors), or to both. A Color may be attached to a sub-shape. In such a case, the sub-shape (and its own sub-shapes) takes its own Color as a priority.
+Colors and Shapes are related to by Tree Nodes.
+These definitions are common to various exchange formats, at least for STEP and IGES.
+@subsubsection occt_1819379545_193690446261 Initialization
+To query, edit, or initialize a Document to handle Colors of XCAF, use:
+Handle(XCAFDoc_ColorTool) myColors =
+XCAFDoc_DocumentTool::ColorTool(Doc-Main ());
+This call can be used at any time. The first time it is used, a relevant structure is added to the document. This definition is used for all the following color calls and will not be repeated for these.
+@subsubsection occt_1819379545_193690446262 Adding a Color
+There are two ways to add a color. You can:
+ * add a new Color defined as Quantity_Color and then directly set it to a Shape (anonymous Color)
+ * define a new Property Color, add it to the list of Colors, and then set it to various shapes.
+When the Color is added by its value Quantity_Color, it is added only if it has not yet been recorded (same RGB values) in the Document.
+
+To set a Color to a Shape using a label, use:
+Quantity_Color Col (red,green,blue);
+XCAFDoc_ColorType ctype ..;
+// can take one of these values :
+// XCAFDoc_ColorGen : all types of geometries
+// XCAFDoc_ColorSurf : surfaces only
+// XCAFDoc_ColorCurv : curves only
+myColors-SetColor ( aLabel, Col, ctype );
+
+Alternately, the Shape can be designated directly, without using its label, use:
+myColors-SetColor ( aShape, Col, ctype );
+// Creating and Adding a Color, explicitly
+Quantity_Color Col (red,green,blue);
+TDF_Label ColLabel = myColors-AddColor ( Col );
+*NOTE: **this Color can then be named, allowing later retrieval by its Name instead of its Value.*
+
+To set a Color, identified by its Label and already recorded, to a Shape, use:
+XCAFDoc_ColorType ctype ..; // see above
+if ( myColors-SetColors ( aLabel, ColLabel, ctype) ) {
+.. it is done .. }
+In this example, aLabel can be replaced by aShape directly.
+@subsubsection occt_1819379545_193690446263 Queries on Colors
+Various queries can be performed on colors. However, only specific queries are included in this section, not general queries using names.
+
+To determine if a Color is attached to a Shape, for a given color type (ctype), use:
+if ( myColors-IsSet (aLabel , ctype)) {
+ // yes, there is one ..
+}
+In this example, aLabel can be replaced by aShape directly.
+
+To get the Color attached to a Shape (for any color type), use:
+Quantity_Color col;
+// will receive the recorded value (if there is some)
+if ( !myColors-GetColor(aLabel, col) ) {
+// sorry, no color ..
+}
+// color name can also be queried from : col.StringName
+// or col.Name
+In this example, aLabel can be replaced by aShape directly.
+
+To get the Color attached to a Shape, with a specific color type, use:
+XCAFDoc_ColorType ctype ..;
+// the desired color type
+Quantity_Color col;
+// will receive the recorded value (if there is some)
+if ( !myColors-GetColor(aLabel, ctype, col) ) {
+// sorry, no color ..
+}
+
+To get all the Colors recorded in the Document, use:
+Quantity_Color col; // to receive the values
+TDF_LabelSequence ColLabels;
+myColors-GetColors(ColLabels);
+Standard_Integer i, nbc = ColLabels.Length();
+for (i = 1; i = nbc; i ++) {
+ aLabel = Labels.Value(i);
+ if ( !myColors-GetColor(aLabel, col) ) continue;
+ // col receives the color n0 i ..
+}
+
+To find a Color from its Value, use:
+Quantity_Color Col (red,green,blue);
+TDF_Label ColLabel = myColors-FindColor (Col);
+if ( !ColLabel.IsNull() ) { .. found .. }
+@subsubsection occt_1819379545_193690446264 Editing Colors
+Besides adding colors, the following attribute edits can be made:
+
+To unset a Color on a Shape, use:
+XCAFDoc_ColorType ctype ...;
+// desired type (XCAFDoc_ColorGen for all )
+myColors-UnSetColor (aLabel,ctype);
+
+To remove a Color and all the references to it (so that the related shapes will become colorless), use:
+myColors-RemoveColor(ColLabel);
+@subsection occt_1819379545_19369044627 Layers
+Layers are handled using the same principles as for Colors (see 2.6 Colors). Simply replace ;Color; with ;Layer; when dealing with Layers. Layers are supported by the class XCAFDoc_LayerTool.
+The class of the property is XCAFDoc_Layer, sub-class of TDF_Attribute while its definition is a TCollection_ExtendedString. Integers are generally used when dealing with Layers. The general cases are:
+ * IGES has LevelList as a list of Layer Numbers (not often used)
+ * STEP identifies a Layer (not by a Number, but by a String), to be more general.
+@subsection occt_1819379545_19369044628 Reading and Writing STEP or IGES
+Note that saving and restoring the document itself are standard OCAF operations. As the various previously described definitions enter into this frame, they will not be explained any further.
+The same can be said for Viewing: presentations can be defined from Shapes and Colors.
+There are several important points to consider:
+ * Previously defined Readers and Writers for dealing with Shapes only, whether Standard or Advanced, remain unchanged in their form and in their dependencies. In addition, functions other than mapping are also unchanged.
+ * XDE provides mapping with data other than Shapes. Names, Colors, Layers, Validation Properties (Centroid, Volume, Area), and Assembly Structure are hierarchic with rigid motion.
+ * XDE mapping is relevant for use within the Advanced level of Data Exchanges, rather than Standard ones, because a higher level of information is better suited to a higher quality of shapes. In addition, this allows to avoid the multiplicity of combinations between various options. Note that this choice is not one of architecture but of practical usage and packaging.
+ * Reader and Writer classes for XDE are generally used like those for Shapes. However, their use is adapted to manage a Document rather than a Shape.
+The packages to manage this are IGESCAFControl for IGES, and STEPCAFControl for STEP.
+@subsubsection occt_1819379545_193690446281 Reading a STEP file
+To read a STEP file by itself, use:
+STEPCAFControl_Reader reader;
+IFSelect_ReturnStatus readstat = reader.ReadFile(filename);
+// The various ways of reading a file are available here too :
+// to read it by the reader, to take it from a WorkSession ...
+Handle(TDocStd_Document) doc...
+// the document referred to is already defined and
+// properly initialized.
+// Now, the transfer itself
+if ( !reader.Transfer ( doc ) ) {
+ cout;Cannot read any relevant data from the STEP file;endl;
+ // abandon ..
+}
+// Here, the Document has been filled from a STEP file,
+// it is ready to use
+In addition, the reader provides methods that are applicable to document transfers and for directly querying of the data produced.
+@subsubsection occt_1819379545_193690446282 Writing a STEP file
+To write a STEP file by itself, use:
+STEPControl_StepModelType mode =
+STEPControl_AsIs;
+// Asis is the recommended value, others are available
+// Firstly, perform the conversion to STEP entities
+STEPCAFControl_Writer writer;
+//(the user can work with an already prepared WorkSession or create a //new one)
+Standard_Boolean scratch = Standard_False;
+STEPCAFControl_Writer writer ( WS, scratch );
+// Translating document (conversion) to STEP
+if ( ! writer.Transfer ( Doc, mode ) ) {
+ cout;The document cannot be translated or gives no result;endl;
+ // abandon ..
+}
+// Writing the File
+IFSelect_ReturnStatus stat = writer.Write(file-name);
+@subsubsection occt_1819379545_193690446283 Reading an IGES File
+Use the same procedure as for a STEP file but with IGESCAFControl instead of STEPCAFControl.
+@subsubsection occt_1819379545_193690446284 Writing an IGES File
+Use the same procedure as for a STEP file but with IGESCAFControl instead of STEPCAFControl.
+@subsection occt_1819379545_19369044629 Using an XDE Document
+There are several ways of exploiting XDE data from an application, you can:
+-# 1. Get the data relevant for the application by mapping XDE/Appli, then discard the XDE data once it has been used.
+-# 2. Create a reference from the Application Document to the XDE Document, to have its data available as external data.
+-# 3. Embed XDE data inside the Application Document (see the following section for details).
+-# 4. Directly exploit XDE data such as when using file checkers.
+@subsubsection occt_1819379545_193690446291 XDE Data inside an Application Document
+To have XCAF data elsewhere than under label 0.1, you use the DocLabel of XDE. The method DocLabel from XCAFDoc_DocumentTool determines the relevant Label for XCAF. However, note that the default is 0.1.
+In addition, as XDE data is defined and managed in a modular way, you can consider exclusively Assembly Structure, only Colors, and so on.
+As XDE provides an extension of the data structure, for relevant data in standardized exchanges, note the following:
+ * This data structure is fitted for data exchange, rather than for use by the final application.
+ * The provided definitions are general, for common use and therefore do not bring strongly specific semantics.
+As a result, if an application works on Assemblies, on Colors or Layers, on Validation Properties (as defined in STEP), it can rely on all or a part of the XDE definitions, and include them in its own data structure.
+In addition, if an application has a data structure far from these notions, it can get data (such as Colors and Names on Shapes) according to its needs, but without having to consider the whole.
+
+@section occt_1819379545_685425104 Package XCAFDoc
+@subsection occt_1819379545_6854251041 General description
+This package is intended for definition of general structure of an XDE document and tools to work with it.
+The document is composed of sections, each section storing its own kind of data and managing by a corresponding tool.
+The API enumeration is
+ * XCAFDoc_ColorType.
+The API classes are the following:
+ * XCAFDoc_DocumentTool
+ * XCAFDoc_Location
+ * XCAFDoc_Color
+ * XCAFDoc_Volume
+ * XCAFDoc_ Area
+ * XCAFDoc_ Centroid
+ * XCAFDoc_ ShapeTool
+ * XCAFDoc_ ColorTool
+ * XCAFDoc_ LayerTool
+ * XCAFDoc_ GraphNode
+@subsection occt_1819379545_6854251042 Enumeration XCAFDoc_ColorType
+Definition:
+enumeration ColorType is
+ColorGen, -- simple color
+ColorSurf, -- color of surfaces
+ColorCurv -- color of curves
+end ColorType;
+Purpose: Defines types of color assignments.
+@subsection occt_1819379545_6854251043 Class XCAFDoc_DocumentTool
+@subsubsection occt_1819379545_68542510431 General description
+Purpose: Attribute marking an OCAF document as being an XDE document.
+Creates the sections structure of the document.
+@subsubsection occt_1819379545_68542510432 Methods
+The methods are the following:
+<h4>Constructors</h4>
+XCAFDoc_DocumentTool()
+Purpose: Empty constructor
+<h4>Methods:</h4>
+ * XCAFDoc_DocumentTool::Init
+void XCAFDoc_DocumentTool::Init() const
+Purpose: To be called when reading this attribute from a file.
+ * XCAFDoc_DocumentTool::Set
+Handle(XCAFDoc_DocumentTool) XCAFDoc_DocumentTool::Set(
+const TDF_Label& L, const Standard_Boolean IsAcces)
+ * Purpose: Creates (if does not exist) a DocumentTool attribute on 0.1 label if IsAcces is true, else on L label. This label will be returned by DocLabel(); If the attribute is already set it will not be reset on L even if IsAcces is false. ColorTool and ShapeTool attributes are also set by this method. Returns DocumentTool from XCAFDoc;
+ * XCAFDoc_DocumentTool::DocLabel
+TDF_Label XCAFDoc_DocumentTool::DocLabel(
+const TDF_Label& acces)
+ * Purpose: Returns the label where the DocumentTool attribute is or *0.1* if DocumentTool is not yet set.
+ * XCAFDoc_DocumentTool::ShapesLabel
+TDF_Label XCAFDoc_DocumentTool::ShapesLabel(
+const TDF_Label& acces)
+Purpose: Returns the shapes sub-label of DocLabel().
+ * XCAFDoc_DocumentTool::ColorsLabel
+TDF_Label XCAFDoc_DocumentTool::ColorsLabel(
+const TDF_Label& acces)
+Purpose: Returns the colors sub-label of DocLabel().
+ * XCAFDoc_DocumentTool::LayersLabel
+TDF_Label XCAFDoc_DocumentTool::LayersLabel(
+const TDF_Label& acces)
+Purpose: Returns the layers sub-label of DocLabel().
+ * XCAFDoc_DocumentTool::ShapeTool
+Handle(XCAFDoc_ShapeTool) XCAFDoc_DocumentTool::ShapeTool(
+const TDF_Label& acces)
+Purpose: Creates (if does not exist) a ShapeTool attribute on ShapesLabel().
+ * XCAFDoc_DocumentTool::ColorTool
+Handle(XCAFDoc_ColorTool) XCAFDoc_DocumentTool::ColorTool (
+const TDF_Label& acces)
+Purpose: Creates (if does not exist) a ColorTool attribute on ColorsLabel().
+ * XCAFDoc_DocumentTool::LayerTool
+Handle(XCAFDoc_LayerTool) XCAFDoc_DocumentTool::LayerTool (
+const TDF_Label& acces)
+Purpose: Creates (if does not exist) a LayerTool attribute on LayersLabel().
+@subsection occt_1819379545_6854251044 Class XCAFDoc_Location
+@subsubsection occt_1819379545_68542510441 General description
+Purpose: Attribute to store TopLoc_Location.
+Inherits Attribute from TDF
+@subsubsection occt_1819379545_68542510442 Methods
+The methods are the following:
+<h4>Constructors</h4>
+XCAFDoc_Location()
+Purpose: Empty constructor.
+<h4>Methods:</h4>
+ * XCAFDoc_Location::Set
+void XCAFDoc_Location::Set(const TopLoc_Location& Loc)
+Purpose: Sets a Location attribute.
+Handle(XCAFDoc_Location) XCAFDoc_Location::Set(
+const TDF_Label& L,const TopLoc_Location& Loc)
+ * Purpose: Finds or creates a Location attribute and sets its value. The Location attribute is returned.
+ * XCAFDoc_Location::Get
+TopLoc_Location XCAFDoc_Location::Get() const
+Purpose: Returns Location from TopLoc.
+@subsection occt_1819379545_6854251045 Class XCAFDoc_Color
+@subsubsection occt_1819379545_68542510451 General description
+Purpose: Attribute to store color.
+Inherits Attribute from TDF
+@subsubsection occt_1819379545_68542510452 Methods
+The methods are the following:
+<h4>Constructors</h4>
+XCAFDoc_Color()
+Purpose: Empty constructor.
+<h4>Methods:</h4>
+ * XCAFDoc_Color::Set
+void XCAFDoc_Color::Set(const Quantity_Color& C)
+void XCAFDoc_Color::Set(const Quantity_NameOfColor C)
+void XCAFDoc_Color::Set(const Standard_Real R,
+const Standard_Real G, const Standard_Real B)
+Purpose: Sets a Color attribute.
+Handle(XCAFDoc_Color) XCAFDoc_Color::Set(
+const TDF_Label& L, const Quantity_Color& C)
+Handle(XCAFDoc_Color) XCAFDoc_Color::Set(
+const TDF_Label& L, const Quantity_NameOfColor C)
+Handle(XCAFDoc_Color) XCAFDoc_Color::Set(
+const TDF_Label& L, const Standard_Real R,
+const Standard_Real G, const Standard_Real B)
+Purpose: Finds or creates a Color attribute and sets its value. The Color attribute is returned.
+ * XCAFDoc_Color::GetColor
+Quantity_Color XCAFDoc_Color::GetColor() const
+Purpose: Returns a Color attribute.
+ * XCAFDoc_Color::GetNOC
+Quantity_NameOfColor XCAFDoc_Color::GetNOC() const
+Purpose: Returns a Name of Color.
+ * XCAFDoc_Color::GetRGB
+void XCAFDoc_Color::GetRGB(Standard_Real& R,
+Standard_Real& G, Standard_Real& B) const
+Purpose: Returns RGB.
+@subsection occt_1819379545_6854251046 Class XCAFDoc_Volume
+@subsubsection occt_1819379545_68542510461 General description
+Purpose: Attribute to store volume.
+Inherits Attribute from TDF
+
+
+
+@subsubsection occt_1819379545_68542510462 Methods
+The methods are the following:
+<h4>Constructors</h4>
+XCAFDoc_Volume()
+Purpose: Empty constructor.
+<h4>Methods:</h4>
+ * XCAFDoc_Volume::Set
+void XCAFDoc_Volume::Set (const Standard_Real V)
+Purpose: Sets a value of Volume.
+Handle(XCAFDoc_Volume) XCAFDoc_Volume::Set (
+const TDF_Label& L,const Standard_Real V)
+Purpose: Finds or creates a Volume attribute and sets its value.
+ * XCAFDoc_Volume::Get
+Standard_Real XCAFDoc_Volume::Get() const
+Purpose: Returns a value of Volume
+Standard_Boolean XCAFDoc_Volume::Get(
+const TDF_Label& label,Standard_Real& vol)
+Purpose: Returns Volume as argument. Returns false if there is no such attribute at the label.
+@subsection occt_1819379545_6854251047 Class XCAFDoc_Area
+@subsubsection occt_1819379545_68542510471 General description
+Purpose: Attribute to store area.
+Inherits Attribute from TDF
+@subsubsection occt_1819379545_68542510472 Methods
+The methods are the following:
+<h4>Constructors</h4>
+XCAFDoc_Area()
+Purpose: Empty constructor.
+<h4>Methods:</h4>
+ * XCAFDoc_Area::Set
+void XCAFDoc_Area::Set (const Standard_Real V)
+Purpose: Sets a value of area.
+Handle(XCAFDoc_Area) XCAFDoc_Area::Set (
+const TDF_Label& L,const Standard_Real V)
+Purpose: Finds or creates an Area attribute and sets its value.
+ * XCAFDoc_Area::Get
+Standard_Real XCAFDoc_Area::Get() const
+Purpose: Returns a value of area.
+Standard_Boolean XCAFDoc_Area::Get(
+const TDF_Label& label, Standard_Real& area)
+Purpose: Returns the volume of area as an argument and success status returns false if there is no such attribute at the label.
+@subsection occt_1819379545_6854251048 Class XCAFDoc_Centroid
+@subsubsection occt_1819379545_68542510481 General description
+Purpose: Attribute to store Centroid.
+Inherits Attribute from TDF
+@subsubsection occt_1819379545_68542510482 Methods
+The methods are the following:
+<h4>Constructors</h4>
+XCAFDoc_Centroid()
+Purpose: Empty constructor.
+<h4>Methods:</h4>
+ * XCAFDoc_Centroid::Set
+void XCAFDoc_Centroid::Set(const gp_Pnt& pnt)
+Purpose: Sets a Centroid attribute.
+Handle(XCAFDoc_Centroid) XCAFDoc_Centroid::Set(
+const TDF_Label& L, const gp_Pnt& pnt)
+Purpose: Finds or creates a Centroid attribute and sets its value. The Centroid attribute is returned.
+ * XCAFDoc_Area::Get
+gp_Pnt XCAFDoc_Centroid::Get() const
+Purpose: Returns a Centroid attribute.
+Standard_Boolean XCAFDoc_Centroid::Get(
+const TDF_Label& label,gp_Pnt& pnt)
+Purpose: Returns a point as an argument. Returns false if there is no such attribute at the label.
+@subsection occt_1819379545_6854251049 Class XCAFDoc_ShapeTool
+@subsubsection occt_1819379545_68542510491 General description
+ Purpose: attribute containing the Shapes section of an XDE document.
+Provides tools for management of the Shapes section.
+@subsubsection occt_1819379545_68542510492 Methods
+The methods are the following:
+<h4>Constructors</h4>
+XCAFDoc_ShapeTool()
+Purpose: Empty constructor.
+<h4>Method Set</h4>
+ * XCAFDoc_ ShapeTool::Set
+Handle(XCAFDoc_ShapeTool) XCAFDoc_ShapeTool::Set(const TDF_Label& L)
+Purpose: Creates (if does not exist) ShapeTool from XCAFDoc on L.
+<h4>Methods for work with top-level structure of shapes </h4>
+ * XCAFDoc_ShapeTool::Search
+Standard_Boolean XCAFDoc_ShapeTool::Search (
+const TopoDS_Shape &S, TDF_Label &L,
+const Standard_Boolean findInstance,
+const Standard_Boolean findComponent,
+const Standard_Boolean findSubShape) const
+Purpose: General tool to find a (sub) shape in the document
+- If findInstance is True, and S has a non-null location, first tries to find the shape among the top-level shapes with this location
+- If not found, and findComponent is True, tries to find the shape among the components of assemblies
+- If not found, tries to find the shape without location among top-level shapes
+- If not found and findSubshape is True, tries to find a shape as a subshape of top-level simple shapes
+Returns False if nothing is found.
+ * XCAFDoc_ShapeTool::FindShape
+Standard_Boolean XCAFDoc_ShapeTool::FindShape (
+const TopoDS_Shape& S, TDF_Label& L,
+const Standard_Boolean findInstance) const
+Purpose. Returns the label corresponding to shape S (searches among top-level shapes, not including subcomponents of assemblies). If findInstance is False (default), searches for the non-located shape (i.e. among original shapes). If findInstance is True, searches for the shape with the same location, including shape instances. Returns True if S is found.
+TDF_Label XCAFDoc_ShapeTool::FindShape (const TopoDS_Shape& S,
+const Standard_Boolean findInstance) const
+Purpose: Does the same as the previous method. Returns the Null label if not found.
+ * XCAFDoc_ShapeTool::GetShape
+Standard_Boolean XCAFDoc_ShapeTool::GetShape (
+const TDF_Label& L, TopoDS_Shape& S)
+Purpose: To get TopoDS_Shape from the shape's label. For component, returns a new shape with a correct location. Returns False if the label does not contain a shape.
+TopoDS_Shape XCAFDoc_ShapeTool::GetShape(const TDF_Label& L)
+Purpose: To get TopoDS_Shape from the shape's label. For component, returns a new shape with a correct location. Returns a Null shape if the label does not contain a shape.
+ * XCAFDoc_ShapeTool::NewShape
+TDF_Label XCAFDoc_ShapeTool::NewShape() const
+Purpose: Creates a new (empty) top-level shape. Initially it holds an empty TopoDS_Compound.
+ * XCAFDoc_ShapeTool::SetShape
+void XCAFDoc_ShapeTool::SetShape (const TDF_Label& L,
+const TopoDS_Shape& S) const
+Purpose: Sets representation (TopoDS_Shape) for the top-level shape.
+ * XCAFDoc_ShapeTool::AddShape
+TDF_Label XCAFDoc_ShapeTool::AddShape (const TopoDS_Shape& S,
+const Standard_Boolean makeAssembly) const
+Purpose: Adds a new top-level (creates and returns a new label). If makeAssembly is True, treats TopAbs_COMPOUND shapes as assemblies (creates assembly structure).
+ * XCAFDoc_ShapeTool::RemoveShape
+Standard_Boolean XCAFDoc_ShapeTool::RemoveShape (
+const TDF_Label& L) const
+Purpose: Removes a shape (whole label and all its sublabels). Returns False (and does nothing) if the shape is not free or is not a top-level shape.
+ * XCAFDoc_ShapeTool::GetShapes
+void XCAFDoc_ShapeTool::GetShapes (TDF_LabelSequence& Labels) const
+Purpose: Returns a sequence of all top-level shapes.
+ * XCAFDoc_ShapeTool::GetFreeShapes
+void XCAFDoc_ShapeTool::GetFreeShapes (
+TDF_LabelSequence& FreeLabels) const
+Purpose: Returns a sequence of all top-level shapes, which are free (i.e. not referred by any other shape).
+ * XCAFDoc_ShapeTool::GetUsers
+Standard_Integer XCAFDoc_ShapeTool::GetUsers (const TDF_Label& L,
+TDF_LabelSequence& Labels,
+const Standard_Boolean getsubchilds)
+Purpose: Returns a list of labels, which refer to shape L as a component. Returns the number of users (0 if the shape is free).
+ * XCAFDoc_ShapeTool::GetLocation
+TopLoc_Location XCAFDoc_ShapeTool::GetLocation (const TDF_Label& L)
+Purpose: Returns the location of instance.
+ * XCAFDoc_ShapeTool::GetReferredShape
+Standard_Boolean XCAFDoc_ShapeTool::GetReferredShape (
+const TDF_Label& L, TDF_Label& Label)
+Purpose: Returns the label, which corresponds to a shape referred by L. Returns False if the label is not a reference.
+<h4>Methods for analysis</h4>
+ * XCAFDoc_ShapeTool::IsTopLevel
+Standard_Boolean XCAFDoc_ShapeTool::IsTopLevel (const TDF_Label& L) const
+Purpose: Returns True if the label is a label of a top-level shape, as opposed to a component of an assembly or a subshape.
+ * XCAFDoc_ShapeTool::IsShape
+Standard_Boolean XCAFDoc_ShapeTool::IsShape (const TDF_Label& L)
+Purpose: Returns True if the label represents a shape (simple shape, assembly or reference).
+ * XCAFDoc_ShapeTool::IsSimpleShape
+Standard_Boolean XCAFDoc_ShapeTool::IsSimpleShape (const TDF_Label& L)
+Purpose: Returns True if the label is a label of a simple shape.
+ * XCAFDoc_ShapeTool::IsReference
+Standard_Boolean XCAFDoc_ShapeTool::IsReference (const TDF_Label& L)
+Purpose: Returns true if L is a located instance of another shape i.e. a reference.
+XCAFDoc_ShapeTool::IsAssembly
+Standard_Boolean XCAFDoc_ShapeTool::IsAssembly (const TDF_Label& L)
+Purpose: Returns True if the label is a label of assembly, i.e. contains sublabels which are assembly components. This is relevant only if IsShape() is True.
+ * XCAFDoc_ShapeTool::IsComponent
+Standard_Boolean XCAFDoc_ShapeTool::IsComponent (const TDF_Label& L)
+Purpose: Returns true if L is a reference serving as a component of an assembly.
+ * XCAFDoc_ShapeTool::IsSubShape
+Standard_Boolean XCAFDoc_ShapeTool::IsSubShape (const TDF_Label& L)
+Purpose: Returns true if L is a subshape of a top-level shape.
+Standard_Boolean XCAFDoc_ShapeTool::IsSubShape (
+const TDF_Label &shapeL,
+const TopoDS_Shape &sub) const
+Purpose: Checks whether shape sub is a subshape of a shape stored on label shapeL.
+ * XCAFDoc_ShapeTool::IsFree
+Standard_Boolean XCAFDoc_ShapeTool::IsFree (const TDF_Label& L)
+Purpose: Returns True if the label is not used by any assembly, i.e. contains sublabels which are assembly components. This is relevant only if IsShape() is True (There is no Father TreeNode on this L).
+<h4>Methods for work with assembly structure </h4>
+ * XCAFDoc_ShapeTool::NbComponents
+Standard_Integer XCAFDoc_ShapeTool::NbComponents (const TDF_Label& L,
+const Standard_Boolean getsubchilds)
+Purpose: Returns the number of Assembles components.
+ * XCAFDoc_ShapeTool::GetComponents
+Standard_Boolean XCAFDoc_ShapeTool::GetComponents (const TDF_Label& L,
+TDF_LabelSequence& Labels,
+const Standard_Boolean getsubchilds)
+Purpose: Returns a list of components of an assembly. Returns False if the label is not an assembly.
+ * XCAFDoc_ShapeTool::AddComponent
+TDF_Label XCAFDoc_ShapeTool::AddComponent (const TDF_Label& assembly,
+const TDF_Label& compL, const TopLoc_Location &Loc) const
+Purpose: Adds a component given by its label and location to the assembly. Note: the assembly must be IsAssembly() or IsSimpleShape().
+ * XCAFDoc_ShapeTool::AddComponent
+TDF_Label XCAFDoc_ShapeTool::AddComponent (const TDF_Label& assembly,
+const TopoDS_Shape& comp,
+const Standard_Boolean expand) const
+Purpose: Adds a shape (located) as a component to the assembly. If necessary, creates an additional top-level shape for the component and returns the Label of component. If expand is True and the component is Compound, it will be created as an assembly also. Note: the assembly must be IsAssembly() or IsSimpleShape().
+ * XCAFDoc_ShapeTool::RemoveComponent
+void XCAFDoc_ShapeTool::RemoveComponent (const TDF_Label& comp) const
+Purpose: Removes a component from its assembly.
+ * XCAFDoc_ShapeTool::UpdateAssembly
+void XCAFDoc_ShapeTool::UpdateAssembly (const TDF_Label& L) const
+Purpose: Updates an assembly at label L.
+<h4>Methods for work with sub-shapes of shape</h4>
+ * XCAFDoc_ShapeTool::FindSubShape
+Standard_Boolean XCAFDoc_ShapeTool::FindSubShape (
+const TDF_Label &shapeL, const TopoDS_Shape &sub,
+TDF_Label &L) const
+Purpose: Finds a label for subshape sub of the shape stored on label shapeL. Returns a Null label if it is not found.
+ * XCAFDoc_ShapeTool::AddSubShape
+TDF_Label XCAFDoc_ShapeTool::AddSubShape (const TDF_Label &shapeL,
+const TopoDS_Shape &sub) const
+Purpose: Adds a label for subshape sub of the shape stored on label shapeL. Returns a Null label if it is not a subshape.
+ * XCAFDoc_ShapeTool::FindMainShape
+TDF_Label XCAFDoc_ShapeTool::FindMainShape (
+const TopoDS_Shape &sub) const
+Purpose: Performs a search among top-level shapes to find the shape containing sub as a subshape. Checks only simple shapes, and returns the first found label (which should be the only one for valid model).
+ * XCAFDoc_ShapeTool::GetSubShapes
+Standard_Boolean XCAFDoc_ShapeTool::GetSubShapes (
+const TDF_Label &L, TDF_LabelSequence& Labels)
+Purpose: Returns the list of labels identifying subshapes of the given shape. Returns False if no subshapes are placed on that label.
+<h4>Auxiliary methods</h4>
+ * XCAFDoc_ShapeTool::MakeReference
+void XCAFDoc_ShapeTool::MakeReference (const TDF_Label &L,
+const TDF_Label &refL, const TopLoc_Location &loc)
+Purpose: Makes a shape on label L to be a reference to shape refL with location loc.
+ * XCAFDoc_ShapeTool::BaseLabel
+TDF_Label XCAFDoc_ShapeTool::BaseLabel () const
+Purpose: returns the label under which shapes are stored.
+@subsection occt_1819379545_68542510410 Class XCAFDoc_ColorTool
+@subsubsection occt_1819379545_685425104101 General description
+Purpose: Attribute containing Colors section of an XDE document.
+Provides tools for management of the Colors section of a document.
+@subsubsection occt_1819379545_685425104102 Methods
+The methods are the following:
+<h4>Constructors</h4>
+XCAFDoc_ShapeTool()
+Purpose: Empty constructor.
+<h4>Method Set</h4>
+ * XCAFDoc_ColorTool::Set
+Handle(XCAFDoc_ColorTool) XCAFDoc_ColorTool::Set(const TDF_Label& L)
+Purpose: Creates (if does not exist) a ColorTool.
+<h4>Methods for general structure</h4>
+ * XCAFDoc_ColorTool::BaseLabel
+TDF_Label XCAFDoc_ColorTool::BaseLabel() const
+Purpose: Returns the label under which colors are stored
+ * XCAFDoc_ColorTool::ShapeTool
+const Handle(XCAFDoc_ShapeTool)& XCAFDoc_ColorTool::ShapeTool()
+Purpose: Returns the internal XCAFDoc_ShapeTool tool
+<h4>Methods for color table management</h4>
+ * XCAFDoc_ColorTool::IsColor
+Standard_Boolean XCAFDoc_ColorTool::IsColor (const TDF_Label& lab) const
+Purpose: Returns True if the label belongs to a colortable and is a color definition
+ * XCAFDoc_ColorTool::GetColor
+Standard_Boolean XCAFDoc_ColorTool::GetColor (const TDF_Label& lab,
+Quantity_Color& col) const
+Purpose: Returns a color defined by label lab. Returns False if the label is not in the colortable or does not define a color.
+ * XCAFDoc_ColorTool::FindColor
+Standard_Boolean XCAFDoc_ColorTool::FindColor (
+const Quantity_Color& col,
+TDF_Label& lab) const
+Purpose: Finds a color definition in the colortable and returns its label if found. Returns False if the color is not found in the colortable.
+ * XCAFDoc_ColorTool::FindColor
+TDF_Label XCAFDoc_ColorTool::FindColor (const Quantity_Color& col) const
+Purpose: Finds a color definition in the colortable and returns its label if found (or Null label otherwise)
+ * XCAFDoc_ColorTool::AddColor
+TDF_Label XCAFDoc_ColorTool::AddColor (const Quantity_Color& col) const
+Purpose: Adds a color definition to the colortable and returns its label (returns the existing label if the same color is already defined).
+ * XCAFDoc_ColorTool::RemoveColor
+void XCAFDoc_ColorTool::RemoveColor (const TDF_Label& lab) const
+Purpose: Removes color from the colortable.
+ * XCAFDoc_ColorTool::GetColors
+void XCAFDoc_ColorTool::GetColors (TDF_LabelSequence& Labels) const
+Purpose: Returns a sequence of colors currently stored in the colortable.
+<h4>Methods for assignment of colors to labels</h4>
+ * XCAFDoc_ColorTool::SetColor
+void XCAFDoc_ColorTool::SetColor (const TDF_Label& L,
+const TDF_Label& colorL, const XCAFDoc_ColorType type) const
+Purpose: Sets a link with a GUID defined by type (see XCAFDoc::ColorRefGUID()) from label L to a color defined by colorL.
+void XCAFDoc_ColorTool::SetColor (const TDF_Label& L,
+const Quantity_Color& Color,
+const XCAFDoc_ColorType type) const
+Purpose: Sets a link with a GUID defined by type (see XCAFDoc::ColorRefGUID()) from label L to color Color in the colortable. Adds a color as necessary.
+ * XCAFDoc_ColorTool::UnSetColor
+void XCAFDoc_ColorTool::UnSetColor (const TDF_Label& L,
+const XCAFDoc_ColorType type) const
+Purpose: Removes a link with a GUID defined by type (see XCAFDoc::ColorRefGUID()) from label L to color Color.
+ * XCAFDoc_ColorTool::IsSet
+Standard_Boolean XCAFDoc_ColorTool::IsSet (const TDF_Label& L,
+const XCAFDoc_ColorType type) const
+Purpose: Returns True if label L has a color assignment of the type type.
+ * XCAFDoc_ColorTool::GetColor
+Standard_Boolean XCAFDoc_ColorTool::GetColor (const TDF_Label& L,
+const XCAFDoc_ColorType type, TDF_Label& colorL)
+Purpose: Returns a label with a color assigned to L as type. Returns False if no such color is assigned.
+Standard_Boolean XCAFDoc_ColorTool::GetColor (const TDF_Label& L,
+const XCAFDoc_ColorType type, Quantity_Color& color)
+Purpose: Returns a color assigned to L as type. Returns False if no such color is assigned.
+<h4>Methods for assignment of colors to shapes in the Shapes section</h4>
+ * XCAFDoc_ColorTool::SetColor
+Standard_Boolean XCAFDoc_ColorTool::SetColor (const TopoDS_Shape& S,
+const TDF_Label& colorL, const XCAFDoc_ColorType type)
+Purpose: Sets a link with a GUID defined by type (see XCAFDoc::ColorRefGUID()) from label L to the color defined by colorL. Returns False if cannot find a label for shape S.
+Standard_Boolean XCAFDoc_ColorTool::SetColor (const TopoDS_Shape& S,
+const Quantity_Color& Color, const XCAFDoc_ColorType type)
+Purpose: Sets a link with a GUID defined by type (see XCAFDoc::ColorRefGUID()) from label L to color Color in the colortable. Adds a color as necessary. Returns False if cannot find a label for shape S.
+ * XCAFDoc_ColorTool::UnSetColor
+Standard_Boolean XCAFDoc_ColorTool::UnSetColor (const TopoDS_Shape& S,
+const XCAFDoc_ColorType type)
+Purpose: Removes a link with a GUID defined by type (see XCAFDoc::ColorRefGUID()) from label L to color Color. Returns True if such link existed.
+ * XCAFDoc_ColorTool::IsSet
+Standard_Boolean XCAFDoc_ColorTool::IsSet (const TopoDS_Shape& S,
+const XCAFDoc_ColorType type)
+Purpose: Returns True if label L has a color assignment of the type type.
+ * XCAFDoc_ColorTool::GetColor
+Standard_Boolean XCAFDoc_ColorTool::GetColor (const TopoDS_Shape& S,
+const XCAFDoc_ColorType type, TDF_Label& colorL)
+Purpose: Returns label with a color assigned to L as type. Returns False if no such color is assigned.
+Standard_Boolean XCAFDoc_ColorTool::GetColor (const TopoDS_Shape& S,
+const XCAFDoc_ColorType type, Quantity_Color& color)
+Purpose: Returns a color assigned to L as type. Returns False if no such color is assigned.
+@subsection occt_1819379545_68542510411 Class XCAFDoc_LayerTool;
+@subsubsection occt_1819379545_685425104111 General description
+Purpose: Attribute containing Layers section of an XDE document.
+Provides tools for management of the Layers section of a document.
+@subsubsection occt_1819379545_685425104112 Methods
+The methods are the following:
+<h4>Constructors</h4>
+XCAFDoc_LayerTool()
+Purpose: Empty constructor.
+<h4>Method Set</h4>
+ * XCAFDoc_LayerTool::Set
+Handle(XCAFDoc_LayerTool) XCAFDoc_LayerTool::Set(const TDF_Label& L)
+<h4>Method of general structure</h4>
+ * XCAFDoc_LayerTool::BaseLabel
+TDF_Label XCAFDoc_LayerTool::BaseLabel() const
+Purpose: Returns the label under which Layers are stored.
+ * XCAFDoc_LayerTool::ShapeTool
+const Handle(XCAFDoc_ShapeTool)& XCAFDoc_LayerTool::ShapeTool()
+Purpose: Returns the internal XCAFDoc_ShapeTool tool.
+<h4>Methods for Layer table management</h4>
+ * XCAFDoc_LayerTool::IsLayer
+Standard_Boolean XCAFDoc_LayerTool::IsLayer(const TDF_Label& lab) const
+Purpose: Returns True if a label belongs to the Layertable and is a Layer definition.
+ * XCAFDoc_LayerTool::GetLayer
+Standard_Boolean XCAFDoc_LayerTool::GetLayer (const TDF_Label& lab,
+TCollection_ExtendedString& aLayer) const
+Purpose: Returns a Layer defined by label lab. Returns False if the label is not in Layertable or does not define aLayer.
+ * XCAFDoc_LayerTool::FindLayer
+Standard_Boolean XCAFDoc_LayerTool::FindLayer (
+const TCollection_ExtendedString& aLayer,
+TDF_Label& lab) const
+Purpose: Finds a Layer definition in theLayertable and returns its label if found. Returns False if the Layer is not found in the Layertable.
+TDF_Label XCAFDoc_LayerTool::FindLayer(
+const TCollection_ExtendedString& aLayer) const
+Purpose: Finds a Layer definition in the Layertable and returns its label if found (or the Null label otherwise).
+ * XCAFDoc_LayerTool::AddLayer
+TDF_Label XCAFDoc_LayerTool::AddLayer(
+const TCollection_ExtendedString& aLayer) const
+Purpose: Adds a Layer definition to the Layertable and returns its label (returns the existing label if the same Layer is already defined).
+ * XCAFDoc_LayerTool::RemoveLayer
+void XCAFDoc_LayerTool::RemoveLayer(const TDF_Label& lab) const
+Purpose: Removes a Layer from the Layertable.
+ * XCAFDoc_LayerTool::GetLayerLabels
+void XCAFDoc_LayerTool::GetLayerLabels(TDF_LabelSequence& Labels) const
+Purpose: Returns a sequence of Layers currently stored in the Layertable.
+ * XCAFDoc_LayerTool::SetLayer
+void XCAFDoc_LayerTool::SetLayer(const TDF_Label& L,
+const TDF_Label& LayerL,
+const Standard_Boolean shapeInOneLayer) const
+Purpose: Sets a link from label L to a Layer defined by LayerL, an optional parameter shapeInOneLayer shows whether a shape could be in a number of layers or only in one.
+void XCAFDoc_LayerTool::SetLayer(const TDF_Label& L,
+const TCollection_ExtendedString& aLayer,
+const Standard_Boolean shapeInOneLayer) const
+Purpose: Sets a link from label L to Layer aLayer in the Layertable. Adds aLayer as necessary; an optional parameter shapeInOneLayer shows whether a shape could be in a number of layers or only in one.
+ * XCAFDoc_LayerTool::UnSetLayers
+void XCAFDoc_LayerTool::UnSetLayers(const TDF_Label& L) const
+Purpose: Removes a link from label L to all layers.
+ * XCAFDoc_LayerTool::UnSetOneLayer
+Standard_Boolean XCAFDoc_LayerTool::UnSetOneLayer(
+const TDF_Label& L,
+const TCollection_ExtendedString& aLayer) const
+Purpose: Removes a link from label L and Layer aLayer. Returns FALSE if no such layer exists.
+ * XCAFDoc_LayerTool::IsSet
+Standard_Boolean XCAFDoc_LayerTool::IsSet(const TDF_Label& L,
+const TCollection_ExtendedString& aLayer) const
+Purpose: Returns True if label L has a Layer associated with the aLayer.
+ * XCAFDoc_LayerTool::GetLayers
+Standard_Boolean XCAFDoc_LayerTool::GetLayers(const TDF_Label& L,
+Handle(TColStd_HSequenceOfExtendedString)& aLayerS)
+Purpose: Returns a sequence of strings aLayerS that are associated with label L.
+Handle(TColStd_HSequenceOfExtendedString) XCAFDoc_LayerTool::GetLayers(
+const TDF_Label& L)
+Purpose: Returns a sequence of strings that are associated with label L.
+ * XCAFDoc_LayerTool::GetShapesOfLayer
+void XCAFDoc_LayerTool::GetShapesOfLayer(const TDF_Label& layerL,
+TDF_LabelSequence& ShLabels) const
+Purpose: Returns a sequence of shape labels that are assigned with layers to ShLabels.
+ * XCAFDoc_LayerTool::IsVisible
+Standard_Boolean XCAFDoc_LayerTool::IsVisible (
+const TDF_Label& layerL) const
+Purpose: Return TRUE if a layer is visible, FALSE if it is invisible.
+ * XCAFDoc_LayerTool::SetVisibility
+void XCAFDoc_LayerTool::SetVisibility (const TDF_Label& layerL,
+const Standard_Boolean isvisible) const
+Purpose: Set the visibility of a layer. If a layer is invisible when on its layer will set UAttribute with a corresponding GUID.
+<h4>Methods for assignment of Layers to shapes in the Shapes section</h4>
+ * XCAFDoc_LayerTool::SetLayer
+Standard_Boolean XCAFDoc_LayerTool::SetLayer(const TopoDS_Shape& Sh,
+const TDF_Label& LayerL,
+const Standard_Boolean shapeInOneLayer)
+Purpose: Sets a link from a label containing shape Sh with a layer situated at label LayerL. An optional parameter shapeInOneLayer shows whether a shape could be in a number of layers or only in one. Returns FALSE if no such shape Sh or label LayerL exists.
+Standard_Boolean XCAFDoc_LayerTool::SetLayer(const TopoDS_Shape& Sh,
+const TCollection_ExtendedString& aLayer,
+const Standard_Boolean shapeInOneLayer)
+Purpose: Sets a link from a label containing shape Sh with layer aLayer. Adds aLayer to LayerTable if necessary. An optional parameter shapeInOneLayer shows whether a shape could be in a number of layers or only in one. Returns FALSE if no such shape Sh exists.
+ * XCAFDoc_LayerTool::UnSetLayers
+Standard_Boolean XCAFDoc_LayerTool::UnSetLayers(const TopoDS_Shape& Sh)
+Purpose: Removes a link between shape Sh and all Layers at the LayerTable. Returns FALSE if no such shape Sh exists in XCAF Document.
+ * XCAFDoc_LayerTool::UnSetOneLayer
+Standard_Boolean XCAFDoc_LayerTool::UnSetOneLayer(
+const TopoDS_Shape& Sh,
+const TCollection_ExtendedString& aLayer)
+Purpose: Removes a link between shape Sh and layer aLayer. Returns FALSE if no such layer aLayer or shape Sh exists.
+ * XCAFDoc_LayerTool::IsSet
+Standard_Boolean XCAFDoc_LayerTool::IsSet(const TopoDS_Shape& Sh,
+Purpose: Returns True if shape Sh has a Layer associated with the aLayer.
+ * XCAFDoc_LayerTool::GetLayers
+Standard_Boolean XCAFDoc_LayerTool::GetLayers(const TopoDS_Shape& Sh,
+Handle(TColStd_HSequenceOfExtendedString)& aLayerS)
+Purpose: Returns a sequence of strings aLayerS associated with shape Sh.
+Handle(TColStd_HSequenceOfExtendedString) XCAFDoc_LayerTool::GetLayers(
+const TopoDS_Shape& Sh)
+Purpose: Returns a sequence of strings associated with shape Sh.
+@subsection occt_1819379545_68542510412 Class XCAFDoc_GraphNode;
+@subsubsection occt_1819379545_685425104121 General description
+Purpose: Attribute containing a sequence of father and child labels.
+Creates and allows to work with Graph in XCAFDocument.
+@subsubsection occt_1819379545_685425104122 Methods
+The methods are the following:
+<h4>Constructors</h4>
+XCAFDoc_GraphNode()
+Purpose: Empty constructor.
+<h4>Class methods working on the node </h4>
+ * XCAFDoc_GraphNode::Find
+Standard_Boolean XCAFDoc_GraphNode::Find(const TDF_Label& L,
+Handle(XCAFDoc_GraphNode)& G)
+Purpose: Shortcut to search a Graph node attribute with a default GraphID. Returns true if found.
+ * XCAFDoc_GraphNode::GetDefaultGraphID
+const Standard_GUID& XCAFDoc_GraphNode::GetDefaultGraphID()
+Purpose: Returns a default Graph ID. This ID is used by the Set method without an explicit tree ID.
+ * XCAFDoc_GraphNode::Set
+Handle(XCAFDoc_GraphNode) XCAFDoc_GraphNode::Set(const TDF_Label& L)
+Purpose: Finds or Creates a GraphNode attribute on the label L with a default Graph ID, returned by the method GetDefaultGraphID(). Returns the created/found GraphNode attribute.
+Handle(XCAFDoc_GraphNode) XCAFDoc_GraphNode::Set (const TDF_Label& L,
+const Standard_GUID& explicitID)
+Purpose: Finds or Creates a GraphNode attribute on the label L, with an explicit tree ID. ExplicitGraphID is the ID returned by the TDF_Attribute::ID() method. Returns the found/created GraphNode attribute.
+<h4>Instance methods</h4>
+ * XCAFDoc_GraphNode::SetFather
+Standard_Integer XCAFDoc_GraphNode::SetFather(
+const Handle(XCAFDoc_GraphNode)& F)
+Purpose: Sets GraphNode F as the father of this attribute and returns an index of F in a sequence containing Father GraphNodes. Returns an index of F from GraphNodeSequnece.
+ * XCAFDoc_GraphNode::SetChild
+Standard_Integer XCAFDoc_GraphNode::SetChild(
+const Handle(XCAFDoc_GraphNode)& Ch)
+Purpose: Sets GraphNode Ch as a child of this attribute and returns an index of Ch in a sequence containing Children GraphNodes. Returns an index of Ch from GraphNodeSequnece.
+ * XCAFDoc_GraphNode::UnSetFather
+void XCAFDoc_GraphNode::UnSetFather(const Handle(XCAFDoc_GraphNode)& F)
+Purpose: Removes F from Fathers GraphNodeSequence and removes the link between the father and the child.
+void XCAFDoc_GraphNode::UnSetFather(const Standard_Integer Findex)
+Purpose: Removes Father GraphNode by index from Fathers GraphNodeSequence and removes the link between the father and the child.
+ * XCAFDoc_GraphNode::UnSetFatherlink
+void XCAFDoc_GraphNode::UnSetFatherlink(
+const Handle(XCAFDoc_GraphNode)& F)
+Purpose: Removes the link between the father and the child.
+ * XCAFDoc_GraphNode::UnSetChild
+void XCAFDoc_GraphNode::UnSetChild(const Handle(XCAFDoc_GraphNode)& Ch)
+Purpose: Removes Ch from GraphNodeSequence and removes the link between the father and the child.
+void XCAFDoc_GraphNode::UnSetChild(const Standard_Integer Chindex)
+Purpose: Removes Child GraphNode by index from Children GraphNodeSequence and removes the link between the father and the child.
+ * XCAFDoc_GraphNode::UnSetChildlink
+void XCAFDoc_GraphNode::UnSetChildlink(
+const Handle(XCAFDoc_GraphNode)& Ch)
+Purpose: Removes the link between the father and the child.
+ * XCAFDoc_GraphNode::GetFather
+Handle(XCAFDoc_GraphNode) XCAFDoc_GraphNode::GetFather(
+const Standard_Integer Findex) const
+Purpose: Returns GraphNode by index from GraphNodeSequence.
+ * XCAFDoc_GraphNode::GetChild
+Handle(XCAFDoc_GraphNode) XCAFDoc_GraphNode::GetChild(
+const Standard_Integer Chindex) const
+Purpose: Returns GraphNode by index from GraphNodeSequence.
+ * XCAFDoc_GraphNode::FatherIndex
+Standard_Integer XCAFDoc_GraphNode::FatherIndex(
+const Handle(XCAFDoc_GraphNode)& F) const
+Purpose: Returns the index of F, or zero if there is no such Graphnode.
+ * XCAFDoc_GraphNode::ChildIndex
+Standard_Integer XCAFDoc_GraphNode::ChildIndex(
+const Handle(XCAFDoc_GraphNode)& Ch) const
+Purpose: Returns the index of Ch, or zero if there is no such Graphnode.
+ * XCAFDoc_GraphNode::IsFather
+Standard_Boolean XCAFDoc_GraphNode::IsFather(
+const Handle(XCAFDoc_GraphNode)& Ch) const
+Purpose: Returns True if this attribute is the father of Ch.
+ * XCAFDoc_GraphNode::IsChild
+Standard_Boolean XCAFDoc_GraphNode::IsChild(
+const Handle(XCAFDoc_GraphNode)& F) const
+Purpose: Returns True if this attribute is a child of F.
+ * XCAFDoc_GraphNode::NbFathers
+Standard_Integer XCAFDoc_GraphNode::NbFathers() const
+Purpose: Returns the Number of Father GraphNodes.
+ * XCAFDoc_GraphNode::NbChildren
+Standard_Integer XCAFDoc_GraphNode::NbChildren() const
+Purpose: Returns the Number of Children GraphNodes.
+@subsection occt_1819379545_68542510413 Package methods
+Purpose: Definition of GUIDs
+<h4>Methods:</h4>
+ * XCAFDoc::AssemblyGUID
+Standard_GUID XCAFDoc::AssemblyGUID ()
+Purpose: Returns a GUID for UAttribute identifying the assembly
+ * XCAFDoc::ShapeRefGUID
+Standard_GUID XCAFDoc::ShapeRefGUID ()
+Purpose: Returns a GUID for TreeNode representing an assembly link.
+ * XCAFDoc::ColorRefGUID
+Standard_GUID XCAFDoc::ColorRefGUID (const XCAFDoc_ColorType type)
+Purpose: Returns a GUID for TreeNode representing specified types of colors.
+ * XCAFDoc::LayerRefGUID
+Standard_GUID XCAFDoc::LayerRefGUID ()
+Purpose: Returns a GUID from Standard.
+ * XCAFDoc::InvisibleGUID
+Standard_GUID XCAFDoc::InvisibleGUID ()
+Purpose: Returns a GUID from Standard;
+ * XCAFDoc::ExternRefGUID
+Standard_GUID XCAFDoc::ExternRefGUID ()
+Purpose: Returns a GUID for UAttribute identifying an external reference.
--- /dev/null
+@echo off
+
+rem Helper script to run generation of OCCT documentation on Windows.
+rem Running it requires that Tcl, Doxygen, and MikTex (for PDF generation)
+rem should be in the PATH
+
+if exist "%~dp0env.bat" (
+ call "%~dp0env.bat"
+)
+
+if not ["%1"] == ["-h"] (
+ tclsh85.exe %~dp0dox/start.tcl %*
+) else (
+ echo.
+ echo gen.bat options:
+ echo -html : To generate HTML files ^(cannot be used with -pdf^)
+ echo -pdf : To generate PDF files ^(cannot be used with -html^)
+ echo -m^=^<modules_list^> : Specifies list of articles to generate. If it is not specified, all files, mentioned in FILES.txt are processed
+ echo "-l=<document_name> : Specifies the article caption for a single document"
+ echo -h : Prints help message
+ echo -v : Specifies the Verbose mode ^(info on all script actions is shown^)
+ echo.
+)
projects / occt-copy.git / commitdiff
