Open yanorei32 opened 7 months ago
Yes, we're loading fonts only when the main SVG has text nodes. We do not check referenced SVGs. Will fix.
For now, simply add a single empty text
element to the main SVG and it will fix the issue.
Amazing! Thank you for very fast reply! I confirmed that solution is works and that completely avoid this problem. I hope this problem will be fixed in future.
Yes, we're loading fonts only when the main SVG has text nodes. We do not check referenced SVGs.
Didn't I fix this in #675? Apparently I didn't...
Oh... It's because resvg
has it's own logic for checking if there are text nodes... So it works in tests but not in the CLI:
That's gonna be tricky to change though if we want to do it inside the resvg CLI...
Maybe it's best to just always initialize the fontdb?
Maybe it's best to just always initialize the fontdb?
That's pretty slow. Even on a macbook with a hot cache it's like 10-20ms. It could easily take 100-500ms on an average hardware.
The issue here is that before, text flattening was done after parsing, not during. So before we were checking for usvg::Text
nodes, not text
XML elements.
This is partially related to #710 , as we have to add a callback to text flattening. I haven't thought about it much yet.
The only "solution" so far is to have some public, intermediate tree representation. One between usvg::parser::svgtree
and usvg::Tree
.
This way we wouldn't have to do everything in one go, which has it's own limitations (paint servers resolving) and complicates code quite a bit (text flattening). But it would have a small performance hit.
Basically, instead of modifying usvg::Tree
and passing it to resvg
, we would allow modifying of this new tree, which then be converted into usvg::Tree
.
And we already do roxmltree -> svgtree -> usvg::Tree ...
That will be a lot of trees then. :p But I've also had thoughts about whether there should be some additional intermediate representation...
While intermediate representations do reduce performance a bit, they do simplify the code and logic quite a lot. The hard part is to find the right boundaries for each representation.
My goal is to keep usvg::Tree
read-only with all of the SVG complexity removed and all metadata calculated (bboxes, etc).
For the caller, SVG should look like a simple list of layers. And as you already know, it's ridiculously hard to do.
I wrote are two SVGs and I nested those and I got a blank image unexpectedly.
Is this a bug...? (Sorry. I can't classify that problem as bug, unimplemented feature, undefined behaviour or something else, because I'm not an expert of SVG specification.)
Version: 0.41.0 OS: Windows 11 23H2 22631.3447 (x86_64) and Arch Linux.
I got a same results in
--use-fonts-dir
option.Text containing SVG (
child.svg
)Works expectedly if this file only. This file just needs to contain a text element. But I wrote some elements and attributes for visiblity.
Rendered Image (
child.svg
):Parent SVG (
parent.svg
)Rendered Image (
parent.svg
):Actually behaviour (
parent.svg
)and I got warning:
Expected behaviour (
parent.svg
)Completly same as
child.svg
in this case.