Magnus Jacobsson [Sun, 17 Apr 2022 15:45:24 +0000 (17:45 +0200)]
arrows: refactor arrow length calculation to allow arrow type specific length functions
Add a len function to arrowtype_t. This is currently a no-op. All
arrow types use a generic function that just returns the nominal
length. Future commits will replace the generic function with
functions specific for each arrow type.
Towards https://gitlab.com/graphviz/graphviz/-/issues/372.
Magnus Jacobsson [Wed, 13 Apr 2022 21:01:41 +0000 (23:01 +0200)]
splines: bezier_clip: change to clip just inside instead of just outside the node
The previous changes removed *all* overlap between nodes and edges at
the expense of creating a very small gap instead. This is visually not
very pleasing. This change ensures that we get a very small minimum
overlap instead.
The test_min_edge_node_overlap_simple and
test_min_edge_node_overlap_node_shapes tests tests now succeed, so the
expectancy that they should fail is removed.
Towards https://gitlab.com/graphviz/graphviz/-/issues/372.
Magnus Jacobsson [Wed, 14 Sep 2022 19:58:57 +0000 (21:58 +0200)]
shapes: star_inside: fix clipping of edge at node outline
Take node penwidth into account when doing the clipping of the 'star'
shape. This causes the clipping to occur at the visible node outline
instead of at the "ideal" bounding box which does not take node
penwidth into account.
For the star shape, this fixes the second part of arrow not respecting
penwidth. Similar fixes need to be applied to fix the second part for
other node shapes.
The test_max_edge_node_overlap_node_shapes test case now succeeds, so
the expectancy that it should fail is removed.
Towards https://gitlab.com/graphviz/graphviz/-/issues/372.
Magnus Jacobsson [Mon, 11 Apr 2022 18:06:26 +0000 (20:06 +0200)]
shapes: poly_init/poly_inside: fix clipping of edge at node outline
Take node penwidth into account when doing the clipping. This causes
the clipping to occur at the visible node outline instead of at the
"ideal" bounding box which assumes a zero node penwidth.
For polygon shapes, this fixes the second part of arrow not respecting
penwidth. Similar fixes need to be applied to fix the second part for
other node shapes.
The test_max_edge_node_overlap_simple test now succeeds, so the
expectancy that it should fail is removed.
The test_min_edge_node_overlap_simple and
test_min_edge_node_overlap_node_shapes tests now fail since there's
now a small gap between the edge and the node, so they're temporarily
set to be expected to fail. This gap will be removed in an upcoming
commit in this series.
Towards https://gitlab.com/graphviz/graphviz/-/issues/372.
arrows: arrow_type_normal: fix positioning of normal/inv arrow
Take edge penwidth into account when calculating the outline of the
edge arrrow shape instead of using the "ideal" arrow shape assuming
zero penwidth.
This change moves the tip of the arrow so that it does not overlap the
node periphery assuming that the node penwidth is zero. To account for
the node penwidth is the second part that will be adressed in upcoming
commits.
For normal and inv arrows not using the 'l' or 'r' arrow shape
modifiers, this fixes the first part of arrow not respecting
penwith. Similar fixes need to be applied to fix the first part for
other arrow types. The 'l' and 'r' shape modifiers will handled in an
upcoming commit in this series.
The test_max_edge_stem_arrow_overlap_simple test case now fails since
there's now a slightly too large overlap between the edge stem and its
arrow heads, so the test case is temporarily set to be expected to
fail. This small overlap will be removed in an upcoming commit in this
series.
Towards https://gitlab.com/graphviz/graphviz/-/issues/372.
Magnus Jacobsson [Sun, 27 Mar 2022 10:56:45 +0000 (12:56 +0200)]
arrows: refactor arrow generating functions to return the actual start point
This is currently a no-op, but upcoming commits will adjust the arrow
start point to take pendwidth into account in order to avoid
overlapping the node periphery and subsequent primitive arrow shapes
of multi-shape arrows.
The arrow start point is the point on the arrow which is farthest away
along the edge from the node it is associated with.
Towards https://gitlab.com/graphviz/graphviz/-/issues/372.
tests: remove test_regression_subset_differences test
Upcoming commits will step by step make changes that affect the layout
and there's too much work to maintain the reference files, since they
differ slightly across operating systems. We only checked for
difference for a very small fraction of the subtests anyway so this
test did not add much value.
Note that the test_regression_failure test remains. It checks the exit
status of each subtest, but does not compare with reference files.
`fmin` is typically implemented as a compiler built-in and has the potential to
be more efficient than `MIN`, while also avoiding the loss of type safety and
double-expansion problems of macros.
`fmax` is typically implemented as a compiler built-in and has the potential to
be more efficient than `MAX`, while also avoiding the loss of type safety and
double-expansion problems of macros.
neatogen print_bounding_box: use cgraph wrappers for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
neatogen OverlapSmoother_new: use cgraph wrappers for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
neatogen relative_position_constraints_new: use cgraph wrapper for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
neatogen get_overlap_graph: use cgraph wrappers for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
This macro was mistakenly not used when the
test_edge_node_overlap_all_primitive_edge_arrows,
test_edge_node_overlap_normal_and_inv_edge_arrows and
test_edge_node_overlap_normal_and_inv_edge_arrows_all_modifiers tests
were introduced.
This ensures that the generated artifact file names begin with the
same name as the test case file.
remove SWIG setup steps in Windows build preparation script
As discussed on Gitlab,¹ this Windows build script tries to discover SWIG, but
none of the Windows options for building Graphviz support compiling any of the
components that use SWIG.
sccmap: re-enable non-silent output when '-v' is passed
Unix command line tools generally have a “last option wins” kind of semantics,
wherein it is valid to pass options multiple times or in combination with other
options that do their opposite. Thus when calling `sccmap -S -v`, the user could
reasonably expect that `-v` (“verbose”) reversed the effect of `-S` (“silent”).
This is also what the man page implies. But this was not what the code was
doing.
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
gvpack: replace CDT pair dictionaries with 'std::multiset'
This is intended to be a non-functional change with a number of benefits:
1. This is C++ code, so no need for custom CDT data structures. The STL
equivalents are likely more optimized, better understood by the compiler,
and more familiar to human readers.
2. We avoid the lib/common allocation routines (`NEW` macro and friends). Now
allocation failures naturally propagate outwards as `std::bad_alloc`
exceptions without any custom handling.
3. Related to (2), we no longer need to manually free any of these objects.
RAII takes care of all of this.
gvpack: replace CDT attribute dictionaries with std::maps
This is intended to be a non-functional change with a number of benefits:
1. This is C++ code, so no need for custom CDT data structures. The STL
equivalents are likely more optimized, better understood by the compiler,
and more familiar to human readers.
2. We avoid the lib/common allocation routines (`NEW` macro and friends). Now
allocation failures naturally propagate outwards as `std::bad_alloc`
exceptions without any custom handling.
3. Related to (2), we no longer need to manually free any of these objects.
RAII takes care of all of this.
mm2gv makeDotGraph: use cgraph wrappers for allocation
The lib/cgraph/alloc.h wrappers are similar to the older lib/common/memory.h
wrappers except (1) they are header-only and (2) they live in a directory
(cgraph) that is at the root of the dependency tree. The long term plan is to
replace all use of lib/common/memory.h with lib/cgraph/alloc.h.
fix erroneous commas in JSON output of graphs with only clusters
When a graph or subgraph contained exclusively subnodes that were clusters (that
is, it contained a non-zero number of subnodes, but all of them were clusters),
the output of `-Tjson` would contain an extra comma. This malformed JSON could
not be ingested by most downstream parsers.
This appears to have been a mistake in f82c51fc9644047e9ce80d860fea562e98d3311c
that introduced cluster skipping in the loop that emits nodes in JSON. It did
not account for the earlier part of the containing function that was intended to
early-exit if the loop would have a 0 iteration count.
As noted in the discussion of #2282, a couple of the maintainers believe this
manual JSON writing code is inherently fragile and likely contains more latent
bugs. But we do not have maintainer consensus on migrating to an established
JSON-writing library. This fix attempts to surgically address the current known
bug. But I cannot guarantee it does not introduce others.