diff --git a/dox/dev_guides/contribution_workflow/contribution_workflow.md b/dox/dev_guides/contribution_workflow/contribution_workflow.md index 5e0d6b2067..e8429c8e6b 100644 --- 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 1f43b8f4f1..e1e4838f04 100644 --- 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. +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 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. +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 2e99346874..5d6beb6102 100644 --- 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 309350faa6..1cd63326b3 100644 --- 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 f5c2785fa8..86d3e49b98 100644 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 67627ca7fd..012b88926f 100644 --- 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