Page with encoded SVG leads to "TypeError: float() argument must be a string or a real number, not 'NoneType'"

[hammerbacher-com]

Hello!

1. We (Hammerbacher) would love to continue sponsoring the project, but we need a kind of receipt or invoice. Maybe we can get in touch about that? This issue (of missing receipt) seems to have been forgotten for a while.

2. When I POST certain HTML with an data-URL SVG to an instance of a weasyprint-service container (see also Extend WeasyPrint with Rest API and provide it as a service #2194, "weasyprint": "63.1") , I obtain error 500 and the log says:

[2025-03-21 09:24:40] "POST /convert/html?pdf_variant=pdf/a-3b HTTP/1.1" 500 241 0.050852
ERROR:root:Cannot find SVG dimensions. Width: None, Height: None
ERROR:root:Unexpected error due converting to PDF: float() argument must be a string or a real number, not 'NoneType'
Traceback (most recent call last):
  File "/opt/weasyprint/app/WeasyprintController.py", line 40, in convert_html
    html = SvgUtils.process_svg(html)
  File "/opt/weasyprint/app/SvgUtils.py", line 19, in process_svg
    return re.sub(pattern, replace_img_base64, html)
           ~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/re/__init__.py", line 208, in sub
    return _compile(pattern, flags).sub(repl, string, count)
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^
  File "/opt/weasyprint/app/SvgUtils.py", line 56, in replace_img_base64
    image_type, content = replace_svg_with_png(svg_content)
                          ~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
  File "/opt/weasyprint/app/SvgUtils.py", line 66, in replace_svg_with_png
    width, height = extract_svg_dimensions_as_px(svg_content)
                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
  File "/opt/weasyprint/app/SvgUtils.py", line 98, in extract_svg_dimensions_as_px
    return convert_to_px(width, width_unit), convert_to_px(height, height_unit)
           ~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^
  File "/opt/weasyprint/app/SvgUtils.py", line 184, in convert_to_px
    value = float(value)
TypeError: float() argument must be a string or a real number, not 'NoneType'

This is the HTML file. It contains barely more than a logo:
weasyprint.svg-data-url-problem.html.txt

Using a locally installed weasyprint 52.5

]# python3 -m weasyprint --info
WeasyPrint version: 52.5
Python version: 3.6.8
Cairo version: 11512
Pango version: 14203
CairoSVG version: 2.6.0

the HTML can be rendered to PDF without any problem:
weasyprint.svg-data-url-problem.html.pdf

Unfortunately, I am not able to upgrade the locally installed weasyprint. So I can only compare the local version 52.5 it with the container version 63.1 here and hope that there is no app code of weasyprint-service container causing the problem.

The weirdest part of this issue is, that the same error appears when rendering with Weasyprint 63.1, if the img tag is commented out.
Shouldn't there be no svg rendering in that case?
weasyprint.svg-data-url-problem-commented-out.html.txt

We would be very grateful if someone could confirm, help here or fix this.

[hammerbacher-com]

I forgot to mention that rendering a different encoded svg is rendered successfully, like this one with just a blue rectangle:

weasyprint.other-encoded-svg.success.html.txt

And also the failing svg is rendered successfully, if it is not base64 encoded in a data-URL but just an embedded svg:

weasyprint.embedded-svg.success.html.txt

[hammerbacher-com]

It turns out that the encoded SVG in the data-URL can be rendered, if I add width and height as attributes to the root <svg> tag of the SVG file, like

<svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
	 viewBox="0 0 563.14 107" width="563.14" height="107"  enable-background="new 0 0 563.14 107" xml:space="preserve">

This solves my rendering problem here, for now.

Still, the weird rendering of commented code might be worth a look, as mentioned above:

Shouldn't there be no svg rendering in that case?
weasyprint.svg-data-url-problem-commented-out.html.txt

[liZe]

Hi!

(Thanks for your support, and sorry for the delay, we’ll send a mail for the sponsoring part.)

It looks like it’s a problem with weasyprint-service container’s code, not WeasyPrint’s. I think it’s already been fixed by SchweizerischeBundesbahnen/weasyprint-service#79.