SVG files used as external graphics need a width and a height attribute (in pixel units) in the svg tag to be drawn properly.
If these attributes are not present in the opening SVG tag, geoserver seems to have difficulties using the fallback method provided by Batik's getBounds() method.
Attached is an example SVG file that does not render properly without these attributes
Transforms are really not necessary in the SVG, they are mostly used when exporting part of a drawing in Adobe Illustrator for instance when the viewbox's origin is not the same as the whole drawing's origin.
As for units, I believe this is the real problem with handling SVGs in GeoServer : not unit is necessarily declared in an SVG file, but then GeoServer has to somehow pick one.
Anyway, I'm not sure the problem comes from either of these attributes missing.
Those decisions are happening one level below GeoServer and GeoTools code, in Batik, I saw no obvious way to get a SVG shape in its native coordinates, ignoring the viewBox.
This article may help understanding (have no time to read it, actual customers need to be taken care of now, but you might want to look into it):
If there is an issue you might want to report it down onto the Batik library too, or at least discuss the correctness of the current behavior and ask if there are ways to extract geometries that are not transformed by the viewBox: https://xmlgraphics.apache.org/batik/
I don't really have an issue since adding width and height attributes in the SVG header works fine, but maybe this requirement should be added to the GeoServer documentation ?
That might be a good idea indeed. Anyone can contribute to the documentation, there are instructions here:
and for small changes there is a simplified procedure:
OK I'll do this, but since I'm not a native English speaker this might require re-writing.