0029755: Proofread changes in the user guides from v7.2 to v7.3
authorysn <ysn@opencascade.com>
Fri, 11 May 2018 12:17:12 +0000 (15:17 +0300)
committerabv <abv@opencascade.com>
Thu, 24 May 2018 12:36:24 +0000 (15:36 +0300)
Recent modifications and additions in the user and dev guides have been reviewed (except for upgrade.md and inspector.md).

dox/dev_guides/git_guide/git_guide.md
dox/dev_guides/tests/tests.md
dox/user_guides/boolean_operations/boolean_operations.md
dox/user_guides/draw_test_harness/draw_test_harness.md
dox/user_guides/modeling_algos/modeling_algos.md
dox/user_guides/modeling_data/modeling_data.md
dox/user_guides/visualization/visualization.md
dox/user_guides/xde/xde.md

index aefc95e..f608890 100644 (file)
@@ -140,7 +140,7 @@ The official repository contains:
   @figure{OCCT_GitGuide_V2_image006.png,"",320}
 
   Optionally, you can set up TortoiseGit to use visual diff utility for SVG images used in OCCT documentation.
-  For that, click on item "Diff Viewer" in the Settings dialog, then click button "Advanced..." on the right tab add new record with the following parameters:
+  For that, click on item "Diff Viewer" in the Settings dialog, then click button "Advanced..." in the right tab to add a new record with the following parameters:
   - Extension: <code>.svg</code>
   - External program: <code>&lt;path_to_OCCT&gt;\\adm\\svgdiff.bat %%base %%mine %%bname %%yname</code>
 
index 4356711..ce9a8da 100644 (file)
@@ -193,9 +193,9 @@ Use prefix <i>bug</i> followed by Mantis issue ID and, if necessary, additional
        *       To check expected output which should be obtained as the test result, add @ref testmanual_3_7 "REQUIRED" statement for each line of output to mark it as required.
        *       If the test case produces error messages (contained in parse.rules), which are expected in that test and should not be considered as its failure (e.g. test for *checkshape* command), add REQUIRED statement for each error to mark it as required output.
 4.     To check whether the data files needed for the test are already present in the database, use DRAW command *testfile* (see below).
-    If the data file is already present, use it for new test instead of adding a duplicate.
-    If the data file(s) are not yet present in the test database, put them to some folder and add it to the environment variable *CSF_TestDataPath* to be found by the test system.
-    Information on where the data files can be accessed by OCC team for putting to official database should be provided in comment to Mantis issue, clearly indicating how names of the files used by the test script match the actual names of the files.
+    If the data file is already present, use it for a new test instead of adding a duplicate.
+    If the data file(s) are not yet present in the test database, put them to a folder and add it to the environment variable *CSF_TestDataPath* to be found by the test system.
+    The location of the data files, which need to be accessed by OCC team and put to the official database, should be provided in the comment to Mantis issue, clearly indicating how the names of the files used by the test script match the actual names of the files.
     The simplest way is to attach the data files to the Mantis issue, with the same names as used by the test script.
 5.     Check that the test case runs as expected (test for fix: OK with the fix, FAILED without the fix; test for existing problem: BAD), and integrate it to the Git branch created for the issue.
 
@@ -222,8 +222,8 @@ fixshape result a 0.01 0.01
 checkshape result
 ~~~~~
 
-DRAW command testfile should be used to check the data files being used by the test for possible duplication of content or names.
-The command accepts list of paths to files being checked as single argument, and will give conclusion on each of the files, for instance:
+DRAW command *testfile* should be used to check the data files used by the test for possible duplication of content or names.
+The command accepts the list of paths to files to be checked (as a single argument) and gives a conclusion on each of the files, for instance:
 
 ~~~~~
 Draw[1]> testfile [glob /my/data/path/bug12345*]
index f981db4..dbd97df 100644 (file)
@@ -2171,7 +2171,7 @@ aMV.SetArguments(aLS);
 // setting options for this algorithm is similar to setting options for GF algorithm (see "GF Usage" chapter)
 ...
 // Additional option of the algorithm
-Standard_Boolean bAvoidInternalShapes = Standard_False; /* Avoid or not the internal for solids shapes in the result*/
+Standard_Boolean bAvoidInternalShapes = Standard_False; // Set to True to exclude from the result any shapes internal to the solids
 aMV.SetAvoidInternalShapes(bAvoidInternalShapes);
 
 // Perform the operation
@@ -2819,10 +2819,10 @@ To enable the safe processing mode for the operation in DRAW, it is necessary to
 bnondestructive 1
 ~~~~
 
-@subsection occt_algorithms_11a_4 Disabling check of the input solids for inverted status
+@subsection occt_algorithms_11a_4 How to disable check of input solids for inverted status
 
-By default, all input solids are checked for inverted status, i.e. the solids are classified to understand if they are holes in the space (negative volumes) or normal solids (positive volumes). The possibility to disable the check of the input solids for inverted status is the advanced option in Boolean Operation component. This option can be applied to all Basic operations such as General Fuse, Splitting, Boolean, Section, Maker Volume, Cells building.
-This option allows avoiding time-consuming classification of the input solids and operate with them as with positive volumes, saving up to 10 percent of time on the cases with big number of input solids.
+By default, all input solids are checked for inverted status, i.e. the solids are classified to understand if they are holes in the space (negative volumes) or normal solids (positive volumes). The possibility to disable the check of the input solids for inverted status is the advanced option in Boolean Operation component. This option can be applied to all Basic operations, such as General Fuse, Splitting, Boolean, Section, Maker Volume and Cells building.
+This option allows avoiding time-consuming classification of the input solids and processing them in the same way as positive volumes, saving up to 10 percent of time on the cases with a big number of input solids.
 
 The classification should be disabled only if the user is sure that there are no negative volumes among the input solids, otherwise the result may be invalid.
 
@@ -2842,7 +2842,7 @@ aGF.SetCheckInverted(Standard_False);
 ~~~~
 
 #### TCL level
-To enable/disable the classification of the solids in DRAW, it is necessary to call the *bcheckinverted* command with appropriate value:
+To enable/disable the classification of the solids in DRAW, it is necessary to call *bcheckinverted* command with the appropriate value:
 * 0 - disabling the classification;
 * 1 - default value, enabling the classification.
 
@@ -2852,7 +2852,7 @@ bcheckinverted 0
 
 @subsection occt_algorithms_11a_5_obb Usage of Oriented Bounding Boxes
 
-Since Oriented Bounding Boxes are usually much tighter than Axes Aligned Bounding Boxes (for more information on OBB please see the @ref occt_modat_6 "Bounding boxes" chapter of Modeling data User guide) its usage can significantly speed-up the intersection stage of the operation by reducing the number of interfering objects.
+Since Oriented Bounding Boxes are usually much tighter than Axes Aligned Bounding Boxes (for more information on OBB see the @ref occt_modat_6 "Bounding boxes" chapter of Modeling data User guide) its usage can significantly speed-up the intersection stage of the operation by reducing the number of interfering objects.
 
 @subsubsection occt_algorithms_11a_5_obb_1 Usage
 
@@ -3026,7 +3026,7 @@ modified m2 cut_hist e2
 
 @subsubsection occt_algorithms_history_gen Generated shapes
 
-The two intersecting edges will both have the intersection vertices Generated from them.
+Two intersecting edges will both have the intersection vertices Generated from them.
 
 As for the operation with intersecting faces, consider the following example:
 
index 32b7e30..587c562 100644 (file)
@@ -5577,7 +5577,7 @@ intconcon curve1 curve2
 
 Displays the intersection points between two 2d curves. 
 Curves must be only conic sections: 2d lines, circles, ellipses,
-hyperbolas, parabolas. Algorithm from IntAna2d_AnaIntersection is used.
+hyperbolas, parabolas. The algorithm from *IntAna2d_AnaIntersection* is used.
 
 **Example:** 
 ~~~~~
@@ -7405,12 +7405,12 @@ Syntax:
 bounding {-s shape | -c xmin ymin zmin xmax ymax zmax} [-obb] [-shape name] [-dump] [-notriangulation] [-perfmeter name NbIters] [-save xmin ymin zmin xmax ymax zmax] [-nodraw] [-optimal] [-exttoler]
 ~~~~~
 
-Computes and displays the bounding box (BndBox) of a shape. The bounding box is a cuboid circumscribes the source shape.
-Generaly, bounding boxes can be divided on two main types:
-  - axis-aligned BndBox (AABB). I.e. the box whose edges are parallel to the some axis of World Coordinate System (WCS);
+Computes and displays the bounding box (BndBox) of a shape. The bounding box is a cuboid that circumscribes the source shape.
+Generaly, bounding boxes can be divided into two main types:
+  - axis-aligned BndBox (AABB). I.e. the box whose edges are parallel to an axis of World Coordinate System (WCS);
   - oriented BndBox (OBB). I.e. not AABB.
 
-Detailed information about this command is availabe in DRAW help-system (enter "help bounding" in DRAW-application).
+Detailed information about this command is availabe in DRAW help-system (enter "help bounding" in DRAW application).
   
 **Example 1: Creation of AABB with given corners** 
 ~~~~~
@@ -7491,7 +7491,7 @@ Syntax:
 isbbinterf shape1 shape2 [-o]
 ~~~~~
 
-Checks whether the bounding-boxes created from the given shapes are interfered. If "-o"-option is switched on then the oriented boxes will be checked. Otherwise, axes-aligned boxes will be checked.
+Checks whether the bounding boxes created from the given shapes are interfered. If "-o"-option is switched on then the oriented boxes will be checked. Otherwise, axis-aligned boxes will be checked.
 
 **Example 1: Not interfered AABB** 
 ~~~~~
@@ -7540,7 +7540,7 @@ Syntax:
 distmini name Shape1 Shape2 
 ~~~~~
 
-Calculates the minimum distance between two shapes. The calculation returns the number of solutions, If more than one solution exists. The options are displayed in the viewer(red) and the results are listed in the shell window. The *distmini* lines are considered as shapes which have a value v. 
+Calculates the minimum distance between two shapes. The calculation returns the number of solutions, if more than one solution exists. The options are displayed in the viewer in red and the results are listed in the shell window. The *distmini* lines are considered as shapes which have a value v. 
 
 **Example:** 
 ~~~~~
@@ -7610,8 +7610,8 @@ checkshape [-top] shape [result] [-short]
 
 Where: 
 * *top* -- optional parameter, which allows checking only topological validity of a shape. 
-* *shape* -- the only required parameter which represents the name of the shape to check. 
-* *result* -- optional parameter which is the prefix of the output shape names. 
+* *shape* -- the only required parameter, defines the name of the shape to check. 
+* *result* -- optional parameter, defines custom prefix for the output shape names.
 * *short* -- a short description of the check. 
 
 **checkshape** examines the selected object for topological and geometric coherence. The object should be a three dimensional shape. 
@@ -7656,9 +7656,9 @@ validrange edge [(out) u1 u2]
 
 Where: 
 * *edge* -- the name of the edge to analyze. 
-* *u1*, *u2* -- optional names of variables to put the range into.
+* *u1*, *u2* -- optional names of variables to put into the range.
 
-**validrange** computes valid range of the edge. If *u1* and *u2* are not given it returns first and last parameters. Otherwise, it sets the variables u1 and u2.
+**validrange** computes valid range of the edge. If *u1* and *u2* are not given, it returns the first and the last parameters. Otherwise, it sets variables *u1* and *u2*.
 
 **Example:** 
 ~~~~~
@@ -8034,7 +8034,7 @@ Options:
 
 @subsection occt_draw_hist History commands
 
-Draw module for @ref occt_modalg_hist "History Information support" includes the command to save history into a drawable object and the actual history commands:
+Draw module for @ref occt_modalg_hist "History Information support" includes the command to save history of modifications performed by Boolean operation or sibling commands into a drawable object and the actual history commands:
 
 * *savehistory*;
 * *isdeleted*;
@@ -8050,8 +8050,8 @@ Syntax:
 savehistory     : savehistory name
 ~~~~
 
-If the history of some operation is needed the *savehistory* command should be called after the command performing the operation.
-If some other operation supporting history will be performed before the history of first operation is saved it will be overwritten with the new history.
+If the history of shape modifications performed during an operation is needed, the *savehistory* command should be called after the command performing the operation.
+If another operation supporting history will be performed before the history of the first operation is saved it will be overwritten with the new history.
 
 Example:
 ~~~~
@@ -8102,7 +8102,7 @@ foreach s [join [list [explode b2 v] [explode b2 e] [explode b2 f] ] ] {
 
 @subsubsection occt_draw_hist_mod modified
 
-*modified* command returns the shapes Modified from the given shape in the given history. All modified shapes are put into compound. If the shape has not been modified the resulting compound will be empty. Note that if the shape has been modified into a single shape only, it will be returned without enclosure into compound.
+*modified* command returns the shapes Modified from the given shape in the given history. All modified shapes are put into a compound. If the shape has not been modified, the resulting compound will be empty. Note that if the shape has been modified into a single shape only, it will be returned without enclosure into the compound.
 
 Syntax:
 ~~~~
@@ -8125,7 +8125,7 @@ modified m5 fillet_hist b_5
 
 @subsubsection occt_draw_hist_gen generated
 
-*generated* command returns the shapes Generated from the given shape in the given history. All generated shapes are put into compound. If no shapes have been generated from the shape the resulting compound will be empty. Note that if the shape has generated a single shape only, it will be returned without enclosure into compound.
+*generated* command returns the shapes Generated from the given shape in the given history. All generated shapes are put into a compound. If no shapes have been generated from the shape, the resulting compound will be empty. Note that; if the shape has generated a single shape only, it will be returned without enclosure into the compound.
 
 Syntax:
 ~~~~
@@ -11020,24 +11020,24 @@ tinspector [-plugins {name1 ... [nameN] | all}]
            [-select {object | name1 ... [nameN]}]
            [-show {0|1} = 1]
 ~~~~~
-Starts tool of inspection.
+Starts inspection tool.
 Options:
 * *plugins* enters plugins that should be added in the inspector.
-Available names are: dfbrowser, vinspector and shapeview.
-Plugins order will be the same as defined in arguments.
+Available names are: *dfbrowser*, *vinspector* and *shapeview*.
+Plugins order will be the same as defined in the arguments.
 'all' adds all available plugins in the order:
 DFBrowser, VInspector and ShapeView.
-If at the first call this option is not used, 'all' option is applyed;
+If at the first call this option is not used, 'all' option is applied;
 * *activate* activates the plugin in the tool view.
 If at the first call this option is not used, the first plugin is activated;
-* *shape* initializes plugin/s by the shape object. If 'name' is empty, initializes all plugins;
-* *open* gives the file to the plugin/s. If the plugin is active, after open, update content will be done;
+* *shape* initializes plugin(s) by the shape object. If 'name' is empty, initializes all plugins;
+* *open* gives the file to the plugin(s). If the plugin is active after open, the content will be updated;
 * *update* updates content of the active plugin;
 * *select* sets the parameter that should be selected in an active tool view.
-Depending on active tool the parameter is:
-ShapeView: 'object' is an instance of TopoDS_Shape TShape,
-DFBrowser: 'name' is an entry of TDF_Label and name2(optionaly) for TDF_Attribute type name,
-VInspector: 'object' is an instance of AIS_InteractiveObject;
+Depending on the active tool the parameter is:
+ShapeView: 'object' is an instance of *TopoDS_Shape TShape*,
+DFBrowser: 'name' is an entry of *TDF_Label* and 'name2' (optionally) for *TDF_Attribute* type name,
+VInspector: 'object' is an instance of *AIS_InteractiveObject*;
 * *show* sets Inspector view visible or hidden. The first call of this command will show it.
 
 **Example:** 
index a0c8675..5827c0c 100644 (file)
@@ -1286,11 +1286,11 @@ TopoDS_Edge E = ME;
 
 @subsection occt_modalg_hist History support
 
-All topological API algorithms support the history of shapes modifications (or just History) for their arguments.
+All topological API algorithms support the history of shape modifications (or just History) for their arguments.
 Generally, the history is available for the following types of sub-shapes of input shapes:
-* Vertex
-* Edge
-* Face
+* Vertex;
+* Edge;
+* Face.
 
 Some algorithms also support the history for Solids.
 
@@ -1300,7 +1300,7 @@ The history information consists of the following information:
 * Information about Generated shapes.
 
 The History is filled basing on the result of the operation. History cannot return any shapes not contained in the result.
-Thus, if the result of the operation is empty shape, all input shapes will be considered as Deleted and none will have Modified and Generated shapes.
+If the result of the operation is an empty shape, all input shapes will be considered as Deleted and none will have Modified and Generated shapes.
 
 The history information can be accessed by the API methods:
 * *Standard_Boolean IsDeleted(const TopoDS_Shape& theS)* - to check if the shape has been Deleted during the operation;
@@ -1310,7 +1310,7 @@ The history information can be accessed by the API methods:
 @subsubsection occt_modalg_hist_del Deleted shapes
 
 The shape is considered as Deleted during the operation if all of the following conditions are met:
-* The shape is the part of the argument shapes of the operation;
+* The shape is a part of the argument shapes of the operation;
 * The result shape does not contain the shape itself;
 * The result shape does not contain any of the splits of the shape.
 
@@ -1318,19 +1318,19 @@ For example, in the CUT operation between two intersecting solids all vertices/e
 
 @subsubsection occt_modalg_hist_mod Modified shapes
 
-The shape is considered as Modified during the operation if the result shape contains the splits of the shape, not the shape itself. The shape can be modified only into the shapes with same dimension.
+The shape is considered as Modified during the operation if the result shape contains the splits of the shape, not the shape itself. The shape can be modified only into the shapes with the same dimension.
 The splits of the shape contained in the result shape are Modified from the shape.
 The Modified shapes are created from the sub-shapes of the input shapes and, generally, repeat their geometry.
 
-The list of Modified elements will contain only those which are contained in the result of the operation. If the list is empty the shape has not been modified and it is necessary to check if it has been Deleted.
+The list of Modified elements will contain only those contributing to the result of the operation. If the list is empty, the shape has not been modified and it is necessary to check if it has been Deleted.
 
 For example, after translation of the shape in any direction all its sub-shapes will be modified into their translated copies.
 
 @subsubsection occt_modalg_hist_gen Generated shapes
 
-The shapes contained in the result shape are considered as Generated from the input shape if they were produced during the operation and have different dimension with the shapes from which they were created.
+The shapes contained in the result shape are considered as Generated from the input shape if they were produced during the operation and have a different dimension from the shapes from which they were created.
 
-The list of Generated elements will contain only those which are contained in the result of the operation. If the list is empty no new shapes have been Generated from the shape.
+The list of Generated elements will contain only those included in the result of the operation. If the list is empty, no new shapes have been Generated from the shape.
 
 For example, extrusion of the edge in some direction will create a face. This face will be generated from the edge.
 
@@ -1338,7 +1338,7 @@ For example, extrusion of the edge in some direction will create a face. This fa
 
 *BRepTools_History* is the general History tool intended for unification of the histories of different algorithms.
 
-BRepTools_History can be created from any algorithm supporting the standard history methods (IsDeleted(), Modified() and Generated()):
+*BRepTools_History* can be created from any algorithm supporting the standard history methods *(IsDeleted(), Modified()* and *Generated())*:
 ~~~~
 // The arguments of the operation
 TopoDS_Shape aS = ...;
@@ -1355,7 +1355,7 @@ anArguments.Append(aS);
 BRepTools_History aHistory(anArguments, aTransformer);
 ~~~~
 
-BRepTools_History also allows merging of the histories. Thus, if you have two or more subsequent operations you can get one final history combined from histories of these operations:
+*BRepTools_History* also allows merging histories. Thus, if you have two or more subsequent operations you can get one final history combined from histories of these operations:
 
 ~~~~
 Handle(BRepTools_History) aHist1 = ...; // History of first operation
@@ -1374,27 +1374,27 @@ aResHistory->Merge(aHist1);
 aResHistory->Merge(aHist2);
 ~~~~
 
-The possibility of Merging of the histories and its creation from the API algorithms allows providing easy History support for the new algorithms.
+The possibilities of Merging histories and history creation from the API algorithms allow providing easy History support for the new algorithms.
 
 @subsubsection occt_modalg_hist_draw DRAW history support
 
-DRAW History support for the algorithms supporting history is provided by three basic commands:
+DRAW History support for the algorithms is provided by three basic commands:
 * *isdeleted*; 
 * *modified*;
 * *generated*.
 
-For more information on the Draw History mechanism please refer the corresponding chapter in the Draw users guide - @ref occt_draw_hist "History commands".
+For more information on the Draw History mechanism please refer to the corresponding chapter in the Draw users guide - @ref occt_draw_hist "History commands".
 
 
 @section occt_modalg_3 Standard  Topological Objects
 
 The following  standard topological objects can be created:
-  * Vertices
-  * Edges
-  * Faces
-  * Wires
-  * Polygonal wires
-  * Shells
+  * Vertices;
+  * Edges;
+  * Faces;
+  * Wires;
+  * Polygonal wires;
+  * Shells;
   * Solids.
 
 There are two root classes for their construction and modification: 
@@ -3141,23 +3141,23 @@ You can obtain information on the shape by first exploring it. To access triangu
 
 @section occt_modalg_defeaturing 3D Model Defeaturing
 
-The Open CASCADE Technology Defeaturing algorithm is intended for removal of the unwanted parts or features from the model. These parts could be the holes, protrusions, gaps, chamfers, fillets etc.
+The Open CASCADE Technology Defeaturing algorithm is intended for removal of the unwanted parts or features from the model. These parts can be holes, protrusions, gaps, chamfers, fillets, etc.
 
-Feature detection is not performed, and all features desired for removal should be defined by the user. The input shape is not modified during Defeaturing, the new shape is built in the result.
+Feature detection is not performed, and all features to be removed should be defined by the user. The input shape is not modified during Defeaturing, the new shape is built in the result.
 
-On the API level the Defeaturing algorithm is implemented in the *BRepAlgoAPI_Defeaturing* class. On the input the algorithm accepts the shape to remove the features from and the features (one or many) to remove from the shape.
-Currently, the input shape should either be SOLID, or COMPSOLID, or COMPOUND of SOLIDs.
-The features to remove are the sets of faces forming the features. It does not matter how the feature faces are given. It could be the separate faces or the collections of them. The faces should belong to the initial shape, and those that do not belong will be ignored.
+On the API level the Defeaturing algorithm is implemented in the *BRepAlgoAPI_Defeaturing* class. At input the algorithm accepts the shape to remove the features from and the features (one or many) to be removed from the shape.
+Currently, the input shape should be either SOLID, or COMPSOLID, or COMPOUND of SOLIDs.
+The features to be removed are defined by the sets of faces forming them. It does not matter how the feature faces are given: as separate faces or their collections. The faces should belong to the initial shape, else they are ignored.
 
-The actual features removal is performed by the low-level *BOPAlgo_RemoveFeatures* algorithm. On the API level, all the inputs are passed into the tool and the method *BOPAlgo_RemoveFeatures::Perform()* is called.
+The actual features removal is performed by the low-level *BOPAlgo_RemoveFeatures* algorithm. On the API level, all inputs are passed into the tool and the method *BOPAlgo_RemoveFeatures::Perform()* is called.
 
-Before starting Features removal all the faces requested for removal from the shape are sorted on the connected blocks - each block represents single feature to remove.
-The features will be removed from the shape one by one, which will allow removing all possible features even if there were some problems with the removal of some of them (due to e.g. incorrect input data).
+Before removing features, all faces to be removed from the shape are sorted into connected blocks - each block represents a single feature to be removed.
+The features are removed from the shape one by one, which allows removing all possible features even if there are some problems with their removal (e.g. due to incorrect input data).
 
-The removed feature is filled by the extension of the faces adjacent to the feature. In general, the algorithm of removing of the single feature from the shape looks as follows:
+The removed feature is filled by the extension of the faces adjacent to it. In general, the algorithm removing a single feature from the shape goes as follows:
 * Find the faces adjacent to the feature;
 * Extend the adjacent faces to cover the feature;
-* Trim the extended faces by the bounds of original face (except for bounds common with the feature), so it will cover the feature only;
+* Trim the extended faces by the bounds of the original face (except for the bounds common with the feature), so that they cover the feature only;
 * Rebuild the solids with reconstructed adjacent faces avoiding the feature faces.
 
 If the single feature removal was successful, the result shape is overwritten with the new shape, otherwise the results are not kept, and the warning is given.
@@ -3170,27 +3170,27 @@ and the options available from base class (*BOPAlgo_Options*):
 * Error/Warning reporting system;
 * Parallel processing mode.
 
-Please note that the other options of the base class are not supported here and will have no effect.
+Note that the other options of the base class are not supported here and will have no effect.
 
 <b>History support</b> allows tracking modification of the input shape in terms of Modified, IsDeleted and Generated. By default, the history is collected, but it is possible to disable it using the method *TrackHistory(false)*.
 On the low-level the history information is collected by the history tool *BRepTools_History*, which can be accessed through the method *BOPAlgo_RemoveFeatures::History()*. 
 
-<b>Error/Warning reporting system</b> - allows obtaining the extended overview of the Errors/Warnings occurred during the operation. As soon as any error appears the algorithm stops working. The warnings allow continuing the job, informing the user that something went wrong. The algorithm returns the following errors/warnings:
-* BOPAlgo_AlertUnsupportedType - the alert will be given as an error if the input shape does not contain any solids, and as a warning if the input shape contains not only solids, but also other shapes;
-* BOPAlgo_AlertNoFacesToRemove - the error alert is given in case there are no faces to remove from the shape (nothing to do);
-* BOPAlgo_AlertUnableToRemoveTheFeature - the warning alert is given to inform the user the removal of the feature is not possible. The algorithm will still try to remove the other features;
-* BOPAlgo_AlertRemoveFeaturesFailed - the error alert is given in case if the operation was aborted by the unknown reason.
+<b>Error/Warning reporting system</b> allows obtaining the extended overview of the Errors/Warnings occurred during the operation. As soon as any error appears, the algorithm stops working. The warnings allow continuing the job and informing the user that something went wrong. The algorithm returns the following errors/warnings:
+* *BOPAlgo_AlertUnsupportedType* - the alert will be given as an error if the input shape does not contain any solids, and as a warning if the input shape contains not only solids, but also other shapes;
+* *BOPAlgo_AlertNoFacesToRemove* - the error alert is given in case there are no faces to remove from the shape (nothing to do);
+* *BOPAlgo_AlertUnableToRemoveTheFeature* - the warning alert is given to inform the user the removal of the feature is not possible. The algorithm will still try to remove the other features;
+* *BOPAlgo_AlertRemoveFeaturesFailed* - the error alert is given in case if the operation was aborted by the unknown reason.
 
 For more information on the error/warning reporting system please see the chapter @ref occt_algorithms_ers "Errors and warnings reporting system" of Boolean operations user guide.
 
 <b>Parallel processing mode</b> - allows running the algorithm in parallel mode obtaining the result faster.
 
 The algorithm has certain limitations:
-* Intersection of the surfaces of the connected faces adjacent to the feature should not be empty. It means, that such faces should not be tangent to each other.
+* Intersection of the surfaces of the connected faces adjacent to the feature should not be empty. It means, that such faces should not be tangent to each other. 
 If the intersection of the adjacent faces will be empty, the algorithm will be unable to trim the faces correctly and, most likely, the feature will not be removed.
 * The algorithm does not process the INTERNAL parts of the solids, they are simply removed during reconstruction.
 
-Note, that for successful removal of the feature, the extended faces adjacent to the feature should cover the feature completely, otherwise the solids will not be rebuild.
+Note, that for successful removal of the feature, the extended faces adjacent to the feature should cover the feature completely, otherwise the solids will not be rebuild. 
 Take a look at the simple shape on the image below:
 @figure{/user_guides/modeling_algos/images/modeling_algos_rf_im001.png,"",220}
 
@@ -3234,7 +3234,7 @@ if (aDF.HasWarnings())                   // Check for the warnings
 const TopoDS_Shape& aResult = aDF.Shape(); // Result shape
 ~~~~
 
-To track the history of a shape use the API history methods:
+Use the API history methods to track the history of a shape:
 ~~~~
 // Obtain modification of the shape
 const TopTools_ListOfShape& BRepAlgoAPI_Defeaturing::Modified(const TopoDS_Shape& theS);
@@ -3246,17 +3246,15 @@ const TopTools_ListOfShape& BRepAlgoAPI_Defeaturing::Generated(const TopoDS_Shap
 Standard_Boolean BRepAlgoAPI_Defeaturing::IsDeleted(const TopoDS_Shape& theS);
 ~~~~
 
-For the usage of the Defeaturing algorithm on the Draw level the command <b>removefeatures</b> has been implemented.
+The command <b>removefeatures</b> allows using the Defeaturing algorithm on the Draw level.
 
-To track the history of a shape modification during Defeaturing the @ref occt_draw_hist "standard history commands" can be used.
+The @ref occt_draw_hist "standard history commands" can be used to track the history of shape modification during Defeaturing. 
 
-For more details on commands above please refer the @ref occt_draw_defeaturing "Defeaturing commands" of the Draw test harness user guide.
-
-To have possibility to access the error/warning shapes of the operation use the *bdrawwarnshapes* command before running the algorithm (see command usage in the @ref occt_algorithms_ers "Errors and warnings reporting system" of Boolean operations user guide).
+For more details on commands above, refer to the @ref occt_draw_defeaturing "Defeaturing commands" of the Draw test harness user guide.
 
 @subsection occt_modalg_defeaturing_examples Examples
 
-Here are the few examples of defeaturing of the ANC101 model:
+Here are the examples of defeaturing of the ANC101 model:
 
 @figure{/user_guides/modeling_algos/images/modeling_algos_rf_im004.png,"ANC101 model",220}</td>
 
index 914260f..26159ad 100644 (file)
@@ -1296,28 +1296,29 @@ The following sample code reads a shape from ASCII file and writes it to a binar
 
 @section occt_modat_6 Bounding boxes
 
-*Bounding box(es) (BndBox(es))* is used in many OCCT algorithms. In general, it is some filter to avoid check of excess interferences between pairs of shapes (check of interferences between BndBoxes is much simpler then between shapes and if BndBoxes do not interfere then there is no point in searching interferences between the corresponding shapes).
-Generally, BndBoxes can be divided on two main types: 
-  - axis-aligned BndBox (AABB). I.e. the box whose edges are parallel to the axes of World Coordinate System (WCS);
-  - oriented BndBox (OBB). I.e. not AABB.
-In fact, every AABB is a specific case of OBB.<br>
+Bounding boxes are used in many OCCT algorithms. The most common use is as a filter avoiding check of excess interferences between pairs of shapes (check of interferences between bounding boxes is much simpler then between shapes and if they do not interfere then there is no point in searching interferences between the corresponding shapes).
+Generally, bounding boxes can be divided into two main types: 
+  - axis-aligned bounding box (AABB) is the box whose edges are parallel to the axes of the World Coordinate System (WCS);
+  - oriented BndBox (OBB) is defined in its own coordinate system that can be rotated with respect to the WCS.
+Indeed, an AABB is a specific case of OBB.<br>
 
 The image below illustrates the example, when using OBB is better than AABB. 
 
 @figure{/user_guides/modeling_data/images/modeling_data_image015.png,"Illustrating the problem with AABB.",320}
 
-AABBs in this picture are interfered. Therefore, many OCCT-algorithms will spend much time to interfere the shapes. However, if we check OBBs, which are not interfered, then searching of interferences between the shapes will not be necessary. At that, creation and analysis of OBBs takes significantly more time than the analogical operations with AABB.
+AABBs in this picture are interfered. Therefore, many OCCT algorithms will spend much time to interfere the shapes. However, if we check OBBs, which are not interfered, then searching of interferences between the shapes will not be necessary. At that, creation and analysis of OBBs takes significantly more time than the analogical operations with AABB.
 
-Later in this section, the BndBox having the smallest surface area will be called as <b> optimal </b>.
+Later in this section, the bounding boxes having the smallest surface area will be called *optimal*.
 
-In OCCT, BndBox(es) are described in Bnd package. In general, Bnd_Box class describes AABB, Bnd_OBB class describes OBB. These classes contain the following common methods (this list is not complete; please see the documentation about corresponding class for detailed information):
+In OCCT, bounding boxes are defined in *Bnd* package. *Bnd_Box* class defines AABB, *Bnd_OBB* class defines OBB. These classes contain the following common methods (this list is not complete; see the documentation about the corresponding class for detailed information):
 
-  - SetVoid() and IsVoid(). SetVoid method clears the existing BndBox. IsVoid method indicates whether the BndBox is initialized.
-  - Enlarge(...). Extends the current BndBox.
-  - Add(...). Rebuilds the current BndBox in order to cover all previous objects (which it was created from) and the argument of the method.
-  - IsOut(...). Checks whether the argument is inside/outside of the current BndBox.
+  - *IsVoid* method indicates whether the bounding box is empty (uninitialized).
+  - *SetVoid* method clears the existing bounding box.
+  - *Enlarge(...)* extends the current bounding box.
+  - *Add(...)* extends the bounding box as necessary to include the object (a point, a shape, etc.) passed as the argument.
+  - *IsOut(...)* checks whether the argument is inside/outside of the current BndBox.
   
-Also, BRepBndLib class contains methods to provide creation of BndBox (both AABB and OBB) from the complex shape. 
+BRepBndLib class contains methods for creation of bounding boxes (both AABB and OBB) from the shapes.
 
 @subsection occt_modat_6_1 Brief description of some algorithms working with OBB
 
@@ -1340,22 +1341,22 @@ Further, let us consider the triangle \f$ T_{0}\left \langle p_{0}, p_{1}, p_{2}
 <span>10.</span> Compute the center of OBB and its half dimensions.<br>
 <span>11.</span> Create OBB using the center, axes and half dimensions.<br>
 
-This algorithm is realized in Bnd_OBB::ReBuild(...) method.
+This algorithm is implemented in the *Bnd_OBB::ReBuild(...)* method.
 
 @subsubsection occt_modat_6_1_2 Creation of OBB based on Axes of inertia
 
 The algorithm contains the following steps:
 1. Calculate three inertia axes, which will be the axes of the OBB.
-2. Transform the source object (TopoDS_Shape) into the local coordinate system based on the axes from item 1.
+2. Transform the source object *(TopoDS_Shape)* into the local coordinate system based on the axes from item 1.
 3. Create an AABB for the shape obtained in the item 2.
-4. Compute the center of AABB and its half dimensions
-5. Transform the center into the WCS
+4. Compute the center of AABB and its half dimensions.
+5. Transform the center into the WCS.
 6. Create OBB using the center, axes and half dimensions.
 
 @subsubsection occt_modat_6_1_3 Method IsOut for a point
 
 1. Project the point to each axis.
-2. Check, whether the absolute value of the projection parameter greater than the correspond half-dimension. In this case, IsOut method will return TRUE.
+2. Check, whether the absolute value of the projection parameter greater than the correspond half-dimension. In this case, *IsOut* method will return TRUE.
 
 @subsubsection occt_modat_6_1_4 Method IsOut for another OBB
 
@@ -1366,27 +1367,27 @@ The algorithm of analyzing axis \f$ \mathbf{l} \f$ is following:
 
 If OBBs are not interfered in terms of at least one axis (of 15) then they are not interfered at all.
 
-@subsubsection occt_modat_6_1_5 Method Add for point or another BndBox
+@subsubsection occt_modat_6_1_5 Method Add for point or another bounding box
 
-Create new OBB (see the section @ref occt_modat_6_1_1) based on the source point and all vertices of the given BndBoxes.
+Create a new OBB (see the section @ref occt_modat_6_1_1) based on the source point and all vertices of the given bounding boxes.
 
 @subsection occt_modat_6_2 Add a shape
 
-Method BRepBndLib::AddOBB(...) allows creating BndBox from the complex object (TopoDS_Shape). This method uses both algorithms described in the sections @ref occt_modat_6_1_1 and sections @ref occt_modat_6_1_2.
+Method *BRepBndLib::AddOBB(...)* allows creating the bounding box from a complex object *(TopoDS_Shape)*. This method uses both algorithms described in the sections @ref occt_modat_6_1_1 and sections @ref occt_modat_6_1_2.
 
-The first algorithm is used if the shape outer shell can be represented by a set of points contained in the shape. Namely, only the following elements are the source of set of points:
+The first algorithm is used if the outer shell of the shape can be represented by a set of points contained in it. Namely, only the following elements are the source of set of points:
 
   - Nodes of triangulation;
-  - Nodes of Poly_Polygon3D;
-  - Vertices of edges with linear 3D-curve lying in the planar face;
-  - Vertices of edges with linear 3D-curve if the source shape does not contain more complex topological structure (e.g. the source shape is a compound of edges);
-  - Vertices if the source shape does not contain more complex topological structure (e.g. the source shape is a compound of vertices).
+  - Nodes of *Poly_Polygon3D*;
+  - Vertices of edges with a linear 3D-curve lying in the planar face;
+  - Vertices of edges with a linear 3D-curve if the source shape does not contain a more complex topological structure (e.g. the source shape is a compound of edges);
+  - Vertices if the source shape does not contain a more complex topological structure (e.g. the source shape is a compound of vertices).
 
-If required set of points cannot be extracted then the algorithm from section @ref occt_modat_6_1_2 is used for OBB creation.
+If the required set of points cannot be extracted then the algorithm from section @ref occt_modat_6_1_2 is used for OBB creation.
 
-The package BRepBndLib contains the methods BRepBndLib::Add(...), BRepBndLib::AddClose(...) and BRepBndLib::AddOptimal(...) for creation of AABB of a shape. Please see reference manual for detailed information.
+The package *BRepBndLib* contains methods *BRepBndLib::Add(...), BRepBndLib::AddClose(...)* and *BRepBndLib::AddOptimal(...)* for creation of AABB of a shape. See the reference manual for the detailed information.
 
 @subsection occt_modat_6_3 Limitations of algorithm for OBB creation.
 
-1. The algorithm described in the section @ref occt_modat_6_1_1 works significantly better (finds resulting OBB with less surface area) and faster than the algorithm from the section @ref occt_modat_6_1_2. Nevertheless, (in general) the result returned by both algorithms is not always optimal (i.e. sometimes another OBB exists having less surface area). Moreover, the first method does not allow computing OBB of shapes with complex geometry.
-2. Currently, the algorithm of OBB creation is implemented for objects in 3D-space only.
+1. The algorithm described in the section @ref occt_modat_6_1_1 works significantly better (finds resulting OBB with less surface area) and faster than the algorithm from the section @ref occt_modat_6_1_2. Nevertheless, (in general) the result returned by both algorithms is not always optimal (i.e. sometimes another OBB exists with a smaller surface area). Moreover, the first method does not allow computing OBBs of shapes with a complex geometry.
+2. Currently, the algorithm of OBB creation is implemented for objects in 3D space only.
index 2769a97..8fb5b37 100644 (file)
@@ -138,7 +138,7 @@ Selectable object stores information about all created selection modes and sensi
 All successors of a selectable object must implement the method that splits its presentation into sensitive entities according to the given mode. The computed entities are arranged in one selection and added to the list of all selections of this object. No selection will be removed from the list until the object is deleted permanently.
 
 For all standard OCCT shapes, zero mode is supposed to select the whole object (but it may be redefined easily in the custom object). For example, the standard OCCT selection mechanism and *AIS_Shape* determine the following modes:
-  - 0 -- selection of entire object (AIS_Shape);
+  - 0 -- selection of the entire object *(AIS_Shape)*;
   - 1 -- selection of the vertices;
   - 2 -- selection of the edges;
   - 3 -- selection of the wires;
@@ -765,10 +765,10 @@ theCtx->SetDisplayMode (2, true);
 The Local Selection is defined by index (Selection Mode). The Selection Modes implemented by a specific interactive object and their meaning should be checked within the documentation of this class.
 See, for example, *MeshVS_SelectionModeFlags* for *MeshVS_Mesh* object.
 
-The interactive object, which is used the most by applications, is *AIS_Shape*. Consequently, there are standard functions, which allow you to easily prepare selection operations on the constituent elements of shapes (selection of vertices, edges, faces, etc.). The Selection Mode for a specific shape type (*TopAbs_ShapeEnum*) is returned by method *AIS_Shape::SelectionMode()*.
+*AIS_Shape* is the most used interactive object. It provides API to manage selection operations on the constituent elements of shapes (selection of vertices, edges, faces, etc.). The Selection Mode for a specific shape type (*TopAbs_ShapeEnum*) is returned by method *AIS_Shape::SelectionMode()*.
 
-The function *AIS_InteractiveObject::Display* (without argument taking Selection Mode) activates the object's default Selection Mode.
-The functions *AIS_InteractiveContext::Activate* and *AIS_InteractiveContext::Deactivate* activate and deactivate specific Selection Mode.
+The method *AIS_InteractiveObject::Display()* without a Selection Mode argument activates the default Selection Mode of the object.
+The methods *AIS_InteractiveContext::Activate()* and *AIS_InteractiveContext::Deactivate()* activate and deactivate a specific Selection Mode.
 
 More than one Selection Mode can be activated at the same time (but default 0 mode for selecting entire object is exclusive - it cannot be combined with others).
 The list of active modes can be retrieved using function *AIS_InteractiveContext::ActivatedModes*.
@@ -843,8 +843,8 @@ After using the *Select* and *ShiftSelect* functions, you can explore the list o
   * *AIS_InteractiveContext::NextSelected* -- moves the iterator to the next position;
   * *AIS_InteractiveContext::SelectedOwner* -- returns an entity at the current iterator position.
 
-The owner object *SelectMgr_EntityOwner* is a key object identifying selectable entitiy in the viewer (returned by methods *AIS_InteractiveContext::DetectedOwner* and *AIS_InteractiveContext::SelectedOwner*).
-The Interactive Object itself can be retrieved by method *SelectMgr_EntityOwner::Selectable*, while identifying sub-part depends on type of Interactive Object.
+The owner object *SelectMgr_EntityOwner* is a key object identifying the selectable entity in the viewer (returned by methods *AIS_InteractiveContext::DetectedOwner* and *AIS_InteractiveContext::SelectedOwner*).
+The Interactive Object itself can be retrieved by method *SelectMgr_EntityOwner::Selectable*, while identifying a sub-part depends on the type of Interactive Object.
 In case of *AIS_Shape*, the (sub)shape is returned by method *StdSelect_BRepOwner::Shape*.
 
 #### Example
@@ -1121,9 +1121,9 @@ The root is the top of a structure hierarchy or structure network. The attribute
   * Have a type, a scale factor, and a color,
   * Have a size, shape, and orientation independent of transformations.
 * **Triangulation**
-  * Have at least three vertices,
-  * Have nodal normals defined for shading,
-  * Have interior attributes -- style, color, front and back material, texture and reflection ratio,
+  * Has at least three vertices,
+  * Has nodal normals defined for shading,
+  * Has interior attributes -- style, color, front and back material, texture and reflection ratio.
 * **Polylines** or **Segments**
   * Have two or more vertices,
   * Have the following attributes -- type, width scale factor, color.
@@ -1196,7 +1196,7 @@ aGroup->SetGroupPrimitivesAspect (myDrawer->ShadingAspect()->Aspect());
 
 @subsubsection occt_visu_4_2_5 Text primitive
 
-TKOpenGL toolkit renders text labels using texture fonts. *Graphic3d* text primitives have the following features:
+*TKOpenGL* toolkit renders text labels using texture fonts. *Graphic3d* text primitives have the following features:
   * fixed size (non-zoomable) or zoomable,
   * can be rotated to any angle in the view plane,
   * support unicode charset.
@@ -1213,8 +1213,16 @@ void Graphic3d_Group::Text (const Standard_CString theText,
                             const Graphic3d_VerticalTextAlignment theVta,
                             const Standard_Boolean theToEvalMinMax);
 ~~~~~
-*theText* parameter is the text string, *thePoint* is the three-dimensional position of the text, *theHeight* is the text height, *theAngle* is the orientation of the text (at the moment, this parameter has no effect, but you can specify the text orientation through  the *Graphic3d_AspectText3d* attributes).
-*theTp* parameter defines the text path, *theHta* is the horizontal alignment of the text, *theVta* is the vertical alignment of the text.
+
+The meaning of these parameters is as follows: 
+* *theText* - the text string,
+* *thePoint* - the three-dimensional position of the text,
+* *theHeight* - the text height,
+* *theAngle* - the text orientation (at the moment, this parameter has no effect, but you can specify the text orientation through the *Graphic3d_AspectText3d* attributes).
+* *theTp* defines the text path,
+* *theHta* - the horizontal alignment of the text,
+* *theVta* - the vertical alignment of the text.
+
 You can pass FALSE as *theToEvalMinMax* if you do not want the graphic3d structure boundaries to be affected by the text position.
 
 **Note** that the text orientation angle can be defined by *Graphic3d_AspectText3d* attributes.
index c649114..3455f32 100644 (file)
@@ -100,7 +100,7 @@ for the Representation and Presentation of Product Manufacturing Information (PM
 XDE can read and write GD\&T data of the following types:
 * dimensions, such as distance, length, radius and so on;
 * geometric tolerances;
-* datums, i.e a theoretically exact geometric references, such as point, line or plane, to which toleranced features are related.
+* datums, i.e theoretically exact geometric references, such as point, line or plane, to which toleranced features are related.
 
 XDE supports two presentations of GD\&T data:
 * semantic presentation, i.e. data is stored in a machine-consumable way and includes all information required to understand the
@@ -116,7 +116,7 @@ XDE provides capabilities for adding, editing and removing clipping planes.
 
 @subsection occt_xde_1_9 Saved views
 
-XDE supports reading from STEP views. Views allow to save information about camera parameters (position, direction, zoom factor, etc.)
+XDE supports reading from STEP views. Views allow saving information about camera parameters (position, direction, zoom factor, etc.)
 and visible shapes, PMIs, used clipping planes and notes. Currently, XDE supports saving of clipping planes in XBF format only.
 
 XDE provides the following view management capabilities:
@@ -677,7 +677,7 @@ Each GD\&T entity then corresponds to the dedicated label, the property itself i
   * *XCAFDimTolObject_GeomToleranceObject* - for geometric tolerances;
   * *XCAFDimTolObject_DatumObject* - for geometric tolerance Datums.
 
-GD\&Ts and Shapes are related to by Graph Nodes. 
+GD\&Ts and Shapes are related by Graph Nodes. 
 
 These definitions are common to various exchange formats, at least for STEP. 
 
@@ -710,7 +710,7 @@ A similar approach can be used for other GD\&T types.
 
 @subsubsection occt_xde_2_7_3 Editing a GD\&T
 A newly added GD\&T entity is empty. To set its data a corresponding access object should be used as it is demonstrated
-below, where the dimension becomes the linear distance between two points.
+below, where the dimension becomes a linear distance between two points.
 ~~~~~
 Handle(XCAFDoc_Dimension) aDimAttr;
 aDimLabel.FindAttribute(XCAFDoc_Dimension::GetID(), aDimAttr);
@@ -732,7 +732,7 @@ A similar approach can be used for other GD\&T types.
 To link a GD\&T entity with other OCAF labels (e.g. representing shapes) one should use the following methods:
   * *SetDimension* - for dimensions;
   * *SetGeomTolerance* - for geometric tolerances;
-  * SetDatum - for geometric tolerance datums.
+  * *SetDatum* - for geometric tolerance datums.
 
 These methods can take a single label or a sequence of labels. All previous links will be removed.
 
@@ -751,7 +751,7 @@ In addition, a special method *SetDatumToGeomTol* should be used to link a datum
 @subsubsection occt_xde_2_7_5 Finding GD\&Ts and reference shapes
 
 *XCAFDimTolObjects_Tool* class provides basic capabilities for searching GD\&Ts linked to shapes.
-Using the tool one can get sequences of dimensions, geometric tolerances and datums linked with a shape. A series of related datums is also returned for geometric tolerances.
+The tool provides sequences of dimensions, geometric tolerances and datums linked with a shape. A series of related datums is also returned for geometric tolerances.
 
 To get reference shapes for a GD\&T entity one can use *GetRefShapeLabel* from *XCAFDoc_DimTolTool*.
 
@@ -798,7 +798,7 @@ if (!myClipPlaneTool->RemoveClippingPlane(aClipPlnLbl))
 ~~~~~
 The plane will not be removed if it is referenced in at least one view.
 
-To change clipping plane and its name use *UpdateClippingPlane* method, e.g.:
+To change the clipping plane and its name use *UpdateClippingPlane* method, e.g.:
 ~~~~~
 gp_Pln aPln = ...
 myClipPlaneTool->UpdateClippingPlane(aClipPlnLbl, aPln, "New name of plane");
@@ -810,7 +810,7 @@ Standard_Boolean aCapping = ...
 myClipPlaneTool->SetCapping(aClipPlnLbl, aCapping);
 ~~~~~
 
-*XCAFDoc_ClippingPlaneTool* can be used to get all clipping plane labels and to check if a label belongs to the ClippingPlane table, e.g.:
+*XCAFDoc_ClippingPlaneTool* can be used to get all clipping plane labels and to check if a label belongs to the *ClippingPlane table*, e.g.:
 ~~~~~
 TDF_LabelSequence aClipPlaneLbls;
 myClipPlaneTool->GetClippingPlanes(aClipPlaneLbls);
@@ -834,7 +834,7 @@ for (TDF_LabelSequence::Iterator anIt(aClipPlaneLbls); anIt.More(); anIt.Next())
 
 @subsection occt_xde_2_9 Saved views
 
-In an XDE document, Views are managed by the class *XCAFDoc_ViewTool*. It works basing on the same principles as ShapeTool works with Shapes. This tool can be provided on the Main Label or on any sub-label. Views are stored in a child of the starting document label 0.1.7, where a view itself is defined as *XCAFDoc_View* sub-class of *TDF_Attribute*. Views and selected shapes, clipping planes, GD\&Ts and notes are related to by Graph Nodes.
+In an XDE document, Views are managed by the class *XCAFDoc_ViewTool*. It works basing on the same principles as ShapeTool works with Shapes. This tool can be provided on the Main Label or on any sub-label. Views are stored in a child of the starting document label 0.1.7, where a view itself is defined as *XCAFDoc_View* sub-class of *TDF_Attribute*. Views and selected shapes, clipping planes, GD\&Ts and notes are related by Graph Nodes.
 
 To query, edit, or initialize a Document to handle views of XCAF, use: 
 ~~~~~
@@ -899,11 +899,11 @@ To get shapes, clipping planes, GD\&Ts or notes associated with a particular vie
   * *GetRefAnnotationLabel* - returns a sequence of associated annotated labels.
 
 And vice versa, to get views that display a particular clipping plane, GD\&T or note use the following methods:
-  * *GetViewLabelsForShape* - returns a sequence of associated view labels for a shape;
-  * *GetViewLabelsForGDT* - returns a sequence of associated view labels for a GD\&T;
-  * *GetViewLabelsForClippingPlane* - returns a sequence of associated view labels for a clipping plane;
-  * *GetViewLabelsForNote* - returns a sequence of associated view labels for a note;
-  * *GetViewLabelsForAnnotation* - returns a sequence of associated view labels for an annotated label.
+  * *GetViewLabelsForShape* - returns a sequence of view labels associated with a shape;
+  * *GetViewLabelsForGDT* - returns a sequence of view labels associated with a GD\&T;
+  * *GetViewLabelsForClippingPlane* - returns a sequence of view labels associated with a clipping plane;
+  * *GetViewLabelsForNote* - returns a sequence of view labels associated with a note;
+  * *GetViewLabelsForAnnotation* - returns a sequence of view labels associated with an annotated label.
 
 @subsection occt_xde_2_10 Custom notes