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.
We now always have a "current point" which is either the last point an
operation was made to, or (0, 0) if no drawing operation has
been made yet.
Adding a contour of any kind to the builder will always update the
current point to that contour's end point.
1. Allow specifying the max number of contours
2. Be smarter about creating the paths:
With 10% chance, create a "weird" path like the empty one or only
points or things like that.
Otherwise create a bunch of contours, with 2/3 a standard contour,
with 1/3 a predetermined one.
Instead of the Cairo method and imitating cairo_path_data_t, use the
Skia method and keep points and operations separate.
That way we get a points array that includes the starting point -
because it's always the end point of the previous operation.
Make .svg use the Cairo renderer to save to an SVG file.
It's useful when comparing rendering behavior and times with
web browsers (as long as one is aware that browsers build a full
DOM tree out of those SVGs).
