0024336: Content of OCCT documentation should be updated. Iter 2
authorysn <ysn@opencascade.com>
Thu, 21 Nov 2013 09:04:37 +0000 (13:04 +0400)
committerbugmaster <bugmaster@opencascade.com>
Thu, 21 Nov 2013 09:27:41 +0000 (13:27 +0400)
CDL guide finalized.
Brep WP added
Added white-papers and 2 dev guides in the generated documentation structure.
White-papers + 2 developer guides + Draw UG finalized.
Visualization guide finalized.
Fixes for bugs 24205, 23737 and 24021

527 files changed:
dox/FILES.txt
dox/dev_guides/cdl/cdl.md
dox/dev_guides/contribution_workflow/contribution_workflow.md [new file with mode: 0644]
dox/dev_guides/contribution_workflow/images/OCCT_ContributionWorkflow_V3_image001.png [new file with mode: 0644]
dox/dev_guides/contribution_workflow/images/OCCT_ContributionWorkflow_V3_image002.jpg [new file with mode: 0644]
dox/dev_guides/dev_guides.md
dox/dev_guides/git_guide/git_guide.md [new file with mode: 0644]
dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image001.png [new file with mode: 0644]
dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image002.png [new file with mode: 0644]
dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image003.png [new file with mode: 0644]
dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image004.png [new file with mode: 0644]
dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image005.png [new file with mode: 0644]
dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image006.png [new file with mode: 0644]
dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image007.png [new file with mode: 0644]
dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image008.png [new file with mode: 0644]
dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image009.png [new file with mode: 0644]
dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image010.png [new file with mode: 0644]
dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image011.png [new file with mode: 0644]
dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image012.png [new file with mode: 0644]
dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image013.png [new file with mode: 0644]
dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image014.png [new file with mode: 0644]
dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image015.png [new file with mode: 0644]
dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image016.png [new file with mode: 0644]
dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image017.png [new file with mode: 0644]
dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image018.png [new file with mode: 0644]
dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image019.png [new file with mode: 0644]
dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image020.png [new file with mode: 0644]
dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image021.png [new file with mode: 0644]
dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image022.png [new file with mode: 0644]
dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image023.png [new file with mode: 0644]
dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image024.png [new file with mode: 0644]
dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image025.png [new file with mode: 0644]
dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image026.png [new file with mode: 0644]
dox/overview/Overview.md
dox/user_guides/brep_wp/brep_wp.md [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image003.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image004.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image005.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image006.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image007.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image008.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image009.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image010.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image011.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image012.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image013.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image014.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image015.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image016.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image017.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image018.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image019.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image020.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image021.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image022.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image023.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image024.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image025.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image026.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image027.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image028.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image029.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image030.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image031.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image032.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image033.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image034.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image035.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image036.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image037.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image038.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image039.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image040.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image041.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image042.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image043.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image044.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image045.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image046.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image047.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image048.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image049.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image050.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image051.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image052.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image053.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image054.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image055.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image056.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image057.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image058.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image059.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image060.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image061.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image062.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image063.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image064.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image065.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image066.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image067.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image068.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image069.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image070.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image071.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image072.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image073.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image074.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image075.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image076.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image077.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image078.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image079.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image080.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image081.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image082.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image083.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image084.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image085.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image086.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image087.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image088.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image089.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image090.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image091.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image092.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image093.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image094.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image095.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image096.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image097.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image098.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image099.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image100.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image101.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image102.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image103.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image104.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image105.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image106.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image107.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image108.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image109.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image110.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image111.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image112.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image113.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image114.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image115.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image116.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image117.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image118.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image119.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image120.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image121.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image122.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image123.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image124.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image125.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image126.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image127.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image128.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image129.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image130.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image131.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image132.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image133.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image134.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image135.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image136.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image137.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image138.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image139.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image140.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image141.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image142.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image143.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image144.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image145.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image146.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image147.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image148.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image149.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image150.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image151.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image152.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image153.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image154.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image155.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image156.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image157.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image158.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image159.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image160.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image161.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image162.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image163.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image164.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image165.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image166.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image167.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image168.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image169.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image170.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image171.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image172.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image173.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image174.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image175.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image176.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image177.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image178.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image179.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image180.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image181.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image182.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image183.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image184.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image185.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image186.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image187.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image188.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image189.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image190.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image191.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image192.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image193.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image194.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image195.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image196.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image197.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image198.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image199.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image200.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image201.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image202.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image203.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image204.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image205.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image206.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image207.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image208.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image209.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image210.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image211.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image212.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image213.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image214.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image215.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image216.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image217.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image218.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image219.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image220.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image221.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image222.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image223.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image224.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image225.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image226.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image227.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image228.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image229.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image230.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image231.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image232.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image233.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image234.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image235.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image236.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image237.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image238.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image239.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image240.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image241.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image242.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image243.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image244.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image245.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image246.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image247.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image248.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image249.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image250.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image251.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image252.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image253.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image254.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image255.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image256.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image257.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image258.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image259.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image260.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image261.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image262.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image263.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image264.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image265.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image266.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image267.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image268.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image269.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image270.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image271.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image272.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image273.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image274.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image275.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image276.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image277.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image278.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image279.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image280.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image281.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image282.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image283.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image284.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image285.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image286.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image287.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image288.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image289.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image290.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image291.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image292.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image293.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image294.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image295.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image296.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image297.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image298.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image299.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image300.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image301.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image302.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image303.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image304.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image305.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image306.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image307.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image308.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image309.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image310.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image311.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image312.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image313.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image314.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image315.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image316.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image317.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image318.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image319.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image320.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image321.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image322.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image323.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image324.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image325.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image326.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image327.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image328.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image329.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image330.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image331.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image332.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image333.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image334.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image335.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image336.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image337.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image338.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image339.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image340.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image341.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image342.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image343.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image344.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image345.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image346.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image347.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image348.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image349.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image350.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image351.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image352.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image353.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image354.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image355.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image356.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image357.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image358.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image359.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image360.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image361.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image362.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image363.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image364.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image365.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image366.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image367.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image368.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image369.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image370.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image371.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image372.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image373.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image374.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image375.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image376.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image377.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image378.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image379.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image380.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image381.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image382.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image383.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image384.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image385.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image386.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image387.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image388.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image389.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image390.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image391.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image392.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image393.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image394.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image395.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image396.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image397.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image398.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image399.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image400.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image401.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image402.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image403.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image404.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image405.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image406.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image407.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image408.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image409.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image410.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image411.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image412.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image413.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image414.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image415.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image416.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image417.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image418.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image419.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image420.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image421.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image422.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image423.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image424.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image425.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image426.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image427.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image428.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image429.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image430.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image431.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image432.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image433.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image434.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image435.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image436.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image437.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image438.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image439.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image440.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image441.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image442.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image443.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image444.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image445.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image446.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image447.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image448.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image449.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image450.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image451.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image452.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image453.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image454.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image455.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image456.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image457.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image458.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image459.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image460.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image461.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image462.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image463.gif [new file with mode: 0644]
dox/user_guides/brep_wp/images/brep_wp_image464.gif [new file with mode: 0644]
dox/user_guides/draw_test_harness.md
dox/user_guides/iges/iges.md
dox/user_guides/ocaf_functionmechanism_wp/images/ocaf_functionmechanism_wp_image003.png [new file with mode: 0644]
dox/user_guides/ocaf_functionmechanism_wp/images/ocaf_functionmechanism_wp_image005.png [new file with mode: 0644]
dox/user_guides/ocaf_functionmechanism_wp/ocaf_functionmechanism_wp.md [new file with mode: 0644]
dox/user_guides/ocaf_tree_wp/images/ocaf_tree_wp_image003.png [new file with mode: 0644]
dox/user_guides/ocaf_tree_wp/images/ocaf_tree_wp_image004.png [new file with mode: 0644]
dox/user_guides/ocaf_tree_wp/images/ocaf_tree_wp_image005.png [new file with mode: 0644]
dox/user_guides/ocaf_tree_wp/images/ocaf_tree_wp_image006.png [new file with mode: 0644]
dox/user_guides/ocaf_tree_wp/ocaf_tree_wp.md [new file with mode: 0644]
dox/user_guides/ocaf_wp/images/ocaf_wp_image003.png [new file with mode: 0644]
dox/user_guides/ocaf_wp/images/ocaf_wp_image004.png [new file with mode: 0644]
dox/user_guides/ocaf_wp/images/ocaf_wp_image005.png [new file with mode: 0644]
dox/user_guides/ocaf_wp/images/ocaf_wp_image006.png [new file with mode: 0644]
dox/user_guides/ocaf_wp/ocaf_wp.md [new file with mode: 0644]
dox/user_guides/step/step.md
dox/user_guides/user_guides.md
dox/user_guides/visualization/images/visualization_image003.png
dox/user_guides/visualization/images/visualization_image004.png
dox/user_guides/visualization/images/visualization_image023.png
dox/user_guides/visualization/visualization.md
dox/user_guides/voxels_wp/images/voxels_wp_image003.jpg [new file with mode: 0644]
dox/user_guides/voxels_wp/images/voxels_wp_image004.jpg [new file with mode: 0644]
dox/user_guides/voxels_wp/images/voxels_wp_image005.jpg [new file with mode: 0644]
dox/user_guides/voxels_wp/images/voxels_wp_image006.jpg [new file with mode: 0644]
dox/user_guides/voxels_wp/images/voxels_wp_image007.jpg [new file with mode: 0644]
dox/user_guides/voxels_wp/images/voxels_wp_image008.jpg [new file with mode: 0644]
dox/user_guides/voxels_wp/images/voxels_wp_image009.jpg [new file with mode: 0644]
dox/user_guides/voxels_wp/images/voxels_wp_image010.jpg [new file with mode: 0644]
dox/user_guides/voxels_wp/voxels_wp.md [new file with mode: 0644]

index 50d4b47..77dd56c 100644 (file)
@@ -21,6 +21,11 @@ user_guides/ocaf/ocaf.md
 user_guides/tobj/tobj.md
 user_guides/shape_healing/shape_healing.md
 user_guides/draw_test_harness.md
+user_guides/brep_wp/brep_wp.md
+user_guides/ocaf_functionmechanism_wp/ocaf_functionmechanism_wp.md
+user_guides/ocaf_tree_wp/ocaf_tree_wp.md
+user_guides/ocaf_wp/ocaf_wp.md
+user_guides/voxels_wp/voxels_wp.md
 
 dev_guides/dev_guides.md
 dev_guides/contribution/coding_rules.md
@@ -28,6 +33,9 @@ dev_guides/cdl/cdl.md
 dev_guides/tests/tests.md
 dev_guides/documentation/documentation.md
 dev_guides/wok/wok.md
+dev_guides/contribution_workflow/contribution_workflow.md
+dev_guides/git_guide/git_guide.md
+
 
 dev_guides/building/building.md
 dev_guides/building/3rdparty/3rdparty_windows.md
index 327170b..a54a4be 100644 (file)
@@ -7,7 +7,7 @@
 
 Please note that CDL is considered as obsolete and is to be removed in one of future releases of OCCT.
 
-@section occt_1819379591_354121062 CDL and Application Architecture
+@section occt_cdl_1 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: 
 
@@ -16,71 +16,61 @@ CDL is the component  definition language of the Open CASCADE Technology (**OCCT
   * 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. 
+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. 
 
 
-    @image html /dev_guides/cdl/images/cdl_image003.png
-    @image latex /dev_guides/cdl/images/cdl_image003.png
-     
-Figure 1. Building  an Open CASCADE Technology application 
-@section occt_1819379591_986437237 2. Introduction to  CDL
-@subsection occt_1819379591_98643723721  Purposes of the Language
+@image html /dev_guides/cdl/images/cdl_image003.png "Building  an Open CASCADE Technology application" 
+@image latex /dev_guides/cdl/images/cdl_image003.png "Building  an Open CASCADE Technology application" 
+    
+@section occt_cdl_2 Introduction to  CDL
+@subsection occt_cdl_2_1  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. 
 
-    @image html /dev_guides/cdl/images/cdl_image004.png
-    @image latex /dev_guides/cdl/images/cdl_image004.png     
+@image html /dev_guides/cdl/images/cdl_image004.png "The Development Process" 
+@image latex /dev_guides/cdl/images/cdl_image004.png "The Development Process" 
 
-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. 
+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++). 
+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
+  
+@subsection occt_cdl_2_2   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
+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. 
 
-A class is an  implementation of a **data type**. It defines its **behavior **and its **representation**. 
+@subsubsection occt_cdl_2_2_1    Classes
 
-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. 
+A class is an  implementation of a **data type**. It defines its **behavior** and its **representation**. 
 
-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 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
 
@@ -89,53 +79,59 @@ 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: 
+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: 
+
+@subsubsection occt_cdl_2_2_2     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
   
-    @image html /dev_guides/cdl/images/cdl_image005.png
-    @image latex /dev_guides/cdl/images/cdl_image005.png      
-
-Figure 3. Manipulation of data types 
-
+    @image html /dev_guides/cdl/images/cdl_image005.png "Manipulation of data types" 
+    @image latex /dev_guides/cdl/images/cdl_image005.png  "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 ... 
+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: 
 
+~~~~~
+Handle(myClass) m = new myClass;
+~~~~~
 
 
-@subsubsection occt_1819379591_986437237223     Persistence
+@subsubsection occt_cdl_2_2_3     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. 
+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. 
+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. 
+Note that the classes  inheriting from the *Persistent* class are handled by reference. 
 
 **Example** 
+~~~~~
+class Watch inherits Persistent
+~~~~~
 
-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. 
+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** 
 
+**Example** 
+~~~~~
 If 
 class WatchSpring  inherits Storable 
 //then this could be  stored as a field of a Watch 
@@ -146,31 +142,33 @@ fields
 name :  ConstructorName; 
 powersource :  WatchSpring; 
 end; 
+~~~~~
 
+@subsubsection occt_cdl_2_2_4    Packages
 
-@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. 
 
-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. 
 
-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
+@subsubsection occt_cdl_2_2_5     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.. 
+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. 
+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** 
 
+**Example** 
+~~~~~
 deferred class BankAccount inherits Persistent 
 is 
 ....... 
@@ -178,36 +176,40 @@ fields
 name :  AccountHolderName; 
 balance : CreditBalance; 
 end; 
+~~~~~
 
-
-@subsubsection occt_1819379591_986437237226     Genericity
+@subsubsection occt_cdl_2_2_6     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. 
+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
+@subsubsection occt_cdl_2_2_7     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
+
+@subsubsection occt_cdl_2_2_8     Completeness
 
 You use CDL to define  data types. Such definitions are not considered complete unless they contain  the required amount of structured commentary. 
 
@@ -216,67 +218,63 @@ The compiler does not  enforce this required degree of completeness, so it is th
 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
+@subsection occt_cdl_2_3   Lexical Conventions
+@subsubsection occt_cdl_2_3_1    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} 
-
+  * 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** 
-
+~~~~~
+passing-method ::=  <b>[in] | out | in out </b> 
+~~~~~
   * 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. 
+~~~~~
+**NOTE** To introduce the 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
+@subsubsection occt_cdl_2_3_2    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
+@subsubsection occt_cdl_2_3_3     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. 
+**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. 
+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. 
 
-**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.  
 
@@ -291,33 +289,64 @@ These rubrics can be  attached to:
   * Executables
   * Clients
 
-@subsubsection occt_1819379591_986437237234     Identifiers
+@subsubsection occt_cdl_2_3_4     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
+@subsubsection occt_cdl_2_3_5     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 
+* 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
+@subsubsection occt_cdl_2_3_6     Constants
 
 There are three  categories of constants: 
 
@@ -325,123 +354,131 @@ There are three  categories of constants:
   * Literal
   * Named
 
-***Numeric Constants*** 
+#### 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 
+An **integer** constant  consists of a string of digits, which may or may not be preceded by a sign.  Integer constants express whole numbers. 
 
-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** 
+~~~~~
+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
 
 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** 
+An **individual  character** constant is a single printable character enclosed by two  apostrophes. (See the definition of the class Character in the Standard  Package). 
 
+**Examples** 
+~~~~~
  ‘B’       ‘y’      ‘&amp;’      ‘*’      ‘’’ ‘‘ 
+~~~~~
+A **string** constant  is composed of printable characters enclosed by quotation marks. 
 
-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. 
 
-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
 
 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
+**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_cdl_3 Software  Components
 
-@subsection occt_1819379591_171843530931   Predefined Resources
-@subsubsection occt_1819379591_1718435309311     Primitive types
+@subsection occt_cdl_3_1   Predefined Resources
+@subsubsection occt_cdl_3_1_1     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: 
+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. 
+* **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. 
+* **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)
+@subsubsection occt_cdl_3_1_2     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.
+  * 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. 
 
-@image html /dev_guides/cdl/images/cdl_image006.png
-@image latex /dev_guides/cdl/images/cdl_image006.png
+@image html /dev_guides/cdl/images/cdl_image006.png "Manipulation of a data type by reference"
+@image latex /dev_guides/cdl/images/cdl_image006.png "Manipulation of a data type by reference"
 
-Figure 4. Manipulation of a data type by reference 
 
-
-@subsubsection occt_1819379591_1718435309313     Manipulating types by value
+@subsubsection occt_cdl_3_1_3     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. 
 
-    @image html /dev_guides/cdl/images/cdl_image007.png
-    @image latex /dev_guides/cdl/images/cdl_image007.png
-      
-Figure 5. Manipulation of a data type by value 
+@image html /dev_guides/cdl/images/cdl_image007.png "Manipulation of a data type by value" 
+@image latex /dev_guides/cdl/images/cdl_image007.png "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
+@subsubsection occt_cdl_3_1_4   Summary  of properties
 
-**Figure 6. Summary of the relationship for the  various data** 
-**types between how they are handled and their  storability.** 
 
+Here is a summary of how various data types are handled and their  storability:
+| | Manipulated by handle | Manipulated by value |
+| :---- | :---- | :---- |
+| storable | Persistent | Primitive, Storable (storable if nested in a persistent class) |
+| temporary | Transient | Other | 
 
-@subsection occt_1819379591_171843530932   Classes
 
-@subsubsection occt_1819379591_1718435309321    Class  declaration
+
+
+@subsection occt_cdl_3_2   Classes
+
+@subsubsection occt_cdl_3_2_1    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 } ] 
@@ -456,14 +493,15 @@ 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. 
+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** 
+**Exceptions** are declared after the word **raises**. 
 
+**Example** 
+~~~~~
 class Line from  GeomPack 
 usesPoint,  Direction, Transformation 
 raisesNullDirection,  IdenticalPoints 
@@ -473,180 +511,165 @@ is-- class  definition follows here
 -- 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.
 
-    @image html /dev_guides/cdl/images/cdl_image009.png
-    @image latex /dev_guides/cdl/images/cdl_image009.png
-    
-**Figure 7. Contents of a class** 
-*** a deferred class does not have to contain a  constructor** 
-
+    @image html /dev_guides/cdl/images/cdl_image009.png "Contents of a class"
+    @image latex /dev_guides/cdl/images/cdl_image009.png "Contents of a class"
 
-@subsubsection occt_1819379591_1718435309322     Categories of classes
+@subsubsection occt_cdl_3_2_2     Categories of classes
 
 Classes fall into three categories: 
-
   * Ordinary classes
   * Deferred classes
   * Generic classes
 
-<h4>Deferred classes</h4>
+#### Deferred classes
 
-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** 
+The principal  characteristic of a **deferred class** is that you cannot instantiate it.  Its purpose is to provide a given behavior shared by a hierarchy of  classes and dependent on the implementation of the descendents. This allows guaranteeing 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: 
 
--- declaration-of-a-deferred-class ::= 
-deferred class  class-name 
+~~~~~
+-- 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]’;’ 
-
+       is class-definition 
+       end [class-name]’;’ 
+~~~~~
+Please, note that a deferred class does not have to contain a  constructor
 
 <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** 
+The principal  characteristic of a **generic class** is that it offers a set of  functional behavior 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: 
 
--- declaration-of-a-generic-class ::= 
-[deferred] generic  class class-name ’(’generic-type 
-{’,’ generic-type}’)’ 
+~~~~~
+-- 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]’;’ 
+       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}’)’] 
+type-constraint ::= any | class-name [’(’data-type {’,’ data-type}’)’] 
+~~~~~
 
 
+@subsection occt_cdl_3_3   Packages
 
-@subsection occt_1819379591_171843530933   Packages
+@subsubsection occt_cdl_3_3_1    Package  declaration
 
-@subsubsection occt_1819379591_1718435309331    Package  declaration
+**Packages** are  used to group   classes, which have some logical coherence. For example, the  Standard Package groups together all the predefined resources of the language.  In its simplest form, a package contains the declaration of all data types,  which it introduces. You may also use a package to offer public methods and  hide its internal classes by declaring them private. 
 
- **Packages** are  used to group   classes, which have some logical coherence. For example, the  Standard Package groups together all the predefined resources of the language.  In its simplest form, a package contains the declaration of all data types,  which it introduces. You may also use a package to offer public methods and  hide its internal classes by declaring them private. 
-**    ** 
 **Example** 
 
--- package-declaration ::= 
-**package **package-name 
-[**uses **package-name {’,’ package-name}] 
-**is **package-definition 
-**end **[package-name]’;’ 
--- package-name ::= 
-identifier 
+~~~~~
+-- 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}] 
+       [{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] 
+       [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: 
+[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. 
+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. 
+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. 
+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**. 
+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**. 
 
-@image html /dev_guides/cdl/images/cdl_image010.png
-@image latex /dev_guides/cdl/images/cdl_image010.png
-Figure 8. Contents of a package 
+@image html /dev_guides/cdl/images/cdl_image010.png "Contents of a package" 
+@image latex /dev_guides/cdl/images/cdl_image010.png "Contents of a package" 
 
-The example of the  package below includes some of the basic data structures: 
-**Example** 
 
+The example of the package below includes some of the basic data structures: 
+
+~~~~~
 package Collection 
-uses 
-Standard 
-is 
+       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**. 
+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
+@subsubsection occt_cdl_3_3_2    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. 
+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** 
+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**.
 
--- class-name ::= 
-identifier [**from **package-name] 
--- exception-name ::= 
-identifier [**from **package-name] 
--- enumeration-name ::= 
-identifier [**from **package-name] 
+~~~~~
+-- 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** 
+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: 
 
+~~~~~
 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.*** 
+**Note** that 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 
+       Point from Geom2d, 
+       Point from Geom3d 
 is 
--- class definition  using 
--- Point from  AppropriatePackage 
--- wherever Point  appears 
+       -- class definition  using Point from AppropriatePackage wherever Point  appears 
 end; 
+~~~~~
 
-
-@subsubsection occt_1819379591_1718435309333     Declaration of classes
+@subsubsection occt_cdl_3_3_3     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. 
+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 
+       uses 
+       Standard 
+       is 
 exception  NoMoreObject inherits Failure from Standard; 
 exception NoSuchObject inherits Failure from Standard; 
 generic class SingleList; 
@@ -655,251 +678,264 @@ 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; 
+       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.... 
+       inherits 
+               Persistent from Standard; 
+       raises 
+               NoSuchObject from Collection, 
+               NoMoreObject from  Collection 
+               private class Node  instantiates SingleList 
+               from Collection  (Item); 
  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. 
+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: 
 
-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** 
 
+**Example** 
+~~~~~
 package Collection 
-uses 
-Standard 
-is 
+       uses 
+       Standard 
+       is 
 generic class Set,  Node, Iterator; 
 private generic class SingleList; 
 exception NoMoreObject inherits Failure from Standard; 
 end Collection; 
+~~~~~
 
 
 
+@subsection occt_cdl_3_4   Other Data Types
 
-@subsection occt_1819379591_171843530934   Other Data Types
-
-These are: 
-
+The other data types are: 
   * Enumerations
   * Imports
   * Aliases
   * Exceptions
   * Pointers
 
-@subsubsection occt_1819379591_1718435309341     Enumerations
+@subsubsection occt_cdl_3_4_1     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** 
+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 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** 
 
+**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. 
+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 
+       Honda, 
+       Ford, 
+       Volkswagen, 
+       Renault 
 end; 
 enumeration AmericanPresidents is 
-Nixon, 
-Reagan, 
-Ford, -- Error: ‘Ford’ already defined 
-Carter 
+       Nixon, 
+       Reagan, 
+       Ford, -- Error: ‘Ford’ already defined 
+       Carter 
 end; 
+~~~~~
 
+@subsubsection occt_cdl_3_4_2    Imports
 
-@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. 
+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: 
+~~~~~
+declaration-of-an-imported-type::=[private] imported  typename ; 
+~~~~~
+
+Let us try to define an imported type:
+
+* In the *MyPack.cdl* file, you declare the imported type:
+~~~~~ 
+package MyPack 
+       .... 
+       imported MyImport; 
+       .... 
+       end Mypack; 
+~~~~~  
+* In the *MyPack_MyImport.hxx* file, you write the following C++ code: 
+~~~~~
 #ifndef _MyPack_MyImport_HeaderFile 
 #define _MyPack_MyImport_HeaderFile 
 #include Standard_Type.hxx 
 typedef unsigned long MyPack_MyImport; 
 extern const Handle(Standard_Type)&amp; TYPE 
 (MyPack_MyImport); 
--- In the MyPack_MyImport.cxx file, you write the 
-following 
--- C++ code: 
+~~~~~
+* In the *MyPack_MyImport.cxx* file, you write the following C++ code: 
+~~~~~
 #ifndef _MyPack_MyImport_HeaderFile 
 #include MyPack_MyImport.hxx 
 #endif 
 const Handle(Standard_Type)&amp; TYPE (MyPack_MyImport) 
-
 { 
-static Handle(Standard_Type) _aType = 
-new Standard_Type  (“MyPack_MyImport”,sizeof 
-(MyPack_MyImport)) 
- return _aType; 
-} 
+       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. 
+Then, add the names of  these two files <i>(MyPack_MyImport.hxx, MyPack_MyImport.cxx)</i> 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
+@subsubsection occt_cdl_3_4_3    Aliases
 
-An **alias **is an  extra name for a type, which is already known. It is declared as in the  following syntax: 
+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** 
+~~~~~
+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. 
+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
+@subsubsection occt_cdl_3_4_4     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 
+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: 
+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. 
+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="#occt_cdl_4">“Defining the Software Components”</a>  on page 32. 
 
 
-@subsection occt_1819379591_171843530935   Schemas
+@subsection occt_cdl_3_5   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. 
+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 
+schema SchemaName 
 is 
-{**package **PackageName;} 
-{**class **ClassName;} 
-**end**; 
-**Example** 
-
+{package PackageName;} 
+{class ClassName;} 
+end;
+~~~~~
+For 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** 
+**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_cdl_3_6   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 ExecutableName 
+       is 
 { 
 executable ExecutablePart 
-[uses  [Identifier as external] 
-[{’,’  Identifier as external}] 
-[UnitName as  library] 
-[{’,’  UnitName as library}] 
-is 
-{FileName  [as C++|c|fortran|object];} 
+       [uses  [Identifier as external] 
+       [{’,’  Identifier as external}] 
+       [UnitName as  library] 
+       [{’,’  UnitName as library}] 
+       is 
+       {FileName  [as C++|c|fortran|object];} 
+       end; 
+       } 
 end; 
-} 
-end; 
-**Example** 
+~~~~~
 
+**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; 
+       ---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
+@section occt_cdl_4 Defining the Software Components
 
-@subsection occt_1819379591_197231010841   Behavior
+@subsection occt_cdl_4_1   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: 
+The behavior of an  object class is defined by a list of **methods**, which are either **functions** or **procedures**. Functions return an object, whereas procedures only  communicate by passing arguments. In both cases, when the transmitted object is  an instance manipulated by a handle, its identifier is passed. There are three  categories of methods: 
 
-**Object constructor            **Creates an instance of the described class. A  class will have one or more object constructors with various arguments or none. 
+* **Object constructor** Creates an instance of the described class. A  class will have one or more object constructors with various arguments or none. 
+* **Instance method** Operates on the instance which owns it. 
+* **Class method** Does not work on individual instances, only on the class itself. 
 
-**Instance method               **Operates on the instance which owns it. 
+@subsubsection occt_cdl_4_11    Object  Constructors
 
-**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** 
+A constructor is a  function, which allows the **creation of instances** of the class it  describes. 
 
+~~~~~
 constructor-declaration ::= 
-Create [ simple-formal-part ] declaration-ofconstructed- 
-type 
+Create [ simple-formal-part ] declaration-ofconstructed-type 
 [ exception-declarations ] 
 simple-formal-part ::= 
 ’(’  initialization-parameter {’;’ initialization parameter}’)’ 
@@ -907,86 +943,84 @@ initialization-parameter ::=
 identifier {’,’ identifier} ’:’ parameter-access  datatype 
 [ ’=’ initial-value ] 
 parameter-access ::= 
-**mutable **| [ **immutable **] 
+mutable | [ immutable ] 
 initial_value ::= 
 numeric-constant | literal-constant | named-constant 
 declaration-of-constructed-type ::= 
-**returns **[ **mutable **] class-name 
+returns [ mutable ] class-name 
+~~~~~
 
-The name of the  constructors is fixed: “Create”. The object returned by a constructor  is  always of the type of the described class. If that type is manipulated by a  handle, you *must *declare it as **mutable**, in which case the content  of the instance it references is accessible for further modification. 
+The name of the  constructors is fixed: “Create”. The object returned by a constructor is  always of the type of the described class. If that type is manipulated by a  handle, you *must* declare it as **mutable**, in which case the content  of the instance it references is accessible for further modification. 
 
 For example, the  constructor of the class “Point” 
-**Example** 
-
+~~~~~
 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. 
+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** 
+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**. Let, for example, take the constructor of the  persistent class “Line”. 
 
+~~~~~
 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** 
+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. Let, for example, take the constructor of the  persistent class “Vector”. 
 
+~~~~~
 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. 
+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
+
+@subsubsection occt_cdl_4_1_2     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 
+**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 
+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 
+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: 
+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. 
+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. 
+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. 
+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 
 
@@ -999,90 +1033,91 @@ SetCoord (me : mutable; X, Y, Z : Real);
 
 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. 
+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
+@subsubsection occt_cdl_4_1_3    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-a-class-method ::= identifier formal-part-of-class-method 
 [ declaration-of-returned-type ] 
 [ exception-declaration ] 
-formal-part-of-class-method ::= 
-’(’ **myclass **{’;’ parameter}’)’ 
+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. 
 
-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
+@subsubsection occt_cdl_4_1_4    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] 
+~~~~~
+package-method ::= identifier  [simple-formal-part][returned-type-declaration] 
 [exception-declaration] 
-[**is private**]’;’ 
-
+[is private]’;’ 
+~~~~~
 
-@subsubsection occt_1819379591_1972310108415     Sensitivity to Overloading
+@subsubsection occt_cdl_4_1_5     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: 
+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**) 
+  * 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
+  
+@subsection occt_cdl_4_2   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** 
+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. 
 
-declaration-of-the-internal-representation-of-a-class 
-::= 
-**fields **field {field} 
-field ::= 
-identifier {’,’ identifier} ’:’ data-type [’[’integer 
-{’,’integer}’]’]’;’ 
+**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. 
+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** 
 
+**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
+@subsection occt_cdl_4_3   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. 
+~~~~~
+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) 
@@ -1091,112 +1126,117 @@ Coord (me; i : Integer) returns Real
 -- 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. 
+Instance methods are  likely to raise certain exceptions called **systematic exceptions** which do  not have to appear. They are: 
 
-**TypeMismatch                              **Raised if an argument typed by association is of  an unsuitable type. 
+* *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
+@subsection occt_cdl_4_4   Inheritance
 
-@subsubsection occt_1819379591_1972310108441     Overview
+@subsubsection occt_cdl_4_4_1     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. 
+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  hyperbolas. 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**. 
+**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]’;’ 
+~~~~~
 
-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. 
+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**. 
 
-NOTE 
-Note that constructors and class methods are never  inherited. 
+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** that constructors and class methods are never  inherited. 
 
-@subsubsection occt_1819379591_1972310108442     Redefining methods
+@subsubsection occt_cdl_4_4_2     Redefining methods
 
 Certain inherited  methods can be redefined. 
+
 **Example** 
 
-declaration-of-a-redefined-method ::= 
-identifier formal-part-of-instance-method [returnedtype- 
-declaration] 
+~~~~~
+declaration-of-a-redefined-method ::= identifier formal-part-of-instance-method [returnedtype- declaration] 
 [declaration-of-exceptions] 
-**  is redefined **[visibility]’;’ 
+is redefined [visibility]’;’ 
+~~~~~
 
 A redefined method must conform  to the syntax described in the super-class where it appears. The exceptions  contained in the super-class can be renewed, and others may be added as long as  they inherit from an ancestor class. 
 
-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** 
+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="#occt_cdl_4_6"> Visibility </a> section. 
+
 
+**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
+@subsubsection occt_cdl_4_4_3 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. 
+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-a-non-redefinable-method ::= identifier formal-part-of-instance-method [returnedtype- declaration] 
 [declaration-of-exceptions] 
-** is virtual **[visibility]’;’ 
+ is virtual [visibility]’;’ 
+~~~~~
 
-All methods are static  by default. To enable redefinition in all the child classes, add “**is virtual;**“ when declaring the method. 
+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
+@subsubsection occt_cdl_4_4_4 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] 
+
+**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]’;’ 
+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. 
+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** 
+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. 
@@ -1209,103 +1249,99 @@ 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”. 
+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. 
+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. 
+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: 
+@subsubsection occt_cdl_4_4_5     Declaration by Association
 
-**Example** 
+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: 
+~~~~~
 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, let us go back to the “Distance” method of the “Point” class: 
 
-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 
 
+~~~~~
+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.*** 
+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: 
+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. 
 
-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
+@subsubsection occt_cdl_4_4_6     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- 
+~~~~~
+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-a-field ::= [field-name] from [class] class-name 
+~~~~~
 
-Redefinition of fields  can *only *be done in classes manipulated by a handle. 
+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
+@subsection occt_cdl_4_5   Genericity
 
-@subsubsection occt_1819379591_1972310108451     Overview
+@subsubsection occt_cdl_4_5_1     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
+@subsubsection occt_cdl_4_5_2     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}’)’] 
+~~~~~
+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. 
@@ -1316,484 +1352,495 @@ 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** 
-
+Below is a partial  example of a generic class: a persistent singly linked list.
+~~~~~
 generic class SingleList (Item as Storable) 
-inherits Persistent 
-raises NoSuchObject 
-is 
-Create returns mutable SingleList; 
+       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; 
+       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** 
 
+**Example** 
+~~~~~
 generic class Sequence(Item as any, Node as 
 SingleList(Item)) 
 inherits Object 
 . . . 
 end Sequence 
+~~~~~
 
-In the above example,  there are two generic types: Item &amp; Node. The first imposes no restriction.  The second must at least have available the services of the class SingleList  instantiated with the type with which Sequence will itself be instantiated. 
+In the above example,  there are two generic types: *Item* and *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** 
+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
+~~~~~
+
+@subsubsection occt_cdl_4_5_3     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-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** 
+For example, let’s  instantiate the class *Sequence* for the type *Point*: 
 
+~~~~~
 class SingleListOfPoint instantiates SingleList(Point); 
 class Sequence instantiates 
-Sequence(Point,SingleListOfPoint); 
+       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. 
+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
+@subsubsection occt_cdl_4_5_4    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. 
 
-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}] 
+~~~~~
+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 
+   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**, 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. 
+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. 
+       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. 
+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}; 
+~~~~~
+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
+@subsection occt_cdl_4_6   Visibility
 
-@subsubsection occt_1819379591_1972310108461     Overview
+@subsubsection occt_cdl_4_6_1     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
+@subsubsection occt_cdl_4_6_2     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. 
+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 
+~~~~~
+field ::= identifier {’,’ identifier} ’:’ data-type 
 [’[’integer{’,’integer}’]’] 
-[**is protected**]’;’ 
-Example 
+[is protected]’;’ 
+~~~~~
+
+**Example** 
 
+~~~~~
 fields 
    Phi, Delta, Gamma : AngularMomenta [3] 
    is protected ; 
+~~~~~
 
+@subsubsection occt_cdl_4_6_3     Visibility of Methods
 
-@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. 
 
-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.  
+* **Public** methods are the default and 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 
+~~~~~
 
--- 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. 
+The declaration of the  visibility of a method appears at the end of its definition, before the final  semi-colon. The attribute **private** indicates that the method will only be  visible to the behavior of the class of which the method is a member; **protected** will propagate the visibility among the sub-classes of this class. 
 
 For example, add to the  class “Line” an internal method allowing the calculation of the perpendicular  distance to the power of two, from the line to a point. 
-**Example** 
 
+~~~~~
 SquareDistance (me; P : Point) returns Real 
-@subsubsection occt_1819379591_1972310108464     Visibility of Classes, Exceptions, &amp; Enumerations
+is private;
+~~~~~
+
+@subsubsection occt_cdl_4_6_4     Visibility of Classes, Exceptions and 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. 
+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**. 
+As was explained in the  section on “<a href="#occt_cdl_3_3_2">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. 
+A class declared **private** is only available within its own package. 
 
-@subsubsection occt_1819379591_1972310108465    Friend  Classes &amp; Methods
+@subsubsection occt_cdl_4_6_5    Friend  Classes and 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. 
+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 
+**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”. 
+The formal part must be present 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. 
-
-    @image html /dev_guides/cdl/images/cdl_image011.png
-    @image latex /dev_guides/cdl/images/cdl_image011.png
+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. 
 
 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
+
+| | Public | Private | Protected |
+| :---- | :---- | :---- | :----- |
+| Field | Does not exist | **Default** - Visible to methods in its own class and in friend classes | Visible to methods in its own class, sub-classes and friend classes |
+| Method | **Default** - Callable anywhere | Callable by methods in its own class and in friend classes | Callable by methods in its own class, sub-classes and friend classes | 
+| Class | **Default**  - Visible everywhere with the use of **from** rubric | Visible to classes in its own package | Does not exist | 
+| Package method | **Default** - Callable everywhere with the use of **from** rubric | Visible to classes in its own package | Does not exist | 
+| Nested Class | **Default** -  Visible to the clients of the encompassing class | Visible to the encompassing class and other classes nested in the encompassing class | Does not exist | 
 
 
+@section occt_cdl_5 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’ 
+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. 
 
-(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’ 
+(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’ 
 
-(3) digit ::= 
-’0’ | ’1’ | ’2’ | ’3’ | ’4’ | ’5’ | ’6’ | ’7’ | 
-’8’ | ’9’ 
+(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’ 
 
-(4) underscore ::= 
-’_’ 
+(3) digit ::= ’0’ | ’1’ | ’2’ | ’3’ | ’4’ | ’5’ | ’6’ | ’7’ | ’8’ | ’9’ 
 
-(5) special character  ::= 
-’ ’ | ’!’ | ’”’ | ’#’ | ’$’ | ’%’ | ’&amp;’ | ’’’ | 
-’(’ | ’)’ | ’*’ | ’+’ | ’,’ | ’-’ | 
-’.’ | ’/’ | ’:’ | ’;’ | ’’ | ’=’ | ’’ | ’?’ | 
-’@’ | ’[’ | ’\’ | ’]’ | ’^’ | ’‘’ | 
-’{’ | ’|’ | ’}’ | ’~’ 
+(4) underscore ::= ’_’ 
 
-(6) printable  character::= 
-capitals | non-capitals | digits | underscore | 
-special characters 
+(5) special character  ::= ’ ’ | ’!’ | ’”’ | ’#’ | ’$’ | ’%’ | ’&amp;’ | ’’’ | ’(’ | ’)’ | ’*’ | ’+’ | ’,’ | ’-’ | ’.’ | ’/’ | ’:’ | ’;’ | ’’ | ’=’ | ’’ | ’?’ | ’@’ | ’[’ | ’\’ | ’]’ | ’^’ | ’‘’ | ’{’ | ’|’ | ’}’ | ’~’ 
 
-(7) letter ::= 
-capital |  non-capital 
+(6) printable  character::= capitals | non-capitals | digits | underscore | special characters 
 
-(8) alphanumeric ::= 
-letter | digit 
+(7) letter ::= capital |  non-capital 
 
-(9) identifier ::= 
-letter{[underscore]alphanumeric} 
+(8) alphanumeric ::= letter | digit 
 
-(10) integer ::= 
-digit{digit} 
+(9) identifier ::= letter{[underscore]alphanumeric} 
 
-(11) exponent ::= 
-’E’[’+’]integer |  ’E-’integer 
+(10) integer ::= digit{digit} 
 
-(12) numeric-constant  ::= 
-[’+’]integer ’.’ integer[exponent] | ’-’integer 
-’.’ integer[exponent] 
+(11) exponent ::= ’E’[’+’]integer |  ’E-’integer 
 
+(12) numeric-constant  ::= [’+’]integer ’.’ integer[exponent] | ’-’integer ’.’ integer[exponent] 
 
-(13) literal-constant  ::= 
-’’’printable character’’’ | ’~’{printable 
+
+(13) literal-constant  ::= ’’’printable character’’’ | ’~’{printable 
 character}’~’ 
 
-(14) package-name ::= 
-identifier 
+(14) package-name ::= identifier 
+
+(15) enumeration-name  ::= identifier [**from** package-name] 
+
+(16) class-name ::= identifier [**from** package-name] 
 
-(15) enumeration-name  ::= 
-identifier [**from**** **package-name] 
+(17) exception-name ::= identifier [**from** package-name] 
 
-(16) class-name ::= 
-identifier [**from**** **package-name] 
+(18) constructor-name  ::= ’Create’ |  ’Initialize’ 
 
-(17) exception-name ::= 
-identifier [**from**** **package-name] 
+(19) primitive-type ::= ’Boolean’ |  ’Character’ | ’Integer’ | ’Real’ 
 
-(18) constructor-name  ::= 
-’Create’ |  ’Initialize’ 
+(20) data-type ::= enumeration-name | class-name | exception-name | primitive-type 
 
-(19) primitive-type ::= 
-’Boolean’ |  ’Character’ | ’Integer’ | ’Real’ 
+(21) passed-type ::= data-type | **like me** | **like** identifier 
 
-(20) data-type ::= 
-enumeration-name | class-name | exception-name 
-| primitive-type 
+(22) passing-mode ::= [**in**] | **out** | **in out** 
 
-(21) passed-type ::= 
-data-type | **like me**** **| **like**** **identifier 
+(23) parameter-access ::= **mutable** | [**immutable**] 
 
-(22) passing-mode ::= 
-[**in**] | **out**** **| **in out** 
+(23A) return-access ::= **mutable** | [**immutable**]| **any** 
 
-(23) parameter-access ::= 
-**mutable**** **| [**immutable**] 
+(24) value ::= numeric-constant | literal-constant | identifier 
 
-(23A) return-access ::= 
-**mutable**** **| [**immutable**]| **any** 
+(25) parameter ::= identifier {’,’ identifier} ’:’ passing-mode access-right passed-type [’=’ value] 
 
-(24) value ::= 
-numeric-constant | literal-constant | 
-identifier 
+(26) simple-formal-part  ::= ’(’parameter {’;’  parameter}’)’ 
 
-(25) parameter ::= 
-identifier {’,’ identifier} ’:’ passing-mode 
-access-right passed-type [’=’ value] 
+(27)  formal-part-of-instance-method ::= ’(’ **me** [’:’ passing-mode access-right] {’;’ parameter}’)’ 
 
-(26) simple-formal-part  ::= 
-’(’parameter {’;’  parameter}’)’ 
+(28)  formal-part-of-class-method ::= ’(’ **myclass** {’;’ parameter}’)’ 
 
-(27)  formal-part-of-instance-method ::= 
-’(’**me**** **[’:’ passing-mode access-right] {’;’ 
-parameter}’)’ 
+(29) visibility ::= **private** | **protected** 
 
-(28)  formal-part-of-class-method ::= 
-’(’**myclass**** **{’;’ parameter}’)’ 
+(30) redefinition ::= **static** | **deferred** 
 
-(29) visibility ::= 
-**private**** **| **protected** 
-(30) redefinition ::= 
-**static**** **| **deferred** 
-(31) definition-level  ::= 
-redefinition |** ****redefined**** **[redefinition] 
+(31) definition-level ::= redefinition | **redefined** [redefinition] 
 
-(32)  declaration-of-constructed-type ::= 
-**returns**** **[**mutable**] class-name 
+(32)  declaration-of-constructed-type ::= **returns** [**mutable**] class-name 
 
-(33)  declaration-of-returned-type ::= 
-**returns**** **return-access  passed-type 
+(33)  declaration-of-returned-type ::= **returns** return-access  passed-type 
 
-(34)  declaration-of-errors ::= 
-**raises**** **exception-name {’,’  exception-name} 
+(34)  declaration-of-errors ::= **raises** exception-name {’,’  exception-name} 
 
-(35)  declaration-of-visibility ::= 
-**is****  **visibility 
+(35)  declaration-of-visibility ::= **is** visibility 
 
-(36)  declaration-of-attributes-of-instance-method ::= 
-**is**** **visibility | **is **definition-of-level 
-[visibility] 
+(36)  declaration-of-attributes-of-instance-method ::= **is** visibility | **is** definition-of-level [visibility] 
 
-(37) constructor ::= 
-constructor-name [simple-formal-part] 
+(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 
+(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 
+(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] 
+(40) package-method ::= identifier [simple-formal-part] 
 [declaration-of-returned-type] 
 [declaration-of-errors] 
 [**is private**]’;’ 
 
-(41) member-method ::= 
-constructor |  instance-method | class-method 
+(41) member-method ::= constructor |  instance-method | class-method 
 
-(42) formal-part ::= 
-simple-formal-part | 
-formal-part-of-instance-method| 
-formal-part-of-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] | 
+(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 
+(44) field ::= identifier {’,’ identifier} ’:’ data-type 
 [’[’integer {’,’ integer}’]’] 
 [**is protected**]’;’ 
 
-45)  redefinition-of-field ::= 
-[field-name] **from**** **[**class**] class-name 
+45)  redefinition-of-field ::= [field-name] **from** [**class**] class-name 
 
-(46)  declaration-of-fields ::= 
-**fields**** **[**redefined**** **redefinition-of-field  {’,’ 
-redefinition-of-field}’;’] 
+(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] 
+(47)  declaration-of-an-alias::= [**private**] **alias** class-name1 **is** class-name2  [**from** package-name] 
 
-(48)  declaration-of-friends ::= 
-**friends**** **friend {’,’ friend} 
+(48)  declaration-of-friends ::= **friends** friend {’,’ friend} 
 
-(49) class-definition  ::= 
-[{member-method}] 
+(49) class-definition  ::= [{member-method}] 
 [declaration-of-fields] 
 [declaration-of-friends] 
 
-(50)  declaration-of-an-exception ::= 
-**exception**** **exception-name 
-**inherits**** **exception-name 
+(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]]’;’ 
+(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’;’ 
+[**deferred**] **class** class-name’;’ 
 
 (53)  incomplete-declaration-of-a-generic-class ::= 
-[**deferred**] **generic class**** **class-name {’,’ class-name}’;’ 
+[**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
-
-    @image html /dev_guides/cdl/images/cdl_image012.png
-    @image latex /dev_guides/cdl/images/cdl_image012.png
-    
\ No newline at end of file
+[**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 
+
+(57) 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}]
+[{[visibility] declaration-of-a-class}]
+**is** class-definition
+**end** [class-name]’;’
+
+(58) instantiation-of-a-generic-class::=
+[**deferred**] **class** class-name
+**instantiates** class-name ’(’data-type
+{’,’ data-type}’);’
+
+(59) declaration-of-a-class::=
+incomplete-declaration-of-a-non-generic-class
+|
+incomplete-declaration-of-a-generic-class |
+declaration-of-a-non-generic-class |
+declaration-of-a-generic-class |
+instantiation-of-a-generic-class
+
+(60) type-declaration ::=
+[private] declaration-of-an-enumeration | [**private**] class-declaration | declaration-of-an-exception
+
+(61) package-definition ::=
+[{type-declaration}]
+[{package-method}]
+
+(62) package-declaration ::= **package** package-name
+[**uses** package-name {’,’ package-name}]
+  **is** package-definition
+**end** [package-name]’;’
+
+(63) executable-declaration ::=
+             **executable** executable-name
+                            **is**
+            {
+             **executable** executable-part
+[**uses** [identifier **as external**]
+     [{’,’ identifier **as external**}]
+     [unit-name **as library**]
+     [{’,’ unit-name **as library**}]
+                           **is**
+                     {file-name [as C++|c|fortran|object];}
+                               **end** ’;’
+                }
+                **end** ’;’
+
+(64) schema-declaration ::=
+ **schema** schema-name
+  **is**
+[{**package** package-name ’;’ }]
+[{**class** class-name ’;’ }]
+**end** ’;’
+
+
+
+
+
+@section occt_cdl_6 Appendix B Comparison of CDL and C++ 
+
+## Syntax for Data Types manipulated by Handle and by Value in CDL
+
+|  | Handle | Value |
+| :---- | :---- | :---- | 
+| Permanent | Persistent | Storable |
+| Temporary | Transient | Any |
+| Reading | Immutable | In |
+| Writing | Mutable | Out |
+| Read/Write | Mutable | In out | 
+| Return | Not specified : any | Without copy: --C++ return const& |
+
+## Syntax for Data Types manipulated by Handle and by Value in C++
+
+| | Handle | Value |
+| :---- | :---- | :--- |
+| C++ Declaration | Handle(PGeom_Point) p1; | gp_Pnt p2; |
+| C++ Constructor | p1 = newPGeom_Point(p2); | p2(0.,0.,0.); |
+| C++ Method | x=p1 -> XCoord(); | x=p2.XCoord(); |
+
+
+   
\ No newline at end of file
diff --git a/dox/dev_guides/contribution_workflow/contribution_workflow.md b/dox/dev_guides/contribution_workflow/contribution_workflow.md
new file mode 100644 (file)
index 0000000..8db8e35
--- /dev/null
@@ -0,0 +1,283 @@
+Contribution Workflow {#dev_guides_contribution_workflow}
+====================================
+@tableofcontents 
+
+@section occt_contribution_workflow_1 Introduction
+
+The purpose of this document is to describe standard workflow for processing contributions to certified version of OCCT. 
+
+@subsection occt_contribution_workflow_1_1 Use of issue tracker system
+
+Each contribution should have corresponding issue (bug, or feature, or integration request) 
+registered in the MantisBT issue tracker system accessible by URL 
+http://tracker.dev.opencascade.org. 
+The issue is processed further according to the described workflow.
+
+@subsection occt_contribution_workflow_1_2 Access Levels 
+
+  Access level defines the permissions of the user to view, 
+  register and modify issues in a Mantis bugtracker. 
+  The correspondence of access level and user permissions 
+  is defined in accordance with the table below.
+
+| Access level  | Granted to       | Permissions       | Can set statuses         |
+|:------------- | :--------- | :-------------- | :----------------------- |
+| Viewer        | Everyone (anonymous access)   | View public issues only    | No     |
+| Reporter | Users registered on dev.opencascade.com  | View, report, and comment issues  | New, Resolved   |
+| Updater       | Users of dev.opencascade.com in publicly visible projects | View  and comment issues | New, Resolved  |
+| Developer     | OCC developers and external contributors who signed the CLA  | View, report, modify, and handle issues | New, Assigned, Resolved, Reviewed  |
+| Tester        | OCC engineer devoted to certification testing | View, report, modify, and handle issues | Assigned, Tested         |
+| Manager       | Person responsible for a project or OCCT component | View, report, modify, and handle issues | New, Resolved, Reviewed, Tested, Closed  |
+
+According to his access level, the user can participate in the issue handling process under different roles, as described below.
+
+@section occt_contribution_workflow_2 Typical workflow for an issue
+
+@subsection occt_contribution_workflow_2_1 General scheme
+
+@image html OCCT_ContributionWorkflow_V3_image001.png "Standard life cycle of an issue"
+@image latex OCCT_ContributionWorkflow_V3_image001.png "Standard life cycle of an issue"
+  
+@subsection occt_contribution_workflow_2_2 Issue registration
+
+An issue is registered in Mantis bugtracker by the Reporter with definition of the necessary attributes. 
+The definition of the following attributes is obligatory:
+
+  * **Category** - indicates component of OCCT to which the issue relates. If in doubt, assign OCCT:Foundation Classes.
+  * **Reproducibility** 
+  * **Severity** 
+  * **Priority**
+  * **Profile** - allows defining the platform on which the problem was detected   from the list of predefined platforms. If a platform is absent in the list of predefined platforms it is possible to use Or Fill In option to define the platform manually.
+    * **Platform**
+    * **OS**
+    * **OS Version**
+  * **Products Version** - defines the version of Open CASCADE on which the problem has been detected.
+  * **Summary** - a short, one sentence description of the issue. It has a limit of 128 characters. It should be informative and useful for the developers. It is advisable to avoid vague or misleading phrases, such as "it doesn't work" or "it crashed". It is not allowed to mention the issue originator, and in particular the customer, in the name of the registered issue.
+  * **Description** - should contain a detailed definition of the nature of the registered issue depending on its type. For a bug it is required to submit a detailed description of the incorrect behavior, including the indication of the cause of the problem (if possible at this stage) or any inputs from the originator. For a feature or integration request it is recommended to describe the proposed feature in details (as possible at that stage), including the changes required for its implementation and the main features of the new functionality. Filling the bug description is obligatory. 
+  * **Steps To Reproduce** - in this field it is possible to describe in detail how to reproduce the issue.  This field considerably helps to find the cause of the problem, to eliminate it and to create the test case.
+  * *Upload File* field allows attaching the shapes, scripts or modified source files of OCCT. It is recommended to attach a prototype test case in form of a Tcl script for DRAW,   using either existing DRAW commands, or a C++ code which can be organized in DRAW commands,   as well as sample shapes or other input data (if applicable), immediately after the issue registration. 
+  
+  The newly registered issue gets status **NEW** and is assigned to the developer responsible for the OCCT component indicated in the Category field (Maintainer). 
+
+@subsection occt_contribution_workflow_2_3 Assigning the issue
+
+  The description of the new issue is checked by the **Maintainer** and if it is feasible, 
+  he may assign the issue to a **Developer**. Alternatively, any user with **Developer** access level  
+  or higher can assign the issue to himself if he wants to provide a solution. 
+  
+  The recommended way to handle contributions is that the **Reporter** assigns the issue to himself and provides a solution.
+
+  The **Maintainer, Technical Project Manager,** or **Bugmaster** can close or reassign the issue 
+  (in **FEEDBACK** state) to the **Reporter** after it has been registered, if its description does not contain sufficient details to reproduce the bug or explain the purpose of the new feature. 
+  That decision shall be documented in the comments to the issue in the Bugtracker.
+
+  The assigned issue should have state **ASSIGNED**.
+
+@subsection occt_contribution_workflow_2_4 Resolving the issue
+
+  The **Developer** responsible for the issue assigned to him provides a solution 
+  as a change on the version of OCCT indicated in the issue attributes, or the last development version. 
+
+  The modified sources should be submitted for review and testing to the dedicated branch of the official OCCT Git repository:
+
+  * Branch should be created for the issue with name composed of letters ‘CR’ followed by issue ID number (without leading zeroes). 
+   Optional suffix can be added to the branch name after issue ID, 
+   e.g. to distinguish between several version of the fix.
+  * The branch should be based on recent version of the master branch 
+   (not later than commit tagged as last OCCT release).
+  * The first line of the first commit message should contain 
+   the Summary of the issue (starting with its ID followed by colon, e.g. "0022943: Bug TDataXtd_PatternStd"). 
+   The consequent lines should contain a description of the changes made. 
+   If more than one commit has been made, the commit messages should contain description of the changes made.
+  * The amount of the code affected by the change should be limited 
+   to only the changes required for the bug fix or improvement. 
+   Change of layout or re-formatting of the existing code is allowed 
+   only in the parts where meaningful changes related to the issue have been made.
+  * The name of the branch where the fix is submitted should be given 
+   in the note to the Mantis issue 
+   (providing the direct link to relevant branch view in GitWeb is encouraged).
+  * The description of the changes made should be put to the field 
+   "Additional information and documentation updates" of the Mantis issue.
+
+  In some cases (if Git is not accessible for the contributor), 
+  external contributions can be submitted as patch (diff) files or sources 
+  attached to the Mantis issue, with indication of OCCT version on which the fix is made. 
+  Such contributions should be put to Git for processing by someone else,
+  and hence they have less priority in processing than the ones submitted directly through Git.
+
+  The issue for which solution is provided should be switched to **RESOLVED** state 
+  and assigned to the developer who is expected to make a code review 
+  (the **Reviewer**; by default, can be set to the **Maintainer** of the component).
+
+@subsection occt_contribution_workflow_2_5 Code review
+
+  The **Reviewer** analyzes the proposed solution for applicability in accordance with OCCT Code reviewing rules and examines all changes in the sources to detect obvious and possible errors, misprints, conformity to coding style.
+  
+    * If Reviewer detects some problems, he can either:
+      * Fix these issues and provide new solution, reassigning the issue (in **RESOLVED** state) to the **Developer**, who then becomes a **Reviewer**. 
+       Possible disagreements should be resolved through discussion, which is done normally within issue notes (or on the OCCT developer’s forum if necessary).
+      * Reassign the issue back to the **Developer**,  providing detailed list of remarks. The issue then gets status **ASSIGNED** and a new solution should be provided.
+    * If Reviewer does not detect any problems, he changes status to **REVIEWED**.
+
+@subsection occt_contribution_workflow_2_6 Testing
+
+  The issues that are in **REVIEWED** state are subject of certification (non-regression) testing. 
+  The issue is assigned to OCC **Tester** when he starts processing it.
+  The results of tests are checked by the **Tester**: 
+    * If the **Tester** detects build problems or regressions, he changes the status to **ASSIGNED** and reassigns the issue to the **Developer** with a detailed description of the problem. The **Developer** should produce a new solution.
+    * If the **Tester** does not detect build problems or regressions, he changes the status to **TESTED** for further integration.
+
+@subsection occt_contribution_workflow_2_7 Integration of a solution
+
+  Before integration into the master branch of the repository the **Integrator** checks the following conditions:
+    * the change has been reviewed;
+    * the change has been tested without regressions (or with regressions treated properly);
+    * the test case has been created for this issue (when applicable), and the change has been rechecked on this test case;
+    * "Additional information and documentation updates" field is filled by the developer;
+    * the change does not conflict with other changes integrated previously.
+  
+  If the result of check is successful the Integrator integrates solution 
+  into the master branch of the repository. Each change is integrated into the master branch 
+  as a single commit without preserving the history of changes made in the branch 
+  (by rebase, squashing all intermediate commits), however, preserving the author when possible. 
+  This is done to have the master branch history plain and clean. 
+  The following picture illustrates the process:
+  
+@image html OCCT_ContributionWorkflow_V3_image002.jpg "Integration of several branches"
+@image latex OCCT_ContributionWorkflow_V3_image002.jpg "Integration of several branches"
+  
+  The new master branch is tested against possible regressions that might appear due to interference between separate changes. When the tests are Ok, the new master is pushed to the official repository 
+  and the original branches are removed from it.
+  The issue status is set then to **VERIFIED** and is assigned to the **Reporter** so that he could check the fix as-integrated.
+
+@subsection occt_contribution_workflow_2_8 Closing a bug
+
+  The **Bugmaster** closes the issue after regular OCCT Release provided that the issue status is **VERIFIED** and that issue was really solved in that release, by rechecking the corresponding test case. The final issue state is **CLOSED**.
+
+@subsection occt_contribution_workflow_2_9 Reopening a bug
+
+  If a regression is detected, the **Bugmaster** may reopen and reassign the **CLOSED** issue to the appropriate developer with comprehensive comments about the reason of reopening. The issue then becomes **ASSIGNED** again. 
+
+@section occt_contribution_workflow_3 Appendix
+
+@subsection occt_contribution_workflow_3_1 Issue attributes
+
+@subsubsection occt_contribution_workflow_3_1_1 Severity
+
+  Severity shows at which extent the issue affects the product. 
+  The list of used severities is given in the table below in the descending order.
+  
+  | Severity    |                  Description                      | Weight for Bug Score |
+  | :---------- | :------------------------------------------------ | :------------------: |
+  | crash       | Crash of the application or OS, loss of data      |          5           |
+  | block       | Regression corresponding to the previously  delivered official version. Impossible  operation of a function on any data with no work-around. Missing function previously requested in software requirements specification.   Destroyed data.     |        4            |
+  | major       | Impossible operation of a function with existing work-around. Incorrect operation of a function on a particular dataset. Impossible operation of a function after intentional input of incorrect data. Incorrect behavior of a function   after intentional input of incorrect data.  | 3 |
+  | minor       | Incorrect behavior of a function corresponding  to the description in software requirements specification. Insufficient performance  of a function.          |   2     |
+  | tweak       | Ergonomic inconvenience, need of light updates.   |          1           |
+  | text        | Inconsistence of program code to the Coding Standard. Errors in source text  (e.g.  unnecessary variable declarations, missing   comments, grammatical errors in user manuals). | 1 |
+  | trivial     | Cosmetic bugs.                                    |          1           |
+  | feature     | Bug fix, new feature, improvement that requires workload estimation and validation. | 1 |   
+  | integration request | Requested integration of an existing feature into the product.               |          0           |
+  | Just a question       | A question to be processed, without need   of any changes in the product.        |         0                |
+
+@subsubsection occt_contribution_workflow_3_1_2 Statuses of issues
+
+  The bug statuses that can be applied to the issues are listed in the table below. 
+  
+  | Status               |  Description                                                        |
+  | :------------------- | :----------------------------------------- |
+  | New                  | New just registered issue. Testing case should be created by Reporter. |
+  | Feedback             | The issue requires more information; the original posters should pay attention. |
+  | Assigned             | Assigned to a developer.  |
+  | Resolved + a resolution  |    The issue has been fixed, and now is waiting for revision.  |
+  |Revised  + a resolution   | The issue has been revised, and now is waiting for testing. |
+  | Tested               | The fix has been internally tested by the tester with success on the full non-regression database or its part and a test case has been created for this issue. |
+  | Verified             | The fix has been integrated into the master of the corresponding repository |
+  | Closed               | The fix has been integrated to the master. The corresponding test case has been executed successfully. The issue is no longer reproduced. |
+
+@subsubsection occt_contribution_workflow_3_1_3 Resolutions
+
+  **Resolution** is set when the bug is resolved. "Reopen" resolution is added automatically when the bug is reopened.
+
+  | Resolution            |                               Description                                    |
+  |:--------------------- | :--------------------------------------------------------------------------- |
+  | Open                  | The issue is being processed.                                                |
+  | Fixed                 | The issue has been successfully fixed.                                       |
+  | Reopened              | The bug has been reopened because of insufficient fix or regression.         |
+  |                       | Unable to reproduceThe bug is not reproduced.                                |
+  | Not fixable           | The bug cannot be fixed because it is a bug of third party software, or because it requires more workload than it can be allowed.        |
+  | Duplicate             | The bug for the same issue already exists in the tracker.                    |
+  | Not a bug             | It is a normal behavior in accordance with the specification of the product  |
+  | No change required    | The issue didn’t require any change of the product, such as a question issue |
+  | Suspended             | This resolution is set for Acknowledged status only. It means that the issue is waiting for fix until a special administrative decision is taken (e.g. a budget is not yet set in accordance with the contract)       | 
+  | Documentation updated | The issue was a normal behavior of the product, but the actions of the user  were wrong. The specification and the user manual have been updated  to reflect this issue.    |
+  | Won’t fix             | An administrative/contractual decision has been taken to not fix the bug     |
+
+@subsection occt_contribution_workflow_3_2 Update and evolution of documentation
+
+  The documentation on Open CASCADE Technology currently exists in three forms:
+  
+  * OCCT Technical Documentation generated automatically with Doxygen tool on the basis of comments in CDL or HXX files.    
+  * User’s Reference Documentation on OCCT packages and Products supplied in the form of PDF User’s guides
+  * OCCT Release Documentation supplied in the form of Release Notes with each release.
+  
+  It is strictly required to properly report the improvements and changes introduced in OCCT in all three forms of Documentation.
+  
+@subsubsection occt_contribution_workflow_3_2_1 Maintenance of CDL files
+
+  Every developer providing a contribution to the source code of OCC 
+  should make a relevant change in the corresponding header file, including CDL.
+
+  Making the appropriate comments is mandatory in the following cases:
+  
+  * Development of a new package / class / method / enumeration;
+  * Modification of an existing package / class / method / enumeration that changes its behavior;
+  * Modification / new development impacts at other packages / classes / methods / enumerations, the documentation  which of should be modified correspondingly.  
+
+  The only case when the comments may be not required is introducing 
+  a modification that does not change the existing behavior in any noticeable way
+  or brings the behavior in accordance with the existing description.
+  
+  CDL description must be in good English, containing as much relevant 
+  information and as clear as possible. If the developer is unable to properly formulate 
+  his ideas in English or suspects that his description can be misunderstood, 
+  he should address to the Documentation Engineer for language assistance. 
+  Such action is completely subject to the discretion of the developer; however, 
+  the Documentation Engineer can require that the developer should provide a relevant 
+  technical documentation and reopen a bug until all documentation satisfies the requirements above.
+
+@subsubsection occt_contribution_workflow_3_2_2 Maintenance of the User’s Reference Documentation
+
+  The User’s Reference Documentation is distributed among a number of User’s Guides, 
+  each describing a certain module of OCCT. 
+  The User's Guides do not cover the entire functionality of OCCT; 
+  however, they describe most widely used and important packages.
+  
+  In most aspects the User's Guides present the information that is contained in CDL descriptions for methods, classes, etc., only from a different point of view. Thus, it is required that any developer who implements a new or modifies an existing package / class / method / enumeration and adds a description of new development or changes in the corresponding CDL file should also check if this class  package / class / method / enumeration or the package / class, to which the added class / method belongs is already described in the documentation and update the User’s Reference Documentation correspondingly.
+
+3.2.3. Preparation of the Release Documentation
+
+  Before changing the bug Status to RESOLVED, the developer should provide a description of the implemented work using the "Additional information and documentation updates" field of Mantis bugtracker. 
+  
+  This description is used for the Release Documentation and has the following purposes:
+  
+  * to inform the OCCT users about the main features and improvements implemented in the platform in the release;
+  * to give a complete and useable list of changes introduced into the OCCT since the latest version. 
+
+  The changes should be described from the user’s viewpoint so that the text 
+  could be comprehensible even for beginners having a very vague idea about OCCT. 
+  If the developer is unable to properly formulate his ideas in English or suspects 
+  that his description can be misunderstood, he should address to the Documentation Engineer 
+  for language assistance. Such action is completely subject to the discretion of the developer; 
+  however, the Documentation Engineer can require that the developer 
+  should provide a relevant technical documentation and reopen a bug 
+  until all documentation satisfies the requirements.
+
+  **Note**, that it is required to single out the changes in the OCCT behavior as compared to the previous versions and especially the changes to be considered when porting from the previous version of OCCT.
+
+For example: 
+*  If global macros XXX() was used in the code of your application, revise it for direct use of the argument stream object. 
+*  You might need to revise the code related to text display in 3d viewer to take into account new approach of using system fonts via XXX library. 
+
+  The **Documentation Engineer** is responsible for preparation of the version Release Notes 
+  and update of the User’s Guides. If the **Documentation Engineer** considers that the description currently provided by the **Developer** is somehow inadequate or unsatisfactory he can demand the **Developer** to rewrite the documentation with the **Documentation Engineer’s** assistance.
diff --git a/dox/dev_guides/contribution_workflow/images/OCCT_ContributionWorkflow_V3_image001.png b/dox/dev_guides/contribution_workflow/images/OCCT_ContributionWorkflow_V3_image001.png
new file mode 100644 (file)
index 0000000..110b38a
Binary files /dev/null and b/dox/dev_guides/contribution_workflow/images/OCCT_ContributionWorkflow_V3_image001.png differ
diff --git a/dox/dev_guides/contribution_workflow/images/OCCT_ContributionWorkflow_V3_image002.jpg b/dox/dev_guides/contribution_workflow/images/OCCT_ContributionWorkflow_V3_image002.jpg
new file mode 100644 (file)
index 0000000..c362ec4
Binary files /dev/null and b/dox/dev_guides/contribution_workflow/images/OCCT_ContributionWorkflow_V3_image002.jpg differ
index ec7b3ae..327cc39 100644 (file)
@@ -8,7 +8,7 @@ The following documents provide information on OCCT building, development and te
 * @subpage dev_guides__coding_rules "Coding Rules"
 * Contribution Workflow
 * Guide to installing and using Git for OCCT development
-* @subpage dev_guides__tests "Automatic Testing system"
+ @subpage dev_guides__tests "Automatic Testing system"
 
 Two other documents provide details on obsolete technologies used by OCCT, 
 to be removed in future releases:
diff --git a/dox/dev_guides/git_guide/git_guide.md b/dox/dev_guides/git_guide/git_guide.md
new file mode 100644 (file)
index 0000000..1daf4f1
--- /dev/null
@@ -0,0 +1,602 @@
+Guide to installing and using Git for OCCT development {#dev_guides_git_guide}
+=================================
+
+@tableofcontents 
+
+@section occt_gitguide_1 Overview
+
+@subsection occt_gitguide_1_1 Purpose
+
+  The purpose of this document is to provide a practical introduction to Git 
+  to OCCT developers who are not familiar with this tool 
+  and to facilitate the use of the official OCCT Git repository for code contribution to OCCT.
+
+  Reading this document does not exempt from the need to learn Git concepts and tools. 
+  Please consult a book or manual describing Git to get acquainted with this tool. 
+  Many good books on Git can be found at http://git-scm.com/documentation 
+  
+  For the experienced Git users it can be enough to read sections 1 and 3
+   of this document to start working with the repository.
+   
+  Please make sure to get familiar with the Contribution Workflow document 
+  that describes how Git is used for processing contributions to OCCT.
+  
+  This and related documents are available at the Resources page 
+  of the OCCT development portal at http://dev.opencascade.org/index.php?q=home/resources. 
+
+@subsection occt_gitguide_1_2 Git URL
+
+  URL of the official OCCT source code Git repository (accessed by SSH protocol) is:
+  
+   gitolite@git.dev.opencascade.org:occt
+  
+  or 
+  
+   ssh://gitolite@git.opencascade.org/occt.git
+
+@subsection occt_gitguide_1_3 Content
+
+The official repository contains:
+
+  * The current certified version of OCCT: the "master" branch. This branch is updated by the Bugmaster only. Official OCCT releases are marked by tags.
+  * Topic branches created by contributors to submit changes for review / testing or for collaborative development.    The topic branches should be named by the pattern "CR12345" where 12345    is the ID of the relevant issue registered in Mantis (without leading zeroes),    and "CR" stands for "Change Request". The name can have an additional postfix used if more than    one branch was created for the same issue.
+  * Occasionally topic branches with non-standard names can be created by the Bugmaster for special needs.
+
+@subsection occt_gitguide_1_4 Short rules of use
+
+  The name specified in the user.name field in Git configuration should correspond 
+  to your login name on the OCCT development portal. 
+  This is important to clearly identify the authorship of commits. 
+  (The full real name can be used as well; in this case add the login username in parentheses.)
+  
+  By default, contributors are allowed to push branches only with the names starting with CR 
+  (followed by the relevant Mantis issue ID). 
+  Possibility to work with other branches can be enabled by the Bugmaster on request.
+  
+  The branch is created by the developer in his local repository when the development of a contribution starts. 
+  The branch for new developments is to be created from the current master. 
+  The branch for integration of patches or developments based on an obsolete version 
+  is created from a relevant tag or commit. The branch should be pushed to the official repo 
+  only when sharing with other people (for collaborative work or review / testing) is needed. 
+  
+  Rebasing the local branch to the current master is encouraged before the first submission 
+  to the official repository. If rebasing was needed after the branch is pushed to the official repo, 
+  the rebased branch should have a different name (use suffix).
+  
+  Integration of contributions that have passed certification testing is made exclusively by the Bugmaster. 
+  Normally this is made by rebasing the contribution branch on the current master 
+  and squashing it into a single commit. This is made to have the master branch history plain and clean, 
+  following the general rule “one issue – one commit”. 
+  The description of the commit integrated to the master branch is taken from the Mantis issue 
+  (ID, 'Summary', followed by the information from 'Documentation' field if present).
+  
+  In special cases when it is important to save the  commits history in the branch 
+  (e.g. in case of  a long-term development integration) it can be integrated by merge (no fast-forward).
+  
+  The authorship of the contribution is respected by preserving the Author field of the commit when integrating.
+  Branches are removed from the official repository when integrated to the master. 
+  The Bugmaster can also remove branches which have no commits during one-month period.
+  
+  The Bugmaster may ask the developer (normally the one who produced the contribution) 
+  to rebase a branch on the current master, in the case if merge conflicts appear during integration.
+
+@subsection occt_gitguide_1_5 Version of Git
+
+  The repository is tested to work with Git 1.7.6 to 1.7.9. 
+  Please do not use versions below 1.7.1 as they are known to cause troubles.
+
+@section occt_gitguide_2 Installing Tools for Work with Git
+
+@subsection occt_gitguide_2_1 Windows platform
+
+  Installation of Git for Windows (provided by MSysGit project) is required. 
+  
+  In addition, it is recommended to install TortoiseGit to work with Git on Windows. 
+  If you do not install TortoiseGit or any other GUI tool, 
+  you can use GitGui and Gitk GUI tools delivered with Git and available on all platforms.
+
+@subsubsection occt_gitguide_2_1_1 Installation of Git for Windows
+
+  Download Git for Windows distributive from http://code.google.com/p/msysgit/downloads/list.
+  During the installation:
+
+  * Select Windows Explorer integration options:
+    * Git Bash Here
+    * Git GUI Here
+    
+@image html OCCT_GitGuide_V2_image001.png
+@image latex OCCT_GitGuide_V2_image001.png
+
+  * To avoid a mess in your PATH, we recommend selecting ‘Run Git from Windows Prompt’ in the environment settings dialog: 
+  
+@image html OCCT_GitGuide_V2_image002.png
+@image latex OCCT_GitGuide_V2_image002.png
+
+  * In "Configuring the line ending conversions" dialog, select "Checkout Windows-style, commit Unix style endings".
+  
+@image html OCCT_GitGuide_V2_image003.png
+@image latex OCCT_GitGuide_V2_image003.png
+  Note that by default Git user interface is localized to the system default language. 
+  If you prefer to work with the English interface, remove or rename .msg localization file 
+  in subdirectories *share/git-gui/lib/msgs* and *share/gitk/lib/msgs* of the Git installation directory.
+  
+  Before the first commit to the OCCT repository, make sure that your User Name in the Git configuration file (file *.gitconfig* in the $HOME directory) is equal to your username on the OCCT development portal. 
+
+@subsubsection occt_gitguide_2_1_2 Installation and configuration of TortoiseGit
+
+  Download TortoiseGit distributive from http://code.google.com/p/tortoisegit/downloads/list. 
+  Launch the installation.
+
+  * Select your SSH client. Choose OpenSSH if you prefer to use command-line tools 
+   for SSH keys generation, or TortoisePLink if you prefer to use GUI tool (PuttyGen, see 3.2):
+   
+@image html OCCT_GitGuide_V2_image004.png
+@image latex OCCT_GitGuide_V2_image004.png
+
+  * Complete the installation.
+  
+@image html OCCT_GitGuide_V2_image005.png
+@image latex OCCT_GitGuide_V2_image005.png
+  
+  TortoiseGit integrates to Windows Explorer, thus it is possible to use popup menu in Windows Explorer to access its functionality:
+  Note that if you have installed MSysGit or have Git installed in non-default path, 
+  on the first time you use TortoiseGit you may get the message demanding to define path to Git. 
+  In such case, click on **Set MSysGit path** button and add the path to git.exe 
+  and path to MigGW libraries in the Settings dialog.
+
+  * After the installation  select Start -> Programs -> TortoiseGit Settings to configure TortoiseGit.
+  
+  Select Git->Config to add your user name and Email address to the local .gitconfig file
+  
+  @image html OCCT_GitGuide_V2_image006.png
+  @image latex OCCT_GitGuide_V2_image006.png
+
+@subsection occt_gitguide_2_2 Linux platform
+
+  We assume that Linux users have Git already installed and available in the PATH.
+  
+  Make sure to configure Git so that the user name is equal to your username 
+  on the OCCT development portal, and set SafeCrLf option to true:
+
+~~~~~
+    > git config --global user.name "Your User Name"
+    > git config --global user.email your@mail.address
+    > git config --global your@mail.address
+~~~~~
+
+@section occt_gitguide_3 Getting access to the repository
+
+@subsection occt_gitguide_3_1 Prerequisites
+
+  Access to the repository is granted to the users who have signed the Contributor License Agreement.
+  
+  The repository is accessed by SSH protocol, thus you need to register your public SSH key 
+  on the development portal to get access to the repository.
+  
+  SSH keys are used for secure authentication of the user when accessing the Git server. 
+  Private key is the one stored on the user workstation (optionally encrypted). 
+  Open (or public) key is stored in the user account page on the web site. 
+  When Git client accesses the remote repository through SSH, 
+  it uses this key pair to identify the user and acquire relevant access rights.
+  
+  Normally when you have Git installed, you should have also SSH client available. 
+  On Unix/Linux it is installed by default in the system. 
+  On Windows it is typical to have several SSH clients installed; 
+  in particular they are included with Cygwin, Git, TortoiseGit.
+  
+  It is highly recommended to use the tools that come 
+  with the chosen Git client for generation of SSH keys. 
+  Using incompatible tools (e.g. ssh-keygen.exe from Cygwin for code generation, 
+  and TortoiseGit GUI with a default Putty client for connection to server) 
+  may lead to authentication problems.
+
+@subsection occt_gitguide_3_2 How to generate a key
+
+@subsubsection occt_gitguide_3_2_1 Generating key with Putty
+
+  Use this option if you have installed TortoiseGit (or other GUI Git client on Windows) 
+  and have chosen “TortoisePLink” (or other Putty client) as SSH client during installation.
+  
+  To generate the key with this client, run Puttygen (e.g. from Start menu -> TortoiseGit -> Puttygen), 
+  then click Generate and move mouse cursor over the blank area until the key is generated. 
+  
+@image html OCCT_GitGuide_V2_image007.png "Putty key generator"
+@image latex OCCT_GitGuide_V2_image007.png "Putty key generator"
+
+  After the key is generated, you will see GUI controls to define the public key comment 
+  and / or specify the password for the private key protection. 
+  When done, save both the public and the private key to the files of your choice 
+  (make sure to store your private key in a secure place!).
+  
+  Copy the public key as shown by Puttygen to the clipboard to add it in your account. 
+  Do not copy the Putty public key file content -- it is formatted in a way not suitable for the web site.
+
+@subsubsection occt_gitguide_3_2_2 Generating key with command-line tools
+
+  Use this option if you work on Linux or if you have chosen “OpenSSH” as SSH client 
+  during installation of TortoiseGit (or other Windows tool).
+  
+  Make sure that you have *ssh* and *ssh-keygen* commands in the path. 
+  On Windows, you might need to start 'Git Bash' command prompt window provided by Git for Windows.
+  
+  Use the following command to generate SSH keys:
+~~~~~  
+    > ssh-keygen -t rsa -C "your@mail.address"
+~~~~~  
+
+  The last argument is an optional comment, which can be included with the public key and used to distinguish between different keys (if you have many).  The common practice is to put here your mail address or workstation name.
+  
+  The command will ask you where to store the keys. It is recommended to accept the default path *$HOME/.ssh/id_rsa*. Just press Enter for that. You will be warned if a key is already present in the specified file; you can either overwrite it by the new one, or stop generation and use the old key.
+    
+  If you want to be on the safe side, enter password to encrypt the private key. You will be asked to enter this password each time you use that key (e.g. access a remote Git repository), unless you use the tool that caches the key (like TortoiseGit). If you do not want to bother, enter an empty string.  
+  
+  On Windows, make sure to note the complete path to the generated files (the location of your $HOME might be not obvious). Two key files will be created in the specified location (by default in $HOME/.ssh/):
+  
+  * *id_rsa* - private key
+  * id_rsa.pub - public key
+  
+  The content of the public key file (one text line) is the key to be added to the user account on the site (see below).
+
+@subsubsection occt_gitguide_3_2_3 Generating key with Git GUI
+
+  GitGUI (standard GUI interface included with Git) provides the option 
+  to either generate the SSH key (if not present yet) or show the existing one. 
+  Click Help/Show SSH key and copy the public key content for adding to the user account page (see below).
+
+@subsection occt_gitguide_3_3 Adding public key in your account
+
+  Log in on the portal http://dev.opencascade.org and click on 'My account' link to the right. 
+  If you have a Contributor status, you will see 'SSH keys' tab to the right. 
+  Click on that tab, then click 'Add a public key', and paste the text of the public key 
+  (see above sections on how to generate the key) into the text box. 
+  Click "Save" to input the key to the system. 
+  
+  Note that a user can have several SSH keys. 
+  You can distinguish between these keys by the Title field ID; by default it is taken from SSH key comment. 
+  It is typical to use your e-mail address or workstation name for this field; no restrictions are set by the portal.
+  
+@image html OCCT_GitGuide_V2_image008.png
+@image latex OCCT_GitGuide_V2_image008.png
+
+  Please note that some time (5-10 min) is needed for the system 
+  to update the configuration after the new key is added. 
+  After that time, you can try accessing Git.
+
+@section occt_gitguide_4 WORK WITH REPOSITORY: DEVELOPER OPERATIONS
+
+@subsection occt_gitguide_4_1 General workflow
+
+  To start working with OCCT source repository, you need to create its clone in your local system. 
+  This cloned repository will manage your working copy of the sources 
+  and provide you the means to exchange code between your clone and the origin. 
+  
+  In most cases it is sufficient to have one clone of the repository; 
+  your working copy will be updated automatically by Git when you switch branches.
+  
+  The typical development cycle for an issue is as follows:
+
+  * Create a new branch for your development, basing on the selected version of the sources 
+   (usually the current master) and switch your working copy to it
+  * Develop and test your change. Note that for the first time, and after any changes 
+   made in CDL files you will have to re-generate build scripts or Visual Studio projects using WOK. 
+  * Do as many commits in your branch as you feel convenient; 
+   the general recommendation is to commit every stable state (even incomplete), to record the history of your development.
+  * Push your branch to the repository when your development is complete or when you need to share it with other people (e.g. for review)
+  * Before the first push, rebase your local branch on the latest master; 
+   consider collapsing the history in one commit unless you think the history of your commits is interesting for others. 
+   Make sure to provide a good commit message.
+  * Do not amend the commits that have been already pushed in the remote repository, 
+   If you need to rebase your branch, commit the rebased branch under a different name, and remove the old branch.
+  
+  You can switch to another branch at any moment 
+  (unless you have some uncommitted changes in the working copy) 
+  and return back to the branch when necessary (e.g. to take into account review remarks). 
+  Note that only the sources that are different between the switched branches will be modified, 
+  thus required recompilation should be reasonably small in most cases.
+
+@subsection occt_gitguide_4_2 Cloning official repository
+
+  Clone the official OCCT repository in one of following ways:
+
+  * From command line by command: 
+
+~~~~~  
+    > git clone gitolite@git.dev.opencascade.org:occt <path>
+~~~~~
+
+  where <i><path></i> is the path to the new folder which will be created for the repository.
+    
+  * In TortoiseGit: right-click in the Explorer window, then choose "Git Clone":
+@image html OCCT_GitGuide_V2_image009.png
+@image latex OCCT_GitGuide_V2_image009.png
+
+  If you have chosen Putty as SSH client during TortoiseGit installation, check the “Load Putty Key” option and specify the location of the private key file saved by PuttyGen (see 3.2.1). This shall be done for the first time only.   
+  
+  Note that on the first connection to the repository server you may be requested to enter a password for your private SSH key; further you can get a message that the authenticity of the host cannot be established and will be asked if you want to continue connecting or not:
+
+@image html OCCT_GitGuide_V2_image010.png
+@image latex OCCT_GitGuide_V2_image010.png
+
+  Choose “Yes” to continue. Then the host’s key will be stored in $HOME/.ssh/known_hosts file.
+
+@subsection occt_gitguide_4_3 Branch creation
+
+  You need to create a branch when you are going to start development of a new change, 
+  apply a patch, etc. It is recommended to fetch updates from the remote repository 
+  before this operation, to make sure you work with the up-to-date version.
+  
+  Create a branch from the current master branch unless you need to base your development on a particular version or revision. 
+
+In the console:
+
+~~~~~
+    > git checkout -b CR12345 origin/master
+~~~~~
+  
+In TortoiseGit: 
+  * Go to the local copy of the repository. 
+  * Right-click in the Explorer window, then choose "Git Create Branch".
+  
+@image html OCCT_GitGuide_V2_image011.png
+@image latex OCCT_GitGuide_V2_image011.png
+
+  * Select “Base On” Branch remotes/origin/master 
+
+@image html OCCT_GitGuide_V2_image012.png
+@image latex OCCT_GitGuide_V2_image012.png
+
+  Check option ‘Switch to new branch’ if you are going to start working with the newly created branch immediately.
+
+@subsection occt_gitguide_4_4 Branch switching
+
+  If you need to switch to another branch, use Git command checkout for that.
+  In the console:
+
+~~~~~
+    > git checkout CR12345
+~~~~~
+  
+  In TortoiseGit: right-click, TortoiseGit -> Checkout/switch
+@image html OCCT_GitGuide_V2_image013.png
+@image latex OCCT_GitGuide_V2_image013.png
+
+  Note that in order to work with the branch locally you need to set option 
+  “Create new branch” when you checkout the branch from the remote repository for the first time. 
+  Option “Track” stores association between the local branch and the original branch in a remote repository.
+
+@subsection occt_gitguide_4_5 Committing branch changes
+
+  Commit your changes locally as soon as a stable status of the work is reached. 
+  Make sure to review carefully the committed changes beforehand to avoid unintentional commit of a wrong code. 
+  
+  * In the console:
+  
+~~~~~
+    > git diff
+    …
+    > git commit -a -m "Write meaningful commit message here"
+~~~~~
+
+  Option –a tells the command to automatically include (stage) files 
+  that have been modified or deleted, but it will omit the new files that might have been added by you. 
+  To commit such new files, you must add (stage) them before commit command.
+
+  To find new unstaged files and them to commit, use commands:
+
+~~~~~
+    > git status -s
+      ?? file1.hxx 
+      ?? file2.cxx
+    > git add file1.hxx file2.cxx
+~~~~~
+
+  * In TortoiseGit: right-click, choose “Git Commit -> CR…”:
+@image html OCCT_GitGuide_V2_image014.png
+@image latex OCCT_GitGuide_V2_image014.png
+
+  Unstaged files will be shown if you check the option ‘Show Unversioned Files’. 
+  Double-clock on each modified file to see the changes to be committed (as a difference vs. the base version). 
+
+@subsection occt_gitguide_4_6 Pushing branch to the remote repository
+
+  When the code developed in your local branch is ready for review, 
+  or you need to share it with others, push your local changes to the remote repository.
+  
+  * In the console:
+
+~~~~~  
+    > git push "origin" CR12345:CR12345
+~~~~~
+
+  * In TortoiseGit: right-click, TortoiseGit -> Push
+
+@image html OCCT_GitGuide_V2_image015.png
+@image latex OCCT_GitGuide_V2_image015.png
+
+Note that Git will forbid pushing a branch if the corresponding remote branch already exists and has some changes, which are not in the history of your local branch. This may happen in different situations:
+  * You have amended the last commit which is already in the remote repository. 
+   If you are sure that nobody else uses your branch, push again with ‘force’ option. 
+  * You have rebased your branch, so that now it is completely different 
+   from the branch in the remote repository. In this case, push it under a different name (add a suffix): 
+@image html OCCT_GitGuide_V2_image016.png
+@image latex OCCT_GitGuide_V2_image016.png
+
+  Then remove the original remote branch so that other people recognize that it has been replaced by the new one. For that, select TortoiseGit -> Push again, then select an empty line for your local branch name, 
+  and enter the name of the branch to be removed in ‘Remote’ field:
+
+@image html OCCT_GitGuide_V2_image017.png
+@image latex OCCT_GitGuide_V2_image017.png
+
+  * The other developer has committed some changes in the remote branch. 
+   In this case, pull changes from the remote repository to have them merged 
+   with your version, and push your branch after it is successfully merged.
+
+@subsection occt_gitguide_4_7 Synchronizing with remote repository
+
+  Maintain your repository synchronized with the remote one and clean unnecessary stuff regularly.
+  Use Git command fetch with option prune to get update of all branches 
+  from the remote repository and to clean your local repository from the remote branches that have been deleted.
+  
+  * In the console:
+
+~~~~~  
+    > git fetch --prune 
+~~~~~
+    
+  * In TortoiseGit:
+  
+@image html OCCT_GitGuide_V2_image018.png
+@image latex OCCT_GitGuide_V2_image018.png
+
+  If some changes have been made to the branch you are working with in the remote repository, 
+  use Git command pull to get the remote changes and merge them with your local branch. 
+  This operation is required in particular to update your local master branch when the remote master changes.
+  
+  * In console:
+~~~~~  
+    > git pull
+~~~~~    
+  * In TortoiseGit:
+
+@image html OCCT_GitGuide_V2_image019.png
+@image latex OCCT_GitGuide_V2_image019.png
+
+  Note that the local branches of your repository are the primary place 
+  where your changes are stored until they get integrated to the official version 
+  of OCCT (master branch). The branches submitted to official repository 
+  are for collaborative work, review, and integration; 
+  that repository should not be used for long-term storage of incomplete changes. 
+  
+Remove the local branches that you do not need any more. Note that you cannot delete the current branch, thus you need to switch to another one (e.g. master) if the branch you are going to delete is the current one.
+  
+  * In the console:
+~~~~~ 
+    > git branch -d CR12345
+~~~~~
+    
+  * In TortoiseGit: right-click, select TortoiseGit -> Show log
+
+@image html OCCT_GitGuide_V2_image020.png
+@image latex OCCT_GitGuide_V2_image020.png
+
+  Select “All branches” to view all branches.
+  Right-click on the branch you want to delete and select Delete… menu item corresponding to this branch. 
+  Note that the log view in TortoiseGit is a convenient tool 
+  to visualize and manage branches; it provides short-cuts to many functions described above.
+
+@subsection occt_gitguide_4_8 Applying a fix made on older version of OCCT
+
+  If you have a fix made on a previous version of OCCT, 
+  perform the following sequence of operations to prepare it 
+  for testing and integration to the current development version.
+
+  * Identify the version of OCCT on which the fix has been made. 
+   In most cases, this will be an OCCT release, e.g. OCCT 6.7.0.; 
+   then just find a tag or a commit corresponding to this version in the Git history log of the master branch.
+  * Create a branch basing on this tag or commit. In TortoiseGit history log: right-click on the base commit, then select **Create branch at this version**.
+  
+@image html OCCT_GitGuide_V2_image021.png
+@image latex OCCT_GitGuide_V2_image021.png
+
+  Check option **Switch to the new branch** to start working within the new branch immediately, or switch to it separately afterwards.
+
+  * Put your fix in the working copy, build and check that it works, then commit to the branch.
+  * Rebase the branch on the current master.
+  
+  In TortoiseGit: right-click on the working directory, 
+  then choose TortoiseGit->Rebase; then select *remotes/origin/master* as UpStream revision, and click **Start**:
+@image html OCCT_GitGuide_V2_image022.png
+@image latex OCCT_GitGuide_V2_image022.png
+
+  Note that you can get some conflicts during rebase. 
+  To resolve the conflicts double-click on each conflicted file 
+  (highlighted by red in the file list) to open visual merge tool. 
+  Switch between conflicting fragments by red arrows, and for each one 
+  decide if the code of one or both conflicting versions is to be taken. 
+  Use the toolbar.
+
+@subsection occt_gitguide_4_9 Rebasing with history clean-up
+
+  At some moments you might need to rebase your branch on the latest version of the master. 
+  
+  We recommend rebasing before the first submission of the branch 
+  for review or when the master has diverged substantially from your branch. 
+  
+  Rebasing is a good occasion to clean-up the history of commits in the branch. 
+  Consider collapsing (squashing, in terms of Git) the history of your branch 
+  into a single commit unless you deem that having separate commits is important 
+  for your future work with the branch or its code reviewing. 
+  Git also allows you to change the order of commits, edit commit contents and messages, etc. 
+  
+  Here is the sequence of actions to rebase your branch into a single commit:
+  
+  * Switch to your branch (e.g. “CR12345”)
+  * In TortoiseGit history log, select a branch to rebase on (usually remotes/origin/master) 
+   and in the context menu choose **Rebase “CR12345” onto this**.
+  * In the Rebase dialog, check **Squash All**.
+
+@image html OCCT_GitGuide_V2_image023.png
+@image latex OCCT_GitGuide_V2_image023.png
+
+  **Note** that you can also change the order of commits and define for each commit 
+  whether it should be kept (“pick”), edited, or just skipped.
+  
+  * Click **Start**.
+  * The process will stop if a conflict is detected. 
+   In such case, find files with status ‘Conflicted’ in the list (marked by red), 
+   and double-click on them to resolve the conflict. 
+   When all conflicts are resolved, click ‘Continue’.
+   
+@image html OCCT_GitGuide_V2_image024.png
+@image latex OCCT_GitGuide_V2_image024.png
+  * At the end of the process, edit the final commit message (it should start from the issue ID and  a description from Mantis in the first line, followed by a summary of actual changes), and click **Commit**.
+   
+@image html OCCT_GitGuide_V2_image025.png
+@image latex OCCT_GitGuide_V2_image025.png
+
+@section occt_gitguide_5 Work with repository: Reviewer operations
+
+@subsection occt_gitguide_5_1 Review branch changes using GitWeb
+
+  The changes made in the branch can be reviewed without direct access to Git, using GitWeb interface:
+
+  * Open GitWeb in your web browser: http://git.dev.opencascade.org/gitweb/?p=occt.git 
+  * Locate the branch you want to review among heads (click ‘…’ at the bottom of the page to see the full list).
+  * Click log (or shortlog) to see the history of the branch. 
+    
+  **Note** that the branch can contain more than one commit, and you need to distinguish commits 
+  that belong to that branch (those to be reviewed) from the commits 
+  corresponding to the previous state of the master branch. 
+  Normally the first commit in the list that starts from the ID 
+  of the other issue indicates the branching point; 
+  commits above it are the ones to be reviewed.
+  
+  * Click *commitdiff* on each log entry to review the changes (highlighted with color format).
+
+@subsection occt_gitguide_5_2 Review branch changes with TortoiseGit 
+
+  Use of TortoiseGit is recommended for convenient code review:
+
+  * Fetch the changes from the remote repository as described in 4.7;
+  * Right-click on the repository, choose TortoiseGit -> Show log;
+  * Locate the remote branch you need to review;
+  * To review commits one-by-one, select each commit in the log. 
+   The list of changed files is shown at the bottom of the window; 
+   double-click on the file will open visual compare tool.
+  * To review all changes made in the branch at once, or to compare 
+   two arbitrary revisions, select the corresponding commits in the log 
+   (e.g. the last commit in the branch and the branching point), 
+   right-click for the context menu, and choose **Compare revisions**.
+
+@image html OCCT_GitGuide_V2_image026.png
+@image latex OCCT_GitGuide_V2_image026.png
+
diff --git a/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image001.png b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image001.png
new file mode 100644 (file)
index 0000000..8152cc9
Binary files /dev/null and b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image001.png differ
diff --git a/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image002.png b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image002.png
new file mode 100644 (file)
index 0000000..33894e2
Binary files /dev/null and b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image002.png differ
diff --git a/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image003.png b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image003.png
new file mode 100644 (file)
index 0000000..ab44c52
Binary files /dev/null and b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image003.png differ
diff --git a/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image004.png b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image004.png
new file mode 100644 (file)
index 0000000..7c13d47
Binary files /dev/null and b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image004.png differ
diff --git a/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image005.png b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image005.png
new file mode 100644 (file)
index 0000000..c570456
Binary files /dev/null and b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image005.png differ
diff --git a/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image006.png b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image006.png
new file mode 100644 (file)
index 0000000..953143c
Binary files /dev/null and b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image006.png differ
diff --git a/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image007.png b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image007.png
new file mode 100644 (file)
index 0000000..9ed5e9d
Binary files /dev/null and b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image007.png differ
diff --git a/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image008.png b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image008.png
new file mode 100644 (file)
index 0000000..c5c73e5
Binary files /dev/null and b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image008.png differ
diff --git a/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image009.png b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image009.png
new file mode 100644 (file)
index 0000000..6ad161e
Binary files /dev/null and b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image009.png differ
diff --git a/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image010.png b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image010.png
new file mode 100644 (file)
index 0000000..277eebc
Binary files /dev/null and b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image010.png differ
diff --git a/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image011.png b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image011.png
new file mode 100644 (file)
index 0000000..41cf51c
Binary files /dev/null and b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image011.png differ
diff --git a/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image012.png b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image012.png
new file mode 100644 (file)
index 0000000..438f752
Binary files /dev/null and b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image012.png differ
diff --git a/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image013.png b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image013.png
new file mode 100644 (file)
index 0000000..7de58e7
Binary files /dev/null and b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image013.png differ
diff --git a/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image014.png b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image014.png
new file mode 100644 (file)
index 0000000..9f0c119
Binary files /dev/null and b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image014.png differ
diff --git a/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image015.png b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image015.png
new file mode 100644 (file)
index 0000000..3d634ae
Binary files /dev/null and b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image015.png differ
diff --git a/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image016.png b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image016.png
new file mode 100644 (file)
index 0000000..8a4d8d6
Binary files /dev/null and b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image016.png differ
diff --git a/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image017.png b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image017.png
new file mode 100644 (file)
index 0000000..6dbeea8
Binary files /dev/null and b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image017.png differ
diff --git a/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image018.png b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image018.png
new file mode 100644 (file)
index 0000000..ebc5d7f
Binary files /dev/null and b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image018.png differ
diff --git a/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image019.png b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image019.png
new file mode 100644 (file)
index 0000000..0fba94f
Binary files /dev/null and b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image019.png differ
diff --git a/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image020.png b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image020.png
new file mode 100644 (file)
index 0000000..02cf386
Binary files /dev/null and b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image020.png differ
diff --git a/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image021.png b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image021.png
new file mode 100644 (file)
index 0000000..078be9b
Binary files /dev/null and b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image021.png differ
diff --git a/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image022.png b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image022.png
new file mode 100644 (file)
index 0000000..0f2993a
Binary files /dev/null and b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image022.png differ
diff --git a/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image023.png b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image023.png
new file mode 100644 (file)
index 0000000..47c3532
Binary files /dev/null and b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image023.png differ
diff --git a/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image024.png b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image024.png
new file mode 100644 (file)
index 0000000..976e0ae
Binary files /dev/null and b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image024.png differ
diff --git a/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image025.png b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image025.png
new file mode 100644 (file)
index 0000000..06ab464
Binary files /dev/null and b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image025.png differ
diff --git a/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image026.png b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image026.png
new file mode 100644 (file)
index 0000000..1ff0963
Binary files /dev/null and b/dox/dev_guides/git_guide/images/OCCT_GitGuide_V2_image026.png differ
index d730f88..02313c8 100644 (file)
@@ -456,17 +456,17 @@ Remarks:
 
 **On Linux:**
 
-1. If OCCT was built by Code::Blocks   * use $CASROOT/draw_cbp.sh file to launch DRAWEXE executable;
-2. If OCCT was built by Automake    * use $CASROOT/draw_amk.sh file to launch DRAWEXE executable;
+1. If OCCT was built by Code::Blocks  use <i>$CASROOT/draw_cbp.sh</i> file to launch *DRAWEXE* executable;
+2. If OCCT was built by Automake    use <i>$CASROOT/draw_amk.sh</i> file to launch *DRAWEXE* executable;
 
 Draw[1]> prompt appears in the command window
 
-Type pload ALL
+Type *pload ALL*
 
 **On Windows:**
 
 Launch Draw executable from Open CASCADE Technology\\Test Harness\\Draw Test Harness 
-item of the Start\\Programs menu or Use $CASROOT\\draw.bat file to launch DRAWEXE executable.
+item of the Start\\Programs menu or Use <i>$CASROOT\\draw.bat</i> file to launch *DRAWEXE* executable.
 
 Draw[1]> prompt appears in the command window
 
@@ -474,36 +474,33 @@ Type pload ALL
 
 **Creating your first geometric objects**
 
-1. In the command window, type axo to create an axonometric view
-2. Type box b -10 -10 -10 20 20 20 to create a cube b of size 20, 
-   parallel to the X Y Z axis and centered on the origin. 
-   The cube will be displayed in the axonometric view in wireframe mode
-3. Type fit to fill the viewer with the cube
-4. Type pcylinder c 2 30 to create a cylinder c of radius 2 and height 30.
-   The cylinder will be displayed in addition to the cube
+1. In the command window, type *axo* to create an axonometric view
+2. Type *box b -10 -10 -10 20 20 20* to create a cube *b* of size 20, parallel to the X Y Z axis and centered on the origin. The cube will be displayed in the axonometric view in wireframe mode.
+3. Type *fit* to fill the viewer with the cube
+4. Type *pcylinder c 2 30* to create a cylinder *c* of radius 2 and height 30. The cylinder will be displayed in addition to the cube
 
 **Manipulating the view**
 
-1. Type clear to erase the view
-2. Type donly c to display the cylinder only
-3. Type donly b to display the cube only
-4. Type hlr hlr b to display the cube in the hidden line removal mode
+1. Type *clear* to erase the view
+2. Type *donly c* to display the cylinder only
+3. Type *donly b* to display the cube only
+4. Type *hlr hlr b* to display the cube in the hidden line removal mode
 
 **Running demonstration files**
 
-1. Type cd ../.. to return to the root directory
-2. Type cd src/DrawResources to reach the DrawResources directory
-3. Type source "Available Demo File" to run the demonstration provided with Open CASCADE
-4. The following demonstration files are available:
+1. Type *cd ../..* to return to the root directory
+2. Type *cd samples/tcl* to reach the *DrawResources* directory
+3. Type *source <demo_file>* to run the demonstration file provided with Open CASCADE. The following demonstration files are available:
+  * bottle.tcl
+  * challenge.tcl  
   * DataExchangeDemo.tcl
   * ModelingDemo.tcl
-  * OCAFDemo.tcl
   * VisualizationDemo.tcl
 
 **Getting Help**
 
-1. Type help to see all available commands
-2. Type help command-name to find out the arguments for a given command
+1. Type *help* to see all available commands
+2. Type *help <command_name>* to find out the arguments for a given command
 
 @subsection OCCT_OVW_SECTION_7_3 Programming Samples
 
diff --git a/dox/user_guides/brep_wp/brep_wp.md b/dox/user_guides/brep_wp/brep_wp.md
new file mode 100644 (file)
index 0000000..13404b0
--- /dev/null
@@ -0,0 +1,2221 @@
+ BRep Format Description  {#occt_brep_format}
+========================
+
+@tableofcontents 
+
+@section occt_brep_format_1 Introduction
+
+  BREP format is used to store 3D models and allows to store a model which consists 
+  of vertices, edges, wires, faces, shells, solids,  compsolids, compounds, edge triangulations, 
+  face triangulations, polylines on  triangulations, space location and orientation. 
+  Any set of such models may be  stored as a single model which is a compound of the models.  
+   
+  The format is described in an order which is convenient for understanding 
+  rather than in the order the format parts follow each other. 
+  BNF-like definitions are used in this document. 
+  Most of the chapters contain BREP format descriptions in the following order:  
+  
+  * format file fragment to illustrate the part;  
+  * BNF-like definition of the part;  
+  * detailed description of the part.  
+@section occt_brep_format_2 Format Common Structure
+  ASCII encoding is used to read/write BREP format from/to  file. The format data are stored in a file as text data.  
+   
+  BREP format uses the following BNF terms:
+
+  * <\n>;  
+  * <_\n>;  
+  * <_>;  
+  * <flag>;  
+  * <int>;  
+  * <real>;  
+  * <2D point>;  
+  * <3D point>;  
+  * <2D direction>;  
+  * <3D direction>;  
+  * <+>;  
+  * \n is the operating-system-dependent ASCII  character sequence which separates ASCII text strings in the operating system used.  
+  * _\n = " "* \n;  
+  * _ = " "+;  
+  * _ is a not empty sequence of space characters  with ASCII code 21h.  
+  * flag = "0" | "1";  
+  * int is an integer number from @image html brep_wp_image003.gif to @image html brep_wp_image004.gif which is written in  denary system.  
+  * real is a real from @image html brep_wp_image005.gif to @image html brep_wp_image006.gif 
+   which is written in decimal  or E form with base 10. 
+   
+  The point is used as a delimiter of the integer and  fractional parts.  
+  * 2D point = real _ real;  
+  * 3D point = real (_ real)  ^ 2;  
+  * 2D direction is a 2D point @image html brep_wp_image007.gif so that @image html brep_wp_image008.gif.  
+  * 3D direction is a 3D point @image html brep_wp_image009.gif so that @image html brep_wp_image010.gif.  
+   + is an arithmetic operation of addition.  
+  The format consists of the following sections:  
+
+  * content type;  
+  * version;  
+  * locations;  
+  * geometry;  
+  * shapes.  
+  content type = "DBRep_DrawableShape" _\n  _\n;  
+  content type have other values [1].  
+  version = ("CASCADE Topology V1, (c)  Matra-Datavision" | "CASCADE Topology V2, (c) Matra-Datavision")  _\n;  
+  
+  The difference of the versions is described in the  document.  
+  Sections <locations>, <geometry> and <shapes> are described below in separate chapters of the document.  
+@section occt_brep_format_3 Section locations
+**Example**  
+
+@verbatim 
+    Locations  3  
+    1  
+                   0               0               1               0   
+                   1               0               0               0   
+                   0               1               0               0   
+    1  
+                   1               0               0               4   
+                   0               1               0               5   
+                   0               0               1               6   
+    2   1 1 2 1 0  
+@endverbatim
+**BNF-like Definition**
+
+@verbatim
+    locations = location header _\n  location records;  
+    location header = "Locations" _  location record count;  
+    location record count = int;  
+    location records = location record ^  location record count;  
+    location record = location record 1 |  location record 2;  
+    location record 1 = "1" _\n location  data 1;  
+    location record 2 = "2" _ location  data 2;  
+    location data 1 = ((_ real) ^ 4  _\n) ^ 3;  
+    location data 2 = (int _  int _)* "0" _\n;  
+@endverbatim
+
+****Description****
+
+*location data 1* is interpreted as a 3 x 4 matrix @image html brep_wp_image011.gif 
+which describes transformation of 3 dimensional space and satisfies the following constraints:  
+  * @image html brep_wp_image012.gif where @image html brep_wp_image013.gif where @image html brep_wp_image014.gif;  
+  * @image html brep_wp_image015.gif where @image html brep_wp_image016.gif.  
+The transformation transforms a point 
+
+@image html brep_wp_image017.gif 
+
+to another point 
+
+@image html brep_wp_image018.gif 
+
+by the rule:
+@image html brep_wp_image019.gif.  
+@image html brep_wp_image020.gif 
+
+may be a composition of matrices for the following elementary transformations:  
+  *  parallel translation – @image html brep_wp_image021.gif;  
+  *  rotation around an axis with a direction @image html brep_wp_image022.gif by an angle @image html brep_wp_image023.gif –  
+@image html brep_wp_image024.gif;  
+  *  scaling –          @image html brep_wp_image025.gif where @image html brep_wp_image026.gif;  
+  *  central symmetry – @image html brep_wp_image027.gif;  
+  *  axis symmetry –    @image html brep_wp_image028.gif;  
+  *  plane symmetry –   @image html brep_wp_image029.gif.  
+*location data 2* is interpreted as a composition of locations raised to a power and placed above this location data 2 in  the section locations. location data 2 is a sequence @image html brep_wp_image030.gif of @image html brep_wp_image031.gif integer pairs @image html brep_wp_image032.gif (@image html brep_wp_image033.gif). flag 0 is the indicator  of the sequence end. The sequence is interpreted as a composition @image html brep_wp_image034.gif where @image html brep_wp_image035.gif is a location from @image html brep_wp_image036.gif-th location  record in the section locations. location record numbering  starts from1.  
+@section occt_brep_format_4 Section geometry
+
+@verbatim
+    geometry =  
+    2D curves  
+    3D curves  
+    3D polygons  
+    polygons on triangulations  
+    surfaces  
+    triangulations;  
+@endverbatim 
+@subsection occt_brep_format_4_1  Subsection 3D curves
+**Example**
+
+@verbatim
+    Curves 13  
+    1 0 0 0 0 0 1   
+    1 0 0 3 -0 1 0   
+    1 0 2 0 0 0 1   
+    1 0 0 0 -0 1 0   
+    1 1 0 0 0 0 1   
+    1 1 0 3 0 1 0   
+    1 1 2 0 0 0 1   
+    1 1 0 0 -0 1 0   
+    1 0 0 0 1 0 -0   
+    1 0 0 3 1 0 -0   
+    1 0 2 0 1 0 -0   
+    1 0 2 3 1 0 -0   
+    1 1 0 0 1 0 0   
+@endverbatim 
+**BNF-like Definition**
+
+@verbatim
+    3D curves = 3D curve header  _\n 3D curve records;  
+     
+    3D curve header = "Curves" _ 3D  curve count;  
+     
+    3D curve count = int;  
+     
+    3D curve records = 3D curve record ^  3D curve count;  
+     
+    3D curve record =  
+    3D curve record 1 |  
+    3D curve record 2 |  
+    3D curve record 3 |  
+    3D curve record 4 |  
+    3D curve record 5 |  
+    3D curve record 6 |  
+    3D curve record 7 |  
+    3D curve record 8 |  
+    3D curve record 9;  
+@subsubsection occt_brep_format_4_1_1 3D curve record 1 – Line
+**Example**  
+
+@verbatim
+    1 1 0 3 0 1 0   
+@endverbatim
+**BNF-like Definition**
+
+@verbatim
+    3D curve record 1 = "1" _ 3D  point _ 3D direction _\n;  
+@endverbatim
+**Description**  
+3D curve record 1 describes a line. The line  data consist of a 3D point @image html brep_wp_image037.gif and a 3D direction @image html brep_wp_image038.gif. The line passes through the  point @image html brep_wp_image037.gif, has  the direction @image html brep_wp_image038.gif and  is defined by the following parametric equation:  
+@image html brep_wp_image039.gif, @image html brep_wp_image040.gif.  
+The **Example** record is interpreted as a line which  passes through a point @image html brep_wp_image041.gif, has a direction @image html brep_wp_image042.gif and is defined by the  following parametric equation: @image html brep_wp_image043.gif.  
+@subsubsection occt_brep_format_4_1_2 3D curve record 2 – Circle
+**Example**  
+
+@verbatim 
+    2 1 2 3 0 0 1 1 0 -0 -0 1 0 4  
+@endverbatim 
+**BNF-like Definition**
+@verbatim
+    3D curve record 2 = "2" _ 3D  circle center _ 3D circle N _ 3D circle Dx _    3D circle Dy _ 3D circle radius _\n;  
+     
+    3D circle center = 3D point;  
+     
+    3D circle N = 3D direction;  
+     
+    3D circle Dx = 3D direction;  
+     
+    3D circle Dy = 3D direction;  
+     
+    3D circle radius = real;  
+@endverbatim 
+**Description**  
+3D curve record 2 describes a circle. The  circle data consist of a 3D point @image html brep_wp_image037.gif, pairwise orthogonal 3D directions @image html brep_wp_image044.gif, @image html brep_wp_image045.gif and @image html brep_wp_image046.gif and a non-negative real @image html brep_wp_image047.gif. The circle has a center  @image html brep_wp_image037.gif and is  located in a plane with a normal @image html brep_wp_image044.gif. The circle has a radius @image html brep_wp_image047.gif and is defined by  the following parametric equation:  
+@image html brep_wp_image048.gif, @image html brep_wp_image049.gif.  
+The  example record is interpreted as a circle which has its center @image html brep_wp_image050.gif, is located in plane  with a normal @image html brep_wp_image051.gif.  Directions for the circle are @image html brep_wp_image052.gif and @image html brep_wp_image053.gif. The circle has a radius @image html brep_wp_image054.gif and is defined by  the following parametric equation: @image html brep_wp_image055.gif.  
+@subsubsection occt_brep_format_4_1_3 3D curve record 3 – Ellipse
+**Example**  
+
+@verbatim
+    3 1 2 3 0 0 1 1 0 -0 -0 1 0 5  4  
+@endverbatim
+**BNF-like Definition**
+
+@verbatim 
+    3D curve record 3 = "3" _ 3D  ellipse center _ 3D ellipse N _ 3D ellipse Dmaj  _ 3D ellipse Dmin _ 3D ellipse Rmaj _  3D ellipse Rmin _\n;  
+     
+    3D ellipse center = 3D point;  
+     
+    3D ellipse N = 3D direction;  
+     
+    3D ellipse Dmaj = 3D direction;  
+     
+    3D ellipse Dmin = 3D direction;  
+     
+    3D ellipse Rmaj = real;  
+     
+    3D ellipse Rmin = real;  
+@endverbatim 
+**Description**  
+3D curve record 3 describes an ellipse. The  ellipse data consist of a 3D point @image html brep_wp_image037.gif, pairwise orthogonal 3D directions @image html brep_wp_image044.gif, @image html brep_wp_image056.gif and @image html brep_wp_image057.gif and non-negative reals @image html brep_wp_image058.gif and @image html brep_wp_image059.gif so that @image html brep_wp_image060.gif. The ellipse has its  center @image html brep_wp_image037.gif, is  located in plane with the normal @image html brep_wp_image044.gif, has major and minor axis directions @image html brep_wp_image056.gif and @image html brep_wp_image057.gif, major and minor  radii @image html brep_wp_image058.gif and @image html brep_wp_image059.gif and is defined by  the following parametric equation:  
+@image html brep_wp_image061.gif, @image html brep_wp_image049.gif.  
+The  example record is interpreted as an ellipse which has its center @image html brep_wp_image050.gif, is located in plane  with a normal @image html brep_wp_image051.gif,  has major and minor axis directions @image html brep_wp_image062.gif and @image html brep_wp_image063.gif, major and minor radii @image html brep_wp_image064.gif and @image html brep_wp_image065.gif and is defined by  the following parametric equation: @image html brep_wp_image066.gif.  
+@subsubsection occt_brep_format_4_1_4 3D curve record 4 – Parabola
+**Example**  
+
+@verbatim 
+    4 1 2 3 0 0 1 1 0 -0 -0 1 0  16  
+@endverbatim 
+**BNF-like Definition**  
+
+@verbatim
+    3D curve record 4 = "4" _ 3D  parabola origin _ 3D parabola N _   3D parabola Dx _ 3D parabola Dy _ 3D  parabola focal length _\n;  
+     
+    3D parabola origin = 3D point;  
+     
+    3D parabola N = 3D direction;  
+     
+    3D parabola Dx = 3D direction;  
+     
+    3D parabola Dy = 3D direction;  
+     
+    3D parabola focal length = real;  
+@endverbatim 
+**Description**  
+3D curve record 4 describes a parabola. The  parabola data consist of a 3D point @image html brep_wp_image037.gif, pairwise orthogonal 3D directions @image html brep_wp_image044.gif, @image html brep_wp_image045.gif and @image html brep_wp_image046.gif and a non-negative real @image html brep_wp_image067.gif. The parabola is  located in plane which passes through the point @image html brep_wp_image037.gif and has the normal @image html brep_wp_image044.gif. The parabola has a focus  length @image html brep_wp_image067.gif and  is defined by the following parametric equation:  
+@image html brep_wp_image068.gif, @image html brep_wp_image069.gif &Uuml; @image html brep_wp_image070.gif;  
+@image html brep_wp_image071.gif, @image html brep_wp_image069.gif &Uuml; @image html brep_wp_image072.gif (degenerated case).  
+The  example record is interpreted as a parabola in plane which passes through a  point @image html brep_wp_image073.gif and  has a normal @image html brep_wp_image074.gif.  Directions for the parabola are @image html brep_wp_image075.gif and @image html brep_wp_image076.gif. The parabola has a focus length @image html brep_wp_image077.gif and is defined by  the following parametric equation: @image html brep_wp_image078.gif.  
+@subsubsection occt_brep_format_4_1_5 3D curve record 5 – Hyperbola
+**Example**  
+
+@verbatim
+    5 1 2 3 0 0 1 1 0 -0 -0 1 0 5  4  
+@verbatim
+**BNF-like Definition**  
+
+@verbatim
+    3D curve record 5 = "5" _ 3D  hyperbola origin _ 3D hyperbola N _   3D hyperbola Dx _ 3D hyperbola Dy _ 3D  hyperbola Kx _ 3D hyperbola Ky _\n;  
+     
+    3D hyperbola origin = 3D point;  
+     
+    3D hyperbola N = 3D direction;  
+     
+    3D hyperbola Dx = 3D direction;  
+     
+    3D hyperbola Dy = 3D direction;  
+     
+    3D hyperbola Kx = real;  
+     
+    3D hyperbola Ky = real;  
+@endverbatim
+Descripton  
+3D curve record 5 describes a hyperbola. The  hyperbola data consist of a 3D point @image html brep_wp_image037.gif, pairwise orthogonal 3D directions @image html brep_wp_image044.gif, @image html brep_wp_image045.gif and @image html brep_wp_image046.gif and non-negative reals @image html brep_wp_image079.gif and @image html brep_wp_image080.gif. The hyperbola is  located in plane which passes through the point @image html brep_wp_image037.gif and has the normal @image html brep_wp_image044.gif. The hyperbola is defined by  the following parametric equation:  
+@image html brep_wp_image081.gif, @image html brep_wp_image069.gif.  
+The  example record is interpreted as a hyperbola in plane which passes through a  point @image html brep_wp_image073.gif and  has a normal @image html brep_wp_image074.gif.  Other hyperbola data are @image html brep_wp_image075.gif, @image html brep_wp_image076.gif, @image html brep_wp_image082.gif and @image html brep_wp_image083.gif. The hyperbola is defined by the  following parametric equation: @image html brep_wp_image084.gif.  
+@subsubsection occt_brep_format_4_1_6 3D curve record 6 – Bezier Curve
+**Example**  
+
+@verbatim
+    6 1 2 0 1 0  4 1 -2 0  5 2 3  0  6   
+@verbatim
+**BNF-like Definition**
+
+@verbatim
+    3D curve record 6 = "6" _ 3D  Bezier rational flag _ 3D Bezier degree   3D Bezier weight poles _\n;  
+     
+    3D Bezier rational flag = flag;  
+     
+    3D Bezier degree = int;  
+     
+    3D Bezier weight poles = (_ 3D  Bezier weight pole) ^ (3D Bezier degree + "1");  
+     
+    3D Bezier weight pole = 3D point  [_ real];  
+@verbatim
+**Description**  
+3D curve record 6 describes a Bezier curve.  The curve data consist of a rational flag @image html brep_wp_image047.gif, a degree @image html brep_wp_image085.gif and weight poles.  
+The weight poles are @image html brep_wp_image086.gif 3D points @image html brep_wp_image087.gif if the flag @image html brep_wp_image047.gif is 0. The weight  poles are @image html brep_wp_image086.gif pairs  @image html brep_wp_image088.gif if flag @image html brep_wp_image047.gif is 1. Here @image html brep_wp_image089.gif is a 3D point and @image html brep_wp_image090.gif is a positive real (@image html brep_wp_image091.gif). @image html brep_wp_image092.gif (@image html brep_wp_image093.gif) if the flag @image html brep_wp_image047.gif is 0.  
+The Bezier curve is defined by the following  parametric equation:  
+@image html brep_wp_image094.gif, @image html brep_wp_image095.gif  
+where @image html brep_wp_image096.gif.  
+The example record is interpreted as a Bezier curve  with a rational flag @image html brep_wp_image097.gif, degree @image html brep_wp_image098.gif and weight poles @image html brep_wp_image099.gif, @image html brep_wp_image100.gif, @image html brep_wp_image101.gif, @image html brep_wp_image102.gif and @image html brep_wp_image103.gif, @image html brep_wp_image104.gif. The Bezier curve is defined  by the following parametric equation:  
+@image html brep_wp_image105.gif.  
+@subsubsection occt_brep_format_4_1_7 3D curve record 7 – B-spline Curve
+**Example**  
+
+@verbatim
+    7 1 0  1 3 5  0 1 0  4 1 -2  0  5 2 3 0  6  
+     0 1 0.25 1 0.5 1 0.75 1 1 1  
+@endverbatim
+**BNF-like Definition**
+
+@verbatim
+    3D curve record 7 = "7" _ 3D  B-spline rational flag _ "0" _ 3D B-spline degree _   3D B-spline pole count _ 3D B-spline multiplicity knot  count 3D B-spline weight poles   _\n 3D B-spline multiplicity knots _\n;  
+     
+    3D B-spline rational flag = flag;  
+     
+    3D B-spline degree = int;  
+     
+    3D B-spline pole count = int;  
+     
+    3D B-spline multiplicity knot count = int;  
+     
+    3D B-spline weight poles = (_ 3D  B-spline weight pole) ^ 3D B-spline pole count;  
+     
+    3D B-spline weight pole = 3D point  [_ real];  
+     
+    3D B-spline multiplicity knots =  
+    (_ 3D B-spline multiplicity knot) ^  3D B-spline multiplicity knot count;  
+     
+    3D B-spline multiplicity knot = real  _ int;  
+@endverbatim
+**Description**  
+3D curve record 7 describes a B-spline curve.  The curve data consist of a rational flag @image html brep_wp_image047.gif, a degree @image html brep_wp_image085.gif, pole count @image html brep_wp_image106.gif, multiplicity knot count @image html brep_wp_image107.gif, weight poles and  multiplicity knots.  
+The weight poles are @image html brep_wp_image108.gif 3D points @image html brep_wp_image109.gif if the flag @image html brep_wp_image047.gif is 0. The weight  poles are @image html brep_wp_image108.gif pairs  @image html brep_wp_image110.gif if the flag  @image html brep_wp_image047.gif is 1. Here @image html brep_wp_image089.gif is a 3D point and @image html brep_wp_image090.gif is a positive real (@image html brep_wp_image111.gif). @image html brep_wp_image092.gif (@image html brep_wp_image111.gif) if the flag @image html brep_wp_image047.gif is 0.  
+The multiplicity knots are @image html brep_wp_image107.gif pairs @image html brep_wp_image112.gif. Here @image html brep_wp_image113.gif is a knot with a multiplicity  @image html brep_wp_image114.gif (@image html brep_wp_image115.gif) so that  
+@image html brep_wp_image116.gif (@image html brep_wp_image117.gif),  
+@image html brep_wp_image118.gif, @image html brep_wp_image119.gif, @image html brep_wp_image120.gif (@image html brep_wp_image121.gif), @image html brep_wp_image122.gif.  
+The B-spline curve is defined by the following  parametric equation:  
+@image html brep_wp_image123.gif, @image html brep_wp_image124.gif  
+where functions @image html brep_wp_image125.gif have the following recursion definition  by @image html brep_wp_image126.gif  
+@image html brep_wp_image127.gif, @image html brep_wp_image128.gif (@image html brep_wp_image129.gif)  
+where  
+@image html brep_wp_image130.gif (@image html brep_wp_image131.gif, @image html brep_wp_image132.gif).  
+The example record is interpreted as a B-spline curve  with a rational flag @image html brep_wp_image097.gif, a degree @image html brep_wp_image133.gif, pole count @image html brep_wp_image134.gif, multiplicity knot count @image html brep_wp_image135.gif, weight poles @image html brep_wp_image136.gif, @image html brep_wp_image137.gif, @image html brep_wp_image138.gif, @image html brep_wp_image139.gif and @image html brep_wp_image140.gif, @image html brep_wp_image141.gif, multiplicity knots @image html brep_wp_image142.gif, @image html brep_wp_image143.gif, @image html brep_wp_image144.gif, @image html brep_wp_image145.gif, @image html brep_wp_image146.gif, @image html brep_wp_image147.gif, @image html brep_wp_image148.gif, @image html brep_wp_image149.gif and @image html brep_wp_image150.gif, @image html brep_wp_image151.gif. The B-spline curve is defined  by the following parametric equation:  
+@image html brep_wp_image152.gif.  
+@subsubsection occt_brep_format_4_1_8 3D curve record 8 – Trimmed Curve
+**Example**  
+
+@verbatim
+    8  4 -5  
+    1 1 2 3 1 0 0   
+@endverbatim
+**BNF-like Definition**  
+
+@verbatim
+    3D curve record 8 = "8" _ 3D  trimmed curve u min _ 3D trimmed curve u max _\n  3D curve record;  
+     
+    3D trimmed curve u min = real;  
+     
+    3D trimmed curve u max = real;  
+@endverbatim
+**Description**  
+3D curve record 8 describes a trimmed curve.  The trimmed curve data consist of reals @image html brep_wp_image153.gif and @image html brep_wp_image154.gif and 3D curve record so that @image html brep_wp_image155.gif. The trimmed curve  is a restriction of the base curve @image html brep_wp_image156.gif described in the record to the segment @image html brep_wp_image157.gif. The trimmed curve is  defined by the following parametric equation:  
+@image html brep_wp_image158.gif, @image html brep_wp_image159.gif.  
+The  example record is interpreted as a trimmed curve with @image html brep_wp_image160.gif and @image html brep_wp_image161.gif for the base curve @image html brep_wp_image162.gif. The trimmed curve is  defined by the following parametric equation: @image html brep_wp_image163.gif, @image html brep_wp_image164.gif.  
+@subsubsection occt_brep_format_4_1_9 3D curve record 9 – Offset Curve
+**Example**  
+
+@verbatim
+    9 2  
+    0 1 0   
+    1 1 2 3 1 0 0   
+@endverbatim
+**BNF-like Definition**  
+
+@verbatim
+    3D  curve record 9 = "9" _ 3D offset curve distance _\n  
+    3D  offset curve direction _\n  
+    3D  curve record;  
+     
+    3D  offset curve distance = real;  
+     
+    3D  offset curve direction = 3D direction;  
+@endverbatim
+**Description**  
+3D  curve record 9 describes an offset curve. The offset curve data consist of a  distance @image html brep_wp_image165.gif, a  3D direction @image html brep_wp_image038.gif and  a 3D curve record. The offset curve is the result of offsetting the base  curve @image html brep_wp_image156.gif described  in the record to the distance @image html brep_wp_image165.gif along the vector @image html brep_wp_image166.gif. The offset curve is defined  by the following parametric equation:  
+@image html brep_wp_image167.gif, @image html brep_wp_image168.gif.  
+The  example record is interpreted as an offset curve with a distance @image html brep_wp_image169.gif, direction @image html brep_wp_image170.gif, base curve @image html brep_wp_image162.gif and defined by the  following parametric equation: @image html brep_wp_image171.gif.  
+@subsection occt_brep_format_4_2  Subsection surfaces
+**Example**  
+
+@verbatim
+    Surfaces 6  
+    1 0 0 0 1 0 -0 0 0 1 0 -1 0   
+    1 0 0 0 -0 1 0 0 0 1 1 0 -0   
+    1 0 0 3 0 0 1 1 0 -0 -0 1 0   
+    1 0 2 0 -0 1 0 0 0 1 1 0 -0   
+    1 0 0 0 0 0 1 1 0 -0 -0 1 0   
+    1 1 0 0 1 0 -0 0 0 1 0 -1 0   
+@endverbatim
+**BNF-like Definition**  
+
+@verbatim
+    surfaces = surface header _\n  surface records;  
+     
+    surface header = "Surfaces" _  surface count;  
+     
+    surface records = surface record ^  surface count;  
+     
+    surface record =  
+    surface record 1 |  
+    surface record 2 |  
+    surface record 3 |  
+    surface record 4 |  
+    surface record 5 |  
+    surface record 6 |  
+    surface record 7 |  
+    surface record 8 |  
+    surface record 9 |  
+    surface record 10 |  
+    surface record 11;  
+@verbatim
+@subsubsection occt_brep_format_4_2_1 surface record 1 – Plane
+**Example**  
+
+@verbatim
+    1 0 0 3 0 0 1 1 0 -0 -0 1 0   
+@endverbatim
+**BNF-like Definition**
+
+@verbatim
+surface record 1 = "1" _ 3D  point (_ 3D direction) ^ 3 _\n;  
+@endverbatim
+**Description**  
+surface record 1 describes a plane. The plane  data consist of a 3D point @image html brep_wp_image037.gif and pairwise orthogonal 3D directions @image html brep_wp_image044.gif, @image html brep_wp_image172.gif and @image html brep_wp_image173.gif. The plane passes through the  point @image html brep_wp_image037.gif, has  the normal @image html brep_wp_image174.gif and  is defined by the following parametric equation:  
+@image html brep_wp_image175.gif, @image html brep_wp_image176.gif.  
+The example record is interpreted as a plane which  passes through a point @image html brep_wp_image177.gif, has a normal @image html brep_wp_image074.gif and is defined by the  following parametric equation: @image html brep_wp_image178.gif.  
+@subsubsection occt_brep_format_4_2_2 surface record 2 – Cylinder
+**Example**  
+
+@verbatim
+    2 1 2 3 0 0 1 1 0 -0 -0 1 0 4  
+@endverbatim
+**BNF-like Definition**  
+
+@verbatim
+    surface record 2 = "2" _ 3D  point (_ 3D direction) ^ 3 _ real  _\n;  
+@endverbatim
+**Description**  
+surface record 2 describes a cylinder. The  cylinder data consist of a 3D point @image html brep_wp_image037.gif, pairwise orthogonal 3D directions @image html brep_wp_image173.gif, @image html brep_wp_image045.gif and @image html brep_wp_image046.gif and a non-negative real @image html brep_wp_image047.gif. The cylinder axis  passes through the point @image html brep_wp_image037.gif and has the direction @image html brep_wp_image173.gif. The cylinder has  the radius @image html brep_wp_image179.gif and  is defined by the following parametric equation:  
+@image html brep_wp_image180.gif, @image html brep_wp_image181.gif.  
+The  example record is interpreted as a cylinder which axis passes through a point @image html brep_wp_image073.gif and has a direction @image html brep_wp_image182.gif. Directions for the  cylinder are @image html brep_wp_image075.gif and  @image html brep_wp_image076.gif. The  cylinder has a radius @image html brep_wp_image054.gif and is defined by the following  parametric equation: @image html brep_wp_image183.gif.  
+@subsubsection occt_brep_format_4_2_3 surface record 3 – Cone
+**Example**  
+
+@verbatim
+    3 1 2 3 0 0 1 1 0 -0 -0 1 0 4  
+    0.75
+@endverbatim
+**BNF-like Definition**
+
+@verbatim
+    surface record 3 = "3" _ 3D  point (_ 3D direction) ^ 3 (_ real) ^ 2  _\n;  
+@endverbatim
+**Description**  
+surface record 3 describes a cone. The cone  data consist of a 3D point @image html brep_wp_image037.gif, pairwise orthogonal 3D directions @image html brep_wp_image184.gif, @image html brep_wp_image045.gif and @image html brep_wp_image046.gif, a non-negative real @image html brep_wp_image047.gif and a real @image html brep_wp_image185.gif. The cone axis passes  through the point @image html brep_wp_image037.gif and  has the direction @image html brep_wp_image184.gif.  The plane which passes through the point @image html brep_wp_image037.gif and is parallel to directions @image html brep_wp_image045.gif and @image html brep_wp_image046.gif is the cone referenced  plane. The cone section by the plane is a circle with the radius @image html brep_wp_image047.gif. The direction from  the point @image html brep_wp_image037.gif to  the cone apex is @image html brep_wp_image186.gif.  The cone has a half-angle @image html brep_wp_image187.gif and is defined by the following  parametric equation:  
+@image html brep_wp_image188.gif, @image html brep_wp_image189.gif.  
+The example record is interpreted as a cone with an axis  which passes through a point @image html brep_wp_image073.gif and has a direction @image html brep_wp_image190.gif. Other cone data are @image html brep_wp_image075.gif, @image html brep_wp_image076.gif, @image html brep_wp_image191.gif and @image html brep_wp_image192.gif. The cone is defined by the  following parametric equation:  
+@image html brep_wp_image193.gif.  
+@subsubsection occt_brep_format_4_2_4 surface record 4 – Sphere
+**Example**  
+
+@verbatim
+    4 1 2 3 0 0 1 1 0 -0 -0 1 0 4  
+@endverbatim
+**BNF-like Definition**
+
+@verbatim
+    surface record 4 = "4" _ 3D  point (_ 3D direction) ^ 3 _ real  _\n;  
+@endverbatim
+**Description**  
+surface record 4 describes a sphere. The  sphere data consist of a 3D point @image html brep_wp_image037.gif, pairwise orthogonal 3D directions @image html brep_wp_image184.gif, @image html brep_wp_image045.gif and @image html brep_wp_image046.gif and a non-negative real @image html brep_wp_image047.gif. The sphere has the  center @image html brep_wp_image194.gif,  radius @image html brep_wp_image179.gif and  is defined by the following parametric equation:  
+@image html brep_wp_image195.gif, @image html brep_wp_image196.gif.  
+The  example record is interpreted as a sphere with its center @image html brep_wp_image073.gif. Directions for the sphere are  @image html brep_wp_image190.gif, @image html brep_wp_image075.gif and @image html brep_wp_image076.gif. The sphere has a radius  @image html brep_wp_image191.gif and is  defined by the following parametric equation:  
+@image html brep_wp_image197.gif.  
+@subsubsection occt_brep_format_4_2_5 surface record 5 – Torus
+**Example**  
+
+@verbatim
+    5 1 2 3 0 0 1 1 0 -0 -0 1 0 8  4  
+@endverbatim
+**BNF-like Definition**
+
+@verbatim
+    surface record 5 = "5" _ 3D  point (_ 3D direction) ^ 3 (_ real) ^ 2  _\n;  
+@endverbatim
+**Description**  
+surface record 5 describes a torus. The torus  data consist of a 3D point @image html brep_wp_image037.gif, pairwise orthogonal 3D directions @image html brep_wp_image184.gif, @image html brep_wp_image045.gif and @image html brep_wp_image046.gif and non-negative reals @image html brep_wp_image198.gif and @image html brep_wp_image199.gif. The torus axis  passes through the point @image html brep_wp_image037.gif and has the direction @image html brep_wp_image184.gif. @image html brep_wp_image198.gif is the distance from the  torus circle center to the axis. The torus circle has the radius @image html brep_wp_image199.gif. The torus is defined  by the following parametric equation:  
+@image html brep_wp_image200.gif, @image html brep_wp_image201.gif.  
+The example record is interpreted as a torus with an axis  which passes through a point @image html brep_wp_image073.gif and has a direction @image html brep_wp_image190.gif. @image html brep_wp_image075.gif, @image html brep_wp_image076.gif, @image html brep_wp_image202.gif and @image html brep_wp_image203.gif for the torus. The torus is defined  by the following parametric equation:  
+@image html brep_wp_image204.gif.  
+@subsubsection occt_brep_format_4_2_6 surface record 6 – Linear Extrusion
+**Example**  
+
+@verbatim
+    6 0 0.6 0.8   
+    2 1 2 3 0 0 1 1 0 -0 -0 1 0 4  
+@endverbatim
+**BNF-like Definition**
+
+@verbatim
+    surface record 6 = "6" _ 3D  direction _\n 3D curve record;  
+@endverbatim
+**Description**  
+surface record 6 describes a linear extrusion  surface. The surface data consist of a 3D direction @image html brep_wp_image173.gif and a 3D curve  record. The linear extrusion surface has the direction @image html brep_wp_image173.gif, the base curve @image html brep_wp_image205.gif described in the  record and is defined by the following parametric equation:  
+@image html brep_wp_image206.gif, @image html brep_wp_image207.gif.  
+The example record is interpreted as a linear  extrusion surface with a direction @image html brep_wp_image208.gif. The base curve is a circle for the  surface. The surface is defined by the following parametric equation: @image html brep_wp_image209.gif, @image html brep_wp_image189.gif.  
+@subsubsection occt_brep_format_4_2_7 surface record 7 – Revolution Surface
+**Example**  
+
+@verbatim
+    7 -4 0 3 0 1 0   
+    2 1 2 3 0 0 1 1 0 -0 -0 1 0 4  
+@endverbatim
+**BNF-like Definition**
+
+@verbatim
+    surface record 7 = "7" _ 3D  point _ 3D direction _\n 3D curve record;  
+@endverbatim
+**Description**  
+surface record 7 describes a revolution  surface. The surface data consist of a 3D point @image html brep_wp_image037.gif, a 3D direction @image html brep_wp_image038.gif and a 3D curve  record. The surface axis passes through the point @image html brep_wp_image037.gif and has the direction @image html brep_wp_image038.gif. The base curve @image html brep_wp_image210.gif described by the  record and the axis are coplanar. The surface is defined by the following  parametric equation:  
+@image html brep_wp_image211.gif, @image html brep_wp_image212.gif  
+where @image html brep_wp_image213.gif, @image html brep_wp_image214.gif.  
+The example record is interpreted as a revolution  surface with an axis which passes through a point @image html brep_wp_image215.gif and has a direction @image html brep_wp_image170.gif. The base curve is a circle  for the surface. The surface is defined by the following parametric equation:  
+@image html brep_wp_image216.gif, @image html brep_wp_image201.gif where @image html brep_wp_image217.gif, @image html brep_wp_image218.gif.  
+@subsubsection occt_brep_format_4_2_8 surface record 8 – Bezier Surface
+**Example**  
+
+@verbatim
+    8 1 1 2 1 0 0 1  7 1 0 -4  10    
+    0 1 -2  8 1 1 5  11   
+    0 2 3  9 1 2 6  12   
+@endverbatim
+**BNF-like Definition**
+
+@verbatim
+    surface record 8 = "8" _ Bezier  surface u rational flag _ Bezier surface v rational flag  _ Bezier surface u degree _ Bezier surface v  degree _   Bezier surface weight poles;  
+     
+    Bezier surface u rational flag = flag;  
+     
+    Bezier surface v rational flag = flag;  
+     
+    Bezier surface u degree = int;  
+     
+    Bezier surface v degree = int;  
+     
+    Bezier surface weight poles =  
+    (Bezier surface weight pole group _\n)  ^ (Bezier surface u degree + "1");  
+     
+    Bezier surface weight pole group = Bezier  surface weight pole  
+    (_ Bezier surface weight pole) ^  Bezier surface v degree;  
+     
+    Bezier surface weight pole = 3D point  [_ real];  
+    @endverbatim
+**Description**  
+surface record 8 describes a Bezier surface.  The surface data consist of a u rational flag @image html brep_wp_image219.gif, v rational flag @image html brep_wp_image220.gif, u degree @image html brep_wp_image221.gif, v degree @image html brep_wp_image222.gif and weight poles.  
+The weight poles are @image html brep_wp_image223.gif 3D points @image html brep_wp_image224.gif (@image html brep_wp_image225.gif) if @image html brep_wp_image226.gif. The weight poles are @image html brep_wp_image223.gif pairs @image html brep_wp_image227.gif (@image html brep_wp_image225.gif) if @image html brep_wp_image228.gif. Here @image html brep_wp_image224.gif is a 3D point and @image html brep_wp_image229.gif is a positive real (@image html brep_wp_image225.gif). @image html brep_wp_image230.gif (@image html brep_wp_image225.gif) if @image html brep_wp_image226.gif.  
+The Bezier surface is defined by the following  parametric equation:  
+@image html brep_wp_image231.gif, @image html brep_wp_image232.gif  
+where @image html brep_wp_image096.gif.  
+The example record is interpreted as a Bezier surface  with a u rational flag @image html brep_wp_image233.gif, v rational flag @image html brep_wp_image234.gif, u degree @image html brep_wp_image235.gif, v degree @image html brep_wp_image236.gif, weight poles @image html brep_wp_image237.gif, @image html brep_wp_image238.gif, @image html brep_wp_image239.gif, @image html brep_wp_image240.gif, @image html brep_wp_image241.gif, @image html brep_wp_image242.gif, @image html brep_wp_image243.gif, @image html brep_wp_image244.gif, @image html brep_wp_image245.gif, @image html brep_wp_image246.gif and @image html brep_wp_image247.gif, @image html brep_wp_image248.gif. The surface is defined by  the following parametric equation:  
+@image html brep_wp_image249.gif  
+@subsubsection occt_brep_format_4_2_9 surface record 9 – B-spline Surface
+**Example**  
+
+@verbatim
+    9  1 1 0 0 1 1 3 2 5 4 0 0 1  7 1 0 -4  10   
+    0  1 -2  8 1 1 5  11   
+    0  2 3  9 1 2 6  12   
+     
+    0  1  
+    0.25  1  
+    0.5  1  
+    0.75  1  
+    1  1  
+     
+    0  1  
+    0.3  1  
+    0.7  1  
+    1 1  
+@endverbatim
+**BNF-like Definition**
+
+@verbatim
+    surface record 9 = "9" _ B-spline  surface u rational flag _   B-spline surface v rational flag _ "0" _ "0" _  B-spline surface u degree _   B-spline surface v degree _ B-spline surface u pole  count _   B-spline surface v pole count _ B-spline surface u  multiplicity knot count _   B-spline surface v multiplicity knot count _ B-spline  surface weight poles _\n   B-spline surface u multiplicity knots _\n B-spline surface  v multiplicity knots;  
+     
+    B-spline surface u rational flag =  flag;  
+     
+    B-spline surface v rational flag = flag;  
+     
+    B-spline surface u degree = int;  
+     
+    B-spline surface v degree = int;  
+     
+    B-spline surface u pole count = int;  
+     
+    B-spline surface v pole count = int;  
+     
+    B-spline surface u multiplicity knot count =  int;  
+     
+    B-spline surface v multiplicity knot count =  int;  
+     
+    B-spline surface weight poles =  
+    (B-spline surface weight pole group  _\n) ^ B-spline surface u pole count;  
+     
+    B-spline surface weight pole group =  
+    (B-spline surface weight pole _) ^  B-spline surface v pole count;  
+     
+    B-spline surface weight pole = 3D  point [_ real];  
+     
+    B-spline surface u multiplicity knots =  
+    (B-spline surface u multiplicity knot  _\n) ^ B-spline surface u multiplicity knot count;  
+     
+    B-spline surface u multiplicity knot =  real _ int;  
+     
+    B-spline surface v multiplicity knots =  
+    (B-spline surface v multiplicity knot  _\n) ^ B-spline surface v multiplicity knot count;  
+     
+    B-spline surface v multiplicity knot =  real _ int;  
+@endverbatim
+**Description**  
+surface record 9 describes a B-spline surface.  The surface data consist of a u rational flag @image html brep_wp_image219.gif, v rational flag @image html brep_wp_image220.gif, u degree @image html brep_wp_image221.gif, v degree @image html brep_wp_image222.gif, u pole count @image html brep_wp_image250.gif, v pole count @image html brep_wp_image251.gif, u multiplicity knot count @image html brep_wp_image252.gif, v multiplicity knot count @image html brep_wp_image253.gif, weight poles, u multiplicity  knots, v multiplicity knots.  
+The weight poles are @image html brep_wp_image254.gif 3D points @image html brep_wp_image224.gif (@image html brep_wp_image255.gif) if @image html brep_wp_image226.gif. The weight poles are @image html brep_wp_image254.gif pairs @image html brep_wp_image227.gif (@image html brep_wp_image255.gif) if @image html brep_wp_image228.gif. Here @image html brep_wp_image224.gif is a 3D point and @image html brep_wp_image229.gif is a positive real (@image html brep_wp_image255.gif). @image html brep_wp_image230.gif (@image html brep_wp_image255.gif) if @image html brep_wp_image226.gif.  
+The u multiplicity knots are @image html brep_wp_image252.gif pairs @image html brep_wp_image256.gif. Here @image html brep_wp_image113.gif is a knot with multiplicity @image html brep_wp_image114.gif (@image html brep_wp_image257.gif) so that  
+@image html brep_wp_image116.gif (@image html brep_wp_image258.gif),  
+@image html brep_wp_image259.gif, @image html brep_wp_image260.gif, @image html brep_wp_image261.gif (@image html brep_wp_image262.gif), @image html brep_wp_image263.gif.  
+The v multiplicity knots are @image html brep_wp_image253.gif pairs @image html brep_wp_image264.gif. Here @image html brep_wp_image265.gif is a knot with multiplicity @image html brep_wp_image266.gif (@image html brep_wp_image267.gif) so that  
+@image html brep_wp_image268.gif (@image html brep_wp_image269.gif),  
+@image html brep_wp_image270.gif, @image html brep_wp_image271.gif, @image html brep_wp_image272.gif (@image html brep_wp_image273.gif), @image html brep_wp_image274.gif.  
+The B-spline surface is defined by the following  parametric equation:  
+@image html brep_wp_image275.gif, @image html brep_wp_image276.gif  
+where functions @image html brep_wp_image277.gif and @image html brep_wp_image278.gif have the following recursion definition  by @image html brep_wp_image279.gif  
+@image html brep_wp_image127.gif, @image html brep_wp_image128.gif (@image html brep_wp_image280.gif);  
+@image html brep_wp_image281.gif, @image html brep_wp_image282.gif (@image html brep_wp_image283.gif);  
+where  
+@image html brep_wp_image284.gif (@image html brep_wp_image285.gif,@image html brep_wp_image286.gif),  
+@image html brep_wp_image287.gif (@image html brep_wp_image288.gif,@image html brep_wp_image289.gif).  
+The example record is interpreted as a B-spline  surface with a u rational flag @image html brep_wp_image233.gif, v rational flag @image html brep_wp_image234.gif, u degree @image html brep_wp_image290.gif, v degree @image html brep_wp_image236.gif, u pole count @image html brep_wp_image291.gif, v pole count @image html brep_wp_image292.gif, u multiplicity knot count @image html brep_wp_image293.gif, v multiplicity knot count @image html brep_wp_image294.gif, weight poles @image html brep_wp_image295.gif, @image html brep_wp_image296.gif, @image html brep_wp_image297.gif, @image html brep_wp_image298.gif, @image html brep_wp_image299.gif, @image html brep_wp_image300.gif, @image html brep_wp_image301.gif, @image html brep_wp_image302.gif, @image html brep_wp_image303.gif, @image html brep_wp_image304.gif and @image html brep_wp_image305.gif, @image html brep_wp_image306.gif, u multiplicity  knots @image html brep_wp_image142.gif, @image html brep_wp_image143.gif, @image html brep_wp_image144.gif, @image html brep_wp_image145.gif, @image html brep_wp_image146.gif, @image html brep_wp_image147.gif, @image html brep_wp_image148.gif, @image html brep_wp_image149.gif and @image html brep_wp_image150.gif, @image html brep_wp_image151.gif, v multiplicity  knots @image html brep_wp_image307.gif, @image html brep_wp_image308.gif, @image html brep_wp_image309.gif, @image html brep_wp_image310.gif, @image html brep_wp_image311.gif, @image html brep_wp_image312.gif and @image html brep_wp_image313.gif, @image html brep_wp_image314.gif. The B-spline surface is defined  by the following parametric equation:  
+@image html brep_wp_image315.gif  
+@subsubsection occt_brep_format_4_2_10  surface  record 10 – Rectangular Trim Surface
+**Example**  
+
+@verbatim
+    10 -1 2 -3 4  
+    1 1 2 3 0 0 1 1 0 -0 -0 1 0   
+@endverbatim
+**BNF-like Definition**
+
+@verbatim
+    surface record 10 = "10" _ trim  surface u min _ trim surface u max _   trim surface v min _ trim surface v max _\n  surface record;  
+     
+    trim surface u min = real;  
+     
+    trim surface u max = real;  
+     
+    trim surface v min = real;  
+     
+    trim surface v max = real;  
+@verbatim
+**Description**  
+surface record 10 describes a rectangular trim  surface. The surface data consist of reals @image html brep_wp_image153.gif, @image html brep_wp_image154.gif, @image html brep_wp_image316.gif and @image html brep_wp_image317.gif and a surface record so that @image html brep_wp_image155.gif and @image html brep_wp_image318.gif. The rectangular  trim surface is a restriction of the base surface @image html brep_wp_image156.gif described in the record to the set @image html brep_wp_image319.gif. The rectangular  trim surface is defined by the following parametric equation:  
+@image html brep_wp_image320.gif, @image html brep_wp_image321.gif.  
+The example record is interpreted as a rectangular  trim surface to the set @image html brep_wp_image322.gif for the base surface @image html brep_wp_image323.gif. The rectangular  trim surface is defined by the following parametric equation: @image html brep_wp_image324.gif, @image html brep_wp_image325.gif.  
+@subsubsection occt_brep_format_4_2_11 surface record 11 – Offset Surface
+**Example**  
+@verbatim
+    11 -2  
+    1 1 2 3 0 0 1 1 0 -0 -0 1 0   
+@verbatim
+**BNF-like Definition**
+
+@verbatim
+    surface record 11 = "11" _ surface  record distance _\n surface record;  
+    surface record distance = real;  
+@verbatim
+**Description**  
+surface record 11 describes an offset surface.  
+The offset surface data consist of a distance @image html brep_wp_image165.gif and a surface record. The  offset surface is the result of offsetting the base surface @image html brep_wp_image326.gif described in the record to the  distance @image html brep_wp_image165.gif along  the normal @image html brep_wp_image044.gif of  surface @image html brep_wp_image156.gif.  The offset surface is defined by the following parametric equation:  
+@image html brep_wp_image327.gif, @image html brep_wp_image328.gif.  
+@image html brep_wp_image329.gif  
+if @image html brep_wp_image330.gif.  
+The example record is interpreted as an offset surface  with a distance @image html brep_wp_image331.gif and  base surface @image html brep_wp_image323.gif.  The offset surface is defined by the following parametric equation: @image html brep_wp_image332.gif.  
+@subsection occt_brep_format_4_3  Subsection 2D curves
+**Example**  
+
+@verbatim
+    Curve2ds 24  
+    1 0 0 1 0   
+    1 0 0 1 0   
+    1 3 0 0 -1   
+    1 0 0 0 1   
+    1 0 -2 1 0   
+    1 0 0 1 0   
+    1 0 0 0 -1   
+    1 0 0 0 1   
+    1 0 0 1 0   
+    1 0 1 1 0   
+    1 3 0 0 -1   
+    1 1 0 0 1   
+    1 0 -2 1 0   
+    1 0 1 1 0   
+    1 0 0 0 -1   
+    1 1 0 0 1   
+    1 0 0 0 1   
+    1 0 0 1 0   
+    1 3 0 0 1   
+    1 0 0 1 0   
+    1 0 0 0 1   
+    1 0 2 1 0   
+    1 3 0 0 1   
+    1 0 2 1 0   
+@endverbatim
+**BNF-like Definition**
+
+@verbatim
+    2D curves = 2D curve header  _\n 2D curve records;  
+     
+    2D curve header = "Curve2ds" _ 2D  curve count;  
+     
+    2D curve count = int;  
+     
+    2D curve records = 2D curve record ^  2D curve count;  
+     
+    2D curve record =  
+    2D curve record 1 |  
+    2D curve record 2 |  
+    2D curve record 3 |  
+    2D curve record 4 |  
+    2D curve record 5 |  
+    2D curve record 6 |  
+    2D curve record 7 |  
+    2D curve record 8 |  
+    2D curve record 9;  
+@endverbatim
+@subsubsection occt_brep_format_4_3_1 2D curve record 1 – Line
+**Example**  
+
+@verbatim
+    1 3 0 0 -1   
+@verbatim
+**BNF-like Definition**
+
+@verbatim
+    2D curve record 1 = "1" _ 2D  point _ 2D direction _\n;  
+@endverbatim
+**Description**  
+2D curve record 1 describes a line. The line  data consist of a 2D point @image html brep_wp_image037.gif and a 2D direction @image html brep_wp_image038.gif. The line passes through the point  @image html brep_wp_image037.gif, has the  direction @image html brep_wp_image038.gif and  is defined by the following parametric equation:  
+@image html brep_wp_image333.gif, @image html brep_wp_image069.gif.  
+The example record is interpreted as a line which  passes through a point@image html brep_wp_image334.gif, has a direction @image html brep_wp_image335.gif and is defined by the  following parametric equation: @image html brep_wp_image336.gif.  
+@subsubsection occt_brep_format_4_3_2 2D curve record 2 – Circle
+**Example**  
+
+@verbatim
+    2 1 2 1 0 -0 1 3  
+@endverbatim
+**BNF-like Definition**
+
+@verbatim
+    2D curve record 2 = "2" _ 2D  circle center _ 2D circle Dx _ 2D circle Dy  _ 2D circle radius _\n;  
+     
+    2D circle center = 2D point;  
+     
+    2D circle Dx = 2D direction;  
+     
+    2D circle Dy = 2D direction;  
+     
+    2D circle radius = real;  
+@endverbatim
+**Description**  
+2D curve record 2 describes a circle. The  circle data consist of a 2D point @image html brep_wp_image037.gif, orthogonal 2D directions @image html brep_wp_image045.gif and @image html brep_wp_image046.gif and a non-negative  real @image html brep_wp_image047.gif. The  circle has a center @image html brep_wp_image037.gif. The circle plane is parallel to  directions @image html brep_wp_image045.gif and  @image html brep_wp_image046.gif. The  circle has a radius @image html brep_wp_image047.gif and is defined by the following  parametric equation:  
+@image html brep_wp_image337.gif, @image html brep_wp_image338.gif.  
+The example record is interpreted as a circle which  has a center @image html brep_wp_image339.gif.  The circle plane is parallel to directions @image html brep_wp_image340.gif and @image html brep_wp_image341.gif. The circle has a radius @image html brep_wp_image342.gif and is defined by  the following parametric equation: @image html brep_wp_image343.gif.  
+@subsubsection occt_brep_format_4_3_3 2D curve record 3 – Ellipse
+**Example**  
+
+@verbatim
+    3 1 2 1 0 -0 1 4 3  
+@verbatim
+**BNF-like Definition**
+
+@verbatim
+    2D curve record 3 = "3" _ 2D  ellipse center _ 2D ellipse Dmaj _   2D ellipse Dmin _ 2D ellipse Rmaj _ 2D  ellipse Rmin _\n;  
+     
+    2D ellipse center = 2D point;  
+     
+    2D ellipse Dmaj = 2D direction;  
+     
+    2D ellipse Dmin = 2D direction;  
+     
+    2D ellipse Rmaj = real;  
+     
+    2D ellipse Rmin = real;  
+@endverbatim
+**Description**  
+2D curve record 3 describes an ellipse. The  ellipse data are 2D point @image html brep_wp_image037.gif, orthogonal 2D directions @image html brep_wp_image056.gif and @image html brep_wp_image057.gif and non-negative  reals @image html brep_wp_image344.gif and @image html brep_wp_image345.gif that @image html brep_wp_image346.gif. The ellipse has a center  @image html brep_wp_image037.gif, major and  minor axis directions @image html brep_wp_image056.gif and @image html brep_wp_image057.gif, major and minor radii @image html brep_wp_image058.gif and @image html brep_wp_image345.gif and is defined by  the following parametric equation:  
+@image html brep_wp_image347.gif, @image html brep_wp_image338.gif.  
+The example record is interpreted as an ellipse which  has a center @image html brep_wp_image339.gif,  major and minor axis directions @image html brep_wp_image348.gif and @image html brep_wp_image349.gif, major and minor radii @image html brep_wp_image350.gif and @image html brep_wp_image351.gif and is defined by  the following parametric equation: @image html brep_wp_image352.gif.  
+@subsubsection occt_brep_format_4_3_4 2D curve record 4 – Parabola
+**Example**  
+
+@verbatim
+    4 1 2 1 0 -0 1 16  
+@endverbatim
+**BNF-like Definition**
+
+@verbatim
+    2D curve record 4 = "4" _ 2D  parabola origin _ 2D parabola Dx _   2D parabola Dy _ 2D parabola focal length _\n;  
+     
+    2D parabola origin = 2D point;  
+     
+    2D parabola Dx = 2D direction;  
+     
+    2D parabola Dy = 2D direction;  
+     
+    2D parabola focal length = real;  
+@endverbatim
+**Description**  
+2D curve record 4 describes a parabola. The  parabola data consist of a 2D point @image html brep_wp_image037.gif, orthogonal 2D directions @image html brep_wp_image045.gif and @image html brep_wp_image046.gif and a non-negative  real @image html brep_wp_image067.gif. The  parabola coordinate system has its origin @image html brep_wp_image037.gif and axis directions @image html brep_wp_image045.gif and @image html brep_wp_image046.gif. The parabola has a focus  length @image html brep_wp_image067.gif and  is defined by the following parametric equation:  
+@image html brep_wp_image068.gif, @image html brep_wp_image069.gif &Uuml; @image html brep_wp_image070.gif;  
+@image html brep_wp_image071.gif, @image html brep_wp_image069.gif &Uuml; @image html brep_wp_image072.gif (degenerated case).  
+The example record is interpreted as a parabola in  plane which passes through a point @image html brep_wp_image339.gif and is parallel to directions @image html brep_wp_image340.gif and @image html brep_wp_image341.gif. The parabola has a focus  length @image html brep_wp_image077.gif and  is defined by the following parametric equation: @image html brep_wp_image353.gif.  
+@subsubsection occt_brep_format_4_3_5 2D curve record 5 – Hyperbola
+**Example**  
+5 1 2 1 0 -0 1 3 4  
+
+**BNF-like Definition**
+
+@verbatim
+    2D curve record 5 = "5" _ 2D  hyperbola origin _ 2D hyperbola Dx _   2D hyperbola Dy _ 2D hyperbola Kx _ 2D  hyperbola Ky _\n;  
+     
+    2D hyperbola origin = 2D point;  
+     
+    2D hyperbola Dx = 2D direction;  
+     
+    2D hyperbola Dy = 2D direction;  
+     
+    2D hyperbola Kx = real;  
+     
+    2D hyperbola Ky = real;  
+@endverbatim
+**Description**  
+2D curve record 5 describes a hyperbola. The  hyperbola data consist of a 2D point @image html brep_wp_image037.gif, orthogonal 2D directions @image html brep_wp_image045.gif and @image html brep_wp_image046.gif and non-negative  reals @image html brep_wp_image079.gif and @image html brep_wp_image080.gif. The hyperbola  coordinate system has origin @image html brep_wp_image037.gif and axis directions @image html brep_wp_image045.gif and @image html brep_wp_image046.gif. The hyperbola is defined by  the following parametric equation:  
+@image html brep_wp_image081.gif, @image html brep_wp_image069.gif.  
+The example record is interpreted as a hyperbola with  coordinate system which has origin @image html brep_wp_image339.gif and axis directions @image html brep_wp_image354.gif and @image html brep_wp_image341.gif. Other data for the hyperbola  are @image html brep_wp_image082.gif and @image html brep_wp_image083.gif. The hyperbola is defined  by the following parametric equation: @image html brep_wp_image355.gif.  
+@subsubsection occt_brep_format_4_3_6 2D curve record 6 – Bezier Curve
+**Example**  
+
+@verbatim
+6 1 2 0 1  4 1 -2  5 2 3  6   
+@endverbatim
+**BNF-like Definition**
+
+@verbatim
+2D curve record 6 = "6" _ 2D  Bezier rational flag _ 2D Bezier degree   2D Bezier weight poles _\n;  
+2D Bezier rational flag = flag;  
+2D Bezier degree = int;  
+2D Bezier weight poles = (_ 2D  Bezier weight pole) ^ (2D Bezier degree + "1");  
+2D Bezier weight pole = 2D point  [_ real];  
+@endverbatim
+**Description**  
+2D curve record 6 describes a Bezier curve.  The curve data consist of a rational flag @image html brep_wp_image047.gif, a degree @image html brep_wp_image085.gif and weight poles.  
+The weight poles are @image html brep_wp_image086.gif 2D points @image html brep_wp_image087.gif if the flag @image html brep_wp_image047.gif is 0. The weight  poles are @image html brep_wp_image086.gif pairs  @image html brep_wp_image088.gif if the flag  @image html brep_wp_image047.gif is 1. Here @image html brep_wp_image089.gif is a 2D point and @image html brep_wp_image090.gif is a positive real (@image html brep_wp_image093.gif). @image html brep_wp_image092.gif (@image html brep_wp_image093.gif) if the flag @image html brep_wp_image047.gif is 0.  
+The Bezier curve is defined by the following  parametric equation:  
+@image html brep_wp_image094.gif, @image html brep_wp_image095.gif  
+where @image html brep_wp_image096.gif.  
+The example record is interpreted as a Bezier curve  with a rational flag @image html brep_wp_image097.gif, a degree @image html brep_wp_image098.gif and weight poles @image html brep_wp_image356.gif, @image html brep_wp_image100.gif, @image html brep_wp_image357.gif, @image html brep_wp_image102.gif and @image html brep_wp_image358.gif, @image html brep_wp_image104.gif. The Bezier curve is defined  by the following parametric equation:  
+@image html brep_wp_image359.gif.  
+@subsubsection occt_brep_format_4_3_7 2D curve record 7 – B-spline Curve
+**Example**  
+
+@verbatim
+7 1 0  1 3 5  0 1  4 1 -2  5  2 3  6  
+ 0 1 0.25 1 0.5 1 0.75 1 1 1  
+@endverbatim
+**BNF-like Definition**
+
+@verbatim
+    2D curve record 7 = "7" _ 2D  B-spline rational flag _ "0" _ 2D B-spline degree _  2D B-spline pole count _ 2D B-spline multiplicity knot  count 2D B-spline weight poles _\n 2D B-spline  multiplicity knots _\n;  
+     
+    2D B-spline rational flag = flag;  
+     
+    2D B-spline degree = int;  
+     
+    2D B-spline pole count = int;  
+     
+    2D B-spline multiplicity knot count = int;  
+     
+    2D B-spline weight poles = 2D B-spline  weight pole ^ 2D B-spline pole count;  
+     
+    2D B-spline weight pole = _ 2D  point [_ real];  
+     
+    2D B-spline multiplicity knots =  
+    2D B-spline multiplicity knot ^ 2D  B-spline multiplicity knot count;  
+     
+    2D B-spline multiplicity knot = _  real _ int;  
+@endverbatim
+**Description**  
+2D curve record 7 describes a B-spline curve.  The curve data consist of a rational flag @image html brep_wp_image047.gif, a degree @image html brep_wp_image085.gif, a pole count @image html brep_wp_image106.gif, a multiplicity knot count @image html brep_wp_image107.gif, weight poles and  multiplicity knots.  
+The weight poles are @image html brep_wp_image108.gif 2D points @image html brep_wp_image109.gif if the flag @image html brep_wp_image047.gif is 0. The weight  poles are @image html brep_wp_image108.gif pairs  @image html brep_wp_image110.gif if the flag  @image html brep_wp_image047.gif is 1. Here @image html brep_wp_image089.gif is a 2D point and @image html brep_wp_image090.gif is a positive real (@image html brep_wp_image111.gif). @image html brep_wp_image092.gif (@image html brep_wp_image111.gif) if the flag @image html brep_wp_image047.gif is 0.  
+The multiplicity knots are @image html brep_wp_image107.gif pairs @image html brep_wp_image112.gif. Here @image html brep_wp_image113.gif is a knot with multiplicity @image html brep_wp_image114.gif (@image html brep_wp_image115.gif) so that  
+@image html brep_wp_image360.gif (@image html brep_wp_image361.gif),  
+@image html brep_wp_image362.gif, @image html brep_wp_image363.gif, @image html brep_wp_image364.gif (@image html brep_wp_image365.gif), @image html brep_wp_image366.gif.  
+The B-spline curve is defined by the following  parametric equation:  
+@image html brep_wp_image367.gif, @image html brep_wp_image368.gif  
+where functions @image html brep_wp_image125.gif have the following recursion definition  by @image html brep_wp_image126.gif  
+@image html brep_wp_image127.gif, @image html brep_wp_image128.gif (@image html brep_wp_image129.gif)  
+where  
+@image html brep_wp_image284.gif (@image html brep_wp_image369.gif,@image html brep_wp_image286.gif).  
+The example record is interpreted as a B-spline curve  with a rational flag @image html brep_wp_image097.gif, a degree @image html brep_wp_image133.gif, a pole count @image html brep_wp_image134.gif, a multiplicity knot count @image html brep_wp_image135.gif, weight poles @image html brep_wp_image370.gif, @image html brep_wp_image137.gif, @image html brep_wp_image371.gif, @image html brep_wp_image139.gif and @image html brep_wp_image372.gif, @image html brep_wp_image141.gif and multiplicity knots @image html brep_wp_image373.gif, @image html brep_wp_image374.gif, @image html brep_wp_image375.gif, @image html brep_wp_image376.gif, @image html brep_wp_image377.gif, @image html brep_wp_image378.gif, @image html brep_wp_image379.gif, @image html brep_wp_image380.gif and @image html brep_wp_image381.gif, @image html brep_wp_image382.gif. The B-spline curve is defined  by the following parametric equation:  
+@image html brep_wp_image383.gif.  
+@subsubsection occt_brep_format_4_3_8 2D curve record 8 – Trimmed Curve
+**Example**  
+
+@verbatim
+    8 -4 5  
+    1 1 2 1 0   
+@endverbatim
+**BNF-like Definition**
+
+@verbatim
+    2D curve record 8 = "8" _ 2D  trimmed curve u min _ 2D trimmed curve u max _\n   2D curve record;  
+    2D trimmed curve u min = real;  
+    2D trimmed curve u max = real;  
+@endverbatim
+**Description**  
+2D curve record 8 describes a trimmed curve.  The trimmed curve data consist of reals @image html brep_wp_image153.gif and @image html brep_wp_image154.gif and a 2D curve record so that @image html brep_wp_image155.gif. The trimmed curve  is a restriction of the base curve @image html brep_wp_image326.gif described in the record to the segment @image html brep_wp_image157.gif. The trimmed curve is  defined by the following parametric equation:  
+@image html brep_wp_image158.gif, @image html brep_wp_image159.gif.  
+The example record is interpreted as a trimmed curve with @image html brep_wp_image160.gif, @image html brep_wp_image161.gif and base curve @image html brep_wp_image384.gif. The trimmed curve is  defined by the following parametric equation: @image html brep_wp_image385.gif, @image html brep_wp_image164.gif.  
+@subsubsection occt_brep_format_4_3_9 2D curve record 9 – Offset Curve
+**Example**  
+
+@verbatim
+    9 2  
+    1 1 2 1 0   
+@endverbatim
+**BNF-like Definition**
+@verbatim
+2D curve record 9 = "9" _ 2D  offset curve distance _\n 2D curve record;  
+2D offset curve distance = real;  
+@endverbatim
+**Description**  
+2D curve record 9 describes an offset curve.  The offset curve data consist of a distance @image html brep_wp_image165.gif and a 2D curve record. The  offset curve is the result of offsetting the base curve @image html brep_wp_image156.gif described in the record to the  distance @image html brep_wp_image165.gif along  the vector @image html brep_wp_image386.gif where  @image html brep_wp_image387.gif. The offset  curve is defined by the following parametric equation:  
+@image html brep_wp_image388.gif, @image html brep_wp_image168.gif.  
+The example record is interpreted as an offset curve  with a distance 
+@image html brep_wp_image169.gif and  base curve @image html brep_wp_image384.gif and 
+is defined by the following parametric equation: @image html brep_wp_image389.gif.  
+@subsection occt_brep_format_4_4 Subsection 3D polygons
+**Example**  
+
+@verbatim
+    Polygon3D 1  
+    2 1  
+    0.1  
+    1 0 0 2 0 0   
+    0 1   
+@endverbatim
+**BNF-like Definition**
+
+@verbatim
+    3D polygons = 3D polygon header  _\n 3D polygon records;  
+     
+    3D polygon header = "Polygon3D" _  3D polygon record count;  
+     
+    3D polygon records = 3D polygon record  ^ 3D polygon record count;  
+     
+    3D polygon record =  
+    3D polygon node count _ 3D polygon  flag of parameter presence _\n  
+    3D polygon deflection _\n  
+    3D polygon nodes _\n  
+    [3D polygon parameters _\n];  
+     
+    3D polygon node count = int;  
+     
+    3D polygon flag of parameter presence =  flag;  
+     
+    3D polygon deflection = real;  
+     
+    3D polygon nodes = (3D polygon node  _) ^ 3D polygon node count;  
+     
+    3D polygon node = 3D point;  
+     
+    3D polygon u parameters = (3D polygon u  parameter _) ^ 3D polygon node count;  
+     
+    3D polygon u parameter = real;  
+@endverbatim
+**Description**  
+3D polygon record describes a 3D polyline @image html brep_wp_image390.gif which approximates a  3D curve @image html brep_wp_image205.gif.  The polyline data consist of a node count @image html brep_wp_image391.gif, a parameter presence flag @image html brep_wp_image392.gif, a deflection @image html brep_wp_image393.gif, nodes @image html brep_wp_image394.gif (@image html brep_wp_image395.gif) and parameters @image html brep_wp_image113.gif (@image html brep_wp_image395.gif). The parameters are present  only if@image html brep_wp_image396.gif. The  polyline @image html brep_wp_image390.gif passes  through the nodes. The deflection @image html brep_wp_image165.gif describes the deflection of polyline @image html brep_wp_image390.gif from the curve @image html brep_wp_image205.gif:  
+@image html brep_wp_image397.gif.  
+The parameter @image html brep_wp_image113.gif (@image html brep_wp_image395.gif) is the parameter of the node @image html brep_wp_image394.gif on the curve @image html brep_wp_image205.gif:  
+@image html brep_wp_image398.gif.  
+The example record describes a polyline from @image html brep_wp_image098.gif nodes with a parameter  presence flag @image html brep_wp_image396.gif,  a deflection @image html brep_wp_image399.gif,  nodes @image html brep_wp_image400.gif and @image html brep_wp_image401.gif and parameters @image html brep_wp_image142.gif and @image html brep_wp_image402.gif.  
+@subsection occt_brep_format_4_5 Subsection triangulations
+**Example**  
+
+@verbatim
+    Triangulations 6  
+    4 2 1 0  
+    0 0 0 0 0 3 0 2 3 0 2 0 0 0 3  0 3 -2 0 -2 2 4 3 2 1 4   
+    4 2 1 0  
+    0 0 0 1 0 0 1 0 3 0 0 3 0 0 0  1 3 1 3 0 3 2 1 3 1 4   
+    4 2 1 0  
+    0 0 3 0 2 3 1 2 3 1 0 3 0 0 0  2 1 2 1 0 3 2 1 3 1 4   
+    4 2 1 0  
+    0 2 0 1 2 0 1 2 3 0 2 3 0 0 0  1 3 1 3 0 3 2 1 3 1 4   
+    4 2 1 0  
+    0 0 0 0 2 0 1 2 0 1 0 0 0 0 0  2 1 2 1 0 3 2 1 3 1 4   
+    4 2 1 0  
+    1 0 0 1 0 3 1 2 3 1 2 0 0 0 3  0 3 -2 0 -2 2 4 3 2 1 4   
+@endverbatim
+**BNF-like Definition**
+
+@verbatim
+    triangulations = triangulation header  _\n triangulation records;  
+     
+    triangulation header = "Triangulations"  _ triangulation count;  
+     
+    triangulation records = triangulation  record ^ triangulation count;  
+     
+    triangulation record = triangulation node  count _ triangulation triangle count _ triangulation  parameter presence flag _ triangulation deflection  _\n   triangulation nodes [_ triangulation u v parameters]  _ triangulation triangles _\n;  
+     
+    triangulation node count = int;  
+     
+    triangulation triangle count = int;  
+     
+    triangulation parameter presence flag =  flag;  
+     
+    triangulation deflection = real;  
+     
+    triangulation nodes = (triangulation  node _) ^ triangulation node count;  
+     
+    triangulation node = 3D point;  
+     
+    triangulation u v parameters =             (triangulation u v parameter pair _) ^ triangulation node  count;  
+     
+    triangulation u v parameter pair =  real _ real;  
+     
+    triangulation triangles = (triangulation  triangle _) ^ triangulation triangle count;  
+     
+    triangulation triangle = int _  int _ int.  
+@endverbatim
+**Description**  
+triangulation record describes a triangulation  @image html brep_wp_image403.gif which  approximates a surface @image html brep_wp_image404.gif. The triangulation data consist of a node  count @image html brep_wp_image405.gif, a triangle  count @image html brep_wp_image406.gif, a parameter  presence flag @image html brep_wp_image392.gif,  a deflection @image html brep_wp_image393.gif,  nodes @image html brep_wp_image394.gif (@image html brep_wp_image395.gif), parameter pairs @image html brep_wp_image407.gif (@image html brep_wp_image395.gif), triangles @image html brep_wp_image408.gif (@image html brep_wp_image131.gif, @image html brep_wp_image409.gif (@image html brep_wp_image410.gif)). The parameters are present  only if @image html brep_wp_image396.gif.  The deflection describes the triangulation deflection from the surface:  
+@image html brep_wp_image411.gif.  
+The parameter pair @image html brep_wp_image407.gif (@image html brep_wp_image395.gif) describes the parameters of node @image html brep_wp_image394.gif on the surface:  
+@image html brep_wp_image412.gif.  
+The triangle @image html brep_wp_image408.gif (@image html brep_wp_image131.gif) is interpreted as a triangle of nodes @image html brep_wp_image413.gif, @image html brep_wp_image414.gif and @image html brep_wp_image415.gif with circular traversal of  the nodes in the order @image html brep_wp_image413.gif, @image html brep_wp_image414.gif and @image html brep_wp_image415.gif. From any side of the triangulation @image html brep_wp_image403.gif all its triangles  have the same direction of the node circular traversal: either clockwise or  counterclockwise.  
+Triangulation record  
+
+@verbatim 
+    4 2 1 0  
+    0 0 0 0 0 3 0 2 3 0 2 0 0 0 3  0 3 -2 0 -2 2 4 3 2 1 4   
+@endverbatim
+
+describes a triangulation with @image html brep_wp_image416.gif nodes, @image html brep_wp_image417.gif triangles, parameter presence  flag @image html brep_wp_image396.gif,  deflection @image html brep_wp_image418.gif,  nodes @image html brep_wp_image419.gif, @image html brep_wp_image420.gif, @image html brep_wp_image421.gif and @image html brep_wp_image422.gif, parameters @image html brep_wp_image423.gif, @image html brep_wp_image424.gif, @image html brep_wp_image425.gif and @image html brep_wp_image426.gif, and triangles @image html brep_wp_image427.gif and @image html brep_wp_image428.gif. From the point @image html brep_wp_image429.gif (@image html brep_wp_image430.gif) the triangles have clockwise  (counterclockwise) direction of the node circular traversal.  
+@subsection occt_brep_format_4_6 Subsection polygons on triangulations
+**Example**  
+
+@verbatim
+    PolygonOnTriangulations 24  
+    2 1 2   
+    p 0.1 1 0 3   
+    2 1 4   
+    p 0.1 1 0 3   
+    2 2 3   
+    p 0.1 1 0 2   
+    2 1 2   
+    p 0.1 1 0 2   
+    2 4 3   
+    p 0.1 1 0 3   
+    2 1 4   
+    p 0.1 1 0 3   
+    2 1 4   
+    p 0.1 1 0 2   
+    2 1 2   
+    p 0.1 1 0 2   
+    2 1 2   
+    p 0.1 1 0 3   
+    2 2 3   
+    p 0.1 1 0 3   
+    2 2 3   
+    p 0.1 1 0 2   
+    2 4 3   
+    p 0.1 1 0 2   
+    2 4 3   
+    p 0.1 1 0 3   
+    2 2 3   
+    p 0.1 1 0 3   
+    2 1 4   
+    p 0.1 1 0 2   
+    2 4 3   
+    p 0.1 1 0 2   
+    2 1 2   
+    p 0.1 1 0 1   
+    2 1 4   
+    p 0.1 1 0 1   
+    2 4 3   
+    p 0.1 1 0 1   
+    2 1 4   
+    p 0.1 1 0 1   
+    2 1 2   
+    p 0.1 1 0 1   
+    2 2 3   
+    p 0.1 1 0 1   
+    2 4 3   
+    p 0.1 1 0 1   
+    2 2 3   
+    p 0.1 1 0 1   
+@endverbatim
+**BNF-like Definition**
+
+@verbatim
+    polygons on triangulations = polygons on  triangulations header _\n  
+    polygons on triangulations records;  
+     
+    polygons on triangulations header =  
+    "PolygonOnTriangulations" _ polygons on  triangulations record count;  
+     
+    polygons on triangulations record count =  int;  
+     
+    polygons on triangulations records =  
+    polygons on triangulations record ^ polygons  on triangulations record count;  
+     
+    polygons on triangulations record =  
+    polygons on triangulations node count  _ polygons on triangulations node numbers _\n  
+    "p" _ polygons on triangulations  deflection _  
+    polygons on triangulations parameter presence  flag  
+    [_ polygons on triangulations u  parameters] _\n;  
+     
+    polygons on triangulations node count =  int;  
+     
+    polygons on triangulations node numbers =  
+    polygons on triangulations node number ^  polygons on triangulations node count;  
+     
+    polygons on triangulations node number =  int;  
+     
+    polygons on triangulations deflection =  real;  
+     
+    polygons on triangulations parameter presence  flag = flag;  
+     
+    polygons on triangulations u parameters =  
+    (polygons on triangulations u parameter  _) ^ polygons on triangulations node count;  
+     
+    polygons on triangulations u parameter =  real;  
+@endverbatim
+**Description**  
+polygons on triangulations describes a polyline  @image html brep_wp_image390.gif on a triangulation  which approximates a curve @image html brep_wp_image205.gif. The polyline data consist of a node  count @image html brep_wp_image391.gif,  node numbers @image html brep_wp_image431.gif,  deflection @image html brep_wp_image393.gif,  a parameter presence flag @image html brep_wp_image392.gif and parameters @image html brep_wp_image432.gif (@image html brep_wp_image395.gif). The parameters are present  only if @image html brep_wp_image396.gif. The  deflection @image html brep_wp_image165.gif describes  the deflection of polyline @image html brep_wp_image390.gif from the curve @image html brep_wp_image205.gif:  
+@image html brep_wp_image397.gif.  
+Parameter @image html brep_wp_image113.gif (@image html brep_wp_image395.gif) is @image html brep_wp_image433.gif-th node @image html brep_wp_image434.gif parameter on curve @image html brep_wp_image205.gif.  
+@subsection occt_brep_format_4_7 Geometric Sense of a Curve
+Geometric sense of curve @image html brep_wp_image210.gif described above is determined by the direction  of parameter @image html brep_wp_image435.gif increasing.  
+@section occt_brep_format_5 Section shapes
+An example of section shapes and a whole  *.brep file are given in chapter 7 "Appendix".  
+**BNF-like Definition**
+
+@verbatim
+    shapes = shape header  _\n shape records _\n shape final record;  
+     
+    shape header = "TShapes" _  shape count;  
+     
+    shape count = int;  
+     
+    shape records = shape  record ^ shape count;  
+     
+    shape record = shape subrecord  _\n shape flag word _\n shape subshapes  _\n;  
+     
+    shape flag word = flag ^  7;  
+     
+    shape subshapes = (shape  subshape _)* "*";  
+     
+    shape subshape =  
+    shape subshape orientation shape subshape  number _ shape location number;  
+     
+    shape subshape orientation = "+" |  "-" | "i" | "e";  
+     
+    shape subshape number =  int;  
+     
+    shape location number =  int;  
+     
+    shape final record = shape  subshape;  
+     
+    shape subrecord =  
+    ("Ve" _\n vertex data  _\n) |  
+    ("Ed" _\n edge data  _\n) |  
+    ("Wi" _\n _\n) |  
+    ("Fa" _\n face data) |  
+    ("Sh" _\n _\n) |  
+    ("So" _\n _\n) |  
+    ("CS" _\n _\n) |  
+    ("Co" _\n _\n);  
+@endverbatim
+**Description**  
+shape flag word @image html brep_wp_image436.gif flags @image html brep_wp_image437.gif 
+(@image html brep_wp_image438.gif) are interpreted as shape  flags in the following way:  
+
+  *  @image html brep_wp_image439.gif – free;  
+  *  @image html brep_wp_image440.gif – modified;  
+  *  @image html brep_wp_image441.gif – IGNORED (version   *  / checked  (version   * ;  
+  *  @image html brep_wp_image442.gif – orientable;  
+  *  @image html brep_wp_image443.gif – closed;  
+  *  @image html brep_wp_image444.gif – infinite;  
+  *  @image html brep_wp_image445.gif – convex.  
+  
+The flags are used in a special way [1].  
+shape subshape orientation is interpreted in  the following way:  
+
+  *  + – forward;  
+  *  - – reversed;  
+  *  i – internal;  
+  *  e – external.  
+  
+shape subshape orientation is used in a special  way [1].  
+shape subshape number is the number of a shape  record which is located in this section above the shape subshape  number. shape record numbering is backward and starts from 1.  
+shape subrecord types are interpreted in the  following way: 
+  *  "Ve" – vertex;  
+  *  "Ed" – edge;  
+  *  "Wi" – wire;  
+  *  "Fa" – face;  
+  *  "Sh" – shell;  
+  *  "So" – solid;  
+  *  "CS" – compsolid;  
+  *  "Co" – compound.  
+shape final record determines the orientation  and location for the whole model.  
+@subsection occt_brep_format_5_1  Common Terms
+The terms below are used by vertex data, edge  data and face data.  
+**BNF-like Definition**
+
+@verbatim
+    location number = int;  
+     
+    3D curve number = int;  
+     
+    surface number = int;  
+     
+    2D curve number = int;  
+     
+    3D polygon number = int;  
+     
+    triangulation number =  int;  
+     
+    polygon on triangulation number =  int;  
+     
+    curve parameter minimal and maximal  values = real _ real;  
+     
+    curve values for parameter minimal and maximal  values =  
+    real _ real _ real  _ real;  
+@endverbatim
+**Description**  
+location number is the number of location  record from section locations. location record numbering  starts from 1. location number 0 is interpreted  as the identity location.  
+3D curve number is the number of a 3D  curve record from subsection 3D curves of section geometry.  3D curve record numbering starts from 1.  
+surface number is the number of a surface  record from subsection surfaces of section geometry. surface  record numbering starts from 1.  
+2D curve number is the number of a 2D  curve record from subsection 2D curves of section geometry.  2D curve record numbering starts from 1.  
+3D polygon number is the number of a 3D  polygon record from subsection 3D polygons of section geometry.  3D polygon record numbering starts from 1.  
+triangulation number is the number of a triangulation  record from subsection triangulations of section geometry. triangulation  record numbering starts from 1.  
+polygon on triangulation number is the number  of a polygons on triangulations record from subsection polygons on  triangulations of section geometry.  
+polygons on triangulations record numbering  starts from 1.  
+curve parameter minimal and maximal values @image html brep_wp_image446.gif and @image html brep_wp_image447.gif are the curve  parameter@image html brep_wp_image448.gif  bounds: @image html brep_wp_image449.gif.  
+curve  values for parameter minimal and maximal values @image html brep_wp_image446.gif and @image html brep_wp_image447.gif are real pairs @image html brep_wp_image450.gif and @image html brep_wp_image451.gif that @image html brep_wp_image452.gif and @image html brep_wp_image453.gif where @image html brep_wp_image205.gif is a parametric  equation of the curve.  
+@subsection occt_brep_format_5_2 vertex data
+**BNF-like Definition**
+
+@verbatim
+    vertex data = vertex data tolerance  _\n vertex data 3D representation _\n   vertex data representations;  
+     
+    vertex data tolerance = real;  
+     
+    vertex data 3D representation = 3D point;  
+     
+    vertex data representations = (vertex data  representation _\n)* "0 0";  
+     
+    vertex data representation = vertex data  representation u parameter _  
+    vertex data representation data _  location number;  
+     
+    vertex data representation u parameter =  real;  
+     
+    vertex data representation data =  
+    ("1" _ vertex data representation data    *  |  
+    ("2" _ vertex data representation data    *  |  
+    ("3" _ vertex data representation data    * ;  
+     
+    vertex data representation data 1 = 3D  curve number;  
+     
+    vertex data representation data 2 = 2D  curve number _ surface number;  
+     
+    vertex data representation data 3 =  
+    vertex data representation v parameter  _ surface number;  
+     
+    vertex data representation v parameter =  real;  
+@endverbatim
+**Description**  
+The usage of vertex data representation u  parameter @image html brep_wp_image448.gif is  described below.  
+vertex data representation data 1 and  parameter @image html brep_wp_image448.gif describe  the position of the vertex @image html brep_wp_image454.gif on a 3D curve @image html brep_wp_image205.gif. Parameter @image html brep_wp_image448.gif is a parameter of the  vertex @image html brep_wp_image454.gif on the  curve @image html brep_wp_image205.gif: @image html brep_wp_image455.gif.  
+vertex data representation data 2 and  parameter @image html brep_wp_image448.gif describe  the position of the vertex @image html brep_wp_image454.gif on a 2D curve @image html brep_wp_image205.gif which is located on a  surface. Parameter @image html brep_wp_image448.gif is  a parameter of the vertex @image html brep_wp_image454.gif on the curve @image html brep_wp_image205.gif: @image html brep_wp_image455.gif.  
+vertex data representation data 3 and  parameter @image html brep_wp_image435.gif describe  the position of the vertex @image html brep_wp_image454.gif on a surface @image html brep_wp_image404.gif through vertex data  representation v parameter @image html brep_wp_image456.gif: @image html brep_wp_image457.gif.  
+vertex data tolerance @image html brep_wp_image458.gif describes the maximum distance  from the vertex @image html brep_wp_image454.gif to  the set @image html brep_wp_image459.gif* *of vertex @image html brep_wp_image454.gif representations:  
+@image html brep_wp_image460.gif.  
+@subsection occt_brep_format_5_3 edge data
+**BNF-like Definition**
+
+@verbatim
+    edge data = _ edge data tolerance  _ edge data same parameter flag _ edge data same range  flag _ edge data degenerated flag _\n edge data  representations;  
+     
+    edge data tolerance = real;  
+     
+    edge data same parameter flag = flag;  
+     
+    edge data same range flag = flag;  
+     
+    edge data degenerated flag = flag;  
+     
+    edge data representations = (edge data  representation _\n)* "0";  
+     
+    edge data representation =  
+    "1" _ edge data representation data 1  
+    "2" _ edge data representation data 2  
+    "3" _ edge data representation data 3  
+    "4" _ edge data representation data 4  
+    "5" _ edge data representation data 5  
+    "6" _ edge data representation data 6  
+    "7" _ edge data representation data 7;  
+     
+    edge data representation data 1 = 3D curve  number _ location number _  
+    curve parameter minimal and maximal values;  
+     
+    edge data representation data&