0025674: Debug dev guide: misprint in Saving and dumping shapes and geometric objects...

Documentation changes and improvements suggested in bugs 25674, 25702 and 25882.
Some corrections for new content in debug.md

diff --git a/dox/dev_guides/contribution_workflow/contribution_workflow.md b/dox/dev_guides/contribution_workflow/contribution_workflow.md
index 5e0d6b206759d85f8482d5243e276bb34928ae1c..e8429c8e6b7d7cf4000fd2f70d1648515a9e8c1f 100644 (file)
--- a/dox/dev_guides/contribution_workflow/contribution_workflow.md
+++ b/dox/dev_guides/contribution_workflow/contribution_workflow.md
@@ -204,7 +204,7 @@ The definition of the following attributes is obligatory:
   | 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.                                |
+  | Unable to reproduce   | The 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  |

diff --git a/dox/dev_guides/debug/debug.md b/dox/dev_guides/debug/debug.md
index 1f43b8f4f133db6e48a0faf65a9e54b2f385456d..e1e4838f0498886ab81f125938d8a7d97c5d349f 100644 (file)
--- a/dox/dev_guides/debug/debug.md
+++ b/dox/dev_guides/debug/debug.md
@@ -85,7 +85,7 @@ const char* BRepTools_Write (const char* theFileNameStr, void* theShapePtr)
 ~~~~~
 
 Saves the specified shape to a file with the given name.
-- *theFileNameStr* - the DRAW interpreter variable name to set.
+- *theFileNameStr* - the name of the file where the shape is saved.
 - *theShapePtr* - a pointer to *TopoDS_Shape* variable.
 
 ~~~~~
@@ -104,7 +104,7 @@ const char* BRepMesh_Dump (void* theMeshHandlePtr, const char* theFileNameStr)
 
 Stores mesh produced in parametric space to BREP file.
 - *theMeshHandlePtr* - a pointer to *Handle(BRepMesh_DataStructureOfDelaun)* variable.
-- *theFileNameStr* - name of file the mesh sould be stored to.
+- *theFileNameStr* - the name of the file where the mesh is stored.
 
 The following additional function is provided by *TKGeomBase* toolkit:
 
@@ -274,16 +274,17 @@ In Visual Studio 2012 and later, visualizers can be put in a separate file in su
 @section occt_debug_perf Performance measurement tools
 
 It is recommended to use specialized performance analysis tools to profile OCCT and application code.
-However, when such tools are not available or cannot be used for some reason, tools provided by OCD package can be used: see low-level C functions and macros defined OSD_PerfMeter.h, and OSD_PerfMeter class.
-
-This tool maintains an array of 100 global performance counters that can be started and stopped independently.
-Adding performance counter to a function of interest allows to get statistics on number of calls and total execution time of the function.
-In C++ code, this can be achieved by creating local variable OSD_PerfMeter in each block of code to be measured.
-In C or Fortran code, use functions perf_start_meter and perf_stop_meter to start and stop the counter.
-Note that this instrumentation is intended to be removed when profiling is completed.
-Macros provided in OSD_PerfMeter.h can be used to keep instrumentation code permanently, but enable it only when macro PERF_ENABLE_METERS is defined.
+However, when such tools are not available or cannot be used for some reason, tools provided by OSD package can be used: low-level C functions and macros defined in *OSD_PerfMeter.h* and *OSD_PerfMeter* class.
+
+This tool maintains an array of 100 global performance counters that can be started and stopped independently. Adding a performance counter to a function of interest allows to get statistics on the number of calls and the total execution time of the function.
+* In C++ code, this can be achieved by creating local variable *OSD_PerfMeter* in each block of code to be measured.
+* In C or Fortran code, use functions *perf_start_meter* and *perf_stop_meter* to start and stop the counter.
+
+Note that this instrumentation is intended to be removed when the profiling is completed.
+
+Macros provided in *OSD_PerfMeter.h* can be used to keep instrumentation code permanently but enable it only when macro *PERF_ENABLE_METERS* is defined.
 Each counter has its name shown when the collected statistics are printed.
 
-In DRAW, use command dperf to prints all performance statistics.
+In DRAW, use command *dperf* to print all performance statistics.
 
 Note that performance counters are not thread-safe.

diff --git a/dox/user_guides/draw_test_harness/draw_test_harness.md b/dox/user_guides/draw_test_harness/draw_test_harness.md
index 2e99346874647777682ca25953901a9cbfee29d2..5d6beb610210e9896c18e2cf444e6ca1996b5142 100644 (file)
--- a/dox/user_guides/draw_test_harness/draw_test_harness.md
+++ b/dox/user_guides/draw_test_harness/draw_test_harness.md
@@ -1447,7 +1447,7 @@ Returns the number of selected objects in the interactive context.
 
 Syntax:     
 ~~~~~
-valntialiasing 1|0
+vantialiasing 1|0
 ~~~~~
 Sets antialiasing if the command is called with 1 or unsets otherwise.
 

diff --git a/dox/user_guides/modeling_data/modeling_data.md b/dox/user_guides/modeling_data/modeling_data.md
index 309350faa666886dd8b8f2c17f071cb4ad6d7967..1cd63326b34a26b5825cf3813b62b47c47ccd5dc 100644 (file)
--- a/dox/user_guides/modeling_data/modeling_data.md
+++ b/dox/user_guides/modeling_data/modeling_data.md
@@ -648,7 +648,7 @@ The following methods are available:
 
 Note that the B-spline curve and surface are accepted but they are not cut into pieces of the desired continuity. It is the global continuity, which is seen. 
 
-@subsection occt_modat_5 Adaptors for Curves and Surfaces
+@subsection occt_modat_4_4 Adaptors for Curves and Surfaces
 
 Some Open CASCADE Technology general algorithms may work theoretically on numerous types of curves or surfaces. 
 

diff --git a/dox/user_guides/ocaf/images/ocaf_image015.png b/dox/user_guides/ocaf/images/ocaf_image015.png
index f5c2785fa87943fecf2b97a97809ae8434618be0..86d3e49b98f66617917edf7c25a55e14cc12aa0d 100644 (file)
Binary files a/dox/user_guides/ocaf/images/ocaf_image015.png and b/dox/user_guides/ocaf/images/ocaf_image015.png differ

diff --git a/dox/user_guides/ocaf/ocaf.md b/dox/user_guides/ocaf/ocaf.md
index 67627ca7fd7a00020f9cfeb750006b4ccea9ca0f..012b88926f473c3201954bc12de46ffae8f37c3c 100644 (file)
--- a/dox/user_guides/ocaf/ocaf.md
+++ b/dox/user_guides/ocaf/ocaf.md
@@ -703,7 +703,7 @@ Consider the following example. Two boxes (solids) are fused into one solid (the
 
 After the fuse operation a modified result is placed to a separate label as a named shape, which refers to the old shape – one of the boxes, as well as to the new shape – the shape resulting from the fuse operation – and has evolution MODIFY (see the following figure). 
 
-Named shapes, which contain information about modified faces, belong to the fuse result sub-labels: sub-label with tag 1 – modified faces of the first box, sub-label with tag 2 – generated faces of the box 2. 
+Named shapes, which contain information about modified faces, belong to the fuse result sub-labels: sub-label with tag 1 – modified faces from box 1, sub-label with tag 2 – modified faces from box 2. 
 
 @image html /user_guides/ocaf/images/ocaf_image015.png
 @image latex /user_guides/ocaf/images/ocaf_image015.png