SVG rendering problem

[lafar6502]

Hi, attached test case shows some problems with svg graphics support
examples.zip

this is how the svg image looks rendered in the browser

and this is how it looks after converting to PDF with weasyprint:

I suppose there's some problem with svg transform() implementation.

test1.zip
using WeasyPrint version 62.3 on Windows (standalone executable)

[liZe]

Hi!

Thanks for the report. The bug happens because transforms are not applied to symbol elements. Here’s a small example:

<svg height="100" width="100" xmlns="http://www.w3.org/2000/svg">
  <symbol id="rect">
    <rect x="0" y="0" width="25" height="25" />
  </symbol>
  <use x="0" y="0" transform="skewX(30)" href="#rect" />
</svg>

[liZe]

I’ve actually fixed 3 (!!) different bugs thanks to your sample:

• symbol tags are not displayed anymore when seen in the tree,
• bounding boxes is used as a fallback when symbol tag don’t give their size,
• CSS is correctly applied to use tags references.

We can now correctly render symbols with visible overflow and no explicit size referenced by use tags. That’s somewhere between beauty and torture.

(Out of curiosity, which tool do you use to generate these SVG files?)

The rendering is now close to what browsers draw:

Looks like some black stroke is missing. Any idea about what could do this?

[lafar6502]

That's crazy. Thanks!
Will be testing soon.
the SVG is generated from a product configurator, as you have noticed there's a trick to make 3d view from 3 flat pictures by torturing them a little. No vector drawing tool is used, just raw XML.
Don't know what's the problem with black stroke but maybe i'll discover something during testing.

[lafar6502]

pardon my ignorance, but what's the easiest way of testing the last changes to the code if i've only been using windows executable / commandline so far?

[liZe]

the SVG is generated from a product configurator, as you have noticed there's a trick to make 3d view from 3 flat pictures by torturing them a little. No vector drawing tool is used, just raw XML.

Yes, that’s what I thought. That’s a tool you’re developing?

pardon my ignorance, but what's the easiest way of testing the last changes to the code if i've only been using windows executable / commandline so far?

Executable files are automatically generated for each commit, you can find them here: https://github.com/Kozea/WeasyPrint/actions/workflows/exe.yml

[lafar6502]

Yep, it's a tool - product configurator for ordering various sun shading stuff. There's a part of it that generates an SVG drawing representing a simplified view of the product, with dimensions, colors etc according to choices made by the user. Most of it is flat (like roller blinds) but the pergola was a little challenging because it's not flat - that's how the fake 3d view was born.
The reason i started experimenting with weasyprint is that i need to find some better alternative to wkhtmltopdf, which is currently used for generating PDFs with order specification. Wkhtmltopdf is a nice workhorse but sometimes it's hard to convince it to generate something that looks good on print...

[lafar6502]

And first test done with the most recent Windows build https://github.com/Kozea/WeasyPrint/actions/runs/10498523124

Much better, but there's a bit missing in my result - the dimension numbers are not visible. But on your screenshot they're there.
Maybe some commit didn't make it into the build?

test_svg_20240822.zip

[lafar6502]

I think there's a problem with rendering 'monospace' font family specified in my style

.dimtxt {text-anchor: middle; font-family: monospace;font-size:150pt;fill:blue;font-weight:normal}

if font-weight is bold then the text renders. If font-weight:normal, or not specified at all - doesn't render
Should be easy to work around this so don't worry too much.

test2.zip

[liZe]

if font-weight is bold then the text renders. If font-weight:normal, or not specified at all - doesn't render
Should be easy to work around this so don't worry too much.

That’s strange, I didn’t have the problem. It’s probably caused by the fonts installed on your system, using a specific font family instead of Monospace will probably work too.

The other difference I was talking about is the missing black lines around the slats at the top of the pergola (if it’s a pergola 😄). It can be fixed with stroke:black set to .slat, but I have to find why it’s not required for browsers, it’s probably a bug.

[liZe]

I think that everything’s fixed now.

The result is great, the only problem I have is with the text: there’s a small black stroke line on text, that’s too visible in some PDF readers at some zoom levels (and even in browsers, actually). That’s caused by the stroke: black set on svg: the default value of stroke-width is 1, so if you set stroke: black on svg you’ll get a very thin line drawn around everything (including letters), and it can give strange renderings. Maybe you want to set stroke-width: 0 on svg too!

[lafar6502]

Beautiful. let's close it, i'll be doing more tests in next days so if there's anything else, i'll make a new task.
Thanks for all your help so far and great work on this framework.