This allows dropping several workarounds in the CMake build system. The only
supported platform with a CMake version less than 3.13.0 is Ubuntu 18.04. Given
CMake is not the default build system, the age of Ubuntu 18.04 makes it unlikely
there are users there building Graphviz from source, and later CMake versions
are easily obtainable from Kitware, it seems reasonable to increase this
requirement.
The `rsvg_term` function has been a no-op for some time:¹
rsvg_term has been deprecated since version 2.36 and should not be used in
newly-written code.
There is no need to de-initialize librsvg.
This function does nothing.
Graphviz was calling it when linked against librsvg 2.36 (2.36.0 was released
2012-03-26). I do not know why this code was conditional as `rsvg_term` has been
a no-op since 2.35.0.² Moreover, calling it prior to it becoming a no-op was
wrong too. The commit that removed its functionality notes:
rsvg_term() was dangerous to call
The problem is that it previously called libxml2’s `xmlCleanupParser` whose
documentation states:³
This function name is somewhat misleading. It does not clean up parser state,
it cleans up memory allocated by the library itself. It is a cleanup function
for the XML library. It tries to reclaim all related global memory allocated
for the library processing. It doesn't deallocate any document related memory.
One should call xmlCleanupParser() only when the process has finished using
the library and all XML/HTML documents built with it. See also xmlInitParser()
which has the opposite function of preparing the library for operations.
WARNING: if your application is multithreaded or has plugin support calling
this may crash the application if another thread or a plugin is still using
libxml2. It's sometimes very hard to guess if libxml2 is in use in the
application, some libraries or plugins may use it without notice. In case of
doubt abstain from calling this function or do it just before calling exit()
to avoid leak reports from valgrind !
This seems to have come to light ~2010.⁴ But presumably there is still a long
tail of software in the wild still, like Graphviz, erroneously calling
`rsvg_term`.
The `-ffast-math` compiler option enables a mode of floating point semantics
that are heavily relaxed from strict IEEE 754 conformance in the name of speed.¹
The permissible optimizations under `-ffast-math` include transformations that
produce floating point results most users would consider wrong. It is unclear
why “do math fast but incorrectly” is a useful mode. It seems the world is
finally coming around to this tenet.²
This change stops enabling `-ffast-math` anywhere in the Autotools build system.
Gitlab: fixes #1412, #2296 Reported-by: Kasper Daniel Hansen Reported-by: Ross Barnowski
¹ https://gcc.gnu.org/wiki/FloatingPointMath
² https://simonbyrne.github.io/notes/fastmath/,
https://moyix.blogspot.com/2022/09/someones-been-messing-with-my-subnormals.html
remove suppression of -ffast-math when building with ICC
The Intel C Compiler does not support the `-ffast-math` command line option, so
this logic was suppressing it. But it is coming before anything in the Graphviz
build system itself that would add `-ffast-math`. So it is actually suppressing
a `-ffast-math` addition coming from the user’s environment. If you are a user
compiling Graphviz with ICC, I have a very simple alternative for you: do not
pass `-ffast-math` explicitly.
Of the platforms Graphviz supports, the one with the oldest CMake version
available is Ubuntu 18.04, which has CMake 3.10.2. This change raises the
baseline CMake requirement to indicate we no longer support CMake 3.9.
The diff between CMake 3.9 and 3.10 does not actually contain anything useful to
Graphviz. But it still seems wise to proactively move our floor forwards.
Mark Hansen [Sat, 8 Oct 2022 03:32:49 +0000 (14:32 +1100)]
Use full paths to pangocairo libraries, not names
This lets me build on macOS.
Thanks to Matthew for finding this fix for #2286
There are a few other usages of PANGOCAIRO_LIBRARIES within Graphviz,
but none that I'm currently compiling on macOS. Maybe those should be
moved too, but I've just started with this one.
Magnus Jacobsson [Fri, 16 Sep 2022 10:35:53 +0000 (12:35 +0200)]
shapes: point_init/point_inside: fix clipping of edge at node outline
Take node penwidth into account for the point node shape
Following the fix for polygon and ellipse shapes except the 'point'
shape, this fixes the second part of arrow not respecting penwidth for
the 'point' shape. A similar fix needs to be applied to fix the second
part for the 'cylinder' node shape.
The test_edge_node_overlap_point_node_shape test now succeeds, so the
expectancy that it should fail is removed.
Towards https://gitlab.com/graphviz/graphviz/-/issues/372.
Magnus Jacobsson [Fri, 16 Sep 2022 08:53:36 +0000 (10:53 +0200)]
shapes: poly_init: fix clipping of edge at node outline for ellipse node shapes
Take node penwidth into account also for ellipse node shapes.
Following the fix for polygon node shapes, this fixes the second part
of arrow not respecting penwith for ellipse shapes other than
'point'. Similar fixes need to be applied to fix the second part for
the 'point' and 'cylinder' node shapes.
The test_edge_node_overlap_ellipse_node_shapes_except_point test now
succeeds, so the expectancy that it should fail is removed.
Towards https://gitlab.com/graphviz/graphviz/-/issues/372.
Magnus Jacobsson [Thu, 15 Sep 2022 17:01:54 +0000 (19:01 +0200)]
arrows: miter_point: add fallback to bevel
The 'l' and 'r' arrow shape modifiers make the arrow tip have a sharp
angle and causes the normal miter point to exceed the 'miter-limit'
and SVG renderers to fall back to a bevelled corner.
Magnus Jacobsson [Sun, 17 Apr 2022 16:55:50 +0000 (18:55 +0200)]
arrows: arrow_length_normal: take edge penwidth into account when calculating length
This causes the edge stem to be clipped at the visual outline of the
edge arrow instead of at its "ideal" bounding box which fixes the too
large overlap between them that was introduced by eariler commits in
this series.
The test_max_edge_stem_arrow_overlap_simple.cpp,
test_edge_node_overlap_normal_and_inv_edge_arrows
test_edge_node_overlap_simple and test_edge_node_overlap_node_shapes
test cases now succeed, so the expectancy that they should fail is
removed.
Towards https://gitlab.com/graphviz/graphviz/-/issues/372.
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.
projects / graphviz / log