'font' CSS shorthand property ignored in SVG 'text' elements
The font properties set via a 'font' CSS shorthand property seem to be totally ignored when rendering text elements inside SVG images.
Here is a minimal SVG to reproduce the issue:
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 400 400">
<style>
.octl text {
font: 7mm cursive;
fill: purple;
stroke: white;
stroke-width: 0.1mm;
stroke-linecap: butt;
stroke-linejoin: miter;
}
line {
stroke: black;
}
</style>
<g class="octl">
<text class="octl" x="7mm" y="7mm">Text 14mm in cursive.</text>
<line x1="7mm" y1="7mm" x2="7mm" y2="0mm" />
<line x1="7mm" y1="10mm" x2="14mm" y2="10mm" />
</g>
</svg>
It renders well in the PDF from Firefox:
But Weasyprint uses default font family and size:
Replacing the "font" CSS property by specific properties like "font-size" and "font-family" works. This can be used as a workaround.
Hi, and thanks for the report!
This missing feature is caused by the dirty code used for SVG attributes management. We should use the real validated and computed values of SVG attributes and take care of font here:
https://github.com/Kozea/WeasyPrint/blob/a5d8412d0f11e815db31652fdd88fed2fecfeb66/weasyprint/svg/text.py#L27-L43
@liZe if I am not wrong, WeasyPrint handles CSS in SVG differently from other HTML.
The <style> block is completely ignored by the CSS parsing/cascade process. (This is reasonable because parent styles must not be inherited into SVG).
Instead, SVG constructor creates a .style property that contains a list of cssselect2.Matcher based on the <style> block.
Do you think we could use this .style in some way? or, should we create a style_for function similar to the standard one?
Instead,
SVGconstructor creates a.styleproperty that contains a list ofcssselect2.Matcherbased on the<style>block.
This is for historical reasons. The SVG code comes from a different project (CairoSVG) and has not been fully adapted to WeasyPrint… yet!
Do you think we could use this
.stylein some way? or, should we create astyle_forfunction similar to the standard one?
We should definitely use the same CSS code for HTML and SVG, ie rewrite the whole CSS management in SVG.
But that’s unrelated to this issue: even without rewriting the whole CSS-for-SVG code, we can handle font correctly.
Hi! I'd like to work on this issue.
I've looked at the code in weasyprint/svg/text.py (lines 27-43) and understand that we need to replace the direct attribute parsing with proper font shorthand handling using the existing CSS expanders.
I'll start by implementing a solution that:
- Uses the existing
expand_fontparser for thefontshorthand attribute - Maintains the current behavior for individual font properties
- Follows proper cascade: shorthand → individual properties
I may need some guidance on testing approach and any edge cases I should consider.
Thanks!