Build: Version 0.9.8 (bCD-92-0-b3d4fefa 2021-08-03) 64 [Qt 5.15.2]
Operating System: Windows 10
Description
It seems that Fritzing ignores a few attributes related to vertical text alignment when rendering SVGs, in particular:
Workaround
Lack of dy can be somewhat worked around by using transform(translate(0,dy)) instead, although transformations don't accept units (like em) in SVG 1.1 so you'll have to calculate the values. Lack of dominant-baseline does not have a direct workaround transform can still be used if you manually calculate the values you're looking for. In both workarounds, the values you use would also be specific to the font family/size, and so would not be responsive to font changes.
Consequences
One consequence of these values being ignored is that it becomes difficult to vertically center text on a point in a convenient way. This, combined with lack of vertical alignment specification in the design guide (see also #3908) leads to frequent inconsistencies in text alignment. Also, I've noticed that a lot of older parts don't quite use the design guide's font sizes for various labels, so an indirect consequence here is that if we were ever to go through the parts lib and adjust font sizes for consistency, it will take a lot of effort to update parts with hard-coded vertical centering offsets, since those values would all have to be recalculated by hand.
And of course the obvious consequence is that it's a pain to vertically center text, which is a bummer because vertically centered text looks way better on pin and part labels.
Example
Consider the following test SVG (gist):
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg x="0" y="0" width="2in" height="1.0in" viewBox="0 -36 144 72" version="1.1" xmlns="http://www.w3.org/2000/svg">
<rect x=".25" y="-35.75" width="143.5" height="71.5" fill="none" stroke-width="0.5" stroke="#aaaaaa"/>
<g font-family="'Droid Sans'" font-size="7.2">
<g transform="translate(0,-18)">
<line x1="0" y1="0" x2="144" y2="0" stroke-width="0.1" stroke="#ff0000"/>
<text x="18" y="0" text-anchor="middle">ÄgrTtQq</text>
<text x="54" y="0" dominant-baseline="central" text-anchor="middle">ÄgrTtQq</text>
<text x="90" y="0" dominant-baseline="middle" text-anchor="middle">ÄgrTtQq</text>
<text x="126" y="0" dominant-baseline="hanging" text-anchor="middle">ÄgrTtQq</text>
</g>
<!-- droid sans: x-height ratio .536 (/2=.268), X-height ratio .714 (/2=.357) -->
<g transform="translate(0,0)">
<line x1="0" y1="0" x2="144" y2="0" stroke-width="0.1" stroke="#ff0000"/>
<text x="54" y="0" dy="2.5704" text-anchor="middle">ÄgrTtQq</text>
<text x="90" y="0" dy="0.357em" text-anchor="middle">ÄgrTtQq</text>
<text x="126" y="0" transform="translate(0,2.5704)" text-anchor="middle">ÄgrTtQq</text>
</g>
<g transform="translate(0,18)">
<line x1="0" y1="0" x2="144" y2="0" stroke-width="0.1" stroke="#ff0000"/>
<text x="18" y="0" dy="0.5ex" text-anchor="middle">ÄgrTtQq</text>
<text x="54" y="0" dy="1.9296" text-anchor="middle">ÄgrTtQq</text>
<text x="90" y="0" dy="0.268em" text-anchor="middle">ÄgrTtQq</text>
<text x="126" y="0" transform="translate(0,1.9296)" text-anchor="middle">ÄgrTtQq</text>
</g>
</g>
</svg>
Here is a side-by-side comparison:
| Correct |
Fritzing |
 |
 |
This shows dy and dominant-baseline being ignored, and also confirms the use of hard-coded values in transform as a workaround.
Build: Version 0.9.8 (bCD-92-0-b3d4fefa 2021-08-03) 64 [Qt 5.15.2]
Operating System: Windows 10
Description
It seems that Fritzing ignores a few attributes related to vertical text alignment when rendering SVGs, in particular:
dominant-baselinedy(also on<tspan/>)Workaround
Lack of
dycan be somewhat worked around by usingtransform(translate(0,dy))instead, although transformations don't accept units (likeem) in SVG 1.1 so you'll have to calculate the values. Lack ofdominant-baselinedoes not have a direct workaroundtransformcan still be used if you manually calculate the values you're looking for. In both workarounds, the values you use would also be specific to the font family/size, and so would not be responsive to font changes.Consequences
One consequence of these values being ignored is that it becomes difficult to vertically center text on a point in a convenient way. This, combined with lack of vertical alignment specification in the design guide (see also #3908) leads to frequent inconsistencies in text alignment. Also, I've noticed that a lot of older parts don't quite use the design guide's font sizes for various labels, so an indirect consequence here is that if we were ever to go through the parts lib and adjust font sizes for consistency, it will take a lot of effort to update parts with hard-coded vertical centering offsets, since those values would all have to be recalculated by hand.
And of course the obvious consequence is that it's a pain to vertically center text, which is a bummer because vertically centered text looks way better on pin and part labels.
Example
Consider the following test SVG (gist):
Here is a side-by-side comparison:
This shows
dyanddominant-baselinebeing ignored, and also confirms the use of hard-coded values intransformas a workaround.