Advanced Layout Concepts

The layout algorithms that come with the yFiles library support a number of sophisticated and powerful concepts for layout generation, including:

Furthermore, many of the yFiles layout algorithms provide support for advanced inremental layout and the closely related concept of "layout from sketch." An introduction to both these concepts is presented in the section called “Incremental Layout”.

Grouped Graphs

The term "grouped graph" denotes a graph structure where, conceptually, nodes can be declared "children" of a common other node, their "parent." This can be exercised recursively, i.e., parents can be declared children of other parents, resulting in a hierarchy of nodes of possibly arbitrary depth.

The visual presentation of such a hierarchy is normally done by placing the children near each other and have their parent enclosing them. The parent is called a "group node," and the children are its content, they are "grouped nodes." Declaring some nodes to be children of another node is called "grouping."

Layout support for grouped graphs primarily means proper handling of grouped nodes and their enclosing group node. The following table lists the layout algorithms that provide support for group nodes and their content:

Table 10.3. Layout support for grouped graphs

Layout Style Classname Note
Hierarchical IncrementalHierarchicLayouter IncrementalHierarchicLayouter provides direct support for grouped graphs for both incremental as well as non-incremental layout mode. See the description of IncrementalHierarchicLayouter's advanced concepts for more information.
Organic SmartOrganicLayouter See the description of SmartOrganicLayouter's support for layout of grouped graphs for more information.
Orthogonal OrthogonalGroupLayouter See the description of orthogonal group layout for more information.

Table 10.4, “Routing support for grouped graphs” lists the routing algorithms that provide support for grouped graphs.

Table 10.4. Routing support for grouped graphs

Routing Style Classname Note
Orthogonal OrthogonalEdgeRouter, ChannelEdgeRouter, and EdgeRouter OrthogonalEdgeRouter's support for routing with group nodes is partly handled by prepended layout stages. See the description of OrthogonalEdgeRouter for more information. Classes ChannelEdgeRouter and EdgeRouter provide inherent support for routing with group nodes.

Further support for grouped graphs also includes minimum size constraints for group nodes. These are supported by the following layout algorithms: SmartOrganicLayouter and IncrementalHierarchicLayouter.

Setup for Layout

With an IGraph-based graph, when invoking a layout algorithm using the adapter mechanisms, all necessary setup for the layout of a grouped graph is done transparently prior to running the layout. The hierarchy of the nodes of a grouped graph, any group node insets and minimum size constraints for group nodes are converted so that a layout algorithm can access the information as supplemental data.

Port Constraints

The two ends of an edge path are also called source port and target port, respectively. A port constraint serves to pinpoint an edge's end at its source node or target node. There are two kinds of port constraints available:

  • Weak constraint. Determines the node's side at which an edge path's end should connect.
  • Strong constraint. Determines the exact coordinates where the edge path's end should be located. The coordinates are interpreted relative to the node's center.

Both kinds of port constraints can easily be combined to express, for example, that an edge's source port should connect to the middle of the source node's upper border.

Table 10.5, “Layout support for port constraints” lists the layout algorithms that provide support for port constraints.

Table 10.5. Layout support for port constraints

Layout Style Classname Note
Hierarchical IncrementalHierarchicLayouter IncrementalHierarchicLayouter by default obeys weak and strong port constraints as soon as they are set. See the description of the hierarchical layout style for more information.
Tree GenericTreeLayouter Nearly all of the predefined node placer implementations that can be used with the generic tree layout algorithm by default obey strong and weak port constraints as soon as they are set. See the description of generic tree layout for more information.

Table 10.6, “Routing support for port constraints” lists the routing algorithms that provide support for port constraints.

Table 10.6. Routing support for port constraints

Routing Style Classname Note
Orthogonal OrthogonalEdgeRouter, ChannelEdgeRouter, BusRouter, and EdgeRouter All classes by default obey weak and strong port constraints as soon as they are set. See the descriptions of OrthogonalEdgeRouter, ChannelEdgeRouter, BusRouter, and EdgeRouter for more information.

Setup for Layout

Example 10.6, “Adding source port constraints to some edges (IGraph API)” demonstrates the creation of PortConstraint objects, and how they are stored in an IMapper. The mapper is then added to the mapper registry of the IGraph-based graph using the look-up key SourcePortConstraintDpKey as the mapper's tag. During layout calculation, an algorithm first retrieves the data provider using the look-up key, and afterwards retrieves the contained information.

The actual coordinates of an edge end point that has a strong port constraint associated are determined at the time a layout algorithm (or a routing algorithm) processes the edge. In other words, the strong characteristic of a strong port constraint is determined by its "normal" coordinates at the time of processing. Note that the specified coordinates of such edge end points are always interpreted relative to the respective node's center.

Example 10.6. Adding source port constraints to some edges (IGraph API)

// 'graph' is of type yWorks.yFiles.UI.Model.IGraph.

// Create a mapper.
IMapper<IEdge, PortConstraint> pcMap =
    new DictionaryMapper<IEdge, PortConstraint>();

// Set the coordinates for the edge's source port. (Actually, this could also
// be done anywhere prior to invoking the layout algorithm.)
graph.SetRelativeLocation(edge3.SourcePort, new PointD(-10, 20));

// Create PortConstraint objects:
// 1) Port constraint that allows an edge end to connect to any side of its
//    respective node.
PortConstraint pc1 = PortConstraint.Create(PortSide.Any);
// 2) Port constraint that determines an edge end to connect *anywhere* to the
//    upper (North) side of its respective node.
PortConstraint pc2 = PortConstraint.Create(PortSide.North);
// 3) Strong port constraint that determines an edge end to connect to the
//    lower (South) side of its respective node. The actual end point is at a
//    fixed coordinate.
PortConstraint pc3 = PortConstraint.Create(PortSide.South, true);

// Establish a mapping from edges to port constraints.
pcMap[edge1] = pc1;
pcMap[edge2] = pc2;
pcMap[edge3] = pc3;

// Add the mapper to the mapper registry of the graph.
// Use the "well-known" look-up key defined in class PortConstraintKeys.
// Note that the above defined port constraints are set so that they apply to
// the source ends of their respective edges only.
graph.MapperRegistry.AddMapper(PortConstraintKeys.SourcePortConstraintDpKey,
                               pcMap);

// Invoke the layouter.
graph.ApplyLayout(new IncrementalHierarchicLayouter());

Tutorial Demo Code

Setup of port constraints can be observed in the PortCandidateWindow and LogicGateWindow tutorial demo applications.

Port Candidates

The concept of port candidates is an extension to that of classic port constraints as described above. Unlike port constraints, port candidates can be used in conjunction with both nodes and edges. When used in conjunction with nodes, port candidates provide a means to:

  • restrict anchor locations at nodes, i.e., to define a set of locations where edges are allowed to connect to
  • associate costs with a given anchor location, which effectively allows to establish an order of precedence among the set of anchor locations
  • limit the number of connecting edges at a given anchor location

A typical example for the use of port candidates is a flow diagram as shown in Figure 10.4, “Using port candidates to control connection points”: The diamond shape, which is the visualization of a switch, should have its incoming edge connecting at the top. The first outgoing edge should connect at the bottom (left image), the second at the right, the third at the left (middle image). If there are more outgoing edges, these edges should connect at the bottom as well as more than one incoming edge should connect at the top (right image).

Figure 10.4. Using port candidates to control connection points

Using port candidates to control connection points
Using port candidates to control connection points
Using port candidates to control connection points
Incoming edges connect at the top, the first outgoing edge at the bottom... ... more outgoing edges occupy the right and left corners... ... when all corners are occupied, the additional edges connect at the bottom.

Class PortCandidate enables definition of port candidates that conceptually correspond to either weak port constraints, i.e., effectively describe side constraints, or strong port constraints, which encode specific anchor locations at a node. Note that port candidates that correspond to strong port constraints directly include the coordinates for the actual anchor locations.

PortCandidate additionally allows to associate costs with a given port candidate, which can be used to establish an order of precedence among multiple port candidates. When a given edge port is being assigned to any of the available port candidates at a node, those with low costs are favored compared to other port candidates with higher costs associated.

To define the set of side constraints and anchor locations at a node, multiple port candidates can easily be combined using the services of class PortCandidateSet. When a PortCandidate object is added to an instance of PortCandidateSet, the capacity of the port candidate can optionally be configured. The capacity of a given port candidate (sometimes also referred to as "cardinality") specifies the allowed number of connecting edges at that side or anchor location.

Matching Port Candidates

Matching port candidates means the process of distributing a node's edges to the available port candidates. All edges connecting to a node that has a set of port candidates associated with it via a PortCandidateSet object are distributed among the available port candidates with respect to:

  • the costs of a given port candidate
  • the number of edges that are allowed to connect to a given port candidate

For example, when the limit of allowed edges for a given port candidate with costs k is reached, i.e., the given port candidate is said to be "saturated," then the next least expensive port candidate among the remaining ones is chosen to connect edges to.

Example 10.7, “Defining a port candidate set” demonstrates how to create a candidate set for the diamond node shown in Figure 10.4, “Using port candidates to control connection points”: First, port candidates for the four corners of the diamond are defined. The number of connecting edges for these candidates is limited to 1. Further port candidates, which can take an unlimited number (int.MaxValue) of edges, are defined to handle any additional edges. To let the edges first connect to the corners before the additional candidates are occupied, a higher cost is associated with these latter candidates.

Example 10.7. Defining a port candidate set

// define a PortCandidateSet
PortCandidateSet pcs = new PortCandidateSet();

// the node has the size (30, 30) with the point (0, 0) at the center
// so the coordinates for the top corner are (0, -15)

// create a candidate at the top corner with direction North and cost 0
PortCandidate candidate =
    PortCandidate.CreateCandidate(0, -15, PortDirection.North, 0);
// add it to the set and allow only one edge to connect to it
candidateSet.Add(candidate, 1);
// do the same for the other three corners
candidateSet.Add(
    PortCandidate.CreateCandidate(0, 15, PortDirection.South, 0), 1);
candidateSet.Add(
    PortCandidate.CreateCandidate(15, 0, PortDirection.East, 0), 1);
candidateSet.Add(
    PortCandidate.CreateCandidate(-15, 0, PortDirection.West, 0), 1);

// to allow more edges to connect at the top and bottom
// create extra candidates and allow Integer.MAX_VALUE edges to connect

// to avoid that these candidates are occupied before the others
// associate a cost of 1 with them
candidateSet.Add(
    PortCandidate.CreateCandidate(0, -15, PortDirection.North, 1),
    int.MaxValue);
candidateSet.Add(
    PortCandidate.CreateCandidate(0, 15, PortDirection.South, 1),
    int.MaxValue);

To influence the matching process, a subset of the PortCandidate objects used for a node can additionally be associated with the respective ports of its connecting edges. The subset then defines a restricted set of desired port candidates an edge prefers to connect to. The PortCandidate objects can be combined using ICollection objects which are stored by means of data providers. The data providers are registered with the graph using the look-up keys SourcePcListDpKey and TargetPcListDpKey.

Table 10.7, “Layout support for port candidates” lists the layout algorithms that provide support for port candidates.

Table 10.7. Layout support for port candidates

Layout Style Classname Note
Hierarchical IncrementalHierarchicLayouter IncrementalHierarchicalLayouter supports port candidates as soon as they are set. See the description of incremental hierarchical layout for more information.

Setup for Layout

The PortCandidateSet objects for the node set of a graph can be registered by adding an IMapper to the mapper registry of an IGraph-based graph using the NodeDpKey data provider look-up key as the mapper's tag.

Example 10.8. Registering candidates (IGraph API)

// 'candidateSet' is of type yWorks.yFiles.Layout.PortCandidateSet
// 'node' is of type yWorks.yFiles.UI.Model.INode and is the node which should
// be associated with the candidate set
// 'graph' is of type yWorks.yFiles.UI.Model.IGraph.

// Create a mapper to associate the candidates with the node.
IMapper<INode, PortCandidateSet> pcMap =
    new DictionaryMapper<INode, PortCandidateSet>();
// Associate the candidate set with the node.
pcMap[node] = candidateSet;

// Add the mapper to the mapper registry of the graph.
graph.MapperRegistry.AddMapper(PortCandidateSet.NodeDpKey, pcMap);

Tutorial Demo Code

Setup of port candidate sets can be observed in the PortCandidateWindow tutorial demo application. The LogicGateWindow demo application also demonstrates how to configure port candidates for nodes.

Modeling Enhanced Port Constraints Using Port Candidates

The same scheme of combining PortCandidate objects using Collection objects as used for the matching functionality also enables creating enhanced port constraint definitions for edges. The layouters which support this feature are listed in Table 10.8, “Layout support for enhanced port candidates”.

Table 10.8. Layout support for enhanced port candidates

Layout Style Classname Note
Hierarchical IncrementalHierarchicLayouter IncrementalHierarchicalLayouter supports port candidates as soon as they are set. See the description of incremental hierarchical layout for more information.

In particular, this scheme is supported by yFiles routing algorithms, and it allows to conveniently specify side constraints comprising two or three sides, for example. Table 10.9, “Routing support for port candidates” lists the routing algorithms that provide support for port candidates modeling enhanced port constraints.

Table 10.9. Routing support for port candidates

Routing Style Classname Note
Orthogonal OrthogonalEdgeRouter, ChannelEdgeRouter, BusRouter, and EdgeRouter All classes by default support port candidates as soon as they are set. See the descriptions of OrthogonalEdgeRouter, ChannelEdgeRouter, BusRouter, and EdgeRouter for more information.

Setup for Routing

Example 10.9, “Creating enhanced port constraints using port candidates (IGraph API)” shows how port candidates can be used to model enhanced port constraints that allow the source port of edges to connect to two sides of the start nodes.

Example 10.9. Creating enhanced port constraints using port candidates (IGraph API)

// 'graph' is of type yWorks.yFiles.UI.Model.IGraph.

// Define a collection of port candidates for the source ports of all edges.
ICollection<PortCandidate> pcc = new List<PortCandidate>();
// Create port candidates that conceptually correspond to classic side
// constraints (weak constraints) and add them to the collection.
// East side.
pcc.Add(PortCandidate.CreateCandidate(PortDirection.East));
// South side.
pcc.Add(PortCandidate.CreateCandidate(PortDirection.South));

// Create a data provider (adapter) that returns the collection of port
// candidates for each edge.
// Use the "well-known" look-up key defined in class PortCandidate.
graph.MapperRegistry.AddMapper(PortCandidate.SourcePcListDpKey,
                               delegate(IEdge e) { return pcc; });

// Invoke an edge routing algorithm.
graph.ApplyLayout(new OrthogonalEdgeRouter());

Edge/Port Grouping (Bus-Style Edge Routing)

Edge grouping means bundling of a set of edges to be treated in a common manner regarding some aspects of edge path generation. Specifically, if edges at a common source node, for example, are declared an edge group at their source ends, then their source ports will be anchored at the same location.

Additionally, all grouped edges will also be routed in bus-style, i.e., their paths will share a common edge segment. If edges at different source (target) nodes are declared an edge group at their source (target) ends, then they will be routed in bus-style only.

Figure 10.5. Edge groups

Edge groups
Edge groups
Edge groups
Hierarchical layout without any edge groups, ... ... with an edge group at the source ends of outgoing edges at node A. The source ports are anchored at the same location. Also, the edges are routed in bus-style, i.e., their paths share a common edge segment. ... with an edge group at the source ends of outgoing edges at node a, b, and c. The edges are routed in bus-style, i.e., their paths share a common edge segment.

Declaring an edge group at either source or target ends of a set of edges is done by associating a common object with the edges via a data provider. Depending on which end the edge group is declared for, an IMapper is added to the mapper registry of the IGraph-based graph using either the SourceGroupIdDpKey or TargetGroupIdDpKey look-up key as the mapper's tag.

Note

Edge grouping is also referred to as port grouping sometimes. If edges from an edge group have associated inconsistent, or even contradicting port constraints, then the location of the common port is not guaranteed to obey any of them.

Table 10.10, “Layout support for edge groups” lists the layout algorithms that provide support for edge groups.

Table 10.10. Layout support for edge groups

Layout Style Classname Note
Hierarchical IncrementalHierarchicLayouter IncrementalHierarchicLayouter by default generates edge/port groups as soon as they are declared. See the description of the hierarchical layout style for more information.
Orthogonal DirectedOrthogonalLayouter The directed orthogonal layout algorithm by default generates edge/port groups as soon as they are declared. See the description of directed orthogonal layout for more information.

Table 10.11, “Routing support for edge groups” lists the routing algorithms that provide support for edge groups.

Table 10.11. Routing support for edge groups

Routing Style Classname Note
Orthogonal OrthogonalEdgeRouter, EdgeRouter OrthogonalEdgeRouter's support for edge/port groups is partly handled by prepended layout stages. See the description of OrthogonalEdgeRouter for more information. Class EdgeRouter provides inherent support for edge/port groups.

Setup for Layout

Example 10.10, “Creating an edge group at a common target node (IGraph API)” demonstrates how edge groups are declared, and how an IMapper is added to the mapper registry of the IGraph-based graph using the look-up key TargetGroupIdDpKey as the mapper's tag. During layout calculation, an algorithm first retrieves the data provider using the look-up key, and afterwards retrieves the contained information.

Figure 10.6. Edge group at a common target node

Edge group at a common target node
Edge group at a common target node
Hierarchical layout without any edge groups... ... and with an edge group at the target ends of the edges. All target ports are anchored at the same location at the common node. Also, the edges are routed in bus-style, i.e., their paths share a common edge segment.

Example 10.10. Creating an edge group at a common target node (IGraph API)

// 'graph' is of type yWorks.yFiles.UI.Model.IGraph.
// 'specificNode' is of type yWorks.yFiles.UI.Model.INode.

// Create a mapper.
IMapper<IEdge, object> egMap = new DictionaryMapper<IEdge, object>();

// Declare an edge group for the target end of all incoming edges at a specific
// node.
string targetEdgeGroupID = "All my grouped edges.";
foreach (IEdge e in graph.InEdgesAt(specificNode)) {
  egMap[e] = targetEdgeGroupID;
}

// Add the mapper to the mapper registry of the graph.
// Use the "well-known" look-up key defined in class PortConstraintKeys as tag.
graph.MapperRegistry.AddMapper(PortConstraintKeys.TargetGroupIdDpKey, egMap);

// Invoke the layouter.
graph.ApplyLayout(new IncrementalHierarchicLayouter());

Tutorial Demo Code

Setup of edge groups can be observed in the PortCandidateWindow tutorial demo application.

Partition Grid

For the calculation of partitioned layouts, i.e., in particular the special case of swimlane layouts, the so-called partition grid provides the necessary support.

Class PartitionGrid encapsulates a simple grid-like structure consisting of rows and columns. In addition to the structure itself, the partition grid also holds geometric information related to both rows and columns, like, e.g. minimum heights/widths or insets.

Figure 10.7, “Partition grid” shows a partitioned layout. Note the two-dimensional partition which results from the rows and columns.

Figure 10.7. Partition grid

Partitioned layout.
Left-to-right partitioned layout.

The geometric information specific to a row or column is available through its descriptor object, which is an instance of RowDescriptor or ColumnDescriptor, respectively.

Table 10.12, “Layout support for swimlane/partitioned layout” lists the layout algorithms that provide support for swimlane/partitioned layout.

Table 10.12. Layout support for swimlane/partitioned layout

Layout Style Classname Note
Hierarchical IncrementalHierarchicLayouter IncrementalHierarchicLayouter provides direct support for swimlane/partitioned layout. See the description of IncrementalHierarchicLayouter's support for Swimlane Layout for more information.
Organic SmartOrganicLayouter SmartOrganicLayouter provides direct support for swimlane/partitioned layout. See the description of Partitioned Layout for more information.

Setup for Layout

With the classes from the yFiles for Silverlight Complete distribution, the setup for swimlane/partitioned layout calculation of a graph with table structures can be reduced to a minimum by using the MorphLayout convenience (extension) method as shown in Example 10.11, “Swimlane/partitioned layout preparation”. Internally, this method uses the services of class TableLayoutConfigurator to take care of all necessary configuration steps related to swimlane/partitioned layout.

Example 10.11. Swimlane/partitioned layout preparation

// 'graph' is of type yWorks.yFiles.UI.Model.IGraph.

var ihl = new IncrementalHierarchicLayouter() {
                ComponentLayouterEnabled = false,
                LayoutOrientation = LayoutOrientation.LeftToRight,
                OrthogonalRouting = true,
                RecursiveGroupLayering = false };
((SimplexNodePlacer) ihl.NodePlacer).BaryCenterMode = true;

try {
  // Invoke layout calculation.
  // Internally, MorphLayout uses TableLayoutConfigurator to prepare all 
  // relevant information for a layout algorithm.
  graphControl.MorphLayout(ihl, TimeSpan.FromMilliseconds(500), null);
}
catch (Exception exception) {
  Console.WriteLine(exception);
}

Tip

Convenience class LayoutExecutor also uses the services of class TableLayoutConfigurator, but additionally provides access to its internal TableLayoutConfigurator instance for configuration and customization.

Example 10.12, “Swimlane/partitioned layout preparation (IGraph API)” demonstrates how to set up a swimlane/partitioned layout without the convenience functionality from the yFiles for Silverlight Complete distribution.

The services of the PartitionGrid class can be used to

  • define a grid-like structure consisting of rows and columns that represents a partition,
  • create IDs for the cells of a partition (single cells and ranges of cells), which result from the rows and columns setup, and
  • assign the nodes of a diagram to these partition cells by means of the cell IDs.

Partitioned layout calculation needs a PartitionGrid object registered via a data provider with the graph using look-up key PartitionGridDpKey and the mapping of the nodes to partition cells registered via data provider with the graph using look-up key PartitionCellDpKey. During layout calculation, an algorithm first retrieves the data providers using the look-up keys, and afterwards retrieves the contained information.

Basically, the partition grid needs to be created, and the data providers that hold the necessary information about the partition grid and the mapping of nodes to cells have to be filled manually, and be registered with the graph using the data provider look-up keys defined in class PartitionGrid.

Example 10.12. Swimlane/partitioned layout preparation (IGraph API)

// 'graph' is of type yWorks.yFiles.UI.Model.IGraph.
// 'n1' to 'n6' are of type yWorks.yFiles.UI.Model.INode.

// Create a grid having three rows and four columns.
PartitionGrid grid = new PartitionGrid(3, 4);

// Create an IMapper to store the mapping of nodes to swimlanes, resp. partition
// grid cells.
IMapper<INode, PartitionCellId> cellMap =
    new DictionaryMapper<INode, PartitionCellId>();

// Assign the nodes to the cells.
cellMap[n1] = grid.CreateCellId(1, 0);
cellMap[n2] = grid.CreateCellId(0, 1);
cellMap[n3] = grid.CreateCellId(2, 2);
cellMap[n4] = grid.CreateCellId(1, 3);
cellMap[n5] = grid.CreateCellId(0, 3);
cellMap[n6] = grid.CreateCellId(0, 3);

// Add the PartitionGrid object and the mapper to the mapper registry of the
// graph.
// Use the "well-known" look-up keys defined in class PartitionGrid as tags.
IMapperRegistry mapperRegistry = graph.MapperRegistry;
mapperRegistry.AddMapper(PartitionGrid.PartitionGridDpKey,
                         Mappers.CreateConstant<object, PartitionGrid>(grid));
graph.MapperRegistry.AddMapper(PartitionGrid.PartitionCellDpKey, cellMap);

// Create the layout algorithm...
IncrementalHierarchicLayouter ihl = new IncrementalHierarchicLayouter();
ihl.LayoutOrientation = LayoutOrientation.LeftToRight;
// ... and start layout calculation.
graph.ApplyLayout(ihl);

Note that Example 10.12, “Swimlane/partitioned layout preparation (IGraph API)” shows the basic setup of the partition grid seen in Figure 10.7, “Partition grid”. Observe how the layout algorithm respects the specified organization of the nodes within the partition cells.

To create IDs for the cells of a partition (single cells and ranges of cells), class PartitionGrid provides the methods below. The IDs can be used to assign the nodes of a diagram to partition cells. Nodes that do not have an ID associated, can be placed in any partition cell by a layout algorithm.

PartitionCellId CreateCellId(int rowIndex, int colIndex)
Description Creates partition IDs for single cells.
PartitionCellId CreateCellSpanId(int fromRowIndex, int fromColIndex,
                                 int toRowIndex, int toColIndex)
Description Creates partition IDs that represent a (two-dimensional) range of cells stretching the specified rows and columns.

Important

In the set of all specified cells of a partition (single cells and ranges of cells), no two ranges of cells are allowed to overlap with each other, or overlap with a single cell, i.e., the set needs to be disjoint. In particular, this also means that no partition cell can have more than one partition ID associated with it.

Class PartitionGrid enables further optimization of the layout outcome when there are no cell spans specified in a partition grid. The following properties can be used to control whether the order of rows and columns in a swimlane/partitioned layout shall be automatically determined.

bool OptimizeRowOrder { get; set; }
Description Optimize the order of rows to minimize the diagram's overall edge lengths.
bool OptimizeColumnOrder { get; set; }
Description Optimize the order of columns to minimize the diagram's overall edge lengths.

Node Halos

A node halo basically specifies additional paddings around a node. A layout algorithm that supports node halos, keeps this area clear of graph elements, except the labels of this specific node and the adjacent segments of its edges.

Class NodeHalo can be used to denote a node's additional size requirements. The NodeHalo objects for the node set of a graph can be registered by adding an IMapper to the mapper registry of an IGraph-based graph using the NodeHaloDpKey data provider look-up key as the mapper's tag.

The following layout algorithms provide support for node halos:

Table 10.13. Layout support for node halos

Layout Style Classname Note
Hierarchical IncrementalHierarchicLayouter IncrementalHierarchicLayouter by default obeys node halos as soon as they are declared. See the description of the hierarchical layout style for more information.
Orthogonal OrthogonalLayouter, OrthogonalGroupLayouter, DirectedOrthogonalLayouter, and CompactOrthogonalLayouter All classes by default support node halos as soon as they are declared. See the descriptions of OrthogonalLayouter, OrthogonalGroupLayouter, and DirectedOrthogonalLayouter for more information. Note that CompactOrthogonalLayouter supports node halos via the OrthogonalLayouter that it uses internally.
Tree TreeLayouter, BalloonLayouter, and GenericTreeLayouter All classes by default support node halos as soon as they are declared. See the descriptions of TreeLayouter, BalloonLayouter, and GenericTreeLayouter for more information.
Circular CircularLayouter CircularLayouter by default obeys node halos as soon as they are declared. See the description of the circular layout algorithm for more information.
Organic SmartOrganicLayouter SmartOrganicLayouter by default obeys node halos as soon as they are declared. See the description of the organic layout algorithm for more information.
Radial RadialLayouter RadialLayouter by default obeys node halos as soon as they are declared. See the description of the radial layout algorithm for more information.

The following routing algorithms provide support for node halos:

Table 10.14. Routing support for node halos

Routing Style Classname Note
Orthogonal EdgeRouter Class EdgeRouter provides inherent support for node halos.