From: ysn Date: Mon, 9 Jul 2018 10:53:01 +0000 (+0300) Subject: 0029817: Documentation - avoid excessive use of "please" X-Git-Tag: OCCT_VC2017_73~65 X-Git-Url: http://git.dev.opencascade.org/gitweb/?p=occt.git;a=commitdiff_plain;h=07f2b74116b0a121386227b2e73dc2fae627cd4b 0029817: Documentation - avoid excessive use of "please" "Please" is now used in the documentation only in sensitive cases. --- diff --git a/dox/dev_guides/documentation/documentation.md b/dox/dev_guides/documentation/documentation.md index 4f12941c57..fb8af80d2c 100644 --- a/dox/dev_guides/documentation/documentation.md +++ b/dox/dev_guides/documentation/documentation.md @@ -134,7 +134,7 @@ Add a relative path to *svn.md* in file dox/FILES.txt. For instance dev_guides/svn/svn.md @endverbatim -**Note** that the order of paths to documents in *FILES.txt* is reproduced in the Table of Contents in the HTML output. Please, place them logically. +**Note** that the order of paths to documents in *FILES.txt* is reproduced in the Table of Contents in the HTML output, thus they need to be placed logically. **Note** that you should specify a file tag, not the document name. See @ref OCCT_DM_SECTION_A_1 "Header and hierarchic document structure" section for details. @@ -180,7 +180,7 @@ For example: @subsubsection occt_ocaf_1_1_1 The document and the data framework @endverbatim -Please, note that section names can be used for references within the document and in other documents, so it is necessary to use the common prefix indicative of the document name for all section names in the given document. +**Note** that section names can be used for references within the document and in other documents, so it is necessary to use the common prefix indicative of the document name for all section names in the given document. For example, *occt_ocaf* for sections in Open CASCADE Application Framework manual. The remaining part of section names in most documents consists only of numbers, for example *1_1*. Actually, the hierarchical structure of the output table of contents is not based on these numbers and is generated automatically. diff --git a/dox/dev_guides/git_guide/git_guide.md b/dox/dev_guides/git_guide/git_guide.md index f608890003..4f9fa7a5b1 100644 --- a/dox/dev_guides/git_guide/git_guide.md +++ b/dox/dev_guides/git_guide/git_guide.md @@ -11,14 +11,13 @@ Guide to installing and using Git for OCCT development {#occt_dev_guides__git_gu 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. + It can be useful to learn more about Git concepts and tools from a book a or manual. 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 + Familiarize yourselves with the @ref occt_dev_guides__contribution_workflow "Contribution Workflow document" that describes how Git is used for processing contributions to OCCT. This and related documents are available at the Resources page @@ -83,7 +82,7 @@ The official repository contains: @subsection occt_gitguide_1_5 Version of Git The repository is tested to work with Git 1.7.6 and above. - Please do not use versions below 1.7.1 as they are known to cause troubles. + Avoid using versions below 1.7.1 as they are known to cause troubles. @section occt_gitguide_2 Installing Tools for Work with Git @@ -250,7 +249,7 @@ Click **Save** to input the key to the system. It is typical to use your e-mail address or workstation name for this field; no restrictions are set by the portal. - Please note that some time (5-10 min) is needed for the system + **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. diff --git a/dox/dev_guides/upgrade/upgrade.md b/dox/dev_guides/upgrade/upgrade.md index d89f2791f7..47c6cde518 100644 --- a/dox/dev_guides/upgrade/upgrade.md +++ b/dox/dev_guides/upgrade/upgrade.md @@ -51,7 +51,7 @@ for (Standard_Integer aGr = 1; aGr <= aLen; ++aGr) * All occurrences of *Select3D_Projector* in the application code (if any) should be replaced with *Handle(Select3D_Projector)*. * The code of inheritors of *Select3D_SensitiveEntity* should be updated if they override Matches() (this is probable, if clipping planes are used). -* Constructor for *V3d_Plane* has been changed, so the extra argument should be removed if used in the application. It is necessary to add a new plane using method *V3d_Viewer::AddPlane()* if *V3d_Viewer* has been used to manage clipping planes list (this does not affect clipping planes representation). Please, have a look at the source code for new DRAWEXE *vclipplane* command in *ViewerTest_ObjectsCommands.cxx, VClipPlane* to see how clipping planes can be managed in the application. +* Constructor for *V3d_Plane* has been changed, so the extra argument should be removed if used in the application. It is necessary to add a new plane using method *V3d_Viewer::AddPlane()* if *V3d_Viewer* has been used to manage clipping planes list (this does not affect clipping planes representation). Have a look at the source code for new DRAWEXE *vclipplane* command in *ViewerTest_ObjectsCommands.cxx, VClipPlane* to see how clipping planes can be managed in the application. @section upgrade_652 Upgrade to OCCT 6.5.2 @@ -112,14 +112,14 @@ Porting of user applications from an earlier OCCT version to version 6.6.0 requi It is necessary to introduce the corresponding changes in the applications for which the order of sub-shapes resulting from a Boolean operation is important. It is strongly recommended to use identification methods not relying on the order of sub-shapes (e.g. OCAF naming). * If you need to use OCCT on Mac OS X with X11 (without Cocoa), build OCCT with defined pre-processor macro *CSF_MAC_USE_GLX11*. XLib front-end (previously the only way for unofficial OCCT builds on Mac OS X) is now disabled by default on this platform. If your application has no support for Cocoa framework you may build OCCT with XLib front-end adding *MACOSX_USE_GLX* macro to compiler options (you may check the appropriate option in WOK configuration GUI and in CMake configuration). Notice that XQuartz (XLib implementation for Mac OS X) now is an optional component and does not provide a sufficient level of integrity with native (Cocoa-based) applications in the system. It is not possible to build OCCT with both XLib and Cocoa at the same time due to symbols conflict in OpenGL functions. * Animation mode and degeneration presentation mode (simplified presentation for animation) and associated methods have been removed from 3D viewer functionality. -Correspondingly, the code using methods *SetAnimationModeOn(), SetAnimationModeOff(), AnimationModeIsOn(), AnimationMode(), Tumble(), SetDegenerateModeOn(), SetDegenerateModeOff()* and *DegenerateModeIsOn()* of classes *V3d_View* and *Visual3d_View* will need to be removed or redesigned. Please, notice that Hidden Line Removal presentation was not affected; however, the old code that used methods *V3d_View::SetDegenerateModeOn* or *V3d_View::SetDegenerateModeOff* to control HLR presentation should be updated to use *V3d_View::SetComputedMode* method instead. +Correspondingly, the code using methods *SetAnimationModeOn(), SetAnimationModeOff(), AnimationModeIsOn(), AnimationMode(), Tumble(), SetDegenerateModeOn(), SetDegenerateModeOff()* and *DegenerateModeIsOn()* of classes *V3d_View* and *Visual3d_View* will need to be removed or redesigned. Hidden Line Removal presentation was not affected; however, the old code that used methods *V3d_View::SetDegenerateModeOn* or *V3d_View::SetDegenerateModeOff* to control HLR presentation should be updated to use *V3d_View::SetComputedMode* method instead. * Calls of *Graphic3d_Group::BeginPrimitives()* and *Graphic3d_Group::EndPrimitives()* should be removed from the application code. * Application functionality for drawing 2D graphics that was formerly based on *TKV2d* API should be migrated to *TKV3d* API. The following changes are recommended for this migration: * A 2D view can be implemented as a *V3d_View* instance belonging to *V3d_Viewer* managed by *AIS_InteractiveContext* instance. To turn *V3d_View* into a 2D view, the necessary view orientation should be set up at the view initialization stage using *V3d_View::SetProj()* method, and view rotation methods simply should not be called. * Any 2D graphic entity (formerly represented with *AIS2D_InteractiveObject*) should become a class derived from *AIS_InteractiveObject* base. These entities should be manipulated in a view using *AIS_InteractiveContext* class API. * All drawing code should be put into *Compute()* virtual method of a custom interactive object class and use API of *Graphic3d* package. In particular, all geometry should be drawn using class hierarchy derived from *Graphic3d_ArrayOfPrimitives*. Normally, the Z coordinate for 2D geometry should be constant, unless the application implements some advanced 2D drawing techniques like e.g. multiple "Z layers" of drawings. * Interactive selection of 2D presentations should be set up inside *ComputeSelection()* virtual method of a custom interactive object class, using standard sensitive entities from *Select3D* package and standard or custom entity owners derived from *SelectMgr_EntityOwner* base. -Please refer to the Visualization User's Guide for further details concerning OCCT 3D visualization and selection classes. See also *Viewer2D* OCCT sample application, which shows how 2D drawing can be implemented using TKV3d API. +Refer to the Visualization User's Guide for further details concerning OCCT 3D visualization and selection classes. See also *Viewer2D* OCCT sample application, which shows how 2D drawing can be implemented using TKV3d API. * Run-time graphic driver library loading mechanism based on *CSF_GraphicShr* environment variable usage has been replaced by explicit linking against *TKOpenGl* library. The code sample below shows how the graphic driver should be created and initialized in the application code: ~~~~ // initialize a new viewer with OpenGl graphic driver @@ -161,10 +161,10 @@ Porting of user applications from an earlier OCCT version to version 6.7.0 requi @subsection upgrade_670_clipping Object-level clipping and capping algorithm. -* It might be necessary to revise and port code related to management of view-level clipping to use *Graphic3d_ClipPlane* instead of *V3d_Plane* instances. Please note that *V3d_Plane* class has been preserved -- as previously, it can be used as plane representation. Another approach to represent *Graphic3d_ClipPlane* in a view is to use custom presentable object. -* The list of arguments of *Select3D_SensitiveEntity::Matches()* method for picking detection has changed. Since now, for correct selection clipping, the implementations should perform a depth clipping check and return (as output argument) minimum depth value found at the detected part of sensitive. Please refer to CDL / Doxygen documentation to find descriptive hints and snippets. +* It might be necessary to revise and port code related to management of view-level clipping to use *Graphic3d_ClipPlane* instead of *V3d_Plane* instances. Note that *V3d_Plane* class has been preserved -- as previously, it can be used as plane representation. Another approach to represent *Graphic3d_ClipPlane* in a view is to use custom presentable object. +* The list of arguments of *Select3D_SensitiveEntity::Matches()* method for picking detection has changed. Since now, for correct selection clipping, the implementations should perform a depth clipping check and return (as output argument) minimum depth value found at the detected part of sensitive. Refer to CDL / Doxygen documentation to find descriptive hints and snippets. * *Select3D_SensitiveEntity::ComputeDepth()* abstract method has been removed. Custom implementations should provide depth checks by method *Matches()* instead -- all data required for it is available within a scope of single method. -* It might be necessary to revise the code of custom sensitive entities and port *Matches()* and *ComputeDepth()* methods to ensure proper selection clipping. Please note that obsolete signature of *Matches* is not used anymore by the selector. If your class inheriting *Select3D_SensitiveEntity* redefines the method with old signature the code should not compile as the return type has been changed. This is done to prevent override of removed methods. +* It might be necessary to revise the code of custom sensitive entities and port *Matches()* and *ComputeDepth()* methods to ensure proper selection clipping. Note that obsolete signature of *Matches* is not used anymore by the selector. If your class inheriting *Select3D_SensitiveEntity* redefines the method with old signature the code should not compile as the return type has been changed. This is done to prevent override of removed methods. @subsection upgrade_670_markers Redesign of markers presentation @@ -210,7 +210,7 @@ If *ViewMapping* and *ViewOrientation* were used directly, this functionality ha The current perspective model is not fully backward compatible, so the old perspective-related functionality needs to be reviewed. -Please revise application-specific custom presentations to provide proper bounding box. Otherwise object might become erroneously clipped by automatic *ZFit* or frustum culling algorithms enabled by default. +Revise application-specific custom presentations to provide a proper bounding box, otherwise the object might become erroneously clipped by automatic *ZFit* or frustum culling algorithms enabled by default. @subsection upgrade_680_connected_objects Redesign of Connected Interactive Objects @@ -987,11 +987,11 @@ The applications that use *gp_Quaternion* to convert Yaw-Pitch-Roll angles (or o @subsection upgrade_zoom_persistent_selection Zoom Persistent Selection -Zoom persistent selection introduces a new structure *Graphic3d_TransformPers* to transform persistence methods and parameters and a new class *Graphic3d_WorldViewProjState* to refer to the camera transformation state. You might need to update your code to deal with the new classes if you were using the related features. Please, keep in mind the following: +Zoom persistent selection introduces a new structure *Graphic3d_TransformPers* to transform persistence methods and parameters and a new class *Graphic3d_WorldViewProjState* to refer to the camera transformation state. You might need to update your code to deal with the new classes if you were using the related features. Keep in mind the following: * *Graphic3d_Camera::ModelViewState* has been renamed to *Graphic3d_Camera::WorldViewState*. * Transformation matrix utilities from *OpenGl_Utils* namespace have been moved to *Graphic3d_TransformUtils* and *Graphic3d_TransformUtils.hxx* header respectively. * Matrix stack utilities from *OpenGl_Utils* namespace have been moved to *OpenGl_MatrixStack* class and *OpenGl_MatrixStack.hxx* header respectively. -* *OpenGl_View* methods *Begin/EndTransformPersistence* have been removed. Please, use *Graphic3d_TransformPers::Apply()* instead to apply persistence to perspective and world-view projection matrices. +* *OpenGl_View* methods *Begin/EndTransformPersistence* have been removed. Use *Graphic3d_TransformPers::Apply()* instead to apply persistence to perspective and world-view projection matrices. @subsection upgrade_occt700_correction_of_texture Texture mapping of objects diff --git a/dox/overview/overview.md b/dox/overview/overview.md index 2f0fd87410..e3dc2e1c4a 100644 --- a/dox/overview/overview.md +++ b/dox/overview/overview.md @@ -32,7 +32,7 @@ Open CASCADE Technology is free software; you can redistribute it and / or modif @ref license_lgpl_21 "GNU Lesser General Public License (LGPL) version 2.1", with additional @ref occt_lgpl_exception "exception". Note that LGPL imposes some obligations on the application linked with Open CASCADE Technology. -If you wish to use OCCT in a proprietary application, please, pay special attention to address the requirements of LGPL section 6. +If you wish to use OCCT in a proprietary application, please pay a special attention to address the requirements of LGPL section 6. At minimum the following should be considered: 1. Add the notice visible to the users of your application clearly stating that Open CASCADE Technology is used in this application, and that they have rights in this regard according to LGPL. Such notice can be added in About dialog box (this is mandatory if this box contains copyright statements) or a similar place and/or in the documentation. @@ -55,7 +55,7 @@ disclaimer. You are hereby informed that all software is a property of its respective authors and is protected by international and domestic laws on intellectual property and trademarks. -Should you need further information, please directly contact the authors. +Should you need further information, directly contact the authors. **CAS.CADE** and **Open CASCADE** are registered trademarks of OPEN CASCADE S.A.S. @@ -80,7 +80,7 @@ and, in case you need any further information, directly contact their authors. **Qt** is a cross-platform application framework that is widely used for developing application software with graphical user interface (GUI). Qt is free and open source software distributed under the terms of the GNU Lesser General Public License. In OCCT Qt is used for programming samples. -If you need further information on Qt, please, refer to Qt Homepage (https://www.qt.io/) +If you need further information on Qt, refer to Qt Homepage (https://www.qt.io/) **Tcl** is a high-level programming language. Tk is a graphical user interface (GUI) toolkit, with buttons, menus, listboxes, scrollbars, and so on. Taken together Tcl and Tk provide a solution @@ -88,7 +88,7 @@ to develop cross-platform graphical user interfaces with a native look and feel. Scriptics Corp., Sun Microsystems, and other companies. However, Tcl/Tk is an open source, and the copyright allows you to use, modify, and redistribute Tcl/Tk for any purpose, without an explicit license agreement and without paying any license fees or royalties. -To use Tcl/Tk, please refer to the Licensing Terms (https://www.tcl.tk/software/tcltk/license.html). +To use Tcl/Tk, refer to the Licensing Terms (https://www.tcl.tk/software/tcltk/license.html). **FreeType 2** is developed by Antoine Leca, David Turner, Werner Lemberg and others. It is a software font engine that is designed to be small, efficient, highly customizable and @@ -109,12 +109,12 @@ implementation of 3D viewer. OpenGL specification is developed by the Khronos group, https://www.khronos.org/opengl/. OCCT code includes header file *glext.h* obtained from Khronos web site. -**VTK** -- The **Visualization Toolkit (VTK)** is an open-source, freely available software system for 3D computer graphics, image processing and visualization. OCCT VIS component provides adaptation functionality for visualization of OCCT topological shapes by means of VTK library. If you need further information on VTK, please, refer to VTK Homepage http://www.vtk.org/. +**VTK** -- The **Visualization Toolkit (VTK)** is an open-source, freely available software system for 3D computer graphics, image processing and visualization. OCCT VIS component provides adaptation functionality for visualization of OCCT topological shapes by means of VTK library. If you need further information on VTK, refer to VTK Homepage http://www.vtk.org/. **Doxygen** developed by Dimitri van Heesch is open source documentation system for C++, C, Java, Objective-C, Python, IDL, PHP and C#. This product is used in Open CASCADE Technology for automatic creation of Technical Documentation from C++ header files. -If you need further information on Doxygen, please refer to https://www.stack.nl/~dimitri/doxygen/index.html. +If you need further information on Doxygen, refer to https://www.stack.nl/~dimitri/doxygen/index.html. **Graphviz** is open source graph visualization software developed by John Ellson, Emden Gansner, Yifan Hu and Arif Bilgin. Graph visualization is representiation of structured information as diagrams of abstract graphs and networks. @@ -396,7 +396,7 @@ the specified resource file and activates the commands implemented in the plug-i The whole process of using the plug-in mechanism as well as the instructions for extending Test Harness is described in the @ref occt_user_guides__test_harness. Draw Test Harness provides an environment for OCCT automated testing system. -Please, consult its @ref occt_dev_guides__tests "Automated Testing System" for details. +Check its @ref occt_dev_guides__tests "Automated Testing System" for details. Remarks: diff --git a/dox/technical_overview/technical_overview.md b/dox/technical_overview/technical_overview.md index 27b9aa4052..a6bc742c51 100644 --- a/dox/technical_overview/technical_overview.md +++ b/dox/technical_overview/technical_overview.md @@ -56,7 +56,7 @@ This module also provides a variety of general-purpose services, such as: * Progress indication and user break interfaces, giving a possibility even for low-level algorithms to communicate with the user in a universal and convenient way; * and many others... -Please, see the details in @ref occt_user_guides__foundation_classes "Foundation Classes User's Guide" +See the details in @ref occt_user_guides__foundation_classes "Foundation Classes User's Guide" See also: our E-learning & Training offerings. @@ -85,7 +85,7 @@ Topology defines relationships between simple geometric entities. A shape, whic Complex shapes can be defined as assemblies of simpler entities. -Please, see the details in @ref occt_user_guides__modeling_data "Modeling Data User's Guide" +See the details in @ref occt_user_guides__modeling_data "Modeling Data User's Guide" 3D geometric models can be stored in OCCT native BREP format. See @ref occt_user_guides__brep_wp "BREP Format Description White Paper" for details on the format. @@ -147,7 +147,7 @@ See @ref occt_user_guides__boolean_operations "Boolean Operations" User's Guide @figure{/technical_overview/images/0004.png} -Please, see the details in @ref occt_user_guides__modeling_algos "Modeling Algorithms User's Guide". +See the details in @ref occt_user_guides__modeling_algos "Modeling Algorithms User's Guide". See also: our E-learning & Training offerings. @@ -204,7 +204,7 @@ Here are just a few examples: @figure{/technical_overview/images/0008.png, "Display of shape cross-section and dimensions"} -For more details see @ref occt_user_guides__visualization "Visualization User's Guide". +For more details, see @ref occt_user_guides__visualization "Visualization User's Guide". The visualization of OCCT topological shapes by means of VTK library provided by VIS component is described in a separate @ref occt_user_guides__vis "VTK Integration Services" User's Guide. @@ -263,7 +263,7 @@ Each sub-domain of Shape Healing has its own scope of functionality: | Customization | Modifies the shape representation to fit specific needs. | The shape is not modified, only the mathematical form of its internal representation is changed. | | Processing | Mechanism of shape modification via a user-editable resource file. | | -For more details refer to @ref occt_user_guides__shape_healing "Shape Healing User's guide". +For more details, refer to @ref occt_user_guides__shape_healing "Shape Healing User's guide". See also: our E-learning & Training offerings. @@ -285,7 +285,7 @@ OCAF differs from any other CAD framework in the organization of application dat OCAF organizes and embeds these attributes in a document. OCAF documents, in their turn, are managed by an OCAF application. -For more details see @ref occt_user_guides__ocaf "OCAF User's Guide". +For more details, see @ref occt_user_guides__ocaf "OCAF User's Guide". See also: our E-learning & Training offerings. @@ -310,4 +310,4 @@ In addition, **Test Harness** provides commands to create and manipulate curves You can add custom commands to test or demonstrate any new functionalities, which you develop. -For more details see @ref occt_user_guides__test_harness "Draw Test Harness Manual". +For more details, see @ref occt_user_guides__test_harness "Draw Test Harness Manual". diff --git a/dox/user_guides/boolean_operations/boolean_operations.md b/dox/user_guides/boolean_operations/boolean_operations.md index 3ac64f7587..eef0ec6083 100644 --- a/dox/user_guides/boolean_operations/boolean_operations.md +++ b/dox/user_guides/boolean_operations/boolean_operations.md @@ -797,7 +797,7 @@ The General Fuse algorithm has a set of options, which allow speeding-up the ope * Usage of Oriented Bounding Boxes in the operation; * History support. -For more detailed information on these options please see the @ref occt_algorithms_11a "Advanced options" section. +For more detailed information on these options, see the @ref occt_algorithms_11a "Advanced options" section. @subsection occt_algorithms_7_3b Usage @@ -900,7 +900,7 @@ bbuild result @subsection occt_algorithms_7_3 Examples -Please, have a look at the examples, which can help to better understand the definitions. +Have a look at the examples to better understand the definitions. @subsubsection occt_algorithms_7_3_1 Case 1: Three edges intersecting at a point @@ -2428,7 +2428,7 @@ A lot of failures of GFA algorithm can be caused by bugs in low-level algorithms * The Projection Algorithm is used at the Intersection step. The purpose of Projection Algorithm is to compute 2D curves on surfaces. Wrong results here lead to incorrect or missing faces in the final GFA result. * The Classification Algorithm is used at the Building step. The bugs in the Classification Algorithm lead to errors in selecting shape parts (edges, faces, solids) and ultimately to a wrong final GFA result. -The description below illustrates some known GFA limitations. It does not enumerate exhaustively all problems that can arise in practice. Please, address cases of Algorithm failure to the OCCT Maintenance Service. +The description below illustrates some known GFA limitations. It does not enumerate exhaustively all problems that can arise in practice. Please address cases of Algorithm failure to the OCCT Maintenance Service. @subsection occt_algorithms_10_1 Arguments @@ -2524,7 +2524,7 @@ Let us also consider a cylinder-based *Face 2* with radii *R=3000* and *H=6000* @figure{/user_guides/boolean_operations/images/operations_image047.png,"P-Curves for Face 2",230} -Please, pay attention to the Zoom value of the Figures. +Pay attention to the Zoom value of the Figures. It is obvious that starting with some value of *ScF*, e.g. *ScF>1000000*, all sloped p-Curves on *Face 2* will be almost vertical. At least, there will be no difference between the values of angles computed by standard C Run-Time Library functions, such as *double acos(double x)*. The loss of accuracy in computation of angles can cause failure of some BP sub-algorithms, such as building faces from a set of edges or building solids from a set of faces. @@ -3087,7 +3087,7 @@ Some options of the main operation are passed into the Unifier: - Fuzzy tolerance of the operation is given to the Unifier as the linear tolerance. - Non destructive mode here controls the safe input mode in Unifier. -For controlling this possibility in DRAW the command **bsimplify** has been implemented. Please see the @ref occt_draw_bop_options "Boolean Operations options" chapter in draw user guide. +For controlling this possibility in DRAW the command **bsimplify** has been implemented. See the @ref occt_draw_bop_options "Boolean Operations options" chapter in draw user guide. @subsection occt_algorithms_simplification_examples Examples 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 0c946afa90..32176dfdf1 100644 --- a/dox/user_guides/draw_test_harness/draw_test_harness.md +++ b/dox/user_guides/draw_test_harness/draw_test_harness.md @@ -6877,7 +6877,7 @@ tscale c1 0 0 0 0.5 @subsubsection occt_draw_7_6_1 fuse, cut, common These commands are no longer supported, so the result may be unpredictable. -Please use the commands bfuse, bcut, bcommon instead. +Use the commands bfuse, bcut, bcommon instead. Syntax: ~~~~~ @@ -6916,7 +6916,7 @@ ttranslate s4 0 -40 0 @subsubsection occt_draw_7_6_2 section, psection These commands are no longer supported, so the result may be unpredictable. -Please use the command bsection instead. +Use the command **bsection** instead. Syntax: ~~~~~ @@ -6967,7 +6967,7 @@ The new algorithm of Boolean operations avoids a large number of weak points and It also provides wider range of options and diagnostics. The algorithms of Boolean component are fully described in the @ref occt_algorithms_1 "Boolean Operations" of boolean operation user guide. -For the Draw commands to perform operations in Boolean component please read the dedicated section @ref occt_draw_bop "Boolean operations commands" +For the Draw commands to perform operations in Boolean component, read the dedicated section @ref occt_draw_bop "Boolean operations commands" @subsection occt_draw_7_8 Drafting and blending @@ -8372,7 +8372,7 @@ bsplit result @subsubsection occt_draw_bop_build_CB Cells Builder -Please see the @ref occt_algorithms_10c_Cells_1 "Cells Builder Usage" for the Draw usage of Cells Builder algorithm. +See the @ref occt_algorithms_10c_Cells_1 "Cells Builder Usage" for the Draw usage of Cells Builder algorithm. @subsubsection occt_draw_bop_build_API Building result through API diff --git a/dox/user_guides/foundation_classes/foundation_classes.md b/dox/user_guides/foundation_classes/foundation_classes.md index c9e6561f2b..8b2aaefbba 100644 --- a/dox/user_guides/foundation_classes/foundation_classes.md +++ b/dox/user_guides/foundation_classes/foundation_classes.md @@ -1682,7 +1682,7 @@ All these functions are provided by geometric processor package gp. Its The *gp* package defines the basic geometric entities used for algebraic calculation and basic analytical geometry in 2d & 3d space. It also provides basic transformations such as identity, rotation, translation, mirroring, scale transformations, combinations of transformations, etc. Entities are handled by value. -Please, note that gp curves and surfaces are analytic: there is no parameterization and no orientation on gp entities, i.e. these entities do not provide functions which work with these properties. +Note that gp curves and surfaces are analytic: there is no parameterization and no orientation on gp entities, i.e. these entities do not provide functions which work with these properties. If you need, you may use more evolved data structures provided by Geom (in 3D space) and Geom2d (in the plane). However, the definition of gp entities is identical to the one of equivalent Geom and Geom2d entities, and they are located in the plane or in space with the same kind of positioning systems. They implicitly contain the orientation, which they express on the Geom and Geom2d entities, and they induce the definition of their parameterization. diff --git a/dox/user_guides/iges/iges.md b/dox/user_guides/iges/iges.md index bb25e14c13..5743eac6ba 100644 --- a/dox/user_guides/iges/iges.md +++ b/dox/user_guides/iges/iges.md @@ -9,7 +9,7 @@ The IGES interface reads IGES files and translates them to Open CASCADE Technolo Other kinds of data such as colors and names can be read or written with the help of XDE tools IGESCAFControl_Reader and IGESCAFControl_Writer. -Please, note: +**Note** : * an IGES model is an IGES file that has been loaded into memory. * an IGES entity is an entity in the IGES normal sense. @@ -251,7 +251,7 @@ Default value is 0.01.

read.iges.bspline.approxd1.mode

This parameter is obsolete (it is rarely used in real practice). If set to True, it affects the translation of bspline curves of degree 1 from IGES: these curves (which geometrically are polylines) are split by duplicated points, and the translator attempts to convert each of the obtained parts to a bspline of a higher continuity. -Read this parameter with: +Read this parameter with: ~~~~~ Standard_Real bam = Interface_Static::CVal("read.iges.bspline.approxd1.mode"); ~~~~~ @@ -266,9 +266,9 @@ Default value is Off.

read.iges.resource.name and read.iges.sequence

These two parameters define the name of the resource file and the name of the sequence of operators (defined in that file) for Shape Processing, which is automatically performed by the IGES translator. The Shape Processing is a user-configurable step, which is performed after the translation and consists in application of a set of operators to a resulting shape. This is a very powerful tool allowing to customize the shape and to adapt it to the needs of a receiving application. By default, the sequence consists of a single operator *ShapeFix* that calls Shape Healing from the IGES translator. -Please find an example of the resource file for IGES (which defines parameters corresponding to the sequence applied by default, i.e. if the resource file is not found) in the Open CASCADE Technology installation, by the path %CASROOT%/src/XSTEPResource/IGES . +Find an example of the resource file for IGES (which defines parameters corresponding to the sequence applied by default, i.e. if the resource file is not found) in the Open CASCADE Technology sources by the path %CASROOT%/src/XSTEPResource/IGES. -In order for the IGES translator to use that file, you have to define the environment variable *CSF_IGESDefaults*, which should point to the directory where the resource file resides. Note that if you change parameter *read.iges.resource.name*, you should change the name of the resource file and the name of the environment variable correspondingly. The variable should contain a path to the resource file. +IGES translator will use that file if you define the environment variable *CSF_IGESDefaults*, which should point to the directory where the resource file resides. Note that if you change parameter *read.iges.resource.name*, you should change the name of the resource file and the name of the environment variable correspondingly. The variable should contain a path to the resource file. Default values: * read.iges.resource.name -- IGES, @@ -286,7 +286,7 @@ A list of entities can be formed by invoking the method *IGESControl_Reader::Gi Handle(TColStd_HSequenceOfTransient) list = reader.GiveList(); ~~~~~ Several predefined operators can be used to select a list of entities of a specific type. -To make a selection, you use the method *IGESControl_Reader::GiveList* with the selection type in quotation marks as an argument. You can also make cumulative selections. For example, you would use the following syntax: +To make a selection, use the method *IGESControl_Reader::GiveList* with the selection type in quotation marks as an argument. You can also make cumulative selections. For example, you would use the following syntax: 1. Requesting the faces in the file: ~~~~~ faces = Reader.GiveList("iges-faces"); @@ -577,7 +577,7 @@ All methods are in charge of transferring curves from IGES curve entities ( * *IGESToBRep_TopoCurve::TransferPoint* -- vertex is constructed from a Point entity with tolerance *EpsGeom*UnitFactor*. * *IGESToBRep_TopoCurve::Transfer2dPoint* -- vertex is constructed from a Point entity with tolerance *EpsCoeff*. * *IGESToBRep_TopoCurve::TransferCompositeCurveGeneral* -- obtains shapes (edges or wires) from other methods and adds them into the resulting wire. Two adjacent edges of the wire can be connected with tolerance up to *MaxTol*. - * *IGESToBRep_TopoCurve::TransferCurveOnFace* and *IGESToBRep_TopoCurve::TransferBoundaryOnFace* build a wire from 3D and 2D representations of a curve on surface. Edges and vertices of the wire cannot have tolerance larger than *MaxTol*. The value *EpsGeom*UnitFactor* is passed into *ShapeFix_Wire::SetPrecision* and *MaxTol* is passed into *ShapeFix_Wire::MaxTolerance*. To find out how these parameters affect the resulting tolerance changes, please, refer to class *ShapeFix_Wire*. + * *IGESToBRep_TopoCurve::TransferCurveOnFace* and *IGESToBRep_TopoCurve::TransferBoundaryOnFace* build a wire from 3D and 2D representations of a curve on surface. Edges and vertices of the wire cannot have tolerance larger than *MaxTol*. The value *EpsGeom*UnitFactor* is passed into *ShapeFix_Wire::SetPrecision* and *MaxTol* is passed into *ShapeFix_Wire::MaxTolerance*. To find out how these parameters affect the resulting tolerance changes, refer to class *ShapeFix_Wire*. * *IGESToBRep_TopoCurve::TransferTopoBasicCurve* and *IGESToBRep_TopoCurve::Transfer2dTopoBasicCurve* -- the boundary vertices of an edge (or a wire if a curve was of C0 continuity) translated from a basis IGES curve (*BSplineCurve, CopiousData, Line,* etc.) are built with tolerance *EpsGeom*UnitFactor*, the edge tolerance is *Precision::Confusion*. If a curve was divided into several edges, the common vertices of such adjacent edges have tolerance *Precision::Confusion*. @@ -710,7 +710,7 @@ if (!Interface_Static::SetRVal(;write.precision.val;,0.01)) ~~~~~ Default value is 0.0001. -

write.iges.resource.name

and

write.iges.sequence

are the same as the corresponding read.iges.\* parameters, please, see above. Note that the default sequence for writing contains *DirectFaces* operator, which converts elementary surfaces based on left-hand axes (valid in CASCADE) to right-hand axes (which are valid only in IGES). +

write.iges.resource.name

and

write.iges.sequence

are the same as the corresponding read.iges.\* parameters. Note that the default sequence for writing contains *DirectFaces* operator, which converts elementary surfaces based on left-hand axes (valid in CASCADE) to right-hand axes (which are valid only in IGES). Default values : ~~~~~ diff --git a/dox/user_guides/inspector/inspector.md b/dox/user_guides/inspector/inspector.md index 94430b69ea..41b8abd55e 100644 --- a/dox/user_guides/inspector/inspector.md +++ b/dox/user_guides/inspector/inspector.md @@ -30,10 +30,10 @@ Each of the listed plugins is embedded in the common framework, thus it is possi There are two launch modes: 1. Launch **TInspectorEXE** executable sample. For more details see @ref occt_inspector_4_1 "TInspectorEXE" section; 2. Launch DRAW, load plugin INSPECTOR, and use *tinspector* command. - For more details see @ref occt_inspector_4_2 "Launch in DRAW Test Harness" section. + For more details, see @ref occt_inspector_4_2 "Launch in DRAW Test Harness" section. -Note. If you have no Inspector library in your build directory, please, make sure that OCCT is compiled with *BUILD_Inspector* +**Note**. If you have no Inspector library in your build directory, make sure that OCCT is compiled with *BUILD_Inspector* option ON. For more details see @ref occt_inspector_5 "Build procedure". @@ -290,7 +290,7 @@ Selection controls switch on/off the possibility to set selection in the context | Select Presentations | *AIS_InteractiveObject* | Calls *AddOrRemoveSelected* of interactive object for the selected item. | | Select Owners | *SelectMgr_EntityOwner* or
*SelectMgr_SensitiveEntity* | Calls *AddOrRemoveSelected* of *SelectMgr_EntityOwner* for the selected item. | -Please, note that the initial selection in the context will be cleared. +Note that the initial selection in the context will be cleared. If the button is toggled, the button selection is active. Only one button may be toggled at the moment. diff --git a/dox/user_guides/modeling_algos/modeling_algos.md b/dox/user_guides/modeling_algos/modeling_algos.md index e9f0003937..9f68dd3b53 100644 --- a/dox/user_guides/modeling_algos/modeling_algos.md +++ b/dox/user_guides/modeling_algos/modeling_algos.md @@ -1383,7 +1383,7 @@ DRAW History support for the algorithms is provided by three basic commands: * *modified*; * *generated*. -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". +For more information on the Draw History mechanism, refer to the corresponding chapter in the Draw users guide - @ref occt_draw_hist "History commands". @section occt_modalg_3 Standard Topological Objects @@ -3181,7 +3181,7 @@ On the low-level the history information is collected by the history tool *BRepT * *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. +For more information on the error/warning reporting system, see the chapter @ref occt_algorithms_ers "Errors and warnings reporting system" of Boolean operations user guide. Parallel processing mode - allows running the algorithm in parallel mode obtaining the result faster. diff --git a/dox/user_guides/modeling_data/modeling_data.md b/dox/user_guides/modeling_data/modeling_data.md index 26159ad114..5c31123d48 100644 --- a/dox/user_guides/modeling_data/modeling_data.md +++ b/dox/user_guides/modeling_data/modeling_data.md @@ -1166,7 +1166,7 @@ Thus for a contour of four edges it should count 1 wire + 4 edges +4 vertices wi } ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -**Note** For more details about Maps please, refer to the TCollection documentation. (Foundation Classes Reference Manual) +**Note** For more details about Maps, refer to the *TCollection* documentation (Foundation Classes Reference Manual). The following example is more ambitious and writes a program which copies a data structure using an *IndexedMap*. The copy is an identical structure but it shares nothing with the original. The principal algorithm is as follows: - All Shapes in the structure are put into an *IndexedMap*. diff --git a/dox/user_guides/shape_healing/shape_healing.md b/dox/user_guides/shape_healing/shape_healing.md index 1ba66766d6..1086313d4c 100644 --- a/dox/user_guides/shape_healing/shape_healing.md +++ b/dox/user_guides/shape_healing/shape_healing.md @@ -50,7 +50,7 @@ Each sub-domain has its own scope of functionality: * customization -- modifying shape representation to fit specific needs (shape is not modified, only the form of its representation is modified); * processing -- mechanism of managing shape modification via a user-editable resource file. -Message management is used for creating messages, filling them with various parameters and storing them in the trace file. This tool provides functionality for attaching messages to the shapes for deferred analysis of various run-time events. In this document only general principles of using Shape Healing will be described. For more detailed information please see the corresponding header files. +Message management is used for creating messages, filling them with various parameters and storing them in the trace file. This tool provides functionality for attaching messages to the shapes for deferred analysis of various run-time events. In this document only general principles of using Shape Healing will be described. For more detailed information, see the corresponding header files. Tools responsible for analysis, fixing and upgrading of shapes can give the information about how these operations were performed. This information can be obtained by the user with the help of mechanism of status querying. diff --git a/dox/user_guides/step/step.md b/dox/user_guides/step/step.md index 8c03962457..420f6e2298 100644 --- a/dox/user_guides/step/step.md +++ b/dox/user_guides/step/step.md @@ -62,7 +62,7 @@ To choose a translation mode when exporting to a STEP format, use STEPContro There is a set of parameters that concern the translation and can be set before the beginning of the translation. -Please, note: +**Note** : * a STEP model is a STEP file that has been loaded into memory; * all references to shapes indicate OCCT shapes unless otherwise explicitly stated; * a root entity is the highest level entity of any given type, i.e. an entity that is not referenced by any other one. @@ -275,7 +275,7 @@ Default value is File These two parameters define the name of the resource file and the name of the sequence of operators (defined in that file) for Shape Processing, which is automatically performed by the STEP translator. Shape Processing is a user-configurable step, which is performed after translation and consists in applying a set of operators to a resulting shape. This is a very powerful tool allowing customizing the shape and adapting it to the needs of a receiving application. By default the sequence consists of a single operator ShapeFix -- that is how Shape Healing is called from the STEP translator. -Please find an example of the resource file for STEP (which defines parameters corresponding to the sequence applied by default, i.e. if the resource file is not found) in the Open CASCADE Technology installation, by the path %CASROOT%/src/XSTEPResource/STEP. +Find an example of the resource file for STEP (which defines parameters corresponding to the sequence applied by default, i.e. if the resource file is not found) in the Open CASCADE Technology sources by the path %CASROOT%/src/XSTEPResource/STEP. In order for the STEP translator to use that file, you have to define the *CSF_STEPDefaults* environment variable, which should point to the directory where the resource file resides. Note that if you change parameter *read.step.resource.name*, you will change the name of the resource file and the environment variable correspondingly. @@ -543,7 +543,7 @@ Standard_Boolean ok = reader.TransferEntity (ent); ~~~~~ @subsection occt_step_2_4 Mapping STEP entities to Open CASCADE Technology shapes -Tables given in this paragraph show the mapping of STEP entities to OCCT objects. Only topological and geometrical STEP entities and entities defining assembly structures are described in this paragraph. For a full list of STEP entities please refer to Appendix A. +Tables given in this paragraph show the mapping of STEP entities to OCCT objects. Only topological and geometrical STEP entities and entities defining assembly structures are described in this paragraph. For a full list of STEP entities, refer to Appendix A. @subsubsection occt_step_2_4_1 Assembly structure representation entities Not all entities defining the assembly structure in the STEP file are translated to OCCT shapes, but they are used to identify the relationships between assemblies and their components. Since the graph of `natural' dependencies of entities based on direct references between them does not include the references from assemblies to their components, these dependencies are introduced in addition to the former ones. This is made basing on the analysis of the following entities describing the structure of the assembly. @@ -792,7 +792,7 @@ The shapes organized in a structure of nested compounds can be translated either The assembly structure placed in the produced STEP file corresponds to the structure described in the ProSTEP Agreement Log (item 21) as the second alternative (assembly structure through *representation_relationship* / *item_defined_transformation*). To represent an assembly it uses entities of the *representation_relationship_with_transformation* type. Transformation operators used for locating assembly components are represented by *item_defined_transformation* entities. If mode *write.step.assembly* is set to the values *ON* or *Auto* then an OCC shape consisting of nested compounds will be written as an assembly, otherwise it will be written as separate solids. -Please see also @ref occt_step_3_4 "Mapping OCCT shapes to STEP entities". +See also @ref occt_step_3_4 "Mapping OCCT shapes to STEP entities". @subsection occt_step_3_3 Description of the process @subsubsection occt_step_3_3_1 Initializing the process @@ -969,7 +969,7 @@ IFSelect_ReturnStatus stat = writer.Write("filename.stp"); to give the file name. @subsection occt_step_3_4 Mapping Open CASCADE Technology shapes to STEP entities -Only STEP entities that have a corresponding OCCT object and mapping of assembly structures are described in this paragraph. For a full list of STEP entities please refer to Appendix A. +Only STEP entities that have a corresponding OCCT object and mapping of assembly structures are described in this paragraph. For a full list of STEP entities, refer to Appendix A. @subsubsection occt_step_3_4_1 Assembly structures and product information The assembly structures are written to the STEP file if parameter *write.step.assembly* is 1 or 2. @@ -1607,7 +1607,7 @@ Geometric validation properties, such as volume, area and centroid, which are at ### Geometric dimensions and tolerances All entities, which can be imported from STEP, can be exported too. -Please see the same item in section @ref occt_step_7_1 "Reading from STEP" to find more information. +See the same item in section @ref occt_step_7_1 "Reading from STEP" to find more information. Note: OCCT use AP214 by default, so for GD&T exporting AP242 should be set manually: ~~~~~ diff --git a/dox/user_guides/visualization/visualization.md b/dox/user_guides/visualization/visualization.md index 8fb5b375e8..d278db2630 100644 --- a/dox/user_guides/visualization/visualization.md +++ b/dox/user_guides/visualization/visualization.md @@ -1079,7 +1079,7 @@ aMesh->AddBuilder (aBuilder, true); The dynamic selection represents the topological shape, which you want to select, by decomposition of *sensitive primitives* -- the sub-parts of the shape that will be detected and highlighted. The sets of these primitives are handled by the powerful three-level BVH tree selection algorithm. -For more details on the algorithm and examples of usage, please, refer to @ref occt_visu_2_2 "Selection" chapter. +For more details on the algorithm and examples of usage, refer to @ref occt_visu_2_2 "Selection" chapter. @section occt_visu_4 3D Presentations