Power supply symbols help

[fai]

Hi @vanepp ,
I am working on extending the simulator for transitory analysis and I realized that the different power supplies have some issues and they are very heterogeneous. I could use your expertise with SVGs and Fritzing conventions if you are up to it.

The battery part in core is ok, but it is rotated 90 degrees, which is not the common way of writing electronics (power at the top and ground at the bottom). This forces to rotate the part (which is annoying for advanced users) or contributes to creating “ugly” schematics by beginners, see power supplies need to be oriented vertically · Issue #372 · fritzing/fritzing-parts · GitHub

The DC power (sch part only) is not aligned with the grid correctly and has a problem with the wires connecting in the middle of the connectors. See also SCH DC Power: wires from the center of the connectors · Issue #342 · fritzing/fritzing-parts · GitHub

There is also an AC power supply (add a dc power supply and change it to AC), but this part does not align well vertically with the grid and connects not at the end of the connector:

I also made a pulse power supply, but it is based on the battery and it is rotated.

It would be great if you could fix the problems, homogenize all the parts (e.g., now the pulse and the ac power supplies have different circle diameters) and use the Fritzing conventions. I have the fpz files, I just need the svgs. And we will not obsolete the parts, they will be new parts to avoid problems with the obsoleting mechanism.
Cheers,
Andres

[vanepp]

@fai

The DC power (sch part only) is not aligned with the grid correctly and has a problem with the wires connecting in the middle of the connectors.

This looks to be a code problem. The usual answer is that terminalId isn’t set in either the svg or fzp file. Here both are set correctly but don’t work. I expect that is because there is special code triggered by the special moduleId “moduleId=“DC2PowerModuleID””
because there doesn’t seem to be any other cause for it. Here is a copy of the dc_powersupply.svg rescaled and updated to meet the graphics standards, but the misalignment still occurs making me think there is an error in the code somewhere that is suppressing the terminalIds.

edit:

I have made 3 individual parts that work as expected so perhaps I just screwed up the installation in core parts.

all three are the same size and correctly aligned and meet the graphics standards (if you have fzp file you probably just want the svg files!) One had the svg dimensioned in px which will typically break things, all these are in inches.

ac_powersupply.fzpz (1.8 KB)

pulse_powersupply.fzpz (1.8 KB)

dc_powersupply.fzpz (1.9 KB)

edit2:

Looks like I indeed did something wrong on the first try. I just replaced the current svg with my new svg for the battery and it now aligns correctly so if you take the svgs from the above fzpz files you should be fine.

Peter

[fai]

Hi Peter,

I am making a waveform generator part svg image. This image will be used to add a breadboard part for the power supplies (the ones you change), which are currently sch only parts.

This is my current svg file that I made in Inkscape. I used the FritzingCheckPart (the latest version in the repository, GitHub - vanepp/FritzingCheckPart), but it appears that is not removing the tspan labels. I think you mentioned the other day in the Oscilloscope thread, that your program removes automatically. Or did you use Inkscape to do this?

This is the file I made. The plan is to create several images for each kind of waveform (square, triangular, etc.) where each part has the corresponding button in green. The simulator will then generate the waveform according to the properties of the part.

All feedback, modifications and enhancements are welcome.

Thanks for your help,
Andres

[vanepp]

In the released version of FritzingCheckPart.py the tspans are only warned about:

$ FritzingCheckPart.py c98c61ec67d4dde3b8421e3cdf591a31166c94a7.svg
Modified 1: File
‘c98c61ec67d4dde3b8421e3cdf591a31166c94a7.svg’
At line 32

Removed px from font-size leaving 88.5826

…

Warning 26: File
‘c98c61ec67d4dde3b8421e3cdf591a31166c94a7.svg’
At line 88

Apparant nested tspan which fritzing doesn’t support
If your text doesn’t appear in Fritzing this is probably why

Warning 26: File
‘c98c61ec67d4dde3b8421e3cdf591a31166c94a7.svg’
At line 92

Apparant nested tspan which fritzing doesn’t support
If your text doesn’t appear in Fritzing this is probably why

I have a development version which will try and fix them but it doesn’t always work, blanks with space=preserve set will break it and I haven’t yet figured out what to do about that. For me it is fine because it will screw up and I know to remove the space=preserve, but that isn’t a general solution for the average user. Here is a corrected version of your svg from my dev version:

FritzingCheckPartw.py c98c61ec67d4dde3b8421e3cdf591a31166c94a7.svg

**** Starting to process file Startup, no file yet

**** Starting to process file Startup, no file yet

**** Starting to process file c98c61ec67d4dde3b8421e3cdf591a31166c94a7.svg

Error 92: File
‘c98c61ec67d4dde3b8421e3cdf591a31166c94a7.svg’
At line 570

Tspan removal error: xml:space=“preserve” found.

to fix it I edit the svg file and remove these

      <text
        xml:space="preserve"
        x="-722.06952"
        y="3458.2727"
        id="text17"

which then runs like this

$ FritzingCheckPartw.py c98c61ec67d4dde3b8421e3cdf591a31166c94a7.svg

**** Starting to process file Startup, no file yet

**** Starting to process file Startup, no file yet

**** Starting to process file c98c61ec67d4dde3b8421e3cdf591a31166c94a7.svg

Modified 7: File
‘c98c61ec67d4dde3b8421e3cdf591a31166c94a7.svg’
At line 569

A Tspan was removed.
Check the output svg is correctly formatted after the change.

Modified 7: File
‘c98c61ec67d4dde3b8421e3cdf591a31166c94a7.svg’
At line 609

A Tspan was removed.
Check the output svg is correctly formatted after the change.

Modified 7: File
‘c98c61ec67d4dde3b8421e3cdf591a31166c94a7.svg’
At line 650

A Tspan was removed.
Check the output svg is correctly formatted after the change.

and here is the modified svg file

with the tspans removed. And a copy of the development code with tspan removal enabled (and a few other enhancements such as checking for the correct scale that aren’t in the released version.) This is really a .py file so just remove the trailing .fzpz as the forum doesn’t accept .py files for upload it appears.

FritzingCheckPartw.py.fzpz (14.2 KB)

FritzingToolsw.py.fzpz (209.5 KB)

That should work along side the released version. It may also not be needed anymore, the changes in Fritzing may have fixed the tspan errors by properly supporting tspans now (which it didn’t use to do.) If your svg loads correctly in to Fritzing and the text is the correct size then the tspan removal isn’t any longer needed.

Peter

[fai]

Hi,
I have a few problems. First, the AM FM NOISE and RAND text are not placed correctly (neither in your SVG or in the original file). See below.
In your SVG file, there are still px units (e.g.: stroke-width=“10.4167px”). They makle the paths of the signal (on the buttons) very thick. This is easy to fix with the a text editor (replace all px ).
The thickness of the lines of all the buttons seems much thick as it should be. No idea why.

Your SVG image

[vanepp]

Something odd going on. The svg I uploaded has no px in the font sizes:

          <g id="g43" transform="translate(1215.6688,1570.9103)">
            <text x="3841.2488" y="1546.7876" fill="#787878" font-family="'Droid Sans'" font-size="88.5826" id="text33" stroke-width="39.37">COM</text>
          </g>

did you perhaps load and save it in Inkscape? That will add the px back in. The above is from the download of the svg I posted (to make sure my upload matches my expectations!) It is also rendering normally in the forum, the image of the svg looks fine (and not at all like your image!) and the svg rendered by Inkscape which also looks fine

so I’m not sure where the problem is as it doesn’t seem to be in the svg posted as far as I can see. Your image is typical of font-size with px after a render in Fritzing though, although the text rotation is odd. I see there are transforms in the svg

  <g id="breadboard">
    <defs id="defs34"/>
    <rect x="10.04215" y="10.04215" width="4333.2061" height="1789.5654" rx="121.71928" id="rect1" stroke="#000000" stroke-width="20.0843"/>
    <g id="g1" transform="matrix(0.52604504,0,0,0.52604504,55.978834,55.978834)">
      <rect x="132.87378" y="132.87378" width="3690.9385" height="2952.7507" id="rect3" stroke="#000000" stroke-width="29.5275"/>
      <line x1="132.87378" y1="501.96765" x2="3823.812" y2="501.96765" stroke="#808080" stroke-width="5.9055" id="line3"/>
...

ungrouping and regrouping should remove them and eliminate one potential area of problems. I just did that and will upload the resulting svg

  <defs
     id="defs1">
    <defs
       id="defs34" />
  </defs>
  <g
     id="breadbooard">
    <rect
       x="10.04215"
       y="10.04215"
       width="4333.2061"
       height="1789.5654"
       rx="121.71928"
       id="rect1"
       stroke="#000000"
       stroke-width="20.0843" />

no more transforms other than rotate 90 for text and at least one path. See if this one works any better (after I run it through FritzingCheckPart because the edit added back in the pxs

    <text
       x="2263.7537"
       y="316.9043"
       id="text23"
       font-size="76.1801px"
       line-height="1.25"
       font-family="'Droid Sans'"
       letter-spacing="0px"
       word-spacing="0px"

and I correct the spelling of breadbooard so it has a layerId of course. See if this svg works better

edit:

after the run through check part it no longer has a px in the font-size

    <text
      x="-1047.83"
      y="3936.0134"
      id="text17-1-8-5"
      transform="rotate(-90)"
      font-size="96.9097"
      line-height="1.25"
      font-family="'Droid Sans'"
      letter-spacing="0px"
      word-spacing="0px"

they are still there in the letter-spacing and word-spacing but AFAIK Fritzing only cares about the font-size pxs.

Peter

[fai]

Great. I will try it tomorrow in Fritzing (just uploading as logo image) to see if the problems with the text and the strokes are fixed.

[vanepp]

Nope, loading as a logo screws it up:

either image won’t take svgs (although it seems happy with it) or there is something else wrong. Looks like something about the svg is indeed wrong. I put it in to a simple test part (and set 3 connectors on random buttons to keep the fzp happy) and it fails too. I will poke further to see what is happening.

looks the same as the upload to logo but it shouldn’t I don’t think!

edit:

I’m still working on this. I am no closer to understanding what is going on though. The svg looks correct to me and renders correctly in Inkscape but does not in Fritzing and I so far can’t figure out why.

Inkscape

looks fine (after a run through FritzingCheckPartw.py) but doesn’t render correctly in Fritzing:

The stroke width on the button boxes has increased (reason unknown) crowding the text. The paths in the right buttons have a much larger stroke-width and the text has ignored the rotate (-90) in the svg and printed upright and again I don’t know why. I’ll continue poking at this until I figure out what is wrong but so far it is all a mystery.

edit2:

OK, finally progress. The problem is twofold (at least) and based in your svg having odd defaults from Inkscape. First issue is the stroke-widths have a px appended. That is what is causing the text mis sizing. Friting has a different opinion from Inkscape on what size a px is. The fix there is to manually (with a text editor and a global replace) remove all the px from the entire svg or find and disable the px in stroke-width in Inkscape preferences (I must have that set because this doesn’t happen to me!) That fixes the font size issue. That still leaves the boxes being too thick. That turns out to be this parameter (which I don’t know what it does, but it affects stroke width via some internal filter)

paint-order=“stroke fill markers”

removing this causes the same effect we see in Fritzing (indicating Fritzing doesn’t support whatever this is supposed to do) removing it increases the stroke width I expect setting the stroke-width to 10 (from 25 something) once it is removed will fix the problem. Checking your Inkscape preferences (although I have no idea which one! I can supply you with the one I use which hasn’t caused this problem if you like.) to disable this will fix it. I still don’t know what is going on with the rotates not being rendered though. I’ll continue poking at that.

remove the paint-order and it looks like in Fritzing:

change the stroke-width from 25.8891 to 15 and it looks correct (or at least more correct.) It looks like this may have to do with corner rounding as the corners on my modified version are less circular. That may need to be corrected with a path (as Fritzing correctly supports paths, but doesn’t appear to support paint-order. As usual my lack of general Inkscape knowledge is showing here . Now to figure out what is going on with the rotates!

Here is a copy of my preferences.xml from AppData\Roaming\inkscape on Windows10

preferences.xml.fzpz (25.5 KB)

with the extension changed to .fzpz so the forum will upload it. It is really preferences.xml so just remove the .fzpz from the end (it is not zipped!) This is Inkscape 1.3 (the latest version) if it matters which it may.

Peter

[vanepp]

OK, I think finally fixed. I replaced all the rectangles (which don’t seem to be supported in SVG tiny) with paths and redid (mostly simlifying) the text and set the stroke-width to simple numbers (no trailing px) and it now seems to render in Frizting:

Here is the new svg

and the part that it creates

test1.fzpz (6.6 KB)

Now back to why a perfectly standard schematic created by Randy’s extension doesn’t render correctly in Frizing!

Peter

[fai]

Thanks!
The rectangles are definitely supported. In fact, there are still three rect in your svg. Maybe it was some of the properties of the rectangles, but I have not looked into this.
In any case, I will use your file as it is working well.

[vanepp]

@fai

The rectangles are definitely supported.

Rectangles are supported, it appears the curved corner rectangles (here replaced by paths), apparently created with the paint-order attribute, are not. Between them and the px in stroke-widths that appears to explain the problems. It appears Fritzing has a different idea of what a px should be than Inkscape does. Given a px Fritzing will try and figure out what it should be (between 72DPI and 90DPI for earlier Inkscapes I think.) Current Inkscape is using 96DPI I think and thus won’t match either of the 2 values Fritizng guesses causing scaling issues.

Peter