Units on font-style in svg part files do not export as svg

1

I’ve seen pieces of this around the forum, but thought a reproducible summary might be helpful. Text with (an svg) font size specified in px units does show up at the right size (or at all) using export ¦ as Image ¦ SVG. It appears that the export software does not understand the units, and ends up exporting with a font-size of “0”. Simply removing the units from the font-size in the style attribute works around the problem, but a more general solution would be to fix the export logic. Fritzing itself handles the text correctly in the views.

Fedora 24
x86_64
Version 0.9.2 (b8d2d5970658f0bed09c661c9

Have not upgraded to 0.9.3, since trying to stay with what is provided in the Fedora repos.

grep -c -E "font-size:[0-9]+?(\.[0-9]*)?px" /usr/share/fritzing/parts/svg/core/*/*.svg | grep ":[1-9]" | wc
107 files found, although the icon files probably do not matter.  They are never exported.
grep -c -E "font-size:[0-9]+?(\.[0-9]*)?[a-z]" /usr/share/fritzing/parts/svg/core/*/*.svg | grep ":[1-9]" | wc
108 files found, although the icon files probably don´t matter.  They are never exported.

Simple (hopefully) reproducible example. In an empty sketch:

  • find and place a TLP621

  • Fit the breadboard view to the window

  • File ¦ Export ¦ as Image ¦ SVG ¦ test_bb.svg
    Outside of Fritzing, view the original and exported image files

  • …/fritzing/parts/svg/core/breadboard/Optocoupler_TLP621_breadboard.svg

  • test_bb.svg
    The “TLP” and “621” text is visible in the original, but not in the export.
    Use a text editor to look at the 2 files.

  • In Optocoupler_TLP621_breadboard.svg, the text elements for TLP and 621 are wrapped in groups with style attributes. Both start with “font-size:4.44444418px”.

  • In test_bb.svg, the matching text elements are also wrapped inside group elements, but now the style does not have a font-size entry, and there is new font-size attribute set to “0”. Changing that “0” to either “4.44444418px” or “4.44444418” gets the text to show up, although the size is wrong.

  • Exit everything without saving.

  • Change font-size:4.44444418px to font-size:4.44444418 in Optocoupler_TLP621_breadboard.svg.

  • Repeat the find, place, fit, export, view.

  • The text is visible in both the original and export.

  • Viewing the export file in a text editor shows that the font-size has still been removed from the style attribute, but now the font-size attribute is set to “3.2”.

As a guess, the parsing code for the svg export is attempting to convert the whole “4.44444418px” string to a number, which fails and gives 0. It is not expecting or looking for units.

2

That is correct, you need to remove the px from the svgs (Inkscape apparantly adds them due to css). It isn’t only svg export that breaks if you edit a part with px in the font-size usually by the second time it reduces the font size to 0. This behavior is documented in the parts-file-format (along with the recommendation to remove them) here:

Peter

3

I read that reference before, and even saw the unitless reference. It did not click that was going to cause a problem. Looks like the real problem (other than the export not handling the units), is that a lot of existing part svg files have units specified, and so are broken. At least when using export to svg.

grep "font-size:[0-9]*\.[0-9]*px;" /usr/share/fritzing/parts/svg/core/*/*.svg

Pipe that to wc show 295 instances, though not that many unique files.

4

From memory, which isn’t very good, you don’t have to remove all the px’s, just 2 in each text group. It’s some where in my video series.

5

I’m (slowly :slight_smile: ) working on a python script that will fix this (along with a couple of other things that Inkscape does that Fritzing doesn’t like) and will check that the correct layers and connectors in the fpz file actually exist in the svg file (and that the specified svg files exist). Once thats done its easy to convert all the files in core automatically (I’ve already done a test scan and found a number of xml errors that our parts maintainer was good enough to fix up) so help is on the way. Getting them all corrected may be a bit more work though :slight_smile:

Peter