adding either alignment-baseline=“middle” or dominant-baseline: middle; to the text (the two methods I have found to align text vertically) do not work in this case the offset still appears. Does any one know of another attribute that will leave the center line of the text aligned with the center of the pin when the case changes as above? The use case here is the automatic creation of a schematic via an Inkscape extension. So manually editing the offset after a case change is undesirable. I’m hoping someone knows more about text alignment than I do (probably not hard .)
edit: I have decided to poke further at this, so I started with the font files. As far as I can see we are using the wrong font name for DroidSans, the typical one used is ‘Droid Sans’ which from the font file appears incorrect and should be DroidSans (no space!):
owner@owner-PC /cygdrive/d/fritzing-backup/fontsandtemplates/Fonts/DroidSans
$ for file in “$arg”*.{ttf,otf}; do fc-scan --format “%{postscriptname}\n” $file; done
DroidSans-Bold
DroidSans
DroidSansMono
this is supposed to give you the correct name to call your font from the .tff file (here applied to the Fritzing font dirctory.) OCRA appears to be correct (most parts I have seen use OCRA)
owner@owner-PC /cygdrive/d/fritzing-backup/fontsandtemplates/Fonts/OCR A
$ for file in “$arg”*.{ttf,otf}; do fc-scan --format “%{postscriptname}\n” $file; done
OCRA
OCRA
I’ll try a test part using the font variations and see what the result (presumably after font substitution) looks like in Fritzing.
The alignment of the text actually did not change for the examples you show. In both cases, the common “alignment” position is the bottom of the “regular” character glyphs, which is everything except the lower case “p”. What you are circling is the graphical middle of the rendered bounding box that is added by inkscape as a convenience for graphical scaling. It is not the alignment position of the svg text element, and the box does not match the extent of the actual character rendering areas.
As you found, the main svg attributes for controlling vertical positioning are alignment-baseline and dominant-baseline. Alignment though is based on the font as a whole, not the characters being rendered. So the alignment position does not change when characters with descenders and accent marks are added to a text string. Starting from a string with a little of everything, it would not be appropriate (in the general case) for the text to shift vertically if a character with the (current) maximum upper or lower rendering limit was removed.
There are additional values possible for those svg attributes. See alignment-baseline and dominant-baseline in MDN Web Docs for details, and hints about interaction with other attributes. The intellisense in the svg plugin I am using for visual studio code offers even more. The most interesting from that is “text-after-edge” and “text-before-edge”. I think those are replacements for “text-top” and “text-bottom” that do not seem to do anything. Here is a sample svg file showing the positioning with various dominant-baseline attribute values. Note that not all viewers will render this the same. There are small differences between the preview from my vs code plugin, inkscape, firefox and google chrome browsers. The preview plugin comes closest to what I think is intended from the documentation. The EOG (eye-of-gnome) viewer that I have used in the past to look at svg files completely ignores the attribute. All of the text in the sample file is displayed matching “auto” in the others.
Have you tested this inside of a Fritzing part (previously)? I did not do that, but DID load it as an image in each of the views. That also ignored the baseline setting, looking the same as EOG. That could be different for a part file, but I suspect that the qt renderer code ignores the attribute. To get what you want, I suspect you need to use “alphabetic” (the same as auto, or no baseline attribute, assuming no inheritance), with a hard-coded (calculated) offset based on the font-size. That is what I have been doing when manually generating svg part text for Fritzing. Though I ‘cheat’ a little, by putting the offset in a wrapper group using a vertical translate.
'font-family="droid sans"' works correctly on my system. Removing the space gives the same result in EOG, but the editor plugin preview changes to a default font, the same as I get using a totally non-existant font name. How Fritzing looks up the font could work either way. Your test should prove it.
I`m in the process of creating a test part to do the tests through Frtizing to see what happens (and if I can figure out an appropriate attribute if Fritzing will support it.) I see that Inkscape doesn’t list the DroidSans font as DroidSans it lists it as ‘Droid Sans’ so it is possible that the code I used to display what the font is called from the .tff file is incorrect (at least for Inkscape.) It is also lists the DroidSans I specified with a red line through it (I expect indicating it didn’t find a match) although it has a font associated with it. So I expect as usual I don’t know what I am doing here. I’ll continue poking and see what I can come up with because having the text position change depending on what characters are entered is ugly from an automatic text modifying point of view. It may be we just have to live with a little bit of change though.
edit: the sensible course (grep -R Droid in the FritzingApp source) indicates that the correct font name is indeed “Droid Sans” since that is what the source is using. The only place I see where DroidSans is used appears to be in an obsolete directory in parts editor. Although it looks like a constants file has the old values:
Mixed in with this, need to test exports. I expect that an svg export will use the baseline information, even if Fritzing itself does not. Depending on what tool is used to view the export. Gerber export is another separate case. It could be different from Inkscape or Fritzing, and depending on the code, gerber view could be different from what is produced by a production house. Also depending on both how the gerber specification treats text, and how the gerber export code renders it. If gerber (or the export) does not “store” text, it will only be affected by how the export “renders” it.
This COULD be part of the reason for the various reports of text shifting during export. Fritzing calculations might be based on a specific alignment, which does not match the actual used in the svg file, or defaulted by the viewer.
.)