Hi everyone,
I don’t know what I was doing when I edit bread board image on Inkscape. I just edited the text but then when I import to part editor the text become out of scale.
Anyone can explain and teach the right way how to do that?
Thanks.
Either run FrtizingCheckPart.py or after exiting Inkscape edit the modified svg with a text editor and do a global replace of px with “”. What is happening is Inkscape is adding px to the font-size parameters (for CSS compliance) and Fritzing objects to it and either sets the font size to 0 (too small) or maximum (too large as in this case.) FritzingCheckPart.py will remove the px from font-size, plus do a number of other checks and adjustments and complain about errors. It is available in this tutorial somewhere (I don’t remember which section at the moment) on part making. You may want to look at Old_grey’s if you are using parts editor as well
the title and then they come up on YouTube.
Peter
Small remark: Using font-size units like mm or inch is also css compliant 
But device dependent units like px or em, or even “small” and “medium” would cause a lot of headache when printing on 300dpi, etching at 1000dpi, and rendering in a browser on an old pc or modern retina display…
The issue is the px in the font size, Fritzing either sets the font size to 0 or (I think! 256) and makes the font either too small or too large. Removing the px from the font size makes it display properly in Fritzing. If that could be done on input (I expect it probably happens in QT though) that would be good. The parts file spec used to recommend not having px on font-sizes, when I looked just now it now longer seems to but the issue is still there.
Peter
Removing the px on the fly is not a solution. It will create unexpected results.
The problem is inherent in the SVG format. As soon as you mix some absolute dimensions with device dependent dimensions (e.g. inch and px), then you get distorted results.
The problem is not Fritzing specific. Some editors work around it by removing absolute dimensions. This is quite annoying, we then need to guess, for example if a rectangle is supposed to be 2mm or 2inch wide.
For PCBs, but even for breadboards, we want device independent, absolute sizes. You can not use pixel for that.
So, if you get a proper display by removing the font size, this is just luck (and some very unreliable heuristic, that fritzing uses to guess the actual relation of pixel to mm) . Removing the px must therefore be done manually, by the creator of the part. If we “automate” it, we will get random font sizes.
I though there must be a reason for it not being done by Fritzing, but didn’t know what it was (thus the guess that it is done by QT.) FritzingCheckPart.py does just fine by removing the px from only font size, that leaves Fritzing happy with the correct font size (where a px in a font size causes problems, but I think it is intermittent, i.e. a px in the font size doesn’t always cause a problem only sometimes.)
Peter
Automatically removing the “px” from a font will change the size of the font, unless the viewbox, width, and height attributes of the SVG define the same dpi as the device that the font was tested on.
If you remove the unit, you need to use an algorithm that contains some guesswork, to preserve the intended font size. The algorithm could go like this:
Step 1
1.a. If it is “px”, assume 96dpi for Windows. On macOS use 72dpi
1.b. If it is “pt”, assume 72dpi.
1.c. To be confirmed: Adobe Illustrator uses 72dpi for fonts in pixel?
1.d. What dpi does Linux assume for font sizes in px vs pt?
Step 2a
If the SVG has viewbox, width and height, then calculate the dpi from that
Step 2b
If the SVG has no viewbox, we need to apply Fritzing heuristic, 90dpi for regular SVGs, and 72 DPI for Adobe Illustrator. This is a bit wonky, I guess Inkscape uses 96dpi by default.
static constexpr double IllustratorDPI = 72;
static constexpr double StandardFritzingDPI = 1000;
static constexpr double SVGDPI = 90;
Step 3
Recalculate the font size with the ratio of the two derived dpi values.
Especially if the viewbox is missing, this gets wrong way to easy. We need the viewbox, to get a reliable physical size.
But rule 1a. and 1b. might already cover 95% of Fritzing parts, probably all created by you @vanepp? 
I did some efforts in Fritzing 1.0.5 to have unified font sizes on macOS, Windows and Linux, especially for exporting to gerber, and to avoid cut of labels in schematic view. It is much better, but not perfect, and the sane method (but not sure if this is worth it, nobody complained?) would be to render the font into a polygon, and always store the polygons in the .fzz file.
Lets assume we leave the “px” values in the SVG. We could for example just warn. And then treat all font sizes in px at 96dpi … we can’t really determine if the part was created on macOS, and therefore apply the wrong size for files designed on macOS.
My preference was to just not use px or any other unit for font sizes. Many tools use CSS, and the CSS standard allows using px, but the pure SVG standard doesn’t. And it makes lives complicated.
Maybe this explanation helps:
I guess I should try and reproduce the issue. I think (but don’t know that I have ever caused it because I rarely use parts editor) is that processing a part with px in the font-size will change the font size under some circumstances. The advise in the parts format document said don’t put px in font size and that has always cleared the problem when it occurs. Having a case where it happens may provide illumination about what is happening and what can be done about it. I have never seen a report of a font size problem when the part didn’t have px in the font size, but that may just be me running on windows and not understanding all the issues involved. I’ll make a file with px in the font size and run it through parts editor and see if I can break it.
Peter
Just for the record, as an Illustrator user who has experienced this problem, I have subsequently avoided the issue by converting all text in the breadboard view to outlines (an option in the Illustrator Type menu). This also means that I can then effectively use any font in these illustrations because text then becomes just another ‘drawing element’ and is no longer rendered as a font, as such.
That of course bloats the size of the SVG file. Outlines are a lot bigger (need more space in the file) than text strings. It also make certain automatic (runtime) adjustments impossible. Like rotating labels to compensate for rotated parts.
I would add it is also annoying when trying to modify the part because you don’t necessarily know what font and size were used in the text so usually have to reinsert the text using one of the supported fonts.
Peter
Yes, I understand the bloat issue, but in my case the quality of the breadboard image is what I’m after. As far as rotation goes, the text image should rotate with the part… It has done for me any time I’ve needed it to… Maybe that’s related to how the two elements are grouped?
And yes, I agree here. It’s annoying for me too, especially when I’ve gone to the trouble of matching an unusual font and can’t remember what it was! I’ve taken to retaining the original in a separate layer that I delete from the SVG copy of the file that I use for the Fritzing part. And yes, I understand that this is more than the average user would care to do for little more than a pretty picture… 
Inkscape does this as [object to path], which usually materially benefits from [simplify path].
Albeit results vary, sometimes [object to path] yields better results than [stroke to path] and visa versa.
There is less difference than one would believe if the path is simplified. Yes bigger, but not necessarily by much.
Examples, showing “NO”:
<text transform="scale(.265)" fill="#000000" font-family="sans-serif" font-size="40px" letter-spacing="0px" word-spacing="0px" style="line-height:1.25;shape-inside:url(#rect236);white-space:pre" xml:space="preserve"/>
<g id="textS2P" style="white-space:pre" aria-label="NO">
<path d="m39.4 63h1.41l3.42 6.45v-6.45h1.01v7.72h-1.41l-3.42-6.45v6.45h-1.01z"/>
<path d="m50.4 63.7c-0.758 0-1.36 0.282-1.81 0.848-0.444 0.565-0.667 1.34-0.667 2.31 0 0.972 0.222 1.74 0.667 2.3 0.448 0.565 1.05 0.848 1.81 0.848s1.36-0.282 1.8-0.848c0.444-0.565 0.667-1.33 0.667-2.3 0-0.975-0.222-1.74-0.667-2.31-0.441-0.565-1.04-0.848-1.8-0.848zm0-0.848c1.08 0 1.95 0.364 2.59 1.09 0.648 0.724 0.972 1.7 0.972 2.91 0 1.22-0.324 2.19-0.972 2.91-0.648 0.724-1.51 1.09-2.59 1.09-1.09 0-1.95-0.362-2.6-1.09-0.648-0.724-0.972-1.7-0.972-2.91 0-1.22 0.324-2.19 0.972-2.91 0.651-0.727 1.52-1.09 2.6-1.09z"/>
</g>
<g id="textO2P" transform="matrix(.265 0 0 .265 .402 43.4)" style="shape-inside:url(#rect417);white-space:pre" aria-label="NO">
<path d="m149 152h5.31l12.9 24.4v-24.4h3.83v29.2h-5.31l-12.9-24.4v24.4h-3.83z"/>
<path d="m190 155q-4.3 0-6.84 3.2-2.52 3.2-2.52 8.73 0 5.51 2.52 8.71 2.54 3.2 6.84 3.2 4.3 0 6.8-3.2 2.52-3.2 2.52-8.71 0-5.53-2.52-8.73-2.5-3.2-6.8-3.2zm0-3.2q6.13 0 9.8 4.12 3.67 4.1 3.67 11 0 6.89-3.67 11-3.67 4.1-9.8 4.1-6.15 0-9.84-4.1-3.67-4.1-3.67-11t3.67-11q3.69-4.12 9.84-4.12z"/>
</g>
Manual optimisation can still improve.
<g id="textOptimised">
<path d="m40 108-0.0287-7.54 4.81 7.02 0.0178-7.54" fill="none" stroke="#000" stroke-linejoin="round"/>
<path d="m50.1 101c1.85 0.0153 3 1.67 3.04 3.52s-0.99 3.6-3.13 3.57c-2.14-0.0366-3.1-1.97-3.06-3.73s1.36-3.31 3.15-3.36z" fill="none" stroke="#000" stroke-linejoin="round"/>
</g>
Well it appears it isn’t as simple as just leaving the px in the font-size and loading the file in to parts editor. I tried that and it doesn’t fail so there is a step I am missing but I don’t know what it is. The px is the problem because I downloaded the part from this post
and made the single change of removing the px from the breadboard svg’s font-size def (with vi) and remade the part which then works fine. I think this happens when you edit the part in parts editor, but I don’t know what you need to do to cause it, because everything I have tried so far works correctly. I’m hoping that the working / not working example here tells you something because it isn’t telling me anything. When I did the original post I ran the part through FritzingCheckPart.py which makes multiple changes (inlining styles for one) as well as removing the px from the font sizes. In this case the only difference in the breadboard svgs is the px being removed from the font size. There may be something else that I am not seeing that causes the font size change as well (which I think is likely triggered by something in parts editor!) This is this part
BD135-fixed.fzpz (5.4 KB)
which works correctly
this is the original part (where the only difference is the px removed from the text font size) which doesn’t work correctly
BD135.fzpz (5.4 KB)
but does this (note the representation in the icon is correct and what Inkscape shows!) This is why FritzingCheckPart removes the px from font-size, because it has made this work in every case that I am aware of.
The alternate version is when it sets the font size to close to 0 and the font is very small. Hope this sheds some illumination for you because it isn’t for me so far .
Peter