I’m updating a previous custom Fritzing part (Raspberry Pi Pico) and am trying to update the PCB and schematic options. However, when I “Load image for view”, all the fonts are going mad, extra large etc. I also get an error message as follows despite already using Droid Sans.
“Fritzing currently only supports OCRA and Droid fonts–these have been substituted in for the fonts in ‘/home/jamesh/Downloads/rpi_pico-tht_1_schematic.svg’”
I have tried the script I found here, GitHub - vanepp/FritzingCheckPart, and also manually edited the font sizes in the SVG but nothing seems to help.
Should we be moving to OCR-Fritzing-mono.otf
I am using 1.0.3 to do this work, but I have a possible fly in the ointment, where Raspberry Pi OS uses 0.96, and I need to be backwards compatible.
Upload the .fzpz file for the part that is failing (upload is 7th icon from the left in the reply menu) and I will have a look at it and see what is going wrong. The first thing that I would have suggested is that you have px in the font size, but FritzingCheckPart.py will correct that. It may still be the issue as it is the most common cause of incorrect font size, but I need to be able to look at the part to tell.
The problem isn’t pxs in this case but probably is transforms and defs. Fritzing only supports the svg tiny 1.2 standard and sometimes objects to things defined in defs and transforms. I’ll see if I can fix up the svg in Inkscape and post new copies. Inkscape renders both correctly (not a big surprise!)
but neither the forum not Fritzing will. I probably have similar svgs and it will likely be easier to give you two of them to start from. Indeed I do (I fixed up the original part from the RPI folks a couple of years ago):
svg.pcb.rpi_pico-tht_1_pcb.svg
svg.schematic.rpi_pico-tht_1_schematic.svg
to download the svgs right click on them and select save image as. These two svgs meet the Fritzing Graphics standards and work in Frizting (they are from my corrected Raspberry PI Pico part.) These two have been through FritzingCheckPart.py and are thus currently px free, but if you edit them you then need to either remove the px from the font size with a text editor or run it through FritzingCheckPart.py as for CSS compliance Inkscape (and I expect all svg editors) add px to the font size when editing. Hope this helps!
Those were the originals we used before modification (I work for Pi btw, so this is all “official” stuff!). The problem is the modifications we need to make are breaking things and adding all the cruft. I wonder if Illustrator can specify the SVG version to use? Need to check with the graphic design people. We might need to manually edit the old SVGs to add the changes in the new SVGs.
As far as I can see from the Illustrator documentation (I don’t have Illustrator!) there isn’t as much control of things such as document scale, it seems to me that it defaults to what they think is a reasonable value which Fritzing often doesn’t agree with. Inkscape has much more control of all parts of the document, but probably isn’t an option if your standard is Illustrator. If you like I can try and remove the defs from your svg and document how I did it, but I’m not sure it will help as Illustrator may just put them back in again. There are (or at least used to be, I haven’t seen some of them post recently!) folks in here that use Illustrator successfully with Fritzing so there may well be workarounds that I am not aware of. Sorry I can be of more help!
I must confess that I have always had problems importing [Fritzing] SVGs back into Illustrator for editing. I have certainly seen font scaling problems in the past, but I think I only resolved them by doing any editing on the original Illustrator files—the .ai files—and then exporting the updated image again as an SVG file.
My work flow is perhaps not ideal, but I always import my Illustrator SVGs, originals or updates, into the Parts Editor and generate the new or updated part that way—I rarely use Illustrator to work on the SVGs from the Fritzing part, and never if I have the original Illustrator file.
The main thing the Parts Editor does (in my situation) is resolve the Illustrator dimensioning problem related to defining everything in pixels—and if you edit the SVG file in Illustrator, that problem is just reintroduced. Other problems that I have encountered, like the font problem that I had (which I don’t recall being exactly what you are seeing, but it was a scaling issue) were resolved by going back to the Illustrator file, changing whatever needed to be changed there to achieve the desired result, regenerating the relevant SVG file, importing that again into the Parts Editor and generating the updated Fritzing part that way.
I also work on a Mac (several, actually) and I have noticed that I seem to have two versions of the OCRA font (OCRA and OCR A) on one machine—only one of them gets a ‘clean bill of health’ from the Parts Editor, the other gets ‘substituted’. That’s never been a real problem in my situation, but maybe there’s something like that going on with the Droid Sans font in your case—different versions used on the systems used to generate the original file vs the current one.
So, I think we have a solution. Illustrator when you save as SVG has the option to select the SVG version, and selecting SVG 1.2 Tiny seems to make compatible files. Well, they import in to Fritzing without the nasty font scaling anyway. I may run them through the checker to see if there is anything left untoward as there might be scaling issues as per previous post. Note that we are working from the original illustrator files rather than importing back from Fritzing which may means thigs are a little easier.
if this is in px (which I think is Illustrator’s preferred setting) Fritzing will guess at what the px to DPI is (72DPI or 90DPI with current Inkscape and I think the svg standard currently using 96DPI) this will cause scaling problems in Fritzing when it guesses wrong. FritzingCheckPart will find that and issue a warning that dimensions are in px though. It looks like your current SVGs should be fine though. Good luck and feel free to post if you have more problems, always happy to help people make parts!
