Hello,
I don’t know if anyone faced this problem before,
because I facing this MOST of the times, creating new PCB for SMD…
First I thought, It’s due to my setting or editing, But it also Happening with core parts…
Problem:
Editing for new parts, SMD pads are getting bigger. (maybe fritzing adding stroke for copper shape)
Only happening with, Copper pads, with fill shapes, without outline/stroke.
When I extracted svg from core parts svg, having problem most of the time without editing…
When I copy from PCB folder maybe all are working fine, But a simple edit (or save as new) on AI, Problem continues…
Some how I manage to edit on Inkscape. But, It’s a very ***** app. Not very user friendly as AI…
Why I don’t want to use Inkscape:
No global shortcut available, doesn’t even import all AI shortcuts.
Changing object name doesn’t save…!!!
Moving/Rotate or “Resize page to selection”, making the whole PCB smaller…!!! WTH…!!!
No disagreement there, Inkscape’s only advantage is it is open source and thus no cost. That’s why I use it because it is the most common svg editor here. AI should work fine if you have it, as well there is gravit from Coral (not open source but has a free version) discussed here:
I haven’t tried it yet as I have been busy but @opera_night likes it. As to your svgs, the Inkscape one looks fine, dimensions are in ‘in’ (not px like the AI one). If the drawing dimensions are in px, Fritzing will guess which of 72dpi, 90dpi or the current 96dpi (which Fritzing isn’t aware of yet) were the original and sometimes gets it wrong. Looks like AI may do the same. The scale (in Inkscape) is 1.0 for the Ink svg and 0.75 for the AI one (which is dimensioned in px which may well cause problems in Fritzing with scale, don’t know how to change it in AI, perhaps you do.) Again in Inkscape, the AI svg has pads of size w 0.030 by h 0.044 in and the Inkscape version has pads of w 0.165 and h 0.252 in ‘in’ which will certainly render differently in Fritzing (the AI one may also get rescaled due to the px dimensions). Other than group silkscreen is above group copper1 (when it should be the other way) I’d expect the Inkscape version to render correctly in Fritzing. As noted the AI version will probably not do so. If you post the fzz file of that use the supplied svg files and appear wrong in Fritzing I’ll have a look and see if I can see what is going on (upload is 7th icon the left on the reply menu.) For svgs when the forum won’t render them (often!), just change the file extension to .fzp and tell us it is actually a svg so we change the extension back.
This could be caused by translates, again if you supply a original svg and the fzz file that renders wrong I’ll have a look and see if I can tell you why it is rendering incorrectly. If you have groups Inkscape likes to use translates to change their size which is undesirable from a performance standpoint (a translate implies a matrix multiply at every render, so it is more desirable to remove the translates at the svg edit stage.) Fritzing has lots of bugs. With development restarting I’m hoping to remove some of them (some of them to do with parts editing have been fixed in the 0.9.4 pre release version which I’m currently running.)
Been using Gravit 3.5.12 since it’s release. I have NOT updated the version as they keep tweaking and I choose to live with the version that works for me…
Two Noteworthy Issues:
For correct dimensions, Scale (multiply) your input values by 1.25 to get correct Exported dim’s for Fritzing.
Example: If wanting a Fritzing Part/PCB Width of 100mm, input 125mm to get correct output results. (I think they fixed/added 90 DPI Scaling in later versions).
•For making a PCB ‘Board’, the exported file is O.K. after scaling it.
•For making Part files only, the exported file also needs a Simple Edit:
Delete the following text from the XML file,
vector-effect=“non-scaling-stroke”
It’s a useful, friendly App (versus Inkscape).
Lastly, for convenience of editing the XML, I use BBEdit (it has a nice Reflow feature and Replace-All). I leave the file open so it updates with one Reflow click and one Replace-All click.
I’ve posted several posts with Gravit files… search
I thought different DPI maybe the problem, I change the AI 72ppi to 96ppi… But no hope… The issue is same…
There is no problem with supplied svg files… When I open that svg with AI and save, then the problem is happening… Anyway, It’s happening with every “SMD Pad Parts”, No particular parts…
I’ve tried to upload the svg… But upload is not working… Saying “Sorry, but we couldn’t determine the size of the image. Maybe your image is corrupted?”
Anyway… I also noticed some size differences, And I’m adding some screenshots, hope that help you…
That would indicate the problem is in Illustrator settings somewhere, since I’ve not used Illustrator I can’t help. Perhaps someone who does use Illustrator will comment. The best bet is to get Illustrator to make the output defined in either mm or in rather than px because a mm or an inch is always an inch no matter the dpi and Illustrator looks to be outputing in px which can cause scaling problems.
Yep, that is not uncommon (a fault with the forum software I expect). The solution usually used is to rename file.svg to file.fzp then upload the fzp file (which the forum doesn’t try and render) and then tell us that it is really a svg so we rename it when we download it.
I can say without doubt that, though many of the graphic programs in-themselves work well for graphic work, Fritzing is very picky about file contents and is seldom happy with much more than the basic needs for an SVG Tiny1. That is the problem with your files.
•• I opened your 5050 file in Gravit and also in BBedit (to observe and edit the xml) and noticed:
• AI added so much unneeded stuff that it made my head spin.
I deleted stuff while watching the Preview in BBedit. Deleted all the stuff that did not affect the Graphic. Which, is darn-near everything! Thus paring it down to Image #1 below.
•• Deleted the remaining stuff that did not affect the preview graphic and added a default header. Images #2 and #3, below.
•• Deleted the “Vector Sizing…” stuff that Gravit added (see my previous post about that).
Aside from the above comments, your file does NOT have:
proper Layering.
Missing the Layers may not be too important but, correct Naming IS Important for Fritzing.
Note: the order of the images below got re-arranged but, the info still applies
Image#4 shows correct layering (I did not add Copper0. You can add it if needed). I did add “Layer 1”
Attached is your file with the above mentioned edits (delete the .fzp extension)
I did not bother to load it in Fritzing. TWEAK_5050 AI_pcb.svg.fzp (30.1 KB)
[FOLLOW-UP Edit] Oops! totally forgot about your main concern - the size of the Pads…
Your Inkscape-Edited file imported into Gravit with Pad dims of 1mm x 1.5mm. If those are not the desired dim’s you created in AI, then, indeed, there is a scaling error but, the reason is not obvious.
It may be related to the “Mask” and “Percentage” use of the desired dim’s.
You probably have little control of that in AI.
I’ve used about a dozen graphic programs with Fritzing and all of them do something Fritzing isn’t happy with. The Least offensive is Inkscape (but, it’s the worst user-friendly program. Gravit is next in line with making Fritzing happy (and is user friendly, needing only to delete the ‘Vector sizing…’).
This might help (I searched for illustrator settings in the forum search bar):
One of the replies in there included this:
Peter, I had my Illustrator Artboard set on Pixels as the unit of measurement. That was causing it to export the SVG incorrectly.
So if you can figure out how to find the Artboard and set it to “in” instead of “px” things may get better. There doesn’t seem to be any list of illustrator settings useful for fritzing around (and they would likely be old and perhaps now out of date anyway.)
In ‘General’, in addition to previously mentioned, there are a few things I found to sometimes (more often than not) cause Fritzing problems:
Assuming a proper file format with Layers, naming and content…etc
Line termination: Use ‘Miter’, avoid Butt and Square.
For things like Pads, Use a line stroke, set it to same color as the Infill color. Stroke width of 0.5mm (don’t use 0.0).
Use number values instead of Percentages.
Stroke Miter-Limit. In general, try = 2. The value does have an effect.
If scaling is the only final issue, go back to 72dpi and scale up/down the part dimensions - this will help to understand the scale ratio being used.
Example:
If setting is 72dpi and desiring a 100mm part input to be 125mm output, then, 90/72 * 100mm = 125mm, is the value to set dim to…
Perhaps because you use only Inkscape.
My experience from using various programs often brings up those aspects as issues regarding ‘why’ graphics don’t turn out as planned. So, even when I use Inkscape, I stick to the plan. But, good to know and perhaps sometime I’ll do a focused comparison.
As far as I know AI should work fine for Fritzing, many parts are made with it (I’d expect but don’t know for sure smd ones too), but I don’t know what settings to use either. As to Inkscape, I’ve never had a problem like this. I normally ungroup everything (to avoid transforms) then regroup using only the Fritzing layerId as a group name (no layers). Can you provide an example of what doesn’t work and I’ll tell you how I would do the same thing so both Inkscape and Fritzing are happy.
Don’t know if you’re using a Mac (OSX), I am and had the same trouble.
The Mac version of Inkscape has not been updated in long time (though, I haven’t checked in months). They posted an FYI about that. But, I can’t say that’s part of the problem.
However, I figured out the trick: The bad news is I can’t find my full notes on it. The good news is that I somewhat remember enough to maybe help…
It has to do with accessing the layer panel.
If using the panel tabs, the layer tab at bottom left or, in any other way, it won’t work.
However, if you access the Layers from the Main MenuBar, then it worked!
Also, sometimes saving as Plan SVG will enable Ink to properly load the layers into the layers panel (but, don’t count on it).
FYI - Gravit. Like most all software org’s, they mess with it and break things. I stopped updating. For Parts, just delete the “Vector-sizing…” from the xml file.
I didn’t get any audio with the video, but it looks to me that probably ignorance is protecting me from Inkscape , I don’t know how to do the manipulation with objects so I tend to use xml editor to change the underlying xml rather than the graphical tools. To rename your groups (I don’t understand layers and thus don’t use them, and Fritzing doesn’t appear to care), I would modify the group names by changing them in xml editor. Xml editor won’t let me have identical names (if I set an identical name, it automatically changes the other element to for instance circle43 if it was connector1pin) so you may be seeing bugs or features in Inkscape that I don’t. As noted before, I tend to ungroup the entire drawing to avoid transforms, make the changes and then regroup once everything is done, so that too may be helping me get the results I want without running in to the problems others are having.
This one is familiar. The likely cause is that Inkscape has changed something in preferences.xml. I think I usually manage it by hitting a keyboard short cut by accident. Since I usually don’t know what key I hit and thus not how to undo it, I keep a known working copy of preferences.xml around that I can copy in when Inkscape decides to work differently all of a sudden. It is my impression that none of the svg editors work really well with Fritzing, because they are trying to do different and often incompatible things. The right answer is probably what I think was the original intent of parts editor: to make Fritzing’s own svg editor, but even then breadboard would probably need a real svg editor I expect, schematic and pcb are limited enough that they could probably be done in Fritzing just fine.
Convincing Inkscape to not use transforms is close to impossible. The best bet is to ungroup the entire document. With groups Inkscape transforms, without them, most of the time it doesn’t. For subparts I usually ungroup the entire document, make the part (manually removing any transforms Inkscape inserts) and then group the subparts one at a time and then group the subparts one at a time. In some cases apparently transforms are unavoidable (elements with stroke widths are supposed to be one) but in general I like to avoid them for performance reasons. The transform implies a matrix multiply at render time (and Fritzing renders a lot!) so avoiding transforms should provide a speed up. I don’t know whether it is a significant speed up or not though.
Good to know! I probably just add the appropriate xml in Inkscape, but not everybody is familiar with what the xml should look like. Of course you have just become our new Illustrator expert .
, I don’t know how to do the manipulation with objects so I tend to use xml editor to change the underlying xml rather than the graphical tools. To rename your groups (I don’t understand layers and thus don’t use them, and Fritzing doesn’t appear to care), I would modify the group names by changing them in xml editor. Xml editor won’t let me have identical names (if I set an identical name, it automatically changes the other element to for instance circle43 if it was connector1pin) so you may be seeing bugs or features in Inkscape that I don’t. As noted before, I tend to ungroup the entire drawing to avoid transforms, make the changes and then regroup once everything is done, so that too may be helping me get the results I want without running in to the problems others are having.
.
