GitLab

Quiet the build a little...

Thanks to
https://github.com/endlessm/ostree/blob/47a54bf876023b0cb457bc8a4f4264f9b2ed5438/Makefile.am
for the incantations.

This makes it possible to release tarballs with all the Rust
dependencies embedded in them.

Hopefully this paves the way for distros to use Cargo's source
replacement to build librsvg with their own versions of dependencies.

Thanks to Sergey Bugaev for the tip.

With this, the test masking-path-04-b.svg passes.

bgo#621088: rsvg_cairo_clip_render_new(): Don't leave uninitialized fields in the parent RsvgCairoRender

A text object used as a clip path caused librsvg to crash.  The reason
is that when we create an RsvgCairoClipRender, we were leaving an
all-zeros clip_render->super.bbox field.

This caused two things:

1. An all-zeros RsvgBbox is invalid; it should be "virgin" or actually
have a valid affine.

2. We were not preserving the bbox from the parent rendering context,
so the clipped objects would not know their viewport size.  Now we
copy the original cairo_render->bbox to our derived
clip_render->super.bbox, and start afresh with an empty bb_stack
inside the clip_render.

The "use" one is for nested use/symbol.

The "viewattr" one is for preserveAspectRatio on image elements.

We still have RsvgViewBox with an "active" boolean field for the C
code.  The Rust code now handles Option<ViewBox> throughout, and only
exposes that to C with rsvg_node_svg_get_view_box().

Massimo Valentini authored Aug 30, 2017 and Federico Mena Quintero committed Aug 30, 2017

If the cairo_t's transformation changes between the time the
PangoLayout is created and the time it is shown, one needs to
pango_cairo_update_layout() first.

We use the list of supported features with bsearch(), and the list
was not sorted.

Added struct-cond-03-t.svg from the SVG test suite to this effect.
The reference PNG is different from the official test suite's original
one, because we do NOT support the SVG DOM feature.  Still, the test
file lets us test for <switch> working based on supported feature names.

Sigh...

We also modify tests/crash.c to test for this condition, and add a
couple of new tests.

This is a basic test for the <switch> element that uses an unsupported
extension name in the requiredExtensions attribute.

We were representing unknown elements as a NodeGroup, so their
children would be rendered.

Now we represent them as NodeDefs.  This is like a NodeGroup, but it
doesn't do any rendering of itself or its children.  The SVG spec says
that we should stop rendering the file if we encounter an unknown
element, but it seems that real-world renderers are more lenient - so
we'll just not render unknown elements and their children.

https://bugzilla.gnome.org/show_bug.cgi?id=634514

This makes it easier to see what the arguments PathBuilder::arc() are about.

We will move PathBuilder from storing cairo::PathSegment directly, to
storing its own PathCommand.  This will be an enum similar to Cairo's,
but that can also store SVG's Arc command, and possibly SVG's quadratic
Béziers, too.

Currently, when adding markers to a path, we have unwanted markers in
the middle of arcs, as they get exploded into Bézier curve segments.  By
having our own Arc PathCommand, we can defer the arc-to-Béziers step
until we finally feed the PathBuilder into Cairo.

This should also make it possible to have tests for parsing Arc
commands; currently there are none.

Yay!

Per https://www.w3.org/TR/SVG/styling.html#StyleElementTypeAttribute ,
if a <style> element doesn't specify a "type" attribute, then it
should be as if type="text/css".  We should really pick up that value
from the svg element's contentStyleType, but we don't read that yet.

https://bugzilla.gnome.org/show_bug.cgi?id=786372

No creator function should ever return a NULL node, so assert that and
remove the check.

For elements of unknown type, we already turn them into groups in
get_node_creator_for_element_name().

On Windows the GTK+ stack does not hard depend on PangoFT2 (thus
Fontconfig--GTK+ uses PangoWin32 to do the Font discovery and
configuration stuff by default, unless one uses an envvar to force
PangoFT2 usage), unlike *NIX platforms, so we need to check for
it by doing:

-On Windows, enable the test code that uses PangoFT2/FontConfig if
 PangoFT2 and FontConfig is found during configure.  On Visual Studio
 builds, this is set to be disabled in config.h.win32(.in), and can be
 manually enabled by uncommenting #define HAVE_PANGOFT2 1 in
 config.h.win32 prior to the build (or rebuild).  This continues to have
 FontConfig and PangoFT2 to act as an optional dependency.

-On non-Windows platforms, make PangoFT2 and FontConfig a hard dependency,
 which is what the current code assumes.

We might probably need to make the custom TTF load via PangoWin32 and/or
the native Windows API to run the tests when PangoFT2 and FontConfig are
not found on Windows.

Also bump the Pango dependency to 1.38 as the test code uses API that is
introduced in 1.38.x.

https://bugzilla.gnome.org/show_bug.cgi?id=779405

If the RsvgHandle was written to but not closed, then we'll still have
an XML parser context at dispose time - don't leak it.

Fixes the leak in https://bugzilla.gnome.org/show_bug.cgi?id=777833#c2

This makes it easier to see, well, which reading state we are in.

libxml2's xmlFreeParserCtxt(c) does not free the underlying c->myDoc;
that needs to be freed separately.  We are forgetting to do that in a
couple of places, so rsvg_free_xml_parser_and_doc() will take care of
that in a single place.

http://xmlsoft.org/html/libxml-parser.html#xmlFreeParserCtxt