From: ysn Date: Fri, 18 Dec 2015 12:33:23 +0000 (+0300) Subject: 0026992: Use Doxygen tag @ref for cross-references in documentation X-Git-Tag: V7_0_0_beta~20 X-Git-Url: http://git.dev.opencascade.org/gitweb/?p=occt.git;a=commitdiff_plain;h=67d7f07f51f356e3ac76883753b8970075fd2369;hp=27245ff9c06aea73b009ca77e94426344b1adcb9 0026992: Use Doxygen tag @ref for cross-references in documentation href have been replaced by @ref tags except for the links to web-pages and other documents where @ref tags do not work either. --- diff --git a/dox/dev_guides/contribution/coding_rules.md b/dox/dev_guides/contribution/coding_rules.md index 43677ebbd3..36e6d40610 100644 --- a/dox/dev_guides/contribution/coding_rules.md +++ b/dox/dev_guides/contribution/coding_rules.md @@ -486,7 +486,7 @@ They should be detailed enough to allow any person to understand what each part It is recommended to comment all static functions (like methods in headers), and to insert at least one comment per each 10-100 lines in the function body. -There are also some rules that define how comments should be formatted, see Formatting Rules. +There are also some rules that define how comments should be formatted, see @ref occt_coding_rules_3 "Formatting Rules". Following these rules is important for good comprehension of the comments. Moreover, this approach allows automatically generating user-oriented documentation directly from the commented sources. diff --git a/dox/dev_guides/documentation/documentation.md b/dox/dev_guides/documentation/documentation.md index a06761008f..f53fb88d4f 100644 --- a/dox/dev_guides/documentation/documentation.md +++ b/dox/dev_guides/documentation/documentation.md @@ -136,7 +136,7 @@ dev_guides/svn/svn.md **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 you should specify a file tag, not the document name. See Header section for details. +**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. @section OCCT_DOC_SECTION_5 Additional Resources diff --git a/dox/dev_guides/git_guide/git_guide.md b/dox/dev_guides/git_guide/git_guide.md index 03adc7b7ac..8126490da0 100644 --- a/dox/dev_guides/git_guide/git_guide.md +++ b/dox/dev_guides/git_guide/git_guide.md @@ -520,7 +520,7 @@ To rebase your branch into a single commit, you need to do the following: Use of TortoiseGit is recommended for convenient code review: - * Fetch the changes from the remote repository as described in Synchronizing with remote repository section. + * Fetch the changes from the remote repository as described in @ref occt_gitguide_4_7 "Synchronizing with remote repository" section. * Right-click on the repository, choose **TortoiseGit** -> **Show** log; * Locate the remote branch you need to review; * To review commits one-by-one, select each commit in the log. The list of changed files is shown at the bottom of the window; double-click on the file will open visual compare tool. diff --git a/dox/dev_guides/tests/tests.md b/dox/dev_guides/tests/tests.md index e3e3a6f772..b7abd572a8 100644 --- a/dox/dev_guides/tests/tests.md +++ b/dox/dev_guides/tests/tests.md @@ -21,7 +21,7 @@ The tests are organized in three levels: * Grid: a set of test cases within a group, usually aimed at testing some particular aspect or mode of execution of the relevant functionality (e.g. buildevol); * Test case: a script implementing an individual test (e.g. K4). -See Test Groups for the current list of available test groups and grids. +See @ref testmanual_5_1 "Test Groups" chapter for the current list of available test groups and grids. Some tests involve data files (typically CAD models) which are located separately and are not included with OCCT code. The archive with publicly available test data files should be downloaded and installed independently on OCCT sources (see http://dev.opencascade.org). @@ -98,7 +98,7 @@ Example: Detailed logs are saved in D:/occt/results_2012-06-04T0919 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The tests are considered as non-regressive if only OK, BAD (i.e. known problem), and SKIPPED (i.e. not executed, typically because of lack of a data file) statuses are reported. See Interpretation of test results for details. +The tests are considered as non-regressive if only OK, BAD (i.e. known problem), and SKIPPED (i.e. not executed, typically because of lack of a data file) statuses are reported. See @ref testmanual_3_5 "Interpretation of test results" for details. The results and detailed logs of the tests are saved by default to a new subdirectory of the subdirectory *results* in the current folder, whose name is generated automatically using the current date and time, prefixed by Git branch name (if Git is available and current sources are managed by Git). If necessary, a non-default output directory can be specified using option –outdir followed by a path to the directory. This directory should be new or empty; use option –overwrite to allow writing results in the existing non-empty directory. @@ -167,12 +167,12 @@ test: Run specified test case @subsubsection testmanual_1_3_4 Creating a New Test -The detailed rules of creation of new tests are given in section 3. The following short description covers the most typical situations: +The detailed rules of creation of new tests are given in @ref testmanual_3 "Creation and modification of tests" chapter. The following short description covers the most typical situations: Use prefix bug followed by Mantis issue ID and, if necessary, additional suffixes, for naming the test script, data files, and DRAW commands specific for this test case. 1. If the test requires C++ code, add it as new DRAW command(s) in one of files in *QABugs* package. -2. Add script(s) for the test case in the subfolder corresponding to the relevant OCCT module of the group *bugs* ($CASROOT/tests/bugs). See the correspondence map. +2. Add script(s) for the test case in the subfolder corresponding to the relevant OCCT module of the group *bugs* ($CASROOT/tests/bugs). See @ref testmanual_5_2 "the correspondence map". 3. In the test script: * Load all necessary DRAW modules by command *pload*. * Use command *locate_data_file* to get a path to data files used by test script. (Make sure to have this command not inside catch statement if it is used.) @@ -288,7 +288,7 @@ This file is a TCL script. It is executed after every test in the current group. Note: *TEST COMPLETED* string should be present in the output to indicate that the test is finished without crash. -See section 3 for more information. +See @ref testmanual_3 "Creation and modification of tests" chapter for more information. Example: ~~~~~ @@ -321,7 +321,7 @@ Example: Lines starting with a *#* character and blank lines are ignored to allow comments and spacing. -See Interpretation of test results chapter for details. +See @ref testmanual_3_5 "Interpretation of test results" chapter for details. If a line matches several rules, the first one applies. Rules defined in the grid are checked first, then rules in the group, then rules in the test root directory. This allows defining some rules on the grid level with status *IGNORE* to ignore messages that would otherwise be treated as errors due to the group level rules. @@ -334,7 +334,7 @@ Example: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @subsubsection testmanual_2_2_6 Directory "data" -The test group may contain subdirectory *data*, where test scripts shared by different test grids can be put. See also Directory *data*. +The test group may contain subdirectory *data*, where test scripts shared by different test grids can be put. See also @ref testmanual_2_3_5 "Directory data". @subsection testmanual_2_3 Test Grids @@ -440,7 +440,7 @@ This section describes how to add new tests and update existing ones. The new tests are usually added in the frame of processing issues in OCCT Mantis tracker. Such tests in general should be added to group bugs, in the grid -corresponding to the affected OCCT functionality. See Mapping of OCCT functionality to grid names in group *bugs*. +corresponding to the affected OCCT functionality. See @ref testmanual_5_2 "Mapping of OCCT functionality to grid names in group bugs". New grids can be added as necessary to contain tests for the functionality not yet covered by existing test grids. The test case name in the bugs group should be prefixed by the ID of the corresponding issue in Mantis (without leading zeroes) with prefix *bug*. It is recommended to add a suffix providing a hint on the tested situation. If more than one test is added for a bug, they should be distinguished by suffixes; either meaningful or just ordinal numbers. @@ -786,7 +786,7 @@ Grids names are based on name of the command used, with suffixes: This group allows testing cases coming from Mantis issues. The grids are organized following OCCT module and category set for the issue in the Mantis tracker. -See Mapping of OCCT functionality to grid names in group *bugs* for details. +See @ref testmanual_5_2 "Mapping of OCCT functionality to grid names in group bugs" chapter for details. @subsubsection testmanual_5_1_5 caf 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 101594f803..a80e1b8a53 100644 --- a/dox/user_guides/draw_test_harness/draw_test_harness.md +++ b/dox/user_guides/draw_test_harness/draw_test_harness.md @@ -1272,7 +1272,7 @@ When an object is modified or erased, the whole view must be repainted. To avoid Graphic operations are buffered by Draw (and also by the X system). Usually the buffer is flushed at the end of a command and before graphic selection. If you want to flush the buffer from inside a script, use the **dflush** command. -See also: pick command. +See also: @ref occt_draw_4_1_11 "pick" command. @subsection occt_draw_4_2 AIS viewer – view commands @@ -4238,7 +4238,7 @@ Syntax: AISMaterial docname entry [material] ~~~~~ -Sets (if *material* is defined) or gets the value of transparency for *AISPresentation* attribute of an *entry* label. *material* is integer from 0 to 20 (see meshmat command). +Sets (if *material* is defined) or gets the value of transparency for *AISPresentation* attribute of an *entry* label. *material* is integer from 0 to 20 (see @ref occt_draw_4_5_6 "meshmat" command). **Example:** ~~~~~ @@ -8463,7 +8463,7 @@ These commands are used for translation of IGES and STEP files into an XCAF docu * XDE layer’s commands * XDE property’s commands -Reminding: All operations of translation are performed with parameters managed by command the command *param*. +Reminding: All operations of translation are performed with parameters managed by command @ref occt_draw_8_3_14 "param". @subsubsection occt_draw_8_4_1 ReadIges @@ -8576,7 +8576,7 @@ Syntax: XFromShape ~~~~~ -This command is similar to the command *fromshape*, but gives additional information about the file name. It is useful if a shape was translated from several files. +This command is similar to the command @ref occt_draw_8_3_7 "fromshape", but gives additional information about the file name. It is useful if a shape was translated from several files. **Example:** ~~~~~ @@ -9961,14 +9961,14 @@ ADVCURV : TKMyAdvCurv MESHING : TKMyMesh ~~~~~ -For other examples of the plug-in resource file refer to the Plug-in resource file chapter above or to the $CASROOT/src/DrawPlugin file shipped with Open CASCADE Technology. +For other examples of the plug-in resource file refer to the @ref occt_draw_1_3_2 "Plug-in resource file" chapter above or to the $CASROOT/src/DrawPlugin file shipped with Open CASCADE Technology. @subsection occt_draw_11_5 Dynamic loading and activation -Loading a plug-in and activating its commands is described in the Activation of the commands implemented in the plug-in chapter. +Loading a plug-in and activating its commands is described in the @ref occt_draw_1_3_3 "Activation of the commands implemented in the plug-in" chapter. -The procedure consists in defining the system variables and using the pload commands in the Test Harness session. +The procedure consists in defining the system variables and using the *pload* commands in the Test Harness session. **Example:** ~~~~ diff --git a/dox/user_guides/iges/iges.md b/dox/user_guides/iges/iges.md index f374efc2f9..13c533ec31 100644 --- a/dox/user_guides/iges/iges.md +++ b/dox/user_guides/iges/iges.md @@ -811,7 +811,7 @@ Translated objects depend on the write mode that you chose. If you chose the Fa @subsection occt_iges_3_5 Tolerance management @subsubsection occt_iges_3_5_1 Setting resolution in an IGES file -There are several possibilities to set resolution in an IGES file. They are controlled by write.precision.mode parameter; the dependence between the value of this parameter and the set resolution is described in paragraph Setting the translation parameters. +There are several possibilities to set resolution in an IGES file. They are controlled by write.precision.mode parameter; the dependence between the value of this parameter and the set resolution is described in paragraph @ref occt_iges_3_3_2 "Setting the translation parameters". If the value of parameter *write.precision.mode* is -1, 0 or 1, resolution is computed from tolerances of sub-shapes inside the shape to be translated. In this computation, only tolerances of *TopoDS_Edges* and *TopoDS_Vertices* participate since they reflect the accuracy of the shape. *TopoDS_Faces* are ignored in computations since their tolerances may have influence on resulting computed resolution while IGES resolution mainly concerns points and curves but not surfaces. @@ -844,7 +844,7 @@ Standard_Integer main() ~~~~~ -@section occt_iges_4_ Using XSTEPDRAW +@section occt_iges_4 Using XSTEPDRAW XSTEPDRAW UL is intended for creating executables for testing XSTEP interfaces interactively in the DRAW environment. It provides an additional set of DRAW commands specific for the data exchange tasks, which allow loading and writing data files and analysis of resulting data structures and shapes. @@ -871,7 +871,7 @@ Command *xtrace* is intended to view and change these parameters: * *Draw xtrace* - directs all messages to the standard output. @subsection occt_iges_4_3 Reading IGES files -For a description of parameters used in reading an IGES file refer to Setting the translation parameters. +For a description of parameters used in reading an IGES file refer to @ref occt_iges_2_3_3 "Setting the translation parameters". These parameters are set by command *param* : @@ -888,7 +888,7 @@ Loading is done by the command ~~~~~ Draw> xload ~~~~~ -Once the file is loaded, it is possible to investigate the structure of the loaded data. To learn how to do it see Analyzing the transferred +Once the file is loaded, it is possible to investigate the structure of the loaded data. To learn how to do it see @ref occt_iges_4_4 "Analyzing the transferred". Reading of an IGES file is done by the command ~~~~~ @@ -910,7 +910,7 @@ After the selected set of entities is loaded the user will be asked how loaded The second parameter of the *igesbrep* command defines the name of the loaded shape. If several shapes are created, they will get indexed names. For instance, if the last parameter is ‘s’, they will be s_1, ... s_N. -\ specifies the scope of selected entities in the model, it is *xst-transferrable-roots* by default. An asterisk “*” can be specified instead of *iges-visible-transf-roots*. For possible values of *selection* refer to Selecting entities section. +\ specifies the scope of selected entities in the model, it is *xst-transferrable-roots* by default. An asterisk “*” can be specified instead of *iges-visible-transf-roots*. For possible values of *selection* refer to @ref occt_iges_2_3_4 "Selecting entities" section. Instead of *igesbrep* it is possible to use commands: @@ -1090,7 +1090,7 @@ When specifying *min* and *max* arguments this command outputs shapes with name @subsection occt_iges_4_5 Writing an IGES file -Refer to Setting the translation parameters for a description of parameters used in reading an IGES file. The parameters are set by command *param*: +Refer to @ref occt_iges_3_3_2 "Setting the translation parameters" for a description of parameters used in reading an IGES file. The parameters are set by command *param*: | Description | Name | Values | | :----------- | :---- | :----- | @@ -1129,10 +1129,10 @@ Loading the file only memorizes, but does not translate the data. @subsection occt_iges_5_2 Checking the loaded IGES file -This step is not obligatory. See the description of this step above. +This step is not obligatory. See the description of @ref occt_iges_2_3_2 "Checking the IGES file" above. @subsection occt_iges_5_3 Setting parameters for translation to XDE -See the description of this step above. +See the description of @ref occt_iges_2_3_3 "Setting translation parameters" above. In addition, the following parameters can be set for XDE translation of attributes: * For transferring colors: diff --git a/dox/user_guides/ocaf/ocaf.md b/dox/user_guides/ocaf/ocaf.md index 0b9b3c446b..5e2d8e1b93 100644 --- a/dox/user_guides/ocaf/ocaf.md +++ b/dox/user_guides/ocaf/ocaf.md @@ -65,8 +65,8 @@ The subsequent chapters of this document explain the concepts and show how to us OCAF provides you with an object-oriented Application-Document-Attribute model consisting of C++ class libraries. -@image html ocaf_wp_image003.png "The Application-Document-Attribute model " -@image latex ocaf_wp_image003.png "The Application-Document-Attribute model " +@image html ocaf_wp_image003.png "The Application-Document-Attribute model" +@image latex ocaf_wp_image003.png "The Application-Document-Attribute model" @subsubsection occt_ocaf_1_2_1 Application @@ -94,18 +94,18 @@ The *Application* is an abstract class in charge of handling documents during th Application data is described by **Attributes**, which are instances of classes derived from the *Attribute* abstract class, organized according to the OCAF Data Framework. - The OCAF Data Framework references aggregations of attributes using persistent identifiers in a single hierarchy. A wide range of attributes come with OCAF, including: + The @ref occt_ocaf_3 "OCAF Data Framework" references aggregations of attributes using persistent identifiers in a single hierarchy. A wide range of attributes come with OCAF, including: - * Standard attributes allow operating with simple common data in the data framework (for example: integer, real, string, array kinds of data), realize auxiliary functions (for example: tag sources attribute for the children of the label counter), create dependencies (for example: reference, tree node)....; - * Shape attributes contain the geometry of the whole model or its elements including reference to the shapes and tracking of shape evolution; + * @ref occt_ocaf_6 "Standard attributes" allow operating with simple common data in the data framework (for example: integer, real, string, array kinds of data), realize auxiliary functions (for example: tag sources attribute for the children of the label counter), create dependencies (for example: reference, tree node)....; + * @ref occt_ocaf_5 "Shape attributes" contain the geometry of the whole model or its elements including reference to the shapes and tracking of shape evolution; * Other geometric attributes such as **Datums** (points, axis and plane) and **Constraints** (*tangent-to, at-a-given-distance, from-a-given-angle, concentric,* etc.) * User attributes, that is, attributes typed by the application - * Visualization attributes allow placing viewer information to the data framework, visual representation of objects and other auxiliary visual information, which is needed for graphical data representation. - * Function services — the purpose of these attributes is to rebuild objects after they have been modified (parameterization of models). While the document manages the notification of changes, a function manages propagation of these changes. The function mechanism provides links between functions and calls to various algorithms. + * @ref occt_ocaf_7 "Visualization attributes" allow placing viewer information to the data framework, visual representation of objects and other auxiliary visual information, which is needed for graphical data representation. + * @ref occt_ocaf_8 "Function services" — the purpose of these attributes is to rebuild objects after they have been modified (parameterization of models). While the document manages the notification of changes, a function manages propagation of these changes. The function mechanism provides links between functions and calls to various algorithms. In addition, application-specific data can be added by defining new attribute classes; naturally, this changes the standard file format. The only functions that have to be implemented are: * Copying the attribute - * Converting it from and to its persistent homologue (persistence is briefly presented in the paragraph Persistent Data Storage) + * Converting it from and to its persistent homologue (persistence is briefly presented in the paragraph @ref occt_ocaf_9a_3 "Persistent Data Storage") @subsection occt_ocaf_1_3 Reference-key model @@ -159,7 +159,7 @@ In addition, application-specific data can be added by defining new attribute c attached to the reference-key. As such, on a parametrized model, after modifying the value of a parameter, the reference-keys still address the appropriate faces, even if their geometry has changed. - Consequently, you change the size of the cube shown in the figure 2 above, + Consequently, you change the size of the cube shown in the figure above, the user texture stay attached to the right face. Note As Topological naming is based on the reference-key and attributes such as Naming @@ -327,11 +327,7 @@ Standard_Integer tag = achild.Tag(); @subsection occt_ocaf_3_4 Label -The tag gives a persistent address to a label. The label – the semantics of the tag – is a place in the data framework where attributes, which contain data, are attached. The data framework is, in fact, a tree of labels with a root as the ultimate father label (refer to the following figure): - -@image html /user_guides/ocaf/images/ocaf_image007.png -@image latex /user_guides/ocaf/images/ocaf_image007.png - +The tag gives a persistent address to a label. The label – the semantics of the tag – is a place in the data framework where attributes, which contain data, are attached. The data framework is, in fact, a tree of labels with a root as the ultimate father label. Label can not be deleted from the data framework, so, the structure of the data framework that has been created can not be removed while the document is opened. Hence any kind of reference to an existing label will be actual while an application is working with the document. @@ -518,7 +514,7 @@ If you use the binary format, do the following: * Factory, which loads the document storage and retrieval drivers; and * AttributeDrivers, which calls the methods AddDrivers for all packages responsible for persistence of the document. 3. Create a plug-in implemented as an executable (see example *BinPlugin*). It calls a macro PLUGIN with the package name where you implemented the method Factory. -See Saving the document and Opening the document from a file for the description of document save/open mechanisms. +See @ref occt_ocaf_4_3_3 "Saving the document" and @ref occt_ocaf_4_3_4 "Opening the document from a file" for the description of document save/open mechanisms. If you decided to use the alternative way (create a new attribute by means of *UAttribute* and a combination of other standard attributes), do the following: 1. Set a *TDataStd_UAttribute* with a unique GUID attached to a label. This attribute defines the semantics of the data type (identifies the data type). @@ -529,7 +525,7 @@ Choosing the alternative way of implementation of new data types allows to forge Let’s study the implementation of the same data type in both ways by the example of transformation represented by *gp_Trsf* class. The class *gp_Trsf* defines the transformation according to the type (*gp_TrsfForm*) and a set of parameters of the particular type of transformation (two points or a vector for translation, an axis and an angle for rotation, and so on). -1. The first way: creation of a new attribute. The implementation of the transformation by creation of a new attribute is represented in the Samples. +1. The first way: creation of a new attribute. The implementation of the transformation by creation of a new attribute is represented in the @ref occt_ocaf_11 "Samples". 2. The second way: creation of a new data type by means of combination of standard attributes. Depending on the type of transformation it may be kept in data framework by different standard attributes. For example, a translation is defined by two points. Therefore the data tree for translation looks like this: * Type of transformation (gp_Translation) as *TDataStd_Integer*; diff --git a/dox/user_guides/shape_healing/shape_healing.md b/dox/user_guides/shape_healing/shape_healing.md index b4ea8d5e0c..2e15c00735 100644 --- a/dox/user_guides/shape_healing/shape_healing.md +++ b/dox/user_guides/shape_healing/shape_healing.md @@ -445,7 +445,7 @@ Let us correct the following wire: @image html /user_guides/shape_healing/images/shape_healing_image013.png "Initial shape" @image latex /user_guides/shape_healing/images/shape_healing_image013.png "Initial shape" -It is necessary to apply the Tools for the analysis of validity of wires to check that: +It is necessary to apply the @ref occt_shg_3_1_2 "tools for the analysis of wire validity" to check that: * the edges are correctly oriented; * there are no edges that are too short; * there are no intersecting adjacent edges; @@ -504,7 +504,7 @@ To see how this tool works, it is possible to take an edge, where the maximum de @image html /user_guides/shape_healing/images/shape_healing_image011.png "Initial shape" @image latex /user_guides/shape_healing/images/shape_healing_image011.png "Initial shape" -First it is necessary to apply the Tool for checking the validity of edges to find that maximum deviation between pcurve and 3D curve is greater than tolerance. Then we can use the repairing tool to increase the tolerance and make the deviation acceptable. +First it is necessary to apply the @ref occt_shg_3_1_3 "tool for checking the edge validity" to find that the maximum deviation between pcurve and 3D curve is greater than tolerance. Then we can use the repairing tool to increase the tolerance and make the deviation acceptable. ~~~~~ ShapeAnalysis_Edge sae; diff --git a/dox/user_guides/step/step.md b/dox/user_guides/step/step.md index e06ef889f4..c63caabf63 100644 --- a/dox/user_guides/step/step.md +++ b/dox/user_guides/step/step.md @@ -16,7 +16,7 @@ Open Cascade allows its users to employ STEP in the following domains: This manual is intended to provide technical documentation on the Open CASCADE Technology (**OCCT**) STEP processor and to help Open CASCADE Technology users with the use of the STEP processor (to read and write STEP files). -Only geometrical, topological STEP entities (shapes) and assembly structures are translated by the basic translator described in sections 2 to 6. Data that cannot be translated on this level are also loaded from a STEP file and can be translated later. XDE STEP translator (see section 7 Reading from and writing to XDE) translates names, colors, layers, validation properties and other data associated with shapes and assemblies into XDE document. +Only geometrical, topological STEP entities (shapes) and assembly structures are translated by the basic translator described in sections 2 to 6. Data that cannot be translated on this level are also loaded from a STEP file and can be translated later. XDE STEP translator (see section 7 @ref occt_step_7 "Reading from and writing to XDE") translates names, colors, layers, validation properties and other data associated with shapes and assemblies into XDE document. File translation is performed in the programming mode, via C++ calls. @@ -105,7 +105,7 @@ The types of STEP topological entities that can be translated are: * faces * shells * solids -For further information see Mapping STEP entities to Open CASCADE Technology shapes. +For further information see @ref occt_step_2_4 "Mapping STEP entities to Open CASCADE Technology shapes". @subsubsection occt_step_2_2_4 Geometrical entities The types of STEP geometrical entities that can be translated are: @@ -793,7 +793,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 Mapping OCCT shapes to STEP entities +Please 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 @@ -1176,7 +1176,7 @@ Physical file writing consists of the following steps: If it is necessary to write and translate an OCCT shape into a new entity by the STEP processor the Writer and Actor scope should be enhanced. -For a description of steps, which should be taken for adding a new entity type to the STEP processor, see Physical file reading. Then, enhance the *STEPControl_ActorWrite* class i.e. methods *Recognize()* and *Transfer()*, or other classes from *TopoDSToStep*, to translate the OCCT shape into a new STEP entity. +For a description of steps, which should be taken for adding a new entity type to the STEP processor, see @ref occt_step_4_2 "Physical file reading". Then, enhance the *STEPControl_ActorWrite* class i.e. methods *Recognize()* and *Transfer()*, or other classes from *TopoDSToStep*, to translate the OCCT shape into a new STEP entity. @section occt_step_6 Using DRAW @subsection occt_step_6_1 DRAW STEP Commands Overview @@ -1205,9 +1205,9 @@ Command xtrace is intended to view and change these parameters: @subsection occt_step_6_3 Reading a STEP file -For a description of parameters used in reading a STEP file refer to Setting the translation parameters section. +For a description of parameters used in reading a STEP file refer to @ref occt_step_2_3_3 "Setting the translation parameters" section. -For reading a STEP file, the following parameters are defined (see above, the command *param*): +For reading a STEP file, the following parameters are defined (see above, @ref occt_step_6_2 "the command *param*"): | Description | Name | Values | Meaning | | :------------ | :---- | :------- | :------- | @@ -1357,7 +1357,7 @@ When specifying min and max arguments this command saves shapes with tolerances * *c* - for shells and faces. @subsection occt_step_6_5 Writing a STEP file -For writing shapes to a STEP file, the following parameters are defined (see above, the command *param*): +For writing shapes to a STEP file, the following parameters are defined (see above, @ref occt_step_6_2 "the command *param*"): | Description | Name | Values | Meaning | | :------------ | :----- | :------ | :------- | @@ -1406,10 +1406,10 @@ IFSelect_ReturnStatus stat = reader.ReadFile("filename.stp"); Loading the file only memorizes the data, it does not translate it. @subsubsection occt_step_7_1_2 Checking the loaded STEP file -This step is not obligatory. See a description of this step in section Checking the STEP file. +This step is not obligatory. See a description of this step in section @ref occt_step_2_3_2 "Checking the STEP file". @subsubsection occt_step_7_1_3 Setting the parameters for translation to XDE -See a description of this step in section Setting the translation parameters. +See a description of this step in section @ref occt_step_2_3_3 "Setting the translation parameters". In addition, the following parameters can be set for XDE translation of attributes: * Parameter for transferring colors: diff --git a/dox/user_guides/visualization/visualization.md b/dox/user_guides/visualization/visualization.md index f64e64b0ff..f771d4dd4b 100644 --- a/dox/user_guides/visualization/visualization.md +++ b/dox/user_guides/visualization/visualization.md @@ -33,8 +33,8 @@ The figure below presents a schematic overview of the relations between the key To answer different needs of CASCADE users, this User's Guide offers the following three paths in reading it. - * If the 3D services proposed in AIS meet your requirements, you need only read chapter 3 AIS: Application Interactive Services. - * If you need more detail, for example, a selection filter on another type of entity - you should read chapter 2 Fundamental Concepts, chapter 3 AIS: Application Interactive Services, and 4 3D Presentations. You may want to begin with the chapter presenting AIS. + * If the 3D services proposed in AIS meet your requirements, you need only read chapter 3 @ref occt_visu_3 "AIS: Application Interactive Services". + * If you need more detail, for example, a selection filter on another type of entity - you should read chapter 2 @ref occt_visu_2 "Fundamental Concepts", chapter 3 @ref occt_visu_3 "AIS: Application Interactive Services", and 4 @ref occt_visu_4 "3D Presentations". You may want to begin with the chapter presenting AIS. For advanced information on visualization algorithms, see our E-learning & Training offerings. @@ -164,7 +164,7 @@ The interactive context is used to manage both selectable objects and selection Selection modes may be activated or de-activated for given selectable objects. Information is then provided about the status of activated/de-activated selection modes for a given object in a given selector. -See also AIS: Application Interactive Services. +See also @ref occt_visu_3 "AIS: Application Interactive Services". Let us consider, for example, a 3D selectable shape object, which corresponds to a topological shape. @@ -502,7 +502,7 @@ Inside these categories, additional characterization is available by means of a * *AIS_InteractiveObject::Type* * *AIS_InteractiveObject::Signature*. -**Note** that some signatures are already used by "standard" objects provided in AIS (see the list of Standard Interactive Object Classes). +**Note** that some signatures are already used by "standard" objects provided in AIS (see the @ref occt_visu_3_5 "List of Standard Interactive Object Classes". The interactive context can have a default mode of representation for the set of interactive objects. This mode may not be accepted by a given class of objects. @@ -555,7 +555,7 @@ void myPk_IsShape::Compute @subsubsection occt_visu_3_2_4 Selection -An interactive object can have an indefinite number of selection modes, each representing a "decomposition" into sensitive primitives; each primitive has an Owner (*SelectMgr_EntityOwner*) which allows identifying the exact entity which has been detected (see Dynamic Selection chapter). +An interactive object can have an indefinite number of selection modes, each representing a "decomposition" into sensitive primitives; each primitive has an Owner (*SelectMgr_EntityOwner*) which allows identifying the exact entity which has been detected (see ref occt_visu_3_6 "Dynamic Selection" chapter). The set of sensitive primitives, which correspond to a given mode, is stocked in a SELECTION (*SelectMgr_Selection*). @@ -563,7 +563,7 @@ Each Selection mode is identified by an index. By Convention, the default selec The calculation of Selection primitives (or sensitive primitives) is done by the intermediary of a virtual function, *ComputeSelection*. This should be implemented for each type of interactive object on which you want to make different type selections using the function *AIS_ConnectedInteractive::ComputeSelection*. -A detailed explanation of the mechanism and the manner of implementing this function has been given in Dynamic Selection chapter. +A detailed explanation of the mechanism and the manner of implementing this function has been given in @ref occt_visu_3_6 "Dynamic Selection" chapter. Moreover, just as the most frequently manipulated entity is *TopoDS_Shape*, the most used Interactive Object is *AIS_Shape*. You will see below activation functions for standard selection modes are proposed in the Interactive context (selection by vertex, by edges etc). To create new classes of interactive object with the same behavior as *AIS_Shape* - such as vertices and edges - you must redefine the virtual function *AIS_ConnectedInteractive::AcceptShapeDecomposition*. @@ -788,7 +788,7 @@ The specific modes of selection only concern the interactive objects, which are The local context can be opened using method *AIS_InteractiveContext::OpenLocalContext*. The following options are available: * *UseDisplayedObjects*: allows loading the interactive objects visualized at Neutral Point in the opened local context. If *FALSE*, the local context is empty after being opened. If *TRUE*, the objects at Neutral Point are modified by their default selection mode. - * *AllowShapeDecomposition*: *AIS_Shape* allows or prevents decomposition in standard shape location mode of objects at Neutral Point, which are type-privileged (see Selection chapter). This Flag is only taken into account when *UseDisplayedObjects* is *TRUE*. + * *AllowShapeDecomposition*: *AIS_Shape* allows or prevents decomposition in standard shape location mode of objects at Neutral Point, which are type-privileged (see @ref occt_visu_3_2_4 "Selection" chapter). This Flag is only taken into account when *UseDisplayedObjects* is *TRUE*. * *AcceptEraseOfObjects*: authorizes other local contexts to erase the interactive objects present in this context. This option is rarely used. The last option has no current use. This function returns the index of the created local context. It should be kept and used when the context is closed. @@ -1507,7 +1507,7 @@ void InteractiveBox::ComputeSelection Selectable objects are loaded in the selection manager, which has one or more selectors; in general, we suggest assigning one selector per viewer. All you have to do afterwards is to activate or deactivate the different selection modes for selectable objects. The *SelectionManager* looks after the call to the *ComputeSelection* functions for different objects. -NOTE: This procedure is completely hidden if you use the AIS Interactive Context +NOTE: This procedure is completely hidden if you use the @ref occt_visu_3_3 "AIS Interactive Context"

Example

~~~~~ @@ -2668,7 +2668,7 @@ myAISContext->Display (anAISShape); Follow the procedure below to compute the presentable object: -1. Build a presentable object inheriting from *AIS_InteractiveObject* (refer to the Chapter on Presentable Objects). +1. Build a presentable object inheriting from *AIS_InteractiveObject* (refer to the Chapter on @ref occt_visu_2_1 "Presentable Objects"). 2. Reuse the *Prs3d_Presentation* provided as an argument of the compute methods. **Note** that there are two compute methods: one for a standard representation, and the other for a degenerated representation, i.e. in hidden line removal and wireframe modes.