When curves have long straight parts that decompose into a single line,
don't try to split them. Instead, split at a well-known position and a
the part of that long straight line as a line.
This gives way more accurate numbers and is more accurate than 1% for
everything but contours with very small weight and
start_point == end_point, where the error is closer to 1.5%.
When decomposing curves that are too straight, we may emit lines for
long parts of the curve. These lines do not properly map
t => distance
and it is better to treat them as a regular line than a curve.
This reason argument gives that information.
No users so far, that will happen in followup commits.
This is a regular path creation API, so treat it that way.
On top, it is rather awkward if the only constructor for a path that is
immediately visible to people reading the docs is the one that takes a
Cairo path - when we want to deprecate Cairo.
These are just nice apis to have and avoid having to carry
these around as extra arguments in many places.
This was showing up as inconvenience in writing tests
for the measure apis.
The progress is non-uniform, so simple translation of progress doesn't work.
So check if larger and smaller values inch closer towards minimal distance.
Conics are evil in that their parameter skews towards the center, and if
it's a very flat conic (weight almost equal to 0), then we'd approximate
it with a single segment and not subdivide, which would cause the
parameter to be wildly off around 0.25 or 0.75.
And that would cause offset calculations to fail.
GskCurve is an abstraction for path operations. It's essentially a
collection of vfuncs per GskPathOperation.
GskStandardContour has been ported to use it where appropriate.
A gskpathop is a pointer to a graphene_point_t* with the low bits used
to encode the GskPathOperation. It's an easy way to introduce API for
operations.
So far it's just used to replace GskStandardOperation.
This way we can default to the siplest possible foreach() output - like
cairo_copy_path_flat() decomposing everything into lines - and add flags
to get more and more fancy.
This will be useful to have conics automatically decomposed for Cairo
drawing or if we want to add more line types in the future.
Implement this in the obvious way, using the decomposed form
of standard contours. Since the decomposed form is part of the
measure object, this api moves from gsk_path_in_fill to
gsk_path_measure_in_fill.
This test includes an implementation of a gsk_path_equal() func with
a tolerance that is necessary because parsing does not always work
100% exactly due to floating point rounding, so we can't just
compare the to_string() output.
Write out the commands for rects and circles in a special
way, and add code in the parser to recognize this, so we
can successfully round-trip these through the SVG path format.
The special way - for people who want to use it for debugging -
for now is that we use uppercase "Z" to close standard paths, but
lowercase "z" to close our special paths.
A test is included, but the random path serializations should take care
of it, too.
The svg A can not do a full circle, since it is a two point
parametrization - if the start and end point are the same,
it draws nothing. So, use two arcs.
Implement the SVG path syntax to read back the strings
that we generate when serializing paths. The tests for
this code are taken from librsvg.
This includes an elliptical arc implementation according
to the SVG spec. The code is mostly taken from librsvg,
but pretty directly follows the SVG spec implementation
notes. We don't export this, since the parametrization
is inconvenient. We do want an arc_to API, but
these are not the arcs we are looking for.
This is elliptical arc implementation according to the SVG spec.
The code is mostly taken from librsvg, but pretty directly
follows the SVG spec implementation notes.
We don't export this, since the parametrization is inconvenient.
We do want an arc_to API, but these are not the arcs we are
looking for.
It will be used in parsing SVG path syntax.
Add a miter limit to GskStroke. This will be needed to
fully implement line joins.
Also introduce the GSK_LINE_JOIN_MITER_CLIP value,
following SVG 2.0. cairo does not have it, so translate
it to plain miter when using cairo.
