Thanks Aditya, I tried your suggestion, but the result is the same. Here's the XML setup for all images in the document: \startxmlsetups xml:img \starttexcode \placefloat[here,force]{}{% \hbox{\externalfigure[\xmlatt{#1}{src}][conversion=mp]} } \stoptexcode \stopxmlsetups Here's the Markdown source document:  The source document is automatically exported as XHTML: <p> <img alt="" src="/path/to/images/dna-02.svg"/> </p> The XHTML is then passed to ConTeXt, whereupon the XML setup for images is applied. The result is the same: the alignment for the text is off. Here's an example where you can see the issue on the 16q24.3 text (far right): https://i.ibb.co/WGh03Sr/genes.png When the same SVG file is rendered using Apache Batik, the white text is aligned to the middle of the black box. Are there aAny other work-arounds? Thank you!

Thanks for checking this. Unfortunately, introducing \hbox didn't work; the text is still off-center with respect to the vertical line: https://i.ibb.co/hYGfdgZ/text-align.png For comparison, the SVG file loaded into Inkscape appears similar to: https://i.ibb.co/KF3PBkw/inkscape-alignment.png Note how the text is vertically centered above the vertical line. To me, it looks like the text, after a rotational transform, is being written to the baseline rather than (cap height + descender height) / 2, which seems to be a MetaPost conversion issue? There's another, possibly related issue, which I'll provide in a separate thread. Here's the code: % SOF \pushoverloadmode \unprotect \permanent\tolerant\protected\def\includesvgfile[#1]#*[#2]% {\hbox\bgroup % no \dontleavehmode \getdummyparameters[\c!offset=\zeropoint,#2]% \clf_includesvgfile{#1}\dimexpr\dummyparameter\c!offset\relax \egroup} \permanent\tolerant\protected\def\includesvgbuffer[#1]#*[#2]% {\hbox\bgroup % no \dontleavehmode \getdummyparameters[\c!offset=\zeropoint,#2]% \clf_includesvgbuffer{#1}\dimexpr\dummyparameter\c!offset\relax \egroup} \protect \popoverloadmode \startbuffer[svg] <svg width="25mm" height="70mm" viewBox="0 0 25 70" xmlns="http://www.w3.org/2000/svg" xmlns:svg="http://www.w3.org/2000/svg"> <path d="m 12.500001,63.971412 v -12.4787" id="path2" style="fill:none;fill-opacity:1;stroke:#000000;stroke-opacity:1" /> <text x="-48.831322" y="15.60547" id="text4933-8-6" transform="rotate(-90)" style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:12px;font-family:Roboto;-inkscape-font-specification:'Roboto, Normal';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-east-asian:normal"><tspan id="tspan159594-1" x="-48.831322" y="15.60547" style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:12px;font-family:Roboto;-inkscape-font-specification:'Roboto, Normal';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-east-asian:normal">16p13.3</tspan></text> </svg> \stopbuffer \starttext \placefigure[]{}{\includesvgbuffer[svg][conversion=mp]} \stoptext % EOF

Here's the formal rule: https://www.w3.org/TR/SVG11/coords.html#TransformAttribute rotate(<rotate-angle> [<cx> <cy>]), which specifies a rotation by <rotate-angle> degrees about a given point. If optional parameters <cx> and <cy> are not supplied, the rotation is about the origin of the current user coordinate system. The operation corresponds to the matrix [cos(a) sin(a) -sin(a) cos(a) 0 0]. If optional parameters <cx> and <cy> are supplied, the rotation is about the point (cx, cy). The operation represents the equivalent of the following specification: translate(<cx>, <cy>) rotate(<rotate-angle>) translate(-<cx>, -<cy>). It looks like cx/cy, if not present, mean to rotate the text about its origin, which I would take to be width/2 and height/2. They define the rotation matrix as [cos(a) sin(a) -sin(a) cos(a) 0 0], where a is the angle: https://www.w3.org/TR/SVG11/coords.html#RotationDefined It appears as though LMTX is rotating around the baseline, rather than the central point of the text's bounding box. (I thought that (cap height + descender height) / 2 was the middle, but I suppose that wouldn't account for diacritics.) Thanks for looking into this! On Wed, Jun 29, 2022 at 2:24 PM Hans Hagen via ntg-context < ntg-context@ntg.nl> wrote:

On 6/29/2022 8:48 PM, Thangalin wrote:

...

To me, it looks like the text, after a rotational transform, is being written to the baseline rather than (cap height + descender height) / 2, which seems to be a MetaPost conversion issue? There's another, possibly related issue, which I'll provide in a separate thread. Where is that rediculous (rather font version sensitive) rule defined? In all test i did so far baseline works ok.

Btw, it is sort of baffling what applications spit out when it comes to svg (and exp text). The cod being meant for machines "eyes" only is not really an excuse.

Hans

----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------

___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net

___________________________________________________________________________________