made the changes suggested and all fixed. I'm guessing that the way svg is rendered in different programs is slightly different - e.g. looked good in chrome but the png converter was slightly different. Thank you for the solution.

I can add the steps that cause the issue.

1. create an svg image
2. add a <text...> element to it.
3. upload.
4. In the background Wikicommons creates a png version of the svg which is used to display as a thumbnail/preview/non-svg on pages. The <text> element will be shifted ~5 pixels??? on the autocreated png images. If you click on the png thumbnail, the svg opens and the image appears as programmed in the svg code. I'm not sure if the issue is with the <text> element itself or the <...transform> attribute within the <text element>. see https://commons.wikimedia.org/wiki/File:Hoogsteen_Watson_Crick_pairing.svg as an example.
5. If you change the text to a <path> element this does not occur
6. It's as if, whatever is converting the svg to a png for thumbnail purposes, uses a slightly different size viewbox.
7. this is a major issue because we use the svg <text> elements to facilitate multilingual diagrams. E.g. on the file listed above someone could just add local language/characters in lines 9-30. If they're converted to paths translation cannot (easily) be done.
8. In articles, it is the png preview that is displayed in the image template, so unless someone clicks on the preview png, they won't know that a properly aligned image exists
9. If you look at https://en.wikipedia.org/wiki/Hoogsteen_base_pair it shows the offset png, if you click on it >> still shows a png, and will only show the svg if you click on the details then click on the image directly in commons.

We would all love more detailed video-play metrics. In the interim, this dataset already exists and is relied upon to give "good enough" impressions metrics for our partners who submit video content to Wikimedia.