| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Closes #950
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/822>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was added during the port of the filters code to Rust, but it is
redundant with tests/fixtures/reftests/svg1.1/filters-morph-01-f.svg
Also this file produces frequent failures in the test suite whenever
the font rendering stack changes even just a bit. The point of the
test is to test the feMorphology, not text rendering - so remove it in
favor of the other test from the SVG1.1 test suite, which does erosion
and dilation filters on paths, not on text.
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/817>
|
|
|
|
| |
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/810>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is a new limit, MAX_XINCLUDE_DEPTH, which is a constant with the
maximum level of nesting for XInclude.
We keep a counter of the current nesting level in XmlStateInner, and
check against the limit every time we need to xinclude another XML
document.
The sample file has <xi:include parse="xml" href=""/> which properly
causes the *same* file to be included, per https://www.w3.org/TR/xinclude-11/#include_element
The href attribute is optional; the absence of this attribute is
the same as specifying href="", that is, the reference is to the
same document.
Fixes https://gitlab.gnome.org/GNOME/librsvg/-/issues/942
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/810>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, an invalid "transform" property specified for clipPath
would bubble up as a non-recoverable "invalid matrix" error from
Cairo, stopping rendering at that point. Instead, we want to validate
all transforms and just not render the offending element.
This commit has many changes:
* Introduce a ValidTransform newtype, created with "impl
TryFrom<Transform> for Transform". This sees if the transform is
invertible before wrapping it. The idea is to do all transform
operations first, then see if the result is valid by trying to convert
to a ValidTransform.
* There is no "impl From<Transform> for cairo::Matrix" anymore, but
there is From<ValidTransform>. That way, we guarantee that an
unvalidated transform cannot be easily set on a Cairo context.
* DrawingCtx::get_transform() returns a ValidTransform, since a) it
comes from the cr, and Cairo already validated that transform for
us. Otherwise, the cr would have been in an error state.
* There is a new variant RenderingError::InvalidTransform, which lets
us use "?" everywhere as normal. This error case is caught in
Node::draw() and the node is just not drawn. Eventually we can move
to a scheme where we distinguish between fatal
errors (e.g. RenderingError::LimitExceeded) and recoverable ones.
Fixes https://gitlab.gnome.org/GNOME/librsvg/-/issues/930
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/800>
|
|
|
|
| |
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/796>
|
|
|
|
|
|
| |
Fixes https://gitlab.gnome.org/GNOME/librsvg/-/issues/743
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/793>
|
|
|
|
|
|
|
|
|
|
| |
When the input_bounds from the filter source is empty, we tried to
create a zero-sized image for tiling. This is not allowed. There is
nothing to tile in that case, so just return the original image to filter.
Fixes https://gitlab.gnome.org/GNOME/librsvg/-/issues/928
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/787>
|
|
|
|
| |
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/776>
|
|
|
|
| |
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/776>
|
|
|
|
| |
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/776>
|
|
|
|
| |
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/776>
|
|
|
|
| |
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/776>
|
|
|
|
| |
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/776>
|
|
|
|
| |
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/776>
|
|
|
|
|
|
|
| |
From 123-blahblah.svg to bug123-blahblah.svg, so that it's easier to
turn them into Rust symbols like bug123_blahblah later.
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/776>
|
|
|
|
|
|
|
|
|
|
|
| |
This is https://gitlab.gnome.org/GNOME/librsvg/-/issues/913 and it
already works fine, but more or less by accident - the feGaussianBlur
filter primitive gets marked as "in error" due to the negative
stdDeviation, and the filters code skips it.
This test is for future-proofing the refactoring that follows.
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/763>
|
|
|
|
| |
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/740>
|
|
|
|
| |
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/739>
|
|
|
|
|
|
|
|
|
|
|
| |
referenced symbol
We meant to look at the referenced <symbol>'s computed values, not the
<use>'s computed values.
Fixes https://gitlab.gnome.org/GNOME/librsvg/-/issues/92
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/737>
|
|
|
|
| |
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/728>
|
|
|
|
|
|
|
|
| |
After SVG2, where width/height always compute to 100% because their
initial value is "auto", has_width and has_height will always be
TRUE. It is only has_viewbox that needs testing.
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/727>
|
|
|
|
| |
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/727>
|
|
|
|
|
|
|
|
| |
bounding box
Fixes https://gitlab.gnome.org/GNOME/librsvg/-/issues/880
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/713>
|
|
|
|
|
|
| |
This still passes; the next one will fail.
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/697>
|
|
|
|
|
|
| |
Finally, something I've been wanting to do for a while.
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/697>
|
|
|
|
| |
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/697>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
match the default viewport
Curiously, this manifests in the same way as #521, and is fixed by
removing the code that I added to fix that one.
I'm thinking that all the cleanups around viewport and viewBox
handling caused the old code to not be needed anymore.
(Found by adding the same debug output to librsvg-2.48 and the main
branch, and comparing executions.)
Fixes https://gitlab.gnome.org/GNOME/librsvg/-/issues/823
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/695>
|
|
|
|
|
|
|
|
|
| |
It seems I broke this when splitting patterns into the resolve stage
and the drawing stage.
Fixes https://gitlab.gnome.org/GNOME/librsvg/-/issues/721
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/679>
|
|
|
|
|
|
|
|
|
|
|
| |
These tests:
pservers-grad-07-b-ref.png
pservers-grad-08-b-ref.png
They both have text that has different scaling in the x/y dimensions;
they are rendered correctly now.
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/673>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It looks like this won't be fixed in Pango soon, so let's draw all
text as paths instead. We create the text-as-path with an identity
transform, and then replay the path to the Cairo context with the
current transform.
I disabled tests/fixtures/text/804-tspan-direction-change.svg in
tests/src/text.rs because its spacing is different - need to figure
that one out.
Also regenerated the test reference files that have text in them; with
text-as-path they render slightly differently.
Fixes https://gitlab.gnome.org/GNOME/librsvg/-/issues/599
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/673>
|
|
|
|
| |
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/673>
|
|
|
|
|
|
| |
This reverts commit fc5579d408001b1063ac342983d0eadf3265c156.
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/672>
|
|
|
|
|
|
| |
This reverts commit 4887a02b7f1b22286c4600349d1abc005657c4e0.
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/672>
|
|
|
|
|
|
| |
Yay, code coverage!
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/670>
|
|
|
|
|
|
|
|
|
|
|
| |
These tests:
pservers-grad-07-b-ref.png
pservers-grad-08-b-ref.png
They both have text that has different scaling in the x/y dimensions;
they are rendered correctly now.
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/660>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It looks like this won't be fixed in Pango soon, so let's draw all
text as paths instead. We create the text-as-path with an identity
transform, and then replay the path to the Cairo context with the
current transform.
I disabled tests/fixtures/text/804-tspan-direction-change.svg in
tests/src/text.rs because its spacing is different - need to figure
that one out.
Also regenerated the test reference files that have text in them; with
text-as-path they render slightly differently.
Fixes https://gitlab.gnome.org/GNOME/librsvg/-/issues/599
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/660>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. This was one of the tests that we started ignoring recently, when
Pango reverted its fix for for fonts that are not scaled the same in
the x/y dimensions.
2. That test was for the old
https://bugzilla.gnome.org/show_bug.cgi?id=777834, where the Rust code
for patterns would panic when the C code for text generated an empty
bounding box.
Since the code for patterns in (2) is fixed since a long time ago, we
no longer need this test.
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/660>
|
|
|
|
| |
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/660>
|
|
|
|
| |
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/660>
|
|
|
|
|
|
|
|
|
| |
That function now puts the rectangles in a BoundingBox, with their
coordinate system.
The test filters-composite-02-b.svg seems to have lost a pixel column...
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/660>
|
|
|
|
| |
Did Pango change its strike/underline metrics...?
|
|
|
|
|
|
|
|
|
|
|
|
| |
The three files in question are the only ones in the test suite that
have text elements scaled non-uniformly in the X/Y directions. Pango
had to revert its fix for
https://gitlab.gnome.org/GNOME/pango/-/issues/620 (now marked as
duplicate of https://gitlab.gnome.org/GNOME/pango/-/issues/520), which
came from https://gitlab.gnome.org/GNOME/librsvg/-/issues/599
Summary: this is a Pango bug; unfortunately librsvg can't do anything
about it right now.
|
|
|
|
|
|
| |
The fix for https://gitlab.gnome.org/GNOME/pango/-/issues/620 (https://gitlab.gnome.org/GNOME/librsvg/-/issues/599)
causes our tests that have scaled fonts to change. Fortunately this really fixes the text elements
that are not scaled uniformly.
|
|
|
|
| |
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/647>
|
|
|
|
|
|
|
|
|
|
| |
The code structure made it so that an element with a `mask` attribute,
together with `opacity` and/or `mix-blend-mode`, would only apply the
mask. Now they can all be used together.
Fixes https://gitlab.gnome.org/GNOME/librsvg/-/issues/818
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/631>
|
|
|
|
|
|
|
| |
This got triggered from DrawingCtx::with_discrete_layer(), where it
tries to resolve the paint servers to pass on to the filters code.
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/631>
|
|
|
|
|
|
|
|
| |
This is an easy one; Isolation::Isolate basically means to
unconditionally create a temporary surface for compositing, which we
already know how to do.
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/630>
|
|
|
|
|
|
|
| |
The PNG reference wasn't the same as the result when using Harfbuzz
3.0.0 (the test suite still assumes Harfbuzz 2.9.x).
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/626>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit causes each span's text to be wrapped with the directional
control characters specified in
https://www.w3.org/TR/css-writing-modes-3/#unicode-bidi
For a more complete implementation of unicode-bidi, we'll have to
change the code to actually bidi/shape the whole character content of
a <text> element and its children, not just each individual span.
That will come soon.
Part-of: <https://gitlab.gnome.org/GNOME/librsvg/-/merge_requests/621>
|