Thanks I’ll take a look and see whats what.
Peter
OK, the result looks pretty close, still some problems but if we (or more correctly you since I am likely no help with Illustrator 
)we may beat this. In Inkscape your svg has large sizes (the 90 inch you mentioned)
Illustrator doesn’t look to have updated the height and width fields correctly.
For comparison this is the original svg in Inkscape
When I change the height and width in Inkscape xml editor to their proper values things get much better.
the scale is correct and height and width are correct but there is space around the viewbox now. If I ungroup the svg (to avoid adding translates when Inkscape modifies the svg)
then do a Edit->resize page to selection the sizes are somewhat smaller (probably indicating the scale in Illustrator isn’t quite right, possibly because of the bad height and width values?)
the height should be 6.5in not 6.34 and height should be 2.1in not 2.049in but that is remarkably close. If you can figure out how to get Illustrator to set the height and width correctly this may work. I expect that may be difficult because as I said from reading their docs, they appear to feel you should work about the internal details and leave that to them.
Peter
I redownloaded your latest fzpz and noticed that the red plus signs in the bottom are causing a selection that is too large, see there:
The properties for me are:
If i adjust it to y 1,9116 , then there are no ‘outer bounds’ in the selection. I did everything I mentioned in my last reply and saved the svg. Can you test this file again if this fixes the space around the viewbox?
Yes that appears to fix things. Changing the height and width this time gets the scale correct and all appears well.
It stayed well when I did an “edit->select all” and “edit-resize page to selection” then regrouped the svg
If you can figure out how to get Illustrator to update the height and width to the correct values that should do the job. If that isn’t possible even documenting what you need to do in Illustrator to get the dimensions in inches would be a big help (its default setting of px makes the svgs unusable in Inkscape as the scale changes and unless we know the dimensions of the part we have no way of rescaling it!)
edit
Which + is wrong in Illustrator? I’ll have a look at it in Inkscape and see if I can see why it is unhappy.
edit2
I would guess it is this one:
it has both a transform which isn’t in the original svg and has changed font family from OCRA to ArialMT, Arial which Fritzing won’t accept, it will substitute either OCRA or ‘Droid Sans’ when the part loads as they are the only two it accepts (the fonts are available on the Fritizng.org site if you don’t have them.)
Peter
the version of the svg i just send you is the best Illustrator can do. Once i change back to 6.5in width, the viewbox will go back to 467 (the pixel equivalent of 6.5in). How do you want me to create that tutorial? Somewhere in this forum?
Check the image i send of the wrong +. Both the red plusses on the bottom were positioned too low
lol i was just replying again saying my exported svg still has ArialMT, Arial in it. Ill try your link for the font.
i installed ocra font. Re-did everything from before. Also changed width and height in code editor to 6.5in and 2.1in. Can you check this svg?
Could you create a new fzpz if the svg is correct now? for future testing purposes
edit: maybe its better to convert the - and + signes to outlines instead of characters. That way we don’t need to reposition. Just a thought.
The svg looks fine. Did you have to manually change the height and width? While I don’t know what is going on in Illustrator, I wonder if this will work to make this automatic.
I’m wondering if subtracting the difference between the width and what the width should be in the svg, and then subtracting the same amount from X will work to set the height and width correctly like this
x - 83.77 = -80.02 to make the width be 6.5in (setting 6.5in for the width in Illustrator and
height 29.27in wants to be 2.1in so subtract 27.17 from y -1.07in = -28.24in and maybe the height and width will be correct. I’m not sure where the values in x and y come from, but this should keep the ratio correct while ending up with the correct number in height and width. In any case here is a new part with the new svg. For some reason FritizngCheckPart.py is flagging a scale error when the svg appears to be correct (it may be an issue with the limits being too tight in the check I’ll have to see later.)
Warning 32: File
‘svg.breadboard.breadboard-bb-32655-pwr-rails-aligned.svg.bak’
At line 10
Scale is not the desirable 1/1000 ratio from width/height to
viewBox width/height.
as far as I can see the ratio is correct though. If you have the current part loaded you will need to delete it then restart Fritzing (to really delete it) before it will let you load this new part.
breadboard-bb-32655-pwr-rails-aligned-newsvg.fzpz (37.3 KB)
That can be done, but I would rather leave them as text and figure out why there is a problem. They can be converted to a path which eliminates font issues, but it makes modifying the part more difficult because you don’t know what font the person that made the part used if you need to change the text.
Peter
ill try your suggestion later on, but don’t think it works. The x and y is only for positioning the shapes relative to the artboard. As soon as you change anything on the width and height for the artboard, the 6499 value in the viewbox changes also. Bad luck there…
About the font: it’s just how fonts work. They have like “extra room”. If you edit the character and add a underline, it actually appears below the artboard. The plus is also a bit smaller then a regular character. So our best approach would be to position this character a bit more upwards (like I mentioned earlier).
edit: no your suggestion didn’t work. It’s just not possible in Illustrator.
Could you explain again what is wrong with having a width of 6.5in and height of 2.1in while the viewbox is 0 0 468 151? Was that something Fritzing couldn’t handle correctly? Because on the web, the viewbox is only used for creating “user units”. If the viewbox has a width of 468, then a rectangle that is as large as the artboard also has width=“468”. If the viewbox has 0 0 6499 2100 then the rectangle would have width=“6499”. Tot width and height of the artboard itself (the 6.5in and 2.1in) would only be used for displaying the svg as a whole to the correct dimensions.
No it doesn’t cause any problem, it just isn’t to the standard. An svg with the wrong scale will work as well as one with the right scale. The important part is getting Illustrator to use inches or mm rather then px (because px depends on the DPI that the editor is using and has changed over time, it used to be 90DPI and is now 96DPI I think in the svg standard although I’m not sure.) I’m not all that surprised that Illustrator won’t do it, as their docs should have it if it would and they don’t appear to. Thanks for trying anyway!
Peter
ok. Well, not sure if we talked about that, but that is just a setting :
When setting this to inches, the width and height of the artboard is set to inches. Exporting to svg will give you width=“6.5in” height=“2.1in”. Only thing is that viewbox is always set to pixels. Illustrator works with 72 DPI for the conversion. 1/72 = 0,01389. And 6,499 in / 0,01389 is 468.
That is the setting I need. As long as dimensions are in inches all will be well. The viewbox being in px can be worked around if we want by rescaling in Inkscape, but because the svg is in real world units the drawing will always be the same size because an inch is an inch, and all will be well. Thank you! I’ll add this to a how to configure Illustrator howto.
Peter
Getting a little off topic here but, just for the record, I use a very old version of Illustrator (CS3) and in that case the SVG output dimensions are always presented as px, regardless of the units used within Illustrator or the options used when saving in SVG format. There are several things that the Parts Editor does to the [Illustrator-sourced] SVG files it is given but I believe the critical change in the present context is simply the conversion of the height and width attributes in the svg tag from px to in, and this would appear to be a simple conversion based on 72 pixels per inch.
I’ve looked at a sample of several cases and typically the svg tag looks like the following when output from Illustrator:
<svg version="1.1" id="breadboard" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
width="59.445px" height="49.606px" viewBox="0 0 59.445 49.606" enable-background="new 0 0 59.445 49.606" xml:space="preserve">
The Parts Editor drops the xmls:xlink attribute, adds a gorn attribute and rearranges the attributes (somewhat illogically to my way of thinking, I might add) to yield:
<svg xmlns="http://www.w3.org/2000/svg" enable-background="new 0 0 59.445 49.606" version="1.1" id="breadboard" x="0px" height="0.688972in" y="0px" xml:space="preserve" viewBox="0 0 59.445 49.606" gorn="0" xmlns:xml="http://www.w3.org/XML/1998/namespace" width="0.825625in">
That appears to be the only ‘dimensioning’ change that is made (note that the x and y attributes retain their px unit identifier—maybe 0 is 0 on any scale, so that doesn’t upset anyone). The Parts Editor also adds a desc attribute and gorn attributes to groups (<g> tags) that have id attributes—I didn’t know how important those things were, so I was happy to just feed everything through the Parts Editor and let it do what it thought needed to be done.
The other issue, which I think is a little more general than just Illustrator, is the need to ensure that content is enclosed within an ‘outer’ group tag—[for me] that seems to happen some times but not others, and I’ve never really worked out the pattern, so that’s one of the things I check/do manually (through a text editor).
That older versions of Illustrator always use px is good to know as that would make the advise to change to “in” wrong on old Illustrator versions. I guess we just have to leave it where it is and deal with the consequences. It is possible to rescale the svg with Inkscape from 72DPI to 96DPI and then change the units to in and that maybe needs to be the solution. As you note feeding the svg through parts editor looks to clean things up (I believe even 0.9.3 guess 72DPI if it thinks it is Illustrator so that may have always happened or the developers may have fixed parts editor to react better in newer Fritzing versions. I was hoping for an easier solution but it looks like there isn’t one.
Peter
I think we can conclude that one should use an svg measured in inches only for width and height for the svg. The rest (including the viewbox) can be still in pixels.
If someone uses an old Illustrator that only generates pixels, including width and height for the svg itself, then those people should convert the width and height values themselfs (just give them an example), thats like half a minute of work. Sure, you coudl give people advice to use inkscape, but I would be more happy with this little extra trick in a code editor and just use illustrator, buts thats a personal thing, that might be the case for others.
one more question, what is the problem with some parts that can’t connect correctly or precisely enough to the ports?
when i put it just a bit hight it turns blue/green:
Is this due to incorrect port placements in the svg? or something else?
PS i could swear someone posted the same question about a part not connecting correctly to the ports, but cant see that anymore here
edit: found it VTL 5C1 or the like vactrol - #4 by poetaster
In this case it is likely misalignment in the breadboard svg or that you need to move the part slightly to align to the grid.
this post from just now is likely what you are thinking of, it discusses this same issue on a new part.
Peter
my OCD can’t handle this. You think I should dive into this and try to fix it in the breadboard svg?
It should be fairly easy to do, the pins (or more likely a terminalId as the pin isn’t aligned to the middle of the pin as it would be without a terminalId) is likely misaligned. In breadboard and that should be easy to fix (although those have been famous last words before .) Centering the terminalId on the pin in x should do it (easiest way is make the terminalId same width as the pin and symmetrical and then make it identical to the start point of the pin, that is usually what I do. )
Peter