Move guides on documentation, tests, coding rules, contribution workflow to dox/contribution
user_guides/brep_wp/brep_wp.md
user_guides/vis/vis.md
-dev_guides/dev_guides.md
-dev_guides/documentation/documentation.md
-dev_guides/contribution/coding_rules.md
-dev_guides/contribution_workflow/contribution_workflow.md
-dev_guides/git_guide/git_guide.md
-dev_guides/tests/tests.md
+contribution/contribution.md
+contribution/documentation/documentation.md
+contribution/coding_rules.md
+contribution/contribution_workflow/contribution_workflow.md
+contribution/git_guide/git_guide.md
+contribution/tests/tests.md
debug/debug.md
upgrade/upgrade.md
dev_guides/visualization/pbr_math.md
user_guides/xde/xde.md
user_guides/vis/vis.md
-dev_guides/contribution_workflow/contribution_workflow.md
-dev_guides/documentation/documentation.md
-dev_guides/contribution/coding_rules.md
-dev_guides/git_guide/git_guide.md
-dev_guides/tests/tests.md
+contribution/contribution_workflow/contribution_workflow.md
+contribution/documentation/documentation.md
+contribution/coding_rules.md
+contribution/git_guide/git_guide.md
+contribution/tests/tests.md
+
upgrade/upgrade.md
dev_guides/visualization/pbr_math.md
--- /dev/null
+Coding Rules {#occt_dev_guides__coding_rules}
+======================================
+
+@tableofcontents
+
+@section occt_coding_rules_1 Introduction
+
+The purpose of this document is to define a common programming style for Open CASCADE Technology.
+
+The common style facilitates understanding and maintaining a code developed cooperatively by several programmers. In addition, it enables construction of tools that incorporate knowledge of these standards to help in the programming.
+
+OCCT programming style follows common and appropriate best practices, so some guidelines have been excerpted from the public domain.
+
+The guide can be improved in the future as new ideas and enhancements are added.
+
+@subsection occt_coding_rules_1_1 Scope of the document
+
+Rules in this document refer to C++ code. However, with minor exceptions due to language restrictions, they are applicable to any sources in Open CASCADE Technology framework, including:
+- C/C++
+- GLSL programs
+- OpenCL kernels
+- TCL scripts and test cases
+
+@section occt_coding_rules_2 Naming Conventions
+
+@subsection occt_coding_rules_2_1 General naming rules
+
+The names considered in this section mainly refer to the interface of Open CASCADE Technology libraries or source code itself.
+
+### International language [MANDATORY]
+
+Open CASCADE Technology is an open source platform available for an international community, thus all names need to be composed of English words or their abbreviations.
+
+### Meaningful names
+
+Names should be meaningful or, at least, contain a meaningful part. To better understand this requirement, let us examine the existing names of toolkits, packages, classes and methods:
+- Packages containing words *Geom* or *Geom2d* in their names are related to geometrical data and operations.
+- Packages containing words *TopoDS* or *BRep* in their names are related to topological data and operations.
+- Packages ending with <i>...Test</i> define Draw Harness plugins.
+- Methods starting with *Get...* and *Set...* are usually responsible for correspondingly retrieving and storing data.
+
+### Related names
+
+Names related to a logically connected functionality should have the same prefix (start with the same letters) or, at least, have any other common part.
+For example, method *GetCoord* returns a triple of real values and is defined for directions, vectors and points. The logical connection is obvious.
+
+### Camel Case style
+Camel Case style is preferred for names.
+For example:
+
+~~~~~{.cpp}
+Standard_Integer awidthofbox; // this is bad
+Standard_Integer width_of_box; // this is bad
+Standard_Integer aWidthOfBox; // this is OK
+~~~~~
+
+@subsection occt_coding_rules_2_2 Names of development units
+
+Usually a unit (e.g. a package) is a set of classes, methods, enumerations or any other sources implementing a common functionality, which is self-contained and independent from other parts of the library.
+
+### No underscores in unit names [MANDATORY]
+
+Names of units should not contain underscores, unless the use of underscores is allowed explicitly.
+
+### File name extensions [MANDATORY]
+
+The following extensions should be used for source files, depending on their type:
+
+* <i>.cxx</i> -- C++ source files
+* <i>.hxx</i> -- C++ header files
+* <i>.lxx</i> -- additional headers containing definitions of inline methods and auxiliary code
+
+Note that .lxx files should be avoided in most cases - inline method should be placed in header file instead.
+
+### Prefix for toolkit names [MANDATORY]
+
+Toolkit names are prefixed by *TK*, followed by a meaningful part of the name explaining the domain of functionality covered by the toolkit (e.g. *TKOpenGl*).
+
+### Names of public types
+
+Names of public classes and other types (structures, enums, typedefs) should match the common pattern: name of the package followed by underscore and suffix (the own name of the type):
+
+~~~~~
+ <package-name>_<class-name>
+~~~~~
+
+Static methods related to the whole package are defined in the class with the same name as package (without suffix).
+
+Each type should be defined in its own header file with the name of the type and extension ".hxx".
+Implementation should be placed in the file with the same name and extension ".cxx"; for large classes it is possible to split implementation into multiple source files with additional suffixes in the names (usually numerical, e.g. *BSplCLib_1.cxx*).
+
+For example, class *Adaptor2d_Curve2d* belongs to the package *Adaptor2d*; it is defined in header file *Adaptor2d_Curve2d.hxx* and implemented in source file *Adaptor2d_Curve2d.cxx*.
+
+This rule also applies to complex types constructed by instantiation of templates.
+Such types should be given own names using *typedef* statement, located in same-named header file.
+
+For example, see definition in the file *TColStd_IndexedDataMapOfStringString.hxx*:
+~~~~~
+typedef NCollection_IndexedDataMap<TCollection_AsciiString,TCollection_AsciiString,TCollection_AsciiString> TColStd_IndexedDataMapOfStringString;
+~~~~~
+
+### Names of functions
+
+The term **function** here is defined as:
+- Any class method
+- Any package method
+- Any non-member procedure or function
+
+It is preferred to start names of public methods from an upper case character and to start names of protected and private methods from a lower case character.
+
+
+~~~~~{.cpp}
+class MyPackage_MyClass
+{
+
+public:
+
+ Standard_Integer Value() const;
+ void SetValue (const Standard_Integer theValue);
+
+private:
+
+ void setIntegerValue (const Standard_Integer theValue);
+
+};
+~~~~~
+
+@subsection occt_coding_rules_2_3 Names of variables
+
+There are several rules that describe currently accepted practices for naming variables.
+
+### Naming of variables
+
+Name of a variable should not conflict with the existing or possible global names (for packages, macros, functions, global variables, etc.).
+
+The name of a variable should not start with an underscore.
+
+See the following examples:
+
+~~~~~{.cpp}
+Standard_Integer Elapsed_Time = 0; // this is bad - possible class name
+Standard_Integer gp = 0; // this is bad - existing package name
+Standard_Integer aGp = 0; // this is OK
+Standard_Integer _KERNEL = 0; // this is bad
+Standard_Integer THE_KERNEL = 0; // this is OK
+~~~~~
+
+### Names of function parameters
+
+The name of a function (procedure, class method) parameter should start with prefix *the* followed by the meaningful part of the name starting with a capital letter.
+
+See the following examples:
+
+~~~~~{.cpp}
+void Package_MyClass::MyFunction (const gp_Pnt& p); // this is bad
+void Package_MyClass::MyFunction (const gp_Pnt& theP); // this is OK
+void Package_MyClass::MyFunction (const gp_Pnt& thePoint); // this is preferred
+~~~~~
+
+### Names of class member variables
+
+The name of a class member variable should start with prefix *my* followed by the meaningful of the name starting with a capital letter.
+
+See the following examples:
+
+~~~~~{.cpp}
+Standard_Integer counter; // This is bad
+Standard_Integer myC; // This is OK
+Standard_Integer myCounter; // This is preferred
+~~~~~
+
+### Names of global variables
+
+It is strongly recommended to avoid defining any global variables.
+However, as soon as a global variable is necessary, its name should be prefixed by the name of a class or a package where it is defined followed with <i>_my</i>.
+
+See the following examples:
+
+~~~~~{.cpp}
+Standard_Integer MyPackage_myGlobalVariable = 0;
+Standard_Integer MyPackage_MyClass_myGlobalVariable = 0;
+~~~~~
+
+Static constants within the file should be written in upper-case and begin with prefix *THE_*:
+~~~~~{.cpp}
+namespace
+{
+ static const Standard_Real THE_CONSTANT_COEF = 3.14;
+};
+~~~~~
+
+### Names of local variables
+
+The name of a local variable should be distinguishable from the name of a function parameter, a class member variable and a global variable.
+
+It is preferred to prefix local variable names with *a* and *an* (or *is*, *to* and *has* for Boolean variables).
+
+See the following example:
+
+~~~~~{.cpp}
+Standard_Integer theI; // this is bad
+Standard_Integer i; // this is bad
+Standard_Integer index; // this is bad
+Standard_Integer anIndex; // this is OK
+~~~~~
+
+### Avoid dummy names
+Avoid dummy names, such as <i>i, j, k</i>. Such names are meaningless and easy to mix up.
+
+The code becomes more and more complicated when such dummy names are used there multiple times with different meanings, or in cycles with different iteration ranges, etc.
+
+See the following examples for preferred style:
+
+~~~~~{.cpp}
+void Average (const Standard_Real** theArray,
+ Standard_Integer theRowsNb,
+ Standard_Integer theRowLen,
+ Standard_Real& theResult)
+{
+ theResult = 0.0;
+ for (Standard_Integer aRow = 0; aRow < aRowsNb; ++aRow)
+ {
+ for (Standard_Integer aCol = 0; aCol < aRowLen; ++aCol)
+ {
+ theResult += theArray[aRow][aCol];
+ }
+ theResult /= Standard_Real(aRowsNb * aRowLen);
+ }
+}
+~~~~~
+
+@section occt_coding_rules_3 Formatting rules
+
+To improve the open source readability and, consequently, maintainability, the following set of rules is applied.
+
+### International language [MANDATORY]
+
+All comments in all sources must be in English.
+
+### Line length
+
+Try to stay within the limit of 120 characters per line in all sources.
+
+### C++ style comments
+
+Prefer C++ style comments in C++ sources.
+
+### Commenting out unused code
+
+Delete unused code instead of commenting it or using \#define.
+
+### Indentation in sources [MANDATORY]
+
+Indentation in all sources should be set to two space characters.
+Use of tabulation characters for indentation is disallowed.
+
+### Separating spaces
+
+Punctuation rules follow the rules of the English language.
+* C/C++ reserved words, commas, colons and semicolons should be followed by a space character if they are not at the end of a line.
+* There should be no space characters after '(' and before ')'. Closing and opening brackets should be separated by a space character.
+* For better readability it is also recommended to surround conventional operators by a space character.
+Examples:
+
+~~~~~{.cpp}
+while (true) // NOT: while( true ) ...
+{
+ DoSomething (theA, theB, theC, theD); // NOT: DoSomething(theA,theB,theC,theD);
+}
+for (anIter = 0; anIter < 10; ++anIter) // NOT: for (anIter=0;anIter<10;++anIter){
+{
+ theA = (theB + theC) * theD; // NOT: theA=(theB+theC)*theD
+}
+~~~~~
+
+### Declaration of pointers and references
+
+In declarations of simple pointers and references put asterisk (*) or ampersand (&) right after the type without extra space.
+
+Since declaration of several variables with mixed pointer types contrudicts this rule, it should be avoided. Instead, declare each variable independently with fully qualified type.
+
+Examples:
+
+~~~~~{.cpp}
+Standard_Integer *theVariable; // not recommended
+Standard_Integer * theVariable; // not recommended
+Standard_Integer* theVariable; // this is OK
+
+Standard_Integer *&theVariable; // not recommended
+Standard_Integer *& theVariable; // not recommended
+Standard_Integer*& theVariable; // this is OK
+
+Standard_Integer **theVariable; // not recommended
+Standard_Integer ** theVariable; // not recommended
+Standard_Integer** theVariable; // this is OK
+
+Standard_Integer *theA, theB, **theC; // not recommended (declare each variable independently)
+~~~~~
+
+### Separate logical blocks
+
+Separate logical blocks of code with one blank line and comments.
+
+See the following example:
+
+~~~~~{.cpp}
+// check arguments
+Standard_Integer anArgsNb = argCount();
+if (anArgsNb < 3 || isSmthInvalid)
+{
+ return THE_ARG_INVALID;
+}
+
+// read and check header
+...
+...
+
+// do our job
+...
+...
+~~~~~
+
+Notice that multiple blank lines should be avoided.
+
+### Separate function bodies [MANDATORY]
+
+Use function descriptive blocks to separate function bodies from each other.
+Each descriptive block should contain at least a function name and purpose description.
+
+See the following example:
+
+~~~~~{.cpp}
+// =======================================================================
+// function : TellMeSmthGood
+// purpose : Gives me good news
+// =======================================================================
+void TellMeSmthGood()
+{
+ ...
+}
+
+// =======================================================================
+// function : TellMeSmthBad
+// purpose : Gives me bad news
+// =======================================================================
+void TellMeSmthBad()
+{
+ ...
+}
+~~~~~
+
+### Block layout [MANDATORY]
+Figure brackets <i>{ }</i> and each operator <i>(for, if, else, try, catch)</i> should be written on a dedicated line.
+
+In general, the layout should be as follows:
+
+~~~~~{.cpp}
+while (expression)
+{
+ ...
+}
+~~~~~
+
+Entering a block increases and leaving a block decreases the indentation by one tabulation.
+
+### Single-line operators
+
+Single-line conditional operators <i>(if, while, for,</i> etc.) can be written without brackets on the following line.
+
+~~~~~{.cpp}
+if (!myIsInit) return Standard_False; // bad
+
+if (thePtr == NULL) // OK
+ return Standard_False;
+
+if (!theAlgo.IsNull()) // preferred
+{
+ DoSomething();
+}
+~~~~~
+
+Having all code in the same line is less convenient for debugging.
+
+### Comparison expressions with constants
+
+In comparisons, put the variable (in the current context) on the left side and constant on the right side of expression.
+That is, the so called "Yoda style" is to be avoided.
+
+~~~~~{.cpp}
+if (NULL != thePointer) // Yoda style, not recommended
+if (thePointer != NULL) // OK
+
+if (34 < anIter) // Yoda style, not recommended
+if (anIter > 34) // OK
+
+if (theNbValues >= anIter) // bad style (constant function argument vs. local variable)
+if (anIter <= theNbValues) // OK
+
+if (THE_LIMIT == theValue) // bad style (global constant vs. variable)
+if (theValue == THE_LIMIT) // OK
+~~~~~
+
+### Alignment
+
+Use alignment wherever it enhances the readability. See the following example:
+
+~~~~~{.cpp}
+MyPackage_MyClass anObject;
+Standard_Real aMinimum = 0.0;
+Standard_Integer aVal = theVal;
+switch (aVal)
+{
+ case 0: computeSomething(); break;
+ case 12: computeSomethingElse (aMinimum); break;
+ case 3:
+ default: computeSomethingElseYet(); break;
+}
+~~~~~
+
+### Indentation of comments
+
+Comments should be indented in the same way as the code to which they refer or they can be in the same line if they are short.
+
+The text of the comment should be separated from the slash character by a single space character.
+
+See the following example:
+
+~~~~~{.cpp}
+while (expression) //bad comment
+{
+ // this is a long multi-line comment
+ // which is really required
+ DoSomething(); // maybe, enough
+ DoSomethingMore(); // again
+}
+~~~~~
+
+### Early return statement
+
+Use an early return condition rather than collect indentations.
+
+Write like this:
+
+~~~~~{.cpp}
+Standard_Integer ComputeSumm (const Standard_Integer* theArray,
+ const Standard_Size theSize)
+{
+ Standard_Integer aSumm = 0;
+ if (theArray == NULL || theSize == 0)
+ {
+ return 0;
+ }
+
+ ... computing summ ...
+ return aSumm;
+}
+~~~~~
+
+Rather than:
+
+~~~~~{.cpp}
+Standard_Integer ComputeSumm (const Standard_Integer* theArray,
+ const Standard_Size theSize)
+{
+ Standard_Integer aSumm = 0;
+ if (theArray != NULL && theSize != 0)
+ {
+ ... computing summ ...
+ }
+ return aSumm;
+}
+~~~~~
+
+This helps to improve readability and reduce the unnecessary indentation depth.
+
+### Trailing spaces
+
+Trailing spaces should be removed whenever possible.
+Spaces at the end of a line are useless and do not affect functionality.
+
+### Headers order
+
+Split headers into groups: system headers, headers per each framework, project headers; sort the list of includes alphabetically.
+Within the class source file, the class header file should be included first.
+
+This rule improves readability, allows detecting useless multiple header inclusions and makes 3rd-party dependencies clearly visible.
+Inclusion of class header on top verifies consistency of the header (e.g. that header file does not use any undefined declarations due to missing includes of dependencies).
+
+An exception to the rule is ordering system headers generating a macros declaration conflicts (like "windows.h" or "X11/Xlib.h") - these headers should be placed in the way solving the conflict.
+
+The source or header file should include only minimal set of headers necessary for compilation, without duplicates (considering nested includes).
+
+~~~~~{.cpp}
+// the header file of implemented class
+#include <PackageName_ClassName.hxx>
+
+// OCCT headers
+#include <gp_Pnt.hxx>
+#include <gp_Vec.hxx>
+#include <NCollection_List.hxx>
+
+// Qt headers
+#include <QDataStream>
+#include <QString>
+
+// system headers
+#include <iostream>
+#include <windows.h>
+~~~~~
+
+@section occt_coding_rules_4 Documentation rules
+
+The source code is one of the most important references for documentation.
+The comments in the source code should be complete enough to allow understanding the corresponding code and to serve as basis for other documents.
+
+The main reasons why the comments are regarded as documentation and should be maintained are:
+- The comments are easy to reach -- they are always together with the source code;
+- It is easy to update a description in the comment when the source is modified;
+- The source by itself is a good context to describe various details that would require much more explanations in a separate document;
+- As a summary, this is the most cost-effective documentation.
+
+The comments should be compatible with Doxygen tool for automatic documentation generation (thus should use compatible tags).
+
+### Documenting classes [MANDATORY]
+
+Each class should be documented in its header file (.hxx).
+The comment should give enough details for the reader to understand the purpose of the class and the main way of work with it.
+
+### Documenting class methods [MANDATORY]
+
+Each class or package method should be documented in the header file (.hxx).
+
+The comment should explain the purpose of the method, its parameters, and returned value(s).
+Accepted style is:
+
+@verbatim
+//! Method computes the square value.
+//! @param theValue the input value
+//! @return squared value
+Standard_Export Standard_Real Square (Standard_Real theValue);
+@endverbatim
+
+### Documenting C/C++ sources
+
+It is very desirable to put comments in the C/C++ sources of the package/class.
+
+They should be detailed enough to allow any person to understand what each part of code does.
+
+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 @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.
+
+@section occt_coding_rules_5 Application design
+
+The following rules define the common style, which should be applied by any developer contributing to the open source.
+
+### Allow possible inheritance
+
+Try to design general classes (objects) keeping possible inheritance in mind.
+This rule means that the user who makes possible extensions of your class should not encounter problems of private implementation.
+Try to use protected members and virtual methods wherever you expect extensions in the future.
+
+### Avoid friend declarations
+
+Avoid using 'friend' classes or functions except for some specific cases (for example, iteration) 'Friend' declarations increase coupling.
+
+### Set/get methods
+
+Avoid providing set/get methods for all fields of the class.
+Intensive set/get functions break down encapsulation.
+
+### Hiding virtual functions [MANDATORY]
+
+Avoid hiding a base class virtual function by a redefined function with a different signature.
+Most of the compilers issue warning on this.
+
+### Avoid mixing error reporting strategies
+
+Try not to mix different error indication/handling strategies (exceptions or returned values) on the same application level.
+
+### Minimize compiler warnings [MANDATORY]
+
+When compiling the source pay attention to and try to minimize compiler warnings.
+
+### Avoid unnecessary inclusions
+
+Try to minimize compilation dependencies by removing unnecessary inclusions.
+
+@section occt_coding_rules_6 General C/C++ rules
+
+This section defines the rules for writing a portable and maintainable C/C++ source code.
+
+### Wrapping of global variables [MANDATORY]
+
+Use package or class methods returning reference to wrap global variables to reduce possible name space conflicts.
+
+### Avoid private members
+
+Use *protected* members instead of *private* wherever reasonable to enable future extensions.
+Use *private* fields if future extensions should be disabled.
+
+### Constants and inlines over defines [MANDATORY]
+
+Use constant variables (const) and inline functions instead of defines (\#define).
+
+### Avoid explicit numerical values [MANDATORY]
+
+Avoid usage of explicit numeric values. Use named constants and enumerations instead.
+Numbers produce difficulties for reading and maintenance.
+
+### Three mandatory methods
+
+If a class has a destructor, an assignment operator or a copy constructor, it usually needs the other two methods.
+
+### Virtual destructor
+
+A class with virtual function(s) ought to have a virtual destructor.
+
+### Overriding virtual methods
+
+Declaration of overriding method should contains specifiers "virtual" and "override"
+(using Standard_OVERRIDE alias for compatibility with old compilers).
+
+~~~~~{.cpp}
+class MyPackage_BaseClass
+{
+
+public:
+
+ Standard_EXPORT virtual Standard_Boolean Perform();
+
+};
+
+class MyPackage_MyClass : public MyPackage_BaseClass
+{
+
+public:
+
+ Standard_EXPORT virtual Standard_Boolean Perform() Standard_OVERRIDE;
+
+};
+~~~~~
+
+This makes class definition more clear (virtual methods become highlighted).
+
+Declaration of interface using pure virtual functions protects against
+incomplete inheritance at first level, but does not help when method is overridden multiple times within nested inheritance
+or when method in base class is intended to be optional.
+
+And here "override" specifier introduces additional protection against situations when interface changes might be missed
+(class might contain old methods which will be never called).
+
+### Default parameter value
+
+Do not redefine a default parameter value in an inherited function.
+
+### Use const modifier
+
+Use *const* modifier wherever possible (functions parameters, return values, etc.)
+
+### Usage of goto [MANDATORY]
+Avoid *goto* statement unless it is really needed.
+
+### Declaring variable in for() header
+
+Declare a cycle variable in the header of the *for()* statement if not used out of cycle.
+
+~~~~~{.cpp}
+Standard_Real aMinDist = Precision::Infinite();
+for (NCollection_Sequence<gp_Pnt>::Iterator aPntIter (theSequence);
+ aPntIter.More(); aPntIter.Next())
+{
+ aMinDist = Min (aMinDist, theOrigin.Distance (aPntIter.Value()));
+}
+~~~~~
+
+### Condition statements within zero
+
+Avoid usage of C-style comparison for non-boolean variables:
+
+~~~~~{.cpp}
+void Function (Standard_Integer theValue,
+ Standard_Real* thePointer)
+{
+ if (!theValue) // bad style - ambiguous logic
+ {
+ DoSome();
+ }
+
+ if (theValue == 0) // OK
+ {
+ DoSome();
+ }
+
+ if (thePointer != NULL) // OK, predefined NULL makes pointer comparison cleaner to reader
+ { // (nullptr should be used instead as soon as C++11 will be available)
+ DoSome2();
+ }
+}
+~~~~~
+
+@section occt_coding_rules_7 Portability issues
+
+This chapter contains rules that are critical for cross-platform portability.
+
+### Provide code portability [MANDATORY]
+
+The source code must be portable to all platforms listed in the official 'Technical Requirements'.
+The term 'portable' here means 'able to be built from source'.
+
+The C++ source code should meet C++03 standard.
+Any usage of compiler-specific features or further language versions (for example, C++11, until all major compilers on all supported platforms implement all its features) should be optional (used only with appropriate preprocessor checks) and non-exclusive (an alternative implementation compatible with other compilers should be provided).
+
+### Avoid usage of global variables [MANDATORY]
+
+Avoid usage of global variables. Usage of global variables may cause problems when accessed from another shared library.
+
+Use global (package or class) functions that return reference to static variable local to this function instead of global variables.
+
+Another possible problem is the order of initialization of global variables defined in various libraries that may differ depending on platform, compiler and environment.
+
+### Avoid explicit basic types
+
+Avoid explicit usage of basic types (*int*, *float*, *double*, etc.), use Open CASCADE Technology types from package *Standard: Standard_Integer, Standard_Real, Standard_ShortReal, Standard_Boolean, Standard_CString* and others or a specific *typedef* instead.
+
+### Use *sizeof()* to calculate sizes [MANDATORY]
+
+Do not assume sizes of types. Use *sizeof()* instead to calculate sizes.
+
+### Empty line at the end of file [MANDATORY]
+
+In accordance with C++03 standard source files should be trailed by an empty line.
+It is recommended to follow this rule for any plain text files for consistency and for correct work of git difference tools.
+
+@section occt_coding_rules_8 Stability issues
+
+The rules listed in this chapter are important for stability of the programs that use Open CASCADE Technology libraries.
+
+### Use *OSD::SetSignal()* to catch exceptions
+
+When using Open CASCADE Technology in an application, call *OSD::SetSignal()* function when the application is initialized.
+
+This will install C handlers for run-time interrupt signals and exceptions, so that low-level exceptions (such as access violation, division by zero, etc.) will be redirected to C++ exceptions
+that use *try {...} catch (Standard_Failure) {...}* blocks.
+
+The above rule is especially important for robustness of modeling algorithms.
+
+### Cross-referenced handles
+
+Take care about cycling of handled references to avoid chains, which will never be freed. For this purpose, use a pointer at one (subordinate) side.
+
+See the following example:
+
+~~~~{.cpp}
+ class Slave;
+
+ class Master : public Standard_Transient
+ {
+ ...
+ void SetSlave (const Handle(Slave)& theSlave)
+ {
+ mySlave = theSlave;
+ }
+ ...
+ private:
+ Handle(Slave) theSlave; // smart pointer
+ ...
+ }
+
+ class Slave : public Standard_Transient
+ {
+ ...
+ void SetMaster (const Handle(Master)& theMaster)
+ {
+ myMaster = theMaster.get();
+ }
+ ...
+ private:
+ Master* theMaster; // simple pointer
+ ...
+ }
+~~~~
+
+### C++ memory allocation
+
+In C++ use *new* and *delete* operators instead of *malloc()* and *free()*. Try not to mix different memory allocation techniques.
+
+### Match *new* and *delete* [MANDATORY]
+
+Use the same form of new and delete.
+
+~~~~~{.cpp}
+aPtr1 = new TypeA[n]; ... ; delete[] aPtr1;
+aPtr2 = new TypeB(); ... ; delete aPtr2;
+aPtr3 = Standard::Allocate (4096); ... ; Standard::Free (aPtr3);
+~~~~~
+
+### Methods managing dynamical allocation [MANDATORY]
+
+Define a destructor, a copy constructor and an assignment operator for classes with dynamically allocated memory.
+
+### Uninitialized variables [MANDATORY]
+
+Every variable should be initialized.
+
+~~~~~{.cpp}
+Standard_Integer aTmpVar1; // bad
+Standard_Integer aTmpVar2 = 0; // OK
+~~~~~
+
+Uninitialized variables might be kept only within performance-sensitive code blocks and only when their initialization is guaranteed by subsequent code.
+
+### Do not hide global *new*
+
+Avoid hiding the global *new* operator.
+
+### Assignment operator
+
+In *operator=()* assign to all data members and check for assignment to self.
+
+### Float comparison
+
+Don't check floats for equality or non-equality; check for GT, GE, LT or LE.
+
+~~~~~{.cpp}
+if (Abs (theFloat1 - theFloat2) < theTolerance)
+{
+ DoSome();
+}
+~~~~~
+
+Package *Precision* provides standard values for SI units and widely adopted by existing modeling algorithms:
+
+- *Precision::Confusion()* for lengths in meters;
+- *Precision::Angular()* for angles in radians.
+
+as well as definition of infinite values within normal range of double precision:
+- *Precision::Infinite()*
+- *Precision::IsInfinite()*
+- *Precision::IsPositiveInfinite()*
+- *Precision::IsNegativeInfinite()*
+
+### Non-indexed iteration
+
+Avoid usage of iteration over non-indexed collections of objects.
+If such iteration is used, make sure that the result of the algorithm does not depend on the order of iterated items.
+
+Since the order of iteration is unpredictable in case of a non-indexed collection of objects, it frequently leads to different behavior of the application from one run to another, thus embarrassing the debugging process.
+
+It mostly concerns mapped objects for which pointers are involved in calculating the hash function. For example, the hash function of *TopoDS_Shape* involves the address of *TopoDS_TShape* object. Thus the order of the same shape in the *TopTools_MapOfShape* will vary in different sessions of the application.
+
+### Do not throw in destructors
+
+Do not throw from within a destructor.
+
+### Assigning to reference [MANDATORY]
+
+Avoid the assignment of a temporary object to a reference. This results in a different behavior for different compilers on different platforms.
+
+@section occt_coding_rules_9 Performance issues
+
+These rules define the ways of avoiding possible loss of performance caused by ineffective programming.
+
+### Class fields alignment
+
+Declare fields of a class in the decreasing order of their size for better alignment.
+Generally, try to reduce misaligned accesses since they impact the performance (for example, on Intel machines).
+
+### Fields initialization order [MANDATORY]
+
+List class data members in the constructor's initialization list in the order they are declared.
+
+~~~~~{.cpp}
+class MyPackage_MyClass
+{
+
+public:
+
+ MyPackage_MyClass()
+ : myPropertyA (1),
+ myPropertyB (2) {}
+
+// NOT
+// : myPropertyB (2),
+// myPropertyA (1) {}
+
+private:
+
+ Standard_Integer myPropertyA;
+ Standard_Integer myPropertyB;
+
+};
+~~~~~
+
+### Initialization over assignment
+
+Prefer initialization over assignment in class constructors.
+
+~~~~~{.cpp}
+MyPackage_MyClass()
+: myPropertyA (1) // preferred
+{
+ myPropertyB = 2; // not recommended
+}
+~~~~~
+
+### Optimize caching
+
+When programming procedures with extensive memory access, try to optimize them in terms of cache behavior. Here is an example of how the cache behavior can be impacted:
+
+On x86 this code
+
+~~~~~{.cpp}
+Standard_Real anArray[4096][2];
+for (Standard_Integer anIter = 0; anIter < 4096; ++anIter)
+{
+ anArray[anIter][0] = anArray[anIter][1];
+}
+~~~~~
+
+is more efficient then
+
+~~~~~{.cpp}
+Standard_Real anArray[2][4096];
+for (Standard_Integer anIter = 0; anIter < 4096; ++anIter)
+{
+ anArray[0][anIter] = anArray[1][anIter];
+}
+~~~~~
+
+since linear access does not invalidate cache too often.
+
+@section occt_coding_rules_10 Draw Harness command
+
+Draw Harness provides TCL interface for OCCT algorithms.
+
+There is no TCL wrapper over OCCT C++ classes, instead interface is provided through the set of TCL commands implemented in C++.
+
+There is a list of common rules which should be followed to implement well-formed Draw Harness command.
+
+### Return value
+
+Command should return 0 in most cases even if the executed algorithm has failed. Returning 1 would lead to a TCL exception, thus should be used in case of a command line syntax error and similar issues.
+
+### Validate input parameters
+
+Command arguments should be validated before usage. The user should see a human-readable error description instead of a runtime exception from the executed algorithm.
+
+### Validate the number of input parameters
+
+Command should warn the user about unknown arguments, including cases when extra parameters have been pushed for the command with a fixed number of arguments.
+
+~~~~~{.cpp}
+ if (theArgsNb != 3)
+ {
+ std::cout << "Syntax error - wrong number of arguments!\n";
+ return 1;
+ }
+
+ Standard_Integer anArgIter = 1;
+ Standard_CString aResName = theArgVec[anArgIter++];
+ Standard_CString aFaceName = theArgVec[anArgIter++];
+ TopoDS_Shape aFaceShape = DBRep::Get (aFaceName);
+ if (aFaceShape.IsNull()
+ || aFaceShape.ShapeType() != TopAbs_FACE)
+ {
+ std::cout << "Shape " << aFaceName << " is empty or not a Face!\n";
+ return 1;
+ }
+ DBRep::Set (aResName, aFaceShape);
+ return 0;
+~~~~~
+
+### Message printing
+
+Informative messages should be printed into standard output *std::cout*, whilst command results (if any) -- into Draw Interpreter.
+
+Information printed into Draw Interpreter should be well-structured to allow usage in TCL script.
+
+### Long list of arguments
+
+Any command with a long list of obligatory parameters should be considered as ill-formed by design.
+Optional parameters should start with flag name (with '-' prefix) and followed by its values:
+
+~~~~~{.tcl}
+myCommand -flag1 value1 value2 -flag2 value3
+~~~~~
+
+### Arguments parser
+
+- Integer values should be read using *Draw::Atoi()* function.
+- Real values should be read using *Draw::Atof()* function.
+- Flags names should be checked in case insensitive manner.
+
+Functions *Draw::Atof()* and *Draw::Atoi()* support expressions and read values in C-locale.
+
+~~~~~{.cpp}
+ Standard_Real aPosition[3] = {0.0, 0.0, 0.0};
+ for (Standard_Integer anArgIter = 1; anArgIter < theArgsNb; ++anArgIter)
+ {
+ Standard_CString anArg = theArgVec[anArgIter];
+ TCollection_AsciiString aFlag (anArg);
+ aFlag.LowerCase(); //!< for case insensitive comparison
+ if (aFlag == "position")
+ {
+ if ((anArgIt + 3) >= theArgsNb)
+ {
+ std::cerr << "Wrong syntax at argument '" << anArg << "'!\n";
+ return 1;
+ }
+ aPosition[0] = Draw::Atof (theArgVec[++anArgIt]);
+ aPosition[1] = Draw::Atof (theArgVec[++anArgIt]);
+ aPosition[2] = Draw::Atof (theArgVec[++anArgIt]);
+ }
+ else
+ {
+ std::cout << "Syntax error! Unknown flag '" << anArg << "'\n";
+ return 1;
+ }
+ }
+~~~~~
+
+@section occt_coding_rules_11 Examples
+
+### Sample documented class
+
+@verbatim
+class Package_Class
+{
+
+public: //! @name public methods
+
+ //! Method computes the square value.
+ //! @param theValue the input value
+ //! @return squared value
+ Standard_Export Standard_Real Square (const Standard_Real theValue);
+
+private: //! \@name private methods
+
+ //! Auxiliary method
+ void increment();
+
+private: //! \@name private fields
+
+ Standard_Integer myCounter; //!< usage counter
+
+};
+
+
+@endverbatim
+
+~~~~~
+#include <Package_Class.hxx>
+// ==========================================================
+// function : Square
+// purpose : Method computes the square value
+// ==========================================================
+Standard_Real Package_Class::Square (const Standard_Real theValue)
+{
+ increment();
+ return theValue * theValue;
+}
+
+// ==========================================================
+// function : increment
+// purpose :
+// ==========================================================
+void Package_Class::increment()
+{
+ ++myCounter;
+}
+~~~~~
+
+### TCL script for Draw Harness
+
+~~~~~{.tcl}
+# show fragments (solids) in shading with different colors
+proc DisplayColored {theShape} {
+ set aSolids [uplevel #0 explode $theShape so]
+ set aColorIter 0
+ set THE_COLORS {red green blue1 magenta1 yellow cyan1 brown}
+ foreach aSolIter $aSolids {
+ uplevel #0 vdisplay $aSolIter
+ uplevel #0 vsetcolor $aSolIter [lindex $THE_COLORS [expr [incr aColorIter] % [llength $THE_COLORS]]]
+ uplevel #0 vsetdispmode $aSolIter 1
+ uplevel #0 vsetmaterial $aSolIter plastic
+ uplevel #0 vsettransparency $aSolIter 0.5
+ }
+}
+
+# load modules
+pload MODELING VISUALIZATION
+
+# create boxes
+box bc 0 0 0 1 1 1
+box br 1 0 0 1 1 2
+compound bc br c
+
+# show fragments (solids) in shading with different colors
+vinit View1
+vclear
+vaxo
+vzbufftrihedron
+DisplayColored c
+vfit
+vdump $imagedir/${casename}.png 512 512
+~~~~~
+
+### GLSL program:
+~~~~~{.fs}
+vec3 Ambient; //!< Ambient contribution of light sources
+vec3 Diffuse; //!< Diffuse contribution of light sources
+vec3 Specular; //!< Specular contribution of light sources
+
+//! Computes illumination from light sources
+vec4 ComputeLighting (in vec3 theNormal,
+ in vec3 theView,
+ in vec4 thePoint)
+{
+ // clear the light intensity accumulators
+ Ambient = occLightAmbient.rgb;
+ Diffuse = vec3 (0.0);
+ Specular = vec3 (0.0);
+ vec3 aPoint = thePoint.xyz / thePoint.w;
+ for (int anIndex = 0; anIndex < occLightSourcesCount; ++anIndex)
+ {
+ int aType = occLight_Type (anIndex);
+ if (aType == OccLightType_Direct)
+ {
+ directionalLight (anIndex, theNormal, theView);
+ }
+ else if (aType == OccLightType_Point)
+ {
+ pointLight (anIndex, theNormal, theView, aPoint);
+ }
+ }
+
+ return vec4 (Ambient, 1.0) * occFrontMaterial_Ambient()
+ + vec4 (Diffuse, 1.0) * occFrontMaterial_Diffuse()
+ + vec4 (Specular, 1.0) * occFrontMaterial_Specular();
+}
+
+//! Entry point to the Fragment Shader
+void main()
+{
+ gl_FragColor = computeLighting (normalize (Normal),
+ normalize (View),
+ Position);
+}
+~~~~~
--- /dev/null
+ Developer Guides {#dev_guides}
+================
+
+The following documents provide information on OCCT building, development and testing:
+
+* @subpage occt_dev_guides__building "Building OCCT from sources"
+* @subpage occt_dev_guides__documentation "Documentation system"
+* @subpage occt_dev_guides__coding_rules "Coding Rules"
+* @subpage occt_dev_guides__contribution_workflow "Contribution Workflow"
+* @subpage occt_dev_guides__git_guide "Guide to installing and using Git for OCCT development"
+* @subpage occt_dev_guides__tests "Automatic Testing system"
+* @subpage occt_dev_guides__debug "Debugging tools and hints"
+
+The following documents provide information on OCCT algorithms background:
+
+* @subpage occt_dev_guides__pbr_math "Physically-based Rendering math (PBR for rasterization)"
+
+The following guide provides information relevant to upgrading applications developed with previous versions of OCCT, to recent one:
+
+* @subpage occt_dev_guides__upgrade "Upgrade from previous OCCT versions"
--- /dev/null
+Contribution Workflow {#occt_dev_guides__contribution_workflow}
+====================================
+@tableofcontents
+
+@section occt_contribution_intro Introduction
+
+The purpose of this document is to describe standard workflow for processing contributions to certified version of OCCT.
+
+@subsection occt_contribution_intro_tracker Use of issue tracker system
+
+Each contribution should have corresponding issue (bug, or feature, or integration request)
+registered in the MantisBT issue tracker system accessible by URL
+https://tracker.dev.opencascade.org.
+The issue is processed according to the described workflow.
+
+@subsection occt_contribution_intro_access Access levels
+
+Access level defines the permissions of the user to view, register and modify issues in the issue tracker.
+The correspondence of access level and user permissions is defined in the table below.
+
+| Access level | Granted to | Permissions | Can set statuses |
+|:------------- | :--------- | :-------------- | :----------------------- |
+| Viewer | Everyone (anonymous access) | View public issues only | None |
+| Updater | Users registered on dev.opencascade.org, in Open CASCADE project | View and comment issues | None |
+| Reporter | Users registered on dev.opencascade.org, in Community project | View, report, and comment issues | New, Resolved, Feedback |
+| Developer | OCC developers and (in Community project) external contributors who signed the CLA | View, report, modify, and handle issues | New, Assigned, Resolved, Reviewed, Feedback |
+| Tester | OCC engineer devoted to certification testing | View, report, modify, and handle issues | Assigned, Tested, Feedback |
+| Maintainer | Person responsible for a project or OCCT component | View, report, modify, and handle issues | New, Resolved, Reviewed, Tested, Closed, Feedback |
+| Bugmaster | Person responsible for Mantis issue tracker, integrations, certification, and releases | Full access | All statuses |
+
+According to his access level, the user can participate in the issue handling process under different roles, as described below.
+
+@section occt_contribution_workflow Standard workflow for an issue
+
+@subsection occt_contribution_workflow_general General scheme
+
+<center>
+@figure{OCCT_ContributionWorkflow_V3_image001.svg,"Standard life cycle of an issue",360}
+</center>
+
+@subsection occt_contribution_workflow_issue Issue registration
+
+An issue is registered in Mantis bugtracker by the **Reporter** with definition of the necessary attributes (see also @ref occt_contribution_app):
+
+**Category** -- indicates the OCCT component, to which the issue relates.
+ (If in doubt, assign to OCCT:Foundation Classes.)
+
+**Severity** -- indicates the impact of the issue in the context where it was discovered.
+
+**Profile** -- specifies the configuration, on which the problem was detected.
+For specific configurations it is possible to specify separately platform, OS, and version.
+These fields can be left empty if the issue is not configuration-specific.
+Additional details relevant for the environment where the issue is reproduced (such as compiler version, bitness, etc.) can be provided in the **Description**.
+
+**Products Version** -- defines the OCCT version, on which the problem has been detected.
+
+It is preferable to indicate the version of the earliest known official release where the problem can be reproduced.
+If the issue is reported on the current development version of OCCT, the current development version should be used (for convenience, this version is marked by asterisk in Mantis).
+
+@note OCCT version number can be consulted in the file Standard_Version.hxx (value of OCC_VERSION_COMPLETE macro).
+
+**Assign to** -- developer to whom the issue will be assigned.
+ By default, it is set to **Maintainer** of the OCCT component selected in **Category** field.
+
+**Target Version** -- defines the target version for the fix to be provided.
+ By default, it is set to the current version under development.
+
+**Summary** -- a short, one sentence description of the issue.
+
+The **Summary** has a limit of 128 characters.
+It should be informative and useful for the developers.
+It is not allowed to mention the issue originator, and in particular the customer, in the name of the registered issue.
+
+A good practice is to start the issue with indication of the relevant component (OCCT module, package, class etc.) to better represent its context.
+
+The summary should be given in imperative mood when it can be formulated as goal to be achieved or action to be done.
+In particular, this applies to feature requests and improvements, for instance:
+
+> *Visualization - provide a support of zoom persistent selection*
+
+If the issue reports a problem, the summary should be given in Present Simple.
+If reported problem is believed to be a regression, it is recommended to indicate this in the summary, like this:
+
+> [Regression in 6.9.0] *IGES - Export of a reversed face leads to wrong data*
+
+**Description** -- should contain a detailed definition of the nature of the registered issue depending on its type.
+
+For a bug it is required to submit a detailed description of the incorrect behavior, including the indication of the cause of the problem (if known at this stage), and details on the context where the issue has been detected.
+
+For a feature or integration request it is necessary to describe the proposed feature in details (as much as possible at that stage), including the changes required for its implementation and the main features of the new functionality.
+
+Example:
+
+> *Currently selection does not work correctly for non-zoomable objects (those defined using transform persistence). To provide correct selection for such objects, first-level (object) BVH structures must be updated on each camera change, and frustum must be rebuilt accordingly.*
+
+@note In the description and notes to the issues you can refer to another issue by its ID prefixed by number sign (e.g.: #12345), and refer to a note by its ID prefixed by tilde (e.g.: ~20123).
+These references will be expanded by Mantis into links to the corresponding issue or note.
+When the number sign or the tilde followed by digits are a part of a normal text, add a space before digits (e.g.: "face # 12345 contains ~ 1000 edges") to avoid this conversion.
+
+**Steps To Reproduce** -- allows describing in detail how to reproduce the issue.
+
+This information is crucial for the developer to investigate the cause of the problem and to create the test case.
+The optimal approach is to give a sequence of @ref occt_user_guides__test_harness "DRAW Test Harness" commands to reproduce the problem in DRAW.
+This information can also be provided as a DRAW Tcl script attached to the issue (in **Upload File** field).
+
+**Additional information and documentation updates** -- any additional information, remarks to be taken into account in Release Notes, etc..
+
+**Upload File** -- allows attaching the shapes, snapshots, scripts, documents, or modified source files of OCCT.
+
+This field can be used to attach a prototype test case in form of a Tcl script for DRAW, a C++ code which can be organized in DRAW commands, sample shapes, documents describing proposed change or analysis of the problem, or other data required for reproduction of the issue.
+Where applicable, pictures demonstrating a problem and/or desired result can be attached.
+
+The newly registered issue gets status **NEW** and is assigned to the person indicated in the **Assign to** field.
+
+@subsection occt_contribution_workflow_assign Assigning the issue
+
+The description of the new issue is checked by the **Maintainer** and if it is feasible, he may assign the issue to a **Developer**.
+Alternatively, any user with **Developer** access level or higher can assign the issue to himself if he wants to provide a solution.
+
+The recommended way to handle contributions is that the **Reporter** assigns the issue to himself and provides a solution.
+
+The **Maintainer** or **Bugmaster** can close or reassign the issue (in **FEEDBACK** state) to the **Reporter** after it has been registered, if its description does not contain sufficient details to reproduce the bug or explain the need of the new feature.
+That decision shall be documented in the comments to the issue in the Bugtracker.
+
+The assigned issue has status **ASSIGNED**.
+
+@subsection occt_contribution_workflow_fix Resolving the issue
+
+The **Developer** responsible for the issue assigned to him provides a solution including:
+
+* Changes in the code, with appropriate comments;
+* Test case (when applicable) and data necessary for its execution;
+* Changes in the user and developer guides (when necessary).
+
+The change is integrated to branch named CRxxxxx (where **xxxxx** is issue number) in the OCCT Git repository, based on current master, and containing a single commit with the appropriate description.
+Then the issue is switched to **RESOLVED** for further review and testing.
+
+The following sub-sections describe this process, relevant requirements and options, in more details.
+
+@subsubsection occt_contribution_workflow_fix_code Requirements to the code modification
+
+The amount of code affected by the change should be limited to the changes required for the bug fix or improvement.
+Change of layout or re-formatting of the existing code is allowed only in the parts where meaningful changes related to the issue have been made.
+
+@note If deemed useful, re-formatting or cosmetic changes affecting considerable parts of the code can be made within a dedicated issue.
+
+The changes should comply with the OCCT @ref occt_dev_guides__coding_rules "Codng Rules".
+It is especially important to comment the code properly so that other people can understand it easier.
+
+The modification should be tested by running OCCT tests (on the platform and scope available to **Developer**) and ensuring absence of regressions.
+In case if modification affects results of some existing test case and the new result is correct, such test case should be updated to report OK (or BAD), as descibed in @ref testmanual_details_results "Automated Test System / Interpretation of Test Results".
+
+@subsubsection occt_contribution_workflow_fix_test Providing a test case
+
+For modifications affecting OCCT functionality, a test case should be created (unless already exists) and included in the commit or patch.
+See @ref testmanual_intro_quick_create "Automated Test System / Creating a New Test" for relevant instructions.
+
+The data files required for a test case should be attached to the corresponding issue in Mantis (i.e. not included in the commit).
+
+When the test case cannot be provided for any reason, the maximum possible information on how the problem can be reproduced and how to check the fix should be provided in the **Steps to Reproduce** field of an issue.
+
+@subsubsection occt_contribution_workflow_fix_doc Updating user and developer guides
+
+If the change affects a functionality described in @ref user_guides "User Guides", the corresponding user guide should be updated to reflect the change.
+
+If the change affects OCCT test system, build environment, or development tools described in @ref dev_guides "Developer Guides", the corresponding guide should be updated.
+
+The changes that break compatibility with the previous versions of OCCT (i.e. affecting API or behavior of existing functionality in the way that may require update of existing applications based on an earlier official release of OCCT to work correctly) should be described in the document @ref occt_dev_guides__upgrade "Upgrade from previous OCCT versions".
+It is recommended to add a sub-section for each change described.
+The description should provide the explanation of the incompatibility introduced by the change, and describe how it can be resolved (at least, in known situations).
+When feasible, the automatic upgrade procedure (adm/upgrade.tcl) can be extended by a new option to perform the required upgrade of the dependent code automatically.
+
+@subsubsection occt_contribution_workflow_fix_git Submission of change as a Git branch
+
+The modification of sources should be provided in the dedicated branch of the official OCCT Git repository.
+
+The branch should contain a single commit, with the appropriate commit message (see @ref occt_contribution_workflow_fix_commit "Requirements to the commit message" below).
+
+In general, this branch should be based on the recent version of the master branch.
+It is highly preferable to submit changes basing on the current master.
+In case if the fix is implemented on the previous release of OCCT, the branch can be based on the corresponding tag in Git, instead of the master.
+
+The branch name should be composed of letters **CR** (abbreviation of "Change Request") followed by the issue ID number (without leading zeros).
+It is possible to add an optional suffix to the branch name after the issue ID, e.g. to distinguish between several versions of the fix (see @ref occt_contribution_nonstd_rebase).
+
+See @ref occt_dev_guides__git_guide "Guide to using GIT" for help.
+
+@note When a branch with the name given according to the above rule is pushed to Git, a note is automatically added to the corresponding issue in Mantis, indicating the person who has made the push, the commit hash, and (for new commits) the description.
+
+@subsubsection occt_contribution_workflow_fix_commit Requirements to the commit message
+
+The commit message posted in Git constitutes an integral part of both the fix and the release documentation.
+
+The first line of the commit message should contain the Summary of the issue (starting with its ID followed by colon, e.g. "0022943: Bug in TDataXtd_PatternStd"), followed by an empty line.
+
+The following lines should provide a description of the context and details on the changes made.
+The contents and the recommended structure of the description depend on the nature of the bug.
+
+In a general case, the following elements should be present:
+* **Problem** -- a description of the unwanted behavior;
+* **Change** -- a description of the implemented changes, including the names of involved classes / methods / enumerations etc.;
+* **Result** -- a description of the current behavior (after the implementation).
+
+Example:
+
+> *0026330: BRepOffsetAPI_ThruSections creates invalid shape.*
+>
+> *Methods BRep_Tool::CurveOnSurface() and BRepCheck_Edge::InContext() now properly handle parametric range on a 3D curve when it is used to generate a p-curve dynamically (on a planar surface) and both the surface and the 3D curve have non-null locations.*
+
+Provide sufficient context so that potential user of the affected functionality can understand what has been changed and how the algorithm works now.
+Describe reason and essence of the changes made, but do not go too deep into implementation details -- these should be reflected in comments in the code.
+
+@subsubsection occt_contribution_workflow_fix_resolve Marking issue as resolved
+
+To mark the change as ready for review and testing, the corresponding issue should be switched to **RESOLVED** state.
+By default, the issue gets assigned to the **Maintainer** of the component, who is thus responsible for its review.
+Alternatively, another person can be selected as a reviewer at this step.
+
+When the issue is switched to **RESOLVED**, it is required to update or fill the field **Steps to reproduce**.
+The possible variants are:
+
+* The name of an existing or new test case (preferred variant);
+* A sequence of DRAW commands;
+* N/A (Not required / Not possible / Not applicable);
+* Reference to an issue in the bug tracker of another project.
+
+@subsection occt_contribution_workflow_review Code review
+
+The **Reviewer** analyzes the proposed solution for applicability in accordance with OCCT @ref occt_dev_guides__coding_rules "Coding Rules" and examines all changes in the sources, test case(s), and documentation to detect obvious and possible errors, misprints, or violations of the coding style.
+
+If the Reviewer detects some problems, he can either:
+
+* Fix these issues and provide a new solution.
+ The issue can then be switched to **REVIEWED**.
+
+ In case of doubt or possible disagreement the **Reviewer** can reassign the issue (in **RESOLVED** state) to the **Developer**, who then becomes a **Reviewer**.
+ Possible disagreements should be resolved through discussion, which is done normally within issue notes (or on the OCCT developer’s forum if necessary).
+
+* Reassign the issue back to the **Developer**, providing detailed list of remarks. The issue then gets status **ASSIGNED** and a new solution should be provided.
+
+If Reviewer does not detect any problems, or provides a corrected version, he changes status to **REVIEWED**.
+The issue gets assigned to the **Bugmaster**.
+
+@subsection occt_contribution_workflow_test Testing
+
+ The issues that are in **REVIEWED** state are subject of certification (non-regression) testing.
+ The issue is assigned to an OCCT **Tester** when he starts processing it.
+
+ If the branch submitted for testing is based on obsolete status of the master branch, **Tester** @ref occt_contribution_nonstd_rebase "rebases" it on master HEAD.
+ In case of conflicts, the issue is assigned back to **Developer** in **FEEDBACK** status, requesting for a rebase.
+
+ Certification testing includes:
+ * Addition of new data models (if required for a new test case) to the data base;
+ * Revision of the new test case(s) added by developer, and changes in the existing test cases included in commit.
+ The **Tester** can amend tests to ensure their correct behavior in the certification environment.
+ * Building OCCT on a sub-set of supported configurations (OS and compiler), watching for errors and warnings;
+ * Execution of tests on sub-set of supported platforms (at least, one Windows and one Linux configuration), watching for regressions;
+ * Building OCCT samples, watching for errors;
+ * Building and testing of OCC products based on OCCT.
+
+If the **Tester** does not detect problems or regressions, he changes the status to **TESTED** for further integration.
+
+If the **Tester** detects build problems or regressions, he changes the status to **ASSIGNED** and reassigns the issue to the **Developer** with a detailed description of the problems.
+The **Developer** should analyze the reported problems and, depending on results of this analysis, either:
+* Confirm that the detected problems are expected changes and they should be accepted as a new status of the code. Then the issue should be switched to **FEEDBACK** and assigned to the **Bugmaster**.
+* Produce a new solution (see @ref occt_contribution_workflow_fix, and also @ref occt_contribution_nonstd_minor).
+
+@subsection occt_contribution_workflow_integrate Integration of a solution
+
+Before integration into the master branch of the repository the **Integrator** checks the following conditions:
+ * the change has been reviewed;
+ * the change has been tested without regressions (or with regressions treated properly);
+ * the test case has been created for this issue (when applicable), and the change has been rechecked on this test case;
+ * the change does not conflict with other changes integrated previously.
+
+If the result of check is successful the Integrator integrates the solution into the branch.
+The integrations are performed weekly; integration branches are named following the pattern IR-YYYY-MM-DD.
+
+Each change is integrated as a single commit without preserving the history of changes made in the branch (by rebase, squashing all intermediate commits if any), however, preserving the author when possible.
+This is done to have the master branch history plain and clean.
+The following picture illustrates the process:
+
+@figure{OCCT_ContributionWorkflow_V3_image002.png,"Integration of several branches",420}
+
+The new integration branch is tested against possible regressions that might appear due to interference between separate changes.
+When the tests are OK, the integration branch is pushed as the new master to the official repository.
+The issue status is set then to **VERIFIED** and is assigned to the **Reporter** so that he could check the fix as integrated.
+
+The branches corresponding to the integrated fixes are removed from the repository by the **Bugmaster**.
+
+@subsection occt_contribution_workflow_close Closing an issue
+
+When possible, the **Reporter** should check whether the problem is actually resolved in the environment where it has been discovered, after the fix is integrated to master.
+If the fix does not actually resolve the original problem, the issue in **VERIFIED** status can be reopened and assigned back to the **Developer** for rework.
+The details on how to check that the issue is still reproducible should be provided.
+However, if the issue does resolve the problem as described in the original report, but a similar problem is discovered for another input data or configuration, or the fix has caused a regression, that problem should be registered as a separate (@ref occt_contribution_nonstd_relate "related") issue.
+
+If the fix integrated to master causes regressions, **Bugmaster** can revert it and reopen the issue.
+
+The **Bugmaster** closes the issue after the regular OCCT Release, provided that the issue status is **VERIFIED** and the change was actually included in the release.
+The final issue state is **CLOSED**.
+
+The field **Fixed in Version** of the issue is set to the OCCT version where it is fixed.
+
+@section occt_contribution_nonstd Additional workflow elements
+
+@subsection occt_contribution_nonstd_feedback Requesting more information or specific action
+
+If, at any step of the issue lifetime, the person responsible for it cannot process it due to absence of required information, expertise, or rights, he can switch it to status **FEEDBACK** and assign to the person who is (presumably) able to resolve the block. Some examples of typical situations where **FEEDBACK** is used are:
+
+* The **Maintainer** or the **Developer** requests for more information from the **Reporter** to reproduce the issue;
+* The **Tester** requests the **Developer** or the **Maintainer** to help him in the interpretation of testing results;
+* The **Developer** or the **Maintainer** asks the **Bugmaster** to close the issue that is found irrelevant or already fixed (see @ref occt_contribution_nonstd_autofix).
+
+In general, issues with status **FEEDBACK** should be processed as fast as possible, to avoid unjustified delays.
+
+@subsection occt_contribution_nonstd_relate Defining relationships between issues
+
+When two or more issues are related to each other, this relationship should be reflected in the issue tracker.
+It is also highly recommended to add a note to explain the relationship.
+Typical cases of relationships are:
+
+* Issue A is caused by previous fix made for issue B (A is a child of B);
+* Issue A describes the same problem as issue B (A is a duplicate of B);
+* Issues A and B relate to the same piece of code, functionality etc., in the sense that the fix for one of these issues will affect the other (A is related to B)
+
+When the fix made for one issue also resolves another one, these issues should be marked as related or duplicate.
+In general, the duplicate issue should have the same status, and, when closed, be marked as fixed in the same OCCT version, as the main one.
+
+@subsection occt_contribution_nonstd_patch Submission of a change as a patch
+
+In some cases (if Git is not accessible for the contributor), external contributions can be submitted as a patch file (generated by *diff* command) or as modified sources attached to the Mantis issue.
+The OCCT version, for which the patch is generated, should be clearly specified (e.g. as hash code of Git commit if the patch is based on an intermediate state of the master).
+
+@note Such contributions should be put to Git by someone else (e.g. the **Reviewer**), this may cause delay in their processing.
+
+@subsection occt_contribution_nonstd_rebase Updating branches in Git
+
+Updates of the existing branch (e.g. taking into account the remarks of the **Reviewer**, or fixing regressions) should be provided as new commits on top of previous state of the branch.
+
+It is allowed to rebase the branch on the new state of the master and push it to the repository under the same name (with <i>--force</i> option) provided that the original sequence of commits is preserved.
+
+When a change is squashed into a single commit (e.g. to be submitted for review), it should be pushed into a branch a with different name.
+
+The recommended approach is to add a numeric suffix (index) indicating the version of the change, e.g. "CR12345_5".
+Usually it is worth keeping a non-squashed branch in Git for reference.
+
+To avoid confusions, the branch corresponding to the latest version of the change should have a greater index.
+
+@note Make sure to revise the commit message after squashing a branch, to keep it meaningful and comprehensive.
+
+@subsection occt_contribution_nonstd_minor Minor corrections
+
+In some cases review remarks or results of testing require only minor corrections to be done in the branch containing a change.
+"Minor" implies that the correction does not impact the functionality and does not affect the description of the previously committed change.
+
+As an exception to general @ref occt_contribution_workflow_fix_git "single-commit rule", it is allowed to put such minor corrections on top of the existing branch as a separate commit, and re-submit it for further processing in the same branch, without squashing.
+
+Minor commits should have a single-line message starting with #.
+These messages will be ignored when the branch is squashed at integration.
+
+Typical cases of minor corrections are:
+
+* Amendments of test cases (including those made by the **Tester** to adjust a test script to a specific platform);
+* Trivial corrections of compilation warnings (such as removal of an unused variable);
+* Addition or correction of comments or documentation;
+* Corrections of code formatting (e.g. reversion of irrelevant formatting changes made in the main commit).
+
+@subsection occt_contribution_nonstd_autofix Handling non-reproducible issues
+
+Investigation of each issue starts with reproducing it on current development version (master).
+
+If it cannot be reproduced on the current master, but can be reproduced on one of previous releases (or previous state of the master), it is considered as solved by a change made for another issue.
+If that "fixing" issue can be identified (e.g. by parsing Git log), it should be set as related to that issue.
+The issue should be switched to **FEEDBACK** and assigned to the **Bugmaster** for further processing.
+
+The **Bugmaster** decides whether it is necessary to create a test case for that issue, and if so may assign it to the **Developer** or the **Tester** to create a test.
+The issue then follows the standard workflow.
+
+Otherwise, if the issue is fixed in one of previous releases, the **Bugmaster** closes it setting the appropriate value in **Fixed in Version** field, or, if the issue is fixed after the last release, switches it to **VERIFIED** status.
+
+If the issue cannot be reproduced due to an unclear description, missing data, etc., it should be assigned back to the **Reporter** in **FEEDBACK** status, requesting for more information.
+The **Reporter** should provide additional information within one month; after that time, if no new information is provided, the issue should be closed by the **Bugmaster** with resolution **Unable to reproduce**.
+
+@section occt_contribution_app Appendix: Issue attributes
+
+@subsection occt_contribution_app_category Category
+
+The category corresponds to the component of OCCT where the issue is found:
+
+ | Category | Component |
+ | :--------------------------- | :----------------------------------------------------- |
+ | OCCT:Foundation Classes | Foundation Classes module |
+ | OCCT:Modeling Data | Modeling Data classes |
+ | OCCT:Modeling Algorithms | Modeling Algorithms, except shape healing and meshing |
+ | OCCT:Shape Healing | Shape Healing component (TKShapeHealing) |
+ | OCCT:Mesh | BRepMesh algorithm |
+ | OCCT:Data Exchange | Data Exchange module |
+ | OCCT:Visualization | Visualization module |
+ | OCCT:Application Framework | OCAF |
+ | OCCT:DRAW | DRAW Test Harness |
+ | OCCT:Tests | Automatic Test System |
+ | OCCT:Documentation | Documentation |
+ | OCCT:Coding | General code quality |
+ | OCCT:Configuration | Configuration, build system, etc. |
+ | OCCT:Releases | Official OCCT releases |
+ | Website:Tracker | OCCT Mantis issue tracker, tracker.dev.opencascade.org |
+ | Website:Portal | OCCT development portal, dev.opencascade.org |
+ | Website:Git | OCCT Git repository, git.dev.opencascade.org |
+
+
+@subsection occt_contribution_app_severity Severity
+
+ Severity shows at which extent the issue affects the product.
+ The list of used severities is given in the table below in the descending order.
+
+ | Severity | Description |
+ | :---------- | :------------------------------------------------ |
+ | crash | Crash of the application or OS, loss of data |
+ | block | Regression corresponding to the previously delivered official version. Impossible operation of a function on any data with no work-around. Missing function previously requested in software requirements specification. Destroyed data. |
+ | major | Impossible operation of a function with existing work-around. Incorrect operation of a function on a particular dataset. Impossible operation of a function after intentional input of incorrect data. Incorrect behavior of a function after intentional input of incorrect data. |
+ | minor | Incorrect behavior of a function corresponding to the description in software requirements specification. Insufficient performance of a function. |
+ | tweak | Ergonomic inconvenience, need of light updates. |
+ | text | Non-conformance of the program code to the Coding Rules, mistakes and non-functional errors in the source text (e.g. unnecessary variable declarations, missing comments, grammatical errors in user manuals). |
+ | trivial | Cosmetic issues. |
+ | feature | Request for a new feature or improvement. |
+ | integration request | Requested integration of an existing feature into the product. |
+ | just a question | A question to be processed, without need of any changes in the product. |
+
+@subsection occt_contribution_app_status Status
+
+ The bug statuses that can be applied to the issues are listed in the table below.
+
+ | Status | Description |
+ | :------------------- | :----------------------------------------- |
+ | New | A new, just registered issue. |
+ | Acknowledged | Can be used to mark the issue as postponed. |
+ | Confirmed | Can be used to mark the issue as postponed. |
+ | Feedback | The issue requires more information or a specific action. |
+ | Assigned | Assigned to a developer. |
+ | Resolved | The issue has been fixed, and now is waiting for review. |
+ | Reviewed | The issue has been reviewed, and now is waiting for testing (or being tested). |
+ | Tested | The fix has been internally tested by the tester with success on the full non-regression database or its part and a test case has been created for this issue. |
+ | Verified | The fix has been integrated into the master of the corresponding repository |
+ | Closed + resolution | The fix has been integrated to the master. The corresponding test case has been executed successfully. The issue is no longer reproduced. |
+
+@subsection occt_contribution_app_resolution Resolution
+
+ **Resolution** is set when the bug is closed. "Reopen" resolution is added automatically when the bug is reopened.
+
+ | Resolution | Description |
+ |:--------------------- | :--------------------------------------------------------------------------- |
+ | Open | The issue is pending. |
+ | Fixed | The issue has been successfully fixed. |
+ | Reopened | The bug has been reopened because of insufficient fix or regression. |
+ | Unable to reproduce | The bug is not reproduced. |
+ | Not fixable | The bug cannot be fixed because e.g. it is a bug of third party software, OS or hardware limitation, etc. |
+ | 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. |
+ | No change required | The issue didn’t require any change of the product, such as a question issue.|
+ | Suspended | The issue is postponed (for Acknowledged status). |
+ | Documentation updated | The documentation has been updated to resolve a misunderstanding causing the issue. |
+ | Won’t fix | It is decided to keep the existing behavior. |
+
--- /dev/null
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+
+<svg
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:cc="http://creativecommons.org/ns#"
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:svg="http://www.w3.org/2000/svg"
+ xmlns="http://www.w3.org/2000/svg"
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+ width="447.27399"
+ height="737.74353"
+ id="svg2"
+ version="1.1"
+ inkscape:version="0.91 r13725"
+ sodipodi:docname="OCCT_ContributionWorkflow_V3_image001.svg">
+ <defs
+ id="defs4">
+ <clipPath
+ id="clipEmfPath1"
+ clipPathUnits="userSpaceOnUse">
+ <rect
+ id="rect2990"
+ height="777.18896"
+ width="607.5"
+ y="0"
+ x="0" />
+ </clipPath>
+ <clipPath
+ id="clipEmfPath2"
+ clipPathUnits="userSpaceOnUse">
+ <rect
+ id="rect2993"
+ height="30.298595"
+ width="44.849998"
+ y="180.89162"
+ x="255.075" />
+ </clipPath>
+ <clipPath
+ id="clipEmfPath3"
+ clipPathUnits="userSpaceOnUse">
+ <rect
+ id="rect2996"
+ height="32.323502"
+ width="60.674999"
+ y="55.572422"
+ x="131.625" />
+ </clipPath>
+ <clipPath
+ id="clipEmfPath4"
+ clipPathUnits="userSpaceOnUse">
+ <rect
+ id="rect2999"
+ height="39.223183"
+ width="106.8"
+ y="148.79311"
+ x="50.625" />
+ </clipPath>
+ <clipPath
+ id="clipEmfPath5"
+ clipPathUnits="userSpaceOnUse">
+ <rect
+ id="rect3002"
+ height="22.198971"
+ width="141.675"
+ y="294.66135"
+ x="61.875" />
+ </clipPath>
+ <clipPath
+ id="clipEmfPath6"
+ clipPathUnits="userSpaceOnUse">
+ <rect
+ id="rect3005"
+ height="22.198971"
+ width="141.675"
+ y="15.074301"
+ x="101.25" />
+ </clipPath>
+ <clipPath
+ id="clipEmfPath7"
+ clipPathUnits="userSpaceOnUse">
+ <rect
+ id="rect3008"
+ height="21.224016"
+ width="79.800003"
+ y="46.722836"
+ x="203.02499" />
+ </clipPath>
+ <clipPath
+ id="clipEmfPath8"
+ clipPathUnits="userSpaceOnUse">
+ <rect
+ id="rect3011"
+ height="17.099207"
+ width="90.074997"
+ y="298.33618"
+ x="202.05" />
+ </clipPath>
+ <clipPath
+ id="clipEmfPath9"
+ clipPathUnits="userSpaceOnUse">
+ <rect
+ id="rect3014"
+ height="40.423126"
+ width="74.550003"
+ y="165.51733"
+ x="124.35" />
+ </clipPath>
+ <clipPath
+ id="clipEmfPath10"
+ clipPathUnits="userSpaceOnUse">
+ <rect
+ id="rect3017"
+ height="21.224016"
+ width="79.800003"
+ y="76.346458"
+ x="51.150002" />
+ </clipPath>
+ <clipPath
+ id="clipEmfPath11"
+ clipPathUnits="userSpaceOnUse">
+ <rect
+ id="rect3020"
+ height="30.298595"
+ width="75.224998"
+ y="585.49786"
+ x="257.85001" />
+ </clipPath>
+ <clipPath
+ id="clipEmfPath12"
+ clipPathUnits="userSpaceOnUse">
+ <rect
+ id="rect3023"
+ height="22.198971"
+ width="133.05"
+ y="664.01923"
+ x="32.775002" />
+ </clipPath>
+ <clipPath
+ id="clipEmfPath13"
+ clipPathUnits="userSpaceOnUse">
+ <rect
+ id="rect3026"
+ height="22.723946"
+ width="166.875"
+ y="490.17728"
+ x="252.14999" />
+ </clipPath>
+ <clipPath
+ id="clipEmfPath14"
+ clipPathUnits="userSpaceOnUse">
+ <rect
+ id="rect3029"
+ height="22.198971"
+ width="114.3"
+ y="441.42953"
+ x="60" />
+ </clipPath>
+ <clipPath
+ id="clipEmfPath15"
+ clipPathUnits="userSpaceOnUse">
+ <rect
+ id="rect3032"
+ height="22.198971"
+ width="174.60001"
+ y="558.27411"
+ x="300.45001" />
+ </clipPath>
+ <clipPath
+ id="clipEmfPath16"
+ clipPathUnits="userSpaceOnUse">
+ <rect
+ id="rect3035"
+ height="23.773897"
+ width="186.14999"
+ y="455.1539"
+ x="297.14999" />
+ </clipPath>
+ <clipPath
+ id="clipEmfPath17"
+ clipPathUnits="userSpaceOnUse">
+ <rect
+ id="rect3038"
+ height="10.34952"
+ width="110.325"
+ y="513.3512"
+ x="186.3" />
+ </clipPath>
+ <clipPath
+ id="clipEmfPath18"
+ clipPathUnits="userSpaceOnUse">
+ <rect
+ id="rect3041"
+ height="31.423544"
+ width="133.95"
+ y="607.4718"
+ x="175.8" />
+ </clipPath>
+ <clipPath
+ id="clipEmfPath19"
+ clipPathUnits="userSpaceOnUse">
+ <rect
+ id="rect3044"
+ height="10.649506"
+ width="58.200001"
+ y="465.42841"
+ x="212.925" />
+ </clipPath>
+ <clipPath
+ id="clipEmfPath20"
+ clipPathUnits="userSpaceOnUse">
+ <rect
+ id="rect3047"
+ height="10.199527"
+ width="61.424999"
+ y="565.69879"
+ x="214.64999" />
+ </clipPath>
+ <clipPath
+ id="clipEmfPath21"
+ clipPathUnits="userSpaceOnUse">
+ <rect
+ id="rect3050"
+ height="22.648951"
+ width="83.474998"
+ y="703.91736"
+ x="261.52499" />
+ </clipPath>
+ <clipPath
+ id="clipEmfPath22"
+ clipPathUnits="userSpaceOnUse">
+ <rect
+ id="rect3053"
+ height="52.722553"
+ width="79.800003"
+ y="217.33992"
+ x="203.02499" />
+ </clipPath>
+ <clipPath
+ id="clipEmfPath23"
+ clipPathUnits="userSpaceOnUse">
+ <rect
+ id="rect3056"
+ height="10.049534"
+ width="131.55"
+ y="346.10895"
+ x="266.77499" />
+ </clipPath>
+ <clipPath
+ id="clipEmfPath24"
+ clipPathUnits="userSpaceOnUse">
+ <rect
+ id="rect3059"
+ height="25.04884"
+ width="118.05"
+ y="334.93448"
+ x="73.125" />
+ </clipPath>
+ <clipPath
+ id="clipEmfPath25"
+ clipPathUnits="userSpaceOnUse">
+ <rect
+ id="rect3062"
+ height="10.649506"
+ width="69"
+ y="362.90817"
+ x="206.925" />
+ </clipPath>
+ <clipPath
+ id="clipEmfPath26"
+ clipPathUnits="userSpaceOnUse">
+ <rect
+ id="rect3065"
+ height="26.473772"
+ width="90.074997"
+ y="406.70615"
+ x="195.52499" />
+ </clipPath>
+ <clipPath
+ id="clipEmfPath27"
+ clipPathUnits="userSpaceOnUse">
+ <rect
+ id="rect3068"
+ height="31.348545"
+ width="133.95"
+ y="730.16614"
+ x="175.8" />
+ </clipPath>
+ <clipPath
+ id="clipEmfPath28"
+ clipPathUnits="userSpaceOnUse">
+ <rect
+ id="rect3071"
+ height="22.723946"
+ width="83.474998"
+ y="385.18213"
+ x="257.77499" />
+ </clipPath>
+ <clipPath
+ id="clipEmfPath29"
+ clipPathUnits="userSpaceOnUse">
+ <rect
+ id="rect3074"
+ height="22.198971"
+ width="174.60001"
+ y="678.26855"
+ x="301.35001" />
+ </clipPath>
+ <clipPath
+ id="clipEmfPath30"
+ clipPathUnits="userSpaceOnUse">
+ <rect
+ id="rect3077"
+ height="10.199527"
+ width="61.5"
+ y="685.69324"
+ x="211.8" />
+ </clipPath>
+ <clipPath
+ id="clipEmfPath31"
+ clipPathUnits="userSpaceOnUse">
+ <rect
+ id="rect3080"
+ height="22.198971"
+ width="114.3"
+ y="541.7749"
+ x="60.900002" />
+ </clipPath>
+ <clipPath
+ id="clipEmfPath32"
+ clipPathUnits="userSpaceOnUse">
+ <rect
+ id="rect3083"
+ height="30.898567"
+ width="84"
+ y="132.29387"
+ x="202.425" />
+ </clipPath>
+ <clipPath
+ id="clipEmfPath33"
+ clipPathUnits="userSpaceOnUse">
+ <rect
+ id="rect3086"
+ height="30.298595"
+ width="94.5"
+ y="127.49409"
+ x="320.70001" />
+ </clipPath>
+ </defs>
+ <sodipodi:namedview
+ id="base"
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1.0"
+ inkscape:pageopacity="0.0"
+ inkscape:pageshadow="2"
+ inkscape:zoom="1.4142136"
+ inkscape:cx="423.51378"
+ inkscape:cy="280.02058"
+ inkscape:document-units="px"
+ inkscape:current-layer="layer1"
+ showgrid="false"
+ fit-margin-top="0"
+ fit-margin-left="10"
+ fit-margin-right="10"
+ fit-margin-bottom="10"
+ inkscape:snap-bbox="false"
+ inkscape:snap-nodes="false"
+ inkscape:window-width="1920"
+ inkscape:window-height="1028"
+ inkscape:window-x="-8"
+ inkscape:window-y="-8"
+ inkscape:window-maximized="1"
+ showguides="true"
+ inkscape:guide-bbox="true" />
+ <metadata
+ id="metadata7">
+ <rdf:RDF>
+ <cc:Work
+ rdf:about="">
+ <dc:format>image/svg+xml</dc:format>
+ <dc:type
+ rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+ <dc:title></dc:title>
+ </cc:Work>
+ </rdf:RDF>
+ </metadata>
+ <g
+ inkscape:label="Layer 1"
+ inkscape:groupmode="layer"
+ id="layer1"
+ transform="translate(-13.241957,-37.469169)">
+ <text
+ xml:space="preserve"
+ x="605.35443"
+ y="783.80597"
+ style="font-style:normal;font-weight:normal;font-size:12.52499962px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3090" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
+ clip-path="url(#clipEmfPath1)"
+ d="m 255.09375,180.89161 0,30.37359 44.86875,0 0,-30.37359 -44.86875,0 z"
+ id="path3092"
+ transform="translate(-2.1455429,6.6919971)" />
+ <text
+ xml:space="preserve"
+ x="252.92946"
+ y="196.8082"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3094">YES, bug</text>
+ <text
+ xml:space="preserve"
+ x="295.15445"
+ y="196.8082"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3096" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
+ clip-path="url(#clipEmfPath2)"
+ d="m 131.5875,51.522611 0,40.498122 60.75,0 0,-40.498122 -60.75,0 z"
+ id="path3098"
+ transform="translate(-2.1455429,6.6919971)" />
+ <text
+ xml:space="preserve"
+ x="137.57947"
+ y="71.488991"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3100">Reporter </text>
+ <text
+ xml:space="preserve"
+ x="137.57947"
+ y="83.038452"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3102">provides </text>
+ <text
+ xml:space="preserve"
+ x="137.57947"
+ y="94.512924"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3104">more info</text>
+ <text
+ xml:space="preserve"
+ x="179.27946"
+ y="94.512924"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3106" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
+ clip-path="url(#clipEmfPath3)"
+ d="m 50.5875,144.70579 0,47.4353 106.875,0 0,-47.4353 -106.875,0 z"
+ id="path3108"
+ transform="translate(-2.1455429,6.6919971)" />
+ <text
+ xml:space="preserve"
+ x="56.579456"
+ y="164.70967"
+ style="font-style:normal;font-weight:bold;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3110">No</text>
+ <text
+ xml:space="preserve"
+ x="69.854454"
+ y="164.70967"
+ style="font-style:normal;font-weight:bold;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3112">t clear:</text>
+ <text
+ xml:space="preserve"
+ x="102.62946"
+ y="164.70967"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3114" />
+ <text
+ xml:space="preserve"
+ x="105.40446"
+ y="164.70967"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3116">more info</text>
+ <text
+ xml:space="preserve"
+ x="147.10446"
+ y="164.70967"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3118" />
+ <text
+ xml:space="preserve"
+ x="56.579456"
+ y="176.18414"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3120">requested</text>
+ <text
+ xml:space="preserve"
+ x="101.05445"
+ y="176.18414"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3122" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
+ clip-path="url(#clipEmfPath4)"
+ d="m 61.8375,290.57403 0,30.37359 141.75,0 0,-30.37359 -141.75,0 z"
+ id="path3124"
+ transform="translate(-2.1455429,6.6919971)" />
+ <text
+ xml:space="preserve"
+ x="107.72945"
+ y="310.57788"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3126">Developer resolves </text>
+ <text
+ xml:space="preserve"
+ x="196.07947"
+ y="310.57788"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3128" />
+ <text
+ xml:space="preserve"
+ x="153.25446"
+ y="322.05237"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3130">the issue</text>
+ <text
+ xml:space="preserve"
+ x="193.30446"
+ y="322.05237"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3132" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
+ clip-path="url(#clipEmfPath5)"
+ d="m 101.2125,11.024489 0,30.373592 141.75,0 0,-30.373592 -141.75,0 z"
+ id="path3134"
+ transform="translate(-2.1455429,6.6919971)" />
+ <text
+ xml:space="preserve"
+ x="107.20445"
+ y="50.915874"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3136">Reporter registers an issue</text>
+ <text
+ xml:space="preserve"
+ x="227.20447"
+ y="30.915874"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3138" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
+ clip-path="url(#clipEmfPath6)"
+ d="m 202.4625,42.148046 0,30.317344 80.87812,0 0,-30.317344 -80.87812,0 z"
+ id="path3140"
+ transform="translate(-2.1455429,6.6919971)" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:none;stroke:#000000;stroke-width:0.78957015px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ d="m 200.243,57.766078 0,21.465274 81.02604,0 0,-21.465274 z"
+ id="path3142" />
+ <text
+ xml:space="preserve"
+ x="229.52946"
+ y="70.839348"
+ style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3144">New</text>
+ <text
+ xml:space="preserve"
+ x="252.02946"
+ y="63.839348"
+ style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3146" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.075px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
+ clip-path="url(#clipEmfPath7)"
+ d="m 243.21562,72.577885 0.42188,34.564025 c 0.009,0.34686 -0.27188,0.62809 -0.61875,0.63747 -0.3375,0 -0.62813,-0.28124 -0.62813,-0.61872 l -0.42187,-34.564026 c -0.009,-0.346859 0.27187,-0.628096 0.61875,-0.63747 0.3375,0 0.62812,0.281237 0.62812,0.618721 z m 3.53438,33.279705 -3.65625,7.53715 -3.84375,-7.45278 z"
+ id="path3148"
+ transform="translate(-2.1455429,6.6919971)" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
+ d="m 199.37946,300.45338 0,26.19254 91.125,0 0,-26.19254 -91.125,0 z"
+ id="path3150" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:none;stroke:#000000;stroke-width:0.9375px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ d="m 199.37946,300.45338 0,26.19254 91.125,0 0,-26.19254 z"
+ id="path3152" />
+ <text
+ xml:space="preserve"
+ x="219.92946"
+ y="315.75266"
+ style="font-style:normal;font-weight:bold;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3154">Resolved</text>
+ <text
+ xml:space="preserve"
+ x="269.95447"
+ y="315.75266"
+ style="font-style:normal;font-weight:bold;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3156" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.075px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
+ clip-path="url(#clipEmfPath8)"
+ d="m 243.59062,243.13873 0.0563,44.37919 c 0,0.34686 -0.28125,0.61872 -0.62812,0.61872 -0.3375,0.009 -0.61875,-0.27186 -0.61875,-0.61872 l -0.0563,-44.36982 c 0,-0.34686 0.28125,-0.62809 0.61875,-0.62809 0.34687,0 0.62812,0.28123 0.62812,0.61872 z m 3.17813,43.123 -3.74063,7.49965 -3.75937,-7.49028 z"
+ id="path3158"
+ transform="translate(-2.1455429,6.6919971)" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
+ d="m 122.19508,172.20933 0,40.49812 74.625,0 0,-40.49812 -74.625,0 z"
+ id="path3162" />
+ <text
+ xml:space="preserve"
+ x="150.17946"
+ y="181.4339"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3164">Ma</text>
+ <text
+ xml:space="preserve"
+ x="164.05446"
+ y="181.4339"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3166">intainer</text>
+ <text
+ xml:space="preserve"
+ x="196.82947"
+ y="181.4339"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3168" />
+ <text
+ xml:space="preserve"
+ x="165.70447"
+ y="192.90837"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3170">checks</text>
+ <text
+ xml:space="preserve"
+ x="196.82947"
+ y="192.90837"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3172" />
+ <text
+ xml:space="preserve"
+ x="131.80446"
+ y="204.45782"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3174">the </text>
+ <text
+ xml:space="preserve"
+ x="148.45447"
+ y="204.45782"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3176">description</text>
+ <text
+ xml:space="preserve"
+ x="196.82947"
+ y="204.45782"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3178" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
+ clip-path="url(#clipEmfPath9)"
+ d="m 50.5875,71.771672 0,30.312658 80.87812,0 0,-30.312658 -80.87812,0 z"
+ id="path3180"
+ transform="translate(-2.1455429,6.6919971)" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:none;stroke:#000000;stroke-width:0.9375px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ d="m 48.441957,78.463669 0,30.312661 80.878123,0 0,-30.312661 z"
+ id="path3182" />
+ <text
+ xml:space="preserve"
+ x="62.954456"
+ y="93.762955"
+ style="font-style:normal;font-weight:bold;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3184">Feedback</text>
+ <text
+ xml:space="preserve"
+ x="114.85445"
+ y="93.762955"
+ style="font-style:normal;font-weight:bold;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3186" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.075px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
+ clip-path="url(#clipEmfPath10)"
+ d="m 168.9,148.21188 -87.853125,-0.67497 c -0.3375,0 -0.61875,-0.28124 -0.61875,-0.6281 l -0.075,-38.51071 c 0,-0.34686 0.28125,-0.61872 0.628125,-0.6281 0.3375,0 0.61875,0.28124 0.61875,0.6281 l 0.08438,38.51071 -0.628125,-0.62809 87.853115,0.67497 c 0.34688,0.009 0.61876,0.29061 0.61876,0.63747 0,0.33748 -0.28125,0.61872 -0.62812,0.61872 z m -91.66875,-38.55759 3.73125,-7.50903 3.76875,7.49966 z"
+ id="path3188"
+ transform="translate(-2.1455429,6.6919971)" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.07166955px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
+ d="m 129.43631,98.095449 97.87721,-0.06896 c 0.3352,0 0.61453,0.24996 0.62383,0.568875 l 0.2514,19.884776 c 0,0.31891 -0.27002,0.5775 -0.61452,0.5775 -0.34451,0.008 -0.62384,-0.24996 -0.62384,-0.56888 l -0.2607,-19.876157 0.62383,0.560255 -97.86791,0.07757 c -0.3445,0 -0.62383,-0.25858 -0.62383,-0.577494 0,-0.318914 0.27933,-0.577494 0.61453,-0.577494 z m 101.8437,19.195221 -3.64061,6.93856 -3.80819,-6.85236 z"
+ id="path3190" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.0761172px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
+ d="m 241.44501,189.85283 0.0469,23.11907 c 0,0.34765 -0.27184,0.63736 -0.61867,0.63736 -0.34683,0.009 -0.62806,-0.28005 -0.62806,-0.63736 l -0.0469,-23.10942 c 0,-0.35731 0.28122,-0.64702 0.61868,-0.64702 0.34682,0 0.62804,0.28971 0.62804,0.63737 z m 3.16837,21.82502 -3.7308,7.72567 -3.7683,-7.71602 z"
+ id="path3192" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.0748096px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
+ d="m 189.86832,477.33276 -136.423363,0 c -0.335788,0 -0.615612,-0.28124 -0.615612,-0.63747 l 0,-221.61489 c 0,-0.33748 0.279824,-0.61872 0.615612,-0.61872 l 140.284923,0 c 0.35444,0 0.61561,0.28124 0.61561,0.61872 0,0.35624 -0.26117,0.63747 -0.61561,0.63747 l -140.284923,0 0.615612,-0.63747 0,221.61489 -0.615612,-0.61872 136.423363,0 c 0.35444,0 0.63426,0.28123 0.63426,0.61872 0,0.35623 -0.27982,0.63747 -0.63426,0.63747 z m 2.61168,-226.00218 7.46197,3.74982 -7.46197,3.74984 z"
+ id="path3194" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.07489965px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
+ d="M 191.842,697.88495 23.879416,696.72562 c -0.3375,0 -0.600001,-0.26179 -0.600001,-0.59837 l 0,-461.67788 c 0,-0.14959 0.075,-0.29919 0.187501,-0.41138 0.1125,-0.11219 0.2625,-0.18698 0.45,-0.18698 L 194.092,234.93555 c 0.3375,0 0.6375,0.29918 0.6,0.63576 0,0.33658 -0.2625,0.63577 -0.6,0.63577 l -170.212584,-1.12194 0.6375,-0.63577 0,461.67788 -0.6,-0.63576 167.925084,1.15933 c 0.375,0 0.6375,0.26179 0.6375,0.63576 0,0.33659 -0.3,0.59837 -0.6375,0.59837 z m 1.0125,-466.05344 7.4625,3.7772 -7.5,3.70239 z"
+ id="path3196" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
+ d="m 255.70446,592.18985 0,30.37359 75.2625,0 0,-30.37359 -75.2625,0 z"
+ id="path3198" />
+ <text
+ xml:space="preserve"
+ x="255.70447"
+ y="601.41443"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3200">YES, fixed</text>
+ <text
+ xml:space="preserve"
+ x="302.42947"
+ y="601.41443"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3202" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
+ clip-path="url(#clipEmfPath11)"
+ d="m 32.775,659.9319 0,30.37359 133.125,0 0,-30.37359 -133.125,0 z"
+ id="path3204"
+ transform="translate(-2.1455429,6.6919971)" />
+ <text
+ xml:space="preserve"
+ x="38.729458"
+ y="679.93579"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3206">Reporter</text>
+ <text
+ xml:space="preserve"
+ x="80.354454"
+ y="679.93579"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3208" />
+ <text
+ xml:space="preserve"
+ x="84.129456"
+ y="679.93579"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3210">is not satisfied </text>
+ <text
+ xml:space="preserve"
+ x="38.729458"
+ y="691.41028"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3212">with </text>
+ <text
+ xml:space="preserve"
+ x="59.204456"
+ y="691.41028"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3214" />
+ <text
+ xml:space="preserve"
+ x="61.979458"
+ y="691.41028"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3216">the </text>
+ <text
+ xml:space="preserve"
+ x="78.704453"
+ y="691.41028"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3218">fix</text>
+ <text
+ xml:space="preserve"
+ x="88.754456"
+ y="691.41028"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3220" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
+ clip-path="url(#clipEmfPath12)"
+ d="m 252.15,490.19602 0,22.7427 166.95,0 0,-22.7427 -166.95,0 z"
+ id="path3222"
+ transform="translate(-2.1455429,6.6919971)" />
+ <text
+ xml:space="preserve"
+ x="250.00446"
+ y="506.01883"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3224">YES, fixed</text>
+ <text
+ xml:space="preserve"
+ x="296.65445"
+ y="506.01883"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3226">, no regressions</text>
+ <text
+ xml:space="preserve"
+ x="367.82947"
+ y="506.01883"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3228" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
+ clip-path="url(#clipEmfPath13)"
+ d="m 59.9625,437.37972 0,30.37359 114.375,0 0,-30.37359 -114.375,0 z"
+ id="path3230"
+ transform="translate(-2.1455429,6.6919971)" />
+ <text
+ xml:space="preserve"
+ x="65.954453"
+ y="457.3461"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3232">Tester </text>
+ <text
+ xml:space="preserve"
+ x="98.204453"
+ y="457.3461"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3234">is not satisfied </text>
+ <text
+ xml:space="preserve"
+ x="65.954453"
+ y="468.89557"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3236">with </text>
+ <text
+ xml:space="preserve"
+ x="86.429451"
+ y="468.89557"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3238">the </text>
+ <text
+ xml:space="preserve"
+ x="103.15446"
+ y="468.89557"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3240">fix</text>
+ <text
+ xml:space="preserve"
+ x="113.20445"
+ y="468.89557"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3242" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
+ clip-path="url(#clipEmfPath14)"
+ d="m 300.4125,554.1868 0,30.3736 174.675,0 0,-30.3736 -174.675,0 z"
+ id="path3244"
+ transform="translate(-2.1455429,6.6919971)" />
+ <text
+ xml:space="preserve"
+ x="306.40445"
+ y="574.11572"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3246">Integrator merges the fix to trunk</text>
+ <text
+ xml:space="preserve"
+ x="450.92947"
+ y="574.11572"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3248" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
+ clip-path="url(#clipEmfPath15)"
+ d="m 297.15,455.13515 0,23.86764 186.1875,0 0,-23.86764 -186.1875,0 z"
+ id="path3250"
+ transform="translate(-2.1455429,6.6919971)" />
+ <text
+ xml:space="preserve"
+ x="295.00446"
+ y="471.07047"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3252">Tester verifies the solution</text>
+ <text
+ xml:space="preserve"
+ x="411.70447"
+ y="471.07047"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3254" />
+ <text
+ xml:space="preserve"
+ x="414.47946"
+ y="471.07047"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3256" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
+ clip-path="url(#clipEmfPath16)"
+ d="m 185.775,508.81391 0,19.44285 111.375,0 0,-19.44285 -111.375,0 z"
+ id="path3258"
+ transform="translate(-2.1455429,6.6919971)" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:none;stroke:#000000;stroke-width:0.9375px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ d="m 183.62946,515.50591 0,19.44285 111.375,0 0,-19.44285 z"
+ id="path3260" />
+ <text
+ xml:space="preserve"
+ x="221.20447"
+ y="530.39276"
+ style="font-style:normal;font-weight:bold;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3262">Tested</text>
+ <text
+ xml:space="preserve"
+ x="257.42947"
+ y="530.39276"
+ style="font-style:normal;font-weight:bold;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3264" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
+ clip-path="url(#clipEmfPath17)"
+ d="m 175.275,602.93454 0,40.49813 135,0 0,-40.49813 -135,0 z"
+ id="path3266"
+ transform="translate(-2.1455429,6.6919971)" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:none;stroke:#000000;stroke-width:0.9375px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ d="m 173.12946,609.62654 0,40.49813 135,0 0,-40.49813 z"
+ id="path3268" />
+ <text
+ xml:space="preserve"
+ x="184.37946"
+ y="624.58838"
+ style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3270">Integration to the trunk</text>
+ <text
+ xml:space="preserve"
+ x="296.95447"
+ y="624.58838"
+ style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3272" />
+ <text
+ xml:space="preserve"
+ x="220.00446"
+ y="637.86273"
+ style="font-style:normal;font-weight:bold;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3274">Verified</text>
+ <text
+ xml:space="preserve"
+ x="261.25446"
+ y="637.86273"
+ style="font-style:normal;font-weight:bold;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3276" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.075px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
+ clip-path="url(#clipEmfPath18)"
+ d="M 242.6625,524.82567 242.7,548.8808 c 0,0.33748 -0.2625,0.61872 -0.61875,0.61872 -0.3375,0.0188 -0.61875,-0.26249 -0.61875,-0.61872 l -0.0563,-24.05513 c 0,-0.35624 0.28125,-0.61873 0.61875,-0.63747 0.35625,0 0.6375,0.28123 0.6375,0.63747 z m 3.16875,22.79894 -3.73125,7.49965 -3.76875,-7.4809 z"
+ id="path3278"
+ transform="translate(-2.1455429,6.6919971)" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
+ d="m 239.87946,462.25838 -50.625,15.18679 50.625,15.1868 50.625,-15.1868 z"
+ id="path3280" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:none;stroke:#000000;stroke-width:0.9375px;stroke-linecap:round;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ d="m 239.87946,462.25838 -50.625,15.18679 50.625,15.1868 50.625,-15.1868 z"
+ id="path3282" />
+ <text
+ xml:space="preserve"
+ x="223.00446"
+ y="482.54492"
+ style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3284">Fixed?</text>
+ <text
+ xml:space="preserve"
+ x="256.75446"
+ y="482.54492"
+ style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3286" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.075px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
+ clip-path="url(#clipEmfPath19)"
+ d="m 242.6625,487.62739 0.0375,14.0056 c 0,0.33749 -0.28125,0.61872 -0.61875,0.61872 -0.35625,0.0188 -0.6375,-0.26249 -0.6375,-0.61872 l -0.0375,-13.98685 c 0,-0.35623 0.28125,-0.63747 0.61875,-0.63747 0.35625,0 0.6375,0.28124 0.6375,0.61872 z m 3.16875,12.74941 -3.73125,7.49965 -3.76875,-7.4809 z"
+ id="path3288"
+ transform="translate(-2.1455429,6.6919971)" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
+ d="m 243.16071,562.69747 -53.90625,14.75557 53.90625,14.73681 53.90625,-14.73681 z"
+ id="path3290" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:none;stroke:#000000;stroke-width:0.9375px;stroke-linecap:round;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ d="m 240.16071,563.69747 -53.90625,14.75557 53.90625,14.73681 53.90625,-14.73681 z"
+ id="path3292" />
+ <text
+ xml:space="preserve"
+ x="215.35446"
+ y="580.81531"
+ style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3294">Conflict ?</text>
+ <text
+ xml:space="preserve"
+ x="265.15445"
+ y="582.81531"
+ style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3298" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.075px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
+ clip-path="url(#clipEmfPath20)"
+ d="m 242.6625,585.49785 0.0375,12.56192 c 0,0.35623 -0.28125,0.63747 -0.61875,0.63747 -0.35625,0 -0.6375,-0.28124 -0.6375,-0.61872 l -0.0375,-12.56192 c 0,-0.35623 0.28125,-0.63747 0.61875,-0.63747 0.35625,0 0.6375,0.28124 0.6375,0.61872 z m 3.15,11.30573 -3.7125,7.5184 -3.7875,-7.49965 z"
+ id="path3300"
+ transform="translate(-2.1455429,6.6919971)" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
+ d="m 259.37946,710.57186 0,22.76145 83.5125,0 0,-22.76145 -83.5125,0 z"
+ id="path3302" />
+ <text
+ xml:space="preserve"
+ x="259.37946"
+ y="719.83392"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3304">YES, fixed</text>
+ <text
+ xml:space="preserve"
+ x="306.10446"
+ y="719.83392"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3306" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
+ clip-path="url(#clipEmfPath21)"
+ d="m 202.4625,212.76513 0,61.87214 80.87812,0 0,-61.87214 -80.87812,0 z"
+ id="path3308"
+ transform="translate(-2.1455429,6.6919971)" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:none;stroke:#000000;stroke-width:0.9375px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ d="m 200.31696,219.45713 0,61.87214 80.87812,0 0,-61.87214 z"
+ id="path3310" />
+ <text
+ xml:space="preserve"
+ x="215.50446"
+ y="234.83142"
+ style="font-style:normal;font-weight:bold;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3312">Assigned</text>
+ <text
+ xml:space="preserve"
+ x="266.12946"
+ y="234.83142"
+ style="font-style:normal;font-weight:bold;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3314" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
+ clip-path="url(#clipEmfPath22)"
+ d="m 266.775,346.07145 0,10.12453 131.625,0 0,-10.12453 -131.625,0 z"
+ id="path3316"
+ transform="translate(-2.1455429,6.6919971)" />
+ <text
+ xml:space="preserve"
+ x="264.62946"
+ y="362.02551"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3318">Reviewer</text>
+ <text
+ xml:space="preserve"
+ x="306.25446"
+ y="362.02551"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3320" />
+ <text
+ xml:space="preserve"
+ x="309.02945"
+ y="362.02551"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3322">verifies the solution</text>
+ <text
+ xml:space="preserve"
+ x="394.67947"
+ y="362.02551"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3324" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.075px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
+ clip-path="url(#clipEmfPath23)"
+ d="M 241.03125,375.71383 240.9,390.63814 c 0,0.35623 -0.28125,0.63747 -0.6375,0.61872 -0.3375,0 -0.61875,-0.28124 -0.61875,-0.61872 l 0.13125,-14.94306 c 0.0187,-0.33748 0.3,-0.61872 0.6375,-0.61872 0.35625,0 0.61875,0.28124 0.61875,0.63747 z m 3,13.70561 -3.80625,7.46216 -3.69375,-7.5184 z"
+ id="path3326"
+ transform="translate(-2.1455429,6.6919971)" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.07680816px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
+ d="m 190.48632,375.76754 -122.978386,0 c -0.335598,0 -0.615264,-0.29663 -0.615264,-0.65258 l 0,-110.82166 c 0,-0.35597 0.279666,-0.65259 0.615264,-0.65259 l 125.849616,0 c 0.35425,0 0.61526,0.29662 0.61526,0.65259 0,0.37572 -0.26101,0.67236 -0.61526,0.67236 l -125.849616,0 0.615265,-0.67236 0,110.82166 -0.615265,-0.67237 122.978386,0 c 0.35424,0 0.63391,0.29662 0.63391,0.67237 0,0.35595 -0.27967,0.65258 -0.63391,0.65258 z m 1.62205,-115.42934 7.45776,3.9551 -7.45776,3.95508 z"
+ id="path3328" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
+ d="m 70.941957,337.57666 0,33.18596 118.125003,0 0,-33.18596 -118.125003,0 z"
+ id="path3330" />
+ <text
+ xml:space="preserve"
+ x="79.079453"
+ y="350.85101"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3332">Reviewer</text>
+ <text
+ xml:space="preserve"
+ x="120.70445"
+ y="350.85101"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3334" />
+ <text
+ xml:space="preserve"
+ x="123.47945"
+ y="350.85101"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3336">is not </text>
+ <text
+ xml:space="preserve"
+ x="79.079453"
+ y="362.40048"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3338">satisfied with </text>
+ <text
+ xml:space="preserve"
+ x="139.07947"
+ y="362.40048"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3340">the fix</text>
+ <text
+ xml:space="preserve"
+ x="165.77946"
+ y="362.40048"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3342" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.075px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
+ clip-path="url(#clipEmfPath24)"
+ d="m 241.21875,421.6117 1.0125,26.75501 c 0.0188,0.35623 -0.24375,0.63747 -0.6,0.65622 -0.3375,0 -0.6375,-0.26249 -0.6375,-0.59997 l -1.03125,-26.75501 c 0,-0.35623 0.2625,-0.63747 0.61875,-0.65622 0.3375,-0.0188 0.61875,0.26249 0.6375,0.59997 z m 4.0875,25.38632 -3.46875,7.6309 -4.03125,-7.34966 z"
+ id="path3344"
+ transform="translate(-2.1455429,6.6919971)" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
+ d="m 239.22321,359.70063 -61.40625,15.1868 61.40625,15.18679 61.40625,-15.18679 z"
+ id="path3346" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:none;stroke:#000000;stroke-width:0.9375px;stroke-linecap:round;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ d="m 239.22321,359.70063 -61.40625,15.1868 61.40625,15.18679 61.40625,-15.18679 z"
+ id="path3348" />
+ <text
+ xml:space="preserve"
+ x="222.40446"
+ y="380.02469"
+ style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3350">Good</text>
+ <text
+ xml:space="preserve"
+ x="249.85446"
+ y="380.02469"
+ style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3352">?</text>
+ <text
+ xml:space="preserve"
+ x="256.15445"
+ y="380.02469"
+ style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3354" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
+ clip-path="url(#clipEmfPath25)"
+ d="m 194.9625,402.13135 0,35.62335 91.125,0 0,-35.62335 -91.125,0 z"
+ id="path3356"
+ transform="translate(-2.1455429,6.6919971)" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:none;stroke:#000000;stroke-width:0.9375px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ d="m 192.81696,408.82335 0,35.62335 91.125,0 0,-35.62335 z"
+ id="path3358" />
+ <text
+ xml:space="preserve"
+ x="213.50446"
+ y="428.74765"
+ style="font-style:normal;font-weight:bold;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3360">Reviewed</text>
+ <text
+ xml:space="preserve"
+ x="241.20447"
+ y="430.74765"
+ style="font-style:normal;font-weight:bold;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3362" />
+ <text
+ xml:space="preserve"
+ x="264.40445"
+ y="423.74765"
+ style="font-style:normal;font-weight:bold;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3364" />
+ <text
+ xml:space="preserve"
+ x="230.02946"
+ y="759.72205"
+ style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3366">+ Resolution</text>
+ <text
+ xml:space="preserve"
+ x="269.87946"
+ y="436.72205"
+ style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3368" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
+ clip-path="url(#clipEmfPath26)"
+ d="m 175.275,725.55386 0,40.49812 135,0 0,-40.49812 -135,0 z"
+ id="path3370"
+ transform="translate(-2.1455429,6.6919971)" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:none;stroke:#000000;stroke-width:0.84135455px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+ d="m 173.08139,732.19779 0,32.59426 135.09614,0 0,-32.59426 z"
+ id="path3372" />
+ <text
+ xml:space="preserve"
+ x="184.67946"
+ y="747.28265"
+ style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3374">Delivery of the release</text>
+ <text
+ xml:space="preserve"
+ x="296.57947"
+ y="747.28265"
+ style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3376" />
+ <text
+ xml:space="preserve"
+ x="189.87946"
+ y="759.48206"
+ style="font-style:normal;font-weight:bold;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3378">Closed</text>
+ <text
+ xml:space="preserve"
+ x="259.37946"
+ y="760.48206"
+ style="font-style:normal;font-weight:bold;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3380" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.075px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
+ clip-path="url(#clipEmfPath27)"
+ d="m 243.59062,0.89995827 0.2625,34.18903973 c 0.009,0.337484 -0.27187,0.628096 -0.61874,0.628096 -0.34688,0 -0.62813,-0.281237 -0.62813,-0.618721 l -0.2625,-34.18904016 c 0,-0.34685892 0.27187,-0.62809588 0.61875,-0.62809588 0.34687,0 0.62812,0.27186239 0.62812,0.61872131 z M 246.975,33.814057 243.28125,41.341833 239.475,33.870305 Z"
+ id="path3382"
+ transform="translate(-2.1455429,6.6919971)" />
+ <text
+ xml:space="preserve"
+ x="255.62946"
+ y="401.02371"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3384">YES, code is good</text>
+ <text
+ xml:space="preserve"
+ x="337.90445"
+ y="401.02371"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3386" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
+ clip-path="url(#clipEmfPath28)"
+ d="m 301.35,674.18124 0,30.37359 174.675,0 0,-30.37359 -174.675,0 z"
+ id="path3388"
+ transform="translate(-2.1455429,6.6919971)" />
+ <text
+ xml:space="preserve"
+ x="307.30447"
+ y="694.11017"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3390">Reporter can re</text>
+ <text
+ xml:space="preserve"
+ x="376.75446"
+ y="694.11017"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3392">-</text>
+ <text
+ xml:space="preserve"
+ x="380.12946"
+ y="694.11017"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3394">check the fix</text>
+ <text
+ xml:space="preserve"
+ x="435.70447"
+ y="694.11017"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3396" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.075px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
+ clip-path="url(#clipEmfPath29)"
+ d="m 243.6,644.8201 0.0375,24.07389 c 0,0.33748 -0.2625,0.59997 -0.6,0.59997 -0.3375,0 -0.6375,-0.26249 -0.6375,-0.59997 l -0.0375,-24.07389 c 0,-0.33748 0.2625,-0.63747 0.6,-0.63747 0.375,0 0.6375,0.29999 0.6375,0.63747 z m 3.1875,22.79895 -3.75,7.49965 -3.75,-7.46216 z"
+ id="path3398"
+ transform="translate(-2.1455429,6.6919971)" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
+ d="m 240.36696,682.71066 -53.925,14.73681 53.925,14.73682 53.8875,-14.73682 z"
+ id="path3400" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:none;stroke:#000000;stroke-width:0.9375px;stroke-linecap:round;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ d="m 240.36696,682.71066 -53.925,14.73681 53.925,14.73682 53.8875,-14.73682 z"
+ id="path3402" />
+ <text
+ xml:space="preserve"
+ x="229.15446"
+ y="702.80975"
+ style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3404">OK</text>
+ <text
+ xml:space="preserve"
+ x="245.42946"
+ y="702.80975"
+ style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3406">?</text>
+ <text
+ xml:space="preserve"
+ x="251.65446"
+ y="702.80975"
+ style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3408" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.075px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
+ clip-path="url(#clipEmfPath30)"
+ d="m 243.6,705.49229 0.0375,12.56192 c 0,0.37498 -0.2625,0.63747 -0.6,0.63747 -0.375,0 -0.6375,-0.26249 -0.6375,-0.59998 l -0.0375,-12.56191 c 0,-0.37499 0.2625,-0.63747 0.6,-0.63747 0.375,0 0.6375,0.26248 0.6375,0.59997 z m 3.15,11.32447 -3.7125,7.49966 -3.7875,-7.49966 z"
+ id="path3410"
+ transform="translate(-2.1455429,6.6919971)" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.075px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
+ d="m 188.54196,579.51544 -151.968753,0 c -0.3375,0 -0.61875,-0.28124 -0.61875,-0.63747 l 0,-333.17205 c 0,-0.33749 0.28125,-0.61872 0.61875,-0.61872 l 156.937503,0 c 0.35625,0 0.61875,0.28123 0.61875,0.61872 0,0.35623 -0.2625,0.63747 -0.61875,0.63747 l -156.937503,0 0.61875,-0.63747 0,333.17205 -0.61875,-0.61872 151.968753,0 c 0.3375,0 0.61875,0.28124 0.61875,0.61872 0,0.35623 -0.28125,0.63747 -0.61875,0.63747 z m 3.7125,-337.55935 7.5,3.74983 -7.5,3.74982 z"
+ id="path3412" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
+ d="m 58.754457,544.37957 0,30.37359 114.375003,0 0,-30.37359 -114.375003,0 z"
+ id="path3414" />
+ <text
+ xml:space="preserve"
+ x="66.854454"
+ y="557.69147"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3416">Conflict with other </text>
+ <text
+ xml:space="preserve"
+ x="66.854454"
+ y="569.16595"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3418">change is detected</text>
+ <text
+ xml:space="preserve"
+ x="150.77946"
+ y="569.16595"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3420" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.075px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
+ clip-path="url(#clipEmfPath31)"
+ d="m 301.3875,146.89944 102.95625,0 c 0.35625,0 0.61875,0.28124 0.61875,0.61872 l 0,158.05517 c 0,0.35624 -0.2625,0.63747 -0.61875,0.63747 l -104.30625,0 c -0.35625,0 -0.6375,-0.28123 -0.6375,-0.63747 0,-0.33748 0.28125,-0.61872 0.6375,-0.61872 l 104.30625,0 -0.61875,0.61872 0,-158.05517 0.61875,0.63747 -102.95625,0 c -0.3375,0 -0.61875,-0.28124 -0.61875,-0.63747 0,-0.33748 0.28125,-0.61872 0.61875,-0.61872 z m -0.1125,162.42372 -7.5,-3.74983 7.5,-3.74982 z"
+ id="path3422"
+ transform="translate(-2.1455429,6.6919971)" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
+ d="m 242.22321,118.96179 -76.40625,35.43586 76.40625,35.43586 76.40625,-35.43586 z"
+ id="path3424" />
+ <text
+ xml:space="preserve"
+ x="258.85446"
+ y="149.41039"
+ style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3430" />
+ <text
+ xml:space="preserve"
+ x="276.02945"
+ y="162.30978"
+ style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3434" />
+ <text
+ xml:space="preserve"
+ x="318.55447"
+ y="143.41066"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3436">YES, fix provided</text>
+ <text
+ xml:space="preserve"
+ x="395.27945"
+ y="143.41066"
+ style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3438" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.08784765px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
+ d="m 241.21873,80.019597 0.0468,30.842723 c 0,0.4638 -0.27142,0.8503 -0.6177,0.8503 -0.34628,0.0124 -0.62706,-0.37361 -0.62706,-0.8503 l -0.0468,-30.829846 c 0,-0.476685 0.28077,-0.863176 0.6177,-0.863176 0.34628,0 0.62705,0.386491 0.62705,0.850299 z m 3.16336,29.116363 -3.7249,10.30667 -3.76234,-10.2938 z"
+ id="path3192-1" />
+ <g
+ transform="matrix(1,0,0,0.82597166,232.6452,389.49727)"
+ id="g4649">
+ <text
+ xml:space="preserve"
+ x="-1.4697021"
+ y="13.642687"
+ style="font-style:normal;font-weight:normal;font-size:17.93036652px;font-family:Calibri;text-align:start;text-anchor:start;fill:#000000"
+ id="text4651" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.09798014px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
+ d="M 6.6504022,0.48301422 6.4789369,16.185905 c -0.00612,0.364725 -0.3735493,0.655519 -0.8267074,0.655519 -0.4531582,-0.0049 -0.81446,-0.300651 -0.8083362,-0.665376 L 5.0153586,0.46822807 c 0.00612,-0.35979631 0.3735492,-0.6555193 0.8267074,-0.65059058 0.4470344,0.004929 0.8083362,0.30065171 0.8083362,0.66537673 z M 10.575732,14.904439 5.5848681,22.750955 0.77771738,14.830508 Z"
+ id="path4653" />
+ </g>
+ <g
+ transform="matrix(0.982276,0,0,1.0254389,234.01098,492.23124)"
+ id="g4666">
+ <text
+ xml:space="preserve"
+ x="-1.4697021"
+ y="13.642687"
+ style="font-style:normal;font-weight:normal;font-size:17.93036652px;font-family:Calibri;text-align:start;text-anchor:start;fill:#000000"
+ id="text4668" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.09798014px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
+ d="M 6.6504022,0.48301422 6.4789369,16.185905 c -0.00612,0.364725 -0.3735493,0.655519 -0.8267074,0.655519 -0.4531582,-0.0049 -0.81446,-0.300651 -0.8083362,-0.665376 L 5.0153586,0.46822807 c 0.00612,-0.35979631 0.3735492,-0.6555193 0.8267074,-0.65059058 0.4470344,0.004929 0.8083362,0.30065171 0.8083362,0.66537673 z M 10.575732,14.904439 5.5848681,22.750955 0.77771738,14.830508 Z"
+ id="path4670" />
+ </g>
+ <g
+ transform="matrix(1,0,0,0.78256812,233.6452,444.48204)"
+ id="g4683">
+ <text
+ xml:space="preserve"
+ x="-1.4697021"
+ y="13.642687"
+ style="font-style:normal;font-weight:normal;font-size:17.93036652px;font-family:Calibri;text-align:start;text-anchor:start;fill:#000000"
+ id="text4685" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.09798014px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
+ d="M 6.6504022,0.48301422 6.4789369,16.185905 c -0.00612,0.364725 -0.3735493,0.655519 -0.8267074,0.655519 -0.4531582,-0.0049 -0.81446,-0.300651 -0.8083362,-0.665376 L 5.0153586,0.46822807 c 0.00612,-0.35979631 0.3735492,-0.6555193 0.8267074,-0.65059058 0.4470344,0.004929 0.8083362,0.30065171 0.8083362,0.66537673 z M 10.575732,14.904439 5.5848681,22.750955 0.77771738,14.830508 Z"
+ id="path4687" />
+ </g>
+ <g
+ transform="matrix(1,0,0,1.2605595,234.6452,535.1005)"
+ id="g4683-9">
+ <text
+ xml:space="preserve"
+ x="-1.4697021"
+ y="13.642687"
+ style="font-style:normal;font-weight:normal;font-size:17.93036652px;font-family:Calibri;text-align:start;text-anchor:start;fill:#000000"
+ id="text4685-4" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.09798014px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
+ d="M 6.6504022,0.48301422 6.4789369,16.185905 c -0.00612,0.364725 -0.3735493,0.655519 -0.8267074,0.655519 -0.4531582,-0.0049 -0.81446,-0.300651 -0.8083362,-0.665376 L 5.0153586,0.46822807 c 0.00612,-0.35979631 0.3735492,-0.6555193 0.8267074,-0.65059058 0.4470344,0.004929 0.8083362,0.30065171 0.8083362,0.66537673 z M 10.575732,14.904439 5.5848681,22.750955 0.77771738,14.830508 Z"
+ id="path4687-8" />
+ </g>
+ <g
+ transform="matrix(1,0,0,0.69536234,233.6452,592.9386)"
+ id="g4683-8">
+ <text
+ xml:space="preserve"
+ x="-1.4697021"
+ y="13.642687"
+ style="font-style:normal;font-weight:normal;font-size:17.93036652px;font-family:Calibri;text-align:start;text-anchor:start;fill:#000000"
+ id="text4685-2" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.09798014px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
+ d="M 6.6504022,0.48301422 6.4789369,16.185905 c -0.00612,0.364725 -0.3735493,0.655519 -0.8267074,0.655519 -0.4531582,-0.0049 -0.81446,-0.300651 -0.8083362,-0.665376 L 5.0153586,0.46822807 c 0.00612,-0.35979631 0.3735492,-0.6555193 0.8267074,-0.65059058 0.4470344,0.004929 0.8083362,0.30065171 0.8083362,0.66537673 z M 10.575732,14.904439 5.5848681,22.750955 0.77771738,14.830508 Z"
+ id="path4687-4" />
+ </g>
+ <g
+ transform="matrix(1,0,0,1.4346023,234.6452,649.62184)"
+ id="g4683-9-5">
+ <text
+ xml:space="preserve"
+ x="-1.4697021"
+ y="13.642687"
+ style="font-style:normal;font-weight:normal;font-size:17.93036652px;font-family:Calibri;text-align:start;text-anchor:start;fill:#000000"
+ id="text4685-4-5" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.09798014px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
+ d="M 6.6504022,0.48301422 6.4789369,16.185905 c -0.00612,0.364725 -0.3735493,0.655519 -0.8267074,0.655519 -0.4531582,-0.0049 -0.81446,-0.300651 -0.8083362,-0.665376 L 5.0153586,0.46822807 c 0.00612,-0.35979631 0.3735492,-0.6555193 0.8267074,-0.65059058 0.4470344,0.004929 0.8083362,0.30065171 0.8083362,0.66537673 z M 10.575732,14.904439 5.5848681,22.750955 0.77771738,14.830508 Z"
+ id="path4687-8-1" />
+ </g>
+ <g
+ transform="translate(234.70643,711.44155)"
+ id="g4759">
+ <text
+ xml:space="preserve"
+ x="-1.4697021"
+ y="13.272961"
+ style="font-style:normal;font-weight:normal;font-size:17.93036652px;font-family:Calibri;text-align:start;text-anchor:start;fill:#000000"
+ id="text4761" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.09798014px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
+ d="M 6.3197192,0.48857527 6.374833,14.127968 c 0.00612,0.37661 -0.3613017,0.68197 -0.8144599,0.68197 -0.4470344,0 -0.8144599,-0.30027 -0.8144599,-0.67688 L 4.6907993,0.4936646 c 0,-0.37661011 0.3613018,-0.68196965 0.81446,-0.68196965 0.4470344,0 0.8144599,0.30027022 0.8144599,0.67688032 z M 10.453256,12.75894 5.5848681,20.917129 0.6552422,12.784386 Z"
+ id="path4763" />
+ </g>
+ <g
+ transform="matrix(1,0,0,0.82597166,234.6327,281.48545)"
+ id="g4649-7">
+ <text
+ xml:space="preserve"
+ x="-1.4697021"
+ y="13.642687"
+ style="font-style:normal;font-weight:normal;font-size:17.93036652px;font-family:Calibri;text-align:start;text-anchor:start;fill:#000000"
+ id="text4651-1" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.09798014px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
+ d="M 6.6504022,0.48301422 6.4789369,16.185905 c -0.00612,0.364725 -0.3735493,0.655519 -0.8267074,0.655519 -0.4531582,-0.0049 -0.81446,-0.300651 -0.8083362,-0.665376 L 5.0153586,0.46822807 c 0.00612,-0.35979631 0.3735492,-0.6555193 0.8267074,-0.65059058 0.4470344,0.004929 0.8083362,0.30065171 0.8083362,0.66537673 z M 10.575732,14.904439 5.5848681,22.750955 0.77771738,14.830508 Z"
+ id="path4653-1" />
+ </g>
+ <g
+ transform="matrix(1,0,0,1.4346023,233.6327,327.6175)"
+ id="g4683-9-5-5">
+ <text
+ xml:space="preserve"
+ x="-1.4697021"
+ y="13.642687"
+ style="font-style:normal;font-weight:normal;font-size:17.93036652px;font-family:Calibri;text-align:start;text-anchor:start;fill:#000000"
+ id="text4685-4-5-2" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.09798014px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
+ d="M 6.6504022,0.48301422 6.4789369,16.185905 c -0.00612,0.364725 -0.3735493,0.655519 -0.8267074,0.655519 -0.4531582,-0.0049 -0.81446,-0.300651 -0.8083362,-0.665376 L 5.0153586,0.46822807 c 0.00612,-0.35979631 0.3735492,-0.6555193 0.8267074,-0.65059058 0.4470344,0.004929 0.8083362,0.30065171 0.8083362,0.66537673 z M 10.575732,14.904439 5.5848681,22.750955 0.77771738,14.830508 Z"
+ id="path4687-8-1-7" />
+ </g>
+ <g
+ id="g3761"
+ transform="matrix(0.94795956,0,0,0.95863162,75.350761,108.12834)">
+ <text
+ id="text3763"
+ style="font-style:normal;font-weight:normal;font-size:14.00640297px;font-family:Calibri;text-align:start;text-anchor:start;fill:#000000"
+ y="11.933813"
+ x="-1.2246037"
+ xml:space="preserve" />
+ <path
+ id="path3765"
+ d="M 94.150965,48.809882 4.5013748,48.103275 c -0.3492034,0 -0.6314362,-0.29442 -0.6314362,-0.652631 L 3.7886172,7.1347711 c 0,-0.3631176 0.2870165,-0.6526303 0.6410035,-0.6575373 0.3492033,0 0.6362198,0.2944197 0.6362198,0.6575373 l 0.076538,40.3158729 -0.6314362,-0.65263 89.6495907,0.7017 c 0.353987,0.0049 0.636219,0.299327 0.631436,0.662445 0,0.35821 -0.287017,0.65263 -0.641004,0.647723 z M 0.60273456,8.4498459 4.4152698,0.58883943 8.2565068,8.4351249 Z"
+ style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.07653772px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
+ inkscape:connector-curvature="0" />
+ </g>
+ <g
+ transform="matrix(1,0,0,0.82597166,236.44519,37.66031)"
+ id="g4649-7-1">
+ <text
+ xml:space="preserve"
+ x="-1.4697021"
+ y="13.642687"
+ style="font-style:normal;font-weight:normal;font-size:17.93036652px;font-family:Calibri;text-align:start;text-anchor:start;fill:#000000"
+ id="text4651-1-7" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.09798014px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
+ d="M 6.6504022,0.48301422 6.4789369,16.185905 c -0.00612,0.364725 -0.3735493,0.655519 -0.8267074,0.655519 -0.4531582,-0.0049 -0.81446,-0.300651 -0.8083362,-0.665376 L 5.0153586,0.46822807 c 0.00612,-0.35979631 0.3735492,-0.6555193 0.8267074,-0.65059058 0.4470344,0.004929 0.8083362,0.30065171 0.8083362,0.66537673 z M 10.575732,14.904439 5.5848681,22.750955 0.77771738,14.830508 Z"
+ id="path4653-1-4" />
+ </g>
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.0791635px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
+ d="m 293.36368,153.30065 123.82335,0 c 0.30475,0 0.55873,0.34675 0.55873,0.78643 l 0,273.41376 c 0,0.41609 -0.25398,0.76334 -0.55873,0.76334 l -127.32827,0 c -0.32171,0 -0.55875,-0.34675 -0.55875,-0.76334 0,-0.43955 0.23704,-0.7865 0.55875,-0.7865 l 127.32827,0 -0.55875,0.7865 0,-273.41376 0.55875,0.76334 -123.82335,0 c -0.32173,0 -0.57572,-0.34675 -0.57572,-0.76334 0,-0.43953 0.25399,-0.78643 0.57572,-0.78643 z m -2.37047,278.82648 -6.77279,-4.62629 6.77279,-4.6263 z"
+ id="path3194-6" />
+ <path
+ inkscape:connector-curvature="0"
+ style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:0.9375px;stroke-linecap:round;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
+ d="m 240.22321,118.96179 -76.40625,35.43586 76.40625,35.43586 76.40625,-35.43586 z"
+ id="path3426" />
+ <text
+ xml:space="preserve"
+ x="225.70447"
+ y="149.41039"
+ style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3428">Clear?</text>
+ <text
+ xml:space="preserve"
+ x="208.52946"
+ y="162.30978"
+ style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
+ id="text3432">Fix provided?</text>
+ </g>
+</svg>
--- /dev/null
+ Documentation System {#occt_dev_guides__documentation}
+======================
+
+@tableofcontents
+
+@section OCCT_DM_SECTION_1 Introduction
+
+This document provides practical guidelines for generation and editing of OCCT user documentation.
+
+@section OCCT_DM_SECTION_2 Prerequisites
+
+You need to have the following software installed to generate the documentation.
+
+**Tcl/Tk**
+Version 8.5 or 8.6: https://www.tcl.tk/software/tcltk/download.html
+
+**Doxygen**
+Version 1.8.4 or above: http://www.doxygen.nl/download.html
+
+**Dot**
+Part of Graphviz software, used by Doxygen for generation of class diagrams in Reference Manual: https://www.graphviz.org/download/
+
+**MiKTeX** or other package providing **pdflatex** command (only needed for generation of PDF documents): https://miktex.org/download
+
+**Inkscape** (only needed for generation of PDF documents containing SVG images): http://www.inkscape.org/download
+
+When generating PDF documentation, **pdflatex** and **inkscape** executables should be accessible by PATH variable.
+You can use *custom.bat* file to add necessary paths to the *PATH* variable.
+
+Note that in the process of PDF generation MiKTeX may need some packages not installed by default.
+We recommend setting option "Install missing packages on-the-fly" to "Ask me first" (default) during MiKTeX installation:
+
+@figure{/contribution/documentation/images/documentation_miktex.png,"",320}
+
+On the first run of **pdflatex** it will open a dialog window prompting for installation of missing packages.
+Follow the instructions to proceed (define proxy settings if needed, select a mirror site to download from, etc.).
+
+**MathJax** is used for rendering math formulas in browser (HTML and CHM outputs): http://www.mathjax.org.
+
+By default MathJAX scripts and fonts work on-line and no installation of MathJAX is necessary if Internet is accessible.
+If you need to use OCCT documentation while off-line, you can install a local copy of MatJAX, see https://docs.mathjax.org/en/v2.7-latest/start.html#installing-your-own-copy-of-mathjax.
+See \ref OCCT_DM_SECTION_A_9 for more details on inserting mathematical expressions.
+
+@section OCCT_DM_SECTION_2_1 Documentation Generation
+
+Run command *gendoc* from command prompt (with OCCT directory as current one) to generate OCCT documentation.
+The synopsis is:
+
+ gendoc \[-h\] {-refman|-overview} \[-html|-pdf|-chm\] \[-m=<list of modules>|-ug=<list of docs>\] \[-v\] \[-s=<search_mode>\] \[-mathjax=<path>\]
+
+Here the options are:
+
+* Choice of documentation to be generated:
+ * <i>-overview</i>: To generate Overview and User Guides (cannot be used with -refman)
+ * <i>-refman</i>: To generate class Reference Manual (cannot be used with -overview)
+
+* Choice of output format:
+ * <i>-html</i>: To generate HTML files (default, cannot be used with -pdf or -chm)
+ * <i>-pdf</i>: To generate PDF files (cannot be used with -refman, -html, or -chm)
+ * <i>-chm</i>: To generate CHM files (cannot be used with -html or -pdf)
+
+* Additional options:
+ * <i>-m=\<modules_list\></i>: List of OCCT modules (separated with comma), for generation of Reference Manual
+ * <i>-ug=\<docs_list\></i>: List of MarkDown documents (separated with comma), to use for generation of Overview / User Guides
+ * <i>-mathjax=\<path\></i>: To use local or alternative copy of MathJax
+ * <i>-s=\<search_mode\></i>: Specifies the Search mode of HTML documents; can be: none | local | server | external
+ * <i>-h</i>: Prints this help message
+ * <i>-v</i>: Enables more verbose output
+
+**Note**
+
+* In case of PDF output the utility generates a separate PDF file for each document;
+* In case of HTML output the utility generates a common Table of contents containing references to all documents.
+* In case of CHM output single CHM file is generated
+
+**Examples**
+
+To generate the output for a specific document specify the path to the corresponding MarkDown file (paths relative to *dox* sub-folder can be given), for instance:
+
+~~~~
+ > gendoc -overview -ug=dev_guides/documentation/documentation.md
+~~~~
+
+To generate Reference Manual for the whole Open CASCADE Technology library, run:
+~~~~
+ > gendoc -refman
+~~~~
+
+To generate Reference Manual for Foundation Classes and Modeling Data modules only, with search option, run:
+~~~~
+ > gendoc -refman -m=FoundationClasses,ModelingData,ModelingAlgorithms -s=local
+~~~~
+
+@section OCCT_DM_SECTION_3 Documentation Conventions
+
+This section contains information about file format conventions, directories structure, etc.
+
+@subsection OCCT_DM_SECTION_3_1 File Format
+
+The format used for documentation is MarkDown with Doxygen extensions.
+The MarkDown files have a <i>*.md</i> extension and are based on rules described in \ref OCCT_DM_SECTION_A section.
+
+@subsection OCCT_DM_SECTION_3_2 Directory Structure
+
+@figure{/contribution/documentation/images/documentation_folders.png,"",160}
+
+Each document has its own folder if there are any images used in it. These images are stored in *images* subfolder.
+
+If you want to use the same image for several documents, you can place it in *dox/resources* folder.
+
+**Note**: To avoid incorrect image display, use a relative path to the image (starting from *dox* folder). For instance:
+
+
+@verbatim
+@figure{/contribution/documentation/images/documentation_test_image.svg,"",420}
+@endverbatim
+
+
+The documentation is generated in subfolder *doc* :
+* *html* -- a directory for generated HTML pages;
+* *pdf* -- a directory for generated PDF files.
+
+@section OCCT_DM_SECTION_4 Adding a New Document
+
+Place a new document in the folder taking into account its logical position in the documentation hierarchy. For instance, the document *svn.md* about the use of SVN to work with OCCT source code can be placed into <i>/dox/dev_guides/</i>.
+
+If there are images in the document, it should be placed in its own folder containing a subfolder for images. For instance:
+* <i> /dox/dev_guides/svn/ </i> -- for *svn.md* file;
+* <i> /dox/dev_guides/svn/images/ </i> -- for images.
+
+Add a relative path to *svn.md* in file <i>dox/FILES.txt</i>. For instance
+
+@verbatim
+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, 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.
+
+@section OCCT_DOC_SECTION_5 Additional Resources
+
+More information about OCCT can be found at http://www.opencascade.com and <br> http://dev.opencascade.org sites.
+
+
+The information on formula syntax can be found at: <br>
+http://en.wikipedia.org/wiki/Help:Displaying_a_formula
+
+More information on MarkDown and Doxygen syntax can be found at: <br>
+http://www.stack.nl/~dimitri/doxygen/manual
+
+@section OCCT_DM_SECTION_A Appendix 1: Document Syntax
+
+A document file in *.md format must start with a proper header defining a caption and a unique tag.
+
+@verbatim
+Documentation System {#dev_guides__documentation}
+=====================
+@endverbatim
+
+The document structure is formed by sections that must be defined consistently.
+
+The document can contain plain text, lists, tables, code snippets, images, math, etc.
+Any specific text elements can be introduced by Markdown language tags or by usual HTML tags.
+
+The table of contents, page numbers (in PDF), and figure numbers (in PDF) are generated automatically.
+
+@subsection OCCT_DM_SECTION_A_1 Headers and hierarchic document structure
+
+Headers of different levels can be specified with the following tags:
+* <i>\@section</i> -- for the first-level headers;
+* <i>\@subsection</i> -- for the second level headers;
+* <i>\@subsubsection</i> -- for the third level headers.
+
+For example:
+
+@verbatim
+ @section occt_ocaf_1 Basic Concepts
+ @subsection occt_ocaf_1_1 Applications and Documents
+ @subsubsection occt_ocaf_1_1_1 The document and the data framework
+@endverbatim
+
+**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.
+
+The numbers are only indicative of a section location in the body of the document. However, duplicate section names in a document inevitably cause errors during generation.
+
+If you insert a section in the middle of a big document, do not renumber the document to the end (which is inefficient and error prone), but choose an arbitrary number or letter, not yet used in the document section naming, and base the naming in this section on it.
+
+The section hierarchy is limited to three levels and further levels cannot be presented in the Table of Contents.
+
+However, the fourth and fifth level headers can be tagged with <i>####</i> and <i>#####</i> correspondingly.
+
+It is also possible to use tags <i>##</i> and <i>###</i> for second and third level headers if you do not wish to show them in the table of contents or make references to them.
+
+@subsection OCCT_DM_SECTION_A_2 Plain Text
+
+A plain text is organized in paragraphs, separated by empty lines in MarkDown source.
+The length of lines is not restricted; it is recommended to put each sentence on a separate line -- this is optimal for easier comparison of different versions of the same document.
+
+To insert special symbols, like \< , \> or \\, prepend them with \\ character: \\\<, \\\>, \\\\, etc.
+To emphasize a word or a group of words, wrap the text with one pair of asterisks (*) or underscores (_) to make it *italic* and two pairs of these symbols to make it **Bold**.
+
+**Note** that if your emphasized text starts or ends with a special symbol, the asterisks may not work. Use explicit HTML tags \<i\>\</i\> and \<b\>\</b\> instead.
+
+
+@subsection OCCT_DM_SECTION_A_3 Lists
+
+To create a bulleted list, start each line with a hyphen or an asterisk,
+followed by a space. List items can be nested. This code:
+
+@verbatim
+* Bullet 1
+* Bullet 2
+ - Bullet 2a
+ - Bullet 2b
+* Bullet 3
+@endverbatim
+
+produces this list:
+
+* Bullet 1
+* Bullet 2
+ * Bullet 2a
+ * Bullet 2b
+* Bullet 3
+
+To create a numbered list, start each line with number and a period,
+then a space. Numbered lists can also be nested. Thus this code
+
+@verbatim
+1. List item 1
+ 1. Sub-item 1
+ 2. Sub-item 2
+2. List item 2
+4. List item 3
+@endverbatim
+
+produces this list:
+
+1. List item 1
+ 1. Sub-item 1
+ 2. Sub-item 2
+2. List item 2
+3. List item 3
+
+**Note** that numbers of list items in the output are generated so they do not necessarily follow the numbering of source items.
+
+In some cases automatic generation adversely restarts the numbering, i.e. you get list items 1. 1. 1. instead of 1. 2. 3. in the output.
+The use of explicit HTML tags \<ol\>\</ol\> and \<li\>\</li\> can help in this case.
+
+Each list item can contain several paragraphs of text; these paragraphs must
+have the same indentation as text after bullet or number in the numbered list
+item (otherwise numbering will be broken).
+
+Code blocks can be inserted as paragraphs with additional indentation
+(4 spaces more). Note that fenced code blocks do not work within numbered lists
+and their use may cause numeration to be reset.
+
+
+Example of a complex nested list:
+
+1. List item 1
+
+ Additional paragraph
+
+ code fragment
+
+ One more paragraph
+
+ 1. Sub-item 1
+
+ code fragment for sub-item 1
+
+ 2. Sub-item 2
+
+ Paragraph for sub-item 2
+
+ Yet one more paragraph for list item 1
+
+2. List item 2
+
+
+@subsection OCCT_DM_SECTION_A_4 Tables
+
+A table consists of a header line, a separator line, and at least one row line.
+Table columns are separated by the pipe (|) character. The following example:
+
+@verbatim
+First Header | Second Header
+------------- | -------------
+Content Cell | Content Cell
+Content Cell | Content Cell
+@endverbatim
+
+ will produce the following table:
+
+First Header | Second Header
+------------ | -------------
+Content Cell | Content Cell
+Content Cell | Content Cell
+
+Column alignment can be controlled via one or two colons at the header separator line:
+
+@verbatim
+| Right | Center | Left |
+| ----: | :----: | :---- |
+| 10 | 10 | 10 |
+| 1000 | 1000 | 1000 |
+@endverbatim
+
+which will looks as follows:
+
+| Right | Center | Left |
+| ----: | :----: | :---- |
+| 10 | 10 | 10 |
+| 1000 | 1000 | 1000 |
+
+Note that each table row should be contained in one line of text; complex tables can be created using HTML tags.
+
+@subsection OCCT_DM_SECTION_A_5 Code Blocks
+
+Paragraphs indented with 4 or more spaces are considered as code fragments and rendered using Courier font.
+Example:
+
+ This line is indented by 4 spaces and rendered as a code block.
+
+A fenced code block does not require indentation, and is defined by a pair of "fence lines".
+Such line consists of 3 or more tilde (~) characters on a line.
+The end of the block should have the same number of tildes.
+Thus it is strongly advised to use only three or four tildes.
+
+By default the output is the same as for a normal code block.
+To highlight the code, the developer has to indicate the typical file extension,
+which corresponds to the programming language, after the opening fence.
+For highlighting according to the C++ language, for instance, write the following code (the curly braces and dot are optional):
+
+@verbatim
+~~~{.cpp}
+int func(int a,int b) { return a*b; }
+~~~
+@endverbatim
+
+which will produce:
+~~~{.cpp}
+int func(int a,int b) { return a*b; }
+~~~
+
+Smaller code blocks can be inserted by wrapping with tags <i>\@code</i> and <i>\@endcode</i>.
+
+Verbatim content (same as code but without syntax highlighting) can be inserted by wrapping with tags <i>\@verbatim</i> and <i>\@endverbatim</i>.
+
+@subsection OCCT_DM_SECTION_A_5a Quotes
+
+Text quoted from other sources can be indented using ">" tag. For example:
+
+@verbatim
+> [Regression in 6.9.0] *IGES - Export of a reversed face leads to wrong data*
+@endverbatim
+
+will produce
+
+> [Regression in 6.9.0] *IGES - Export of a reversed face leads to wrong data*
+
+Note that this tag should prefix each line of the quoted text.
+Empty lines in the quoted text, if any, should not have trailing spaces after the ">" (lines with trailing spaces will break the quote block).
+
+@subsection OCCT_DM_SECTION_A_6 References
+
+To insert a reference to a website, it is sufficient to write an URL.
+For example: http://en.wikipedia.org
+
+To insert a reference to a document or its subsection, use command <i>\@ref</i> followed by the document or section tag name.
+For instance, @code @ref OCCT_DM_SECTION_A @endcode will be rendered as @ref OCCT_DM_SECTION_A.
+
+Note that links between documents will not work in PDF output if each document is generated independently.
+Hence it is recommended to add a name of the referenced section after the tag name in the <i>\@ref</i> command (in quotes): this will guarantee that the reference is recognizable for the reader even if the cross-link is not instantiated.
+For instance: @code @ref occt_modat_1 "Geometry Utilities" @endcode will be rendered as @ref occt_modat_1 "Geometry Utilities".
+
+@subsection OCCT_DM_SECTION_A_7 Images
+
+For inserting images into the document use the command <i>\@figure</i>, as follows:
+
+@verbatim
+ @figure{/relative/path/to/image/image_file_name.png,"Image caption"}
+@endverbatim
+
+The first argument is a path to the image file, relative to the *dox* folder.
+The supported formats for images are PNG, JPG, and SVG.
+The file extension must be lowercase and correspond to the file format.
+The image file name should have no dots except for the one before extension (names with more than one dot confuse **pdflatex**).
+
+The second argument is optional, it defines the caption for the image to be inserted.
+The caption argument, if given, should be quoted, even if it is a single word.
+Captions are included below the image; in PDF output the images with caption are numbered automatically.
+
+Example:
+
+@verbatim
+ @figure{/contribution/documentation/images/documentation_test_image.svg,"Test SVG image"}
+@endverbatim
+
+is rendered as:
+
+@figure{/contribution/documentation/images/documentation_test_image.svg,"Test SVG image",320}
+
+We recommend using **Inkscape** for creation and edition of vector graphics.
+The graphics created in MS Word Draw and some other vector editors can be copy-pasted to Inkscape and saved as SVG images.
+
+Note that the image that will be included in documentation is the whole page of the Inkscape document; use option "Resize page to content" in menu **File -> Document properties** of Inkscape to fit page dimensions to the picture (adding margins as necessary).
+
+Note that the *figure* command is an alias to the standard Doxygen command *image* repeated twice: once for HTML and then for Latex output (used for PDF generation). Thus if HTML and PDF outputs should include different images or captions, command "image" can be used:
+
+@verbatim
+ @image html /relative/path/to/image/occ_logo_for_html.png
+ @image latex /relative/path/to/image/occ_logo_for_pdf.png
+@endverbatim
+
+@subsection OCCT_DM_SECTION_A_8 Table Of Contents
+
+Use \@tableofcontents tag to get the table of contents at the beginning of the document.
+
+Actually, it is not strictly necessary now because TreeView option for HTML is used.
+The TOC in the PDF document will be generated automatically.
+
+@subsection OCCT_DM_SECTION_A_9 Formulas
+
+Formulas within MarkDown documents can be defined using LaTeX syntax.
+
+Equations can be written by several ways:
+
+1.Unnumbered displayed formulas that are centered on a separate line.
+These formulas should be put between \@f\[ and \@f\] tags. An example:
+
+@verbatim
+@f[
+ |I_2|=\left| \int_{0}^T \psi(t)
+ \left\{
+ u(a,t)-
+ \int_{\gamma(t)}^a
+ \frac{d\theta}{k(\theta,t)}
+ \int_{a}^\theta c(\xi)u_t(\xi,t)\,d\xi
+ \right\} dt
+ \right|
+@f]
+@endverbatim
+
+gives the following result:
+
+ @f$
+ |I_2|=\left| \int_{0}^T \psi(t)
+ \left\{
+ u(a,t)-
+ \int_{\gamma(t)}^a
+ \frac{d\theta}{k(\theta,t)}
+ \int_{a}^\theta c(\xi)u_t(\xi,t)\,d\xi
+ \right\} dt
+ \right|
+ @f$
+
+2.Formulas can also be put between @verbatim \begin{align} @endverbatim and @verbatim \end{align} @endverbatim tags.
+
+ For example:
+
+@verbatim
+ \begin{align}
+ \dot{x} & = \sigma(y-x) \\
+ \dot{y} & = \rho x - y - xz \\
+ \dot{z} & = -\beta z + xy
+ \end{align}
+@endverbatim
+
+ gives the following result:
+@latexonly
+ \begin{align}
+ \dot{x} & = \sigma(y-x) \\
+ \dot{y} & = \rho x - y - xz \\
+ \dot{z} & = -\beta z + xy
+ \end{align}
+@endlatexonly
+
+@htmlonly
+ \begin{align}
+ \dot{x} & = \sigma(y-x) \\
+ \dot{y} & = \rho x - y - xz \\
+ \dot{z} & = -\beta z + xy
+ \end{align}
+@endhtmlonly
+
+3.Inline formulas can be specified using this syntax:
+
+@verbatim
+ @f$ \sqrt{3x-1}+(1+x)^2 @f$
+@endverbatim
+
+ that leads to the following result: @f$ \sqrt{3x-1}+(1+x)^2 @f$
+
--- /dev/null
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+
+<svg
+ xmlns:dc="http://purl.org/dc/elements/1.1/"
+ xmlns:cc="http://creativecommons.org/ns#"
+ xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+ xmlns:svg="http://www.w3.org/2000/svg"
+ xmlns="http://www.w3.org/2000/svg"
+ xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+ xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+ width="443.5307"
+ height="187.48862"
+ id="svg2"
+ version="1.1"
+ inkscape:version="0.48.4 r9939"
+ sodipodi:docname="test_image.svg">
+ <defs
+ id="defs4" />
+ <sodipodi:namedview
+ id="base"
+ pagecolor="#ffffff"
+ bordercolor="#666666"
+ borderopacity="1.0"
+ inkscape:pageopacity="0.0"
+ inkscape:pageshadow="2"
+ inkscape:zoom="0.35"
+ inkscape:cx="295.90235"
+ inkscape:cy="-323.77532"
+ inkscape:document-units="px"
+ inkscape:current-layer="layer1"
+ showgrid="false"
+ inkscape:window-width="1366"
+ inkscape:window-height="716"
+ inkscape:window-x="-8"
+ inkscape:window-y="-8"
+ inkscape:window-maximized="1"
+ inkscape:snap-page="false"
+ borderlayer="false"
+ fit-margin-top="5"
+ fit-margin-left="5"
+ fit-margin-right="5"
+ fit-margin-bottom="5" />
+ <metadata
+ id="metadata7">
+ <rdf:RDF>
+ <cc:Work
+ rdf:about="">
+ <dc:format>image/svg+xml</dc:format>
+ <dc:type
+ rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+ <dc:title />
+ </cc:Work>
+ </rdf:RDF>
+ </metadata>
+ <g
+ inkscape:label="Layer 1"
+ inkscape:groupmode="layer"
+ id="layer1"
+ transform="translate(-79.097656,-21.098232)">
+ <path
+ sodipodi:type="spiral"
+ style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+ id="path2985"
+ sodipodi:cx="142.85715"
+ sodipodi:cy="126.6479"
+ sodipodi:expansion="1"
+ sodipodi:revolution="3"
+ sodipodi:radius="73.178566"
+ sodipodi:argument="-18.174814"
+ sodipodi:t0="0"
+ d="m 142.85715,126.6479 c 2.86505,2.29205 -1.67612,4.99285 -3.80953,4.76191 -5.78142,-0.62584 -7.49143,-7.75205 -5.71428,-12.38096 3.17892,-8.28004 13.59119,-10.36558 20.95239,-6.66665 10.80286,5.42832 13.31404,19.50561 7.61903,29.52381 -7.59056,13.35269 -25.44626,16.29352 -38.09525,8.5714 -15.91746,-9.71749 -19.28891,-31.39926 -9.52378,-46.66667 11.82689,-18.490884 37.35922,-22.29349 55.23811,-10.476151 21.06966,13.926321 25.30383,43.323481 11.42852,63.809531 -16.01959,23.65196 -49.29063,28.31803 -72.38096,12.3809 C 82.334702,151.39625 77.236493,114.2452 95.238126,88.552628 115.43324,59.729444 156.46861,54.198885 184.76195,74.26698 c 31.41097,22.27939 37.37404,67.20227 15.23802,98.09525" />
+ <text
+ xml:space="preserve"
+ style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
+ x="225.71429"
+ y="55.219326"
+ id="text2987"
+ sodipodi:linespacing="125%"><tspan
+ sodipodi:role="line"
+ id="tspan2989"
+ x="225.71429"
+ y="55.219326">Test SVG image</tspan></text>
+ <path
+ style="fill:#d40000"
+ id="path2996"
+ d="m 225.93253,80.077991 c 3.24312,6.556366 8.29882,11.800272 13.5792,16.763957 4.5107,4.980932 7.56994,10.929012 10.6621,16.828992 2.61039,5.79272 3.86714,11.94331 7.08009,17.44901 3.75425,6.35398 6.70021,13.19689 8.79217,20.27197 4.84784,15.88966 11.74851,2.45314 -37.25143,18.61001 -0.78487,0.2588 0.15562,-1.64589 0.20424,-2.47091 0.0536,-0.90872 0.0682,-1.81932 0.10224,-2.72899 0.17911,-6.50471 -0.15488,-13.01656 0.28271,-19.50992 0.46019,-6.30504 2.24023,-12.34988 4.0286,-18.37582 2.36519,-5.44796 6.30711,-10.00347 9.73908,-14.79837 3.98599,-5.97976 8.02146,-11.96839 13.10341,-17.072556 4.37574,-4.432922 8.35123,-9.243914 12.37764,-13.99199 4.43478,-4.829914 10.15101,-8.139537 15.06208,-12.425011 14.95925,-12.429871 35.2123,-18.385688 51.95332,-26.62658 11.5059,-5.663868 -23.27039,10.786567 -34.90558,16.179851 17.6228,-9.547136 35.52389,-19.290175 55.17352,-23.555822 4.29932,-0.713125 2.15416,-0.406331 6.43505,-0.923403 0,0 -35.68459,22.595324 -35.68459,22.595324 l 0,0 c -4.12774,0.727408 -2.06126,0.312559 -6.19873,1.248113 -3.11612,0.864072 -6.22731,1.766121 -9.25625,2.908329 -0.8427,0.317783 -3.30812,1.424428 -2.49421,1.03881 40.69568,-19.281166 46.47137,-22.237336 32.54467,-15.189227 -79.1837,37.555094 -31.13152,14.703661 -6.06008,3.03043 4.62777,-2.154687 -15.27783,7.276298 -11.28272,6.532336 -1.75524,1.522667 -3.27126,3.31763 -5.09432,4.758404 -3.18452,2.516733 -7.13492,4.190007 -9.93487,7.239896 -4.62518,4.303389 -8.28044,9.606276 -12.50569,14.296007 -0.80437,0.69437 -4.493,3.820284 -5.21444,4.670532 -2.98505,3.518007 -5.33483,7.691189 -8.08882,11.393589 -2.92337,4.905278 -6.62131,9.277358 -10.15131,13.755678 -2.01215,5.68475 -3.56944,11.57461 -4.40544,17.54154 -0.83081,6.35553 -0.13439,12.77693 -0.29528,19.17264 -0.0102,1.50844 -0.0276,5.46288 -0.0732,5.48876 -34.08891,19.36365 -36.17581,33.13461 -40.63381,14.4297 -1.84609,-6.79718 -4.68694,-13.28977 -8.31428,-19.32972 -3.24304,-5.58446 -4.82126,-11.64528 -7.31615,-17.57296 -2.8174,-5.54315 -5.55105,-11.15816 -9.9264,-15.68612 -5.41001,-5.49645 -10.6705,-11.1173 -14.41843,-17.919019 0,0 38.38591,-18.02746 38.38591,-18.02746 z"
+ inkscape:connector-curvature="0"
+ transform="translate(84.097656,26.098232)" />
+ </g>
+</svg>
--- /dev/null
+Guide to installing and using Git for OCCT development {#occt_dev_guides__git_guide}
+=================================
+
+@tableofcontents
+
+@section occt_gitguide_1 Overview
+
+@subsection occt_gitguide_1_1 Purpose
+
+ The purpose of this document is to provide a practical introduction to Git
+ 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.
+
+ 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 https://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.
+
+ 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
+ of the OCCT development portal at https://dev.opencascade.org/index.php?q=home/resources.
+
+@subsection occt_gitguide_1_2 Git URL
+
+ URL of the official OCCT source code Git repository (accessed by SSH protocol) is:
+
+ gitolite@git.dev.opencascade.org:occt
+
+ or
+
+ ssh://gitolite@dev.opencascade.org/occt.git
+
+@subsection occt_gitguide_1_3 Content
+
+The official repository contains:
+
+ * The current certified version of OCCT: the "master" branch. This branch is updated by the Bugmaster only. Official OCCT releases are marked by tags.
+ * Topic branches created by contributors to submit changes for review / testing or for collaborative development. The topic branches should be named by the pattern "CR12345" where 12345 is the ID of the relevant issue registered in Mantis (without leading zeroes), and "CR" stands for "Change Request". The name can have an additional postfix used if more than one branch was created for the same issue.
+ * Occasionally topic branches with non-standard names can be created by the Bugmaster for special needs.
+
+@subsection occt_gitguide_1_4 Short rules of use
+
+ The name specified in the user.name field in Git configuration should correspond
+ to your login name on the OCCT development portal.
+ This is important to clearly identify the authorship of commits.
+ (The full real name can be used as well; in this case add the login username in parentheses.)
+
+ By default, contributors are allowed to push branches only with the names starting with CR
+ (followed by the relevant Mantis issue ID).
+ Possibility to work with other branches can be enabled by the Bugmaster on request.
+
+ The branch is created by the developer in his local repository when the development of a contribution starts.
+ The branch for new developments is to be created from the current master.
+ The branch for integration of patches or developments based on an obsolete version
+ is created from a relevant tag or commit. The branch should be pushed to the official repo
+ only when sharing with other people (for collaborative work or review / testing) is needed.
+
+ Rebasing the local branch to the current master is encouraged before the first submission
+ to the official repository. If rebasing was needed after the branch is pushed to the official repo,
+ the rebased branch should have a different name (use suffix).
+
+ Integration of contributions that have passed certification testing is made exclusively by the Bugmaster.
+ Normally this is made by rebasing the contribution branch on the current master
+ and squashing it into a single commit. This is made to have the master branch history plain and clean,
+ following the general rule “one issue -- one commit”.
+ The description of the commit integrated to the master branch is taken from the Mantis issue
+ (ID, 'Summary', followed by the information from 'Documentation' field if present).
+
+ In special cases when it is important to save the commits history in the branch
+ (e.g. in case of a long-term development integration) it can be integrated by merge (no fast-forward).
+
+ The authorship of the contribution is respected by preserving the Author field of the commit when integrating.
+ Branches are removed from the official repository when integrated to the master.
+ The Bugmaster can also remove branches which have no commits during one-month period.
+
+ The Bugmaster may ask the developer (normally the one who produced the contribution)
+ to rebase a branch on the current master, in the case if merge conflicts appear during integration.
+
+@subsection occt_gitguide_1_5 Version of Git
+
+ The repository is tested to work with Git 1.7.6 and above.
+ Avoid using versions below 1.7.1 as they are known to cause troubles.
+
+@section occt_gitguide_2 Installing Tools for Work with Git
+
+@subsection occt_gitguide_2_1 Windows platform
+
+ Installation of Git for Windows (provided by MSysGit project) is required.
+
+ In addition, it is recommended to install TortoiseGit to work with Git on Windows.
+ If you do not install TortoiseGit or any other GUI tool,
+ you can use GitGui and Gitk GUI tools delivered with Git and available on all platforms.
+
+@subsubsection occt_gitguide_2_1_1 Installation of Git for Windows
+
+ Download Git for Windows distributive from https://git-for-windows.github.io/
+ During the installation:
+
+ * Check-in "Windows Explorer integration" options:
+ * "Git Bash Here";
+ * "Git GUI Here".
+ * To avoid a mess in your PATH, we recommend selecting "Run Git from Windows Prompt" in the environment settings dialog:
+ * In "Configuring the line ending conversions" dialog, select "Checkout Windows-style, commit Unix style endings".
+
+ Note that by default Git user interface is localized to the system default language.
+ If you prefer to work with the English interface, remove or rename .msg localization file
+ in subdirectories *share/git-gui/lib/msgs* and *share/gitk/lib/msgs* of the Git installation directory.
+
+ Before the first commit to the OCCT repository, make sure that your User Name in the Git configuration file (file <i>.gitconfig</i> in the <i>$HOME</i> directory) is equal to your username on the OCCT development portal.
+
+@subsubsection occt_gitguide_2_1_2 Installation and configuration of TortoiseGit
+
+ Download TortoiseGit distributive from https://tortoisegit.org/download/.
+ Launch the installation.
+
+ * Select your SSH client. Choose option
+ * "OpenSSH, Git default SSH Client" if you prefer to use command-line tools for SSH keys generation, or
+ * "TortoisePLink, coming from Putty, integrates with Windows better" if you prefer to use GUI tool (PuttyGen, see 3.2).
+ * Complete the installation.
+
+ TortoiseGit integrates into Windows Explorer, thus it is possible to use context menu in Windows Explorer to access its functionality:
+
+@figure{OCCT_GitGuide_V2_image005.png,"",100}
+
+
+
+ Note that if you have installed MSysGit or have Git installed in non-default path,
+ on the first time you use TortoiseGit you may get the message demanding to define path to Git.
+ In such case, click on **Set MSysGit path** button and add the path to git.exe
+ and path to MigGW libraries in the Settings dialog.
+
+ * After the installation select Start -> Programs -> TortoiseGit Settings to configure TortoiseGit.
+
+ Select Git->Config to add your user name and Email address to the local <i>.gitconfig</i> file
+
+ @figure{OCCT_GitGuide_V2_image006.png,"",320}
+
+ Optionally, you can set up TortoiseGit to use visual diff utility for SVG images used in OCCT documentation.
+ For that, click on item "Diff Viewer" in the Settings dialog, then click button "Advanced..." in the right tab to add a new record with the following parameters:
+ - Extension: <code>.svg</code>
+ - External program: <code><path_to_OCCT>\\adm\\svgdiff.bat %%base %%mine %%bname %%yname</code>
+
+@figure{OCCT_GitGuide_V2_svgdiff.png,"",709}
+
+@subsection occt_gitguide_2_2 Linux platform
+
+ We assume that Linux users have Git already installed and available in the *PATH*.
+
+ Make sure to configure Git so that the user name is equal to your username
+ on the OCCT development portal, and set SafeCrLf option to true:
+
+~~~~~
+ > git config --global user.name "Your User Name"
+ > git config --global user.email your@mail.address
+ > git config --global your@mail.address
+~~~~~
+
+@section occt_gitguide_3 Getting access to the repository
+
+@subsection occt_gitguide_3_1 Prerequisites
+
+ Access to the repository is granted to the users who have signed the Contributor License Agreement.
+
+ The repository is accessed by SSH protocol, thus you need to register your public SSH key
+ on the development portal to get access to the repository.
+
+ SSH keys are used for secure authentication of the user when accessing the Git server.
+ Private key is the one stored on the user workstation (optionally encrypted).
+ Open (or public) key is stored in the user account page on the web site.
+ When Git client accesses the remote repository through SSH,
+ it uses this key pair to identify the user and acquire relevant access rights.
+
+ Normally when you have Git installed, you should have also SSH client available.
+ On Unix/Linux it is installed by default in the system.
+ On Windows it is typical to have several SSH clients installed;
+ in particular they are included with Cygwin, Git, TortoiseGit.
+
+ It is highly recommended to use the tools that come
+ with the chosen Git client for generation of SSH keys.
+ Using incompatible tools (e.g. *ssh-keygen.exe* from Cygwin for code generation,
+ and TortoiseGit GUI with a default Putty client for connection to server)
+ may lead to authentication problems.
+
+@subsection occt_gitguide_3_2 How to generate a key
+
+@subsubsection occt_gitguide_3_2_1 Generating key with Putty
+
+ Use this option if you have installed TortoiseGit (or other GUI Git client on Windows)
+ and have chosen “TortoisePLink” (or other Putty client) as SSH client during installation.
+
+ To generate the key with this client, run **Puttygen** (e.g. from Start menu -> TortoiseGit -> Puttygen),
+ then click **Generate** and move mouse cursor over the blank area until the key is generated.
+
+@figure{OCCT_GitGuide_V2_image007.png,"Putty key generator",320}
+
+ After the key is generated, you will see GUI controls to define the public key comment
+ and / or specify the password for the private key protection.
+ When done, save both the public and the private key to the files of your choice
+ (make sure to store your private key in a secure place!).
+
+ Copy the public key as shown by Puttygen to the clipboard to add it in your account.
+ Do not copy the Putty public key file content -- it is formatted in a way not suitable for the web site.
+
+@subsubsection occt_gitguide_3_2_2 Generating key with command-line tools
+
+ Use this option if you work on Linux or if you have chosen “OpenSSH” as SSH client
+ during installation of TortoiseGit (or other Windows tool).
+
+ Make sure that you have *ssh* and *ssh-keygen* commands in the path.
+ On Windows, you might need to start **Git Bash** command prompt window.
+
+ Use the following command to generate SSH keys:
+~~~~~
+ > ssh-keygen -t rsa -C "your@mail.address"
+~~~~~
+
+ The last argument is an optional comment, which can be included with the public key and used to distinguish between different keys (if you have many). The common practice is to put here your mail address or workstation name.
+
+ The command will ask you where to store the keys. It is recommended to accept the default path <i>$HOME/.ssh/id_rsa</i>. Just press **Enter** for that. You will be warned if a key is already present in the specified file; you can either overwrite it by the new one, or stop generation and use the old key.
+
+ If you want to be on the safe side, enter password to encrypt the private key. You will be asked to enter this password each time you use that key (e.g. access a remote Git repository), unless you use the tool that caches the key (like TortoiseGit). If you do not want to bother, enter an empty string.
+
+ On Windows, make sure to note the complete path to the generated files (the location of your $HOME might be not obvious). Two key files will be created in the specified location (by default in $HOME/.ssh/):
+
+ * *id_rsa* -- private key
+ * *id_rsa.pub* -- public key
+
+ The content of the public key file (one text line) is the key to be added to the user account on the site (see below).
+
+@subsubsection occt_gitguide_3_2_3 Generating key with Git GUI
+
+ GitGUI (standard GUI interface included with Git) provides the option
+ to either generate the SSH key (if not present yet) or show the existing one.
+ Click Help/Show SSH key and copy the public key content for adding to the user account page (see below).
+
+@subsection occt_gitguide_3_3 Adding public key in your account
+
+Log in on the portal https://dev.opencascade.org and click on **My account** link to the right. If you have a Contributor status, you will see **SSH keys** tab to the right.
+
+Click on that tab, then click **Add a public key**, and paste the text of the public key (see above sections on how to generate the key) into the text box.
+
+Click **Save** to input the key to the system.
+
+ Note that a user can have several SSH keys.
+ You can distinguish between these keys by the Title field ID; by default it is taken from SSH key comment.
+ It is typical to use your e-mail address or workstation name for this field; no restrictions are set by the portal.
+
+
+ **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.
+
+@section occt_gitguide_4 Work with repository: developer operations
+
+@subsection occt_gitguide_4_1 General workflow
+
+ To start working with OCCT source repository, you need to create its clone in your local system.
+ This cloned repository will manage your working copy of the sources
+ and provide you the means to exchange code between your clone and the origin.
+
+ In most cases it is sufficient to have one clone of the repository;
+ your working copy will be updated automatically by Git when you switch branches.
+
+ The typical development cycle for an issue is as follows:
+
+ * Create a new branch for your development, basing on the selected version of the sources
+ (usually the current master) and switch your working copy to it
+ * Develop and test your change.
+ * Do as many commits in your branch as you feel convenient;
+ the general recommendation is to commit every stable state (even incomplete), to record the history of your development.
+ * Push your branch to the repository when your development is complete or when you need to share it with other people (e.g. for review)
+ * Before the first push, rebase your local branch on the latest master;
+ consider collapsing the history in one commit unless you think the history of your commits is interesting for others.
+ Make sure to provide a good commit message.
+ * Do not amend the commits that have been already pushed in the remote repository,
+ If you need to rebase your branch, commit the rebased branch under a different name, and remove the old branch.
+
+ You can switch to another branch at any moment
+ (unless you have some uncommitted changes in the working copy)
+ and return back to the branch when necessary (e.g. to take into account review remarks).
+ Note that only the sources that are different between the switched branches will be modified,
+ thus required recompilation should be reasonably small in most cases.
+
+@subsection occt_gitguide_4_2 Cloning official repository
+
+ Clone the official OCCT repository in one of following ways:
+
+ * From command line by command:
+
+~~~~~
+ > git clone gitolite@git.dev.opencascade.org:occt <path>
+~~~~~
+
+ where <i>\<path\></i> is the path to the new folder which will be created for the repository.
+
+ * In TortoiseGit: create a new folder, open it and right-click in the Explorer window, then choose **Git Clone** in the context menu:
+
+@figure{OCCT_GitGuide_V2_image009.png,"",320}
+
+ If you have chosen Putty as SSH client during TortoiseGit installation, check the **Load Putty Key** option and specify the location of the private key file saved by PuttyGen (see 3.2.1). This shall be done for the first time only.
+
+ Note that on the first connection to the repository server you may be requested to enter a password for your private SSH key; further you can get a message that the authenticity of the host cannot be established and will be asked if you want to continue connecting or not. Choose **Yes** to continue. The host’s key will be stored in <i>$HOME/.ssh/known_hosts</i> file.
+
+@subsection occt_gitguide_4_3 Branch creation
+
+ You need to create a branch when you are going to start development of a new change,
+ apply a patch, etc. It is recommended to fetch updates from the remote repository
+ before this operation, to make sure you work with the up-to-date version.
+
+ Create a branch from the current master branch unless you need to base your development on a particular version or revision.
+
+In the console:
+
+~~~~~
+ > git checkout -b CR12345 origin/master
+~~~~~
+
+In TortoiseGit:
+ * Go to the local copy of the repository.
+ * Right-click in the Explorer window, then choose **Git Create Branch**.
+ * Select **Base On** Branch *remotes/origin/master*.
+
+@figure{OCCT_GitGuide_V2_image012.png,"",320}
+
+ Check option **Switch to new branch** if you are going to start working with the newly created branch immediately.
+
+@subsection occt_gitguide_4_4 Branch switching
+
+ If you need to switch to another branch, use Git command checkout for that.
+ In the console:
+
+~~~~~
+ > git checkout CR12345
+~~~~~
+
+ In TortoiseGit: right-click in the explorer window and select in the context menu **TortoiseGit** -> **Switch/Checkout**.
+
+@figure{OCCT_GitGuide_V2_image013.png,"",320}
+
+ Note that in order to work with the branch locally you need to set option
+ **Create new branch** when you checkout the branch from the remote repository for the first time.
+ Option **Track** stores association between the local branch and the original branch in a remote repository.
+
+@subsection occt_gitguide_4_5 Committing branch changes
+
+ Commit your changes locally as soon as a stable status of the work is reached.
+ Make sure to review carefully the committed changes beforehand to avoid unintentional commit of a wrong code.
+
+ * In the console:
+
+~~~~~
+ > git diff
+ …
+ > git commit -a -m "Write meaningful commit message here"
+~~~~~
+
+ Option -a tells the command to automatically include (stage) files
+ that have been modified or deleted, but it will omit the new files that might have been added by you.
+ To commit such new files, you must add (stage) them before commit command.
+
+ To find new unstaged files and them to commit, use commands:
+
+~~~~~
+ > git status -s
+ ?? file1.hxx
+ ?? file2.cxx
+ > git add file1.hxx file2.cxx
+~~~~~
+
+ * In TortoiseGit: right-click in the explorer window and select in the context menu <b>Git Commit -> CR…</b>:
+
+@figure{OCCT_GitGuide_V2_image014.png,"",320}
+
+ Unstaged files will be shown if you check the option ‘Show Unversioned Files’.
+ Double-click on each modified file to see the changes to be committed (as a difference vs. the base version).
+
+@subsection occt_gitguide_4_6 Pushing branch to the remote repository
+
+ When the code developed in your local branch is ready for review,
+ or you need to share it with others, push your local changes to the remote repository.
+
+ * In the console:
+
+~~~~~
+ > git push "origin" CR12345:CR12345
+~~~~~
+
+ * In TortoiseGit: right-click in the explorer window and select in the context menu, TortoiseGit -> **Push**
+
+@figure{OCCT_GitGuide_V2_image015.png,"",320}
+
+Note that Git forbids pushing a branch if the corresponding remote branch already exists and has some changes, which are not in the history of your local branch. This may happen in different situations:
+ * You have amended the last commit which is already in the remote repository. If you are sure that nobody else uses your branch, push again with **Force** option.
+ * You have rebased your branch, so that now it is completely different from the branch in the remote repository. In this case, push it under a different name (add a suffix):
+
+@figure{OCCT_GitGuide_V2_image016.png,"",320}
+
+ Then remove the original remote branch so that other people recognize that it has been replaced by the new one. For that, select TortoiseGit -> **Push** again, select an empty line for your local branch name,
+ and enter the name of the branch to be removed in **Remote** field:
+
+ * The other developer has committed some changes in the remote branch. In this case, **Pull** changes from the remote repository to have them merged with your version, and push your branch after it is successfully merged.
+
+@subsection occt_gitguide_4_7 Synchronizing with remote repository
+
+ Maintain your repository synchronized with the remote one and clean unnecessary stuff regularly.
+
+ Use Git command *fetch* with option *prune* to get the update of all branches from the remote repository and to clean your local repository from the remote branches that have been deleted.
+
+ * In the console:
+~~~~~
+ > git fetch --prune
+~~~~~
+
+ * In TortoiseGit: right-click in the explorer window and select in the context menu **TortoiseGit** -> **Fetch**. Check in **Prune** check-box.
+
+@figure{OCCT_GitGuide_V2_image018.png,"",320}
+
+ If the branch you are working with has been changed in the remote repository, use Git command *pull* to get the remote changes and merge them with your local branch.
+
+ This operation is required in particular to update your local master branch when the remote master changes.
+
+ * In console:
+~~~~~
+ > git pull
+~~~~~
+
+ * In TortoiseGit: right-click in the explorer window and select in the context menu **TortoiseGit** -> **Pull**.
+
+@figure{OCCT_GitGuide_V2_image019.png,"",320}
+
+Note that the local branches of your repository are the primary place, where your changes are stored until they get integrated to the official version of OCCT (master branch). The branches submitted to official repository are for collaborative work, review, and integration -- that repository should not be used for long-term storage of incomplete changes.
+
+Remove the local branches that you do not need any more. Note that you cannot delete the current branch. It means that you need to switch to another one (e.g. master) if the branch you are going to delete is the current one.
+
+ * In the console:
+~~~~~
+ > git branch -d CR12345
+~~~~~
+
+ * In TortoiseGit: right-click in the explorer window and select in the context menu **TortoiseGit** -> **Git Show Log**.
+
+@figure{OCCT_GitGuide_V2_image020.png,"",420}
+
+ Select **All branches** check-box to view all branches.
+ Right-click on the branch you want to delete and select **Delete** item in the context menu.
+
+Note that many functions described above can be accessed from the Log View, which is a very convenient tool to visualize and manage branches.
+
+@subsection occt_gitguide_4_8 Applying a fix made on older version of OCCT
+
+If you have a fix made on a previous version of OCCT, perform the following sequence of operations to prepare it for testing and integration to the current development version:
+ * Identify the version of OCCT on which the fix has been made. In most cases, this will be an OCCT release, e.g. OCCT 6.7.0.
+ * Find a tag or a commit corresponding to this version in the Git history log of the master branch.
+ * Create a branch basing on this tag or commit. In TortoiseGit history log: right-click on the base commit, then select **Create branch at this version**.
+
+@figure{OCCT_GitGuide_V2_image021.png,"",320}
+
+ * Check option **Switch to the new branch** to start working within the new branch immediately, or switch to it separately afterwards.
+ * Put your fix in the working copy, build and check that it works, then commit to the branch.
+ * Rebase the branch on the current master. In TortoiseGit: right-click on the working directory, choose **TortoiseGit** -> **Rebase**, select *remotes/origin/master* as UpStream revision, and click **Start**:
+
+@figure{OCCT_GitGuide_V2_image022.png,"",320}
+
+Note that you can get some conflicts during rebase. To resolve them, double-click on each conflicted file (highlighted by red in the file list) to open visual merge tool. Switch between conflicting fragments by red arrows, and for each one decide if the code of one or both conflicting versions is to be taken.
+
+@subsection occt_gitguide_4_9 Rebasing with history clean-up
+
+At some moments you might need to rebase your branch on the latest version of the master.
+
+We recommend rebasing before the first submission of the branch for review or when the master has diverged substantially from your branch.
+
+Rebasing is a good occasion to clean-up the history of commits in the branch. Consider collapsing (squashing, in terms of Git) the history of your branch into a single commit unless you deem that having separate commits is important for your future work with the branch or its code reviewing. Git also allows changing the order of commits, edit commit contents and messages, etc.
+
+To rebase your branch into a single commit, you need to do the following:
+ * Switch to your branch (e.g. “CR12345”)
+ * In TortoiseGit history log, select a branch to rebase on <i>(remotes/origin/master)</i> and in the context menu choose **Rebase “CR12345” onto this**.
+ * In the **Rebase** dialog, check **Squash All**. You can also change the order of commits and define for each commit whether it should be kept (**Pick**), edited, or just skipped.
+
+@figure{OCCT_GitGuide_V2_image023.png,"",320}
+
+ * Click **Start**.
+ * The process will stop if a conflict is detected. In that case, find files with status **Conflicted** in the list (marked by red), and double-click on them to resolve the conflict. When all conflicts are resolved, click **Continue**.
+
+@figure{OCCT_GitGuide_V2_image024.png,"",320}
+
+ * At the end of the process, edit the final commit message (it should start from the issue ID and a description from Mantis in the first line, followed by a summary of actual changes), and click **Commit**.
+
+@figure{OCCT_GitGuide_V2_image025.png,"",320}
+
+@section occt_gitguide_5 Work with repository: Reviewer operations
+
+@subsection occt_gitguide_5_1 Review branch changes using GitWeb
+
+ The changes made in the branch can be reviewed without direct access to Git, using GitWeb interface:
+
+ * Open GitWeb in your web browser: https://git.dev.opencascade.org/gitweb/?p=occt.git
+ * Locate the branch you want to review among **heads** (click ‘…’ at the bottom of the page to see the full list).
+ * Click **log** (or **shortlog**) to see the history of the branch.
+
+ **Note** that the branch can contain more than one commit, and you need to distinguish commits that belong to that branch (those to be reviewed) from the commits corresponding to the previous state of the master branch. Normally the first commit in the list that starts from the ID of the other issue indicates the branching point; commits above it are the ones to be reviewed.
+
+ * Click **commitdiff** on each log entry to review the changes (highlighted with color format).
+
+@subsection occt_gitguide_5_2 Review branch changes with TortoiseGit
+
+ Use of TortoiseGit is recommended for convenient code review:
+
+ * 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.
+ * To review all changes made in the branch at once, or to compare two arbitrary revisions, select the corresponding commits in the log (e.g. the last commit in the branch and the branching point), ight-click for the context menu, and choose **Compare revisions**.
+
+@figure{OCCT_GitGuide_V2_image026.png,"",320}
+
+
--- /dev/null
+ Automated Testing System {#occt_dev_guides__tests}
+======================================
+
+@tableofcontents
+
+@section testmanual_intro Introduction
+
+This document provides OCCT developers and contributors with an overview and practical guidelines for work with OCCT automatic testing system.
+
+Reading the Introduction should be sufficient for developers to use the test system to control non-regression of the modifications they implement in OCCT. Other sections provide a more in-depth description of the test system, required for modifying the tests and adding new test cases.
+
+@subsection testmanual_intro_basic Basic Information
+
+OCCT automatic testing system is organized around @ref occt_user_guides__test_harness "DRAW Test Harness", a console application based on Tcl (a scripting language) interpreter extended by OCCT-related commands.
+
+Standard OCCT tests are included with OCCT sources and are located in subdirectory *tests* of the OCCT root folder. Other test folders can be included in the test system, e.g. for testing applications based on OCCT.
+
+The tests are organized in three levels:
+
+ * Group: a group of related test grids, usually testing a particular OCCT functionality (e.g. blend);
+ * 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 @ref testmanual_5_1 "Test Groups" chapter for the current list of available test groups and grids.
+
+@note Many tests involve data files (typically CAD models) which are located separately and (except a few) are not included with OCCT code.
+These tests will be skipped if data files are not available.
+
+@subsection testmanual_1_2 Intended Use of Automatic Tests
+
+Each modification made in OCCT code must be checked for non-regression
+by running the whole set of tests. The developer who makes the modification
+is responsible for running and ensuring non-regression for the tests available to him.
+
+Note that many tests are based on data files that are confidential and thus available only at OPEN CASCADE.
+The official certification testing of each change before its integration to master branch of official OCCT Git repository (and finally to the official release) is performed by OPEN CASCADE to ensure non-regression on all existing test cases and supported platforms.
+
+Each new non-trivial modification (improvement, bug fix, new feature) in OCCT should be accompanied by a relevant test case suitable for verifying that modification. This test case is to be added by the developer who provides the modification.
+
+If a modification affects the result of an existing test case, either the modification should be corrected (if it causes regression) or the affected test cases should be updated to account for the modification.
+
+The modifications made in the OCCT code and related test scripts should be included in the same integration to the master branch.
+
+@subsection testmanual_1_3 Quick Start
+
+@subsubsection testmanual_1_3_1 Setup
+
+Before running tests, make sure to define environment variable *CSF_TestDataPath* pointing to the directory containing test data files.
+
+For this it is recommended to add a file *DrawAppliInit* in the directory which is current at the moment of starting DRAWEXE (normally it is OCCT root directory, <i>$CASROOT </i>). This file is evaluated automatically at the DRAW start.
+
+Example (Windows)
+
+~~~~~{.tcl}
+set env(CSF_TestDataPath) $env(CSF_TestDataPath)\;d:/occt/test-data
+~~~~~
+
+Note that variable *CSF_TestDataPath* is set to default value at DRAW start, pointing at the folder <i>$CASROOT/data</i>.
+In this example, subdirectory <i>d:/occt/test-data</i> is added to this path. Similar code could be used on Linux and Mac OS X except that on non-Windows platforms colon ":" should be used as path separator instead of semicolon ";".
+
+All tests are run from DRAW command prompt (run *draw.bat* or *draw.sh* to start it).
+
+@subsubsection testmanual_1_3_2 Running Tests
+
+To run all tests, type command *testgrid*
+
+Example:
+
+~~~~~
+Draw[]> testgrid
+~~~~~
+
+To run only a subset of test cases, give masks for group, grid, and test case names to be executed.
+Each argument is a list of file masks separated with commas or spaces; by default "*" is assumed.
+
+Example:
+
+~~~~~
+Draw[]> testgrid bugs caf,moddata*,xde
+~~~~~
+
+As the tests progress, the result of each test case is reported.
+At the end of the log a summary of test cases is output,
+including the list of detected regressions and improvements, if any.
+
+
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ Tests summary
+
+ CASE 3rdparty export A1: OK
+ ...
+ CASE pipe standard B1: BAD (known problem)
+ CASE pipe standard C1: OK
+ No regressions
+ Total cases: 208 BAD, 31 SKIPPED, 3 IMPROVEMENT, 1791 OK
+ Elapsed time: 1 Hours 14 Minutes 33.7384512019 Seconds
+ 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 @ref testmanual_details_results "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 <i> -outdir</i> followed by a path to the directory. This directory should be new or empty; use option <i>-overwrite</i> to allow writing results in the existing non-empty directory.
+
+Example:
+~~~~~
+Draw[]> testgrid -outdir d:/occt/last_results -overwrite
+~~~~~
+In the output directory, a cumulative HTML report <i>summary.html</i> provides links to reports on each test case. An additional report in JUnit-style XML format can be output for use in Jenkins or other continuous integration system.
+
+To re-run the test cases, which were detected as regressions on the previous run, option <i>-regress dirname</i> should be used.
+<i>dirname</i> is a path to the directory containing the results of the previous run. Only the test cases with *FAILED* and *IMPROVEMENT* statuses will be tested.
+
+Example:
+~~~~~
+Draw[]> testgrid -regress d:/occt/last_results
+~~~~~
+
+Type <i>help testgrid</i> in DRAW prompt to get help on options supported by *testgrid* command:
+
+~~~~~
+Draw[3]> help testgrid
+testgrid: Run all tests, or specified group, or one grid
+ Use: testgrid [groupmask [gridmask [casemask]]] [options...]
+ Allowed options are:
+ -parallel N: run N parallel processes (default is number of CPUs, 0 to disable)
+ -refresh N: save summary logs every N seconds (default 60, minimal 1, 0 to disable)
+ -outdir dirname: set log directory (should be empty or non-existing)
+ -overwrite: force writing logs in existing non-empty directory
+ -xml filename: write XML report for Jenkins (in JUnit-like format)
+ -beep: play sound signal at the end of the tests
+ -regress dirname: re-run only a set of tests that have been detected as regressions on the previous run.
+ Here "dirname" is a path to the directory containing the results of the previous run.
+ Groups, grids, and test cases to be executed can be specified by the list of file
+ masks separated by spaces or commas; default is all (*).
+~~~~~
+
+@subsubsection testmanual_1_3_3 Running a Single Test
+
+To run a single test, type command *test* followed by names of group, grid, and test case.
+
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ Draw[1]> test blend simple A1
+ CASE blend simple A1: OK
+ Draw[2]>
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Note that normally an intermediate output of the script is not shown. The detailed log of the test can be obtained after the test execution by running command <i>"dlog get"</i>.
+
+To see intermediate commands and their output during the test execution, add one more argument
+<i>"echo"</i> at the end of the command line. Note that with this option the log is not collected and summary is not produced.
+
+Type <i>help test</i> in DRAW prompt to get help on options supported by *test* command:
+
+~~~~~
+Draw[3]> help test
+test: Run specified test case
+ Use: test group grid casename [options...]
+ Allowed options are:
+ -echo: all commands and results are echoed immediately,
+ but log is not saved and summary is not produced
+ It is also possible to use "1" instead of "-echo"
+ If echo is OFF, log is stored in memory and only summary
+ is output (the log can be obtained with command "dlog get")
+ -outfile filename: set log file (should be non-existing),
+ it is possible to save log file in text file or
+ in html file(with snapshot), for that "filename"
+ should have ".html" extension
+ -overwrite: force writing log in existing file
+ -beep: play sound signal at the end of the test
+ -errors: show all lines from the log report that are recognized as errors
+ This key will be ignored if the "-echo" key is already set.
+~~~~~
+
+@subsubsection testmanual_intro_quick_create Creating a New Test
+
+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 <i>bug</i> 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* <i>($CASROOT/tests/bugs)</i>. 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.)
+ * Use DRAW commands to reproduce the tested situation.
+ * Make sure that in case of failure the test produces a message containing word "Error" or other recognized by the test system as error (add new error patterns in file parse.rules if necessary).
+ * If the test case reports error due to an existing problem and the fix is not available, add @ref testmanual_3_6 "TODO" statement for each error to mark it as a known problem. The TODO statements must be specific so as to match the actually generated messages but not all similar errors.
+ * To check expected output which should be obtained as the test result, add @ref testmanual_3_7 "REQUIRED" statement for each line of output to mark it as required.
+ * If the test case produces error messages (contained in parse.rules), which are expected in that test and should not be considered as its failure (e.g. test for *checkshape* command), add REQUIRED statement for each error to mark it as required output.
+4. To check whether the data files needed for the test are already present in the database, use DRAW command *testfile* (see below).
+ If the data file is already present, use it for a new test instead of adding a duplicate.
+ If the data file(s) are not yet present in the test database, put them to a folder and add it to the environment variable *CSF_TestDataPath* to be found by the test system.
+ The location of the data files, which need to be accessed by OCC team and put to the official database, should be provided in the comment to Mantis issue, clearly indicating how the names of the files used by the test script match the actual names of the files.
+ The simplest way is to attach the data files to the Mantis issue, with the same names as used by the test script.
+5. Check that the test case runs as expected (test for fix: OK with the fix, FAILED without the fix; test for existing problem: BAD), and integrate it to the Git branch created for the issue.
+
+Example:
+
+* Added files:
+
+~~~~~
+git status -short
+A tests/bugs/heal/data/bug210_a.brep
+A tests/bugs/heal/data/bug210_b.brep
+A tests/bugs/heal/bug210_1
+A tests/bugs/heal/bug210_2
+~~~~~
+
+* Test script
+
+~~~~~{.tcl}
+puts "OCC210 (case 1): Improve FixShape for touching wires"
+
+restore [locate_data_file bug210_a.brep] a
+
+fixshape result a 0.01 0.01
+checkshape result
+~~~~~
+
+DRAW command *testfile* should be used to check the data files used by the test for possible duplication of content or names.
+The command accepts the list of paths to files to be checked (as a single argument) and gives a conclusion on each of the files, for instance:
+
+~~~~~
+Draw[1]> testfile [glob /my/data/path/bug12345*]
+Collecting info on test data files repository...
+Checking new file(s)...
+
+* /my/data/path/bug12345.brep: duplicate
+ already present under name bug28773_1.brep
+ --> //server/occt_tests_data/public/brep/bug28773_1.brep
+
+* /my/data/path/cadso.brep: new file
+ Warning: DOS encoding detected, consider converting to
+ UNIX unless DOS line ends are needed for the test
+ Warning: shape contains triangulation (946 triangles),
+ consider removing them unless they are needed for the test!
+ BREP size=201 KiB, nbfaces=33, nbedges=94 -> private
+
+* /my/data/path/case_8_wire3.brep: already present
+ --> //server/occt_tests_data/public/brep/case_8_wire3.brep
+
+* /my/data/path/case_8_wire4.brep: error
+ name is already used by existing file
+ --> //server/occt_tests_data/public/brep/case_8_wire4.brep
+~~~~~
+
+@section testmanual_2 Organization of Test Scripts
+
+@subsection testmanual_2_1 General Layout
+
+Standard OCCT tests are located in subdirectory tests of the OCCT root folder ($CASROOT).
+
+Additional test folders can be added to the test system by defining environment variable *CSF_TestScriptsPath*. This should be list of paths separated by semicolons (*;*) on Windows
+or colons (*:*) on Linux or Mac. Upon DRAW launch, path to *tests* subfolder of OCCT is added at the end of this variable automatically.
+
+Each test folder is expected to contain:
+ * Optional file *parse.rules* defining patterns for interpretation of test results, common for all groups in this folder
+ * One or several test group directories.
+
+Each group directory contains:
+
+ * File *grids.list* that identifies this test group and defines list of test grids in it.
+ * Test grids (sub-directories), each containing set of scripts for test cases, and optional files *cases.list*, *parse.rules*, *begin* and *end*.
+ * Optional sub-directory data
+
+By convention, names of test groups, grids, and cases should contain no spaces and be lower-case.
+The names *begin, end, data, parse.rules, grids.list* and *cases.list* are reserved.
+
+General layout of test scripts is shown in Figure 1.
+
+@figure{/contribution/tests/images/tests_image001.png,"Layout of tests folder",400}
+
+
+@subsection testmanual_2_2 Test Groups
+
+@subsubsection testmanual_2_2_1 Group Names
+
+The names of directories of test groups containing systematic test grids correspond to the functionality tested by each group.
+
+Example:
+
+~~~~~
+ caf
+ mesh
+ offset
+~~~~~
+
+Test group *bugs* is used to collect the tests coming from bug reports. Group *demo* collects tests of the test system, DRAW, samples, etc.
+
+@subsubsection testmanual_2_2_2 File "grids.list"
+
+This test group contains file *grids.list*, which defines an ordered list of grids in this group in the following format:
+
+~~~~~~~~~~~~~~~~~
+001 gridname1
+002 gridname2
+...
+NNN gridnameN
+~~~~~~~~~~~~~~~~~
+
+Example:
+
+~~~~~~~~~~~~~~~~~
+ 001 basic
+ 002 advanced
+~~~~~~~~~~~~~~~~~
+
+@subsubsection testmanual_2_2_3 File "begin"
+
+This file is a Tcl script. It is executed before every test in the current group.
+Usually it loads necessary Draw commands, sets common parameters and defines
+additional Tcl functions used in test scripts.
+
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ pload TOPTEST ;# load topological command
+ set cpulimit 300 ;# set maximum time allowed for script execution
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@subsubsection testmanual_2_2_4 File "end"
+
+This file is a TCL script. It is executed after every test in the current group. Usually it checks the results of script work, makes a snap-shot of the viewer and writes *TEST COMPLETED* to the output.
+
+Note: *TEST COMPLETED* string should be present in the output to indicate that the test is finished without crash.
+
+See @ref testmanual_3 "Creation and modification of tests" chapter for more information.
+
+Example:
+~~~~~
+ if { [isdraw result] } {
+ checkshape result
+ } else {
+ puts "Error: The result shape can not be built"
+ }
+ puts "TEST COMPLETED"
+~~~~~
+
+@subsubsection testmanual_2_2_5 File "parse.rules"
+
+The test group may contain *parse.rules* file. This file defines patterns used for analysis of the test execution log and deciding the status of the test run.
+
+Each line in the file should specify a status (single word), followed by a regular expression delimited by slashes (*/*) that will be matched against lines in the test output log to check if it corresponds to this status.
+
+The regular expressions should follow <a href="https://www.tcl.tk/man/tcl/TclCmd/re_syntax.htm">Tcl syntax</a>, with a special exception that "\b" is considered as word limit (Perl-style), in addition to "\y" used in Tcl.
+
+The rest of the line can contain a comment message, which will be added to the test report when this status is detected.
+
+Example:
+
+~~~~~
+ FAILED /\b[Ee]xception\b/ exception
+ FAILED /\bError\b/ error
+ SKIPPED /Cannot open file for reading/ data file is missing
+ SKIPPED /Could not read file .*, abandon/ data file is missing
+~~~~~
+
+Lines starting with a *#* character and blank lines are ignored to allow comments and spacing.
+
+See @ref testmanual_details_results "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.
+
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ FAILED /\\bFaulty\\b/ bad shape
+ IGNORE /^Error [23]d = [\d.-]+/ debug output of blend command
+ IGNORE /^Tcl Exception: tolerance ang : [\d.-]+/ blend failure
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@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 @ref testmanual_2_3_5 "Directory data".
+
+@subsection testmanual_2_3 Test Grids
+
+@subsubsection testmanual_2_3_1 Grid Names
+
+The folder of a test group can have several sub-directories (Grid 1… Grid N) defining test grids.
+Each directory contains a set of related test cases. The name of a directory should correspond to its contents.
+
+Example:
+
+~~~~~
+caf
+ basic
+ bugs
+ presentation
+~~~~~
+
+Here *caf* is the name of the test group and *basic*, *bugs*, *presentation*, etc. are the names of grids.
+
+@subsubsection testmanual_2_3_2 File "begin"
+
+This file is a TCL script executed before every test in the current grid.
+
+Usually it sets variables specific for the current grid.
+
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ set command bopfuse ;# command tested in this grid
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@subsubsection testmanual_2_3_3 File "end"
+
+This file is a TCL script executed after every test in current grid.
+
+Usually it executes a specific sequence of commands common for all tests in the grid.
+
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ vdump $imagedir/${casename}.png ;# makes a snap-shot of AIS viewer
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@subsubsection testmanual_2_3_4 File "cases.list"
+
+The grid directory can contain an optional file cases.list
+defining an alternative location of the test cases.
+This file should contain a single line defining the relative path to the collection of test cases.
+
+Example:
+
+~~~~~
+../data/simple
+~~~~~
+
+This option is used for creation of several grids of tests with the same data files and operations but performed with differing parameters. The common scripts are usually located place in the common
+subdirectory of the test group, <i>data/simple</i> for example.
+
+If file *cases.list* exists, the grid directory should not contain any test cases.
+The specific parameters and pre- and post-processing commands
+for test execution in this grid should be defined in the files *begin* and *end*.
+
+
+@subsubsection testmanual_2_3_5 Directory "data"
+
+The test grid may contain subdirectory *data*, containing data files used in tests (BREP, IGES, STEP, etc.) of this grid.
+
+@subsection testmanual_2_4 Test Cases
+
+The test case is a TCL script, which performs some operations using DRAW commands
+and produces meaningful messages that can be used to check the validity of the result.
+
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ pcylinder c1 10 20 ;# create first cylinder
+ pcylinder c2 5 20 ;# create second cylinder
+ ttranslate c2 5 0 10 ;# translate second cylinder to x,y,z
+ bsection result c1 c2 ;# create a section of two cylinders
+ checksection result ;# will output error message if result is bad
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The test case can have any name (except for the reserved names *begin, end, data, cases.list* and *parse.rules*).
+For systematic grids it is usually a capital English letter followed by a number.
+
+Example:
+
+~~~~~
+ A1
+ A2
+ B1
+ B2
+~~~~~
+
+Such naming facilitates compact representation of tests execution results in tabular format within HTML reports.
+
+
+@section testmanual_3 Creation And Modification Of Tests
+
+This section describes how to add new tests and update existing ones.
+
+@subsection testmanual_3_1 Choosing Group, Grid, and Test Case Name
+
+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 @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.
+
+Example:
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ bug12345_coaxial
+ bug12345_orthogonal_1
+ bug12345_orthogonal_2
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If the new test corresponds to a functionality already covered by the existing systematic test grid (e.g. group *mesh* for *BRepMesh* issues), this test can be added (or moved later by OCC team) to that grid.
+
+@subsection testmanual_3_2 Adding Data Files Required for a Test
+
+It is advisable to make self-contained test scripts whenever possible, so as they could be used in the environments where data files are not available. For that simple geometric objects and shapes can be created using DRAW commands in the test script itself.
+
+If the test requires a data file, it should be put to the directory listed in environment variable *CSF_TestDataPath*.
+Alternatively, it can be put to subdirectory *data* of the test grid.
+It is recommended to prefix the data file with the corresponding issue id prefixed by *bug*, e.g. *bug12345_face1.brep*, to avoid possible conflicts with names of existing data files.
+
+Note that when the test is integrated to the master branch, OCC team will move the data file to the data files repository, to keep OCCT sources repository clean from data files.
+
+When you prepare a test script, try to minimize the size of involved data model. For instance, if the problem detected on a big shape can be reproduced on a single face extracted from that shape, use only that face in the test.
+
+
+@subsection testmanual_3_3 Adding new DRAW commands
+
+If the test cannot be implemented using available DRAW commands, consider the following possibilities:
+* If the existing DRAW command can be extended to enable possibility required for a test in a natural way (e.g. by adding an option to activate a specific mode of the algorithm), this way is recommended. This change should be appropriately documented in a relevant Mantis issue.
+* If the new command is needed to access OCCT functionality not exposed to DRAW previously, and this command can be potentially reused (for other tests), it should be added to the package where similar commands are implemented (use *getsource* DRAW command to get the package name). The name and arguments of the new command should be chosen to keep similarity with the existing commands. This change should be documented in a relevant Mantis issue.
+* Otherwise the new command implementing the actions needed for this particular test should be added in *QABugs* package. The command name should be formed by the Mantis issue ID prefixed by *bug*, e.g. *bug12345*.
+
+Note that a DRAW command is expected to return 0 in case of a normal completion, and 1 (Tcl exception) if it is incorrectly used (e.g. a wrong number of input arguments). Thus if the new command needs to report a test error, this should be done by outputting an appropriate error message rather than by returning a non-zero value.
+File names must be encoded in the script rather than in the DRAW command and passed to the DRAW command as an argument.
+
+@subsection testmanual_3_4 Script Implementation
+
+The test should run commands necessary to perform the tested operations, in general assuming a clean DRAW session. The required DRAW modules should be loaded by *pload* command, if it is not done by *begin* script. The messages produced by commands in a standard output should include identifiable messages on the discovered problems if any.
+
+Usually the script represents a set of commands that a person would run interactively to perform the operation and see its results, with additional comments to explain what happens.
+
+Example:
+~~~~~
+# Simple test of fusing box and sphere
+box b 10 10 10
+sphere s 5
+bfuse result b s
+checkshape result
+~~~~~
+
+Make sure that file *parse.rules* in the grid or group directory contains a regular expression to catch possible messages indicating the failure of the test.
+
+For instance, for catching errors reported by *checkshape* command relevant grids define a rule to recognize its report by the word *Faulty*:
+
+~~~~~
+FAILED /\bFaulty\b/ bad shape
+~~~~~
+
+For the messages generated in the script it is recommended to use the word 'Error' in the error message.
+
+Example:
+
+~~~~~
+set expected_length 11
+if { [expr $actual_length - $expected_length] > 0.001 } {
+ puts "Error: The length of the edge should be $expected_length"
+}
+~~~~~
+
+At the end, the test script should output *TEST COMPLETED* string to mark a successful completion of the script. This is often done by the *end* script in the grid.
+
+When the test script requires a data file, use Tcl procedure *locate_data_file* to get a path to it, instead of putting the path explicitly. This will allow easy move of the data file from OCCT sources repository to the data files repository without the need to update the test script.
+
+Example:
+
+~~~~~
+stepread [locate_data_file CAROSKI_COUPELLE.step] a *
+~~~~~
+
+When the test needs to produce some snapshots or other artefacts, use Tcl variable *imagedir* as the location where such files should be put.
+* Command *testgrid* sets this variable to the subdirectory of the results folder corresponding to the grid.
+* Command *test* by default creates a dedicated temporary directory in the system temporary folder (normally the one specified by environment variable *TempDir*, *TEMP*, or *TMP*) for each execution, and sets *imagedir* to that location.
+
+However if variable *imagedir* is defined on the top level of Tcl interpretor, command *test* will use it instead of creating a new directory.
+
+Use Tcl variable *casename* to prefix all files produced by the test.
+This variable is set to the name of the test case.
+
+The test system can recognize an image file (snapshot) and include it in HTML log and differences if its name starts with the name of the test case (use variable *casename*), optionally followed by underscore or dash and arbitrary suffix.
+
+The image format (defined by extension) should be *png*.
+
+Example:
+~~~~~
+xwd $imagedir/${casename}.png
+vdisplay result; vfit
+vdump $imagedir/${casename}-axo.png
+vfront; vfit
+vdump $imagedir/${casename}-front.png
+~~~~~
+
+would produce:
+~~~~~
+A1.png
+A1-axo.png
+A1-front.png
+~~~~~
+
+Note that OCCT must be built with FreeImage support to be able to produce usable images.
+
+Other Tcl variables defined during the test execution are:
+- *groupname*: name of the test group;
+- *gridname*: name of the test grid;
+- *dirname*: path to the root directory of the current set of test scripts.
+
+In order to ensure that the test works as expected in different environments, observe the following additional rules:
+* Avoid using external commands such as *grep, rm,* etc., as these commands can be absent on another system (e.g. on Windows); use facilities provided by Tcl instead.
+* Do not put call to *locate_data_file* in catch statement -- this can prevent correct interpretation of the missing data file by the test system.
+* Do not use commands *decho* and *dlog* in the test script, to avoid interference with use of these commands by the test system.
+
+@subsection testmanual_details_results Interpretation of test results
+
+The result of the test is evaluated by checking its output against patterns defined in the files *parse.rules* of the grid and group.
+
+The OCCT test system recognizes five statuses of the test execution:
+* SKIPPED: reported if a line matching SKIPPED pattern is found (prior to any FAILED pattern). This indicates that the test cannot be run in the current environment; the most typical case is the absence of the required data file.
+* FAILED: reported if a line matching pattern with status FAILED is found (unless it is masked by the preceding IGNORE pattern or a TODO or REQUIRED statement), or if message TEST COMPLETED or at least one of REQUIRED patterns is not found. This indicates that the test has produced a bad or unexpected result, and usually means a regression.
+* BAD: reported if the test script output contains one or several TODO statements and the corresponding number of matching lines in the log. This indicates a known problem. The lines matching TODO statements are not checked against other patterns and thus will not cause a FAILED status.
+* IMPROVEMENT: reported if the test script output contains a TODO statement for which no corresponding line is found. This is a possible indication of improvement (a known problem has disappeared).
+* OK: reported if none of the above statuses have been assigned. This means that the test has passed without problems.
+
+Other statuses can be specified in *parse.rules* files, these will be classified as FAILED.
+
+For integration of the change to OCCT repository, all tests should return either OK or BAD status.
+The new test created for an unsolved problem should return BAD. The new test created for a fixed problem should return FAILED without the fix, and OK with the fix.
+
+@subsection testmanual_3_6 Marking BAD cases
+
+If the test produces an invalid result at a certain moment then the corresponding bug should be created in the OCCT issue tracker located at https://tracker.dev.opencascade.org, and the problem should be marked as TODO in the test script.
+
+The following statement should be added to such a test script:
+~~~~~
+puts "TODO BugNumber ListOfPlatforms: RegularExpression"
+~~~~~
+
+Here:
+* *BugNumber* is the bug ID in the tracker. For example: #12345.
+* *ListOfPlatforms* is a list of platforms, at which the bug is reproduced (Linux, Windows, MacOS, or All). Note that the platform name is custom for the OCCT test system; Use procedure *checkplatform* to get the platform name.
+
+Example:
+~~~~~
+Draw[2]> checkplatform
+Windows
+~~~~~
+
+* RegularExpression is a regular expression, which should be matched against the line indicating the problem in the script output.
+
+Example:
+~~~~~
+puts "TODO #22622 Mandriva2008: Abort .* an exception was raised"
+~~~~~
+
+The parser checks the test output and if an output line matches the *RegularExpression* then it will be assigned a BAD status instead of FAILED.
+
+A separate TODO line must be added for each output line matching an error expression to mark the test as BAD. If not all TODO messages are found in the test log, the test will be considered as possible improvement.
+
+To mark the test as BAD for an incomplete case (when the final *TEST COMPLETE* message is missing) the expression *TEST INCOMPLETE* should be used instead of the regular expression.
+
+Example:
+
+~~~~~
+puts "TODO OCC22817 All: exception.+There are no suitable edges"
+puts "TODO OCC22817 All: \\*\\* Exception \\*\\*"
+puts "TODO OCC22817 All: TEST INCOMPLETE"
+~~~~~
+
+@subsection testmanual_3_7 Marking required output
+
+To check the obtained test output matches the expected results considered correct, add REQUIRED statement for each specific message.
+For that, the following statement should be added to the corresponding test script:
+
+~~~~~
+puts "REQUIRED ListOfPlatforms: RegularExpression"
+~~~~~
+
+Here *ListOfPlatforms* and *RegularExpression* have the same meaning as in TODO statements described above.
+
+The REQUIRED statement can also be used to mask the message that would normally be interpreted as error (according to the rules defined in *parse.rules*) but should not be considered as such within the current test.
+
+Example:
+~~~~~
+puts "REQUIRED Linux: Faulty shapes in variables faulty_1 to faulty_5"
+~~~~~
+
+This statement notifies test system that errors reported by *checkshape* command are expected in that test case, and test should be considered as OK if this message appears, despite of presence of general rule stating that 'Faulty' signals failure.
+
+If output does not contain required statement, test case will be marked as FAILED.
+
+@section testmanual_4 Advanced Use
+
+@subsection testmanual_4_1 Running Tests on Older Versions of OCCT
+
+Sometimes it might be necessary to run tests on the previous versions of OCCT (<= 6.5.4) that do not include this test system. This can be done by adding DRAW configuration file *DrawAppliInit* in the directory, which is current by the moment of DRAW start-up, to load test commands and to define the necessary environment.
+
+Note: in OCCT 6.5.3, file *DrawAppliInit* already exists in <i>$CASROOT/src/DrawResources</i>, new commands should be added to this file instead of a new one in the current directory.
+
+For example, let us assume that *d:/occt* contains an up-to-date version of OCCT sources with tests, and the test data archive is unpacked to *d:/test-data*):
+
+~~~~~
+set env(CASROOT) d:/occt
+set env(CSF_TestScriptsPath) $env(CASROOT)/tests
+source $env(CASROOT)/src/DrawResources/TestCommands.tcl
+set env(CSF_TestDataPath) $env(CASROOT)/data;d:/test-data
+return
+~~~~~
+
+Note that on older versions of OCCT the tests are run in compatibility mode and thus not all output of the test command can be captured; this can lead to absence of some error messages (can be reported as either a failure or an improvement).
+
+@subsection testmanual_4_2 Adding custom tests
+
+You can extend the test system by adding your own tests. For that it is necessary to add paths to the directory where these tests are located, and one or more additional data directories, to the environment variables *CSF_TestScriptsPath* and *CSF_TestDataPath*. The recommended way for doing this is using DRAW configuration file *DrawAppliInit* located in the directory which is current by the moment of DRAW start-up.
+
+Use Tcl command <i>_path_separator</i> to insert a platform-dependent separator to the path list.
+
+For example:
+~~~~~
+set env(CSF_TestScriptsPath) \
+ $env(TestScriptsPath)[_path_separator]d:/MyOCCTProject/tests
+set env(CSF_TestDataPath) \
+ d:/occt/test-data[_path_separator]d:/MyOCCTProject/data
+return ;# this is to avoid an echo of the last command above in cout
+~~~~~
+
+@subsection testmanual_4_3 Parallel execution of tests
+
+For better efficiency, on computers with multiple CPUs the tests can be run in parallel mode. This is default behavior for command *testgrid* : the tests are executed in parallel processes (their number is equal to the number of CPUs available on the system). In order to change this behavior, use option parallel followed by the number of processes to be used (1 or 0 to run sequentially).
+
+Note that the parallel execution is only possible if Tcl extension package *Thread* is installed.
+If this package is not available, *testgrid* command will output a warning message.
+
+@subsection testmanual_4_4 Checking non-regression of performance, memory, and visualization
+
+Some test results are very dependent on the characteristics of the workstation, where they are performed, and thus cannot be checked by comparison with some predefined values. These results can be checked for non-regression (after a change in OCCT code) by comparing them with the results produced by the version without this change. The most typical case is comparing the result obtained in a branch created for integration of a fix (CR***) with the results obtained on the master branch before that change is made.
+
+OCCT test system provides a dedicated command *testdiff* for comparing CPU time of execution, memory usage, and images produced by the tests.
+
+~~~~~
+testdiff dir1 dir2 [groupname [gridname]] [options...]
+~~~~~
+Here *dir1* and *dir2* are directories containing logs of two test runs.
+
+Possible options are:
+* <i>-save \<filename\> </i> -- saves the resulting log in a specified file (<i>$dir1/diff-$dir2.log</i> by default). HTML log is saved with the same name and extension .html;
+* <i>-status {same|ok|all}</i> -- allows filtering compared cases by their status:
+ * *same* -- only cases with same status are compared (default);
+ * *ok* -- only cases with OK status in both logs are compared;
+ * *all* -- results are compared regardless of status;
+* <i>-verbose \<level\> </i> -- defines the scope of output data:
+ * 1 -- outputs only differences;
+ * 2 -- additionally outputs the list of logs and directories present in one of directories only;
+ * 3 -- (by default) additionally outputs progress messages;
+* <i>-image [filename]</i> - compare images and save the resulting log in specified file (<i>$dir1/diffimage-$dir2.log</i> by default)
+* <i>-cpu [filename]</i> - compare overall CPU and save the resulting log in specified file (<i>$dir1/diffcpu-$dir2.log</i> by default)
+* <i>-memory [filename]</i> - compare memory delta and save the resulting log in specified file (<i>$dir1/diffmemory-$dir2.log</i> by default)
+* <i>-highlight_percent \<value\></i> - highlight considerable (>value in %) deviations of CPU and memory (default value is 5%)
+
+Example:
+
+~~~~~
+Draw[]> testdiff results/CR12345-2012-10-10T08:00 results/master-2012-10-09T21:20
+~~~~~
+
+Particular tests can generate additional data that need to be compared by *testdiff* command.
+For that, for each parameter to be controlled, the test should produce the line containing keyword "COUNTER* followed by arbitrary name of the parameter, then colon and numeric value of the parameter.
+
+Example of test code:
+
+~~~~~
+puts "COUNTER Memory heap usage at step 5: [meminfo h]"
+~~~~~
+
+@section testmanual_5 APPENDIX
+
+@subsection testmanual_5_1 Test groups
+
+@subsubsection testmanual_5_1_1 3rdparty
+
+This group allows testing the interaction of OCCT and 3rdparty products.
+
+DRAW module: VISUALIZATION.
+
+| Grid | Commands | Functionality |
+| :---- | :----- | :------- |
+| export | vexport | export of images to different formats |
+| fonts | vtrihedron, vcolorscale, vdrawtext | display of fonts |
+
+
+@subsubsection testmanual_5_1_2 blend
+
+This group allows testing blends (fillets) and related operations.
+
+DRAW module: MODELING.
+
+| Grid | Commands | Functionality |
+| :---- | :----- | :------- |
+| simple | blend | fillets on simple shapes |
+| complex | blend | fillets on complex shapes, non-trivial geometry |
+| tolblend_simple | tolblend, blend | |
+| buildevol | buildevol | |
+| tolblend_buildvol | tolblend, buildevol | use of additional command tolblend |
+| bfuseblend | bfuseblend | |
+| encoderegularity | encoderegularity | |
+
+@subsubsection testmanual_5_1_3 boolean
+
+This group allows testing Boolean operations.
+
+DRAW module: MODELING (packages *BOPTest* and *BRepTest*).
+
+Grids names are based on name of the command used, with suffixes:
+* <i>_2d</i> -- for tests operating with 2d objects (wires, wires, 3d objects, etc.);
+* <i>_simple</i> -- for tests operating on simple shapes (boxes, cylinders, toruses, etc.);
+* <i>_complex</i> -- for tests dealing with complex shapes.
+
+| Grid | Commands | Functionality |
+| :---- | :----- | :------- |
+| bcommon_2d | bcommon | Common operation (old algorithm), 2d |
+| bcommon_complex | bcommon | Common operation (old algorithm), complex shapes |
+| bcommon_simple | bcommon | Common operation (old algorithm), simple shapes |
+| bcut_2d | bcut | Cut operation (old algorithm), 2d |
+| bcut_complex | bcut | Cut operation (old algorithm), complex shapes |
+| bcut_simple | bcut | Cut operation (old algorithm), simple shapes |
+| bcutblend | bcutblend | |
+| bfuse_2d | bfuse | Fuse operation (old algorithm), 2d |
+| bfuse_complex | bfuse | Fuse operation (old algorithm), complex shapes |
+| bfuse_simple | bfuse | Fuse operation (old algorithm), simple shapes |
+| bopcommon_2d | bopcommon | Common operation, 2d |
+| bopcommon_complex | bopcommon | Common operation, complex shapes |
+| bopcommon_simple | bopcommon | Common operation, simple shapes |
+| bopcut_2d | bopcut | Cut operation, 2d |
+| bopcut_complex | bopcut | Cut operation, complex shapes |
+| bopcut_simple | bopcut | Cut operation, simple shapes |
+| bopfuse_2d | bopfuse | Fuse operation, 2d |
+| bopfuse_complex | bopfuse | Fuse operation, complex shapes |
+| bopfuse_simple | bopfuse | Fuse operation, simple shapes |
+| bopsection | bopsection | Section |
+| boptuc_2d | boptuc | |
+| boptuc_complex | boptuc | |
+| boptuc_simple | boptuc | |
+| bsection | bsection | Section (old algorithm) |
+
+@subsubsection testmanual_5_1_4 bugs
+
+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 @ref testmanual_5_2 "Mapping of OCCT functionality to grid names in group bugs" chapter for details.
+
+@subsubsection testmanual_5_1_5 caf
+
+This group allows testing OCAF functionality.
+
+DRAW module: OCAFKERNEL.
+
+| Grid | Commands | Functionality |
+| :---- | :----- | :------- |
+| basic | | Basic attributes |
+| bugs | | Saving and restoring of document |
+| driver | | OCAF drivers |
+| named_shape | | *TNaming_NamedShape* attribute |
+| presentation | | *AISPresentation* attributes |
+| tree | | Tree construction attributes |
+| xlink | | XLink attributes |
+
+@subsubsection testmanual_5_1_6 chamfer
+
+This group allows testing chamfer operations.
+
+DRAW module: MODELING.
+
+The test grid name is constructed depending on the type of the tested chamfers. Additional suffix <i>_complex</i> is used for test cases involving complex geometry (e.g. intersections of edges forming a chamfer); suffix <i>_sequence</i> is used for grids where chamfers are computed sequentially.
+
+| Grid | Commands | Functionality |
+| :---- | :----- | :------- |
+| equal_dist | | Equal distances from edge |
+| equal_dist_complex | | Equal distances from edge, complex shapes |
+| equal_dist_sequence | | Equal distances from edge, sequential operations |
+| dist_dist | | Two distances from edge |
+| dist_dist_complex | | Two distances from edge, complex shapes |
+| dist_dist_sequence | | Two distances from edge, sequential operations |
+| dist_angle | | Distance from edge and given angle |
+| dist_angle_complex | | Distance from edge and given angle |
+| dist_angle_sequence | | Distance from edge and given angle |
+
+@subsubsection testmanual_5_1_7 de
+
+This group tests reading and writing of CAD data files (iges, step) to and from OCCT.
+
+Test cases check transfer status, shape and attributes against expected reference values.
+
+| Grid | Commands | Functionality |
+| :---- | :----- | :------- |
+| iges_1, iges_2, iges_3 | igesbrep, brepiges, ReadIges, WriteIges | IGES tests |
+| step_1, step_2, step_3, step_4, step_5 | stepread, stepwrite, ReadStep, WriteStep | STEP tests |
+
+@subsubsection testmanual_5_1_8 demo
+
+This group allows demonstrating how testing cases are created, and testing DRAW commands and the test system as a whole.
+
+| Grid | Commands | Functionality |
+| :---- | :----- | :------- |
+| draw | getsource, restore | Basic DRAW commands |
+| testsystem | | Testing system |
+| samples | | OCCT samples |
+
+
+@subsubsection testmanual_5_1_9 draft
+
+This group allows testing draft operations.
+
+DRAW module: MODELING.
+
+| Grid | Commands | Functionality |
+| :---- | :----- | :------- |
+| Angle | depouille | Drafts with angle (inclined walls) |
+
+
+@subsubsection testmanual_5_1_10 feat
+
+This group allows testing creation of features on a shape.
+
+DRAW module: MODELING (package *BRepTest*).
+
+| Grid | Commands | Functionality |
+| :---- | :----- | :------- |
+| featdprism | | |
+| featlf | | |
+| featprism | | |
+| featrevol | | |
+| featrf | | |
+
+@subsubsection testmanual_5_1_11 heal
+
+This group allows testing the functionality provided by *ShapeHealing* toolkit.
+
+DRAW module: XSDRAW
+
+| Grid | Commands | Functionality |
+| :---- | :----- | :------- |
+| fix_shape | fixshape | Shape healing |
+| fix_gaps | fixwgaps | Fixing gaps between edges on a wire |
+| same_parameter | sameparameter | Fixing non-sameparameter edges |
+| same_parameter_locked | sameparameter | Fixing non-sameparameter edges |
+| fix_face_size | DT_ApplySeq | Removal of small faces |
+| elementary_to_revolution | DT_ApplySeq | Conversion of elementary surfaces to revolution |
+| direct_faces | directfaces | Correction of axis of elementary surfaces |
+| drop_small_edges | fixsmall | Removal of small edges |
+| split_angle | DT_SplitAngle | Splitting periodic surfaces by angle |
+| split_angle_advanced | DT_SplitAngle | Splitting periodic surfaces by angle |
+| split_angle_standard | DT_SplitAngle | Splitting periodic surfaces by angle |
+| split_closed_faces | DT_ClosedSplit | Splitting of closed faces |
+| surface_to_bspline | DT_ToBspl | Conversion of surfaces to b-splines |
+| surface_to_bezier | DT_ShapeConvert | Conversion of surfaces to bezier |
+| split_continuity | DT_ShapeDivide | Split surfaces by continuity criterion |
+| split_continuity_advanced | DT_ShapeDivide | Split surfaces by continuity criterion |
+| split_continuity_standard | DT_ShapeDivide | Split surfaces by continuity criterion |
+| surface_to_revolution_advanced | DT_ShapeConvertRev | Convert elementary surfaces to revolutions, complex cases |
+| surface_to_revolution_standard | DT_ShapeConvertRev | Convert elementary surfaces to revolutions, simple cases |
+| update_tolerance_locked | updatetolerance | Update the tolerance of shape so that it satisfy the rule: toler(face)<=toler(edge)<=toler(vertex) |
+
+@subsubsection testmanual_5_1_12 mesh
+
+This group allows testing shape tessellation (*BRepMesh*) and shading.
+
+DRAW modules: MODELING (package *MeshTest*), VISUALIZATION (package *ViewerTest*)
+
+| Grid | Commands | Functionality |
+| :---- | :----- | :------- |
+| advanced_shading | vdisplay | Shading, complex shapes |
+| standard_shading | vdisplay | Shading, simple shapes |
+| advanced_mesh | mesh | Meshing of complex shapes |
+| standard_mesh | mesh | Meshing of simple shapes |
+| advanced_incmesh | incmesh | Meshing of complex shapes |
+| standard_incmesh | incmesh | Meshing of simple shapes |
+| advanced_incmesh_parallel | incmesh | Meshing of complex shapes, parallel mode |
+| standard_incmesh_parallel | incmesh | Meshing of simple shapes, parallel mode |
+
+@subsubsection testmanual_5_1_13 mkface
+
+This group allows testing creation of simple surfaces.
+
+DRAW module: MODELING (package *BRepTest*)
+
+| Grid | Commands | Functionality |
+| :---- | :----- | :------- |
+| after_trim | mkface | |
+| after_offset | mkface | |
+| after_extsurf_and_offset | mkface | |
+| after_extsurf_and_trim | mkface | |
+| after_revsurf_and_offset | mkface | |
+| mkplane | mkplane | |
+
+@subsubsection testmanual_5_1_14 nproject
+
+This group allows testing normal projection of edges and wires onto a face.
+
+DRAW module: MODELING (package *BRepTest*)
+
+| Grid | Commands | Functionality |
+| :---- | :----- | :------- |
+| Base | nproject | |
+
+@subsubsection testmanual_5_1_15 offset
+
+This group allows testing offset functionality for curves and surfaces.
+
+DRAW module: MODELING (package *BRepTest*)
+
+| Grid | Commands | Functionality |
+| :---- | :----- | :------- |
+| compshape | offsetcompshape | Offset of shapes with removal of some faces |
+| faces_type_a | offsetparameter, offsetload, offsetperform | Offset on a subset of faces with a fillet |
+| faces_type_i | offsetparameter, offsetload, offsetperform | Offset on a subset of faces with a sharp edge |
+| shape_type_a | offsetparameter, offsetload, offsetperform | Offset on a whole shape with a fillet |
+| shape_type_i | offsetparameter, offsetload, offsetperform | Offset on a whole shape with a fillet |
+| shape | offsetshape | |
+| wire_closed_outside_0_005, wire_closed_outside_0_025, wire_closed_outside_0_075, wire_closed_inside_0_005, wire_closed_inside_0_025, wire_closed_inside_0_075, wire_unclosed_outside_0_005, wire_unclosed_outside_0_025, wire_unclosed_outside_0_075 | mkoffset | 2d offset of closed and unclosed planar wires with different offset step and directions of offset ( inside / outside ) |
+
+@subsubsection testmanual_5_1_16 pipe
+
+This group allows testing construction of pipes (sweeping of a contour along profile).
+
+DRAW module: MODELING (package *BRepTest*)
+
+| Grid | Commands | Functionality |
+| :---- | :----- | :------- |
+| Standard | pipe | |
+
+@subsubsection testmanual_5_1_17 prism
+
+This group allows testing construction of prisms.
+
+DRAW module: MODELING (package *BRepTest*)
+
+| Grid | Commands | Functionality |
+| :---- | :----- | :------- |
+| seminf | prism | |
+
+@subsubsection testmanual_5_1_18 sewing
+
+This group allows testing sewing of faces by connecting edges.
+
+DRAW module: MODELING (package *BRepTest*)
+
+| Grid | Commands | Functionality |
+| :---- | :----- | :------- |
+| tol_0_01 | sewing | Sewing faces with tolerance 0.01 |
+| tol_1 | sewing | Sewing faces with tolerance 1 |
+| tol_100 | sewing | Sewing faces with tolerance 100 |
+
+@subsubsection testmanual_5_1_19 thrusection
+
+This group allows testing construction of shell or a solid passing through a set of sections in a given sequence (loft).
+
+| Grid | Commands | Functionality |
+| :---- | :----- | :------- |
+| solids | thrusection | Lofting with resulting solid |
+| not_solids | thrusection | Lofting with resulting shell or face |
+
+@subsubsection testmanual_5_1_20 xcaf
+
+This group allows testing extended data exchange packages.
+
+| Grid | Commands | Functionality |
+| :---- | :----- | :------- |
+| dxc, dxc_add_ACL, dxc_add_CL, igs_to_dxc, igs_add_ACL, brep_to_igs_add_CL, stp_to_dxc, stp_add_ACL, brep_to_stp_add_CL, brep_to_dxc, add_ACL_brep, brep_add_CL | | Subgroups are divided by format of source file, by format of result file and by type of document modification. For example, *brep_to_igs* means that the source shape in brep format was added to the document, which was saved into igs format after that. The postfix *add_CL* means that colors and layers were initialized in the document before saving and the postfix *add_ACL* corresponds to the creation of assembly and initialization of colors and layers in a document before saving. |
+
+
+@subsection testmanual_5_2 Mapping of OCCT functionality to grid names in group *bugs*
+
+| OCCT Module / Mantis category | Toolkits | Test grid in group bugs |
+| :---------- | :--------- | :---------- |
+| Application Framework | PTKernel, TKPShape, TKCDF, TKLCAF, TKCAF, TKBinL, TKXmlL, TKShapeSchema, TKPLCAF, TKBin, TKXml, TKPCAF, FWOSPlugin, TKStdLSchema, TKStdSchema, TKTObj, TKBinTObj, TKXmlTObj | caf |
+| Draw | TKDraw, TKTopTest, TKViewerTest, TKXSDRAW, TKDCAF, TKXDEDRAW, TKTObjDRAW, TKQADraw, DRAWEXE, Problems of testing system | draw |
+| Shape Healing | TKShHealing | heal |
+| Mesh | TKMesh, TKXMesh | mesh |
+| Data Exchange | TKIGES | iges |
+| Data Exchange | TKSTEPBase, TKSTEPAttr, TKSTEP209, TKSTEP | step |
+| Data Exchange | TKSTL, TKVRML | stlvrml |
+| Data Exchange | TKXSBase, TKXCAF, TKXCAFSchema, TKXDEIGES, TKXDESTEP, TKXmlXCAF, TKBinXCAF | xde |
+| Foundation Classes | TKernel, TKMath | fclasses |
+| Modeling_algorithms | TKGeomAlgo, TKTopAlgo, TKPrim, TKBO, TKBool, TKHLR, TKFillet, TKOffset, TKFeat, TKXMesh | modalg |
+| Modeling Data | TKG2d, TKG3d, TKGeomBase, TKBRep | moddata |
+| Visualization | TKService, TKV2d, TKV3d, TKOpenGl, TKMeshVS, TKNIS | vis |
+
+
+@subsection testmanual_5_3 Recommended approaches to checking test results
+
+@subsubsection testmanual_5_3_1 Shape validity
+
+Run command *checkshape* on the result (or intermediate) shape and make sure that *parse.rules* of the test grid or group reports bad shapes (usually recognized by word "Faulty") as error.
+
+Example
+~~~~~
+checkshape result
+~~~~~
+
+To check the number of faults in the shape command *checkfaults* can be used.
+
+Use: checkfaults shape source_shape [ref_value=0]
+
+The default syntax of *checkfaults* command:
+~~~~~
+checkfaults results a_1
+~~~~~
+
+The command will check the number of faults in the source shape (*a_1*) and compare it
+with number of faults in the resulting shape (*result*). If shape *result* contains
+more faults, you will get an error:
+~~~~~
+checkfaults results a_1
+Error : Number of faults is 5
+~~~~~
+It is possible to set the reference value for comparison (reference value is 4):
+
+~~~~~
+checkfaults results a_1 4
+~~~~~
+
+If number of faults in the resulting shape is unstable, reference value should be set to "-1".
+As a result command *checkfaults* will return the following error:
+
+~~~~~
+checkfaults results a_1 -1
+Error : Number of faults is UNSTABLE
+~~~~~
+
+@subsubsection testmanual_5_3_2 Shape tolerance
+
+The maximal tolerance of sub-shapes of each kind of the resulting shape can be extracted from output of tolerance command as follows:
+
+~~~~~
+set tolerance [tolerance result]
+regexp { *FACE +: +MAX=([-0-9.+eE]+)} $tolerance dummy max_face
+regexp { *EDGE +: +MAX=([-0-9.+eE]+)} $tolerance dummy max_edgee
+regexp { *VERTEX +: +MAX=([-0-9.+eE]+)} $tolerance dummy max_vertex
+~~~~~
+
+It is possible to use command *checkmaxtol* to check maximal tolerance of shape and compare it with reference value.
+
+Use: checkmaxtol shape [options...]
+
+Allowed options are:
+ * <i>-ref</i> -- reference value of maximum tolerance;
+ * <i>-source</i> -- list of shapes to compare with;
+ * <i>-min_tol</i> -- minimum tolerance for comparison;
+ * <i>-multi_tol</i> -- tolerance multiplier.
+
+The default syntax of *checkmaxtol* command for comparison with the reference value:
+~~~~~
+checkmaxtol result -ref 0.00001
+~~~~~
+
+There is an opportunity to compare max tolerance of resulting shape with max tolerance of source shape.
+In the following example command *checkmaxtol* gets max tolerance among objects *a_1* and *a_2*.
+Then it chooses the maximum value between founded tolerance and value -min_tol (0.000001)
+and multiply it on the coefficient -multi_tol (i.e. 2):
+
+~~~~~
+checkmaxtol result -source {a_1 a_2} -min_tol 0.000001 -multi_tol 2
+~~~~~
+
+If the value of maximum tolerance more than founded tolerance for comparison, the command will return an error.
+
+Also, command *checkmaxtol* can be used to get max tolerance of the shape:
+
+~~~~~
+set maxtol [checkmaxtol result]
+~~~~~
+
+@subsubsection testmanual_5_3_3 Shape volume, area, or length
+
+Use command *vprops, sprops,* or *lprops* to correspondingly measure volume, area, or length of the shape produced by the test. The value can be extracted from the result of the command by *regexp*.
+
+Example:
+~~~~~
+# check area of shape result with 1% tolerance
+regexp {Mass +: +([-0-9.+eE]+)} [sprops result] dummy area
+if { abs($area - $expected) > 0.1 + 0.01 * abs ($area) } {
+ puts "Error: The area of result shape is $area, while expected $expected"
+}
+~~~~~
+
+@subsubsection testmanual_5_3_4 Memory leaks
+
+The test system measures the amount of memory used by each test case. Considerable deviations (as well as the overall difference) in comparison with reference results can be reported by command *testdiff* (see @ref testmanual_4_4).
+
+To check memory leak on a particular operation, run it in a cycle, measure the memory consumption at each step and compare it with a threshold value.
+The command *checktrend* (defined in *tests/bugs/begin*) can be used to analyze a sequence of memory measurements and to get a statistically based evaluation of the leak presence.
+
+Example:
+~~~~~
+set listmem {}
+for {set i 1} {$i < 100} {incr i} {
+ # run suspect operation
+ …
+ # check memory usage (with tolerance equal to half page size)
+ lappend listmem [expr [meminfo w] / 1024]
+ if { [checktrend $listmem 0 256 "Memory leak detected"] } {
+ puts "No memory leak, $i iterations"
+ break
+ }
+}
+~~~~~
+
+@subsubsection testmanual_5_3_5 Visualization
+
+The following command sequence allows you to take a snapshot of the viewer, give it the name of the test case, and save in the directory indicated by Tcl variable *imagedir*.
+
+~~~~~
+vinit
+vclear
+vdisplay result
+vsetdispmode 1
+vfit
+vzfit
+vdump $imagedir/${casename}_shading.png
+~~~~~
+
+This image will be included in the HTML log produced by *testgrid* command and will be checked for non-regression through comparison of images by command *testdiff*.
+
+Also it is possible to use command *checkview* to make a snapshot of the viewer.
+
+Use: checkview [options...]
+Allowed options are:
+* <i>-display shapename </i> -- displays shape with name *shapename*;
+* <i>-3d </i> -- displays shape in 3d viewer;
+* <i>-2d [ v2d / smallview ] </i> - displays shape in 2d viewer (the default viewer is *smallview*);
+* <i>-path PATH</i> -- sets the location of the saved viewer screenshot;
+* <i>-vdispmode N</i> -- sets *vdispmode* for 3d viewer (default value is 1)
+* <i>-screenshot</i> -- makes a screenshot of already created viewer
+* The procedure can check a property of shape (length, area or volume) and compare it with value *N*:
+ * <i>-l [N]</i>
+ * <i>-s [N]</i>
+ * <i>-v [N]</i>
+ * If the current property is equal to value *N*, the shape is marked as valid in the procedure.
+ * If value *N* is not given, the procedure will mark the shape as valid if the current property is non-zero.
+* <i>-with {a b c}</i> -- displays shapes *a, b* and *c* together with the shape (if the shape is valid)
+* <i>-otherwise {d e f}</i> -- displays shapes *d, e* and *f* instead of the shape (if the shape is NOT valid)
+
+Note that is required to use either option <i> -2d </i> or option <i> -3d</i>.
+
+Examples:
+~~~~~
+checkview -display result -2d -path ${imagedir}/${test_image}.png
+checkview -display result -3d -path ${imagedir}/${test_image}.png
+checkview -display result_2d -2d v2d -path ${imagedir}/${test_image}.png
+~~~~~
+
+~~~~~
+box a 10 10 10
+box b 5 5 5 10 10 10
+bcut result b a
+set result_vertices [explode result v]
+checkview -display result -2d -with ${result_vertices} -otherwise { a b } -l -path ${imagedir}/${test_image}.png
+~~~~~
+
+~~~~~
+box a 10 10 10
+box b 5 5 5 10 10 10
+bcut result b a
+vinit
+vdisplay a b
+vfit
+checkview -screenshot -3d -path ${imagedir}/${test_image}.png
+~~~~~
+
+@subsubsection testmanual_5_3_6 Number of free edges
+
+Procedure *checkfreebounds* compares the number of free edges with a reference value.
+
+Use: checkfreebounds shape ref_value [options...]
+
+Allowed options are:
+ * <i>-tol N</i> -- used tolerance (default -0.01);
+ * <i>-type N</i> -- used type, possible values are "closed" and "opened" (default "closed").
+
+~~~~~
+checkfreebounds result 13
+~~~~~
+
+Option <i>-tol N</i> defines tolerance for command *freebounds*, which is used within command *checkfreebounds*.
+
+Option <i>-type N</i> is used to select the type of counted free edges: closed or open.
+
+If the number of free edges in the resulting shape is unstable, the reference value should be set to "-1".
+As a result command *checkfreebounds* will return the following error:
+
+~~~~~
+checkfreebounds result -1
+Error : Number of free edges is UNSTABLE
+~~~~~
+
+@subsubsection testmanual_5_3_7 Compare numbers
+
+Procedure *checkreal* checks the equality of two reals with a tolerance (relative and absolute).
+
+Use: checkreal name value expected tol_abs tol_rel
+
+~~~~~
+checkreal "Some important value" $value 5 0.0001 0.01
+~~~~~
+
+@subsubsection testmanual_5_3_8 Check number of sub-shapes
+
+Procedure *checknbshapes* compares the number of sub-shapes in "shape" with the given reference data.
+
+Use: checknbshapes shape [options...]
+
+Allowed options are:
+ * <i>-vertex N
+ * -edge N
+ * -wire N
+ * -face N
+ * -shell N
+ * -solid N
+ * -compsolid N
+ * -compound N
+ * -shape N
+ * -t</i> -- compares the number of sub-shapes in "shape" counting
+ the same sub-shapes with different location as different sub-shapes.
+ * <i>-m msg</i> -- prints "msg" in case of error
+
+~~~~~
+checknbshapes result -vertex 8 -edge 4
+~~~~~
+
+@subsubsection testmanual_5_3_9 Check pixel color
+
+Command *checkcolor* can be used to check pixel color.
+
+Use: checkcolor x y red green blue
+
+where:
+ * <i>x, y</i> -- pixel coordinates;
+ * <i>red green blue</i> -- expected pixel color (values from 0 to 1).
+
+This procedure checks color with tolerance (5x5 area).
+
+Next example will compare color of point with coordinates x=100 y=100 with RGB color R=1 G=0 B=0.
+If colors are not equal, procedure will check the nearest ones points (5x5 area)
+~~~~~
+checkcolor 100 100 1 0 0
+~~~~~
+
+@subsubsection testmanual_5_3_10 Compute length, area and volume of input shape
+
+Procedure *checkprops* computes length, area and volume of the input shape.
+
+Use: checkprops shapename [options...]
+
+Allowed options are:
+ * <i>-l LENGTH</i> -- command *lprops*, computes the mass properties of all edges in the shape with a linear density of 1;
+ * <i>-s AREA</i> -- command *sprops*, computes the mass properties of all faces with a surface density of 1;
+ * <i>-v VOLUME</i> -- command *vprops*, computes the mass properties of all solids with a density of 1;
+ * <i>-eps EPSILON</i> -- the epsilon defines relative precision of computation;
+ * <i>-deps DEPSILON</i> -- the epsilon defines relative precision to compare corresponding values;
+ * <i>-equal SHAPE</i> -- compares area, volume and length of input shapes. Puts error if they are not equal;
+ * <i>-notequal SHAPE</i> -- compares area, volume and length of input shapes. Puts error if they are equal.
+
+Options <i> -l, -s </i> and <i> -v</i> are independent and can be used in any order. Tolerance *epsilon* is the same for all options.
+
+~~~~~
+checkprops result -s 6265.68
+checkprops result -s -equal FaceBrep
+~~~~~
+
+@subsubsection testmanual_5_3_11 Parse output dump and compare it with reference values
+
+Procedure *checkdump* is used to parse output dump and compare it with reference values.
+
+Use: checkdump shapename [options...]
+
+Allowed options are:
+ * <i>-name NAME</i> -- list of parsing parameters (e.g. Center, Axis, etc.);
+ * <i>-ref VALUE</i> -- list of reference values for each parameter in *NAME*;
+ * <i>-eps EPSILON</i> -- the epsilon defines relative precision of computation.
+
+~~~~~
+checkdump result -name {Center Axis XAxis YAxis Radii} -ref {{-70 0} {-1 -0} {-1 -0} {0 -1} {20 10}} -eps 0.01
+~~~~~
+
+@subsubsection testmanual_5_3_12 Compute length of input curve
+
+Procedure *checklength* computes length of the input curve.
+
+Use: checklength curvename [options...]
+
+Allowed options are:
+ * <i>-l LENGTH</i> -- command *length*, computes the length of the input curve with precision of computation;
+ * <i>-eps EPSILON</i> -- the epsilon defines a relative precision of computation;
+ * <i>-equal CURVE</i> -- compares the length of input curves. Puts error if they are not equal;
+ * <i>-notequal CURVE</i> -- compares the length of input curves. Puts error if they are equal.
+
+~~~~~
+checklength cp1 -l 7.278
+checklength res -l -equal ext_1
+~~~~~
+@subsubsection testmanual_5_3_13 Check maximum deflection, number of triangles and nodes in mesh
+
+Command *checktrinfo* can be used to to check the maximum deflection, as well as the number of nodes and triangles in mesh.
+
+Use: checktrinfo shapename [options...]
+
+Allowed options are:
+ * <i>-tri [N]</i> -- compares the current number of triangles in *shapename* mesh with the given reference data.
+ If reference value N is not given and the current number of triangles is equal to 0, procedure *checktrinfo* will print an error.
+ * <i>-nod [N]</i> -- compares the current number of nodes in *shapename* mesh with the given reference data.
+ If reference value N is not given and the current number of nodes is equal to 0, procedure *checktrinfo* will print an error.
+ * <i>-defl [N]</i> -- compares the current value of maximum deflection in *shapename* mesh with the given reference data.
+ If reference value N is not given and current maximum deflection is equal to 0, procedure *checktrinfo* will print an error.
+ * <i>-max_defl N</i> -- compares the current value of maximum deflection in *shapename* mesh with the max possible value.
+ * <i>-tol_abs_tri N</i> -- absolute tolerance for comparison of number of triangles (default value 0).
+ * <i>-tol_rel_tri N</i> -- relative tolerance for comparison of number of triangles (default value 0).
+ * <i>-tol_abs_nod N</i> -- absolute tolerance for comparison of number of nodes (default value 0).
+ * <i>-tol_rel_nod N</i> -- relative tolerance for comparison of number of nodes (default value 0).
+ * <i>-tol_abs_defl N</i> -- absolute tolerance for deflection comparison (default value 0).
+ * <i>-tol_rel_defl N</i> -- relative tolerance for deflection comparison (default value 0).
+ * <i>-ref [trinfo a]</i> -- compares deflection, number of triangles and nodes in *shapename* and *a*.
+
+Note that options <i> -tri, -nod </i> and <i> -defl </i> do not work together with option <i> -ref</i>.
+
+Examples:
+
+Comparison with some reference values:
+~~~~~
+checktrinfo result -tri 129 -nod 131 -defl 0.01
+~~~~~
+
+Comparison with another mesh:
+~~~~~
+checktrinfo result -ref [tringo a]
+~~~~~
+
+Comparison of deflection with the max possible value:
+~~~~~
+checktrinfo result -max_defl 1
+~~~~~
+
+Check that the current values are not equal to zero:
+~~~~~
+checktrinfo result -tri -nod -defl
+~~~~~
+
+Check that the number of triangles and the number of nodes are not equal to some specific values:
+~~~~~
+checktrinfo result -tri !10 -nod !8
+~~~~~
+
+It is possible to compare current values with reference values with some tolerances.
+Use options <i>-tol_\* </i> for that.
+~~~~~
+checktrinfo result -defl 1 -tol_abs_defl 0.001
+~~~~~
+
+++ /dev/null
-Coding Rules {#occt_dev_guides__coding_rules}
-======================================
-
-@tableofcontents
-
-@section occt_coding_rules_1 Introduction
-
-The purpose of this document is to define a common programming style for Open CASCADE Technology.
-
-The common style facilitates understanding and maintaining a code developed cooperatively by several programmers. In addition, it enables construction of tools that incorporate knowledge of these standards to help in the programming.
-
-OCCT programming style follows common and appropriate best practices, so some guidelines have been excerpted from the public domain.
-
-The guide can be improved in the future as new ideas and enhancements are added.
-
-@subsection occt_coding_rules_1_1 Scope of the document
-
-Rules in this document refer to C++ code. However, with minor exceptions due to language restrictions, they are applicable to any sources in Open CASCADE Technology framework, including:
-- C/C++
-- GLSL programs
-- OpenCL kernels
-- TCL scripts and test cases
-
-@section occt_coding_rules_2 Naming Conventions
-
-@subsection occt_coding_rules_2_1 General naming rules
-
-The names considered in this section mainly refer to the interface of Open CASCADE Technology libraries or source code itself.
-
-### International language [MANDATORY]
-
-Open CASCADE Technology is an open source platform available for an international community, thus all names need to be composed of English words or their abbreviations.
-
-### Meaningful names
-
-Names should be meaningful or, at least, contain a meaningful part. To better understand this requirement, let us examine the existing names of toolkits, packages, classes and methods:
-- Packages containing words *Geom* or *Geom2d* in their names are related to geometrical data and operations.
-- Packages containing words *TopoDS* or *BRep* in their names are related to topological data and operations.
-- Packages ending with <i>...Test</i> define Draw Harness plugins.
-- Methods starting with *Get...* and *Set...* are usually responsible for correspondingly retrieving and storing data.
-
-### Related names
-
-Names related to a logically connected functionality should have the same prefix (start with the same letters) or, at least, have any other common part.
-For example, method *GetCoord* returns a triple of real values and is defined for directions, vectors and points. The logical connection is obvious.
-
-### Camel Case style
-Camel Case style is preferred for names.
-For example:
-
-~~~~~{.cpp}
-Standard_Integer awidthofbox; // this is bad
-Standard_Integer width_of_box; // this is bad
-Standard_Integer aWidthOfBox; // this is OK
-~~~~~
-
-@subsection occt_coding_rules_2_2 Names of development units
-
-Usually a unit (e.g. a package) is a set of classes, methods, enumerations or any other sources implementing a common functionality, which is self-contained and independent from other parts of the library.
-
-### No underscores in unit names [MANDATORY]
-
-Names of units should not contain underscores, unless the use of underscores is allowed explicitly.
-
-### File name extensions [MANDATORY]
-
-The following extensions should be used for source files, depending on their type:
-
-* <i>.cxx</i> -- C++ source files
-* <i>.hxx</i> -- C++ header files
-* <i>.lxx</i> -- additional headers containing definitions of inline methods and auxiliary code
-
-Note that .lxx files should be avoided in most cases - inline method should be placed in header file instead.
-
-### Prefix for toolkit names [MANDATORY]
-
-Toolkit names are prefixed by *TK*, followed by a meaningful part of the name explaining the domain of functionality covered by the toolkit (e.g. *TKOpenGl*).
-
-### Names of public types
-
-Names of public classes and other types (structures, enums, typedefs) should match the common pattern: name of the package followed by underscore and suffix (the own name of the type):
-
-~~~~~
- <package-name>_<class-name>
-~~~~~
-
-Static methods related to the whole package are defined in the class with the same name as package (without suffix).
-
-Each type should be defined in its own header file with the name of the type and extension ".hxx".
-Implementation should be placed in the file with the same name and extension ".cxx"; for large classes it is possible to split implementation into multiple source files with additional suffixes in the names (usually numerical, e.g. *BSplCLib_1.cxx*).
-
-For example, class *Adaptor2d_Curve2d* belongs to the package *Adaptor2d*; it is defined in header file *Adaptor2d_Curve2d.hxx* and implemented in source file *Adaptor2d_Curve2d.cxx*.
-
-This rule also applies to complex types constructed by instantiation of templates.
-Such types should be given own names using *typedef* statement, located in same-named header file.
-
-For example, see definition in the file *TColStd_IndexedDataMapOfStringString.hxx*:
-~~~~~
-typedef NCollection_IndexedDataMap<TCollection_AsciiString,TCollection_AsciiString,TCollection_AsciiString> TColStd_IndexedDataMapOfStringString;
-~~~~~
-
-### Names of functions
-
-The term **function** here is defined as:
-- Any class method
-- Any package method
-- Any non-member procedure or function
-
-It is preferred to start names of public methods from an upper case character and to start names of protected and private methods from a lower case character.
-
-
-~~~~~{.cpp}
-class MyPackage_MyClass
-{
-
-public:
-
- Standard_Integer Value() const;
- void SetValue (const Standard_Integer theValue);
-
-private:
-
- void setIntegerValue (const Standard_Integer theValue);
-
-};
-~~~~~
-
-@subsection occt_coding_rules_2_3 Names of variables
-
-There are several rules that describe currently accepted practices for naming variables.
-
-### Naming of variables
-
-Name of a variable should not conflict with the existing or possible global names (for packages, macros, functions, global variables, etc.).
-
-The name of a variable should not start with an underscore.
-
-See the following examples:
-
-~~~~~{.cpp}
-Standard_Integer Elapsed_Time = 0; // this is bad - possible class name
-Standard_Integer gp = 0; // this is bad - existing package name
-Standard_Integer aGp = 0; // this is OK
-Standard_Integer _KERNEL = 0; // this is bad
-Standard_Integer THE_KERNEL = 0; // this is OK
-~~~~~
-
-### Names of function parameters
-
-The name of a function (procedure, class method) parameter should start with prefix *the* followed by the meaningful part of the name starting with a capital letter.
-
-See the following examples:
-
-~~~~~{.cpp}
-void Package_MyClass::MyFunction (const gp_Pnt& p); // this is bad
-void Package_MyClass::MyFunction (const gp_Pnt& theP); // this is OK
-void Package_MyClass::MyFunction (const gp_Pnt& thePoint); // this is preferred
-~~~~~
-
-### Names of class member variables
-
-The name of a class member variable should start with prefix *my* followed by the meaningful of the name starting with a capital letter.
-
-See the following examples:
-
-~~~~~{.cpp}
-Standard_Integer counter; // This is bad
-Standard_Integer myC; // This is OK
-Standard_Integer myCounter; // This is preferred
-~~~~~
-
-### Names of global variables
-
-It is strongly recommended to avoid defining any global variables.
-However, as soon as a global variable is necessary, its name should be prefixed by the name of a class or a package where it is defined followed with <i>_my</i>.
-
-See the following examples:
-
-~~~~~{.cpp}
-Standard_Integer MyPackage_myGlobalVariable = 0;
-Standard_Integer MyPackage_MyClass_myGlobalVariable = 0;
-~~~~~
-
-Static constants within the file should be written in upper-case and begin with prefix *THE_*:
-~~~~~{.cpp}
-namespace
-{
- static const Standard_Real THE_CONSTANT_COEF = 3.14;
-};
-~~~~~
-
-### Names of local variables
-
-The name of a local variable should be distinguishable from the name of a function parameter, a class member variable and a global variable.
-
-It is preferred to prefix local variable names with *a* and *an* (or *is*, *to* and *has* for Boolean variables).
-
-See the following example:
-
-~~~~~{.cpp}
-Standard_Integer theI; // this is bad
-Standard_Integer i; // this is bad
-Standard_Integer index; // this is bad
-Standard_Integer anIndex; // this is OK
-~~~~~
-
-### Avoid dummy names
-Avoid dummy names, such as <i>i, j, k</i>. Such names are meaningless and easy to mix up.
-
-The code becomes more and more complicated when such dummy names are used there multiple times with different meanings, or in cycles with different iteration ranges, etc.
-
-See the following examples for preferred style:
-
-~~~~~{.cpp}
-void Average (const Standard_Real** theArray,
- Standard_Integer theRowsNb,
- Standard_Integer theRowLen,
- Standard_Real& theResult)
-{
- theResult = 0.0;
- for (Standard_Integer aRow = 0; aRow < aRowsNb; ++aRow)
- {
- for (Standard_Integer aCol = 0; aCol < aRowLen; ++aCol)
- {
- theResult += theArray[aRow][aCol];
- }
- theResult /= Standard_Real(aRowsNb * aRowLen);
- }
-}
-~~~~~
-
-@section occt_coding_rules_3 Formatting rules
-
-To improve the open source readability and, consequently, maintainability, the following set of rules is applied.
-
-### International language [MANDATORY]
-
-All comments in all sources must be in English.
-
-### Line length
-
-Try to stay within the limit of 120 characters per line in all sources.
-
-### C++ style comments
-
-Prefer C++ style comments in C++ sources.
-
-### Commenting out unused code
-
-Delete unused code instead of commenting it or using \#define.
-
-### Indentation in sources [MANDATORY]
-
-Indentation in all sources should be set to two space characters.
-Use of tabulation characters for indentation is disallowed.
-
-### Separating spaces
-
-Punctuation rules follow the rules of the English language.
-* C/C++ reserved words, commas, colons and semicolons should be followed by a space character if they are not at the end of a line.
-* There should be no space characters after '(' and before ')'. Closing and opening brackets should be separated by a space character.
-* For better readability it is also recommended to surround conventional operators by a space character.
-Examples:
-
-~~~~~{.cpp}
-while (true) // NOT: while( true ) ...
-{
- DoSomething (theA, theB, theC, theD); // NOT: DoSomething(theA,theB,theC,theD);
-}
-for (anIter = 0; anIter < 10; ++anIter) // NOT: for (anIter=0;anIter<10;++anIter){
-{
- theA = (theB + theC) * theD; // NOT: theA=(theB+theC)*theD
-}
-~~~~~
-
-### Declaration of pointers and references
-
-In declarations of simple pointers and references put asterisk (*) or ampersand (&) right after the type without extra space.
-
-Since declaration of several variables with mixed pointer types contrudicts this rule, it should be avoided. Instead, declare each variable independently with fully qualified type.
-
-Examples:
-
-~~~~~{.cpp}
-Standard_Integer *theVariable; // not recommended
-Standard_Integer * theVariable; // not recommended
-Standard_Integer* theVariable; // this is OK
-
-Standard_Integer *&theVariable; // not recommended
-Standard_Integer *& theVariable; // not recommended
-Standard_Integer*& theVariable; // this is OK
-
-Standard_Integer **theVariable; // not recommended
-Standard_Integer ** theVariable; // not recommended
-Standard_Integer** theVariable; // this is OK
-
-Standard_Integer *theA, theB, **theC; // not recommended (declare each variable independently)
-~~~~~
-
-### Separate logical blocks
-
-Separate logical blocks of code with one blank line and comments.
-
-See the following example:
-
-~~~~~{.cpp}
-// check arguments
-Standard_Integer anArgsNb = argCount();
-if (anArgsNb < 3 || isSmthInvalid)
-{
- return THE_ARG_INVALID;
-}
-
-// read and check header
-...
-...
-
-// do our job
-...
-...
-~~~~~
-
-Notice that multiple blank lines should be avoided.
-
-### Separate function bodies [MANDATORY]
-
-Use function descriptive blocks to separate function bodies from each other.
-Each descriptive block should contain at least a function name and purpose description.
-
-See the following example:
-
-~~~~~{.cpp}
-// =======================================================================
-// function : TellMeSmthGood
-// purpose : Gives me good news
-// =======================================================================
-void TellMeSmthGood()
-{
- ...
-}
-
-// =======================================================================
-// function : TellMeSmthBad
-// purpose : Gives me bad news
-// =======================================================================
-void TellMeSmthBad()
-{
- ...
-}
-~~~~~
-
-### Block layout [MANDATORY]
-Figure brackets <i>{ }</i> and each operator <i>(for, if, else, try, catch)</i> should be written on a dedicated line.
-
-In general, the layout should be as follows:
-
-~~~~~{.cpp}
-while (expression)
-{
- ...
-}
-~~~~~
-
-Entering a block increases and leaving a block decreases the indentation by one tabulation.
-
-### Single-line operators
-
-Single-line conditional operators <i>(if, while, for,</i> etc.) can be written without brackets on the following line.
-
-~~~~~{.cpp}
-if (!myIsInit) return Standard_False; // bad
-
-if (thePtr == NULL) // OK
- return Standard_False;
-
-if (!theAlgo.IsNull()) // preferred
-{
- DoSomething();
-}
-~~~~~
-
-Having all code in the same line is less convenient for debugging.
-
-### Comparison expressions with constants
-
-In comparisons, put the variable (in the current context) on the left side and constant on the right side of expression.
-That is, the so called "Yoda style" is to be avoided.
-
-~~~~~{.cpp}
-if (NULL != thePointer) // Yoda style, not recommended
-if (thePointer != NULL) // OK
-
-if (34 < anIter) // Yoda style, not recommended
-if (anIter > 34) // OK
-
-if (theNbValues >= anIter) // bad style (constant function argument vs. local variable)
-if (anIter <= theNbValues) // OK
-
-if (THE_LIMIT == theValue) // bad style (global constant vs. variable)
-if (theValue == THE_LIMIT) // OK
-~~~~~
-
-### Alignment
-
-Use alignment wherever it enhances the readability. See the following example:
-
-~~~~~{.cpp}
-MyPackage_MyClass anObject;
-Standard_Real aMinimum = 0.0;
-Standard_Integer aVal = theVal;
-switch (aVal)
-{
- case 0: computeSomething(); break;
- case 12: computeSomethingElse (aMinimum); break;
- case 3:
- default: computeSomethingElseYet(); break;
-}
-~~~~~
-
-### Indentation of comments
-
-Comments should be indented in the same way as the code to which they refer or they can be in the same line if they are short.
-
-The text of the comment should be separated from the slash character by a single space character.
-
-See the following example:
-
-~~~~~{.cpp}
-while (expression) //bad comment
-{
- // this is a long multi-line comment
- // which is really required
- DoSomething(); // maybe, enough
- DoSomethingMore(); // again
-}
-~~~~~
-
-### Early return statement
-
-Use an early return condition rather than collect indentations.
-
-Write like this:
-
-~~~~~{.cpp}
-Standard_Integer ComputeSumm (const Standard_Integer* theArray,
- const Standard_Size theSize)
-{
- Standard_Integer aSumm = 0;
- if (theArray == NULL || theSize == 0)
- {
- return 0;
- }
-
- ... computing summ ...
- return aSumm;
-}
-~~~~~
-
-Rather than:
-
-~~~~~{.cpp}
-Standard_Integer ComputeSumm (const Standard_Integer* theArray,
- const Standard_Size theSize)
-{
- Standard_Integer aSumm = 0;
- if (theArray != NULL && theSize != 0)
- {
- ... computing summ ...
- }
- return aSumm;
-}
-~~~~~
-
-This helps to improve readability and reduce the unnecessary indentation depth.
-
-### Trailing spaces
-
-Trailing spaces should be removed whenever possible.
-Spaces at the end of a line are useless and do not affect functionality.
-
-### Headers order
-
-Split headers into groups: system headers, headers per each framework, project headers; sort the list of includes alphabetically.
-Within the class source file, the class header file should be included first.
-
-This rule improves readability, allows detecting useless multiple header inclusions and makes 3rd-party dependencies clearly visible.
-Inclusion of class header on top verifies consistency of the header (e.g. that header file does not use any undefined declarations due to missing includes of dependencies).
-
-An exception to the rule is ordering system headers generating a macros declaration conflicts (like "windows.h" or "X11/Xlib.h") - these headers should be placed in the way solving the conflict.
-
-The source or header file should include only minimal set of headers necessary for compilation, without duplicates (considering nested includes).
-
-~~~~~{.cpp}
-// the header file of implemented class
-#include <PackageName_ClassName.hxx>
-
-// OCCT headers
-#include <gp_Pnt.hxx>
-#include <gp_Vec.hxx>
-#include <NCollection_List.hxx>
-
-// Qt headers
-#include <QDataStream>
-#include <QString>
-
-// system headers
-#include <iostream>
-#include <windows.h>
-~~~~~
-
-@section occt_coding_rules_4 Documentation rules
-
-The source code is one of the most important references for documentation.
-The comments in the source code should be complete enough to allow understanding the corresponding code and to serve as basis for other documents.
-
-The main reasons why the comments are regarded as documentation and should be maintained are:
-- The comments are easy to reach -- they are always together with the source code;
-- It is easy to update a description in the comment when the source is modified;
-- The source by itself is a good context to describe various details that would require much more explanations in a separate document;
-- As a summary, this is the most cost-effective documentation.
-
-The comments should be compatible with Doxygen tool for automatic documentation generation (thus should use compatible tags).
-
-### Documenting classes [MANDATORY]
-
-Each class should be documented in its header file (.hxx).
-The comment should give enough details for the reader to understand the purpose of the class and the main way of work with it.
-
-### Documenting class methods [MANDATORY]
-
-Each class or package method should be documented in the header file (.hxx).
-
-The comment should explain the purpose of the method, its parameters, and returned value(s).
-Accepted style is:
-
-@verbatim
-//! Method computes the square value.
-//! @param theValue the input value
-//! @return squared value
-Standard_Export Standard_Real Square (Standard_Real theValue);
-@endverbatim
-
-### Documenting C/C++ sources
-
-It is very desirable to put comments in the C/C++ sources of the package/class.
-
-They should be detailed enough to allow any person to understand what each part of code does.
-
-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 @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.
-
-@section occt_coding_rules_5 Application design
-
-The following rules define the common style, which should be applied by any developer contributing to the open source.
-
-### Allow possible inheritance
-
-Try to design general classes (objects) keeping possible inheritance in mind.
-This rule means that the user who makes possible extensions of your class should not encounter problems of private implementation.
-Try to use protected members and virtual methods wherever you expect extensions in the future.
-
-### Avoid friend declarations
-
-Avoid using 'friend' classes or functions except for some specific cases (for example, iteration) 'Friend' declarations increase coupling.
-
-### Set/get methods
-
-Avoid providing set/get methods for all fields of the class.
-Intensive set/get functions break down encapsulation.
-
-### Hiding virtual functions [MANDATORY]
-
-Avoid hiding a base class virtual function by a redefined function with a different signature.
-Most of the compilers issue warning on this.
-
-### Avoid mixing error reporting strategies
-
-Try not to mix different error indication/handling strategies (exceptions or returned values) on the same application level.
-
-### Minimize compiler warnings [MANDATORY]
-
-When compiling the source pay attention to and try to minimize compiler warnings.
-
-### Avoid unnecessary inclusions
-
-Try to minimize compilation dependencies by removing unnecessary inclusions.
-
-@section occt_coding_rules_6 General C/C++ rules
-
-This section defines the rules for writing a portable and maintainable C/C++ source code.
-
-### Wrapping of global variables [MANDATORY]
-
-Use package or class methods returning reference to wrap global variables to reduce possible name space conflicts.
-
-### Avoid private members
-
-Use *protected* members instead of *private* wherever reasonable to enable future extensions.
-Use *private* fields if future extensions should be disabled.
-
-### Constants and inlines over defines [MANDATORY]
-
-Use constant variables (const) and inline functions instead of defines (\#define).
-
-### Avoid explicit numerical values [MANDATORY]
-
-Avoid usage of explicit numeric values. Use named constants and enumerations instead.
-Numbers produce difficulties for reading and maintenance.
-
-### Three mandatory methods
-
-If a class has a destructor, an assignment operator or a copy constructor, it usually needs the other two methods.
-
-### Virtual destructor
-
-A class with virtual function(s) ought to have a virtual destructor.
-
-### Overriding virtual methods
-
-Declaration of overriding method should contains specifiers "virtual" and "override"
-(using Standard_OVERRIDE alias for compatibility with old compilers).
-
-~~~~~{.cpp}
-class MyPackage_BaseClass
-{
-
-public:
-
- Standard_EXPORT virtual Standard_Boolean Perform();
-
-};
-
-class MyPackage_MyClass : public MyPackage_BaseClass
-{
-
-public:
-
- Standard_EXPORT virtual Standard_Boolean Perform() Standard_OVERRIDE;
-
-};
-~~~~~
-
-This makes class definition more clear (virtual methods become highlighted).
-
-Declaration of interface using pure virtual functions protects against
-incomplete inheritance at first level, but does not help when method is overridden multiple times within nested inheritance
-or when method in base class is intended to be optional.
-
-And here "override" specifier introduces additional protection against situations when interface changes might be missed
-(class might contain old methods which will be never called).
-
-### Default parameter value
-
-Do not redefine a default parameter value in an inherited function.
-
-### Use const modifier
-
-Use *const* modifier wherever possible (functions parameters, return values, etc.)
-
-### Usage of goto [MANDATORY]
-Avoid *goto* statement unless it is really needed.
-
-### Declaring variable in for() header
-
-Declare a cycle variable in the header of the *for()* statement if not used out of cycle.
-
-~~~~~{.cpp}
-Standard_Real aMinDist = Precision::Infinite();
-for (NCollection_Sequence<gp_Pnt>::Iterator aPntIter (theSequence);
- aPntIter.More(); aPntIter.Next())
-{
- aMinDist = Min (aMinDist, theOrigin.Distance (aPntIter.Value()));
-}
-~~~~~
-
-### Condition statements within zero
-
-Avoid usage of C-style comparison for non-boolean variables:
-
-~~~~~{.cpp}
-void Function (Standard_Integer theValue,
- Standard_Real* thePointer)
-{
- if (!theValue) // bad style - ambiguous logic
- {
- DoSome();
- }
-
- if (theValue == 0) // OK
- {
- DoSome();
- }
-
- if (thePointer != NULL) // OK, predefined NULL makes pointer comparison cleaner to reader
- { // (nullptr should be used instead as soon as C++11 will be available)
- DoSome2();
- }
-}
-~~~~~
-
-@section occt_coding_rules_7 Portability issues
-
-This chapter contains rules that are critical for cross-platform portability.
-
-### Provide code portability [MANDATORY]
-
-The source code must be portable to all platforms listed in the official 'Technical Requirements'.
-The term 'portable' here means 'able to be built from source'.
-
-The C++ source code should meet C++03 standard.
-Any usage of compiler-specific features or further language versions (for example, C++11, until all major compilers on all supported platforms implement all its features) should be optional (used only with appropriate preprocessor checks) and non-exclusive (an alternative implementation compatible with other compilers should be provided).
-
-### Avoid usage of global variables [MANDATORY]
-
-Avoid usage of global variables. Usage of global variables may cause problems when accessed from another shared library.
-
-Use global (package or class) functions that return reference to static variable local to this function instead of global variables.
-
-Another possible problem is the order of initialization of global variables defined in various libraries that may differ depending on platform, compiler and environment.
-
-### Avoid explicit basic types
-
-Avoid explicit usage of basic types (*int*, *float*, *double*, etc.), use Open CASCADE Technology types from package *Standard: Standard_Integer, Standard_Real, Standard_ShortReal, Standard_Boolean, Standard_CString* and others or a specific *typedef* instead.
-
-### Use *sizeof()* to calculate sizes [MANDATORY]
-
-Do not assume sizes of types. Use *sizeof()* instead to calculate sizes.
-
-### Empty line at the end of file [MANDATORY]
-
-In accordance with C++03 standard source files should be trailed by an empty line.
-It is recommended to follow this rule for any plain text files for consistency and for correct work of git difference tools.
-
-@section occt_coding_rules_8 Stability issues
-
-The rules listed in this chapter are important for stability of the programs that use Open CASCADE Technology libraries.
-
-### Use *OSD::SetSignal()* to catch exceptions
-
-When using Open CASCADE Technology in an application, call *OSD::SetSignal()* function when the application is initialized.
-
-This will install C handlers for run-time interrupt signals and exceptions, so that low-level exceptions (such as access violation, division by zero, etc.) will be redirected to C++ exceptions
-that use *try {...} catch (Standard_Failure) {...}* blocks.
-
-The above rule is especially important for robustness of modeling algorithms.
-
-### Cross-referenced handles
-
-Take care about cycling of handled references to avoid chains, which will never be freed. For this purpose, use a pointer at one (subordinate) side.
-
-See the following example:
-
-~~~~{.cpp}
- class Slave;
-
- class Master : public Standard_Transient
- {
- ...
- void SetSlave (const Handle(Slave)& theSlave)
- {
- mySlave = theSlave;
- }
- ...
- private:
- Handle(Slave) theSlave; // smart pointer
- ...
- }
-
- class Slave : public Standard_Transient
- {
- ...
- void SetMaster (const Handle(Master)& theMaster)
- {
- myMaster = theMaster.get();
- }
- ...
- private:
- Master* theMaster; // simple pointer
- ...
- }
-~~~~
-
-### C++ memory allocation
-
-In C++ use *new* and *delete* operators instead of *malloc()* and *free()*. Try not to mix different memory allocation techniques.
-
-### Match *new* and *delete* [MANDATORY]
-
-Use the same form of new and delete.
-
-~~~~~{.cpp}
-aPtr1 = new TypeA[n]; ... ; delete[] aPtr1;
-aPtr2 = new TypeB(); ... ; delete aPtr2;
-aPtr3 = Standard::Allocate (4096); ... ; Standard::Free (aPtr3);
-~~~~~
-
-### Methods managing dynamical allocation [MANDATORY]
-
-Define a destructor, a copy constructor and an assignment operator for classes with dynamically allocated memory.
-
-### Uninitialized variables [MANDATORY]
-
-Every variable should be initialized.
-
-~~~~~{.cpp}
-Standard_Integer aTmpVar1; // bad
-Standard_Integer aTmpVar2 = 0; // OK
-~~~~~
-
-Uninitialized variables might be kept only within performance-sensitive code blocks and only when their initialization is guaranteed by subsequent code.
-
-### Do not hide global *new*
-
-Avoid hiding the global *new* operator.
-
-### Assignment operator
-
-In *operator=()* assign to all data members and check for assignment to self.
-
-### Float comparison
-
-Don't check floats for equality or non-equality; check for GT, GE, LT or LE.
-
-~~~~~{.cpp}
-if (Abs (theFloat1 - theFloat2) < theTolerance)
-{
- DoSome();
-}
-~~~~~
-
-Package *Precision* provides standard values for SI units and widely adopted by existing modeling algorithms:
-
-- *Precision::Confusion()* for lengths in meters;
-- *Precision::Angular()* for angles in radians.
-
-as well as definition of infinite values within normal range of double precision:
-- *Precision::Infinite()*
-- *Precision::IsInfinite()*
-- *Precision::IsPositiveInfinite()*
-- *Precision::IsNegativeInfinite()*
-
-### Non-indexed iteration
-
-Avoid usage of iteration over non-indexed collections of objects.
-If such iteration is used, make sure that the result of the algorithm does not depend on the order of iterated items.
-
-Since the order of iteration is unpredictable in case of a non-indexed collection of objects, it frequently leads to different behavior of the application from one run to another, thus embarrassing the debugging process.
-
-It mostly concerns mapped objects for which pointers are involved in calculating the hash function. For example, the hash function of *TopoDS_Shape* involves the address of *TopoDS_TShape* object. Thus the order of the same shape in the *TopTools_MapOfShape* will vary in different sessions of the application.
-
-### Do not throw in destructors
-
-Do not throw from within a destructor.
-
-### Assigning to reference [MANDATORY]
-
-Avoid the assignment of a temporary object to a reference. This results in a different behavior for different compilers on different platforms.
-
-@section occt_coding_rules_9 Performance issues
-
-These rules define the ways of avoiding possible loss of performance caused by ineffective programming.
-
-### Class fields alignment
-
-Declare fields of a class in the decreasing order of their size for better alignment.
-Generally, try to reduce misaligned accesses since they impact the performance (for example, on Intel machines).
-
-### Fields initialization order [MANDATORY]
-
-List class data members in the constructor's initialization list in the order they are declared.
-
-~~~~~{.cpp}
-class MyPackage_MyClass
-{
-
-public:
-
- MyPackage_MyClass()
- : myPropertyA (1),
- myPropertyB (2) {}
-
-// NOT
-// : myPropertyB (2),
-// myPropertyA (1) {}
-
-private:
-
- Standard_Integer myPropertyA;
- Standard_Integer myPropertyB;
-
-};
-~~~~~
-
-### Initialization over assignment
-
-Prefer initialization over assignment in class constructors.
-
-~~~~~{.cpp}
-MyPackage_MyClass()
-: myPropertyA (1) // preferred
-{
- myPropertyB = 2; // not recommended
-}
-~~~~~
-
-### Optimize caching
-
-When programming procedures with extensive memory access, try to optimize them in terms of cache behavior. Here is an example of how the cache behavior can be impacted:
-
-On x86 this code
-
-~~~~~{.cpp}
-Standard_Real anArray[4096][2];
-for (Standard_Integer anIter = 0; anIter < 4096; ++anIter)
-{
- anArray[anIter][0] = anArray[anIter][1];
-}
-~~~~~
-
-is more efficient then
-
-~~~~~{.cpp}
-Standard_Real anArray[2][4096];
-for (Standard_Integer anIter = 0; anIter < 4096; ++anIter)
-{
- anArray[0][anIter] = anArray[1][anIter];
-}
-~~~~~
-
-since linear access does not invalidate cache too often.
-
-@section occt_coding_rules_10 Draw Harness command
-
-Draw Harness provides TCL interface for OCCT algorithms.
-
-There is no TCL wrapper over OCCT C++ classes, instead interface is provided through the set of TCL commands implemented in C++.
-
-There is a list of common rules which should be followed to implement well-formed Draw Harness command.
-
-### Return value
-
-Command should return 0 in most cases even if the executed algorithm has failed. Returning 1 would lead to a TCL exception, thus should be used in case of a command line syntax error and similar issues.
-
-### Validate input parameters
-
-Command arguments should be validated before usage. The user should see a human-readable error description instead of a runtime exception from the executed algorithm.
-
-### Validate the number of input parameters
-
-Command should warn the user about unknown arguments, including cases when extra parameters have been pushed for the command with a fixed number of arguments.
-
-~~~~~{.cpp}
- if (theArgsNb != 3)
- {
- std::cout << "Syntax error - wrong number of arguments!\n";
- return 1;
- }
-
- Standard_Integer anArgIter = 1;
- Standard_CString aResName = theArgVec[anArgIter++];
- Standard_CString aFaceName = theArgVec[anArgIter++];
- TopoDS_Shape aFaceShape = DBRep::Get (aFaceName);
- if (aFaceShape.IsNull()
- || aFaceShape.ShapeType() != TopAbs_FACE)
- {
- std::cout << "Shape " << aFaceName << " is empty or not a Face!\n";
- return 1;
- }
- DBRep::Set (aResName, aFaceShape);
- return 0;
-~~~~~
-
-### Message printing
-
-Informative messages should be printed into standard output *std::cout*, whilst command results (if any) -- into Draw Interpreter.
-
-Information printed into Draw Interpreter should be well-structured to allow usage in TCL script.
-
-### Long list of arguments
-
-Any command with a long list of obligatory parameters should be considered as ill-formed by design.
-Optional parameters should start with flag name (with '-' prefix) and followed by its values:
-
-~~~~~{.tcl}
-myCommand -flag1 value1 value2 -flag2 value3
-~~~~~
-
-### Arguments parser
-
-- Integer values should be read using *Draw::Atoi()* function.
-- Real values should be read using *Draw::Atof()* function.
-- Flags names should be checked in case insensitive manner.
-
-Functions *Draw::Atof()* and *Draw::Atoi()* support expressions and read values in C-locale.
-
-~~~~~{.cpp}
- Standard_Real aPosition[3] = {0.0, 0.0, 0.0};
- for (Standard_Integer anArgIter = 1; anArgIter < theArgsNb; ++anArgIter)
- {
- Standard_CString anArg = theArgVec[anArgIter];
- TCollection_AsciiString aFlag (anArg);
- aFlag.LowerCase(); //!< for case insensitive comparison
- if (aFlag == "position")
- {
- if ((anArgIt + 3) >= theArgsNb)
- {
- std::cerr << "Wrong syntax at argument '" << anArg << "'!\n";
- return 1;
- }
- aPosition[0] = Draw::Atof (theArgVec[++anArgIt]);
- aPosition[1] = Draw::Atof (theArgVec[++anArgIt]);
- aPosition[2] = Draw::Atof (theArgVec[++anArgIt]);
- }
- else
- {
- std::cout << "Syntax error! Unknown flag '" << anArg << "'\n";
- return 1;
- }
- }
-~~~~~
-
-@section occt_coding_rules_11 Examples
-
-### Sample documented class
-
-@verbatim
-class Package_Class
-{
-
-public: //! @name public methods
-
- //! Method computes the square value.
- //! @param theValue the input value
- //! @return squared value
- Standard_Export Standard_Real Square (const Standard_Real theValue);
-
-private: //! \@name private methods
-
- //! Auxiliary method
- void increment();
-
-private: //! \@name private fields
-
- Standard_Integer myCounter; //!< usage counter
-
-};
-
-
-@endverbatim
-
-~~~~~
-#include <Package_Class.hxx>
-// ==========================================================
-// function : Square
-// purpose : Method computes the square value
-// ==========================================================
-Standard_Real Package_Class::Square (const Standard_Real theValue)
-{
- increment();
- return theValue * theValue;
-}
-
-// ==========================================================
-// function : increment
-// purpose :
-// ==========================================================
-void Package_Class::increment()
-{
- ++myCounter;
-}
-~~~~~
-
-### TCL script for Draw Harness
-
-~~~~~{.tcl}
-# show fragments (solids) in shading with different colors
-proc DisplayColored {theShape} {
- set aSolids [uplevel #0 explode $theShape so]
- set aColorIter 0
- set THE_COLORS {red green blue1 magenta1 yellow cyan1 brown}
- foreach aSolIter $aSolids {
- uplevel #0 vdisplay $aSolIter
- uplevel #0 vsetcolor $aSolIter [lindex $THE_COLORS [expr [incr aColorIter] % [llength $THE_COLORS]]]
- uplevel #0 vsetdispmode $aSolIter 1
- uplevel #0 vsetmaterial $aSolIter plastic
- uplevel #0 vsettransparency $aSolIter 0.5
- }
-}
-
-# load modules
-pload MODELING VISUALIZATION
-
-# create boxes
-box bc 0 0 0 1 1 1
-box br 1 0 0 1 1 2
-compound bc br c
-
-# show fragments (solids) in shading with different colors
-vinit View1
-vclear
-vaxo
-vzbufftrihedron
-DisplayColored c
-vfit
-vdump $imagedir/${casename}.png 512 512
-~~~~~
-
-### GLSL program:
-~~~~~{.fs}
-vec3 Ambient; //!< Ambient contribution of light sources
-vec3 Diffuse; //!< Diffuse contribution of light sources
-vec3 Specular; //!< Specular contribution of light sources
-
-//! Computes illumination from light sources
-vec4 ComputeLighting (in vec3 theNormal,
- in vec3 theView,
- in vec4 thePoint)
-{
- // clear the light intensity accumulators
- Ambient = occLightAmbient.rgb;
- Diffuse = vec3 (0.0);
- Specular = vec3 (0.0);
- vec3 aPoint = thePoint.xyz / thePoint.w;
- for (int anIndex = 0; anIndex < occLightSourcesCount; ++anIndex)
- {
- int aType = occLight_Type (anIndex);
- if (aType == OccLightType_Direct)
- {
- directionalLight (anIndex, theNormal, theView);
- }
- else if (aType == OccLightType_Point)
- {
- pointLight (anIndex, theNormal, theView, aPoint);
- }
- }
-
- return vec4 (Ambient, 1.0) * occFrontMaterial_Ambient()
- + vec4 (Diffuse, 1.0) * occFrontMaterial_Diffuse()
- + vec4 (Specular, 1.0) * occFrontMaterial_Specular();
-}
-
-//! Entry point to the Fragment Shader
-void main()
-{
- gl_FragColor = computeLighting (normalize (Normal),
- normalize (View),
- Position);
-}
-~~~~~
+++ /dev/null
-Contribution Workflow {#occt_dev_guides__contribution_workflow}
-====================================
-@tableofcontents
-
-@section occt_contribution_intro Introduction
-
-The purpose of this document is to describe standard workflow for processing contributions to certified version of OCCT.
-
-@subsection occt_contribution_intro_tracker Use of issue tracker system
-
-Each contribution should have corresponding issue (bug, or feature, or integration request)
-registered in the MantisBT issue tracker system accessible by URL
-https://tracker.dev.opencascade.org.
-The issue is processed according to the described workflow.
-
-@subsection occt_contribution_intro_access Access levels
-
-Access level defines the permissions of the user to view, register and modify issues in the issue tracker.
-The correspondence of access level and user permissions is defined in the table below.
-
-| Access level | Granted to | Permissions | Can set statuses |
-|:------------- | :--------- | :-------------- | :----------------------- |
-| Viewer | Everyone (anonymous access) | View public issues only | None |
-| Updater | Users registered on dev.opencascade.org, in Open CASCADE project | View and comment issues | None |
-| Reporter | Users registered on dev.opencascade.org, in Community project | View, report, and comment issues | New, Resolved, Feedback |
-| Developer | OCC developers and (in Community project) external contributors who signed the CLA | View, report, modify, and handle issues | New, Assigned, Resolved, Reviewed, Feedback |
-| Tester | OCC engineer devoted to certification testing | View, report, modify, and handle issues | Assigned, Tested, Feedback |
-| Maintainer | Person responsible for a project or OCCT component | View, report, modify, and handle issues | New, Resolved, Reviewed, Tested, Closed, Feedback |
-| Bugmaster | Person responsible for Mantis issue tracker, integrations, certification, and releases | Full access | All statuses |
-
-According to his access level, the user can participate in the issue handling process under different roles, as described below.
-
-@section occt_contribution_workflow Standard workflow for an issue
-
-@subsection occt_contribution_workflow_general General scheme
-
-<center>
-@figure{OCCT_ContributionWorkflow_V3_image001.svg,"Standard life cycle of an issue",360}
-</center>
-
-@subsection occt_contribution_workflow_issue Issue registration
-
-An issue is registered in Mantis bugtracker by the **Reporter** with definition of the necessary attributes (see also @ref occt_contribution_app):
-
-**Category** -- indicates the OCCT component, to which the issue relates.
- (If in doubt, assign to OCCT:Foundation Classes.)
-
-**Severity** -- indicates the impact of the issue in the context where it was discovered.
-
-**Profile** -- specifies the configuration, on which the problem was detected.
-For specific configurations it is possible to specify separately platform, OS, and version.
-These fields can be left empty if the issue is not configuration-specific.
-Additional details relevant for the environment where the issue is reproduced (such as compiler version, bitness, etc.) can be provided in the **Description**.
-
-**Products Version** -- defines the OCCT version, on which the problem has been detected.
-
-It is preferable to indicate the version of the earliest known official release where the problem can be reproduced.
-If the issue is reported on the current development version of OCCT, the current development version should be used (for convenience, this version is marked by asterisk in Mantis).
-
-@note OCCT version number can be consulted in the file Standard_Version.hxx (value of OCC_VERSION_COMPLETE macro).
-
-**Assign to** -- developer to whom the issue will be assigned.
- By default, it is set to **Maintainer** of the OCCT component selected in **Category** field.
-
-**Target Version** -- defines the target version for the fix to be provided.
- By default, it is set to the current version under development.
-
-**Summary** -- a short, one sentence description of the issue.
-
-The **Summary** has a limit of 128 characters.
-It should be informative and useful for the developers.
-It is not allowed to mention the issue originator, and in particular the customer, in the name of the registered issue.
-
-A good practice is to start the issue with indication of the relevant component (OCCT module, package, class etc.) to better represent its context.
-
-The summary should be given in imperative mood when it can be formulated as goal to be achieved or action to be done.
-In particular, this applies to feature requests and improvements, for instance:
-
-> *Visualization - provide a support of zoom persistent selection*
-
-If the issue reports a problem, the summary should be given in Present Simple.
-If reported problem is believed to be a regression, it is recommended to indicate this in the summary, like this:
-
-> [Regression in 6.9.0] *IGES - Export of a reversed face leads to wrong data*
-
-**Description** -- should contain a detailed definition of the nature of the registered issue depending on its type.
-
-For a bug it is required to submit a detailed description of the incorrect behavior, including the indication of the cause of the problem (if known at this stage), and details on the context where the issue has been detected.
-
-For a feature or integration request it is necessary to describe the proposed feature in details (as much as possible at that stage), including the changes required for its implementation and the main features of the new functionality.
-
-Example:
-
-> *Currently selection does not work correctly for non-zoomable objects (those defined using transform persistence). To provide correct selection for such objects, first-level (object) BVH structures must be updated on each camera change, and frustum must be rebuilt accordingly.*
-
-@note In the description and notes to the issues you can refer to another issue by its ID prefixed by number sign (e.g.: #12345), and refer to a note by its ID prefixed by tilde (e.g.: ~20123).
-These references will be expanded by Mantis into links to the corresponding issue or note.
-When the number sign or the tilde followed by digits are a part of a normal text, add a space before digits (e.g.: "face # 12345 contains ~ 1000 edges") to avoid this conversion.
-
-**Steps To Reproduce** -- allows describing in detail how to reproduce the issue.
-
-This information is crucial for the developer to investigate the cause of the problem and to create the test case.
-The optimal approach is to give a sequence of @ref occt_user_guides__test_harness "DRAW Test Harness" commands to reproduce the problem in DRAW.
-This information can also be provided as a DRAW Tcl script attached to the issue (in **Upload File** field).
-
-**Additional information and documentation updates** -- any additional information, remarks to be taken into account in Release Notes, etc..
-
-**Upload File** -- allows attaching the shapes, snapshots, scripts, documents, or modified source files of OCCT.
-
-This field can be used to attach a prototype test case in form of a Tcl script for DRAW, a C++ code which can be organized in DRAW commands, sample shapes, documents describing proposed change or analysis of the problem, or other data required for reproduction of the issue.
-Where applicable, pictures demonstrating a problem and/or desired result can be attached.
-
-The newly registered issue gets status **NEW** and is assigned to the person indicated in the **Assign to** field.
-
-@subsection occt_contribution_workflow_assign Assigning the issue
-
-The description of the new issue is checked by the **Maintainer** and if it is feasible, he may assign the issue to a **Developer**.
-Alternatively, any user with **Developer** access level or higher can assign the issue to himself if he wants to provide a solution.
-
-The recommended way to handle contributions is that the **Reporter** assigns the issue to himself and provides a solution.
-
-The **Maintainer** or **Bugmaster** can close or reassign the issue (in **FEEDBACK** state) to the **Reporter** after it has been registered, if its description does not contain sufficient details to reproduce the bug or explain the need of the new feature.
-That decision shall be documented in the comments to the issue in the Bugtracker.
-
-The assigned issue has status **ASSIGNED**.
-
-@subsection occt_contribution_workflow_fix Resolving the issue
-
-The **Developer** responsible for the issue assigned to him provides a solution including:
-
-* Changes in the code, with appropriate comments;
-* Test case (when applicable) and data necessary for its execution;
-* Changes in the user and developer guides (when necessary).
-
-The change is integrated to branch named CRxxxxx (where **xxxxx** is issue number) in the OCCT Git repository, based on current master, and containing a single commit with the appropriate description.
-Then the issue is switched to **RESOLVED** for further review and testing.
-
-The following sub-sections describe this process, relevant requirements and options, in more details.
-
-@subsubsection occt_contribution_workflow_fix_code Requirements to the code modification
-
-The amount of code affected by the change should be limited to the changes required for the bug fix or improvement.
-Change of layout or re-formatting of the existing code is allowed only in the parts where meaningful changes related to the issue have been made.
-
-@note If deemed useful, re-formatting or cosmetic changes affecting considerable parts of the code can be made within a dedicated issue.
-
-The changes should comply with the OCCT @ref occt_dev_guides__coding_rules "Codng Rules".
-It is especially important to comment the code properly so that other people can understand it easier.
-
-The modification should be tested by running OCCT tests (on the platform and scope available to **Developer**) and ensuring absence of regressions.
-In case if modification affects results of some existing test case and the new result is correct, such test case should be updated to report OK (or BAD), as descibed in @ref testmanual_details_results "Automated Test System / Interpretation of Test Results".
-
-@subsubsection occt_contribution_workflow_fix_test Providing a test case
-
-For modifications affecting OCCT functionality, a test case should be created (unless already exists) and included in the commit or patch.
-See @ref testmanual_intro_quick_create "Automated Test System / Creating a New Test" for relevant instructions.
-
-The data files required for a test case should be attached to the corresponding issue in Mantis (i.e. not included in the commit).
-
-When the test case cannot be provided for any reason, the maximum possible information on how the problem can be reproduced and how to check the fix should be provided in the **Steps to Reproduce** field of an issue.
-
-@subsubsection occt_contribution_workflow_fix_doc Updating user and developer guides
-
-If the change affects a functionality described in @ref user_guides "User Guides", the corresponding user guide should be updated to reflect the change.
-
-If the change affects OCCT test system, build environment, or development tools described in @ref dev_guides "Developer Guides", the corresponding guide should be updated.
-
-The changes that break compatibility with the previous versions of OCCT (i.e. affecting API or behavior of existing functionality in the way that may require update of existing applications based on an earlier official release of OCCT to work correctly) should be described in the document @ref occt_dev_guides__upgrade "Upgrade from previous OCCT versions".
-It is recommended to add a sub-section for each change described.
-The description should provide the explanation of the incompatibility introduced by the change, and describe how it can be resolved (at least, in known situations).
-When feasible, the automatic upgrade procedure (adm/upgrade.tcl) can be extended by a new option to perform the required upgrade of the dependent code automatically.
-
-@subsubsection occt_contribution_workflow_fix_git Submission of change as a Git branch
-
-The modification of sources should be provided in the dedicated branch of the official OCCT Git repository.
-
-The branch should contain a single commit, with the appropriate commit message (see @ref occt_contribution_workflow_fix_commit "Requirements to the commit message" below).
-
-In general, this branch should be based on the recent version of the master branch.
-It is highly preferable to submit changes basing on the current master.
-In case if the fix is implemented on the previous release of OCCT, the branch can be based on the corresponding tag in Git, instead of the master.
-
-The branch name should be composed of letters **CR** (abbreviation of "Change Request") followed by the issue ID number (without leading zeros).
-It is possible to add an optional suffix to the branch name after the issue ID, e.g. to distinguish between several versions of the fix (see @ref occt_contribution_nonstd_rebase).
-
-See @ref occt_dev_guides__git_guide "Guide to using GIT" for help.
-
-@note When a branch with the name given according to the above rule is pushed to Git, a note is automatically added to the corresponding issue in Mantis, indicating the person who has made the push, the commit hash, and (for new commits) the description.
-
-@subsubsection occt_contribution_workflow_fix_commit Requirements to the commit message
-
-The commit message posted in Git constitutes an integral part of both the fix and the release documentation.
-
-The first line of the commit message should contain the Summary of the issue (starting with its ID followed by colon, e.g. "0022943: Bug in TDataXtd_PatternStd"), followed by an empty line.
-
-The following lines should provide a description of the context and details on the changes made.
-The contents and the recommended structure of the description depend on the nature of the bug.
-
-In a general case, the following elements should be present:
-* **Problem** -- a description of the unwanted behavior;
-* **Change** -- a description of the implemented changes, including the names of involved classes / methods / enumerations etc.;
-* **Result** -- a description of the current behavior (after the implementation).
-
-Example:
-
-> *0026330: BRepOffsetAPI_ThruSections creates invalid shape.*
->
-> *Methods BRep_Tool::CurveOnSurface() and BRepCheck_Edge::InContext() now properly handle parametric range on a 3D curve when it is used to generate a p-curve dynamically (on a planar surface) and both the surface and the 3D curve have non-null locations.*
-
-Provide sufficient context so that potential user of the affected functionality can understand what has been changed and how the algorithm works now.
-Describe reason and essence of the changes made, but do not go too deep into implementation details -- these should be reflected in comments in the code.
-
-@subsubsection occt_contribution_workflow_fix_resolve Marking issue as resolved
-
-To mark the change as ready for review and testing, the corresponding issue should be switched to **RESOLVED** state.
-By default, the issue gets assigned to the **Maintainer** of the component, who is thus responsible for its review.
-Alternatively, another person can be selected as a reviewer at this step.
-
-When the issue is switched to **RESOLVED**, it is required to update or fill the field **Steps to reproduce**.
-The possible variants are:
-
-* The name of an existing or new test case (preferred variant);
-* A sequence of DRAW commands;
-* N/A (Not required / Not possible / Not applicable);
-* Reference to an issue in the bug tracker of another project.
-
-@subsection occt_contribution_workflow_review Code review
-
-The **Reviewer** analyzes the proposed solution for applicability in accordance with OCCT @ref occt_dev_guides__coding_rules "Coding Rules" and examines all changes in the sources, test case(s), and documentation to detect obvious and possible errors, misprints, or violations of the coding style.
-
-If the Reviewer detects some problems, he can either:
-
-* Fix these issues and provide a new solution.
- The issue can then be switched to **REVIEWED**.
-
- In case of doubt or possible disagreement the **Reviewer** can reassign the issue (in **RESOLVED** state) to the **Developer**, who then becomes a **Reviewer**.
- Possible disagreements should be resolved through discussion, which is done normally within issue notes (or on the OCCT developer’s forum if necessary).
-
-* Reassign the issue back to the **Developer**, providing detailed list of remarks. The issue then gets status **ASSIGNED** and a new solution should be provided.
-
-If Reviewer does not detect any problems, or provides a corrected version, he changes status to **REVIEWED**.
-The issue gets assigned to the **Bugmaster**.
-
-@subsection occt_contribution_workflow_test Testing
-
- The issues that are in **REVIEWED** state are subject of certification (non-regression) testing.
- The issue is assigned to an OCCT **Tester** when he starts processing it.
-
- If the branch submitted for testing is based on obsolete status of the master branch, **Tester** @ref occt_contribution_nonstd_rebase "rebases" it on master HEAD.
- In case of conflicts, the issue is assigned back to **Developer** in **FEEDBACK** status, requesting for a rebase.
-
- Certification testing includes:
- * Addition of new data models (if required for a new test case) to the data base;
- * Revision of the new test case(s) added by developer, and changes in the existing test cases included in commit.
- The **Tester** can amend tests to ensure their correct behavior in the certification environment.
- * Building OCCT on a sub-set of supported configurations (OS and compiler), watching for errors and warnings;
- * Execution of tests on sub-set of supported platforms (at least, one Windows and one Linux configuration), watching for regressions;
- * Building OCCT samples, watching for errors;
- * Building and testing of OCC products based on OCCT.
-
-If the **Tester** does not detect problems or regressions, he changes the status to **TESTED** for further integration.
-
-If the **Tester** detects build problems or regressions, he changes the status to **ASSIGNED** and reassigns the issue to the **Developer** with a detailed description of the problems.
-The **Developer** should analyze the reported problems and, depending on results of this analysis, either:
-* Confirm that the detected problems are expected changes and they should be accepted as a new status of the code. Then the issue should be switched to **FEEDBACK** and assigned to the **Bugmaster**.
-* Produce a new solution (see @ref occt_contribution_workflow_fix, and also @ref occt_contribution_nonstd_minor).
-
-@subsection occt_contribution_workflow_integrate Integration of a solution
-
-Before integration into the master branch of the repository the **Integrator** checks the following conditions:
- * the change has been reviewed;
- * the change has been tested without regressions (or with regressions treated properly);
- * the test case has been created for this issue (when applicable), and the change has been rechecked on this test case;
- * the change does not conflict with other changes integrated previously.
-
-If the result of check is successful the Integrator integrates the solution into the branch.
-The integrations are performed weekly; integration branches are named following the pattern IR-YYYY-MM-DD.
-
-Each change is integrated as a single commit without preserving the history of changes made in the branch (by rebase, squashing all intermediate commits if any), however, preserving the author when possible.
-This is done to have the master branch history plain and clean.
-The following picture illustrates the process:
-
-@figure{OCCT_ContributionWorkflow_V3_image002.png,"Integration of several branches",420}
-
-The new integration branch is tested against possible regressions that might appear due to interference between separate changes.
-When the tests are OK, the integration branch is pushed as the new master to the official repository.
-The issue status is set then to **VERIFIED** and is assigned to the **Reporter** so that he could check the fix as integrated.
-
-The branches corresponding to the integrated fixes are removed from the repository by the **Bugmaster**.
-
-@subsection occt_contribution_workflow_close Closing an issue
-
-When possible, the **Reporter** should check whether the problem is actually resolved in the environment where it has been discovered, after the fix is integrated to master.
-If the fix does not actually resolve the original problem, the issue in **VERIFIED** status can be reopened and assigned back to the **Developer** for rework.
-The details on how to check that the issue is still reproducible should be provided.
-However, if the issue does resolve the problem as described in the original report, but a similar problem is discovered for another input data or configuration, or the fix has caused a regression, that problem should be registered as a separate (@ref occt_contribution_nonstd_relate "related") issue.
-
-If the fix integrated to master causes regressions, **Bugmaster** can revert it and reopen the issue.
-
-The **Bugmaster** closes the issue after the regular OCCT Release, provided that the issue status is **VERIFIED** and the change was actually included in the release.
-The final issue state is **CLOSED**.
-
-The field **Fixed in Version** of the issue is set to the OCCT version where it is fixed.
-
-@section occt_contribution_nonstd Additional workflow elements
-
-@subsection occt_contribution_nonstd_feedback Requesting more information or specific action
-
-If, at any step of the issue lifetime, the person responsible for it cannot process it due to absence of required information, expertise, or rights, he can switch it to status **FEEDBACK** and assign to the person who is (presumably) able to resolve the block. Some examples of typical situations where **FEEDBACK** is used are:
-
-* The **Maintainer** or the **Developer** requests for more information from the **Reporter** to reproduce the issue;
-* The **Tester** requests the **Developer** or the **Maintainer** to help him in the interpretation of testing results;
-* The **Developer** or the **Maintainer** asks the **Bugmaster** to close the issue that is found irrelevant or already fixed (see @ref occt_contribution_nonstd_autofix).
-
-In general, issues with status **FEEDBACK** should be processed as fast as possible, to avoid unjustified delays.
-
-@subsection occt_contribution_nonstd_relate Defining relationships between issues
-
-When two or more issues are related to each other, this relationship should be reflected in the issue tracker.
-It is also highly recommended to add a note to explain the relationship.
-Typical cases of relationships are:
-
-* Issue A is caused by previous fix made for issue B (A is a child of B);
-* Issue A describes the same problem as issue B (A is a duplicate of B);
-* Issues A and B relate to the same piece of code, functionality etc., in the sense that the fix for one of these issues will affect the other (A is related to B)
-
-When the fix made for one issue also resolves another one, these issues should be marked as related or duplicate.
-In general, the duplicate issue should have the same status, and, when closed, be marked as fixed in the same OCCT version, as the main one.
-
-@subsection occt_contribution_nonstd_patch Submission of a change as a patch
-
-In some cases (if Git is not accessible for the contributor), external contributions can be submitted as a patch file (generated by *diff* command) or as modified sources attached to the Mantis issue.
-The OCCT version, for which the patch is generated, should be clearly specified (e.g. as hash code of Git commit if the patch is based on an intermediate state of the master).
-
-@note Such contributions should be put to Git by someone else (e.g. the **Reviewer**), this may cause delay in their processing.
-
-@subsection occt_contribution_nonstd_rebase Updating branches in Git
-
-Updates of the existing branch (e.g. taking into account the remarks of the **Reviewer**, or fixing regressions) should be provided as new commits on top of previous state of the branch.
-
-It is allowed to rebase the branch on the new state of the master and push it to the repository under the same name (with <i>--force</i> option) provided that the original sequence of commits is preserved.
-
-When a change is squashed into a single commit (e.g. to be submitted for review), it should be pushed into a branch a with different name.
-
-The recommended approach is to add a numeric suffix (index) indicating the version of the change, e.g. "CR12345_5".
-Usually it is worth keeping a non-squashed branch in Git for reference.
-
-To avoid confusions, the branch corresponding to the latest version of the change should have a greater index.
-
-@note Make sure to revise the commit message after squashing a branch, to keep it meaningful and comprehensive.
-
-@subsection occt_contribution_nonstd_minor Minor corrections
-
-In some cases review remarks or results of testing require only minor corrections to be done in the branch containing a change.
-"Minor" implies that the correction does not impact the functionality and does not affect the description of the previously committed change.
-
-As an exception to general @ref occt_contribution_workflow_fix_git "single-commit rule", it is allowed to put such minor corrections on top of the existing branch as a separate commit, and re-submit it for further processing in the same branch, without squashing.
-
-Minor commits should have a single-line message starting with #.
-These messages will be ignored when the branch is squashed at integration.
-
-Typical cases of minor corrections are:
-
-* Amendments of test cases (including those made by the **Tester** to adjust a test script to a specific platform);
-* Trivial corrections of compilation warnings (such as removal of an unused variable);
-* Addition or correction of comments or documentation;
-* Corrections of code formatting (e.g. reversion of irrelevant formatting changes made in the main commit).
-
-@subsection occt_contribution_nonstd_autofix Handling non-reproducible issues
-
-Investigation of each issue starts with reproducing it on current development version (master).
-
-If it cannot be reproduced on the current master, but can be reproduced on one of previous releases (or previous state of the master), it is considered as solved by a change made for another issue.
-If that "fixing" issue can be identified (e.g. by parsing Git log), it should be set as related to that issue.
-The issue should be switched to **FEEDBACK** and assigned to the **Bugmaster** for further processing.
-
-The **Bugmaster** decides whether it is necessary to create a test case for that issue, and if so may assign it to the **Developer** or the **Tester** to create a test.
-The issue then follows the standard workflow.
-
-Otherwise, if the issue is fixed in one of previous releases, the **Bugmaster** closes it setting the appropriate value in **Fixed in Version** field, or, if the issue is fixed after the last release, switches it to **VERIFIED** status.
-
-If the issue cannot be reproduced due to an unclear description, missing data, etc., it should be assigned back to the **Reporter** in **FEEDBACK** status, requesting for more information.
-The **Reporter** should provide additional information within one month; after that time, if no new information is provided, the issue should be closed by the **Bugmaster** with resolution **Unable to reproduce**.
-
-@section occt_contribution_app Appendix: Issue attributes
-
-@subsection occt_contribution_app_category Category
-
-The category corresponds to the component of OCCT where the issue is found:
-
- | Category | Component |
- | :--------------------------- | :----------------------------------------------------- |
- | OCCT:Foundation Classes | Foundation Classes module |
- | OCCT:Modeling Data | Modeling Data classes |
- | OCCT:Modeling Algorithms | Modeling Algorithms, except shape healing and meshing |
- | OCCT:Shape Healing | Shape Healing component (TKShapeHealing) |
- | OCCT:Mesh | BRepMesh algorithm |
- | OCCT:Data Exchange | Data Exchange module |
- | OCCT:Visualization | Visualization module |
- | OCCT:Application Framework | OCAF |
- | OCCT:DRAW | DRAW Test Harness |
- | OCCT:Tests | Automatic Test System |
- | OCCT:Documentation | Documentation |
- | OCCT:Coding | General code quality |
- | OCCT:Configuration | Configuration, build system, etc. |
- | OCCT:Releases | Official OCCT releases |
- | Website:Tracker | OCCT Mantis issue tracker, tracker.dev.opencascade.org |
- | Website:Portal | OCCT development portal, dev.opencascade.org |
- | Website:Git | OCCT Git repository, git.dev.opencascade.org |
-
-
-@subsection occt_contribution_app_severity Severity
-
- Severity shows at which extent the issue affects the product.
- The list of used severities is given in the table below in the descending order.
-
- | Severity | Description |
- | :---------- | :------------------------------------------------ |
- | crash | Crash of the application or OS, loss of data |
- | block | Regression corresponding to the previously delivered official version. Impossible operation of a function on any data with no work-around. Missing function previously requested in software requirements specification. Destroyed data. |
- | major | Impossible operation of a function with existing work-around. Incorrect operation of a function on a particular dataset. Impossible operation of a function after intentional input of incorrect data. Incorrect behavior of a function after intentional input of incorrect data. |
- | minor | Incorrect behavior of a function corresponding to the description in software requirements specification. Insufficient performance of a function. |
- | tweak | Ergonomic inconvenience, need of light updates. |
- | text | Non-conformance of the program code to the Coding Rules, mistakes and non-functional errors in the source text (e.g. unnecessary variable declarations, missing comments, grammatical errors in user manuals). |
- | trivial | Cosmetic issues. |
- | feature | Request for a new feature or improvement. |
- | integration request | Requested integration of an existing feature into the product. |
- | just a question | A question to be processed, without need of any changes in the product. |
-
-@subsection occt_contribution_app_status Status
-
- The bug statuses that can be applied to the issues are listed in the table below.
-
- | Status | Description |
- | :------------------- | :----------------------------------------- |
- | New | A new, just registered issue. |
- | Acknowledged | Can be used to mark the issue as postponed. |
- | Confirmed | Can be used to mark the issue as postponed. |
- | Feedback | The issue requires more information or a specific action. |
- | Assigned | Assigned to a developer. |
- | Resolved | The issue has been fixed, and now is waiting for review. |
- | Reviewed | The issue has been reviewed, and now is waiting for testing (or being tested). |
- | Tested | The fix has been internally tested by the tester with success on the full non-regression database or its part and a test case has been created for this issue. |
- | Verified | The fix has been integrated into the master of the corresponding repository |
- | Closed + resolution | The fix has been integrated to the master. The corresponding test case has been executed successfully. The issue is no longer reproduced. |
-
-@subsection occt_contribution_app_resolution Resolution
-
- **Resolution** is set when the bug is closed. "Reopen" resolution is added automatically when the bug is reopened.
-
- | Resolution | Description |
- |:--------------------- | :--------------------------------------------------------------------------- |
- | Open | The issue is pending. |
- | Fixed | The issue has been successfully fixed. |
- | Reopened | The bug has been reopened because of insufficient fix or regression. |
- | Unable to reproduce | The bug is not reproduced. |
- | Not fixable | The bug cannot be fixed because e.g. it is a bug of third party software, OS or hardware limitation, etc. |
- | 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. |
- | No change required | The issue didn’t require any change of the product, such as a question issue.|
- | Suspended | The issue is postponed (for Acknowledged status). |
- | Documentation updated | The documentation has been updated to resolve a misunderstanding causing the issue. |
- | Won’t fix | It is decided to keep the existing behavior. |
-
+++ /dev/null
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!-- Created with Inkscape (http://www.inkscape.org/) -->
-
-<svg
- xmlns:dc="http://purl.org/dc/elements/1.1/"
- xmlns:cc="http://creativecommons.org/ns#"
- xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
- xmlns:svg="http://www.w3.org/2000/svg"
- xmlns="http://www.w3.org/2000/svg"
- xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
- xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
- width="447.27399"
- height="737.74353"
- id="svg2"
- version="1.1"
- inkscape:version="0.91 r13725"
- sodipodi:docname="OCCT_ContributionWorkflow_V3_image001.svg">
- <defs
- id="defs4">
- <clipPath
- id="clipEmfPath1"
- clipPathUnits="userSpaceOnUse">
- <rect
- id="rect2990"
- height="777.18896"
- width="607.5"
- y="0"
- x="0" />
- </clipPath>
- <clipPath
- id="clipEmfPath2"
- clipPathUnits="userSpaceOnUse">
- <rect
- id="rect2993"
- height="30.298595"
- width="44.849998"
- y="180.89162"
- x="255.075" />
- </clipPath>
- <clipPath
- id="clipEmfPath3"
- clipPathUnits="userSpaceOnUse">
- <rect
- id="rect2996"
- height="32.323502"
- width="60.674999"
- y="55.572422"
- x="131.625" />
- </clipPath>
- <clipPath
- id="clipEmfPath4"
- clipPathUnits="userSpaceOnUse">
- <rect
- id="rect2999"
- height="39.223183"
- width="106.8"
- y="148.79311"
- x="50.625" />
- </clipPath>
- <clipPath
- id="clipEmfPath5"
- clipPathUnits="userSpaceOnUse">
- <rect
- id="rect3002"
- height="22.198971"
- width="141.675"
- y="294.66135"
- x="61.875" />
- </clipPath>
- <clipPath
- id="clipEmfPath6"
- clipPathUnits="userSpaceOnUse">
- <rect
- id="rect3005"
- height="22.198971"
- width="141.675"
- y="15.074301"
- x="101.25" />
- </clipPath>
- <clipPath
- id="clipEmfPath7"
- clipPathUnits="userSpaceOnUse">
- <rect
- id="rect3008"
- height="21.224016"
- width="79.800003"
- y="46.722836"
- x="203.02499" />
- </clipPath>
- <clipPath
- id="clipEmfPath8"
- clipPathUnits="userSpaceOnUse">
- <rect
- id="rect3011"
- height="17.099207"
- width="90.074997"
- y="298.33618"
- x="202.05" />
- </clipPath>
- <clipPath
- id="clipEmfPath9"
- clipPathUnits="userSpaceOnUse">
- <rect
- id="rect3014"
- height="40.423126"
- width="74.550003"
- y="165.51733"
- x="124.35" />
- </clipPath>
- <clipPath
- id="clipEmfPath10"
- clipPathUnits="userSpaceOnUse">
- <rect
- id="rect3017"
- height="21.224016"
- width="79.800003"
- y="76.346458"
- x="51.150002" />
- </clipPath>
- <clipPath
- id="clipEmfPath11"
- clipPathUnits="userSpaceOnUse">
- <rect
- id="rect3020"
- height="30.298595"
- width="75.224998"
- y="585.49786"
- x="257.85001" />
- </clipPath>
- <clipPath
- id="clipEmfPath12"
- clipPathUnits="userSpaceOnUse">
- <rect
- id="rect3023"
- height="22.198971"
- width="133.05"
- y="664.01923"
- x="32.775002" />
- </clipPath>
- <clipPath
- id="clipEmfPath13"
- clipPathUnits="userSpaceOnUse">
- <rect
- id="rect3026"
- height="22.723946"
- width="166.875"
- y="490.17728"
- x="252.14999" />
- </clipPath>
- <clipPath
- id="clipEmfPath14"
- clipPathUnits="userSpaceOnUse">
- <rect
- id="rect3029"
- height="22.198971"
- width="114.3"
- y="441.42953"
- x="60" />
- </clipPath>
- <clipPath
- id="clipEmfPath15"
- clipPathUnits="userSpaceOnUse">
- <rect
- id="rect3032"
- height="22.198971"
- width="174.60001"
- y="558.27411"
- x="300.45001" />
- </clipPath>
- <clipPath
- id="clipEmfPath16"
- clipPathUnits="userSpaceOnUse">
- <rect
- id="rect3035"
- height="23.773897"
- width="186.14999"
- y="455.1539"
- x="297.14999" />
- </clipPath>
- <clipPath
- id="clipEmfPath17"
- clipPathUnits="userSpaceOnUse">
- <rect
- id="rect3038"
- height="10.34952"
- width="110.325"
- y="513.3512"
- x="186.3" />
- </clipPath>
- <clipPath
- id="clipEmfPath18"
- clipPathUnits="userSpaceOnUse">
- <rect
- id="rect3041"
- height="31.423544"
- width="133.95"
- y="607.4718"
- x="175.8" />
- </clipPath>
- <clipPath
- id="clipEmfPath19"
- clipPathUnits="userSpaceOnUse">
- <rect
- id="rect3044"
- height="10.649506"
- width="58.200001"
- y="465.42841"
- x="212.925" />
- </clipPath>
- <clipPath
- id="clipEmfPath20"
- clipPathUnits="userSpaceOnUse">
- <rect
- id="rect3047"
- height="10.199527"
- width="61.424999"
- y="565.69879"
- x="214.64999" />
- </clipPath>
- <clipPath
- id="clipEmfPath21"
- clipPathUnits="userSpaceOnUse">
- <rect
- id="rect3050"
- height="22.648951"
- width="83.474998"
- y="703.91736"
- x="261.52499" />
- </clipPath>
- <clipPath
- id="clipEmfPath22"
- clipPathUnits="userSpaceOnUse">
- <rect
- id="rect3053"
- height="52.722553"
- width="79.800003"
- y="217.33992"
- x="203.02499" />
- </clipPath>
- <clipPath
- id="clipEmfPath23"
- clipPathUnits="userSpaceOnUse">
- <rect
- id="rect3056"
- height="10.049534"
- width="131.55"
- y="346.10895"
- x="266.77499" />
- </clipPath>
- <clipPath
- id="clipEmfPath24"
- clipPathUnits="userSpaceOnUse">
- <rect
- id="rect3059"
- height="25.04884"
- width="118.05"
- y="334.93448"
- x="73.125" />
- </clipPath>
- <clipPath
- id="clipEmfPath25"
- clipPathUnits="userSpaceOnUse">
- <rect
- id="rect3062"
- height="10.649506"
- width="69"
- y="362.90817"
- x="206.925" />
- </clipPath>
- <clipPath
- id="clipEmfPath26"
- clipPathUnits="userSpaceOnUse">
- <rect
- id="rect3065"
- height="26.473772"
- width="90.074997"
- y="406.70615"
- x="195.52499" />
- </clipPath>
- <clipPath
- id="clipEmfPath27"
- clipPathUnits="userSpaceOnUse">
- <rect
- id="rect3068"
- height="31.348545"
- width="133.95"
- y="730.16614"
- x="175.8" />
- </clipPath>
- <clipPath
- id="clipEmfPath28"
- clipPathUnits="userSpaceOnUse">
- <rect
- id="rect3071"
- height="22.723946"
- width="83.474998"
- y="385.18213"
- x="257.77499" />
- </clipPath>
- <clipPath
- id="clipEmfPath29"
- clipPathUnits="userSpaceOnUse">
- <rect
- id="rect3074"
- height="22.198971"
- width="174.60001"
- y="678.26855"
- x="301.35001" />
- </clipPath>
- <clipPath
- id="clipEmfPath30"
- clipPathUnits="userSpaceOnUse">
- <rect
- id="rect3077"
- height="10.199527"
- width="61.5"
- y="685.69324"
- x="211.8" />
- </clipPath>
- <clipPath
- id="clipEmfPath31"
- clipPathUnits="userSpaceOnUse">
- <rect
- id="rect3080"
- height="22.198971"
- width="114.3"
- y="541.7749"
- x="60.900002" />
- </clipPath>
- <clipPath
- id="clipEmfPath32"
- clipPathUnits="userSpaceOnUse">
- <rect
- id="rect3083"
- height="30.898567"
- width="84"
- y="132.29387"
- x="202.425" />
- </clipPath>
- <clipPath
- id="clipEmfPath33"
- clipPathUnits="userSpaceOnUse">
- <rect
- id="rect3086"
- height="30.298595"
- width="94.5"
- y="127.49409"
- x="320.70001" />
- </clipPath>
- </defs>
- <sodipodi:namedview
- id="base"
- pagecolor="#ffffff"
- bordercolor="#666666"
- borderopacity="1.0"
- inkscape:pageopacity="0.0"
- inkscape:pageshadow="2"
- inkscape:zoom="1.4142136"
- inkscape:cx="423.51378"
- inkscape:cy="280.02058"
- inkscape:document-units="px"
- inkscape:current-layer="layer1"
- showgrid="false"
- fit-margin-top="0"
- fit-margin-left="10"
- fit-margin-right="10"
- fit-margin-bottom="10"
- inkscape:snap-bbox="false"
- inkscape:snap-nodes="false"
- inkscape:window-width="1920"
- inkscape:window-height="1028"
- inkscape:window-x="-8"
- inkscape:window-y="-8"
- inkscape:window-maximized="1"
- showguides="true"
- inkscape:guide-bbox="true" />
- <metadata
- id="metadata7">
- <rdf:RDF>
- <cc:Work
- rdf:about="">
- <dc:format>image/svg+xml</dc:format>
- <dc:type
- rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
- <dc:title></dc:title>
- </cc:Work>
- </rdf:RDF>
- </metadata>
- <g
- inkscape:label="Layer 1"
- inkscape:groupmode="layer"
- id="layer1"
- transform="translate(-13.241957,-37.469169)">
- <text
- xml:space="preserve"
- x="605.35443"
- y="783.80597"
- style="font-style:normal;font-weight:normal;font-size:12.52499962px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3090" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
- clip-path="url(#clipEmfPath1)"
- d="m 255.09375,180.89161 0,30.37359 44.86875,0 0,-30.37359 -44.86875,0 z"
- id="path3092"
- transform="translate(-2.1455429,6.6919971)" />
- <text
- xml:space="preserve"
- x="252.92946"
- y="196.8082"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3094">YES, bug</text>
- <text
- xml:space="preserve"
- x="295.15445"
- y="196.8082"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3096" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
- clip-path="url(#clipEmfPath2)"
- d="m 131.5875,51.522611 0,40.498122 60.75,0 0,-40.498122 -60.75,0 z"
- id="path3098"
- transform="translate(-2.1455429,6.6919971)" />
- <text
- xml:space="preserve"
- x="137.57947"
- y="71.488991"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3100">Reporter </text>
- <text
- xml:space="preserve"
- x="137.57947"
- y="83.038452"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3102">provides </text>
- <text
- xml:space="preserve"
- x="137.57947"
- y="94.512924"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3104">more info</text>
- <text
- xml:space="preserve"
- x="179.27946"
- y="94.512924"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3106" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
- clip-path="url(#clipEmfPath3)"
- d="m 50.5875,144.70579 0,47.4353 106.875,0 0,-47.4353 -106.875,0 z"
- id="path3108"
- transform="translate(-2.1455429,6.6919971)" />
- <text
- xml:space="preserve"
- x="56.579456"
- y="164.70967"
- style="font-style:normal;font-weight:bold;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3110">No</text>
- <text
- xml:space="preserve"
- x="69.854454"
- y="164.70967"
- style="font-style:normal;font-weight:bold;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3112">t clear:</text>
- <text
- xml:space="preserve"
- x="102.62946"
- y="164.70967"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3114" />
- <text
- xml:space="preserve"
- x="105.40446"
- y="164.70967"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3116">more info</text>
- <text
- xml:space="preserve"
- x="147.10446"
- y="164.70967"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3118" />
- <text
- xml:space="preserve"
- x="56.579456"
- y="176.18414"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3120">requested</text>
- <text
- xml:space="preserve"
- x="101.05445"
- y="176.18414"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3122" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
- clip-path="url(#clipEmfPath4)"
- d="m 61.8375,290.57403 0,30.37359 141.75,0 0,-30.37359 -141.75,0 z"
- id="path3124"
- transform="translate(-2.1455429,6.6919971)" />
- <text
- xml:space="preserve"
- x="107.72945"
- y="310.57788"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3126">Developer resolves </text>
- <text
- xml:space="preserve"
- x="196.07947"
- y="310.57788"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3128" />
- <text
- xml:space="preserve"
- x="153.25446"
- y="322.05237"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3130">the issue</text>
- <text
- xml:space="preserve"
- x="193.30446"
- y="322.05237"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3132" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
- clip-path="url(#clipEmfPath5)"
- d="m 101.2125,11.024489 0,30.373592 141.75,0 0,-30.373592 -141.75,0 z"
- id="path3134"
- transform="translate(-2.1455429,6.6919971)" />
- <text
- xml:space="preserve"
- x="107.20445"
- y="50.915874"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3136">Reporter registers an issue</text>
- <text
- xml:space="preserve"
- x="227.20447"
- y="30.915874"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3138" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
- clip-path="url(#clipEmfPath6)"
- d="m 202.4625,42.148046 0,30.317344 80.87812,0 0,-30.317344 -80.87812,0 z"
- id="path3140"
- transform="translate(-2.1455429,6.6919971)" />
- <path
- inkscape:connector-curvature="0"
- style="fill:none;stroke:#000000;stroke-width:0.78957015px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
- d="m 200.243,57.766078 0,21.465274 81.02604,0 0,-21.465274 z"
- id="path3142" />
- <text
- xml:space="preserve"
- x="229.52946"
- y="70.839348"
- style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3144">New</text>
- <text
- xml:space="preserve"
- x="252.02946"
- y="63.839348"
- style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3146" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.075px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
- clip-path="url(#clipEmfPath7)"
- d="m 243.21562,72.577885 0.42188,34.564025 c 0.009,0.34686 -0.27188,0.62809 -0.61875,0.63747 -0.3375,0 -0.62813,-0.28124 -0.62813,-0.61872 l -0.42187,-34.564026 c -0.009,-0.346859 0.27187,-0.628096 0.61875,-0.63747 0.3375,0 0.62812,0.281237 0.62812,0.618721 z m 3.53438,33.279705 -3.65625,7.53715 -3.84375,-7.45278 z"
- id="path3148"
- transform="translate(-2.1455429,6.6919971)" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
- d="m 199.37946,300.45338 0,26.19254 91.125,0 0,-26.19254 -91.125,0 z"
- id="path3150" />
- <path
- inkscape:connector-curvature="0"
- style="fill:none;stroke:#000000;stroke-width:0.9375px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
- d="m 199.37946,300.45338 0,26.19254 91.125,0 0,-26.19254 z"
- id="path3152" />
- <text
- xml:space="preserve"
- x="219.92946"
- y="315.75266"
- style="font-style:normal;font-weight:bold;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3154">Resolved</text>
- <text
- xml:space="preserve"
- x="269.95447"
- y="315.75266"
- style="font-style:normal;font-weight:bold;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3156" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.075px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
- clip-path="url(#clipEmfPath8)"
- d="m 243.59062,243.13873 0.0563,44.37919 c 0,0.34686 -0.28125,0.61872 -0.62812,0.61872 -0.3375,0.009 -0.61875,-0.27186 -0.61875,-0.61872 l -0.0563,-44.36982 c 0,-0.34686 0.28125,-0.62809 0.61875,-0.62809 0.34687,0 0.62812,0.28123 0.62812,0.61872 z m 3.17813,43.123 -3.74063,7.49965 -3.75937,-7.49028 z"
- id="path3158"
- transform="translate(-2.1455429,6.6919971)" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
- d="m 122.19508,172.20933 0,40.49812 74.625,0 0,-40.49812 -74.625,0 z"
- id="path3162" />
- <text
- xml:space="preserve"
- x="150.17946"
- y="181.4339"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3164">Ma</text>
- <text
- xml:space="preserve"
- x="164.05446"
- y="181.4339"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3166">intainer</text>
- <text
- xml:space="preserve"
- x="196.82947"
- y="181.4339"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3168" />
- <text
- xml:space="preserve"
- x="165.70447"
- y="192.90837"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3170">checks</text>
- <text
- xml:space="preserve"
- x="196.82947"
- y="192.90837"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3172" />
- <text
- xml:space="preserve"
- x="131.80446"
- y="204.45782"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3174">the </text>
- <text
- xml:space="preserve"
- x="148.45447"
- y="204.45782"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3176">description</text>
- <text
- xml:space="preserve"
- x="196.82947"
- y="204.45782"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3178" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
- clip-path="url(#clipEmfPath9)"
- d="m 50.5875,71.771672 0,30.312658 80.87812,0 0,-30.312658 -80.87812,0 z"
- id="path3180"
- transform="translate(-2.1455429,6.6919971)" />
- <path
- inkscape:connector-curvature="0"
- style="fill:none;stroke:#000000;stroke-width:0.9375px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
- d="m 48.441957,78.463669 0,30.312661 80.878123,0 0,-30.312661 z"
- id="path3182" />
- <text
- xml:space="preserve"
- x="62.954456"
- y="93.762955"
- style="font-style:normal;font-weight:bold;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3184">Feedback</text>
- <text
- xml:space="preserve"
- x="114.85445"
- y="93.762955"
- style="font-style:normal;font-weight:bold;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3186" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.075px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
- clip-path="url(#clipEmfPath10)"
- d="m 168.9,148.21188 -87.853125,-0.67497 c -0.3375,0 -0.61875,-0.28124 -0.61875,-0.6281 l -0.075,-38.51071 c 0,-0.34686 0.28125,-0.61872 0.628125,-0.6281 0.3375,0 0.61875,0.28124 0.61875,0.6281 l 0.08438,38.51071 -0.628125,-0.62809 87.853115,0.67497 c 0.34688,0.009 0.61876,0.29061 0.61876,0.63747 0,0.33748 -0.28125,0.61872 -0.62812,0.61872 z m -91.66875,-38.55759 3.73125,-7.50903 3.76875,7.49966 z"
- id="path3188"
- transform="translate(-2.1455429,6.6919971)" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.07166955px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
- d="m 129.43631,98.095449 97.87721,-0.06896 c 0.3352,0 0.61453,0.24996 0.62383,0.568875 l 0.2514,19.884776 c 0,0.31891 -0.27002,0.5775 -0.61452,0.5775 -0.34451,0.008 -0.62384,-0.24996 -0.62384,-0.56888 l -0.2607,-19.876157 0.62383,0.560255 -97.86791,0.07757 c -0.3445,0 -0.62383,-0.25858 -0.62383,-0.577494 0,-0.318914 0.27933,-0.577494 0.61453,-0.577494 z m 101.8437,19.195221 -3.64061,6.93856 -3.80819,-6.85236 z"
- id="path3190" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.0761172px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
- d="m 241.44501,189.85283 0.0469,23.11907 c 0,0.34765 -0.27184,0.63736 -0.61867,0.63736 -0.34683,0.009 -0.62806,-0.28005 -0.62806,-0.63736 l -0.0469,-23.10942 c 0,-0.35731 0.28122,-0.64702 0.61868,-0.64702 0.34682,0 0.62804,0.28971 0.62804,0.63737 z m 3.16837,21.82502 -3.7308,7.72567 -3.7683,-7.71602 z"
- id="path3192" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.0748096px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
- d="m 189.86832,477.33276 -136.423363,0 c -0.335788,0 -0.615612,-0.28124 -0.615612,-0.63747 l 0,-221.61489 c 0,-0.33748 0.279824,-0.61872 0.615612,-0.61872 l 140.284923,0 c 0.35444,0 0.61561,0.28124 0.61561,0.61872 0,0.35624 -0.26117,0.63747 -0.61561,0.63747 l -140.284923,0 0.615612,-0.63747 0,221.61489 -0.615612,-0.61872 136.423363,0 c 0.35444,0 0.63426,0.28123 0.63426,0.61872 0,0.35623 -0.27982,0.63747 -0.63426,0.63747 z m 2.61168,-226.00218 7.46197,3.74982 -7.46197,3.74984 z"
- id="path3194" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.07489965px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
- d="M 191.842,697.88495 23.879416,696.72562 c -0.3375,0 -0.600001,-0.26179 -0.600001,-0.59837 l 0,-461.67788 c 0,-0.14959 0.075,-0.29919 0.187501,-0.41138 0.1125,-0.11219 0.2625,-0.18698 0.45,-0.18698 L 194.092,234.93555 c 0.3375,0 0.6375,0.29918 0.6,0.63576 0,0.33658 -0.2625,0.63577 -0.6,0.63577 l -170.212584,-1.12194 0.6375,-0.63577 0,461.67788 -0.6,-0.63576 167.925084,1.15933 c 0.375,0 0.6375,0.26179 0.6375,0.63576 0,0.33659 -0.3,0.59837 -0.6375,0.59837 z m 1.0125,-466.05344 7.4625,3.7772 -7.5,3.70239 z"
- id="path3196" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
- d="m 255.70446,592.18985 0,30.37359 75.2625,0 0,-30.37359 -75.2625,0 z"
- id="path3198" />
- <text
- xml:space="preserve"
- x="255.70447"
- y="601.41443"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3200">YES, fixed</text>
- <text
- xml:space="preserve"
- x="302.42947"
- y="601.41443"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3202" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
- clip-path="url(#clipEmfPath11)"
- d="m 32.775,659.9319 0,30.37359 133.125,0 0,-30.37359 -133.125,0 z"
- id="path3204"
- transform="translate(-2.1455429,6.6919971)" />
- <text
- xml:space="preserve"
- x="38.729458"
- y="679.93579"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3206">Reporter</text>
- <text
- xml:space="preserve"
- x="80.354454"
- y="679.93579"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3208" />
- <text
- xml:space="preserve"
- x="84.129456"
- y="679.93579"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3210">is not satisfied </text>
- <text
- xml:space="preserve"
- x="38.729458"
- y="691.41028"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3212">with </text>
- <text
- xml:space="preserve"
- x="59.204456"
- y="691.41028"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3214" />
- <text
- xml:space="preserve"
- x="61.979458"
- y="691.41028"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3216">the </text>
- <text
- xml:space="preserve"
- x="78.704453"
- y="691.41028"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3218">fix</text>
- <text
- xml:space="preserve"
- x="88.754456"
- y="691.41028"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3220" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
- clip-path="url(#clipEmfPath12)"
- d="m 252.15,490.19602 0,22.7427 166.95,0 0,-22.7427 -166.95,0 z"
- id="path3222"
- transform="translate(-2.1455429,6.6919971)" />
- <text
- xml:space="preserve"
- x="250.00446"
- y="506.01883"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3224">YES, fixed</text>
- <text
- xml:space="preserve"
- x="296.65445"
- y="506.01883"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3226">, no regressions</text>
- <text
- xml:space="preserve"
- x="367.82947"
- y="506.01883"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3228" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
- clip-path="url(#clipEmfPath13)"
- d="m 59.9625,437.37972 0,30.37359 114.375,0 0,-30.37359 -114.375,0 z"
- id="path3230"
- transform="translate(-2.1455429,6.6919971)" />
- <text
- xml:space="preserve"
- x="65.954453"
- y="457.3461"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3232">Tester </text>
- <text
- xml:space="preserve"
- x="98.204453"
- y="457.3461"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3234">is not satisfied </text>
- <text
- xml:space="preserve"
- x="65.954453"
- y="468.89557"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3236">with </text>
- <text
- xml:space="preserve"
- x="86.429451"
- y="468.89557"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3238">the </text>
- <text
- xml:space="preserve"
- x="103.15446"
- y="468.89557"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3240">fix</text>
- <text
- xml:space="preserve"
- x="113.20445"
- y="468.89557"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3242" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
- clip-path="url(#clipEmfPath14)"
- d="m 300.4125,554.1868 0,30.3736 174.675,0 0,-30.3736 -174.675,0 z"
- id="path3244"
- transform="translate(-2.1455429,6.6919971)" />
- <text
- xml:space="preserve"
- x="306.40445"
- y="574.11572"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3246">Integrator merges the fix to trunk</text>
- <text
- xml:space="preserve"
- x="450.92947"
- y="574.11572"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3248" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
- clip-path="url(#clipEmfPath15)"
- d="m 297.15,455.13515 0,23.86764 186.1875,0 0,-23.86764 -186.1875,0 z"
- id="path3250"
- transform="translate(-2.1455429,6.6919971)" />
- <text
- xml:space="preserve"
- x="295.00446"
- y="471.07047"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3252">Tester verifies the solution</text>
- <text
- xml:space="preserve"
- x="411.70447"
- y="471.07047"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3254" />
- <text
- xml:space="preserve"
- x="414.47946"
- y="471.07047"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3256" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
- clip-path="url(#clipEmfPath16)"
- d="m 185.775,508.81391 0,19.44285 111.375,0 0,-19.44285 -111.375,0 z"
- id="path3258"
- transform="translate(-2.1455429,6.6919971)" />
- <path
- inkscape:connector-curvature="0"
- style="fill:none;stroke:#000000;stroke-width:0.9375px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
- d="m 183.62946,515.50591 0,19.44285 111.375,0 0,-19.44285 z"
- id="path3260" />
- <text
- xml:space="preserve"
- x="221.20447"
- y="530.39276"
- style="font-style:normal;font-weight:bold;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3262">Tested</text>
- <text
- xml:space="preserve"
- x="257.42947"
- y="530.39276"
- style="font-style:normal;font-weight:bold;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3264" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
- clip-path="url(#clipEmfPath17)"
- d="m 175.275,602.93454 0,40.49813 135,0 0,-40.49813 -135,0 z"
- id="path3266"
- transform="translate(-2.1455429,6.6919971)" />
- <path
- inkscape:connector-curvature="0"
- style="fill:none;stroke:#000000;stroke-width:0.9375px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
- d="m 173.12946,609.62654 0,40.49813 135,0 0,-40.49813 z"
- id="path3268" />
- <text
- xml:space="preserve"
- x="184.37946"
- y="624.58838"
- style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3270">Integration to the trunk</text>
- <text
- xml:space="preserve"
- x="296.95447"
- y="624.58838"
- style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3272" />
- <text
- xml:space="preserve"
- x="220.00446"
- y="637.86273"
- style="font-style:normal;font-weight:bold;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3274">Verified</text>
- <text
- xml:space="preserve"
- x="261.25446"
- y="637.86273"
- style="font-style:normal;font-weight:bold;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3276" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.075px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
- clip-path="url(#clipEmfPath18)"
- d="M 242.6625,524.82567 242.7,548.8808 c 0,0.33748 -0.2625,0.61872 -0.61875,0.61872 -0.3375,0.0188 -0.61875,-0.26249 -0.61875,-0.61872 l -0.0563,-24.05513 c 0,-0.35624 0.28125,-0.61873 0.61875,-0.63747 0.35625,0 0.6375,0.28123 0.6375,0.63747 z m 3.16875,22.79894 -3.73125,7.49965 -3.76875,-7.4809 z"
- id="path3278"
- transform="translate(-2.1455429,6.6919971)" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
- d="m 239.87946,462.25838 -50.625,15.18679 50.625,15.1868 50.625,-15.1868 z"
- id="path3280" />
- <path
- inkscape:connector-curvature="0"
- style="fill:none;stroke:#000000;stroke-width:0.9375px;stroke-linecap:round;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
- d="m 239.87946,462.25838 -50.625,15.18679 50.625,15.1868 50.625,-15.1868 z"
- id="path3282" />
- <text
- xml:space="preserve"
- x="223.00446"
- y="482.54492"
- style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3284">Fixed?</text>
- <text
- xml:space="preserve"
- x="256.75446"
- y="482.54492"
- style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3286" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.075px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
- clip-path="url(#clipEmfPath19)"
- d="m 242.6625,487.62739 0.0375,14.0056 c 0,0.33749 -0.28125,0.61872 -0.61875,0.61872 -0.35625,0.0188 -0.6375,-0.26249 -0.6375,-0.61872 l -0.0375,-13.98685 c 0,-0.35623 0.28125,-0.63747 0.61875,-0.63747 0.35625,0 0.6375,0.28124 0.6375,0.61872 z m 3.16875,12.74941 -3.73125,7.49965 -3.76875,-7.4809 z"
- id="path3288"
- transform="translate(-2.1455429,6.6919971)" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
- d="m 243.16071,562.69747 -53.90625,14.75557 53.90625,14.73681 53.90625,-14.73681 z"
- id="path3290" />
- <path
- inkscape:connector-curvature="0"
- style="fill:none;stroke:#000000;stroke-width:0.9375px;stroke-linecap:round;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
- d="m 240.16071,563.69747 -53.90625,14.75557 53.90625,14.73681 53.90625,-14.73681 z"
- id="path3292" />
- <text
- xml:space="preserve"
- x="215.35446"
- y="580.81531"
- style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3294">Conflict ?</text>
- <text
- xml:space="preserve"
- x="265.15445"
- y="582.81531"
- style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3298" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.075px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
- clip-path="url(#clipEmfPath20)"
- d="m 242.6625,585.49785 0.0375,12.56192 c 0,0.35623 -0.28125,0.63747 -0.61875,0.63747 -0.35625,0 -0.6375,-0.28124 -0.6375,-0.61872 l -0.0375,-12.56192 c 0,-0.35623 0.28125,-0.63747 0.61875,-0.63747 0.35625,0 0.6375,0.28124 0.6375,0.61872 z m 3.15,11.30573 -3.7125,7.5184 -3.7875,-7.49965 z"
- id="path3300"
- transform="translate(-2.1455429,6.6919971)" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
- d="m 259.37946,710.57186 0,22.76145 83.5125,0 0,-22.76145 -83.5125,0 z"
- id="path3302" />
- <text
- xml:space="preserve"
- x="259.37946"
- y="719.83392"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3304">YES, fixed</text>
- <text
- xml:space="preserve"
- x="306.10446"
- y="719.83392"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3306" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
- clip-path="url(#clipEmfPath21)"
- d="m 202.4625,212.76513 0,61.87214 80.87812,0 0,-61.87214 -80.87812,0 z"
- id="path3308"
- transform="translate(-2.1455429,6.6919971)" />
- <path
- inkscape:connector-curvature="0"
- style="fill:none;stroke:#000000;stroke-width:0.9375px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
- d="m 200.31696,219.45713 0,61.87214 80.87812,0 0,-61.87214 z"
- id="path3310" />
- <text
- xml:space="preserve"
- x="215.50446"
- y="234.83142"
- style="font-style:normal;font-weight:bold;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3312">Assigned</text>
- <text
- xml:space="preserve"
- x="266.12946"
- y="234.83142"
- style="font-style:normal;font-weight:bold;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3314" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
- clip-path="url(#clipEmfPath22)"
- d="m 266.775,346.07145 0,10.12453 131.625,0 0,-10.12453 -131.625,0 z"
- id="path3316"
- transform="translate(-2.1455429,6.6919971)" />
- <text
- xml:space="preserve"
- x="264.62946"
- y="362.02551"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3318">Reviewer</text>
- <text
- xml:space="preserve"
- x="306.25446"
- y="362.02551"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3320" />
- <text
- xml:space="preserve"
- x="309.02945"
- y="362.02551"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3322">verifies the solution</text>
- <text
- xml:space="preserve"
- x="394.67947"
- y="362.02551"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3324" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.075px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
- clip-path="url(#clipEmfPath23)"
- d="M 241.03125,375.71383 240.9,390.63814 c 0,0.35623 -0.28125,0.63747 -0.6375,0.61872 -0.3375,0 -0.61875,-0.28124 -0.61875,-0.61872 l 0.13125,-14.94306 c 0.0187,-0.33748 0.3,-0.61872 0.6375,-0.61872 0.35625,0 0.61875,0.28124 0.61875,0.63747 z m 3,13.70561 -3.80625,7.46216 -3.69375,-7.5184 z"
- id="path3326"
- transform="translate(-2.1455429,6.6919971)" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.07680816px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
- d="m 190.48632,375.76754 -122.978386,0 c -0.335598,0 -0.615264,-0.29663 -0.615264,-0.65258 l 0,-110.82166 c 0,-0.35597 0.279666,-0.65259 0.615264,-0.65259 l 125.849616,0 c 0.35425,0 0.61526,0.29662 0.61526,0.65259 0,0.37572 -0.26101,0.67236 -0.61526,0.67236 l -125.849616,0 0.615265,-0.67236 0,110.82166 -0.615265,-0.67237 122.978386,0 c 0.35424,0 0.63391,0.29662 0.63391,0.67237 0,0.35595 -0.27967,0.65258 -0.63391,0.65258 z m 1.62205,-115.42934 7.45776,3.9551 -7.45776,3.95508 z"
- id="path3328" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
- d="m 70.941957,337.57666 0,33.18596 118.125003,0 0,-33.18596 -118.125003,0 z"
- id="path3330" />
- <text
- xml:space="preserve"
- x="79.079453"
- y="350.85101"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3332">Reviewer</text>
- <text
- xml:space="preserve"
- x="120.70445"
- y="350.85101"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3334" />
- <text
- xml:space="preserve"
- x="123.47945"
- y="350.85101"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3336">is not </text>
- <text
- xml:space="preserve"
- x="79.079453"
- y="362.40048"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3338">satisfied with </text>
- <text
- xml:space="preserve"
- x="139.07947"
- y="362.40048"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3340">the fix</text>
- <text
- xml:space="preserve"
- x="165.77946"
- y="362.40048"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3342" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.075px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
- clip-path="url(#clipEmfPath24)"
- d="m 241.21875,421.6117 1.0125,26.75501 c 0.0188,0.35623 -0.24375,0.63747 -0.6,0.65622 -0.3375,0 -0.6375,-0.26249 -0.6375,-0.59997 l -1.03125,-26.75501 c 0,-0.35623 0.2625,-0.63747 0.61875,-0.65622 0.3375,-0.0188 0.61875,0.26249 0.6375,0.59997 z m 4.0875,25.38632 -3.46875,7.6309 -4.03125,-7.34966 z"
- id="path3344"
- transform="translate(-2.1455429,6.6919971)" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
- d="m 239.22321,359.70063 -61.40625,15.1868 61.40625,15.18679 61.40625,-15.18679 z"
- id="path3346" />
- <path
- inkscape:connector-curvature="0"
- style="fill:none;stroke:#000000;stroke-width:0.9375px;stroke-linecap:round;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
- d="m 239.22321,359.70063 -61.40625,15.1868 61.40625,15.18679 61.40625,-15.18679 z"
- id="path3348" />
- <text
- xml:space="preserve"
- x="222.40446"
- y="380.02469"
- style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3350">Good</text>
- <text
- xml:space="preserve"
- x="249.85446"
- y="380.02469"
- style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3352">?</text>
- <text
- xml:space="preserve"
- x="256.15445"
- y="380.02469"
- style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3354" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
- clip-path="url(#clipEmfPath25)"
- d="m 194.9625,402.13135 0,35.62335 91.125,0 0,-35.62335 -91.125,0 z"
- id="path3356"
- transform="translate(-2.1455429,6.6919971)" />
- <path
- inkscape:connector-curvature="0"
- style="fill:none;stroke:#000000;stroke-width:0.9375px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
- d="m 192.81696,408.82335 0,35.62335 91.125,0 0,-35.62335 z"
- id="path3358" />
- <text
- xml:space="preserve"
- x="213.50446"
- y="428.74765"
- style="font-style:normal;font-weight:bold;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3360">Reviewed</text>
- <text
- xml:space="preserve"
- x="241.20447"
- y="430.74765"
- style="font-style:normal;font-weight:bold;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3362" />
- <text
- xml:space="preserve"
- x="264.40445"
- y="423.74765"
- style="font-style:normal;font-weight:bold;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3364" />
- <text
- xml:space="preserve"
- x="230.02946"
- y="759.72205"
- style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3366">+ Resolution</text>
- <text
- xml:space="preserve"
- x="269.87946"
- y="436.72205"
- style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3368" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
- clip-path="url(#clipEmfPath26)"
- d="m 175.275,725.55386 0,40.49812 135,0 0,-40.49812 -135,0 z"
- id="path3370"
- transform="translate(-2.1455429,6.6919971)" />
- <path
- inkscape:connector-curvature="0"
- style="fill:none;stroke:#000000;stroke-width:0.84135455px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
- d="m 173.08139,732.19779 0,32.59426 135.09614,0 0,-32.59426 z"
- id="path3372" />
- <text
- xml:space="preserve"
- x="184.67946"
- y="747.28265"
- style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3374">Delivery of the release</text>
- <text
- xml:space="preserve"
- x="296.57947"
- y="747.28265"
- style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3376" />
- <text
- xml:space="preserve"
- x="189.87946"
- y="759.48206"
- style="font-style:normal;font-weight:bold;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3378">Closed</text>
- <text
- xml:space="preserve"
- x="259.37946"
- y="760.48206"
- style="font-style:normal;font-weight:bold;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3380" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.075px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
- clip-path="url(#clipEmfPath27)"
- d="m 243.59062,0.89995827 0.2625,34.18903973 c 0.009,0.337484 -0.27187,0.628096 -0.61874,0.628096 -0.34688,0 -0.62813,-0.281237 -0.62813,-0.618721 l -0.2625,-34.18904016 c 0,-0.34685892 0.27187,-0.62809588 0.61875,-0.62809588 0.34687,0 0.62812,0.27186239 0.62812,0.61872131 z M 246.975,33.814057 243.28125,41.341833 239.475,33.870305 Z"
- id="path3382"
- transform="translate(-2.1455429,6.6919971)" />
- <text
- xml:space="preserve"
- x="255.62946"
- y="401.02371"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3384">YES, code is good</text>
- <text
- xml:space="preserve"
- x="337.90445"
- y="401.02371"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3386" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
- clip-path="url(#clipEmfPath28)"
- d="m 301.35,674.18124 0,30.37359 174.675,0 0,-30.37359 -174.675,0 z"
- id="path3388"
- transform="translate(-2.1455429,6.6919971)" />
- <text
- xml:space="preserve"
- x="307.30447"
- y="694.11017"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3390">Reporter can re</text>
- <text
- xml:space="preserve"
- x="376.75446"
- y="694.11017"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3392">-</text>
- <text
- xml:space="preserve"
- x="380.12946"
- y="694.11017"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3394">check the fix</text>
- <text
- xml:space="preserve"
- x="435.70447"
- y="694.11017"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3396" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.075px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
- clip-path="url(#clipEmfPath29)"
- d="m 243.6,644.8201 0.0375,24.07389 c 0,0.33748 -0.2625,0.59997 -0.6,0.59997 -0.3375,0 -0.6375,-0.26249 -0.6375,-0.59997 l -0.0375,-24.07389 c 0,-0.33748 0.2625,-0.63747 0.6,-0.63747 0.375,0 0.6375,0.29999 0.6375,0.63747 z m 3.1875,22.79895 -3.75,7.49965 -3.75,-7.46216 z"
- id="path3398"
- transform="translate(-2.1455429,6.6919971)" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
- d="m 240.36696,682.71066 -53.925,14.73681 53.925,14.73682 53.8875,-14.73682 z"
- id="path3400" />
- <path
- inkscape:connector-curvature="0"
- style="fill:none;stroke:#000000;stroke-width:0.9375px;stroke-linecap:round;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
- d="m 240.36696,682.71066 -53.925,14.73681 53.925,14.73682 53.8875,-14.73682 z"
- id="path3402" />
- <text
- xml:space="preserve"
- x="229.15446"
- y="702.80975"
- style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3404">OK</text>
- <text
- xml:space="preserve"
- x="245.42946"
- y="702.80975"
- style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3406">?</text>
- <text
- xml:space="preserve"
- x="251.65446"
- y="702.80975"
- style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3408" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.075px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
- clip-path="url(#clipEmfPath30)"
- d="m 243.6,705.49229 0.0375,12.56192 c 0,0.37498 -0.2625,0.63747 -0.6,0.63747 -0.375,0 -0.6375,-0.26249 -0.6375,-0.59998 l -0.0375,-12.56191 c 0,-0.37499 0.2625,-0.63747 0.6,-0.63747 0.375,0 0.6375,0.26248 0.6375,0.59997 z m 3.15,11.32447 -3.7125,7.49966 -3.7875,-7.49966 z"
- id="path3410"
- transform="translate(-2.1455429,6.6919971)" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.075px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
- d="m 188.54196,579.51544 -151.968753,0 c -0.3375,0 -0.61875,-0.28124 -0.61875,-0.63747 l 0,-333.17205 c 0,-0.33749 0.28125,-0.61872 0.61875,-0.61872 l 156.937503,0 c 0.35625,0 0.61875,0.28123 0.61875,0.61872 0,0.35623 -0.2625,0.63747 -0.61875,0.63747 l -156.937503,0 0.61875,-0.63747 0,333.17205 -0.61875,-0.61872 151.968753,0 c 0.3375,0 0.61875,0.28124 0.61875,0.61872 0,0.35623 -0.28125,0.63747 -0.61875,0.63747 z m 3.7125,-337.55935 7.5,3.74983 -7.5,3.74982 z"
- id="path3412" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
- d="m 58.754457,544.37957 0,30.37359 114.375003,0 0,-30.37359 -114.375003,0 z"
- id="path3414" />
- <text
- xml:space="preserve"
- x="66.854454"
- y="557.69147"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3416">Conflict with other </text>
- <text
- xml:space="preserve"
- x="66.854454"
- y="569.16595"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3418">change is detected</text>
- <text
- xml:space="preserve"
- x="150.77946"
- y="569.16595"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3420" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.075px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
- clip-path="url(#clipEmfPath31)"
- d="m 301.3875,146.89944 102.95625,0 c 0.35625,0 0.61875,0.28124 0.61875,0.61872 l 0,158.05517 c 0,0.35624 -0.2625,0.63747 -0.61875,0.63747 l -104.30625,0 c -0.35625,0 -0.6375,-0.28123 -0.6375,-0.63747 0,-0.33748 0.28125,-0.61872 0.6375,-0.61872 l 104.30625,0 -0.61875,0.61872 0,-158.05517 0.61875,0.63747 -102.95625,0 c -0.3375,0 -0.61875,-0.28124 -0.61875,-0.63747 0,-0.33748 0.28125,-0.61872 0.61875,-0.61872 z m -0.1125,162.42372 -7.5,-3.74983 7.5,-3.74982 z"
- id="path3422"
- transform="translate(-2.1455429,6.6919971)" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#ffffff;fill-opacity:1;fill-rule:evenodd;stroke:none"
- d="m 242.22321,118.96179 -76.40625,35.43586 76.40625,35.43586 76.40625,-35.43586 z"
- id="path3424" />
- <text
- xml:space="preserve"
- x="258.85446"
- y="149.41039"
- style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3430" />
- <text
- xml:space="preserve"
- x="276.02945"
- y="162.30978"
- style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3434" />
- <text
- xml:space="preserve"
- x="318.55447"
- y="143.41066"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3436">YES, fix provided</text>
- <text
- xml:space="preserve"
- x="395.27945"
- y="143.41066"
- style="font-style:normal;font-weight:normal;font-size:9.97500038px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3438" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.08784765px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
- d="m 241.21873,80.019597 0.0468,30.842723 c 0,0.4638 -0.27142,0.8503 -0.6177,0.8503 -0.34628,0.0124 -0.62706,-0.37361 -0.62706,-0.8503 l -0.0468,-30.829846 c 0,-0.476685 0.28077,-0.863176 0.6177,-0.863176 0.34628,0 0.62705,0.386491 0.62705,0.850299 z m 3.16336,29.116363 -3.7249,10.30667 -3.76234,-10.2938 z"
- id="path3192-1" />
- <g
- transform="matrix(1,0,0,0.82597166,232.6452,389.49727)"
- id="g4649">
- <text
- xml:space="preserve"
- x="-1.4697021"
- y="13.642687"
- style="font-style:normal;font-weight:normal;font-size:17.93036652px;font-family:Calibri;text-align:start;text-anchor:start;fill:#000000"
- id="text4651" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.09798014px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
- d="M 6.6504022,0.48301422 6.4789369,16.185905 c -0.00612,0.364725 -0.3735493,0.655519 -0.8267074,0.655519 -0.4531582,-0.0049 -0.81446,-0.300651 -0.8083362,-0.665376 L 5.0153586,0.46822807 c 0.00612,-0.35979631 0.3735492,-0.6555193 0.8267074,-0.65059058 0.4470344,0.004929 0.8083362,0.30065171 0.8083362,0.66537673 z M 10.575732,14.904439 5.5848681,22.750955 0.77771738,14.830508 Z"
- id="path4653" />
- </g>
- <g
- transform="matrix(0.982276,0,0,1.0254389,234.01098,492.23124)"
- id="g4666">
- <text
- xml:space="preserve"
- x="-1.4697021"
- y="13.642687"
- style="font-style:normal;font-weight:normal;font-size:17.93036652px;font-family:Calibri;text-align:start;text-anchor:start;fill:#000000"
- id="text4668" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.09798014px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
- d="M 6.6504022,0.48301422 6.4789369,16.185905 c -0.00612,0.364725 -0.3735493,0.655519 -0.8267074,0.655519 -0.4531582,-0.0049 -0.81446,-0.300651 -0.8083362,-0.665376 L 5.0153586,0.46822807 c 0.00612,-0.35979631 0.3735492,-0.6555193 0.8267074,-0.65059058 0.4470344,0.004929 0.8083362,0.30065171 0.8083362,0.66537673 z M 10.575732,14.904439 5.5848681,22.750955 0.77771738,14.830508 Z"
- id="path4670" />
- </g>
- <g
- transform="matrix(1,0,0,0.78256812,233.6452,444.48204)"
- id="g4683">
- <text
- xml:space="preserve"
- x="-1.4697021"
- y="13.642687"
- style="font-style:normal;font-weight:normal;font-size:17.93036652px;font-family:Calibri;text-align:start;text-anchor:start;fill:#000000"
- id="text4685" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.09798014px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
- d="M 6.6504022,0.48301422 6.4789369,16.185905 c -0.00612,0.364725 -0.3735493,0.655519 -0.8267074,0.655519 -0.4531582,-0.0049 -0.81446,-0.300651 -0.8083362,-0.665376 L 5.0153586,0.46822807 c 0.00612,-0.35979631 0.3735492,-0.6555193 0.8267074,-0.65059058 0.4470344,0.004929 0.8083362,0.30065171 0.8083362,0.66537673 z M 10.575732,14.904439 5.5848681,22.750955 0.77771738,14.830508 Z"
- id="path4687" />
- </g>
- <g
- transform="matrix(1,0,0,1.2605595,234.6452,535.1005)"
- id="g4683-9">
- <text
- xml:space="preserve"
- x="-1.4697021"
- y="13.642687"
- style="font-style:normal;font-weight:normal;font-size:17.93036652px;font-family:Calibri;text-align:start;text-anchor:start;fill:#000000"
- id="text4685-4" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.09798014px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
- d="M 6.6504022,0.48301422 6.4789369,16.185905 c -0.00612,0.364725 -0.3735493,0.655519 -0.8267074,0.655519 -0.4531582,-0.0049 -0.81446,-0.300651 -0.8083362,-0.665376 L 5.0153586,0.46822807 c 0.00612,-0.35979631 0.3735492,-0.6555193 0.8267074,-0.65059058 0.4470344,0.004929 0.8083362,0.30065171 0.8083362,0.66537673 z M 10.575732,14.904439 5.5848681,22.750955 0.77771738,14.830508 Z"
- id="path4687-8" />
- </g>
- <g
- transform="matrix(1,0,0,0.69536234,233.6452,592.9386)"
- id="g4683-8">
- <text
- xml:space="preserve"
- x="-1.4697021"
- y="13.642687"
- style="font-style:normal;font-weight:normal;font-size:17.93036652px;font-family:Calibri;text-align:start;text-anchor:start;fill:#000000"
- id="text4685-2" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.09798014px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
- d="M 6.6504022,0.48301422 6.4789369,16.185905 c -0.00612,0.364725 -0.3735493,0.655519 -0.8267074,0.655519 -0.4531582,-0.0049 -0.81446,-0.300651 -0.8083362,-0.665376 L 5.0153586,0.46822807 c 0.00612,-0.35979631 0.3735492,-0.6555193 0.8267074,-0.65059058 0.4470344,0.004929 0.8083362,0.30065171 0.8083362,0.66537673 z M 10.575732,14.904439 5.5848681,22.750955 0.77771738,14.830508 Z"
- id="path4687-4" />
- </g>
- <g
- transform="matrix(1,0,0,1.4346023,234.6452,649.62184)"
- id="g4683-9-5">
- <text
- xml:space="preserve"
- x="-1.4697021"
- y="13.642687"
- style="font-style:normal;font-weight:normal;font-size:17.93036652px;font-family:Calibri;text-align:start;text-anchor:start;fill:#000000"
- id="text4685-4-5" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.09798014px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
- d="M 6.6504022,0.48301422 6.4789369,16.185905 c -0.00612,0.364725 -0.3735493,0.655519 -0.8267074,0.655519 -0.4531582,-0.0049 -0.81446,-0.300651 -0.8083362,-0.665376 L 5.0153586,0.46822807 c 0.00612,-0.35979631 0.3735492,-0.6555193 0.8267074,-0.65059058 0.4470344,0.004929 0.8083362,0.30065171 0.8083362,0.66537673 z M 10.575732,14.904439 5.5848681,22.750955 0.77771738,14.830508 Z"
- id="path4687-8-1" />
- </g>
- <g
- transform="translate(234.70643,711.44155)"
- id="g4759">
- <text
- xml:space="preserve"
- x="-1.4697021"
- y="13.272961"
- style="font-style:normal;font-weight:normal;font-size:17.93036652px;font-family:Calibri;text-align:start;text-anchor:start;fill:#000000"
- id="text4761" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.09798014px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
- d="M 6.3197192,0.48857527 6.374833,14.127968 c 0.00612,0.37661 -0.3613017,0.68197 -0.8144599,0.68197 -0.4470344,0 -0.8144599,-0.30027 -0.8144599,-0.67688 L 4.6907993,0.4936646 c 0,-0.37661011 0.3613018,-0.68196965 0.81446,-0.68196965 0.4470344,0 0.8144599,0.30027022 0.8144599,0.67688032 z M 10.453256,12.75894 5.5848681,20.917129 0.6552422,12.784386 Z"
- id="path4763" />
- </g>
- <g
- transform="matrix(1,0,0,0.82597166,234.6327,281.48545)"
- id="g4649-7">
- <text
- xml:space="preserve"
- x="-1.4697021"
- y="13.642687"
- style="font-style:normal;font-weight:normal;font-size:17.93036652px;font-family:Calibri;text-align:start;text-anchor:start;fill:#000000"
- id="text4651-1" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.09798014px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
- d="M 6.6504022,0.48301422 6.4789369,16.185905 c -0.00612,0.364725 -0.3735493,0.655519 -0.8267074,0.655519 -0.4531582,-0.0049 -0.81446,-0.300651 -0.8083362,-0.665376 L 5.0153586,0.46822807 c 0.00612,-0.35979631 0.3735492,-0.6555193 0.8267074,-0.65059058 0.4470344,0.004929 0.8083362,0.30065171 0.8083362,0.66537673 z M 10.575732,14.904439 5.5848681,22.750955 0.77771738,14.830508 Z"
- id="path4653-1" />
- </g>
- <g
- transform="matrix(1,0,0,1.4346023,233.6327,327.6175)"
- id="g4683-9-5-5">
- <text
- xml:space="preserve"
- x="-1.4697021"
- y="13.642687"
- style="font-style:normal;font-weight:normal;font-size:17.93036652px;font-family:Calibri;text-align:start;text-anchor:start;fill:#000000"
- id="text4685-4-5-2" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.09798014px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
- d="M 6.6504022,0.48301422 6.4789369,16.185905 c -0.00612,0.364725 -0.3735493,0.655519 -0.8267074,0.655519 -0.4531582,-0.0049 -0.81446,-0.300651 -0.8083362,-0.665376 L 5.0153586,0.46822807 c 0.00612,-0.35979631 0.3735492,-0.6555193 0.8267074,-0.65059058 0.4470344,0.004929 0.8083362,0.30065171 0.8083362,0.66537673 z M 10.575732,14.904439 5.5848681,22.750955 0.77771738,14.830508 Z"
- id="path4687-8-1-7" />
- </g>
- <g
- id="g3761"
- transform="matrix(0.94795956,0,0,0.95863162,75.350761,108.12834)">
- <text
- id="text3763"
- style="font-style:normal;font-weight:normal;font-size:14.00640297px;font-family:Calibri;text-align:start;text-anchor:start;fill:#000000"
- y="11.933813"
- x="-1.2246037"
- xml:space="preserve" />
- <path
- id="path3765"
- d="M 94.150965,48.809882 4.5013748,48.103275 c -0.3492034,0 -0.6314362,-0.29442 -0.6314362,-0.652631 L 3.7886172,7.1347711 c 0,-0.3631176 0.2870165,-0.6526303 0.6410035,-0.6575373 0.3492033,0 0.6362198,0.2944197 0.6362198,0.6575373 l 0.076538,40.3158729 -0.6314362,-0.65263 89.6495907,0.7017 c 0.353987,0.0049 0.636219,0.299327 0.631436,0.662445 0,0.35821 -0.287017,0.65263 -0.641004,0.647723 z M 0.60273456,8.4498459 4.4152698,0.58883943 8.2565068,8.4351249 Z"
- style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.07653772px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
- inkscape:connector-curvature="0" />
- </g>
- <g
- transform="matrix(1,0,0,0.82597166,236.44519,37.66031)"
- id="g4649-7-1">
- <text
- xml:space="preserve"
- x="-1.4697021"
- y="13.642687"
- style="font-style:normal;font-weight:normal;font-size:17.93036652px;font-family:Calibri;text-align:start;text-anchor:start;fill:#000000"
- id="text4651-1-7" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.09798014px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
- d="M 6.6504022,0.48301422 6.4789369,16.185905 c -0.00612,0.364725 -0.3735493,0.655519 -0.8267074,0.655519 -0.4531582,-0.0049 -0.81446,-0.300651 -0.8083362,-0.665376 L 5.0153586,0.46822807 c 0.00612,-0.35979631 0.3735492,-0.6555193 0.8267074,-0.65059058 0.4470344,0.004929 0.8083362,0.30065171 0.8083362,0.66537673 z M 10.575732,14.904439 5.5848681,22.750955 0.77771738,14.830508 Z"
- id="path4653-1-4" />
- </g>
- <path
- inkscape:connector-curvature="0"
- style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.0791635px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-dasharray:none;stroke-opacity:1"
- d="m 293.36368,153.30065 123.82335,0 c 0.30475,0 0.55873,0.34675 0.55873,0.78643 l 0,273.41376 c 0,0.41609 -0.25398,0.76334 -0.55873,0.76334 l -127.32827,0 c -0.32171,0 -0.55875,-0.34675 -0.55875,-0.76334 0,-0.43955 0.23704,-0.7865 0.55875,-0.7865 l 127.32827,0 -0.55875,0.7865 0,-273.41376 0.55875,0.76334 -123.82335,0 c -0.32173,0 -0.57572,-0.34675 -0.57572,-0.76334 0,-0.43953 0.25399,-0.78643 0.57572,-0.78643 z m -2.37047,278.82648 -6.77279,-4.62629 6.77279,-4.6263 z"
- id="path3194-6" />
- <path
- inkscape:connector-curvature="0"
- style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:0.9375px;stroke-linecap:round;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1"
- d="m 240.22321,118.96179 -76.40625,35.43586 76.40625,35.43586 76.40625,-35.43586 z"
- id="path3426" />
- <text
- xml:space="preserve"
- x="225.70447"
- y="149.41039"
- style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3428">Clear?</text>
- <text
- xml:space="preserve"
- x="208.52946"
- y="162.30978"
- style="font-style:normal;font-weight:normal;font-size:11.25px;font-family:Arial;text-align:start;text-anchor:start;fill:#000000"
- id="text3432">Fix provided?</text>
- </g>
-</svg>
+++ /dev/null
- Developer Guides {#dev_guides}
-================
-
-The following documents provide information on OCCT building, development and testing:
-
-* @subpage occt_dev_guides__building "Building OCCT from sources"
-* @subpage occt_dev_guides__documentation "Documentation system"
-* @subpage occt_dev_guides__coding_rules "Coding Rules"
-* @subpage occt_dev_guides__contribution_workflow "Contribution Workflow"
-* @subpage occt_dev_guides__git_guide "Guide to installing and using Git for OCCT development"
-* @subpage occt_dev_guides__tests "Automatic Testing system"
-* @subpage occt_dev_guides__debug "Debugging tools and hints"
-
-The following documents provide information on OCCT algorithms background:
-
-* @subpage occt_dev_guides__pbr_math "Physically-based Rendering math (PBR for rasterization)"
-
-The following guide provides information relevant to upgrading applications developed with previous versions of OCCT, to recent one:
-
-* @subpage occt_dev_guides__upgrade "Upgrade from previous OCCT versions"
+++ /dev/null
- Documentation System {#occt_dev_guides__documentation}
-======================
-
-@tableofcontents
-
-@section OCCT_DM_SECTION_1 Introduction
-
-This document provides practical guidelines for generation and editing of OCCT user documentation.
-
-@section OCCT_DM_SECTION_2 Prerequisites
-
-You need to have the following software installed to generate the documentation.
-
-**Tcl/Tk**
-Version 8.5 or 8.6: https://www.tcl.tk/software/tcltk/download.html
-
-**Doxygen**
-Version 1.8.4 or above: http://www.doxygen.nl/download.html
-
-**Dot**
-Part of Graphviz software, used by Doxygen for generation of class diagrams in Reference Manual: https://www.graphviz.org/download/
-
-**MiKTeX** or other package providing **pdflatex** command (only needed for generation of PDF documents): https://miktex.org/download
-
-**Inkscape** (only needed for generation of PDF documents containing SVG images): http://www.inkscape.org/download
-
-When generating PDF documentation, **pdflatex** and **inkscape** executables should be accessible by PATH variable.
-You can use *custom.bat* file to add necessary paths to the *PATH* variable.
-
-Note that in the process of PDF generation MiKTeX may need some packages not installed by default.
-We recommend setting option "Install missing packages on-the-fly" to "Ask me first" (default) during MiKTeX installation:
-
-@figure{/dev_guides/documentation/images/documentation_miktex.png,"",320}
-
-On the first run of **pdflatex** it will open a dialog window prompting for installation of missing packages.
-Follow the instructions to proceed (define proxy settings if needed, select a mirror site to download from, etc.).
-
-**MathJax** is used for rendering math formulas in browser (HTML and CHM outputs): http://www.mathjax.org.
-
-By default MathJAX scripts and fonts work on-line and no installation of MathJAX is necessary if Internet is accessible.
-If you need to use OCCT documentation while off-line, you can install a local copy of MatJAX, see https://docs.mathjax.org/en/v2.7-latest/start.html#installing-your-own-copy-of-mathjax.
-See \ref OCCT_DM_SECTION_A_9 for more details on inserting mathematical expressions.
-
-@section OCCT_DM_SECTION_2_1 Documentation Generation
-
-Run command *gendoc* from command prompt (with OCCT directory as current one) to generate OCCT documentation.
-The synopsis is:
-
- gendoc \[-h\] {-refman|-overview} \[-html|-pdf|-chm\] \[-m=<list of modules>|-ug=<list of docs>\] \[-v\] \[-s=<search_mode>\] \[-mathjax=<path>\]
-
-Here the options are:
-
-* Choice of documentation to be generated:
- * <i>-overview</i>: To generate Overview and User Guides (cannot be used with -refman)
- * <i>-refman</i>: To generate class Reference Manual (cannot be used with -overview)
-
-* Choice of output format:
- * <i>-html</i>: To generate HTML files (default, cannot be used with -pdf or -chm)
- * <i>-pdf</i>: To generate PDF files (cannot be used with -refman, -html, or -chm)
- * <i>-chm</i>: To generate CHM files (cannot be used with -html or -pdf)
-
-* Additional options:
- * <i>-m=\<modules_list\></i>: List of OCCT modules (separated with comma), for generation of Reference Manual
- * <i>-ug=\<docs_list\></i>: List of MarkDown documents (separated with comma), to use for generation of Overview / User Guides
- * <i>-mathjax=\<path\></i>: To use local or alternative copy of MathJax
- * <i>-s=\<search_mode\></i>: Specifies the Search mode of HTML documents; can be: none | local | server | external
- * <i>-h</i>: Prints this help message
- * <i>-v</i>: Enables more verbose output
-
-**Note**
-
-* In case of PDF output the utility generates a separate PDF file for each document;
-* In case of HTML output the utility generates a common Table of contents containing references to all documents.
-* In case of CHM output single CHM file is generated
-
-**Examples**
-
-To generate the output for a specific document specify the path to the corresponding MarkDown file (paths relative to *dox* sub-folder can be given), for instance:
-
-~~~~
- > gendoc -overview -ug=dev_guides/documentation/documentation.md
-~~~~
-
-To generate Reference Manual for the whole Open CASCADE Technology library, run:
-~~~~
- > gendoc -refman
-~~~~
-
-To generate Reference Manual for Foundation Classes and Modeling Data modules only, with search option, run:
-~~~~
- > gendoc -refman -m=FoundationClasses,ModelingData,ModelingAlgorithms -s=local
-~~~~
-
-@section OCCT_DM_SECTION_3 Documentation Conventions
-
-This section contains information about file format conventions, directories structure, etc.
-
-@subsection OCCT_DM_SECTION_3_1 File Format
-
-The format used for documentation is MarkDown with Doxygen extensions.
-The MarkDown files have a <i>*.md</i> extension and are based on rules described in \ref OCCT_DM_SECTION_A section.
-
-@subsection OCCT_DM_SECTION_3_2 Directory Structure
-
-@figure{/dev_guides/documentation/images/documentation_folders.png,"",160}
-
-Each document has its own folder if there are any images used in it. These images are stored in *images* subfolder.
-
-If you want to use the same image for several documents, you can place it in *dox/resources* folder.
-
-**Note**: To avoid incorrect image display, use a relative path to the image (starting from *dox* folder). For instance:
-
-
-@verbatim
-@figure{/dev_guides/documentation/images/documentation_test_image.svg,"",420}
-@endverbatim
-
-
-The documentation is generated in subfolder *doc* :
-* *html* -- a directory for generated HTML pages;
-* *pdf* -- a directory for generated PDF files.
-
-@section OCCT_DM_SECTION_4 Adding a New Document
-
-Place a new document in the folder taking into account its logical position in the documentation hierarchy. For instance, the document *svn.md* about the use of SVN to work with OCCT source code can be placed into <i>/dox/dev_guides/</i>.
-
-If there are images in the document, it should be placed in its own folder containing a subfolder for images. For instance:
-* <i> /dox/dev_guides/svn/ </i> -- for *svn.md* file;
-* <i> /dox/dev_guides/svn/images/ </i> -- for images.
-
-Add a relative path to *svn.md* in file <i>dox/FILES.txt</i>. For instance
-
-@verbatim
-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, 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.
-
-@section OCCT_DOC_SECTION_5 Additional Resources
-
-More information about OCCT can be found at http://www.opencascade.com and <br> http://dev.opencascade.org sites.
-
-
-The information on formula syntax can be found at: <br>
-http://en.wikipedia.org/wiki/Help:Displaying_a_formula
-
-More information on MarkDown and Doxygen syntax can be found at: <br>
-http://www.stack.nl/~dimitri/doxygen/manual
-
-@section OCCT_DM_SECTION_A Appendix 1: Document Syntax
-
-A document file in *.md format must start with a proper header defining a caption and a unique tag.
-
-@verbatim
-Documentation System {#dev_guides__documentation}
-=====================
-@endverbatim
-
-The document structure is formed by sections that must be defined consistently.
-
-The document can contain plain text, lists, tables, code snippets, images, math, etc.
-Any specific text elements can be introduced by Markdown language tags or by usual HTML tags.
-
-The table of contents, page numbers (in PDF), and figure numbers (in PDF) are generated automatically.
-
-@subsection OCCT_DM_SECTION_A_1 Headers and hierarchic document structure
-
-Headers of different levels can be specified with the following tags:
-* <i>\@section</i> -- for the first-level headers;
-* <i>\@subsection</i> -- for the second level headers;
-* <i>\@subsubsection</i> -- for the third level headers.
-
-For example:
-
-@verbatim
- @section occt_ocaf_1 Basic Concepts
- @subsection occt_ocaf_1_1 Applications and Documents
- @subsubsection occt_ocaf_1_1_1 The document and the data framework
-@endverbatim
-
-**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.
-
-The numbers are only indicative of a section location in the body of the document. However, duplicate section names in a document inevitably cause errors during generation.
-
-If you insert a section in the middle of a big document, do not renumber the document to the end (which is inefficient and error prone), but choose an arbitrary number or letter, not yet used in the document section naming, and base the naming in this section on it.
-
-The section hierarchy is limited to three levels and further levels cannot be presented in the Table of Contents.
-
-However, the fourth and fifth level headers can be tagged with <i>####</i> and <i>#####</i> correspondingly.
-
-It is also possible to use tags <i>##</i> and <i>###</i> for second and third level headers if you do not wish to show them in the table of contents or make references to them.
-
-@subsection OCCT_DM_SECTION_A_2 Plain Text
-
-A plain text is organized in paragraphs, separated by empty lines in MarkDown source.
-The length of lines is not restricted; it is recommended to put each sentence on a separate line -- this is optimal for easier comparison of different versions of the same document.
-
-To insert special symbols, like \< , \> or \\, prepend them with \\ character: \\\<, \\\>, \\\\, etc.
-To emphasize a word or a group of words, wrap the text with one pair of asterisks (*) or underscores (_) to make it *italic* and two pairs of these symbols to make it **Bold**.
-
-**Note** that if your emphasized text starts or ends with a special symbol, the asterisks may not work. Use explicit HTML tags \<i\>\</i\> and \<b\>\</b\> instead.
-
-
-@subsection OCCT_DM_SECTION_A_3 Lists
-
-To create a bulleted list, start each line with a hyphen or an asterisk,
-followed by a space. List items can be nested. This code:
-
-@verbatim
-* Bullet 1
-* Bullet 2
- - Bullet 2a
- - Bullet 2b
-* Bullet 3
-@endverbatim
-
-produces this list:
-
-* Bullet 1
-* Bullet 2
- * Bullet 2a
- * Bullet 2b
-* Bullet 3
-
-To create a numbered list, start each line with number and a period,
-then a space. Numbered lists can also be nested. Thus this code
-
-@verbatim
-1. List item 1
- 1. Sub-item 1
- 2. Sub-item 2
-2. List item 2
-4. List item 3
-@endverbatim
-
-produces this list:
-
-1. List item 1
- 1. Sub-item 1
- 2. Sub-item 2
-2. List item 2
-3. List item 3
-
-**Note** that numbers of list items in the output are generated so they do not necessarily follow the numbering of source items.
-
-In some cases automatic generation adversely restarts the numbering, i.e. you get list items 1. 1. 1. instead of 1. 2. 3. in the output.
-The use of explicit HTML tags \<ol\>\</ol\> and \<li\>\</li\> can help in this case.
-
-Each list item can contain several paragraphs of text; these paragraphs must
-have the same indentation as text after bullet or number in the numbered list
-item (otherwise numbering will be broken).
-
-Code blocks can be inserted as paragraphs with additional indentation
-(4 spaces more). Note that fenced code blocks do not work within numbered lists
-and their use may cause numeration to be reset.
-
-
-Example of a complex nested list:
-
-1. List item 1
-
- Additional paragraph
-
- code fragment
-
- One more paragraph
-
- 1. Sub-item 1
-
- code fragment for sub-item 1
-
- 2. Sub-item 2
-
- Paragraph for sub-item 2
-
- Yet one more paragraph for list item 1
-
-2. List item 2
-
-
-@subsection OCCT_DM_SECTION_A_4 Tables
-
-A table consists of a header line, a separator line, and at least one row line.
-Table columns are separated by the pipe (|) character. The following example:
-
-@verbatim
-First Header | Second Header
-------------- | -------------
-Content Cell | Content Cell
-Content Cell | Content Cell
-@endverbatim
-
- will produce the following table:
-
-First Header | Second Header
------------- | -------------
-Content Cell | Content Cell
-Content Cell | Content Cell
-
-Column alignment can be controlled via one or two colons at the header separator line:
-
-@verbatim
-| Right | Center | Left |
-| ----: | :----: | :---- |
-| 10 | 10 | 10 |
-| 1000 | 1000 | 1000 |
-@endverbatim
-
-which will looks as follows:
-
-| Right | Center | Left |
-| ----: | :----: | :---- |
-| 10 | 10 | 10 |
-| 1000 | 1000 | 1000 |
-
-Note that each table row should be contained in one line of text; complex tables can be created using HTML tags.
-
-@subsection OCCT_DM_SECTION_A_5 Code Blocks
-
-Paragraphs indented with 4 or more spaces are considered as code fragments and rendered using Courier font.
-Example:
-
- This line is indented by 4 spaces and rendered as a code block.
-
-A fenced code block does not require indentation, and is defined by a pair of "fence lines".
-Such line consists of 3 or more tilde (~) characters on a line.
-The end of the block should have the same number of tildes.
-Thus it is strongly advised to use only three or four tildes.
-
-By default the output is the same as for a normal code block.
-To highlight the code, the developer has to indicate the typical file extension,
-which corresponds to the programming language, after the opening fence.
-For highlighting according to the C++ language, for instance, write the following code (the curly braces and dot are optional):
-
-@verbatim
-~~~{.cpp}
-int func(int a,int b) { return a*b; }
-~~~
-@endverbatim
-
-which will produce:
-~~~{.cpp}
-int func(int a,int b) { return a*b; }
-~~~
-
-Smaller code blocks can be inserted by wrapping with tags <i>\@code</i> and <i>\@endcode</i>.
-
-Verbatim content (same as code but without syntax highlighting) can be inserted by wrapping with tags <i>\@verbatim</i> and <i>\@endverbatim</i>.
-
-@subsection OCCT_DM_SECTION_A_5a Quotes
-
-Text quoted from other sources can be indented using ">" tag. For example:
-
-@verbatim
-> [Regression in 6.9.0] *IGES - Export of a reversed face leads to wrong data*
-@endverbatim
-
-will produce
-
-> [Regression in 6.9.0] *IGES - Export of a reversed face leads to wrong data*
-
-Note that this tag should prefix each line of the quoted text.
-Empty lines in the quoted text, if any, should not have trailing spaces after the ">" (lines with trailing spaces will break the quote block).
-
-@subsection OCCT_DM_SECTION_A_6 References
-
-To insert a reference to a website, it is sufficient to write an URL.
-For example: http://en.wikipedia.org
-
-To insert a reference to a document or its subsection, use command <i>\@ref</i> followed by the document or section tag name.
-For instance, @code @ref OCCT_DM_SECTION_A @endcode will be rendered as @ref OCCT_DM_SECTION_A.
-
-Note that links between documents will not work in PDF output if each document is generated independently.
-Hence it is recommended to add a name of the referenced section after the tag name in the <i>\@ref</i> command (in quotes): this will guarantee that the reference is recognizable for the reader even if the cross-link is not instantiated.
-For instance: @code @ref occt_modat_1 "Geometry Utilities" @endcode will be rendered as @ref occt_modat_1 "Geometry Utilities".
-
-@subsection OCCT_DM_SECTION_A_7 Images
-
-For inserting images into the document use the command <i>\@figure</i>, as follows:
-
-@verbatim
- @figure{/relative/path/to/image/image_file_name.png,"Image caption"}
-@endverbatim
-
-The first argument is a path to the image file, relative to the *dox* folder.
-The supported formats for images are PNG, JPG, and SVG.
-The file extension must be lowercase and correspond to the file format.
-The image file name should have no dots except for the one before extension (names with more than one dot confuse **pdflatex**).
-
-The second argument is optional, it defines the caption for the image to be inserted.
-The caption argument, if given, should be quoted, even if it is a single word.
-Captions are included below the image; in PDF output the images with caption are numbered automatically.
-
-Example:
-
-@verbatim
- @figure{/dev_guides/documentation/images/documentation_test_image.svg,"Test SVG image"}
-@endverbatim
-
-is rendered as:
-
-@figure{/dev_guides/documentation/images/documentation_test_image.svg,"Test SVG image",320}
-
-We recommend using **Inkscape** for creation and edition of vector graphics.
-The graphics created in MS Word Draw and some other vector editors can be copy-pasted to Inkscape and saved as SVG images.
-
-Note that the image that will be included in documentation is the whole page of the Inkscape document; use option "Resize page to content" in menu **File -> Document properties** of Inkscape to fit page dimensions to the picture (adding margins as necessary).
-
-Note that the *figure* command is an alias to the standard Doxygen command *image* repeated twice: once for HTML and then for Latex output (used for PDF generation). Thus if HTML and PDF outputs should include different images or captions, command "image" can be used:
-
-@verbatim
- @image html /relative/path/to/image/occ_logo_for_html.png
- @image latex /relative/path/to/image/occ_logo_for_pdf.png
-@endverbatim
-
-@subsection OCCT_DM_SECTION_A_8 Table Of Contents
-
-Use \@tableofcontents tag to get the table of contents at the beginning of the document.
-
-Actually, it is not strictly necessary now because TreeView option for HTML is used.
-The TOC in the PDF document will be generated automatically.
-
-@subsection OCCT_DM_SECTION_A_9 Formulas
-
-Formulas within MarkDown documents can be defined using LaTeX syntax.
-
-Equations can be written by several ways:
-
-1.Unnumbered displayed formulas that are centered on a separate line.
-These formulas should be put between \@f\[ and \@f\] tags. An example:
-
-@verbatim
-@f[
- |I_2|=\left| \int_{0}^T \psi(t)
- \left\{
- u(a,t)-
- \int_{\gamma(t)}^a
- \frac{d\theta}{k(\theta,t)}
- \int_{a}^\theta c(\xi)u_t(\xi,t)\,d\xi
- \right\} dt
- \right|
-@f]
-@endverbatim
-
-gives the following result:
-
- @f$
- |I_2|=\left| \int_{0}^T \psi(t)
- \left\{
- u(a,t)-
- \int_{\gamma(t)}^a
- \frac{d\theta}{k(\theta,t)}
- \int_{a}^\theta c(\xi)u_t(\xi,t)\,d\xi
- \right\} dt
- \right|
- @f$
-
-2.Formulas can also be put between @verbatim \begin{align} @endverbatim and @verbatim \end{align} @endverbatim tags.
-
- For example:
-
-@verbatim
- \begin{align}
- \dot{x} & = \sigma(y-x) \\
- \dot{y} & = \rho x - y - xz \\
- \dot{z} & = -\beta z + xy
- \end{align}
-@endverbatim
-
- gives the following result:
-@latexonly
- \begin{align}
- \dot{x} & = \sigma(y-x) \\
- \dot{y} & = \rho x - y - xz \\
- \dot{z} & = -\beta z + xy
- \end{align}
-@endlatexonly
-
-@htmlonly
- \begin{align}
- \dot{x} & = \sigma(y-x) \\
- \dot{y} & = \rho x - y - xz \\
- \dot{z} & = -\beta z + xy
- \end{align}
-@endhtmlonly
-
-3.Inline formulas can be specified using this syntax:
-
-@verbatim
- @f$ \sqrt{3x-1}+(1+x)^2 @f$
-@endverbatim
-
- that leads to the following result: @f$ \sqrt{3x-1}+(1+x)^2 @f$
-
+++ /dev/null
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!-- Created with Inkscape (http://www.inkscape.org/) -->
-
-<svg
- xmlns:dc="http://purl.org/dc/elements/1.1/"
- xmlns:cc="http://creativecommons.org/ns#"
- xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
- xmlns:svg="http://www.w3.org/2000/svg"
- xmlns="http://www.w3.org/2000/svg"
- xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
- xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
- width="443.5307"
- height="187.48862"
- id="svg2"
- version="1.1"
- inkscape:version="0.48.4 r9939"
- sodipodi:docname="test_image.svg">
- <defs
- id="defs4" />
- <sodipodi:namedview
- id="base"
- pagecolor="#ffffff"
- bordercolor="#666666"
- borderopacity="1.0"
- inkscape:pageopacity="0.0"
- inkscape:pageshadow="2"
- inkscape:zoom="0.35"
- inkscape:cx="295.90235"
- inkscape:cy="-323.77532"
- inkscape:document-units="px"
- inkscape:current-layer="layer1"
- showgrid="false"
- inkscape:window-width="1366"
- inkscape:window-height="716"
- inkscape:window-x="-8"
- inkscape:window-y="-8"
- inkscape:window-maximized="1"
- inkscape:snap-page="false"
- borderlayer="false"
- fit-margin-top="5"
- fit-margin-left="5"
- fit-margin-right="5"
- fit-margin-bottom="5" />
- <metadata
- id="metadata7">
- <rdf:RDF>
- <cc:Work
- rdf:about="">
- <dc:format>image/svg+xml</dc:format>
- <dc:type
- rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
- <dc:title />
- </cc:Work>
- </rdf:RDF>
- </metadata>
- <g
- inkscape:label="Layer 1"
- inkscape:groupmode="layer"
- id="layer1"
- transform="translate(-79.097656,-21.098232)">
- <path
- sodipodi:type="spiral"
- style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
- id="path2985"
- sodipodi:cx="142.85715"
- sodipodi:cy="126.6479"
- sodipodi:expansion="1"
- sodipodi:revolution="3"
- sodipodi:radius="73.178566"
- sodipodi:argument="-18.174814"
- sodipodi:t0="0"
- d="m 142.85715,126.6479 c 2.86505,2.29205 -1.67612,4.99285 -3.80953,4.76191 -5.78142,-0.62584 -7.49143,-7.75205 -5.71428,-12.38096 3.17892,-8.28004 13.59119,-10.36558 20.95239,-6.66665 10.80286,5.42832 13.31404,19.50561 7.61903,29.52381 -7.59056,13.35269 -25.44626,16.29352 -38.09525,8.5714 -15.91746,-9.71749 -19.28891,-31.39926 -9.52378,-46.66667 11.82689,-18.490884 37.35922,-22.29349 55.23811,-10.476151 21.06966,13.926321 25.30383,43.323481 11.42852,63.809531 -16.01959,23.65196 -49.29063,28.31803 -72.38096,12.3809 C 82.334702,151.39625 77.236493,114.2452 95.238126,88.552628 115.43324,59.729444 156.46861,54.198885 184.76195,74.26698 c 31.41097,22.27939 37.37404,67.20227 15.23802,98.09525" />
- <text
- xml:space="preserve"
- style="font-size:40px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
- x="225.71429"
- y="55.219326"
- id="text2987"
- sodipodi:linespacing="125%"><tspan
- sodipodi:role="line"
- id="tspan2989"
- x="225.71429"
- y="55.219326">Test SVG image</tspan></text>
- <path
- style="fill:#d40000"
- id="path2996"
- d="m 225.93253,80.077991 c 3.24312,6.556366 8.29882,11.800272 13.5792,16.763957 4.5107,4.980932 7.56994,10.929012 10.6621,16.828992 2.61039,5.79272 3.86714,11.94331 7.08009,17.44901 3.75425,6.35398 6.70021,13.19689 8.79217,20.27197 4.84784,15.88966 11.74851,2.45314 -37.25143,18.61001 -0.78487,0.2588 0.15562,-1.64589 0.20424,-2.47091 0.0536,-0.90872 0.0682,-1.81932 0.10224,-2.72899 0.17911,-6.50471 -0.15488,-13.01656 0.28271,-19.50992 0.46019,-6.30504 2.24023,-12.34988 4.0286,-18.37582 2.36519,-5.44796 6.30711,-10.00347 9.73908,-14.79837 3.98599,-5.97976 8.02146,-11.96839 13.10341,-17.072556 4.37574,-4.432922 8.35123,-9.243914 12.37764,-13.99199 4.43478,-4.829914 10.15101,-8.139537 15.06208,-12.425011 14.95925,-12.429871 35.2123,-18.385688 51.95332,-26.62658 11.5059,-5.663868 -23.27039,10.786567 -34.90558,16.179851 17.6228,-9.547136 35.52389,-19.290175 55.17352,-23.555822 4.29932,-0.713125 2.15416,-0.406331 6.43505,-0.923403 0,0 -35.68459,22.595324 -35.68459,22.595324 l 0,0 c -4.12774,0.727408 -2.06126,0.312559 -6.19873,1.248113 -3.11612,0.864072 -6.22731,1.766121 -9.25625,2.908329 -0.8427,0.317783 -3.30812,1.424428 -2.49421,1.03881 40.69568,-19.281166 46.47137,-22.237336 32.54467,-15.189227 -79.1837,37.555094 -31.13152,14.703661 -6.06008,3.03043 4.62777,-2.154687 -15.27783,7.276298 -11.28272,6.532336 -1.75524,1.522667 -3.27126,3.31763 -5.09432,4.758404 -3.18452,2.516733 -7.13492,4.190007 -9.93487,7.239896 -4.62518,4.303389 -8.28044,9.606276 -12.50569,14.296007 -0.80437,0.69437 -4.493,3.820284 -5.21444,4.670532 -2.98505,3.518007 -5.33483,7.691189 -8.08882,11.393589 -2.92337,4.905278 -6.62131,9.277358 -10.15131,13.755678 -2.01215,5.68475 -3.56944,11.57461 -4.40544,17.54154 -0.83081,6.35553 -0.13439,12.77693 -0.29528,19.17264 -0.0102,1.50844 -0.0276,5.46288 -0.0732,5.48876 -34.08891,19.36365 -36.17581,33.13461 -40.63381,14.4297 -1.84609,-6.79718 -4.68694,-13.28977 -8.31428,-19.32972 -3.24304,-5.58446 -4.82126,-11.64528 -7.31615,-17.57296 -2.8174,-5.54315 -5.55105,-11.15816 -9.9264,-15.68612 -5.41001,-5.49645 -10.6705,-11.1173 -14.41843,-17.919019 0,0 38.38591,-18.02746 38.38591,-18.02746 z"
- inkscape:connector-curvature="0"
- transform="translate(84.097656,26.098232)" />
- </g>
-</svg>
+++ /dev/null
-Guide to installing and using Git for OCCT development {#occt_dev_guides__git_guide}
-=================================
-
-@tableofcontents
-
-@section occt_gitguide_1 Overview
-
-@subsection occt_gitguide_1_1 Purpose
-
- The purpose of this document is to provide a practical introduction to Git
- 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.
-
- 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 https://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.
-
- 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
- of the OCCT development portal at https://dev.opencascade.org/index.php?q=home/resources.
-
-@subsection occt_gitguide_1_2 Git URL
-
- URL of the official OCCT source code Git repository (accessed by SSH protocol) is:
-
- gitolite@git.dev.opencascade.org:occt
-
- or
-
- ssh://gitolite@dev.opencascade.org/occt.git
-
-@subsection occt_gitguide_1_3 Content
-
-The official repository contains:
-
- * The current certified version of OCCT: the "master" branch. This branch is updated by the Bugmaster only. Official OCCT releases are marked by tags.
- * Topic branches created by contributors to submit changes for review / testing or for collaborative development. The topic branches should be named by the pattern "CR12345" where 12345 is the ID of the relevant issue registered in Mantis (without leading zeroes), and "CR" stands for "Change Request". The name can have an additional postfix used if more than one branch was created for the same issue.
- * Occasionally topic branches with non-standard names can be created by the Bugmaster for special needs.
-
-@subsection occt_gitguide_1_4 Short rules of use
-
- The name specified in the user.name field in Git configuration should correspond
- to your login name on the OCCT development portal.
- This is important to clearly identify the authorship of commits.
- (The full real name can be used as well; in this case add the login username in parentheses.)
-
- By default, contributors are allowed to push branches only with the names starting with CR
- (followed by the relevant Mantis issue ID).
- Possibility to work with other branches can be enabled by the Bugmaster on request.
-
- The branch is created by the developer in his local repository when the development of a contribution starts.
- The branch for new developments is to be created from the current master.
- The branch for integration of patches or developments based on an obsolete version
- is created from a relevant tag or commit. The branch should be pushed to the official repo
- only when sharing with other people (for collaborative work or review / testing) is needed.
-
- Rebasing the local branch to the current master is encouraged before the first submission
- to the official repository. If rebasing was needed after the branch is pushed to the official repo,
- the rebased branch should have a different name (use suffix).
-
- Integration of contributions that have passed certification testing is made exclusively by the Bugmaster.
- Normally this is made by rebasing the contribution branch on the current master
- and squashing it into a single commit. This is made to have the master branch history plain and clean,
- following the general rule “one issue -- one commit”.
- The description of the commit integrated to the master branch is taken from the Mantis issue
- (ID, 'Summary', followed by the information from 'Documentation' field if present).
-
- In special cases when it is important to save the commits history in the branch
- (e.g. in case of a long-term development integration) it can be integrated by merge (no fast-forward).
-
- The authorship of the contribution is respected by preserving the Author field of the commit when integrating.
- Branches are removed from the official repository when integrated to the master.
- The Bugmaster can also remove branches which have no commits during one-month period.
-
- The Bugmaster may ask the developer (normally the one who produced the contribution)
- to rebase a branch on the current master, in the case if merge conflicts appear during integration.
-
-@subsection occt_gitguide_1_5 Version of Git
-
- The repository is tested to work with Git 1.7.6 and above.
- Avoid using versions below 1.7.1 as they are known to cause troubles.
-
-@section occt_gitguide_2 Installing Tools for Work with Git
-
-@subsection occt_gitguide_2_1 Windows platform
-
- Installation of Git for Windows (provided by MSysGit project) is required.
-
- In addition, it is recommended to install TortoiseGit to work with Git on Windows.
- If you do not install TortoiseGit or any other GUI tool,
- you can use GitGui and Gitk GUI tools delivered with Git and available on all platforms.
-
-@subsubsection occt_gitguide_2_1_1 Installation of Git for Windows
-
- Download Git for Windows distributive from https://git-for-windows.github.io/
- During the installation:
-
- * Check-in "Windows Explorer integration" options:
- * "Git Bash Here";
- * "Git GUI Here".
- * To avoid a mess in your PATH, we recommend selecting "Run Git from Windows Prompt" in the environment settings dialog:
- * In "Configuring the line ending conversions" dialog, select "Checkout Windows-style, commit Unix style endings".
-
- Note that by default Git user interface is localized to the system default language.
- If you prefer to work with the English interface, remove or rename .msg localization file
- in subdirectories *share/git-gui/lib/msgs* and *share/gitk/lib/msgs* of the Git installation directory.
-
- Before the first commit to the OCCT repository, make sure that your User Name in the Git configuration file (file <i>.gitconfig</i> in the <i>$HOME</i> directory) is equal to your username on the OCCT development portal.
-
-@subsubsection occt_gitguide_2_1_2 Installation and configuration of TortoiseGit
-
- Download TortoiseGit distributive from https://tortoisegit.org/download/.
- Launch the installation.
-
- * Select your SSH client. Choose option
- * "OpenSSH, Git default SSH Client" if you prefer to use command-line tools for SSH keys generation, or
- * "TortoisePLink, coming from Putty, integrates with Windows better" if you prefer to use GUI tool (PuttyGen, see 3.2).
- * Complete the installation.
-
- TortoiseGit integrates into Windows Explorer, thus it is possible to use context menu in Windows Explorer to access its functionality:
-
-@figure{OCCT_GitGuide_V2_image005.png,"",100}
-
-
-
- Note that if you have installed MSysGit or have Git installed in non-default path,
- on the first time you use TortoiseGit you may get the message demanding to define path to Git.
- In such case, click on **Set MSysGit path** button and add the path to git.exe
- and path to MigGW libraries in the Settings dialog.
-
- * After the installation select Start -> Programs -> TortoiseGit Settings to configure TortoiseGit.
-
- Select Git->Config to add your user name and Email address to the local <i>.gitconfig</i> file
-
- @figure{OCCT_GitGuide_V2_image006.png,"",320}
-
- Optionally, you can set up TortoiseGit to use visual diff utility for SVG images used in OCCT documentation.
- For that, click on item "Diff Viewer" in the Settings dialog, then click button "Advanced..." in the right tab to add a new record with the following parameters:
- - Extension: <code>.svg</code>
- - External program: <code><path_to_OCCT>\\adm\\svgdiff.bat %%base %%mine %%bname %%yname</code>
-
-@figure{OCCT_GitGuide_V2_svgdiff.png,"",709}
-
-@subsection occt_gitguide_2_2 Linux platform
-
- We assume that Linux users have Git already installed and available in the *PATH*.
-
- Make sure to configure Git so that the user name is equal to your username
- on the OCCT development portal, and set SafeCrLf option to true:
-
-~~~~~
- > git config --global user.name "Your User Name"
- > git config --global user.email your@mail.address
- > git config --global your@mail.address
-~~~~~
-
-@section occt_gitguide_3 Getting access to the repository
-
-@subsection occt_gitguide_3_1 Prerequisites
-
- Access to the repository is granted to the users who have signed the Contributor License Agreement.
-
- The repository is accessed by SSH protocol, thus you need to register your public SSH key
- on the development portal to get access to the repository.
-
- SSH keys are used for secure authentication of the user when accessing the Git server.
- Private key is the one stored on the user workstation (optionally encrypted).
- Open (or public) key is stored in the user account page on the web site.
- When Git client accesses the remote repository through SSH,
- it uses this key pair to identify the user and acquire relevant access rights.
-
- Normally when you have Git installed, you should have also SSH client available.
- On Unix/Linux it is installed by default in the system.
- On Windows it is typical to have several SSH clients installed;
- in particular they are included with Cygwin, Git, TortoiseGit.
-
- It is highly recommended to use the tools that come
- with the chosen Git client for generation of SSH keys.
- Using incompatible tools (e.g. *ssh-keygen.exe* from Cygwin for code generation,
- and TortoiseGit GUI with a default Putty client for connection to server)
- may lead to authentication problems.
-
-@subsection occt_gitguide_3_2 How to generate a key
-
-@subsubsection occt_gitguide_3_2_1 Generating key with Putty
-
- Use this option if you have installed TortoiseGit (or other GUI Git client on Windows)
- and have chosen “TortoisePLink” (or other Putty client) as SSH client during installation.
-
- To generate the key with this client, run **Puttygen** (e.g. from Start menu -> TortoiseGit -> Puttygen),
- then click **Generate** and move mouse cursor over the blank area until the key is generated.
-
-@figure{OCCT_GitGuide_V2_image007.png,"Putty key generator",320}
-
- After the key is generated, you will see GUI controls to define the public key comment
- and / or specify the password for the private key protection.
- When done, save both the public and the private key to the files of your choice
- (make sure to store your private key in a secure place!).
-
- Copy the public key as shown by Puttygen to the clipboard to add it in your account.
- Do not copy the Putty public key file content -- it is formatted in a way not suitable for the web site.
-
-@subsubsection occt_gitguide_3_2_2 Generating key with command-line tools
-
- Use this option if you work on Linux or if you have chosen “OpenSSH” as SSH client
- during installation of TortoiseGit (or other Windows tool).
-
- Make sure that you have *ssh* and *ssh-keygen* commands in the path.
- On Windows, you might need to start **Git Bash** command prompt window.
-
- Use the following command to generate SSH keys:
-~~~~~
- > ssh-keygen -t rsa -C "your@mail.address"
-~~~~~
-
- The last argument is an optional comment, which can be included with the public key and used to distinguish between different keys (if you have many). The common practice is to put here your mail address or workstation name.
-
- The command will ask you where to store the keys. It is recommended to accept the default path <i>$HOME/.ssh/id_rsa</i>. Just press **Enter** for that. You will be warned if a key is already present in the specified file; you can either overwrite it by the new one, or stop generation and use the old key.
-
- If you want to be on the safe side, enter password to encrypt the private key. You will be asked to enter this password each time you use that key (e.g. access a remote Git repository), unless you use the tool that caches the key (like TortoiseGit). If you do not want to bother, enter an empty string.
-
- On Windows, make sure to note the complete path to the generated files (the location of your $HOME might be not obvious). Two key files will be created in the specified location (by default in $HOME/.ssh/):
-
- * *id_rsa* -- private key
- * *id_rsa.pub* -- public key
-
- The content of the public key file (one text line) is the key to be added to the user account on the site (see below).
-
-@subsubsection occt_gitguide_3_2_3 Generating key with Git GUI
-
- GitGUI (standard GUI interface included with Git) provides the option
- to either generate the SSH key (if not present yet) or show the existing one.
- Click Help/Show SSH key and copy the public key content for adding to the user account page (see below).
-
-@subsection occt_gitguide_3_3 Adding public key in your account
-
-Log in on the portal https://dev.opencascade.org and click on **My account** link to the right. If you have a Contributor status, you will see **SSH keys** tab to the right.
-
-Click on that tab, then click **Add a public key**, and paste the text of the public key (see above sections on how to generate the key) into the text box.
-
-Click **Save** to input the key to the system.
-
- Note that a user can have several SSH keys.
- You can distinguish between these keys by the Title field ID; by default it is taken from SSH key comment.
- It is typical to use your e-mail address or workstation name for this field; no restrictions are set by the portal.
-
-
- **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.
-
-@section occt_gitguide_4 Work with repository: developer operations
-
-@subsection occt_gitguide_4_1 General workflow
-
- To start working with OCCT source repository, you need to create its clone in your local system.
- This cloned repository will manage your working copy of the sources
- and provide you the means to exchange code between your clone and the origin.
-
- In most cases it is sufficient to have one clone of the repository;
- your working copy will be updated automatically by Git when you switch branches.
-
- The typical development cycle for an issue is as follows:
-
- * Create a new branch for your development, basing on the selected version of the sources
- (usually the current master) and switch your working copy to it
- * Develop and test your change.
- * Do as many commits in your branch as you feel convenient;
- the general recommendation is to commit every stable state (even incomplete), to record the history of your development.
- * Push your branch to the repository when your development is complete or when you need to share it with other people (e.g. for review)
- * Before the first push, rebase your local branch on the latest master;
- consider collapsing the history in one commit unless you think the history of your commits is interesting for others.
- Make sure to provide a good commit message.
- * Do not amend the commits that have been already pushed in the remote repository,
- If you need to rebase your branch, commit the rebased branch under a different name, and remove the old branch.
-
- You can switch to another branch at any moment
- (unless you have some uncommitted changes in the working copy)
- and return back to the branch when necessary (e.g. to take into account review remarks).
- Note that only the sources that are different between the switched branches will be modified,
- thus required recompilation should be reasonably small in most cases.
-
-@subsection occt_gitguide_4_2 Cloning official repository
-
- Clone the official OCCT repository in one of following ways:
-
- * From command line by command:
-
-~~~~~
- > git clone gitolite@git.dev.opencascade.org:occt <path>
-~~~~~
-
- where <i>\<path\></i> is the path to the new folder which will be created for the repository.
-
- * In TortoiseGit: create a new folder, open it and right-click in the Explorer window, then choose **Git Clone** in the context menu:
-
-@figure{OCCT_GitGuide_V2_image009.png,"",320}
-
- If you have chosen Putty as SSH client during TortoiseGit installation, check the **Load Putty Key** option and specify the location of the private key file saved by PuttyGen (see 3.2.1). This shall be done for the first time only.
-
- Note that on the first connection to the repository server you may be requested to enter a password for your private SSH key; further you can get a message that the authenticity of the host cannot be established and will be asked if you want to continue connecting or not. Choose **Yes** to continue. The host’s key will be stored in <i>$HOME/.ssh/known_hosts</i> file.
-
-@subsection occt_gitguide_4_3 Branch creation
-
- You need to create a branch when you are going to start development of a new change,
- apply a patch, etc. It is recommended to fetch updates from the remote repository
- before this operation, to make sure you work with the up-to-date version.
-
- Create a branch from the current master branch unless you need to base your development on a particular version or revision.
-
-In the console:
-
-~~~~~
- > git checkout -b CR12345 origin/master
-~~~~~
-
-In TortoiseGit:
- * Go to the local copy of the repository.
- * Right-click in the Explorer window, then choose **Git Create Branch**.
- * Select **Base On** Branch *remotes/origin/master*.
-
-@figure{OCCT_GitGuide_V2_image012.png,"",320}
-
- Check option **Switch to new branch** if you are going to start working with the newly created branch immediately.
-
-@subsection occt_gitguide_4_4 Branch switching
-
- If you need to switch to another branch, use Git command checkout for that.
- In the console:
-
-~~~~~
- > git checkout CR12345
-~~~~~
-
- In TortoiseGit: right-click in the explorer window and select in the context menu **TortoiseGit** -> **Switch/Checkout**.
-
-@figure{OCCT_GitGuide_V2_image013.png,"",320}
-
- Note that in order to work with the branch locally you need to set option
- **Create new branch** when you checkout the branch from the remote repository for the first time.
- Option **Track** stores association between the local branch and the original branch in a remote repository.
-
-@subsection occt_gitguide_4_5 Committing branch changes
-
- Commit your changes locally as soon as a stable status of the work is reached.
- Make sure to review carefully the committed changes beforehand to avoid unintentional commit of a wrong code.
-
- * In the console:
-
-~~~~~
- > git diff
- …
- > git commit -a -m "Write meaningful commit message here"
-~~~~~
-
- Option -a tells the command to automatically include (stage) files
- that have been modified or deleted, but it will omit the new files that might have been added by you.
- To commit such new files, you must add (stage) them before commit command.
-
- To find new unstaged files and them to commit, use commands:
-
-~~~~~
- > git status -s
- ?? file1.hxx
- ?? file2.cxx
- > git add file1.hxx file2.cxx
-~~~~~
-
- * In TortoiseGit: right-click in the explorer window and select in the context menu <b>Git Commit -> CR…</b>:
-
-@figure{OCCT_GitGuide_V2_image014.png,"",320}
-
- Unstaged files will be shown if you check the option ‘Show Unversioned Files’.
- Double-click on each modified file to see the changes to be committed (as a difference vs. the base version).
-
-@subsection occt_gitguide_4_6 Pushing branch to the remote repository
-
- When the code developed in your local branch is ready for review,
- or you need to share it with others, push your local changes to the remote repository.
-
- * In the console:
-
-~~~~~
- > git push "origin" CR12345:CR12345
-~~~~~
-
- * In TortoiseGit: right-click in the explorer window and select in the context menu, TortoiseGit -> **Push**
-
-@figure{OCCT_GitGuide_V2_image015.png,"",320}
-
-Note that Git forbids pushing a branch if the corresponding remote branch already exists and has some changes, which are not in the history of your local branch. This may happen in different situations:
- * You have amended the last commit which is already in the remote repository. If you are sure that nobody else uses your branch, push again with **Force** option.
- * You have rebased your branch, so that now it is completely different from the branch in the remote repository. In this case, push it under a different name (add a suffix):
-
-@figure{OCCT_GitGuide_V2_image016.png,"",320}
-
- Then remove the original remote branch so that other people recognize that it has been replaced by the new one. For that, select TortoiseGit -> **Push** again, select an empty line for your local branch name,
- and enter the name of the branch to be removed in **Remote** field:
-
- * The other developer has committed some changes in the remote branch. In this case, **Pull** changes from the remote repository to have them merged with your version, and push your branch after it is successfully merged.
-
-@subsection occt_gitguide_4_7 Synchronizing with remote repository
-
- Maintain your repository synchronized with the remote one and clean unnecessary stuff regularly.
-
- Use Git command *fetch* with option *prune* to get the update of all branches from the remote repository and to clean your local repository from the remote branches that have been deleted.
-
- * In the console:
-~~~~~
- > git fetch --prune
-~~~~~
-
- * In TortoiseGit: right-click in the explorer window and select in the context menu **TortoiseGit** -> **Fetch**. Check in **Prune** check-box.
-
-@figure{OCCT_GitGuide_V2_image018.png,"",320}
-
- If the branch you are working with has been changed in the remote repository, use Git command *pull* to get the remote changes and merge them with your local branch.
-
- This operation is required in particular to update your local master branch when the remote master changes.
-
- * In console:
-~~~~~
- > git pull
-~~~~~
-
- * In TortoiseGit: right-click in the explorer window and select in the context menu **TortoiseGit** -> **Pull**.
-
-@figure{OCCT_GitGuide_V2_image019.png,"",320}
-
-Note that the local branches of your repository are the primary place, where your changes are stored until they get integrated to the official version of OCCT (master branch). The branches submitted to official repository are for collaborative work, review, and integration -- that repository should not be used for long-term storage of incomplete changes.
-
-Remove the local branches that you do not need any more. Note that you cannot delete the current branch. It means that you need to switch to another one (e.g. master) if the branch you are going to delete is the current one.
-
- * In the console:
-~~~~~
- > git branch -d CR12345
-~~~~~
-
- * In TortoiseGit: right-click in the explorer window and select in the context menu **TortoiseGit** -> **Git Show Log**.
-
-@figure{OCCT_GitGuide_V2_image020.png,"",420}
-
- Select **All branches** check-box to view all branches.
- Right-click on the branch you want to delete and select **Delete** item in the context menu.
-
-Note that many functions described above can be accessed from the Log View, which is a very convenient tool to visualize and manage branches.
-
-@subsection occt_gitguide_4_8 Applying a fix made on older version of OCCT
-
-If you have a fix made on a previous version of OCCT, perform the following sequence of operations to prepare it for testing and integration to the current development version:
- * Identify the version of OCCT on which the fix has been made. In most cases, this will be an OCCT release, e.g. OCCT 6.7.0.
- * Find a tag or a commit corresponding to this version in the Git history log of the master branch.
- * Create a branch basing on this tag or commit. In TortoiseGit history log: right-click on the base commit, then select **Create branch at this version**.
-
-@figure{OCCT_GitGuide_V2_image021.png,"",320}
-
- * Check option **Switch to the new branch** to start working within the new branch immediately, or switch to it separately afterwards.
- * Put your fix in the working copy, build and check that it works, then commit to the branch.
- * Rebase the branch on the current master. In TortoiseGit: right-click on the working directory, choose **TortoiseGit** -> **Rebase**, select *remotes/origin/master* as UpStream revision, and click **Start**:
-
-@figure{OCCT_GitGuide_V2_image022.png,"",320}
-
-Note that you can get some conflicts during rebase. To resolve them, double-click on each conflicted file (highlighted by red in the file list) to open visual merge tool. Switch between conflicting fragments by red arrows, and for each one decide if the code of one or both conflicting versions is to be taken.
-
-@subsection occt_gitguide_4_9 Rebasing with history clean-up
-
-At some moments you might need to rebase your branch on the latest version of the master.
-
-We recommend rebasing before the first submission of the branch for review or when the master has diverged substantially from your branch.
-
-Rebasing is a good occasion to clean-up the history of commits in the branch. Consider collapsing (squashing, in terms of Git) the history of your branch into a single commit unless you deem that having separate commits is important for your future work with the branch or its code reviewing. Git also allows changing the order of commits, edit commit contents and messages, etc.
-
-To rebase your branch into a single commit, you need to do the following:
- * Switch to your branch (e.g. “CR12345”)
- * In TortoiseGit history log, select a branch to rebase on <i>(remotes/origin/master)</i> and in the context menu choose **Rebase “CR12345” onto this**.
- * In the **Rebase** dialog, check **Squash All**. You can also change the order of commits and define for each commit whether it should be kept (**Pick**), edited, or just skipped.
-
-@figure{OCCT_GitGuide_V2_image023.png,"",320}
-
- * Click **Start**.
- * The process will stop if a conflict is detected. In that case, find files with status **Conflicted** in the list (marked by red), and double-click on them to resolve the conflict. When all conflicts are resolved, click **Continue**.
-
-@figure{OCCT_GitGuide_V2_image024.png,"",320}
-
- * At the end of the process, edit the final commit message (it should start from the issue ID and a description from Mantis in the first line, followed by a summary of actual changes), and click **Commit**.
-
-@figure{OCCT_GitGuide_V2_image025.png,"",320}
-
-@section occt_gitguide_5 Work with repository: Reviewer operations
-
-@subsection occt_gitguide_5_1 Review branch changes using GitWeb
-
- The changes made in the branch can be reviewed without direct access to Git, using GitWeb interface:
-
- * Open GitWeb in your web browser: https://git.dev.opencascade.org/gitweb/?p=occt.git
- * Locate the branch you want to review among **heads** (click ‘…’ at the bottom of the page to see the full list).
- * Click **log** (or **shortlog**) to see the history of the branch.
-
- **Note** that the branch can contain more than one commit, and you need to distinguish commits that belong to that branch (those to be reviewed) from the commits corresponding to the previous state of the master branch. Normally the first commit in the list that starts from the ID of the other issue indicates the branching point; commits above it are the ones to be reviewed.
-
- * Click **commitdiff** on each log entry to review the changes (highlighted with color format).
-
-@subsection occt_gitguide_5_2 Review branch changes with TortoiseGit
-
- Use of TortoiseGit is recommended for convenient code review:
-
- * 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.
- * To review all changes made in the branch at once, or to compare two arbitrary revisions, select the corresponding commits in the log (e.g. the last commit in the branch and the branching point), ight-click for the context menu, and choose **Compare revisions**.
-
-@figure{OCCT_GitGuide_V2_image026.png,"",320}
-
-
+++ /dev/null
- Automated Testing System {#occt_dev_guides__tests}
-======================================
-
-@tableofcontents
-
-@section testmanual_intro Introduction
-
-This document provides OCCT developers and contributors with an overview and practical guidelines for work with OCCT automatic testing system.
-
-Reading the Introduction should be sufficient for developers to use the test system to control non-regression of the modifications they implement in OCCT. Other sections provide a more in-depth description of the test system, required for modifying the tests and adding new test cases.
-
-@subsection testmanual_intro_basic Basic Information
-
-OCCT automatic testing system is organized around @ref occt_user_guides__test_harness "DRAW Test Harness", a console application based on Tcl (a scripting language) interpreter extended by OCCT-related commands.
-
-Standard OCCT tests are included with OCCT sources and are located in subdirectory *tests* of the OCCT root folder. Other test folders can be included in the test system, e.g. for testing applications based on OCCT.
-
-The tests are organized in three levels:
-
- * Group: a group of related test grids, usually testing a particular OCCT functionality (e.g. blend);
- * 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 @ref testmanual_5_1 "Test Groups" chapter for the current list of available test groups and grids.
-
-@note Many tests involve data files (typically CAD models) which are located separately and (except a few) are not included with OCCT code.
-These tests will be skipped if data files are not available.
-
-@subsection testmanual_1_2 Intended Use of Automatic Tests
-
-Each modification made in OCCT code must be checked for non-regression
-by running the whole set of tests. The developer who makes the modification
-is responsible for running and ensuring non-regression for the tests available to him.
-
-Note that many tests are based on data files that are confidential and thus available only at OPEN CASCADE.
-The official certification testing of each change before its integration to master branch of official OCCT Git repository (and finally to the official release) is performed by OPEN CASCADE to ensure non-regression on all existing test cases and supported platforms.
-
-Each new non-trivial modification (improvement, bug fix, new feature) in OCCT should be accompanied by a relevant test case suitable for verifying that modification. This test case is to be added by the developer who provides the modification.
-
-If a modification affects the result of an existing test case, either the modification should be corrected (if it causes regression) or the affected test cases should be updated to account for the modification.
-
-The modifications made in the OCCT code and related test scripts should be included in the same integration to the master branch.
-
-@subsection testmanual_1_3 Quick Start
-
-@subsubsection testmanual_1_3_1 Setup
-
-Before running tests, make sure to define environment variable *CSF_TestDataPath* pointing to the directory containing test data files.
-
-For this it is recommended to add a file *DrawAppliInit* in the directory which is current at the moment of starting DRAWEXE (normally it is OCCT root directory, <i>$CASROOT </i>). This file is evaluated automatically at the DRAW start.
-
-Example (Windows)
-
-~~~~~{.tcl}
-set env(CSF_TestDataPath) $env(CSF_TestDataPath)\;d:/occt/test-data
-~~~~~
-
-Note that variable *CSF_TestDataPath* is set to default value at DRAW start, pointing at the folder <i>$CASROOT/data</i>.
-In this example, subdirectory <i>d:/occt/test-data</i> is added to this path. Similar code could be used on Linux and Mac OS X except that on non-Windows platforms colon ":" should be used as path separator instead of semicolon ";".
-
-All tests are run from DRAW command prompt (run *draw.bat* or *draw.sh* to start it).
-
-@subsubsection testmanual_1_3_2 Running Tests
-
-To run all tests, type command *testgrid*
-
-Example:
-
-~~~~~
-Draw[]> testgrid
-~~~~~
-
-To run only a subset of test cases, give masks for group, grid, and test case names to be executed.
-Each argument is a list of file masks separated with commas or spaces; by default "*" is assumed.
-
-Example:
-
-~~~~~
-Draw[]> testgrid bugs caf,moddata*,xde
-~~~~~
-
-As the tests progress, the result of each test case is reported.
-At the end of the log a summary of test cases is output,
-including the list of detected regressions and improvements, if any.
-
-
-Example:
-
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
- Tests summary
-
- CASE 3rdparty export A1: OK
- ...
- CASE pipe standard B1: BAD (known problem)
- CASE pipe standard C1: OK
- No regressions
- Total cases: 208 BAD, 31 SKIPPED, 3 IMPROVEMENT, 1791 OK
- Elapsed time: 1 Hours 14 Minutes 33.7384512019 Seconds
- 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 @ref testmanual_details_results "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 <i> -outdir</i> followed by a path to the directory. This directory should be new or empty; use option <i>-overwrite</i> to allow writing results in the existing non-empty directory.
-
-Example:
-~~~~~
-Draw[]> testgrid -outdir d:/occt/last_results -overwrite
-~~~~~
-In the output directory, a cumulative HTML report <i>summary.html</i> provides links to reports on each test case. An additional report in JUnit-style XML format can be output for use in Jenkins or other continuous integration system.
-
-To re-run the test cases, which were detected as regressions on the previous run, option <i>-regress dirname</i> should be used.
-<i>dirname</i> is a path to the directory containing the results of the previous run. Only the test cases with *FAILED* and *IMPROVEMENT* statuses will be tested.
-
-Example:
-~~~~~
-Draw[]> testgrid -regress d:/occt/last_results
-~~~~~
-
-Type <i>help testgrid</i> in DRAW prompt to get help on options supported by *testgrid* command:
-
-~~~~~
-Draw[3]> help testgrid
-testgrid: Run all tests, or specified group, or one grid
- Use: testgrid [groupmask [gridmask [casemask]]] [options...]
- Allowed options are:
- -parallel N: run N parallel processes (default is number of CPUs, 0 to disable)
- -refresh N: save summary logs every N seconds (default 60, minimal 1, 0 to disable)
- -outdir dirname: set log directory (should be empty or non-existing)
- -overwrite: force writing logs in existing non-empty directory
- -xml filename: write XML report for Jenkins (in JUnit-like format)
- -beep: play sound signal at the end of the tests
- -regress dirname: re-run only a set of tests that have been detected as regressions on the previous run.
- Here "dirname" is a path to the directory containing the results of the previous run.
- Groups, grids, and test cases to be executed can be specified by the list of file
- masks separated by spaces or commas; default is all (*).
-~~~~~
-
-@subsubsection testmanual_1_3_3 Running a Single Test
-
-To run a single test, type command *test* followed by names of group, grid, and test case.
-
-Example:
-
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
- Draw[1]> test blend simple A1
- CASE blend simple A1: OK
- Draw[2]>
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Note that normally an intermediate output of the script is not shown. The detailed log of the test can be obtained after the test execution by running command <i>"dlog get"</i>.
-
-To see intermediate commands and their output during the test execution, add one more argument
-<i>"echo"</i> at the end of the command line. Note that with this option the log is not collected and summary is not produced.
-
-Type <i>help test</i> in DRAW prompt to get help on options supported by *test* command:
-
-~~~~~
-Draw[3]> help test
-test: Run specified test case
- Use: test group grid casename [options...]
- Allowed options are:
- -echo: all commands and results are echoed immediately,
- but log is not saved and summary is not produced
- It is also possible to use "1" instead of "-echo"
- If echo is OFF, log is stored in memory and only summary
- is output (the log can be obtained with command "dlog get")
- -outfile filename: set log file (should be non-existing),
- it is possible to save log file in text file or
- in html file(with snapshot), for that "filename"
- should have ".html" extension
- -overwrite: force writing log in existing file
- -beep: play sound signal at the end of the test
- -errors: show all lines from the log report that are recognized as errors
- This key will be ignored if the "-echo" key is already set.
-~~~~~
-
-@subsubsection testmanual_intro_quick_create Creating a New Test
-
-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 <i>bug</i> 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* <i>($CASROOT/tests/bugs)</i>. 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.)
- * Use DRAW commands to reproduce the tested situation.
- * Make sure that in case of failure the test produces a message containing word "Error" or other recognized by the test system as error (add new error patterns in file parse.rules if necessary).
- * If the test case reports error due to an existing problem and the fix is not available, add @ref testmanual_3_6 "TODO" statement for each error to mark it as a known problem. The TODO statements must be specific so as to match the actually generated messages but not all similar errors.
- * To check expected output which should be obtained as the test result, add @ref testmanual_3_7 "REQUIRED" statement for each line of output to mark it as required.
- * If the test case produces error messages (contained in parse.rules), which are expected in that test and should not be considered as its failure (e.g. test for *checkshape* command), add REQUIRED statement for each error to mark it as required output.
-4. To check whether the data files needed for the test are already present in the database, use DRAW command *testfile* (see below).
- If the data file is already present, use it for a new test instead of adding a duplicate.
- If the data file(s) are not yet present in the test database, put them to a folder and add it to the environment variable *CSF_TestDataPath* to be found by the test system.
- The location of the data files, which need to be accessed by OCC team and put to the official database, should be provided in the comment to Mantis issue, clearly indicating how the names of the files used by the test script match the actual names of the files.
- The simplest way is to attach the data files to the Mantis issue, with the same names as used by the test script.
-5. Check that the test case runs as expected (test for fix: OK with the fix, FAILED without the fix; test for existing problem: BAD), and integrate it to the Git branch created for the issue.
-
-Example:
-
-* Added files:
-
-~~~~~
-git status -short
-A tests/bugs/heal/data/bug210_a.brep
-A tests/bugs/heal/data/bug210_b.brep
-A tests/bugs/heal/bug210_1
-A tests/bugs/heal/bug210_2
-~~~~~
-
-* Test script
-
-~~~~~{.tcl}
-puts "OCC210 (case 1): Improve FixShape for touching wires"
-
-restore [locate_data_file bug210_a.brep] a
-
-fixshape result a 0.01 0.01
-checkshape result
-~~~~~
-
-DRAW command *testfile* should be used to check the data files used by the test for possible duplication of content or names.
-The command accepts the list of paths to files to be checked (as a single argument) and gives a conclusion on each of the files, for instance:
-
-~~~~~
-Draw[1]> testfile [glob /my/data/path/bug12345*]
-Collecting info on test data files repository...
-Checking new file(s)...
-
-* /my/data/path/bug12345.brep: duplicate
- already present under name bug28773_1.brep
- --> //server/occt_tests_data/public/brep/bug28773_1.brep
-
-* /my/data/path/cadso.brep: new file
- Warning: DOS encoding detected, consider converting to
- UNIX unless DOS line ends are needed for the test
- Warning: shape contains triangulation (946 triangles),
- consider removing them unless they are needed for the test!
- BREP size=201 KiB, nbfaces=33, nbedges=94 -> private
-
-* /my/data/path/case_8_wire3.brep: already present
- --> //server/occt_tests_data/public/brep/case_8_wire3.brep
-
-* /my/data/path/case_8_wire4.brep: error
- name is already used by existing file
- --> //server/occt_tests_data/public/brep/case_8_wire4.brep
-~~~~~
-
-@section testmanual_2 Organization of Test Scripts
-
-@subsection testmanual_2_1 General Layout
-
-Standard OCCT tests are located in subdirectory tests of the OCCT root folder ($CASROOT).
-
-Additional test folders can be added to the test system by defining environment variable *CSF_TestScriptsPath*. This should be list of paths separated by semicolons (*;*) on Windows
-or colons (*:*) on Linux or Mac. Upon DRAW launch, path to *tests* subfolder of OCCT is added at the end of this variable automatically.
-
-Each test folder is expected to contain:
- * Optional file *parse.rules* defining patterns for interpretation of test results, common for all groups in this folder
- * One or several test group directories.
-
-Each group directory contains:
-
- * File *grids.list* that identifies this test group and defines list of test grids in it.
- * Test grids (sub-directories), each containing set of scripts for test cases, and optional files *cases.list*, *parse.rules*, *begin* and *end*.
- * Optional sub-directory data
-
-By convention, names of test groups, grids, and cases should contain no spaces and be lower-case.
-The names *begin, end, data, parse.rules, grids.list* and *cases.list* are reserved.
-
-General layout of test scripts is shown in Figure 1.
-
-@figure{/dev_guides/tests/images/tests_image001.png,"Layout of tests folder",400}
-
-
-@subsection testmanual_2_2 Test Groups
-
-@subsubsection testmanual_2_2_1 Group Names
-
-The names of directories of test groups containing systematic test grids correspond to the functionality tested by each group.
-
-Example:
-
-~~~~~
- caf
- mesh
- offset
-~~~~~
-
-Test group *bugs* is used to collect the tests coming from bug reports. Group *demo* collects tests of the test system, DRAW, samples, etc.
-
-@subsubsection testmanual_2_2_2 File "grids.list"
-
-This test group contains file *grids.list*, which defines an ordered list of grids in this group in the following format:
-
-~~~~~~~~~~~~~~~~~
-001 gridname1
-002 gridname2
-...
-NNN gridnameN
-~~~~~~~~~~~~~~~~~
-
-Example:
-
-~~~~~~~~~~~~~~~~~
- 001 basic
- 002 advanced
-~~~~~~~~~~~~~~~~~
-
-@subsubsection testmanual_2_2_3 File "begin"
-
-This file is a Tcl script. It is executed before every test in the current group.
-Usually it loads necessary Draw commands, sets common parameters and defines
-additional Tcl functions used in test scripts.
-
-Example:
-
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
- pload TOPTEST ;# load topological command
- set cpulimit 300 ;# set maximum time allowed for script execution
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-@subsubsection testmanual_2_2_4 File "end"
-
-This file is a TCL script. It is executed after every test in the current group. Usually it checks the results of script work, makes a snap-shot of the viewer and writes *TEST COMPLETED* to the output.
-
-Note: *TEST COMPLETED* string should be present in the output to indicate that the test is finished without crash.
-
-See @ref testmanual_3 "Creation and modification of tests" chapter for more information.
-
-Example:
-~~~~~
- if { [isdraw result] } {
- checkshape result
- } else {
- puts "Error: The result shape can not be built"
- }
- puts "TEST COMPLETED"
-~~~~~
-
-@subsubsection testmanual_2_2_5 File "parse.rules"
-
-The test group may contain *parse.rules* file. This file defines patterns used for analysis of the test execution log and deciding the status of the test run.
-
-Each line in the file should specify a status (single word), followed by a regular expression delimited by slashes (*/*) that will be matched against lines in the test output log to check if it corresponds to this status.
-
-The regular expressions should follow <a href="https://www.tcl.tk/man/tcl/TclCmd/re_syntax.htm">Tcl syntax</a>, with a special exception that "\b" is considered as word limit (Perl-style), in addition to "\y" used in Tcl.
-
-The rest of the line can contain a comment message, which will be added to the test report when this status is detected.
-
-Example:
-
-~~~~~
- FAILED /\b[Ee]xception\b/ exception
- FAILED /\bError\b/ error
- SKIPPED /Cannot open file for reading/ data file is missing
- SKIPPED /Could not read file .*, abandon/ data file is missing
-~~~~~
-
-Lines starting with a *#* character and blank lines are ignored to allow comments and spacing.
-
-See @ref testmanual_details_results "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.
-
-Example:
-
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
- FAILED /\\bFaulty\\b/ bad shape
- IGNORE /^Error [23]d = [\d.-]+/ debug output of blend command
- IGNORE /^Tcl Exception: tolerance ang : [\d.-]+/ blend failure
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-@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 @ref testmanual_2_3_5 "Directory data".
-
-@subsection testmanual_2_3 Test Grids
-
-@subsubsection testmanual_2_3_1 Grid Names
-
-The folder of a test group can have several sub-directories (Grid 1… Grid N) defining test grids.
-Each directory contains a set of related test cases. The name of a directory should correspond to its contents.
-
-Example:
-
-~~~~~
-caf
- basic
- bugs
- presentation
-~~~~~
-
-Here *caf* is the name of the test group and *basic*, *bugs*, *presentation*, etc. are the names of grids.
-
-@subsubsection testmanual_2_3_2 File "begin"
-
-This file is a TCL script executed before every test in the current grid.
-
-Usually it sets variables specific for the current grid.
-
-Example:
-
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
- set command bopfuse ;# command tested in this grid
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-@subsubsection testmanual_2_3_3 File "end"
-
-This file is a TCL script executed after every test in current grid.
-
-Usually it executes a specific sequence of commands common for all tests in the grid.
-
-Example:
-
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
- vdump $imagedir/${casename}.png ;# makes a snap-shot of AIS viewer
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-@subsubsection testmanual_2_3_4 File "cases.list"
-
-The grid directory can contain an optional file cases.list
-defining an alternative location of the test cases.
-This file should contain a single line defining the relative path to the collection of test cases.
-
-Example:
-
-~~~~~
-../data/simple
-~~~~~
-
-This option is used for creation of several grids of tests with the same data files and operations but performed with differing parameters. The common scripts are usually located place in the common
-subdirectory of the test group, <i>data/simple</i> for example.
-
-If file *cases.list* exists, the grid directory should not contain any test cases.
-The specific parameters and pre- and post-processing commands
-for test execution in this grid should be defined in the files *begin* and *end*.
-
-
-@subsubsection testmanual_2_3_5 Directory "data"
-
-The test grid may contain subdirectory *data*, containing data files used in tests (BREP, IGES, STEP, etc.) of this grid.
-
-@subsection testmanual_2_4 Test Cases
-
-The test case is a TCL script, which performs some operations using DRAW commands
-and produces meaningful messages that can be used to check the validity of the result.
-
-Example:
-
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
- pcylinder c1 10 20 ;# create first cylinder
- pcylinder c2 5 20 ;# create second cylinder
- ttranslate c2 5 0 10 ;# translate second cylinder to x,y,z
- bsection result c1 c2 ;# create a section of two cylinders
- checksection result ;# will output error message if result is bad
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The test case can have any name (except for the reserved names *begin, end, data, cases.list* and *parse.rules*).
-For systematic grids it is usually a capital English letter followed by a number.
-
-Example:
-
-~~~~~
- A1
- A2
- B1
- B2
-~~~~~
-
-Such naming facilitates compact representation of tests execution results in tabular format within HTML reports.
-
-
-@section testmanual_3 Creation And Modification Of Tests
-
-This section describes how to add new tests and update existing ones.
-
-@subsection testmanual_3_1 Choosing Group, Grid, and Test Case Name
-
-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 @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.
-
-Example:
-
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
- bug12345_coaxial
- bug12345_orthogonal_1
- bug12345_orthogonal_2
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-If the new test corresponds to a functionality already covered by the existing systematic test grid (e.g. group *mesh* for *BRepMesh* issues), this test can be added (or moved later by OCC team) to that grid.
-
-@subsection testmanual_3_2 Adding Data Files Required for a Test
-
-It is advisable to make self-contained test scripts whenever possible, so as they could be used in the environments where data files are not available. For that simple geometric objects and shapes can be created using DRAW commands in the test script itself.
-
-If the test requires a data file, it should be put to the directory listed in environment variable *CSF_TestDataPath*.
-Alternatively, it can be put to subdirectory *data* of the test grid.
-It is recommended to prefix the data file with the corresponding issue id prefixed by *bug*, e.g. *bug12345_face1.brep*, to avoid possible conflicts with names of existing data files.
-
-Note that when the test is integrated to the master branch, OCC team will move the data file to the data files repository, to keep OCCT sources repository clean from data files.
-
-When you prepare a test script, try to minimize the size of involved data model. For instance, if the problem detected on a big shape can be reproduced on a single face extracted from that shape, use only that face in the test.
-
-
-@subsection testmanual_3_3 Adding new DRAW commands
-
-If the test cannot be implemented using available DRAW commands, consider the following possibilities:
-* If the existing DRAW command can be extended to enable possibility required for a test in a natural way (e.g. by adding an option to activate a specific mode of the algorithm), this way is recommended. This change should be appropriately documented in a relevant Mantis issue.
-* If the new command is needed to access OCCT functionality not exposed to DRAW previously, and this command can be potentially reused (for other tests), it should be added to the package where similar commands are implemented (use *getsource* DRAW command to get the package name). The name and arguments of the new command should be chosen to keep similarity with the existing commands. This change should be documented in a relevant Mantis issue.
-* Otherwise the new command implementing the actions needed for this particular test should be added in *QABugs* package. The command name should be formed by the Mantis issue ID prefixed by *bug*, e.g. *bug12345*.
-
-Note that a DRAW command is expected to return 0 in case of a normal completion, and 1 (Tcl exception) if it is incorrectly used (e.g. a wrong number of input arguments). Thus if the new command needs to report a test error, this should be done by outputting an appropriate error message rather than by returning a non-zero value.
-File names must be encoded in the script rather than in the DRAW command and passed to the DRAW command as an argument.
-
-@subsection testmanual_3_4 Script Implementation
-
-The test should run commands necessary to perform the tested operations, in general assuming a clean DRAW session. The required DRAW modules should be loaded by *pload* command, if it is not done by *begin* script. The messages produced by commands in a standard output should include identifiable messages on the discovered problems if any.
-
-Usually the script represents a set of commands that a person would run interactively to perform the operation and see its results, with additional comments to explain what happens.
-
-Example:
-~~~~~
-# Simple test of fusing box and sphere
-box b 10 10 10
-sphere s 5
-bfuse result b s
-checkshape result
-~~~~~
-
-Make sure that file *parse.rules* in the grid or group directory contains a regular expression to catch possible messages indicating the failure of the test.
-
-For instance, for catching errors reported by *checkshape* command relevant grids define a rule to recognize its report by the word *Faulty*:
-
-~~~~~
-FAILED /\bFaulty\b/ bad shape
-~~~~~
-
-For the messages generated in the script it is recommended to use the word 'Error' in the error message.
-
-Example:
-
-~~~~~
-set expected_length 11
-if { [expr $actual_length - $expected_length] > 0.001 } {
- puts "Error: The length of the edge should be $expected_length"
-}
-~~~~~
-
-At the end, the test script should output *TEST COMPLETED* string to mark a successful completion of the script. This is often done by the *end* script in the grid.
-
-When the test script requires a data file, use Tcl procedure *locate_data_file* to get a path to it, instead of putting the path explicitly. This will allow easy move of the data file from OCCT sources repository to the data files repository without the need to update the test script.
-
-Example:
-
-~~~~~
-stepread [locate_data_file CAROSKI_COUPELLE.step] a *
-~~~~~
-
-When the test needs to produce some snapshots or other artefacts, use Tcl variable *imagedir* as the location where such files should be put.
-* Command *testgrid* sets this variable to the subdirectory of the results folder corresponding to the grid.
-* Command *test* by default creates a dedicated temporary directory in the system temporary folder (normally the one specified by environment variable *TempDir*, *TEMP*, or *TMP*) for each execution, and sets *imagedir* to that location.
-
-However if variable *imagedir* is defined on the top level of Tcl interpretor, command *test* will use it instead of creating a new directory.
-
-Use Tcl variable *casename* to prefix all files produced by the test.
-This variable is set to the name of the test case.
-
-The test system can recognize an image file (snapshot) and include it in HTML log and differences if its name starts with the name of the test case (use variable *casename*), optionally followed by underscore or dash and arbitrary suffix.
-
-The image format (defined by extension) should be *png*.
-
-Example:
-~~~~~
-xwd $imagedir/${casename}.png
-vdisplay result; vfit
-vdump $imagedir/${casename}-axo.png
-vfront; vfit
-vdump $imagedir/${casename}-front.png
-~~~~~
-
-would produce:
-~~~~~
-A1.png
-A1-axo.png
-A1-front.png
-~~~~~
-
-Note that OCCT must be built with FreeImage support to be able to produce usable images.
-
-Other Tcl variables defined during the test execution are:
-- *groupname*: name of the test group;
-- *gridname*: name of the test grid;
-- *dirname*: path to the root directory of the current set of test scripts.
-
-In order to ensure that the test works as expected in different environments, observe the following additional rules:
-* Avoid using external commands such as *grep, rm,* etc., as these commands can be absent on another system (e.g. on Windows); use facilities provided by Tcl instead.
-* Do not put call to *locate_data_file* in catch statement -- this can prevent correct interpretation of the missing data file by the test system.
-* Do not use commands *decho* and *dlog* in the test script, to avoid interference with use of these commands by the test system.
-
-@subsection testmanual_details_results Interpretation of test results
-
-The result of the test is evaluated by checking its output against patterns defined in the files *parse.rules* of the grid and group.
-
-The OCCT test system recognizes five statuses of the test execution:
-* SKIPPED: reported if a line matching SKIPPED pattern is found (prior to any FAILED pattern). This indicates that the test cannot be run in the current environment; the most typical case is the absence of the required data file.
-* FAILED: reported if a line matching pattern with status FAILED is found (unless it is masked by the preceding IGNORE pattern or a TODO or REQUIRED statement), or if message TEST COMPLETED or at least one of REQUIRED patterns is not found. This indicates that the test has produced a bad or unexpected result, and usually means a regression.
-* BAD: reported if the test script output contains one or several TODO statements and the corresponding number of matching lines in the log. This indicates a known problem. The lines matching TODO statements are not checked against other patterns and thus will not cause a FAILED status.
-* IMPROVEMENT: reported if the test script output contains a TODO statement for which no corresponding line is found. This is a possible indication of improvement (a known problem has disappeared).
-* OK: reported if none of the above statuses have been assigned. This means that the test has passed without problems.
-
-Other statuses can be specified in *parse.rules* files, these will be classified as FAILED.
-
-For integration of the change to OCCT repository, all tests should return either OK or BAD status.
-The new test created for an unsolved problem should return BAD. The new test created for a fixed problem should return FAILED without the fix, and OK with the fix.
-
-@subsection testmanual_3_6 Marking BAD cases
-
-If the test produces an invalid result at a certain moment then the corresponding bug should be created in the OCCT issue tracker located at https://tracker.dev.opencascade.org, and the problem should be marked as TODO in the test script.
-
-The following statement should be added to such a test script:
-~~~~~
-puts "TODO BugNumber ListOfPlatforms: RegularExpression"
-~~~~~
-
-Here:
-* *BugNumber* is the bug ID in the tracker. For example: #12345.
-* *ListOfPlatforms* is a list of platforms, at which the bug is reproduced (Linux, Windows, MacOS, or All). Note that the platform name is custom for the OCCT test system; Use procedure *checkplatform* to get the platform name.
-
-Example:
-~~~~~
-Draw[2]> checkplatform
-Windows
-~~~~~
-
-* RegularExpression is a regular expression, which should be matched against the line indicating the problem in the script output.
-
-Example:
-~~~~~
-puts "TODO #22622 Mandriva2008: Abort .* an exception was raised"
-~~~~~
-
-The parser checks the test output and if an output line matches the *RegularExpression* then it will be assigned a BAD status instead of FAILED.
-
-A separate TODO line must be added for each output line matching an error expression to mark the test as BAD. If not all TODO messages are found in the test log, the test will be considered as possible improvement.
-
-To mark the test as BAD for an incomplete case (when the final *TEST COMPLETE* message is missing) the expression *TEST INCOMPLETE* should be used instead of the regular expression.
-
-Example:
-
-~~~~~
-puts "TODO OCC22817 All: exception.+There are no suitable edges"
-puts "TODO OCC22817 All: \\*\\* Exception \\*\\*"
-puts "TODO OCC22817 All: TEST INCOMPLETE"
-~~~~~
-
-@subsection testmanual_3_7 Marking required output
-
-To check the obtained test output matches the expected results considered correct, add REQUIRED statement for each specific message.
-For that, the following statement should be added to the corresponding test script:
-
-~~~~~
-puts "REQUIRED ListOfPlatforms: RegularExpression"
-~~~~~
-
-Here *ListOfPlatforms* and *RegularExpression* have the same meaning as in TODO statements described above.
-
-The REQUIRED statement can also be used to mask the message that would normally be interpreted as error (according to the rules defined in *parse.rules*) but should not be considered as such within the current test.
-
-Example:
-~~~~~
-puts "REQUIRED Linux: Faulty shapes in variables faulty_1 to faulty_5"
-~~~~~
-
-This statement notifies test system that errors reported by *checkshape* command are expected in that test case, and test should be considered as OK if this message appears, despite of presence of general rule stating that 'Faulty' signals failure.
-
-If output does not contain required statement, test case will be marked as FAILED.
-
-@section testmanual_4 Advanced Use
-
-@subsection testmanual_4_1 Running Tests on Older Versions of OCCT
-
-Sometimes it might be necessary to run tests on the previous versions of OCCT (<= 6.5.4) that do not include this test system. This can be done by adding DRAW configuration file *DrawAppliInit* in the directory, which is current by the moment of DRAW start-up, to load test commands and to define the necessary environment.
-
-Note: in OCCT 6.5.3, file *DrawAppliInit* already exists in <i>$CASROOT/src/DrawResources</i>, new commands should be added to this file instead of a new one in the current directory.
-
-For example, let us assume that *d:/occt* contains an up-to-date version of OCCT sources with tests, and the test data archive is unpacked to *d:/test-data*):
-
-~~~~~
-set env(CASROOT) d:/occt
-set env(CSF_TestScriptsPath) $env(CASROOT)/tests
-source $env(CASROOT)/src/DrawResources/TestCommands.tcl
-set env(CSF_TestDataPath) $env(CASROOT)/data;d:/test-data
-return
-~~~~~
-
-Note that on older versions of OCCT the tests are run in compatibility mode and thus not all output of the test command can be captured; this can lead to absence of some error messages (can be reported as either a failure or an improvement).
-
-@subsection testmanual_4_2 Adding custom tests
-
-You can extend the test system by adding your own tests. For that it is necessary to add paths to the directory where these tests are located, and one or more additional data directories, to the environment variables *CSF_TestScriptsPath* and *CSF_TestDataPath*. The recommended way for doing this is using DRAW configuration file *DrawAppliInit* located in the directory which is current by the moment of DRAW start-up.
-
-Use Tcl command <i>_path_separator</i> to insert a platform-dependent separator to the path list.
-
-For example:
-~~~~~
-set env(CSF_TestScriptsPath) \
- $env(TestScriptsPath)[_path_separator]d:/MyOCCTProject/tests
-set env(CSF_TestDataPath) \
- d:/occt/test-data[_path_separator]d:/MyOCCTProject/data
-return ;# this is to avoid an echo of the last command above in cout
-~~~~~
-
-@subsection testmanual_4_3 Parallel execution of tests
-
-For better efficiency, on computers with multiple CPUs the tests can be run in parallel mode. This is default behavior for command *testgrid* : the tests are executed in parallel processes (their number is equal to the number of CPUs available on the system). In order to change this behavior, use option parallel followed by the number of processes to be used (1 or 0 to run sequentially).
-
-Note that the parallel execution is only possible if Tcl extension package *Thread* is installed.
-If this package is not available, *testgrid* command will output a warning message.
-
-@subsection testmanual_4_4 Checking non-regression of performance, memory, and visualization
-
-Some test results are very dependent on the characteristics of the workstation, where they are performed, and thus cannot be checked by comparison with some predefined values. These results can be checked for non-regression (after a change in OCCT code) by comparing them with the results produced by the version without this change. The most typical case is comparing the result obtained in a branch created for integration of a fix (CR***) with the results obtained on the master branch before that change is made.
-
-OCCT test system provides a dedicated command *testdiff* for comparing CPU time of execution, memory usage, and images produced by the tests.
-
-~~~~~
-testdiff dir1 dir2 [groupname [gridname]] [options...]
-~~~~~
-Here *dir1* and *dir2* are directories containing logs of two test runs.
-
-Possible options are:
-* <i>-save \<filename\> </i> -- saves the resulting log in a specified file (<i>$dir1/diff-$dir2.log</i> by default). HTML log is saved with the same name and extension .html;
-* <i>-status {same|ok|all}</i> -- allows filtering compared cases by their status:
- * *same* -- only cases with same status are compared (default);
- * *ok* -- only cases with OK status in both logs are compared;
- * *all* -- results are compared regardless of status;
-* <i>-verbose \<level\> </i> -- defines the scope of output data:
- * 1 -- outputs only differences;
- * 2 -- additionally outputs the list of logs and directories present in one of directories only;
- * 3 -- (by default) additionally outputs progress messages;
-* <i>-image [filename]</i> - compare images and save the resulting log in specified file (<i>$dir1/diffimage-$dir2.log</i> by default)
-* <i>-cpu [filename]</i> - compare overall CPU and save the resulting log in specified file (<i>$dir1/diffcpu-$dir2.log</i> by default)
-* <i>-memory [filename]</i> - compare memory delta and save the resulting log in specified file (<i>$dir1/diffmemory-$dir2.log</i> by default)
-* <i>-highlight_percent \<value\></i> - highlight considerable (>value in %) deviations of CPU and memory (default value is 5%)
-
-Example:
-
-~~~~~
-Draw[]> testdiff results/CR12345-2012-10-10T08:00 results/master-2012-10-09T21:20
-~~~~~
-
-Particular tests can generate additional data that need to be compared by *testdiff* command.
-For that, for each parameter to be controlled, the test should produce the line containing keyword "COUNTER* followed by arbitrary name of the parameter, then colon and numeric value of the parameter.
-
-Example of test code:
-
-~~~~~
-puts "COUNTER Memory heap usage at step 5: [meminfo h]"
-~~~~~
-
-@section testmanual_5 APPENDIX
-
-@subsection testmanual_5_1 Test groups
-
-@subsubsection testmanual_5_1_1 3rdparty
-
-This group allows testing the interaction of OCCT and 3rdparty products.
-
-DRAW module: VISUALIZATION.
-
-| Grid | Commands | Functionality |
-| :---- | :----- | :------- |
-| export | vexport | export of images to different formats |
-| fonts | vtrihedron, vcolorscale, vdrawtext | display of fonts |
-
-
-@subsubsection testmanual_5_1_2 blend
-
-This group allows testing blends (fillets) and related operations.
-
-DRAW module: MODELING.
-
-| Grid | Commands | Functionality |
-| :---- | :----- | :------- |
-| simple | blend | fillets on simple shapes |
-| complex | blend | fillets on complex shapes, non-trivial geometry |
-| tolblend_simple | tolblend, blend | |
-| buildevol | buildevol | |
-| tolblend_buildvol | tolblend, buildevol | use of additional command tolblend |
-| bfuseblend | bfuseblend | |
-| encoderegularity | encoderegularity | |
-
-@subsubsection testmanual_5_1_3 boolean
-
-This group allows testing Boolean operations.
-
-DRAW module: MODELING (packages *BOPTest* and *BRepTest*).
-
-Grids names are based on name of the command used, with suffixes:
-* <i>_2d</i> -- for tests operating with 2d objects (wires, wires, 3d objects, etc.);
-* <i>_simple</i> -- for tests operating on simple shapes (boxes, cylinders, toruses, etc.);
-* <i>_complex</i> -- for tests dealing with complex shapes.
-
-| Grid | Commands | Functionality |
-| :---- | :----- | :------- |
-| bcommon_2d | bcommon | Common operation (old algorithm), 2d |
-| bcommon_complex | bcommon | Common operation (old algorithm), complex shapes |
-| bcommon_simple | bcommon | Common operation (old algorithm), simple shapes |
-| bcut_2d | bcut | Cut operation (old algorithm), 2d |
-| bcut_complex | bcut | Cut operation (old algorithm), complex shapes |
-| bcut_simple | bcut | Cut operation (old algorithm), simple shapes |
-| bcutblend | bcutblend | |
-| bfuse_2d | bfuse | Fuse operation (old algorithm), 2d |
-| bfuse_complex | bfuse | Fuse operation (old algorithm), complex shapes |
-| bfuse_simple | bfuse | Fuse operation (old algorithm), simple shapes |
-| bopcommon_2d | bopcommon | Common operation, 2d |
-| bopcommon_complex | bopcommon | Common operation, complex shapes |
-| bopcommon_simple | bopcommon | Common operation, simple shapes |
-| bopcut_2d | bopcut | Cut operation, 2d |
-| bopcut_complex | bopcut | Cut operation, complex shapes |
-| bopcut_simple | bopcut | Cut operation, simple shapes |
-| bopfuse_2d | bopfuse | Fuse operation, 2d |
-| bopfuse_complex | bopfuse | Fuse operation, complex shapes |
-| bopfuse_simple | bopfuse | Fuse operation, simple shapes |
-| bopsection | bopsection | Section |
-| boptuc_2d | boptuc | |
-| boptuc_complex | boptuc | |
-| boptuc_simple | boptuc | |
-| bsection | bsection | Section (old algorithm) |
-
-@subsubsection testmanual_5_1_4 bugs
-
-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 @ref testmanual_5_2 "Mapping of OCCT functionality to grid names in group bugs" chapter for details.
-
-@subsubsection testmanual_5_1_5 caf
-
-This group allows testing OCAF functionality.
-
-DRAW module: OCAFKERNEL.
-
-| Grid | Commands | Functionality |
-| :---- | :----- | :------- |
-| basic | | Basic attributes |
-| bugs | | Saving and restoring of document |
-| driver | | OCAF drivers |
-| named_shape | | *TNaming_NamedShape* attribute |
-| presentation | | *AISPresentation* attributes |
-| tree | | Tree construction attributes |
-| xlink | | XLink attributes |
-
-@subsubsection testmanual_5_1_6 chamfer
-
-This group allows testing chamfer operations.
-
-DRAW module: MODELING.
-
-The test grid name is constructed depending on the type of the tested chamfers. Additional suffix <i>_complex</i> is used for test cases involving complex geometry (e.g. intersections of edges forming a chamfer); suffix <i>_sequence</i> is used for grids where chamfers are computed sequentially.
-
-| Grid | Commands | Functionality |
-| :---- | :----- | :------- |
-| equal_dist | | Equal distances from edge |
-| equal_dist_complex | | Equal distances from edge, complex shapes |
-| equal_dist_sequence | | Equal distances from edge, sequential operations |
-| dist_dist | | Two distances from edge |
-| dist_dist_complex | | Two distances from edge, complex shapes |
-| dist_dist_sequence | | Two distances from edge, sequential operations |
-| dist_angle | | Distance from edge and given angle |
-| dist_angle_complex | | Distance from edge and given angle |
-| dist_angle_sequence | | Distance from edge and given angle |
-
-@subsubsection testmanual_5_1_7 de
-
-This group tests reading and writing of CAD data files (iges, step) to and from OCCT.
-
-Test cases check transfer status, shape and attributes against expected reference values.
-
-| Grid | Commands | Functionality |
-| :---- | :----- | :------- |
-| iges_1, iges_2, iges_3 | igesbrep, brepiges, ReadIges, WriteIges | IGES tests |
-| step_1, step_2, step_3, step_4, step_5 | stepread, stepwrite, ReadStep, WriteStep | STEP tests |
-
-@subsubsection testmanual_5_1_8 demo
-
-This group allows demonstrating how testing cases are created, and testing DRAW commands and the test system as a whole.
-
-| Grid | Commands | Functionality |
-| :---- | :----- | :------- |
-| draw | getsource, restore | Basic DRAW commands |
-| testsystem | | Testing system |
-| samples | | OCCT samples |
-
-
-@subsubsection testmanual_5_1_9 draft
-
-This group allows testing draft operations.
-
-DRAW module: MODELING.
-
-| Grid | Commands | Functionality |
-| :---- | :----- | :------- |
-| Angle | depouille | Drafts with angle (inclined walls) |
-
-
-@subsubsection testmanual_5_1_10 feat
-
-This group allows testing creation of features on a shape.
-
-DRAW module: MODELING (package *BRepTest*).
-
-| Grid | Commands | Functionality |
-| :---- | :----- | :------- |
-| featdprism | | |
-| featlf | | |
-| featprism | | |
-| featrevol | | |
-| featrf | | |
-
-@subsubsection testmanual_5_1_11 heal
-
-This group allows testing the functionality provided by *ShapeHealing* toolkit.
-
-DRAW module: XSDRAW
-
-| Grid | Commands | Functionality |
-| :---- | :----- | :------- |
-| fix_shape | fixshape | Shape healing |
-| fix_gaps | fixwgaps | Fixing gaps between edges on a wire |
-| same_parameter | sameparameter | Fixing non-sameparameter edges |
-| same_parameter_locked | sameparameter | Fixing non-sameparameter edges |
-| fix_face_size | DT_ApplySeq | Removal of small faces |
-| elementary_to_revolution | DT_ApplySeq | Conversion of elementary surfaces to revolution |
-| direct_faces | directfaces | Correction of axis of elementary surfaces |
-| drop_small_edges | fixsmall | Removal of small edges |
-| split_angle | DT_SplitAngle | Splitting periodic surfaces by angle |
-| split_angle_advanced | DT_SplitAngle | Splitting periodic surfaces by angle |
-| split_angle_standard | DT_SplitAngle | Splitting periodic surfaces by angle |
-| split_closed_faces | DT_ClosedSplit | Splitting of closed faces |
-| surface_to_bspline | DT_ToBspl | Conversion of surfaces to b-splines |
-| surface_to_bezier | DT_ShapeConvert | Conversion of surfaces to bezier |
-| split_continuity | DT_ShapeDivide | Split surfaces by continuity criterion |
-| split_continuity_advanced | DT_ShapeDivide | Split surfaces by continuity criterion |
-| split_continuity_standard | DT_ShapeDivide | Split surfaces by continuity criterion |
-| surface_to_revolution_advanced | DT_ShapeConvertRev | Convert elementary surfaces to revolutions, complex cases |
-| surface_to_revolution_standard | DT_ShapeConvertRev | Convert elementary surfaces to revolutions, simple cases |
-| update_tolerance_locked | updatetolerance | Update the tolerance of shape so that it satisfy the rule: toler(face)<=toler(edge)<=toler(vertex) |
-
-@subsubsection testmanual_5_1_12 mesh
-
-This group allows testing shape tessellation (*BRepMesh*) and shading.
-
-DRAW modules: MODELING (package *MeshTest*), VISUALIZATION (package *ViewerTest*)
-
-| Grid | Commands | Functionality |
-| :---- | :----- | :------- |
-| advanced_shading | vdisplay | Shading, complex shapes |
-| standard_shading | vdisplay | Shading, simple shapes |
-| advanced_mesh | mesh | Meshing of complex shapes |
-| standard_mesh | mesh | Meshing of simple shapes |
-| advanced_incmesh | incmesh | Meshing of complex shapes |
-| standard_incmesh | incmesh | Meshing of simple shapes |
-| advanced_incmesh_parallel | incmesh | Meshing of complex shapes, parallel mode |
-| standard_incmesh_parallel | incmesh | Meshing of simple shapes, parallel mode |
-
-@subsubsection testmanual_5_1_13 mkface
-
-This group allows testing creation of simple surfaces.
-
-DRAW module: MODELING (package *BRepTest*)
-
-| Grid | Commands | Functionality |
-| :---- | :----- | :------- |
-| after_trim | mkface | |
-| after_offset | mkface | |
-| after_extsurf_and_offset | mkface | |
-| after_extsurf_and_trim | mkface | |
-| after_revsurf_and_offset | mkface | |
-| mkplane | mkplane | |
-
-@subsubsection testmanual_5_1_14 nproject
-
-This group allows testing normal projection of edges and wires onto a face.
-
-DRAW module: MODELING (package *BRepTest*)
-
-| Grid | Commands | Functionality |
-| :---- | :----- | :------- |
-| Base | nproject | |
-
-@subsubsection testmanual_5_1_15 offset
-
-This group allows testing offset functionality for curves and surfaces.
-
-DRAW module: MODELING (package *BRepTest*)
-
-| Grid | Commands | Functionality |
-| :---- | :----- | :------- |
-| compshape | offsetcompshape | Offset of shapes with removal of some faces |
-| faces_type_a | offsetparameter, offsetload, offsetperform | Offset on a subset of faces with a fillet |
-| faces_type_i | offsetparameter, offsetload, offsetperform | Offset on a subset of faces with a sharp edge |
-| shape_type_a | offsetparameter, offsetload, offsetperform | Offset on a whole shape with a fillet |
-| shape_type_i | offsetparameter, offsetload, offsetperform | Offset on a whole shape with a fillet |
-| shape | offsetshape | |
-| wire_closed_outside_0_005, wire_closed_outside_0_025, wire_closed_outside_0_075, wire_closed_inside_0_005, wire_closed_inside_0_025, wire_closed_inside_0_075, wire_unclosed_outside_0_005, wire_unclosed_outside_0_025, wire_unclosed_outside_0_075 | mkoffset | 2d offset of closed and unclosed planar wires with different offset step and directions of offset ( inside / outside ) |
-
-@subsubsection testmanual_5_1_16 pipe
-
-This group allows testing construction of pipes (sweeping of a contour along profile).
-
-DRAW module: MODELING (package *BRepTest*)
-
-| Grid | Commands | Functionality |
-| :---- | :----- | :------- |
-| Standard | pipe | |
-
-@subsubsection testmanual_5_1_17 prism
-
-This group allows testing construction of prisms.
-
-DRAW module: MODELING (package *BRepTest*)
-
-| Grid | Commands | Functionality |
-| :---- | :----- | :------- |
-| seminf | prism | |
-
-@subsubsection testmanual_5_1_18 sewing
-
-This group allows testing sewing of faces by connecting edges.
-
-DRAW module: MODELING (package *BRepTest*)
-
-| Grid | Commands | Functionality |
-| :---- | :----- | :------- |
-| tol_0_01 | sewing | Sewing faces with tolerance 0.01 |
-| tol_1 | sewing | Sewing faces with tolerance 1 |
-| tol_100 | sewing | Sewing faces with tolerance 100 |
-
-@subsubsection testmanual_5_1_19 thrusection
-
-This group allows testing construction of shell or a solid passing through a set of sections in a given sequence (loft).
-
-| Grid | Commands | Functionality |
-| :---- | :----- | :------- |
-| solids | thrusection | Lofting with resulting solid |
-| not_solids | thrusection | Lofting with resulting shell or face |
-
-@subsubsection testmanual_5_1_20 xcaf
-
-This group allows testing extended data exchange packages.
-
-| Grid | Commands | Functionality |
-| :---- | :----- | :------- |
-| dxc, dxc_add_ACL, dxc_add_CL, igs_to_dxc, igs_add_ACL, brep_to_igs_add_CL, stp_to_dxc, stp_add_ACL, brep_to_stp_add_CL, brep_to_dxc, add_ACL_brep, brep_add_CL | | Subgroups are divided by format of source file, by format of result file and by type of document modification. For example, *brep_to_igs* means that the source shape in brep format was added to the document, which was saved into igs format after that. The postfix *add_CL* means that colors and layers were initialized in the document before saving and the postfix *add_ACL* corresponds to the creation of assembly and initialization of colors and layers in a document before saving. |
-
-
-@subsection testmanual_5_2 Mapping of OCCT functionality to grid names in group *bugs*
-
-| OCCT Module / Mantis category | Toolkits | Test grid in group bugs |
-| :---------- | :--------- | :---------- |
-| Application Framework | PTKernel, TKPShape, TKCDF, TKLCAF, TKCAF, TKBinL, TKXmlL, TKShapeSchema, TKPLCAF, TKBin, TKXml, TKPCAF, FWOSPlugin, TKStdLSchema, TKStdSchema, TKTObj, TKBinTObj, TKXmlTObj | caf |
-| Draw | TKDraw, TKTopTest, TKViewerTest, TKXSDRAW, TKDCAF, TKXDEDRAW, TKTObjDRAW, TKQADraw, DRAWEXE, Problems of testing system | draw |
-| Shape Healing | TKShHealing | heal |
-| Mesh | TKMesh, TKXMesh | mesh |
-| Data Exchange | TKIGES | iges |
-| Data Exchange | TKSTEPBase, TKSTEPAttr, TKSTEP209, TKSTEP | step |
-| Data Exchange | TKSTL, TKVRML | stlvrml |
-| Data Exchange | TKXSBase, TKXCAF, TKXCAFSchema, TKXDEIGES, TKXDESTEP, TKXmlXCAF, TKBinXCAF | xde |
-| Foundation Classes | TKernel, TKMath | fclasses |
-| Modeling_algorithms | TKGeomAlgo, TKTopAlgo, TKPrim, TKBO, TKBool, TKHLR, TKFillet, TKOffset, TKFeat, TKXMesh | modalg |
-| Modeling Data | TKG2d, TKG3d, TKGeomBase, TKBRep | moddata |
-| Visualization | TKService, TKV2d, TKV3d, TKOpenGl, TKMeshVS, TKNIS | vis |
-
-
-@subsection testmanual_5_3 Recommended approaches to checking test results
-
-@subsubsection testmanual_5_3_1 Shape validity
-
-Run command *checkshape* on the result (or intermediate) shape and make sure that *parse.rules* of the test grid or group reports bad shapes (usually recognized by word "Faulty") as error.
-
-Example
-~~~~~
-checkshape result
-~~~~~
-
-To check the number of faults in the shape command *checkfaults* can be used.
-
-Use: checkfaults shape source_shape [ref_value=0]
-
-The default syntax of *checkfaults* command:
-~~~~~
-checkfaults results a_1
-~~~~~
-
-The command will check the number of faults in the source shape (*a_1*) and compare it
-with number of faults in the resulting shape (*result*). If shape *result* contains
-more faults, you will get an error:
-~~~~~
-checkfaults results a_1
-Error : Number of faults is 5
-~~~~~
-It is possible to set the reference value for comparison (reference value is 4):
-
-~~~~~
-checkfaults results a_1 4
-~~~~~
-
-If number of faults in the resulting shape is unstable, reference value should be set to "-1".
-As a result command *checkfaults* will return the following error:
-
-~~~~~
-checkfaults results a_1 -1
-Error : Number of faults is UNSTABLE
-~~~~~
-
-@subsubsection testmanual_5_3_2 Shape tolerance
-
-The maximal tolerance of sub-shapes of each kind of the resulting shape can be extracted from output of tolerance command as follows:
-
-~~~~~
-set tolerance [tolerance result]
-regexp { *FACE +: +MAX=([-0-9.+eE]+)} $tolerance dummy max_face
-regexp { *EDGE +: +MAX=([-0-9.+eE]+)} $tolerance dummy max_edgee
-regexp { *VERTEX +: +MAX=([-0-9.+eE]+)} $tolerance dummy max_vertex
-~~~~~
-
-It is possible to use command *checkmaxtol* to check maximal tolerance of shape and compare it with reference value.
-
-Use: checkmaxtol shape [options...]
-
-Allowed options are:
- * <i>-ref</i> -- reference value of maximum tolerance;
- * <i>-source</i> -- list of shapes to compare with;
- * <i>-min_tol</i> -- minimum tolerance for comparison;
- * <i>-multi_tol</i> -- tolerance multiplier.
-
-The default syntax of *checkmaxtol* command for comparison with the reference value:
-~~~~~
-checkmaxtol result -ref 0.00001
-~~~~~
-
-There is an opportunity to compare max tolerance of resulting shape with max tolerance of source shape.
-In the following example command *checkmaxtol* gets max tolerance among objects *a_1* and *a_2*.
-Then it chooses the maximum value between founded tolerance and value -min_tol (0.000001)
-and multiply it on the coefficient -multi_tol (i.e. 2):
-
-~~~~~
-checkmaxtol result -source {a_1 a_2} -min_tol 0.000001 -multi_tol 2
-~~~~~
-
-If the value of maximum tolerance more than founded tolerance for comparison, the command will return an error.
-
-Also, command *checkmaxtol* can be used to get max tolerance of the shape:
-
-~~~~~
-set maxtol [checkmaxtol result]
-~~~~~
-
-@subsubsection testmanual_5_3_3 Shape volume, area, or length
-
-Use command *vprops, sprops,* or *lprops* to correspondingly measure volume, area, or length of the shape produced by the test. The value can be extracted from the result of the command by *regexp*.
-
-Example:
-~~~~~
-# check area of shape result with 1% tolerance
-regexp {Mass +: +([-0-9.+eE]+)} [sprops result] dummy area
-if { abs($area - $expected) > 0.1 + 0.01 * abs ($area) } {
- puts "Error: The area of result shape is $area, while expected $expected"
-}
-~~~~~
-
-@subsubsection testmanual_5_3_4 Memory leaks
-
-The test system measures the amount of memory used by each test case. Considerable deviations (as well as the overall difference) in comparison with reference results can be reported by command *testdiff* (see @ref testmanual_4_4).
-
-To check memory leak on a particular operation, run it in a cycle, measure the memory consumption at each step and compare it with a threshold value.
-The command *checktrend* (defined in *tests/bugs/begin*) can be used to analyze a sequence of memory measurements and to get a statistically based evaluation of the leak presence.
-
-Example:
-~~~~~
-set listmem {}
-for {set i 1} {$i < 100} {incr i} {
- # run suspect operation
- …
- # check memory usage (with tolerance equal to half page size)
- lappend listmem [expr [meminfo w] / 1024]
- if { [checktrend $listmem 0 256 "Memory leak detected"] } {
- puts "No memory leak, $i iterations"
- break
- }
-}
-~~~~~
-
-@subsubsection testmanual_5_3_5 Visualization
-
-The following command sequence allows you to take a snapshot of the viewer, give it the name of the test case, and save in the directory indicated by Tcl variable *imagedir*.
-
-~~~~~
-vinit
-vclear
-vdisplay result
-vsetdispmode 1
-vfit
-vzfit
-vdump $imagedir/${casename}_shading.png
-~~~~~
-
-This image will be included in the HTML log produced by *testgrid* command and will be checked for non-regression through comparison of images by command *testdiff*.
-
-Also it is possible to use command *checkview* to make a snapshot of the viewer.
-
-Use: checkview [options...]
-Allowed options are:
-* <i>-display shapename </i> -- displays shape with name *shapename*;
-* <i>-3d </i> -- displays shape in 3d viewer;
-* <i>-2d [ v2d / smallview ] </i> - displays shape in 2d viewer (the default viewer is *smallview*);
-* <i>-path PATH</i> -- sets the location of the saved viewer screenshot;
-* <i>-vdispmode N</i> -- sets *vdispmode* for 3d viewer (default value is 1)
-* <i>-screenshot</i> -- makes a screenshot of already created viewer
-* The procedure can check a property of shape (length, area or volume) and compare it with value *N*:
- * <i>-l [N]</i>
- * <i>-s [N]</i>
- * <i>-v [N]</i>
- * If the current property is equal to value *N*, the shape is marked as valid in the procedure.
- * If value *N* is not given, the procedure will mark the shape as valid if the current property is non-zero.
-* <i>-with {a b c}</i> -- displays shapes *a, b* and *c* together with the shape (if the shape is valid)
-* <i>-otherwise {d e f}</i> -- displays shapes *d, e* and *f* instead of the shape (if the shape is NOT valid)
-
-Note that is required to use either option <i> -2d </i> or option <i> -3d</i>.
-
-Examples:
-~~~~~
-checkview -display result -2d -path ${imagedir}/${test_image}.png
-checkview -display result -3d -path ${imagedir}/${test_image}.png
-checkview -display result_2d -2d v2d -path ${imagedir}/${test_image}.png
-~~~~~
-
-~~~~~
-box a 10 10 10
-box b 5 5 5 10 10 10
-bcut result b a
-set result_vertices [explode result v]
-checkview -display result -2d -with ${result_vertices} -otherwise { a b } -l -path ${imagedir}/${test_image}.png
-~~~~~
-
-~~~~~
-box a 10 10 10
-box b 5 5 5 10 10 10
-bcut result b a
-vinit
-vdisplay a b
-vfit
-checkview -screenshot -3d -path ${imagedir}/${test_image}.png
-~~~~~
-
-@subsubsection testmanual_5_3_6 Number of free edges
-
-Procedure *checkfreebounds* compares the number of free edges with a reference value.
-
-Use: checkfreebounds shape ref_value [options...]
-
-Allowed options are:
- * <i>-tol N</i> -- used tolerance (default -0.01);
- * <i>-type N</i> -- used type, possible values are "closed" and "opened" (default "closed").
-
-~~~~~
-checkfreebounds result 13
-~~~~~
-
-Option <i>-tol N</i> defines tolerance for command *freebounds*, which is used within command *checkfreebounds*.
-
-Option <i>-type N</i> is used to select the type of counted free edges: closed or open.
-
-If the number of free edges in the resulting shape is unstable, the reference value should be set to "-1".
-As a result command *checkfreebounds* will return the following error:
-
-~~~~~
-checkfreebounds result -1
-Error : Number of free edges is UNSTABLE
-~~~~~
-
-@subsubsection testmanual_5_3_7 Compare numbers
-
-Procedure *checkreal* checks the equality of two reals with a tolerance (relative and absolute).
-
-Use: checkreal name value expected tol_abs tol_rel
-
-~~~~~
-checkreal "Some important value" $value 5 0.0001 0.01
-~~~~~
-
-@subsubsection testmanual_5_3_8 Check number of sub-shapes
-
-Procedure *checknbshapes* compares the number of sub-shapes in "shape" with the given reference data.
-
-Use: checknbshapes shape [options...]
-
-Allowed options are:
- * <i>-vertex N
- * -edge N
- * -wire N
- * -face N
- * -shell N
- * -solid N
- * -compsolid N
- * -compound N
- * -shape N
- * -t</i> -- compares the number of sub-shapes in "shape" counting
- the same sub-shapes with different location as different sub-shapes.
- * <i>-m msg</i> -- prints "msg" in case of error
-
-~~~~~
-checknbshapes result -vertex 8 -edge 4
-~~~~~
-
-@subsubsection testmanual_5_3_9 Check pixel color
-
-Command *checkcolor* can be used to check pixel color.
-
-Use: checkcolor x y red green blue
-
-where:
- * <i>x, y</i> -- pixel coordinates;
- * <i>red green blue</i> -- expected pixel color (values from 0 to 1).
-
-This procedure checks color with tolerance (5x5 area).
-
-Next example will compare color of point with coordinates x=100 y=100 with RGB color R=1 G=0 B=0.
-If colors are not equal, procedure will check the nearest ones points (5x5 area)
-~~~~~
-checkcolor 100 100 1 0 0
-~~~~~
-
-@subsubsection testmanual_5_3_10 Compute length, area and volume of input shape
-
-Procedure *checkprops* computes length, area and volume of the input shape.
-
-Use: checkprops shapename [options...]
-
-Allowed options are:
- * <i>-l LENGTH</i> -- command *lprops*, computes the mass properties of all edges in the shape with a linear density of 1;
- * <i>-s AREA</i> -- command *sprops*, computes the mass properties of all faces with a surface density of 1;
- * <i>-v VOLUME</i> -- command *vprops*, computes the mass properties of all solids with a density of 1;
- * <i>-eps EPSILON</i> -- the epsilon defines relative precision of computation;
- * <i>-deps DEPSILON</i> -- the epsilon defines relative precision to compare corresponding values;
- * <i>-equal SHAPE</i> -- compares area, volume and length of input shapes. Puts error if they are not equal;
- * <i>-notequal SHAPE</i> -- compares area, volume and length of input shapes. Puts error if they are equal.
-
-Options <i> -l, -s </i> and <i> -v</i> are independent and can be used in any order. Tolerance *epsilon* is the same for all options.
-
-~~~~~
-checkprops result -s 6265.68
-checkprops result -s -equal FaceBrep
-~~~~~
-
-@subsubsection testmanual_5_3_11 Parse output dump and compare it with reference values
-
-Procedure *checkdump* is used to parse output dump and compare it with reference values.
-
-Use: checkdump shapename [options...]
-
-Allowed options are:
- * <i>-name NAME</i> -- list of parsing parameters (e.g. Center, Axis, etc.);
- * <i>-ref VALUE</i> -- list of reference values for each parameter in *NAME*;
- * <i>-eps EPSILON</i> -- the epsilon defines relative precision of computation.
-
-~~~~~
-checkdump result -name {Center Axis XAxis YAxis Radii} -ref {{-70 0} {-1 -0} {-1 -0} {0 -1} {20 10}} -eps 0.01
-~~~~~
-
-@subsubsection testmanual_5_3_12 Compute length of input curve
-
-Procedure *checklength* computes length of the input curve.
-
-Use: checklength curvename [options...]
-
-Allowed options are:
- * <i>-l LENGTH</i> -- command *length*, computes the length of the input curve with precision of computation;
- * <i>-eps EPSILON</i> -- the epsilon defines a relative precision of computation;
- * <i>-equal CURVE</i> -- compares the length of input curves. Puts error if they are not equal;
- * <i>-notequal CURVE</i> -- compares the length of input curves. Puts error if they are equal.
-
-~~~~~
-checklength cp1 -l 7.278
-checklength res -l -equal ext_1
-~~~~~
-@subsubsection testmanual_5_3_13 Check maximum deflection, number of triangles and nodes in mesh
-
-Command *checktrinfo* can be used to to check the maximum deflection, as well as the number of nodes and triangles in mesh.
-
-Use: checktrinfo shapename [options...]
-
-Allowed options are:
- * <i>-tri [N]</i> -- compares the current number of triangles in *shapename* mesh with the given reference data.
- If reference value N is not given and the current number of triangles is equal to 0, procedure *checktrinfo* will print an error.
- * <i>-nod [N]</i> -- compares the current number of nodes in *shapename* mesh with the given reference data.
- If reference value N is not given and the current number of nodes is equal to 0, procedure *checktrinfo* will print an error.
- * <i>-defl [N]</i> -- compares the current value of maximum deflection in *shapename* mesh with the given reference data.
- If reference value N is not given and current maximum deflection is equal to 0, procedure *checktrinfo* will print an error.
- * <i>-max_defl N</i> -- compares the current value of maximum deflection in *shapename* mesh with the max possible value.
- * <i>-tol_abs_tri N</i> -- absolute tolerance for comparison of number of triangles (default value 0).
- * <i>-tol_rel_tri N</i> -- relative tolerance for comparison of number of triangles (default value 0).
- * <i>-tol_abs_nod N</i> -- absolute tolerance for comparison of number of nodes (default value 0).
- * <i>-tol_rel_nod N</i> -- relative tolerance for comparison of number of nodes (default value 0).
- * <i>-tol_abs_defl N</i> -- absolute tolerance for deflection comparison (default value 0).
- * <i>-tol_rel_defl N</i> -- relative tolerance for deflection comparison (default value 0).
- * <i>-ref [trinfo a]</i> -- compares deflection, number of triangles and nodes in *shapename* and *a*.
-
-Note that options <i> -tri, -nod </i> and <i> -defl </i> do not work together with option <i> -ref</i>.
-
-Examples:
-
-Comparison with some reference values:
-~~~~~
-checktrinfo result -tri 129 -nod 131 -defl 0.01
-~~~~~
-
-Comparison with another mesh:
-~~~~~
-checktrinfo result -ref [tringo a]
-~~~~~
-
-Comparison of deflection with the max possible value:
-~~~~~
-checktrinfo result -max_defl 1
-~~~~~
-
-Check that the current values are not equal to zero:
-~~~~~
-checktrinfo result -tri -nod -defl
-~~~~~
-
-Check that the number of triangles and the number of nodes are not equal to some specific values:
-~~~~~
-checktrinfo result -tri !10 -nod !8
-~~~~~
-
-It is possible to compare current values with reference values with some tolerances.
-Use options <i>-tol_\* </i> for that.
-~~~~~
-checktrinfo result -defl 1 -tol_abs_defl 0.001
-~~~~~
-
projects / occt.git / commitdiff
